{"id":624,"date":"2016-10-30T20:16:56","date_gmt":"2016-10-30T20:16:56","guid":{"rendered":"http:\/\/spaceengine.org\/?page_id=624"},"modified":"2018-11-22T21:11:31","modified_gmt":"2018-11-22T21:11:31","slug":"introduction","status":"publish","type":"page","link":"https:\/\/spaceengine.org\/manual\/making-addons\/introduction\/","title":{"rendered":"Introduction"},"content":{"rendered":"

[vc_row row_type=\"row\" use_row_as_full_screen_section=\"no\" type=\"full_width\" text_align=\"left\" box_shadow_on_row=\"no\"][vc_column][no_accordion active_tab=\"1\" background_transparency=\"no\" style=\"boxed_accordion\"][no_accordion_section title=\"Introduction\" accordion_type=\"accordion_icon\" icon_pack=\"font_elegant\" fe_icon=\"icon_cog\"][vc_column_text]<\/p>\n

SpaceEngine folders<\/h4>\n

SpaceEngine has two major folders with data files, which can be found in its root (installation) directory: data<\/span> and addons<\/span>. They are equivalent in many respects. The first contains the standard SpaceEngine files, which you should not modify. The second mirrors the internal structure of the first one, and is used for user mods and addons. It has a higher priority when searching for files at startup. This means that if you have some file in the addons<\/span> folder with the same path and name as a file in the data<\/span> folder, SpaceEngine will load the file from addons<\/span>. This is useful for creating mods which change some of the system files (such as shaders), without actually touching the system files.<\/p>\n

Internally, the data<\/span> folder has these standard<\/i> subfolders inside: catalogs, locale, models, music, scripts, shaders, sounds, textures<\/span>. 'Standard' means that SpaceEngine expects to find specific data files in these subfolders, for example, music files must be in data\/music\/<\/span>, and star catalogs must be in data\/catalogs\/stars\/<\/span> (some of these subfolders have their own next-level standard subfolders inside).<\/p>\n

The addons<\/span> folder may also contain these standard subfolders, which would work as mirrors of the subfolders in data<\/span>. This means that SpaceEngine will load data files from both data<\/span> and addons<\/span> as if they were a single large folder (but with higher priority for addons<\/span> in case of a file name conflict, as has been described above).<\/p>\n

The addons<\/span> folder also allows the use of additional internal subfolders, for better organization of addons. These additional subfolders may have any name (which obviously cannot match the name of the standard subfolder), typically representing the name of an addon or a franchise, for example addons\/StarWars\/<\/span>. Internally, the additional subfolder may contain standard subfolders with data files: catalogs, models, textures<\/span> and so on, or it may contain pak files (see below), or it may contain a next-level additional subfolder, for example addons\/StarWars\/EmpireShips\/<\/span>. SpaceEngine allows for an unlimited amount of nested subfolders (limited by OS, typically the path length must not exceed 256 characters).<\/p>\n

The pak files<\/h4>\n

pak files are zip archives provided for better organization and distribution of game content. For example, a large addon with thousands of files may be zipped into a single pak file and distributed in this form, which is more convenient for the user. Zip compression can also be used while creating the pak file, which is useful to save disk space and download traffic.<\/p>\n

pak files are zip archives that include files and folders with the same structure as they have on the disk, starting from the data<\/span> or addon<\/span> root level (or addon\/YourCustomFolder\/<\/span>). This means that the uppermost folder which can be zipped into a pak file is one of the standard subfolders: catalogs, models, textures<\/span> and so on. SpaceEngine reads the content of all pak files at startup and uses them as a virtual file system with date priority. This leads to many consequences:<\/p>\n

1) The pak file format<\/h5>\n

pak files are zip archives (i.e. .zip files with the extension renamed to .pak). You may associate the .pak file type with WinRar or 7zip or whatever program you use to work with archives, and open any .pak file and extract files from it. Creating a .pak file is easy too: just select needed files and folders and compress them as .zip, then rename it to .pak when finished.<\/p>\n

2) Virtual path<\/h5>\n

You may think of a pak file as a container for files\/folders. The internal folder structure inside a pak file is a continuation of the SE folder structure. This means that SE looks for files and folders on the disk and inside all pak files as if there were no pak files and all their content is extracted at the place where these pak files are. We will call this a virtual path<\/i>. The path of the disk in this article will be colored green<\/span>, and inside the pak file will be colored orange<\/span>. For example, these three virtual paths<\/i> are equal (remember that the StarWars<\/span> folder is optional):
\naddons\/StarWars\/<\/span>StarWarsPlanets.pak\/catalogs\/planets\/Coruscant.sc<\/span> (packed into pak file)
\naddons\/StarWars\/catalogs\/planets\/Coruscant.sc<\/span> (unpacked on the disk)
\naddons\/catalogs\/planets\/Coruscant.sc<\/span> (unpacked addon content moved to the addons root - still works)<\/p>\n

3) Priority by modification date<\/h5>\n

