Hello, I'm going to be re-installing Windows soon, and I would like to know how possibly I can back up my Randomly Generated content. I've gotten some pretty cool stuff and since it is random I guess I would be able to admire some of the cool things I came across such. I don't really want to copy the whole program just the folder that has all of the info in it as I only have so much space for backup!
^ No need. There is a point in backing up your bookmarks, which is simply a matter of saving a copy of, I think, places.cfg and journal.cfg (optionally). But while SE uses a pseudorandom number generator, the seed used to start it is always the same, so like any pseudorandom generator, it will always generate the exact same stuff every time, even between installations. The only way you could "lose" a procedural object is if you change the universe.cfg file or SpaceEngineer changes the seed or algorithm (which admittedly he probably will at least once between now and the final release). So as long as you save your bookmarks, there's no need to backup the actual star and planet data.
Intel HD Graphics 4000 ;P
Edited by parameciumkid - Tuesday, 30.06.2015, 19:41
A terribly old thread, I apologise to bump it, but I looked for my favourite systems from 9.7.1 in 9.7.4 RC2, and while the galaxy remained somewhat the same(100 kpc in diameter, but a SBb galaxy instead of S0 galaxy), the star systems did not. Did the compatibility change from 9.7.1 to 9.7.2? I'm rather curious .
Fluent in music, math, Solresol, and hopefully someday, astronomy.
Hanakofuroshira, on each new version there is something mildly different on the generation settings (I don't really know the details), but that causes the random systems, stars and galaxies to be different on each version, so unfortunately you have to find new ones
"Rush, Where the hell are we?" "Several billion light years from home."
I figured it was going to be like that because of all the new settings each body can have haha
Each time I boot up a new version of Space Engine, I always go to RG 0-0-0-607. I've been compiling a rather big list of systems I like so when true importing becomes a thing, I can have a galaxy that has all of my favourite systems in it. Granted, I will never complete it in my lifetime, but I think it's a great way to pass the time.
Fluent in music, math, Solresol, and hopefully someday, astronomy.
Just for clarifying, he doesn't voluntarily change the seed, the reason why the universe changes it's because a new factor of random have been added/an important feature have been modified.
Let's imagine you can start from a number, multiply it by 4.72 and take the last two digits to make a new number, because you want four pseudo-random numbers.
You start with 3.6, you get 9.2, then 2.4 and finally 2.8. Then you realize you need five of them. Easy right? You still start with 3.6, you get 9.2, then 2.4, then 2.8 and finally 1.6.
Let's imagine the last number is somehow related to planets, every planet will change because the number is no more 2.8 but 1.6. Why not using always last numbers? Well, if you're interested ask SpaceEngineer why it's so difficult.
(P.S.: Probably SpaceEngine doesn't use seeds at all, but it's random must always have the same seed)
The universe is not required to be in perfect harmony with human ambition.
Well, SE indeed have no single "master seed". For example, for planetary system, the seed is a some hash computed from stars coordinates:
Code
// Calculate a seed from rounded Universal coordinates of the star int rcx = int(ring((double)PosUniv.x * 100, 2147483647.0)); int rcy = int(ring((double)PosUniv.y * 100, 2147483647.0)); int rcz = int(ring((double)PosUniv.z * 100, 2147483647.0)); seed = rcx * 165954 + rcy * 931245 - rcz * 2296315; Randomize(seed); GaussRandomize(seed);
The older versions have seed as a hash of star ID number, thus tiny change in star generator gives completely different system. The seed based on coordinates is more stable.
Besides this seed, the appearance of the planetary system depends on the main star parameters. This must be obvious: systems of a red giant and red dwarf are very different.
The same for galaxies: they have a hash-seed based on their coordinates (so changing the ID (procedural number) of the galaxy RG XXXX-... does not change the stars inside it anymore, unlike older SE versions), but also stars in galaxy generated using some galaxy parameters (type, radius), and, the most important, galaxy subsystem texture. So moders must take it into account: changing galaxy subsystem texture (but not front texture / sprite model) changes all stars, clusters and nebulae inside it, as well as changing radius; changing galaxy coordinates changes galaxy seed, so again changes everything in it.
Adding/removing some catalog galaxy will shift other galaxies ID, so all procedural stars in them changes their names. But because star generator takes galaxy coordinates to compute hash-seed, not the name or ID, stars in it does not change. For example, in 0.972 procedural stars has numbers RS 8404-xxx, but in 0.974 they are RS 8474-xxx. After adding/removing galaxies (by installing some mod or catalog fix), it will change, but you still can restore your Milky Way locations by looking at name of some procedural star in Milky Way and fixing the galaxy ID part (first number after "RS") in the names of stars in your places-user.cfg (and places-def.cfg!). If I implement some better generation of ID for catalog galaxies (now it is just a index number in the catalog), it will preserve locations after adding/removing galaxies in the catalog. Maybe again some hash based on galaxy coordinates will work.
But the main problem remains. Changing of planets, stars or entire galaxies in the every new version cannot be avoided. Salvo very well described the nature of this thing. The only "solution" I can suggest is preserving all galaxies/stars/planets generation code from version to version, maybe as a dll. Each new SE version will have new dll, which implements new generation algorithms. Locations entry in the places-*.cfg have the version number info, so engine can load corresponding dll and generate planets using it. Also all texture generator shaders must be saved this way. Although this will not work if the galaxy texture changes. Also, supporting this system may become hell as engine code changes. Some changes may be completely incompatible with the old code, for example new terrain rendering and generation system. Thus old code (old dll) must be completely removed time to time. So I'm not sure if implementing of this system worth efforts.
The only "solution" I can suggest is preserving all galaxies/stars/planets generation code from version to version, maybe as a dll.
Yeah, but as you said would be a nightmare to add new features, I guess it's just fine what it is right now, since there is the possibility to export systems.
The universe is not required to be in perfect harmony with human ambition.
Just thinking about another way to fix galaxy number shift issue: show/find procedural star name as real galaxy name + star ID, ie star "RS 8474-1353-8-11843422-287" become "Milky Way RS 1353-8-11843422-287" or "Milky Way-1353-8-11843422-287" It doesn't look good though...
Is there a fairly easy way to import my procedural content from previous versions? I know that one can't import textures, but even importing the body information is still finicky. I already have the .cfg export file of the systems I want to import.
If it helps, I'm trying to import systems from all versions since 0.971. Is it being silly because of the new features, the fact that it's trying to overwrite an existing procedural system, or could it even be that I'm trying to import into a procedural galaxy...?
I might even be messing up something as simple as not watching my parenthesis or inserting the information into the wrong place, but I don't know for sure since I'm following any importing guides I can find.
Fluent in music, math, Solresol, and hopefully someday, astronomy.
ENG
New site
Pirate 
United States 
Italy 
Russian Federation 
