spaceengine吧 关注：19,727贴子：96,136
综述：
SE程序的文件夹（SPACEENGINE FOLDERS）
Space Engine有两个包含数据文件的文件夹，你可以在安装目录中找到，分别是：Data和addons。这两个文件夹的功能大体相近，第一个文件夹包含有标准的SE程序文件，你不应该去修改他们，第二个文件夹的内部结构和第一个文件夹相同（Thesecond mirrors the internal structure of the first one, and is used for usermods and addons.）且在程序启动并开始加载游戏文件时有着较高的优先级，这意味着如果在addons文件夹放入一些文件，且目录名和在Data中的相同时，SE就会加载addons里的文件了。这对于创建要修改原本的SE文件的mod来说很有用，比如shaders，而且不用直接更改SE主文件。
Data文件夹中有这些标准子文件夹：catalogs, locale, models, music, scripts, shaders, sounds, textures.“标准”意味着SpaceEngine要求在这些文件夹里查找特定的内容，比如音乐文件一定在data/music/中，星球目录（star catalogs）一定在data/catalogs/stars/中（有些子文件夹中可能还会有（子标准）文件夹（some of these subfolders have their own next-level standardsubfolders inside））
Addons文件夹可以同样包含有这些标准文件夹，他们的功能和data文件夹内部的文件夹目录相同，这便意味着SE会同时加载data和addons文件夹中的内容，如同他们是同一个文件夹一样（但是addons文件夹享有更高优先级，如果其中文件名与data中相冲突（相同），发生的事情同上述）（but with higher priority for addons in case of a file name conflict,as has been described above）。
为了更好的管理addons，addons文件夹同样允许在其中建立其他子文件夹，这些子文件夹名可以是任意的，通常是插件（addon）名字（显然，不能和data里的那些标准文件夹名字相同），比如：addons/StarWars/就可以。在这些其他名字的文件夹里还可包含标准子文件夹：catalogs,models, textures诸如此类，或者直接包含一个pak文件（详见下文），或还包含其他名字的文件夹，比如：addons/StarWars/EmpireShips/，SE不限制这样嵌套的文件夹的数量（但会被操作系统限制，通常路径长度不超过256个）。
SE程序的文件夹（SPACEENGINE FOLDERS）
Space Engine有两个包含数据文件的文件夹，你可以在安装目录中找到，分别是：Data和addons。这两个文件夹的功能大体相近，第一个文件夹包含有标准的SE程序文件，你不应该去修改他们，第二个文件夹的内部结构和第一个文件夹相同（Thesecond mirrors the internal structure of the first one, and is used for usermods and addons.）且在程序启动并开始加载游戏文件时有着较高的优先级，这意味着如果在addons文件夹放入一些文件，且目录名和在Data中的相同时，SE就会加载addons里的文件了。这对于创建要修改原本的SE文件的mod来说很有用，比如shaders，而且不用直接更改SE主文件。
Data文件夹中有这些标准子文件夹：catalogs, locale, models, music, scripts, shaders, sounds, textures.“标准”意味着SpaceEngine要求在这些文件夹里查找特定的内容，比如音乐文件一定在data/music/中，星球目录（star catalogs）一定在data/catalogs/stars/中（有些子文件夹中可能还会有（子标准）文件夹（some of these subfolders have their own next-level standardsubfolders inside））
Addons文件夹可以同样包含有这些标准文件夹，他们的功能和data文件夹内部的文件夹目录相同，这便意味着SE会同时加载data和addons文件夹中的内容，如同他们是同一个文件夹一样（但是addons文件夹享有更高优先级，如果其中文件名与data中相冲突（相同），发生的事情同上述）（but with higher priority for addons in case of a file name conflict,as has been described above）。
为了更好的管理addons，addons文件夹同样允许在其中建立其他子文件夹，这些子文件夹名可以是任意的，通常是插件（addon）名字（显然，不能和data里的那些标准文件夹名字相同），比如：addons/StarWars/就可以。在这些其他名字的文件夹里还可包含标准子文件夹：catalogs,models, textures诸如此类，或者直接包含一个pak文件（详见下文），或还包含其他名字的文件夹，比如：addons/StarWars/EmpireShips/，SE不限制这样嵌套的文件夹的数量（但会被操作系统限制，通常路径长度不超过256个）。
PAK文件：
pak文件即zip压缩文件，它给游戏内容提供了更好的组织和发布方法。例如，一个非常大的插件（addon）含有上千个文件，便可以被压缩成一个pak文件并且发布在这里，这对于用户来说就更加方便了，创建zip格式的压缩文件是用来创建pak文件的方法，对于节约磁盘空间和下载流量很有用。
pak文件就是一个zip压缩文件，其包含着在硬盘上有相同组织结构文件和文件夹（pak files are zip archives that include files and folders with the same structure as they have on the disk，starting from the data or addon root level (or addon/YourCustomFolder/)）（注：这里应该说的是pak文件里的东西就是之前直接放入addons里的那些文件，目录和文件的组织方式和没有被压缩前应该是要一样的）这意味着可以被压缩进pak里的文件夹应该是这些标准文件夹：catalogs, models, textures……诸如此类(或者是addon里的文件：addon/你的文件夹 /)。
pak文件即zip压缩文件，它给游戏内容提供了更好的组织和发布方法。例如，一个非常大的插件（addon）含有上千个文件，便可以被压缩成一个pak文件并且发布在这里，这对于用户来说就更加方便了，创建zip格式的压缩文件是用来创建pak文件的方法，对于节约磁盘空间和下载流量很有用。
pak文件就是一个zip压缩文件，其包含着在硬盘上有相同组织结构文件和文件夹（pak files are zip archives that include files and folders with the same structure as they have on the disk，starting from the data or addon root level (or addon/YourCustomFolder/)）（注：这里应该说的是pak文件里的东西就是之前直接放入addons里的那些文件，目录和文件的组织方式和没有被压缩前应该是要一样的）这意味着可以被压缩进pak里的文件夹应该是这些标准文件夹：catalogs, models, textures……诸如此类(或者是addon里的文件：addon/你的文件夹 /)。
1.PAK文件格式：
Pak文件就是zip压缩文件（i.e. .zip文件，其扩展名被重命名为.pak）。你可以用WinRAR或者7zip或者随便什么你爱用的压缩软件来操作这些文件，打开pak文件、提取里面的文件……建立.pak文件十分简单，选择需要打包的文件和文件夹，将他们压缩成为zip文件，最后再把扩展名改成.pak就好了。
2.虚拟目录
也许你以为一个pak文件仅仅只是一个包含文件夹和文件的容器，其实在pak文件是SE文件夹的延续，也就是说，SE会查看在磁盘上的文件和文件夹以及在pak文件里的所有文件，如同他们没有打包进pak，pak文件里包含的那些东西解压到和当前pak文件同目录的文件夹里那样，我们提出虚拟路径（virtual path）的概念，正常的路径名在本文中会被标为绿色，pak文件及其内部的文件会被标记为红色
例：这三个目录的作用效果是同等的：（StarWars文件夹是可选的）
Pak文件就是zip压缩文件（i.e. .zip文件，其扩展名被重命名为.pak）。你可以用WinRAR或者7zip或者随便什么你爱用的压缩软件来操作这些文件，打开pak文件、提取里面的文件……建立.pak文件十分简单，选择需要打包的文件和文件夹，将他们压缩成为zip文件，最后再把扩展名改成.pak就好了。
2.虚拟目录
也许你以为一个pak文件仅仅只是一个包含文件夹和文件的容器，其实在pak文件是SE文件夹的延续，也就是说，SE会查看在磁盘上的文件和文件夹以及在pak文件里的所有文件，如同他们没有打包进pak，pak文件里包含的那些东西解压到和当前pak文件同目录的文件夹里那样，我们提出虚拟路径（virtual path）的概念，正常的路径名在本文中会被标为绿色，pak文件及其内部的文件会被标记为红色
例：这三个目录的作用效果是同等的：（StarWars文件夹是可选的）
3.按修改日期排列的加载优先级（PRIORITY BY MODIFICATION DATE）
如果有两个或更多同样的文件在同样的虚拟路径中，SE会加载最新修改的那个，SE会比较磁盘上的文件以及pak文件，以及pak里面的文件的修改日期……。
例：（注：文件日期应该是被创建的日期）
这种情况下，SpaceEngine则会加载最后一个，因为它的日期最新，这对于制作更新包很有用。
但是，使用这个插件：
这个时候，SE却会直接加载这个插件，而不考虑日期，这是因为在addons文件夹里的文件有着比data文件夹更高的加载优先级，为了防止在更新默认的SE程序文件后破坏插件才这么做，但单独在addons文件夹下，新日期文件优先加载依然是适用的
（Inside the addons folder, the same file/pak modification date priority rules apply.）
如果有两个或更多同样的文件在同样的虚拟路径中，SE会加载最新修改的那个，SE会比较磁盘上的文件以及pak文件，以及pak里面的文件的修改日期……。
例：（注：文件日期应该是被创建的日期）
这种情况下，SpaceEngine则会加载最后一个，因为它的日期最新，这对于制作更新包很有用。
但是，使用这个插件：
这个时候，SE却会直接加载这个插件，而不考虑日期，这是因为在addons文件夹里的文件有着比data文件夹更高的加载优先级，为了防止在更新默认的SE程序文件后破坏插件才这么做，但单独在addons文件夹下，新日期文件优先加载依然是适用的
（Inside the addons folder, the same file/pak modification date priority rules apply.）
5.创建pak文件
例：试想你在制作一个行星系统插件，它包含下面这些文件：
当你完成制作和测试并且准备发布时，到StarWars文件夹下，选中catalogs文件夹，然后把它打包成zip格式的压缩文件，再重命名为StarWarsPlanets-v001.pak，文件名是什么其实无关紧要，但是它应该能够反映出文件内容，附加上版本信息就更好了。然后，删除之前的catalogs文件夹以及里面的所有内容（或者把它移动到一个备份的地方）最后留下那个刚刚创建的pak文件，如果你正确的打包好了，你的插件应该像以前一样运行，你的数据文件将会有以下虚拟目录：
这样你就可以分享这个StarWarsPlanets-v001.pak到社区了。注意，放在addons里的任何一个文件夹里这个插件都能够正常工作（标准子文件夹除外），例如：
你可以往pak里放入一切文件，比如，你可能创建一个完整版Star Wars franchise pak，它包含了所有的行星系统，星系，星系模型和所有的飞船模型，但要注意这里还有一些限制。
6.限制
1）SE的根目录（安装目录里）不可以作为放置pak的目录，例：
2）pak文件里不能再包含其他名称的目录，只允许有默认标准目录，以下组织方式无效：
3）单个pak文件大小不能超过4GB，如果你的插件比4GB更大，因该分开打包一些文件。
4）ogg格式的音乐文件不可以再被压缩进pak文件
7.压缩率
Zip文件可以选择是否进行压缩，SE只支持Deflate（默认）压缩选项（注：其实是2种，一种是默认zip的压缩，还有一种在一些压缩软件里叫做”无“或者”存档“即不使用压缩算法压缩文件只是把一堆文件打包成zip格式）。
有一些文件类型有着很高的压缩率（文本文件，比如scripts和catalogs），有一些只有中等大小的压缩率（二进制文件，如：飞船模型，.sm、.dds、.tga图像），有些几乎无法再被压缩（.jpg、.png、.ttf图像）。
将大量的图形图像文件（例如行星贴图）打包成不压缩的zip文件是个好方法，因为这样做你将获得很好的加载性能，高性能永远比节约几兆磁盘空间好，你可以自己试试，为你的插件找到一个合适的压缩选项，如：你可以把贴图单独打包为一个“不压缩”的pak文件，但是将脚本和其他模型打包成另外一个pak文件并且选择压缩。
例：试想你在制作一个行星系统插件，它包含下面这些文件：
当你完成制作和测试并且准备发布时，到StarWars文件夹下，选中catalogs文件夹，然后把它打包成zip格式的压缩文件，再重命名为StarWarsPlanets-v001.pak，文件名是什么其实无关紧要，但是它应该能够反映出文件内容，附加上版本信息就更好了。然后，删除之前的catalogs文件夹以及里面的所有内容（或者把它移动到一个备份的地方）最后留下那个刚刚创建的pak文件，如果你正确的打包好了，你的插件应该像以前一样运行，你的数据文件将会有以下虚拟目录：
这样你就可以分享这个StarWarsPlanets-v001.pak到社区了。注意，放在addons里的任何一个文件夹里这个插件都能够正常工作（标准子文件夹除外），例如：
你可以往pak里放入一切文件，比如，你可能创建一个完整版Star Wars franchise pak，它包含了所有的行星系统，星系，星系模型和所有的飞船模型，但要注意这里还有一些限制。
6.限制
1）SE的根目录（安装目录里）不可以作为放置pak的目录，例：
2）pak文件里不能再包含其他名称的目录，只允许有默认标准目录，以下组织方式无效：
3）单个pak文件大小不能超过4GB，如果你的插件比4GB更大，因该分开打包一些文件。
4）ogg格式的音乐文件不可以再被压缩进pak文件
7.压缩率
Zip文件可以选择是否进行压缩，SE只支持Deflate（默认）压缩选项（注：其实是2种，一种是默认zip的压缩，还有一种在一些压缩软件里叫做”无“或者”存档“即不使用压缩算法压缩文件只是把一堆文件打包成zip格式）。
有一些文件类型有着很高的压缩率（文本文件，比如scripts和catalogs），有一些只有中等大小的压缩率（二进制文件，如：飞船模型，.sm、.dds、.tga图像），有些几乎无法再被压缩（.jpg、.png、.ttf图像）。
将大量的图形图像文件（例如行星贴图）打包成不压缩的zip文件是个好方法，因为这样做你将获得很好的加载性能，高性能永远比节约几兆磁盘空间好，你可以自己试试，为你的插件找到一个合适的压缩选项，如：你可以把贴图单独打包为一个“不压缩”的pak文件，但是将脚本和其他模型打包成另外一个pak文件并且选择压缩。
8.千万别碰默认的pak文件
和所有其他的游戏一样，更改默认的游戏资源是一个坏主意，在未来，游戏客户端将会检查默认的文件是否被修改，如果它们被修改，你将会被踢出服务器（SE未来还能变成网游？）所以请记住：
1）如果你想加入什么，新建一个pak文件，或者直接放入文件夹中
2）如果你想修改什么，就从默认的pak中提取文件然后修改那血提取出来的文件。
In the future, the game client will check the default files for changes and will kick you from the server
if it finds that the default files have been changed.
和所有其他的游戏一样，更改默认的游戏资源是一个坏主意，在未来，游戏客户端将会检查默认的文件是否被修改，如果它们被修改，你将会被踢出服务器（SE未来还能变成网游？）所以请记住：
1）如果你想加入什么，新建一个pak文件，或者直接放入文件夹中
2）如果你想修改什么，就从默认的pak中提取文件然后修改那血提取出来的文件。
In the future, the game client will check the default files for changes and will kick you from the server
if it finds that the default files have been changed. SpaceEngine脚本
SE独有的脚本语言可以用来描述天体，飞船，模型以及配置文件，以及针对场景的描述。脚本是那些被保存为*.sc、*cfg、*se的文件，所有的文件格式都是纯文本文档，所以你可以直接用记事本编辑（或者更好的程序：Notepad++，我们建议您使用这个软件编辑），让我们来看一看SE的一些自带catalog脚本，比如，打开土星的脚本文件，存放目录是：
（打开是这样的）
这个脚本以以一个关键字（keyword）开始：Planet，紧跟着的是一个字符串（string） “Saturn”，然后是被大括号所包围的很多行参数，Planet “Saturn”{……}这个结构叫做一个标签（tag），它在SE脚本中是很重要的，标签将脚本分成了一个个的逻辑单元，一个标签里还可以包含其他标签。
标签可以被命名，比如那个Planet标签，也可以不命名，比如Surface，一个标签可以有多个名字，用 / 符号分隔开，例如：Star “ALF Cen/Toliman/Rigel Kentaurus/Gliese 559”
这些名字便将会在SE中指向同一个内容，他们还可以被用来在SE中进行查找对象，或者被其他的脚本引用（例：你必须在planet脚本参数——ParentBody里指明一个星体的名字，你可以使用上例中的任何一个名字）。
使用希腊字母：
如果需要在对象的名字里使用希腊字母，那你必须要用“缩写”（abbreviations）代替，如：ALF, BET，诸如此类，下面是所有的缩写：
一个参数（parameter）具体是由一行参数名（keyword）（在左）和值（在右）组成的，名字和值必须要用空格或者用tab键分开，一行只允许有一个参数。参数可以像这样：（蓝色部分是参数）
在SE脚本中还可以使用注释，和C语言的格式相同：
// 这是单行注释
/* 这是内联
注释（可以有多行，只要
被包围在头尾这些符号里就
好了 */
SE独有的脚本语言可以用来描述天体，飞船，模型以及配置文件，以及针对场景的描述。脚本是那些被保存为*.sc、*cfg、*se的文件，所有的文件格式都是纯文本文档，所以你可以直接用记事本编辑（或者更好的程序：Notepad++，我们建议您使用这个软件编辑），让我们来看一看SE的一些自带catalog脚本，比如，打开土星的脚本文件，存放目录是：
（打开是这样的）
这个脚本以以一个关键字（keyword）开始：Planet，紧跟着的是一个字符串（string） “Saturn”，然后是被大括号所包围的很多行参数，Planet “Saturn”{……}这个结构叫做一个标签（tag），它在SE脚本中是很重要的，标签将脚本分成了一个个的逻辑单元，一个标签里还可以包含其他标签。
标签可以被命名，比如那个Planet标签，也可以不命名，比如Surface，一个标签可以有多个名字，用 / 符号分隔开，例如：Star “ALF Cen/Toliman/Rigel Kentaurus/Gliese 559”
这些名字便将会在SE中指向同一个内容，他们还可以被用来在SE中进行查找对象，或者被其他的脚本引用（例：你必须在planet脚本参数——ParentBody里指明一个星体的名字，你可以使用上例中的任何一个名字）。
使用希腊字母：
如果需要在对象的名字里使用希腊字母，那你必须要用“缩写”（abbreviations）代替，如：ALF, BET，诸如此类，下面是所有的缩写：
一个参数（parameter）具体是由一行参数名（keyword）（在左）和值（在右）组成的，名字和值必须要用空格或者用tab键分开，一行只允许有一个参数。参数可以像这样：（蓝色部分是参数）
在SE脚本中还可以使用注释，和C语言的格式相同：
// 这是单行注释
/* 这是内联
注释（可以有多行，只要
被包围在头尾这些符号里就
好了 */
天体对象的目录（CATALOGS OF ASTRONOMICAL OBJECTS）
SE处理所有包含在脚本文件里的目录信息
（SpaceEngine handles information about all catalog objects in scriptfiles）
（文件扩展名是＊ｓｃ或者在＊csv中，存放于目录*/catalogs/里，这两种文件都是纯文本文件，因此你也可以编辑他们，csv文件可以使用专门编辑ｃｓｖ文件的软件编辑（像Microsoft Excel，不过会有一些副作用）
针对不同的对象＊/catalogs/ 下还有子目录：galaxies/, clusters/, nebulae/, stars/ and planets/
大多数数据（在SE的默认安装情况下）都被存放在csv文件中
主星系目录存放在
他们是依巴谷星表（Hipparcos），大约包含有110，000颗恒星，NGC/IC星系目录大约包含了10，000个星系，其他对象，包括星系和恒星和附加的数据、双星系统、黑洞、星团和星云、太阳系对象、系外行星及其主星都被存放在同一个系统文件里的多个sc文件中，这些默认的文件不应该被更改，如果你想进行更新或修改他们，或是创建自定义的sc、csv文件，都应该将新的或是修改的文件放入addon文件夹中的对应的标准目录下或者打包为pak文件（例如：addons/catalogs/stars/是存放新的恒星的目录，诸如此类）。
SE有着用来从默认catalog中修改、删除、添加对象脚本选项，当你完成对catalogs的修改时，你可以把他们打包成pak文件然后分享到社区。
SE处理所有包含在脚本文件里的目录信息
（SpaceEngine handles information about all catalog objects in scriptfiles）
（文件扩展名是＊ｓｃ或者在＊csv中，存放于目录*/catalogs/里，这两种文件都是纯文本文件，因此你也可以编辑他们，csv文件可以使用专门编辑ｃｓｖ文件的软件编辑（像Microsoft Excel，不过会有一些副作用）
针对不同的对象＊/catalogs/ 下还有子目录：galaxies/, clusters/, nebulae/, stars/ and planets/
大多数数据（在SE的默认安装情况下）都被存放在csv文件中
主星系目录存放在
他们是依巴谷星表（Hipparcos），大约包含有110，000颗恒星，NGC/IC星系目录大约包含了10，000个星系，其他对象，包括星系和恒星和附加的数据、双星系统、黑洞、星团和星云、太阳系对象、系外行星及其主星都被存放在同一个系统文件里的多个sc文件中，这些默认的文件不应该被更改，如果你想进行更新或修改他们，或是创建自定义的sc、csv文件，都应该将新的或是修改的文件放入addon文件夹中的对应的标准目录下或者打包为pak文件（例如：addons/catalogs/stars/是存放新的恒星的目录，诸如此类）。
SE有着用来从默认catalog中修改、删除、添加对象脚本选项，当你完成对catalogs的修改时，你可以把他们打包成pak文件然后分享到社区。
添加，更新，移除目录（catalog）中的对象
如果你使用．ｓｃ脚本绘制一个新的对象，那它将会被添加到游戏中。“新对象”指的是在你添加到SE以前都没有的对象，更准确地说，一个新对象（比如一颗恒星）及其名字在之前的SE中都不存在，但如果这个新对象的类型和名字已经存在于之前的SE中，那么新的数据就会覆盖游戏中原本的数据，或者和原来的数据相混合，是否更新／混合游戏之前的数据，遵循之前的日期优先级。如果游戏之前具有的脚本中没有一些具体数据（比如行星质量（planet mass）），但是新的脚本中却有这一项的话，那么这项新的数据就会被游戏使用。
行星对象大类（Planetary objects）(planets, moons, asteroids, comets, and stars in multiple-star systems)以更复杂的方式被游戏识别，SE允许有多个同名的行星对象，但它们应该有着不同的母星（parent bodies）（具体指定这项的参数名叫做：ParentBody）。例如，太阳系中有两个相同名字的月亮叫“Pandora”——一个是土星的月亮，而另外个是小行星，它们有着不同的母星，一个是土星，一个是太阳，所以它们在SE中算是两个不同的对象。
当SE在寻找合适的对象的时候，它会扫描脚本中提供的所有的同级名称，比如，你可能更新了这颗恒星Star “ALF Cen/Toliman/Rigel Kentaurus/Gliese 559”的名称，因为你提供的脚本中的内容是：Star “Toliman/Bungula”，SE发现相同名称：Toliman时，便会检测到二者指的都是同一个恒星，然后更新原先的名字，变成这样：“ALF Cen/Toliman/Bungula/Rigel Kentaurus/Gliese 559”。对于一个行星对象来说，你必须指明它的母星，SE仅会在你提供了行星且已指定其母星的情况下将你提供的数据加入游戏中（名字可以随便起）。
你可以禁用游戏之前提供的一些数据，例如，NoClouds true参数将会禁用在之前脚本里的Clouds { }，但如果之前的脚本里有NoClouds true，新的脚本里有Clouds { }，那么这个新Clouds { }依然会生效。
你还可以使用新的标签改变之前的对象类型，例如，如果旧的脚本里有一个行星“KEK”，它被定义为Planet “Kek”，然后你新建了一个脚本并且把它定义成Moon “Kek”，那它的类型就会被改成Moon。当然，改变对象类型只能在它们属于同一大类的前提下进行修改，也就是说，你不可以这样修改：Galaxy “Saturn”，把星系“土星”加入到这个行星对象的大类中，这样的脚本参数会被SE忽略，应为星系不属于行星对象这个大类。以下是其他的对象大类：
如果你使用．ｓｃ脚本绘制一个新的对象，那它将会被添加到游戏中。“新对象”指的是在你添加到SE以前都没有的对象，更准确地说，一个新对象（比如一颗恒星）及其名字在之前的SE中都不存在，但如果这个新对象的类型和名字已经存在于之前的SE中，那么新的数据就会覆盖游戏中原本的数据，或者和原来的数据相混合，是否更新／混合游戏之前的数据，遵循之前的日期优先级。如果游戏之前具有的脚本中没有一些具体数据（比如行星质量（planet mass）），但是新的脚本中却有这一项的话，那么这项新的数据就会被游戏使用。
行星对象大类（Planetary objects）(planets, moons, asteroids, comets, and stars in multiple-star systems)以更复杂的方式被游戏识别，SE允许有多个同名的行星对象，但它们应该有着不同的母星（parent bodies）（具体指定这项的参数名叫做：ParentBody）。例如，太阳系中有两个相同名字的月亮叫“Pandora”——一个是土星的月亮，而另外个是小行星，它们有着不同的母星，一个是土星，一个是太阳，所以它们在SE中算是两个不同的对象。
当SE在寻找合适的对象的时候，它会扫描脚本中提供的所有的同级名称，比如，你可能更新了这颗恒星Star “ALF Cen/Toliman/Rigel Kentaurus/Gliese 559”的名称，因为你提供的脚本中的内容是：Star “Toliman/Bungula”，SE发现相同名称：Toliman时，便会检测到二者指的都是同一个恒星，然后更新原先的名字，变成这样：“ALF Cen/Toliman/Bungula/Rigel Kentaurus/Gliese 559”。对于一个行星对象来说，你必须指明它的母星，SE仅会在你提供了行星且已指定其母星的情况下将你提供的数据加入游戏中（名字可以随便起）。
你可以禁用游戏之前提供的一些数据，例如，NoClouds true参数将会禁用在之前脚本里的Clouds { }，但如果之前的脚本里有NoClouds true，新的脚本里有Clouds { }，那么这个新Clouds { }依然会生效。
你还可以使用新的标签改变之前的对象类型，例如，如果旧的脚本里有一个行星“KEK”，它被定义为Planet “Kek”，然后你新建了一个脚本并且把它定义成Moon “Kek”，那它的类型就会被改成Moon。当然，改变对象类型只能在它们属于同一大类的前提下进行修改，也就是说，你不可以这样修改：Galaxy “Saturn”，把星系“土星”加入到这个行星对象的大类中，这样的脚本参数会被SE忽略，应为星系不属于行星对象这个大类。以下是其他的对象大类：
你也可以禁用／移除原先脚本中的对象，使用Remove ＋ 对象名，例如Remove “Toliman”，但要注意，这一参数应该写在标签的外部，不能被标签包含，要移除的对象名可以是之前脚本中所指的对象的任意一个名字，在恒星目录下，支持的remove命令是
RemoveStar（为了向下兼容），但在行星目录下移除一个行星要使用Remove “Saturn” { ParentBody “Sol” }，这是因为SE使用两个参数：一个行星类对象的名称和它的母星来识别行星类对象。
移除老旧的对象在更新默认的SE目录中很有用，例如，默认的恒星目录中仍然有许多由两个孤立的恒星描述的双星，只能使用Remove参数删除它们，然后新建一个质心描述同一双星系统，然后继续建立和这两个恒星对应的新的行星目录，详情请查看“创建一颗恒星”。
注：无论目录文件的修改日期是怎样的，remove参数都会作用于所有目录文件。因此，如果你使用它一次，那么你就无法再创建具有相同名称的同一类型的对象。这是版本0.9.8.0中的bug。
RemoveStar（为了向下兼容），但在行星目录下移除一个行星要使用Remove “Saturn” { ParentBody “Sol” }，这是因为SE使用两个参数：一个行星类对象的名称和它的母星来识别行星类对象。
移除老旧的对象在更新默认的SE目录中很有用，例如，默认的恒星目录中仍然有许多由两个孤立的恒星描述的双星，只能使用Remove参数删除它们，然后新建一个质心描述同一双星系统，然后继续建立和这两个恒星对应的新的行星目录，详情请查看“创建一颗恒星”。
注：无论目录文件的修改日期是怎样的，remove参数都会作用于所有目录文件。因此，如果你使用它一次，那么你就无法再创建具有相同名称的同一类型的对象。这是版本0.9.8.0中的bug。
检查目录（catalogs）中的错误
在加载目录文件时，SE可以把错误和警告信息输出到Log文件中：system/se.log，这对于找出潜在的错误很有用。现在有两种日之记录类型：全局的日志记录或仅针对单个目录文件记录日志。全局日志记录在config/main-user.cfg中进行配置，具体来说，是Log标签下的CatalogLogLevel（针对.sc目录文件）和CsvLogLevel（针对.csv文件）参数，可用的值有：
0 – 不做任何日志记录
1 – 记录错误和警告内容，但如果在在main-user.cfg或.sc文件中使用了更低的日志级别参数则使用较低的那个
2 – 记录所有事件，但如果在在main-user.cfg或.sc文件中使用了更低的日志级别参数则使用较低的那个
3 – 记录错误和警告内容，忽略所有sc文件中的日志级别参数
4 – 记录所有事件，忽略所有sc文件中的日志级别参数
最后两个参数是用来覆盖sc文件中所有的日志级别设置的（但在CsvLogLevel参数中不可用），它们提供了全局的目录文件错误搜索。
每一个sc文件都可以有自己的日志记录级别，只要在其中加入LogLevel参数即可（不可包含在任何标签中），参数可用的值有：
0 – 关闭日志
1 – 仅记录错误和警告
2 – 记录所有事件
当你在操作目录文件时，我们推荐你在sc文件中使用参数：LogLevel2，在main-user.cfg中使用CatalogLogLevel2参数，这样你就可以获得所有关于star solver运行的信息了（详情请看：创造一颗恒星）。如果你觉得你只要查看潜在的错误，使用LogLevel 1就好了，如果在你即将发行目录文件版本中依然存在错误或警告（但实际上对游戏几乎没有影响）（例如：没有为恒星提供RA/Dec数据，star solver会按需生成那些数据），这个时候我们推荐你使用LogLevel 0，这样其他用户就不会有这样的日志。
在加载目录文件时，SE可以把错误和警告信息输出到Log文件中：system/se.log，这对于找出潜在的错误很有用。现在有两种日之记录类型：全局的日志记录或仅针对单个目录文件记录日志。全局日志记录在config/main-user.cfg中进行配置，具体来说，是Log标签下的CatalogLogLevel（针对.sc目录文件）和CsvLogLevel（针对.csv文件）参数，可用的值有：
0 – 不做任何日志记录
1 – 记录错误和警告内容，但如果在在main-user.cfg或.sc文件中使用了更低的日志级别参数则使用较低的那个
2 – 记录所有事件，但如果在在main-user.cfg或.sc文件中使用了更低的日志级别参数则使用较低的那个
3 – 记录错误和警告内容，忽略所有sc文件中的日志级别参数
4 – 记录所有事件，忽略所有sc文件中的日志级别参数
最后两个参数是用来覆盖sc文件中所有的日志级别设置的（但在CsvLogLevel参数中不可用），它们提供了全局的目录文件错误搜索。
每一个sc文件都可以有自己的日志记录级别，只要在其中加入LogLevel参数即可（不可包含在任何标签中），参数可用的值有：
0 – 关闭日志
1 – 仅记录错误和警告
2 – 记录所有事件
当你在操作目录文件时，我们推荐你在sc文件中使用参数：LogLevel2，在main-user.cfg中使用CatalogLogLevel2参数，这样你就可以获得所有关于star solver运行的信息了（详情请看：创造一颗恒星）。如果你觉得你只要查看潜在的错误，使用LogLevel 1就好了，如果在你即将发行目录文件版本中依然存在错误或警告（但实际上对游戏几乎没有影响）（例如：没有为恒星提供RA/Dec数据，star solver会按需生成那些数据），这个时候我们推荐你使用LogLevel 0，这样其他用户就不会有这样的日志。