If there are two or more files with the same virtual path<\/i>, SE will load the most recent one. It compares the modification date\/time of the disk files, or those of the entire pak file. For example, consider that you have 3 files named SolarSys.sc<\/span> in different places, but with the same virtual path<\/i>:
\ndata\/catalogs\/<\/span>Catalogs0980.pak\/planets\/SolarSys.sc<\/span> in the default pak file, pak date is 2016\/08\/06
\ndata\/catalogs\/planets\/SolarSys.sc<\/span> unpacked on the disk, file date is 2016\/09\/01
\ndata\/catalogs\/<\/span>SolarSysUpdate001.pak\/planets\/SolarSys.sc<\/span> in another pak, pak date is 2016\/09\/05
\nIn this case, SpaceEngine will load the last one, because it has the most recent date. This is useful for making updates. Consider someone adding an addon with this file:
\naddons\/<\/span>SolarSystemMod.pak\/catalogs\/planets\/SolarSys.sc<\/span> pak date is 2016\/08\/15
\nIn this case, SpaceEngine will load the file from this addon pak, despite its older date. This is because files in the addons<\/span> folder have priority over files in the data<\/span> folder. This is to prevent breaking addons after updating the default SE files. Inside the addons<\/span> folder, the same file\/pak modification date priority rules apply.<\/p>\n

4) Extracting files<\/h5>\n

You may extract any file from the pak archives by opening it as a zip archive. When extracting the file, you must create all the folders contained inside the pak, so the extracted file will have the same virtual path<\/i> as the packed one (use the 'extract here' option in your archiver program). For example, if you want to extract the file SolarSys.sc<\/span> from the Catalogs0980.pak<\/span>, you must create the folder data\/catalogs\/planets\/<\/span> and extract that file into it so that it has this path:
\ndata\/catalogs\/planets\/SolarSys.sc<\/span>
\nAfter this, SpaceEngine will load the extracted file, because it will have the more recent date. Now you may modify it.<\/p>\n

5) Creating pak files<\/h5>\n

For example, consider you are making a planetary system addon which has these files:
\naddons\/StarWars\/catalogs\/stars\/StarWarsSystems.sc
\naddons\/StarWars\/catalogs\/planets\/Coruscant.sc
\naddons\/StarWars\/catalogs\/planets\/Tatooine.sc<\/span>
\nWhen you finish creating it, testing everything, and are ready to release, go to the StarWars<\/span> folder, select the catalogs<\/span> folder and pack it into a zip archive. Rename that archive to StarWarsPlanets-v001.pak<\/span>. The file name doesn't really matter, but it should reflect the file's content, and having a version\/revision number in it is also a good idea. After that, delete the catalogs\/<\/span> folder and its content (or move it to some backup place) and leave only the newly created pak file. If you did the packing correctly, your addon should work in SE as before. Your data files will have this virtual path:
\naddons\/StarWars\/<\/span>StarWarsPlanets.pak\/catalogs\/stars\/StarWarsSystems.sc<\/span>
\naddons\/StarWars\/<\/span>StarWarsPlanets.pak\/catalogs\/planets\/Coruscant.sc<\/span>
\naddons\/StarWars\/<\/span>StarWarsPlanets.pak\/catalogs\/planets\/Tatooine.sc<\/span>
\nSo you are ready to share the file StarWarsPlanets-v001.pak<\/span> with the community. Note that it will work if it is placed in any subfolder in the addons<\/span> folder (except standard subfolders of course):
\naddons\/StarWarsPlanets-v001.pak<\/span>
\naddons\/StarWars\/StarWarsPlanets-v001.pak<\/span>
\naddons\/blabla\/ololo\/123\/StarWarsPlanets-v001.pak<\/span>
\nYou are free to put any set of data files in a single pak file. For example, you may create a full Star Wars franchise pak, which includes all planetary systems, galaxy and galaxy model, and all ship models. Note that there are some restrictions.<\/p>\n

6) Restrictions<\/h5>\n

1) The SpaceEngine root folder cannot be used as a place for pak files. The following will not<\/span> work:
\nSpaceEngine\/<\/span>StarWars.pak\/data\/catalogs\/planets\/Coruscant.sc<\/span>
\n2) The pak file cannot contain additional subfolders, only default ones are allowed. The following will not<\/span> work:
\nSpaceEngine\/addons\/<\/span>StarWars.pak\/StarWars\/StarWarsPlanets\/catalogs\/planets\/Coruscant.sc<\/span>
\n3) The pak file should be less than 4GB in size. If your addon is bigger than that, split it into several smaller pak files.
\n4) Music and sound files in ogg format cannot be zipped into pak files.<\/p>\n

7) Compression rate<\/h5>\n

Zip archives can be created with or without compression. SpaceEngine supports only the \"Deflate\" compression method. Some file types have a great compression rate (text files such as scripts and catalogs), some have a medium compression rate (binary files such as ship models .sm, .dds and uncompressed .tga images), some almost cannot be compressed (.jpg, .png, .tif images). It is a good idea to save a large set of image files (such as a planet textures addon) into an archive without<\/i> compression, because it has great extracting\/loading performance. Higher performance is always better than saving few megabytes of disk space. You could experiment to find better options for your addon. For example, you may save textures into a pak without compression, and scripts with models into another pak file with compression.<\/p>\n

8) Never touch the default pak files<\/h5>\n

Just like in all other games, changing the default game resources is a bad idea. 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. So remember these simple rules:
\n1) If you want to add something, create your own pak file (or simply store files in the folders, non-packed).
\n2) If you want to modify something, extract the file from the default pak and modify the extracted file.<\/p>\n

SpaceEngine scripts<\/h4>\n

SpaceEngine has a special scripting language<\/i> to describe astronomical objects, ships, models and configuration files, and for scenarios. Scripts are stored in files with the extensions *.sc, *.sss, *.cfg, *.se<\/span>. All file formats are plain text documents, so you can edit them with notepad (or the better program Notepad++, which we recommend you download and install). Lets take a look at some of SpaceEngine's default catalog scripts. For example, look at the description of Saturn, located in the file data\/catalogs\/<\/span>Catalogs0980.pak\/planets\/SolarSys.sc<\/span>:<\/p>\n

\n
Code<\/div>\n
Planet\u00a0\u00a0\u00a0\"Saturn\"
\n{<\/p>\n
\nParentBody\u00a0\u00a0\u00a0\u00a0\u00a0\"Sol\"
\nClass\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\"GasGiant\"
\nMass\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a095.162
\nRadius\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a060268
\nOblateness\u00a0\u00a0\u00a0\u00a0\u00a0\u00a00.09796
\nRotationPeriod\u00a0\u00a010.65622
\nRotationOffset\u00a0\u00a0358.922
\nObliquity\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a028.049
\nEqAscendNode\u00a0\u00a0\u00a0\u00a0169.53
\nColor\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0( 1.000 1.000 0.850 )
\nAlbedo\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a00.342
\nAlbedoBond\u00a0\u00a0\u00a0\u00a0\u00a0\u00a00.342
\nAlbedoGeom\u00a0\u00a0\u00a0\u00a0\u00a0\u00a00.47
\nBrightness\u00a0\u00a0\u00a0\u00a0\u00a0\u00a01.8Surface
\n{<\/p>\n
\n\/\/ Surface map author: Bjorn Jonsson
\nDiffMap\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\"Saturn\/Surface-BJ\"
\nDiffTileSize\u00a0\u00a0\u00a0\u00a0256
\nDiffTileBorder\u00a0\u00a00
\nDayAmbient\u00a0\u00a0\u00a0\u00a0\u00a0\u00a00
\nNoClouds\u00a0\u00a0\u00a0\u00a0\u00a0true\n<\/div>\n

}
\nAtmosphere
\n{<\/p>\n

\nHeight\u00a0\u00a0\u00a0250\u00a0\u00a0\/\/ km
\nModel\u00a0\u00a0\u00a0\"Earth\"
\nBright\u00a0\u00a0\u00a05.0
\nOpacity\u00a0\u00a00.2
\nSkyLight 0.002<\/p>\n

Composition \/\/ values in percent
\n{<\/p>\n

\nH2\u00a0\u00a0\u00a096.3
\nHe\u00a0\u00a0\u00a03.25
\nCH4\u00a0\u00a00.45
\nNH3\u00a0\u00a00.0125
\nC2H6\u00a00.0007\n<\/div>\n

}\n<\/p><\/div>\n

}<\/p>\n

Aurora
\n{<\/p>\n

\nHeight\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a01000\u00a0\u00a0\u00a0\/\/ km
\nTopColor\u00a0\u00a0\u00a0\u00a0(1.5 0.0 0.8)
\nBottomColor (1.0 0.1 0.0)
\nNorthLat\u00a0\u00a0\u00a0\u00a0\u00a090\u00a0\u00a0\u00a0\u00a0\/\/ degrees
\nNorthLon\u00a0\u00a0\u00a0\u00a0\u00a00\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ degrees
\nNorthRadius\u00a0\u00a015000 \/\/ km
\nNorthWidth\u00a0\u00a0\u00a05000\u00a0\u00a0\/\/ km
\nNorthRings\u00a0\u00a0\u00a03\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ number of rings
\nNorthBright\u00a0\u00a01.0
\nSouthLat\u00a0\u00a0\u00a0\u00a0-90\u00a0\u00a0\u00a0\u00a0\/\/ degrees
\nSouthLon\u00a0\u00a0\u00a0\u00a0\u00a00\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ degrees
\nSouthRadius\u00a0\u00a016000 \/\/ km
\nSouthWidth\u00a0\u00a0\u00a05000\u00a0\u00a0\/\/ km
\nSouthRings\u00a0\u00a0\u00a03\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ number of rings
\nSouthBright\u00a0\u00a01.0\n<\/div>\n

}<\/p>\n

Rings
\n{<\/p>\n

\n\/\/ Rings texture author: Vladimir Romanyuk \"SpaceEngineer\"
\nTexture\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\"Saturn-rings.*\"
\nInnerRadius\u00a0\u00a0\u00a0\u00a0\u00a060284
\nOuterRadius\u00a0\u00a0\u00a0\u00a0\u00a0356993
\nFrontBright\u00a0\u00a0\u00a0\u00a0\u00a01.0
\nBackBright\u00a0\u00a0\u00a0\u00a0\u00a0\u00a05.0
\nBrightness\u00a0\u00a0\u00a0\u00a0\u00a0\u00a01.5\n<\/div>\n

}<\/p>\n

Orbit
\n{<\/p>\n

\nRefPlane\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\"Ecliptic\"
\nPeriod\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a029.4577
\nSemiMajorAxis\u00a0\u00a0\u00a09.5371
\nEccentricity\u00a0\u00a0\u00a0\u00a00.0542
\nInclination\u00a0\u00a0\u00a0\u00a0\u00a02.4845
\nAscendingNode\u00a0\u00a0\u00a0113.715
\nLongOfPericen\u00a0\u00a0\u00a092.432
\nMeanLongitude\u00a0\u00a0\u00a049.944\n<\/div>\n

}\n<\/p><\/div>\n

}\n<\/p><\/div>\n<\/div>\n

The script starts with the keyword<\/i> Planet<\/span>, followed by the string<\/i> \"Saturn\"<\/span>. After that, there are many lines with some parameters<\/i> enclosed in a curly braces. The construction Planet \"Saturn\" { ... }<\/span> is called a tag<\/i> and plays an important role in SE scripts. Tags divide the script into logical sections, and they can themselves include other tags (for example, Surface { ... }<\/span>).<\/p>\n

Tags can be named, like the Planet<\/span> tag, or unnamed, like Surface<\/span>. A named tag can have multiple, or alternate<\/i>, names, separated by a slash '\/'. For example: Star \"ALF Cen\/Toliman\/Rigel Kentaurus\/Gliese 559\"<\/span>. All of these names identify the same object in SpaceEngine, and they can each be used to search for the object in-game, or to refer to it from another script (for example, you must specify a star name in the parameter ParentBody<\/span> in the planet script - you can use one of the multiple names of the star there).<\/p>\n

Greek letters<\/a>, if used, must be entered in the object's name using abbreviations: ALF, BET, etc. This is the full list of abbreviations:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
ALF<\/span><\/td>\n\u03b1<\/td>\n(alpha)<\/td>\n<\/tr>\n
BET<\/span><\/td>\n\u03b2<\/td>\n(beta)<\/td>\n<\/tr>\n
GAM<\/span><\/td>\n\u03b3<\/td>\n(gamma)<\/td>\n<\/tr>\n
DEL<\/span><\/td>\n\u03b4<\/td>\n(delta)<\/td>\n<\/tr>\n
EPS<\/span><\/td>\n\u03b5<\/td>\n(epsilon)<\/td>\n<\/tr>\n
ZET<\/span><\/td>\n\u03b6<\/td>\n(zeta)<\/td>\n<\/tr>\n
ETA<\/span><\/td>\n\u03b7<\/td>\n(eta)<\/td>\n<\/tr>\n
TET<\/span><\/td>\n\u03b8<\/td>\n(theta)<\/td>\n<\/tr>\n
IOT<\/span><\/td>\n\u03b9<\/td>\n(iota)<\/td>\n<\/tr>\n
KAP<\/span><\/td>\n\u03ba<\/td>\n(kappa)<\/td>\n<\/tr>\n
LAM<\/span><\/td>\n\u03bb<\/td>\n(lambda)<\/td>\n<\/tr>\n
MU<\/span><\/td>\n\u03bc<\/td>\n(mu)<\/td>\n<\/tr>\n
NU<\/span><\/td>\n\u03bd<\/td>\n(nu)<\/td>\n<\/tr>\n
KSI<\/span><\/td>\n\u03be<\/td>\n(xi)<\/td>\n<\/tr>\n
OMI<\/span><\/td>\n\u03bf<\/td>\n(omicron)<\/td>\n<\/tr>\n
PI<\/span><\/td>\n\u03c0<\/td>\n(pi)<\/td>\n<\/tr>\n
RHO<\/span><\/td>\n\u03c1<\/td>\n(rho)<\/td>\n<\/tr>\n
SIG<\/span><\/td>\n\u03c3<\/td>\n(sigma)<\/td>\n<\/tr>\n
TAU<\/span><\/td>\n\u03c4<\/td>\n(tau)<\/td>\n<\/tr>\n
UPS<\/span><\/td>\n\u03c5<\/td>\n(upsilon)<\/td>\n<\/tr>\n
PHI<\/span><\/td>\n\u03c6<\/td>\n(phi)<\/td>\n<\/tr>\n
CHI<\/span><\/td>\n\u03c7<\/td>\n(chi)<\/td>\n<\/tr>\n
PSI<\/span><\/td>\n\u03c8<\/td>\n(psi)<\/td>\n<\/tr>\n
OME<\/span><\/td>\n\u03c9<\/td>\n(omega)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

A parameter is a line with the parameter name<\/i> (keyword) on the left side and the parameter value<\/i> on the right side. The name and value must be separated with spaces or tabs. Only one parameter per line is allowed. Parameters can be one of the following types<\/i>:<\/p>\n

string (text): Class \"GasGiant\"<\/span>
\nnumber: Mass 95.162<\/span>
\nvector: Color ( 1.000 1.000 0.850 )<\/span> or Color ( 1.000, 1.000, 0.850 )<\/span>
\nnumber in 'deg min sec' or 'hrs min sec' format: Dec 18 32 16.23<\/span>
\nboolean (binary): NoClouds true<\/span> or NoClouds 1<\/span><\/p>\n

Comments are allowed in SE scripts, which are in the C\/C++ format:
\n\/\/ this is a single-line comment<\/span>
\n\/* this is an inline comment *\/<\/span>
\nThe first is the single-line comment. All text after the \/\/<\/span> symbols until the end of line is considered a comment and ignored by SE. The second is an inline or multi-line comment. All text between \/*<\/span> and *\/<\/span> is considered a comment and ignored by SE. New lines are allowed in this type of comment:
\n\/* this is a
\nmulti-line
\ncomment *\/<\/span><\/p>\n

Catalogs of astronomical objects<\/h4>\n

SpaceEngine handles information about all catalog objects in script files<\/i> (with the extension *.sc) or in CSV files (*.csv), located in the virtual directory *\/catalogs\/<\/span>. Both file formats are plain text documents, so you can edit them with notepad. The csv files can be edited using specialized software for editing csv (like Microsoft Excel, with some side effects). The directory *\/catalogs\/<\/span> has subdirectories named galaxies\/<\/span>, clusters\/<\/span>, nebulae\/<\/span>, stars\/<\/span> and planets\/<\/span>, for each type of object.<\/p>\n

The majority of stars in the default SpaceEngine installation are stored in the csv file data\/catalogs\/<\/span>Catalogs0980.pak\/stars\/HIPPARCOS.csv<\/span>, and the main catalog of galaxies is in data\/catalogs\/<\/span>Catalogs0980.pak\/galaxies\/NGC-IC.csv<\/span>. They are the HIPPARCOS star catalog containing about 110,000 stars, and the NGC\/IC galaxy catalog containing about 10,000 galaxies. Other objects, including some galaxies and stars with additional data, binary star systems, black holes, star clusters and nebulae, Solar System objects, and exoplanets and their host stars, are stored in multiple sc files in the same system pak. These default files should not be modified or changed in any way. If you want to update an object, remove it, or add a new one, create your own sc or csv file in the corresponding addon folder (addons\/catalogs\/stars\/<\/span> for stars and so on). SpaceEngine has scripting options to modify and remove stars or other objects from the default catalogs, or to add new ones. After finishing work on your catalogs, you can zip the catalog files into the pak file and share it with the community.<\/p>\n

The csv format is used to create large catalogs of objects with similar data. It is more compact and a lot faster than sc, but has limitations in the types of data which can be specified in it. It is just a table with values separated by a comma. The current version of SpaceEngine (0.9.8.0) supports csv files only for stars and galaxies. The sc format is designed to specify any possible data that SE can use to describe an object. It is script-like text with 'tags' used to describe an object (galaxy, star, planet etc) and its various parameters.<\/p>\n

Adding, updating, and removing catalog objects<\/h5>\n

If you describe a new object using SpaceEngine sc scripts, it will be added to the game. \"New object\" means that it didn't exist in SE before you made a script for it. More precisely, an object of the same type (for example, a star) and the same name didn't exist in SE. If the object of that type with the same name already exists in SE, it will be updated<\/i> or merged<\/i> with the data you have provided in your script. The order of merging (which data has priority) is defined by the modification date of the sc file or the pak file in which this sc file is packed. The newer file has higher priority, so some data from the script of this object in a previous file will be replaced with the new data provided. If the previous script doesn't have some specific data (for example, planet mass), but the new one has it, the newly provided data will be used.<\/p>\n

Planetary objects (planets, moons, asteroids, comets, and stars in multiple-star systems) are identified in a more complicated way. SpaceEngine allows there to be many planetary objects with the same name, but with different parent bodies (specified in the parameter ParentBody<\/span>). For example, the Solar system has two objects with the name \"Pandora\": a moon of Saturn and an asteroid. They have different parent bodies, Saturn and Sun, so they are different objects in SE.<\/p>\n

While looking for identical objects, SpaceEngine scans all alternative names provided in the scripts. For example, you may update the old star Star \"ALF Cen\/Toliman\/Rigel Kentaurus\/Gliese 559\"<\/span> by describing a star in your script by Star \"Toliman\/Bungula\"<\/span>. SpaceEngine will detect that this is the same object when it finds the name \"Toliman\". It will update the old star with the new data provided in your script, including the star name: it will add the new provided name \"Bungula\" to the list of alternative names, so it will become \"ALF Cen\/Toliman\/Bungula\/Rigel Kentaurus\/Gliese 559\". For a planetary object, as has been noted, you have to specify the parent object. SpaceEngine will merge them only if the object's name and parent object name are identical (any alternative name of the parent object can be used).<\/p>\n

It's possible to cancel out some data in the old scripts, for example, NoClouds true<\/span> will disable Clouds { }<\/span> tags in the old scripts. But if the Clouds { }<\/span> tags are provided for the planet which had NoClouds true<\/span> in the old script, these Clouds { }<\/span> tags will be used.<\/p>\n

It's possible to change the type of an object by defining it with the other tag. For example, if older script has a planet \"Kek\" defined as Planet \"Kek\"<\/span>, and you create a new script and define it as Moon \"Kek\"<\/span>, it will change its type to moon. Changing the type is only possible within the set of types supported by the current catalog. This means that you cannot add a galaxy named \"Saturn\" to the planets catalog using the tag Galaxy \"Saturn\"<\/span>. It will be ignored by SE, because tag Galaxy<\/span> is not allowed in the planets catalog. Here is the list of object types (tags) which are allowed in the corresponding catalogs:<\/p>\n

Planet catalogs *\/catalogs\/planets\/*.sc<\/span>: Star, Planet, Moon, DwarfPlanet, DwarfMoon, Asteroid, Comet, Barycenter<\/span>
\nStar catalogs *\/catalogs\/stars\/*.sc<\/span>: Star, StarBarycenter<\/span>
\nGalaxy catalogs *\/catalogs\/galaxies\/*.sc<\/span>: Galaxy, Quasar<\/span>
\nStar cluster catalogs *\/catalogs\/clusters\/*.sc<\/span>: Cluster<\/span>
\nNebula catalogs *\/catalogs\/nebuale\/*.sc<\/span>: Nebula<\/span><\/p>\n

It's possible to remove (more precisely, disable) some object from the old catalogs. Use the parameter Remove<\/span> with the name of object you want to remove. For example, Remove \"Toliman\"<\/span>. It must be used outside any tag. Any of the object's alternate names can be used. Star catalogs also support the RemoveStar<\/span> parameter with the same effect (for backward compatibility). In the planets catalog you must use a more complex construction: Remove \"Saturn\" { ParentBody \"Sol\" }<\/span>. This is because SpaceEngine identifies a planetary object by its name and its parent's name.<\/p>\n

Removing old objects is useful when upgrading the default SE catalogs. For example, the default star catalogs still have many binary stars described by two solitary stars. One can use Remove<\/span> in the star catalog to delete them, and add a barycenter description to the same star catalog. Then make a planet catalog with two stars with proper orbits and that barycenter as their parent. See Creating a star<\/a> for details.<\/p>\n

Note:<\/span> the Remove<\/span> parameter affects all catalog files, regardless of their modification date. So if you used it once, it will no longer be possible to create an object of the same type with the same name. It is a bug in the current version (0.9.8.0).<\/p>\n

Checking for errors in catalogs<\/h5>\n

SpaceEngine can output some errors and warnings into the log file system\/se.log<\/span> while loading catalogs. This is useful for catching possible errors. There are two ways to enable logging: global and per catalog file. The global logging level is controlled by the parameters CatalogLogLevel<\/span> (for sc catalogs) and CsvLogLevel<\/span> (for csv catalogs) under the Log<\/span> tag in the config\/main-user.cfg<\/span> file. Possible values are:<\/p>\n

0 - do not log anything
\n1 - log errors and warnings, using the lesser log level between those in the main-user.cfg and in the sc file, if defined there
\n2 - log everything, using the lesser log level between those in the main-user.cfg and in the sc file, if defined there
\n3 - log errors and warnings, ignoring log level in all sc files
\n4 - log everything, ignoring log level in all sc files<\/p>\n

The last two are used to override the log level settings in all sc files (not usable in the CsvLogLevel<\/span> parameter). They are provided for global searching for catalog errors.<\/p>\n

Each sc catalog file may have its own log level settings, specified by the parameter LogLevel<\/span>, added somewhere in the global space (i.e. outside the tags Star<\/span>, StarBarycenter<\/span> etc). Possible values are:<\/p>\n

0 - do not log anything
\n1 - log errors and warnings only
\n2 - log everything<\/p>\n

It is recommended to specify LogLevel 2<\/span> in your sc files and CatalogLogLevel 2<\/span> in main-user.cfg<\/span> while you are working on catalogs so you will have all information about star solver<\/i> work in the log file (see Creating a star<\/a> for details). If you need to see only possible errors, specify LogLevel 1<\/span>. If some errors or warnings are still visible in the release version of your catalog (for example, no RA\/Dec data are provided for a star, and star solver generates them procedurally), it's recommended to specify LogLevel 0<\/span>, so other users will have their log files clean of errors related to your catalog.[\/vc_column_text][\/no_accordion_section][\/no_accordion][\/vc_column][\/vc_row]<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"

[vc_row row_type=\"row\" use_row_as_full_screen_section=\"no\" type=\"full_width\" text_align=\"left\" box_shadow_on_row=\"no\"][vc_column][no_accordion active_tab=\"1\" background_transparency=\"no\" style=\"boxed_accordion\"][no_accordion_section title=\"Introduction\" accordion_type=\"accordion_icon\" icon_pack=\"font_elegant\" fe_icon=\"icon_cog\"][vc_column_text] SpaceEngine folders SpaceEngine has two major folders with data files, which can be found in its root (installation) directory: data and addons. They are equivalent in many respects. The first contains the...<\/p>\n","protected":false},"author":1,"featured_media":0,"parent":519,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-624","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/spaceengine.org\/wp-json\/wp\/v2\/pages\/624","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/spaceengine.org\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/spaceengine.org\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/spaceengine.org\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/spaceengine.org\/wp-json\/wp\/v2\/comments?post=624"}],"version-history":[{"count":23,"href":"https:\/\/spaceengine.org\/wp-json\/wp\/v2\/pages\/624\/revisions"}],"predecessor-version":[{"id":2757,"href":"https:\/\/spaceengine.org\/wp-json\/wp\/v2\/pages\/624\/revisions\/2757"}],"up":[{"embeddable":true,"href":"https:\/\/spaceengine.org\/wp-json\/wp\/v2\/pages\/519"}],"wp:attachment":[{"href":"https:\/\/spaceengine.org\/wp-json\/wp\/v2\/media?parent=624"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}