Ok. Getting there slowly but surely. I found 2 ways to "draw" the whole terrain : one is by editing the map in the savegame's cache and gives total control on geometry but not on texturing (which can be made in prevision of this method in the original yamls), and the second method is with custom "groundshapes" in the "Stamps" folder, which has correct texturing because it is included at terrain generation. Only minor problem is with the "splatmaps" in "terrain.ecf" which are made by the SSG but that are not exposed anywhere. I guess I could make a copy-template and try to find more about these. I had one specific question for you, if you know the answer (maybe @Needleship knows this ?) : how do "seeds" for game generation work ? If I choose the same seed at each start, will all randomized content be made identical each time ?
Hi @Kassonnade ! A start seed is 'global' - Meaning, that it should control all 'playfield seeds'. And by that, give the same results. (You can then force a specific playfield seed by setting it directly in the playfield.yaml. This _should_ give the same world, terrain, POI placement - - even with a different world seed. But placement of deco might change; those seem to be part of the global seed. There is even a difference of deco placement between Creative and Survival.) As far as I understand it-- ... The 'splatmap' entry in the terrain.ecf: Splatmaps (for e.g. the 'exterior space view') are being auto-generated, if you load up the world - Not when you export it with the SSG. (And they should end up in the cache folder? The terrain textures (=the terrain.ecf) just reference these; or it even could be a leftover without any meaning. IIRC, I think.... you can use even a terrain.ecf with differing names for these splats, and the terrain.ecf still works fine? - - Haven't checked those cache files, though...) SPOILER: That is part of the ingame 'Legacy' faction, and currently used. .raw stamps are still good. But .png take less memory than .raw, with minimal loss in height fidelity.
If I only have a playfield_static.yaml and playfield_dynamic.yaml but no playfield.yaml where can I put this seed number ? Unfortunately they are in .dat format, so I can't see how they're made. I saw some of the stamps have specific splat maps, but these don't cover the whole terrain... well not as they're made presently. This is my next step. I saw there are many "modifiers" for the regular stamps in .StampDatabase.txt but I did not experiment with these yet : I needed a "stable" terrain so I can see what changes what and how in the row of variables in there. I'm not even sure I understand all the variables in the .GroundShapeDatabase.txt but at least now I have a workflow (with a fixed seed) to get the whole terrain to wrap arount a class 2 moon without crossing the polar limit. Starting from there I can use a global "GroundShape" as base terrain on which I can place the "top" layer of stamps (with their various add/substract & other operations) more precisely. I did not find a way to make the .png work with GroundShapes, so I can only use a .raw and it needs to be flipped vertically to have correct orientation in the game. Sorry if I'm a bit highjacking @jmcburn 's thread with this... Here's a link to pictures : https://empyriononline.com/threads/what-did-you-do-in-empyrion-today.2826/page-1110#post-416116 .
Hi @Kassonnade ! Spoiler: To not spam this thread, the whole text is in here. - Plz Clicky - Playfield seeds are used in 'playfield.yaml's, only. = the file you get, when you export a playfield_dynamic and playfield_static with the SSG. (The playfield.yaml is a combination of the _static and the _dynamic, with a slightly different spacing.) ... The line where you define your groundshape in the .GroundshapeDatabase - - There, column below 'type'- Change that to png, and you can use your photoshop version directly, if saved as png. - Saw your pics from the link. Now I'm curious- - How did you get the groundshape placed exactly at the equator? Usually, groundshapes are placed at random spots - Even partly up into the pole regions... At least, if they are smaller. Is it only at this seed, or others, too? Never used groundshapes much (because unwieldy), except for rare cases. ...Could be the size of the stamp, and the stampPlacer desperately trying to fit it on the terrain... Whatever it is, that would be a quite nice tool to have, at least for class 2 moons. That way, it would be another option to using the standard base terrain. Could be nice for special worlds, that are too complex to create with several stamps... And even with need of a fixed seed, it would be good for scenario builders (if placing all your POI as fixed, too. ) Groundhapes are of the 'ADD' operation - IIRC even if you try other operations there. Meaning, their curvature gets added on the existing terrain curvature on that spot. E.g.if there is a bump there, it will 'shine through'. MAX is pressed through the terrain from below, MIN is a cookie cutter press from above, and SUB will be inserted in the terrain as ADD is, but will go up and down. If a stamp, named 'StampName.png' has a splat named 'StampName_splat.tga', then that will be used as the splat for the stamp, always. In playfield_dynamic or playfield.yaml, you will then need to define the stamp with a placement chance, followed up with the texture channels of the splatstamp. E.g. - Stamps: MyCustomStamp, 0.5, 7,8,S,T (With 7 & 8 being examples for texture channel numbers / 'childs' as shown in the texture editor, S will take the current biome side texture and T the current biome top teture. You can shuffle/combine/partly use them as you like, and they will take the positions of the pixels in the RGBA channels of your splat) (Careful, stamps with splatmaps 'overrule' any biome textures, and only have 4 channels. Depending on what you want to achive - - Maybe you don't even need a splat?)
Thanks for looking this up @Needleship ! Spoiler: My hidden anti-spam reply... Yes, I discovered that, and this unique "playfield.yaml" only appears in the save file now since the SSG doean't work anymore. I tried a zillion ways but it's just dead. I discovered that also. The only problem was that there are many color profiles assigned to these, and some png work, others don't. I had to use 256 b / 20% dot gain, but I merely stumbled upon that randomly when loading a "working" stamp, and Photoshop warned me about there being a different color profile than the workspace's. So now I'm able to skip the conversion to .raw, but images appear upside-down... sometimes... damn... It was a specific seed, but I think your intuition is good. I'm trying to get the exact right vertical size now so it doesn't wrap/ overlap. At least with the exact horizontal lengths for each planet class it constrains overlaps aligned vertically. As you surely saw, the game still uses the old .raw maps after the playfield is loaded, and I know we can edit this terrain but underground textures will how. Since the game still uses these huge 8192 x 4096 .raw images, + the splats, I wonder how "performance" can be better now with even more images to keep track of. I would be curious to see the inner works of this. Thanks for the tips. I'm already trying things with stamps, and I will try to use biomes rules to force stamps to align. I think one of the main problems for both stamps and groundshapes is that the SSG (the game in reality) will "force" the set land/water ratio by shifting/ bumping the elements up down and around. Working with planets, humidity and temperature masks "blindly" (SSG is dead) is like fishing with a machine gun at night... But first I had to make some "empty" templates for planets in which I can try things without breaking them. Even with minimal content I sometimes get errors in game, but I'm getting there. I'll keep you informed anyway, and if I can get the amount of control I want on "manual" generation I will write it down on the forums so everyone can try it.
Spoiler: @Kassionade - Answering :) Yes, the SSG is broken. Plz fill a bug report, some people have to know that this is a demanded issue. ^^ Workaround: Switch to an older version of EGS (IIRC A 11.5 or earlier). Copy the stufff from the ssg into your curent version, into an extra folder at the same level of the folder structure. Then start that SSG.... and export. (It can't do POI placement, since stuff was changed in the meantime, and will scream a lot - - But the export is fine.) For the final touch-up of stamps I use Gimp. (Grayscale png) It's likely much more simple than that. Land-Water ratio controls the shape of the 'base terrain', and prevents stamp spawning at certain places. - Where 'water' should be. And all that, even if you have sealevel zero, and the terrain is much higher. You can use that as another control of 'flat terrain vs Mountains'. At least on dead, waterless worlds. - To have stuff spawn everywhere, turn it to completely land. (LandWaterRatio to zero) Careful, that will influence the numbers of stamps that will spawn. Maybe need to tone down/bump up the spawning numbers then. Groundshapes probably are not influenced by Land/water, since they eagerly spawn on Ocean, which has nearly no land. Uh, sorry, I don't seem to understand - -...? There is a 'legacy' folder, for the old 'fixed' terrain. But those aren't used for "stamp worlds". For "stamp worlds", terrain now is auto-generated. And a small moon wouldn't have that huge resolution, that would spam the HDD with data...
Spoiler: Reply to Needleship All actual "generated" planetary playfields have a .raw map in their respective cache folder, in the savegames, once the "generation" is done. At first load of the game or of each new playfield, its terrain is "cooked" and fixed in a map that you can see in the cache. For each planet/ moon size they have the "old" corresponding .raw maps sizes : size 2 is 1024 x 512, size 3 is 2048 x 1024, size 4 is 4096 x 2048 and size 5 is 8192 x 4096. You can open them and see by yourself : their sizes fit exactly the old fixed maps system. I use ImageJ to see and edit them. So after initial generation (ex. when loading a savegame), the game uses the same old system...
Spoiler: - To Kassonnade! Ok, now I get it...! :) (I thought you would mean that ALL playfields have the 8192 x 4096 resolution) ... Yeah, as you wrote. But it is more a result of using heightmap terrain, instead of the 'calculated' libnoise terrain of old? "Either have ultra-large worlds, with minimal disk space need, ... but no real erosion and planets hard to design (libnoise), ... or use heightmap terrain with complete freedom of shape - But at the cost of disk space, needing a large cache." Edit: And I wrote your name wrong above. Sorry.
Spoiler: Question Do you know of any template that doesn't generate these maps in the savegame apart from space playfields ?
Spoiler: No, sorry... And it is unlikely that there is ever one, since 'has terrain' means - with heightmap tech- that 'the terrain data needs to be saved'. ... Even Debug mode creates cache files. I couldn't get the old xml/dll (Libnoise) worlds to work again. Only those would probably not use these maps.
I have some questions... 1 - Is it possible to manually place a POI/ structure in a playfield and have it spawn in the exact same place/ position without it messing up the terrain ? If not, what is the way to get closest to that result ? 2 - If I want to do this with the "anchor" drone base, what will I have to modify in its blueprint in my scenario's prefabs ? (if answer to first question is positive of course) 3 - Can I "force" manual position of the "anchor" dronebase in a specific location (x,y,z) and how do I get the proper "elevation" when I'm in the playfield at that location ?
Well, I'm no real expert here, but I would try it that way: - Set up a fixed POI, enter the coordinates (and rotation if you like) - set SI to 'Off' in the POI properties (so that it doesn't collapse when the player approaches it.) - Set UseFixed to true in the playfield properties. That should do the trick, I think. /jmc
Hahaha ! You're a chief ! And @Needleship too. Spoiler: See this: I am a noob at making POIs, so my base must have a problem because it just refused to spawn where I told it to, or it was simply because I followed some wrong examples in one of the multiple vanilla template folders (I think it was the "ExamplePlanet" yamls). So by following the new "group" naming method I just failed over and over again. So I tried the example you gave me here jmcburn, with one of the "stock" bases, and it worked ! But before I tried it I just changed my playfield_dynamic to remove something, then I got that result : Then I put back in the overlapping (rather "underlapping") fixed biome containing that 2nd square fixed biome. View from my starter base in space, the red arrow shows where I want to spawn a POI : And once on the planet : The thing spawned in the ground because the height had changed. But the important part is : it spawned anyway ! So I just adjusted the height and started a new test game. This time, the 1st starter biome (there are 2 huge stamps each covering half the planet) was upside-down, but since that little square is fixed it is not affected : And there we are : It worked ! Now I understand that I might have better chances at placing stuff by using the EPD than doing it by hand. It's a bit frustrating that by following examples given to us only yields errors... So this is one way I found to make "drawn" terrains. Far from perfect, but at least we can use the overlapping fixed biomes to specify areas for POIs, and still be able to play around with the terrain design. Even though the notes say that fixed biomes will overwrite all other biomes, it still gets proper deco and temperatures if set in other biomes by altitude, and all zero-values (black) areas in the overlapping "stamp" let the other biomes come through, like here below the trees in the "E" are part of one of the first biomes in the list, and the rocks are from the "catch all" biome just before the several fixed ones I used :
Looks great! The problem is, using groupnames is only possible with RandomPOI placement, and RandomPOIs can't be placed by giving fixed coordinates. So it's either: - add RandomPOIs and there you have to use the POIs groupname (as the game then can choose from different POIs with the same group name set). Then the game decides where the POI get's placed, defined by the parameters set up in the RandomPOI configuration. or - use fixed POIs, where you can control everything, but then you have to use the SpawnName (or FileName, or both, I still mix this up often). So this will always be the exact same POI. And exactly at the same spot. /jmc
What @jmcburn said Placing 'random' POIs at a roughly a certain spot is very tricky, but possible. Spoiler: Loong description for random POIs The random POI placer usually just closes its eyes and throws a dart on the board, for a set amount of 'spawn tries'. So this works better, the smaller the planet and the bigger the 'target biome': 1- You define a biome, that only spawns at a certain location (E.g. a 'special' biome type, which also can be placed manually in x,y position). -> playfield_dynamic, compare with the 'CrashSite' of TemperateStarter 2- Then you brute-force the POI spawner that it only can choose that biome to spawn the POI in ->playfield_dynamic, at the POIs: Random: E.g. 'Biome: [ CrashSite]' ... and use 'IsImportant=true', which increases the spawn tries drastically. 3- If you have another POI that is always close by, you can use 'SpawnPOINear', to increase spawn chances. The PoiPlacer will only try to fit your spawn in that defined range, making those precious spawn tries work better. But only, if that 'anchor POI' also reliably spawns. If the anchor is missing, none of the 'anchored' cluster POIs won't get placed. ... Check with the SSG if it consistently spawns at all seeds (=that is the main part of the work). 4- And if all that still fails occasionally, then you could use a 'fallback' spawn. See SnowStarter, which has a stubborn Talon dronebase: Spoiler: Fallback spawn ->playfield_static, at the POIs: Random: Code: # ========= Talon command center (Base attacks) ========= # (Has to be placed before Polaris and Zirax, since it needs to reserve a place in the Oasis biome. # The Oasis biome may be too tiny on large worlds, so this POI has a fallback spawn) # (Usually placed) - GroupName: TribalZiggurat # POI ANCHOR # CommandCenter Faction: Talon Biome: [ Oasis ] IsImportant: True IsCommandCenter: True CountMinMax: [ 1, 1 ] LevelMod: +3 SpawnPOIAvoid: [START] SpawnPOIAvoidDistance: 4000 SpawnPOINear: [START] SpawnPOINearRange: [4000, 17000] # To increase spawning chances - SpawnCheck will only be done in this range. Properties: - Key: Music Value: Ghost - Key: RegenAfter Value: 720 # (Fallback) - GroupName: TribalZiggurat # POI ANCHOR # CommandCenter Faction: Talon Biome: [ Taiga, TaigaEdge, TaigaSnow, TaigaSnowEdge, Shore, Oasis ] IsImportant: True IsCommandCenter: True CountMinMax: [ 1, 1 ] LevelMod: +3 SpawnPOIAvoid: [TribalZiggurat] SpawnPOIAvoidDistance: 40000 # (Larger than the world = won't spawn another Ziggurat, if the first one got successfully placed.) SpawnPOINear: [START] SpawnPOINearRange: [4000, 17000] # To increase spawning chances - SpawnCheck will only be done in this range. Properties: - Key: Music Value: Ghost - Key: RegenAfter Value: 720 =If you use for the fallback a 'spawnPOIAvoid' towards the 'primary' spawn, and with an extremely large distance value (larger than the playfield), then the 'fallback spawn' will only get placed if your primary has failed. -> Wastes a little bit of world generation time, but gives you another set of 'IsImportant' - spawntries.
Thanks for the tips. In fact I already tried these before resorting to manual placement because I don't want a "random placement" in a "large" spot : I want to be able to group things together without using the "group" random, and seeing how fussy it is with just one structure it is not a good method. I posted my thoughts on this in the "What did you do in Empyrion today" thread this morning, and the only remaining problem is that even "fixed biome" stamps get flipped and mirrored randomly, like the groundshapes did. I tagged Eleon to check this, so let's see what happens. I already asked Taelyn some time ago about the SSG being broken, and he told me there were no plans to fix it ATM. Even with the "cooked" playfield.yaml and a fixed seed, the terrain still changes notably from one draw to another, and after a few tries the stamps just flip and move around. This means that to be able to make a static terrain we have to use the same global seed each time - that's the only solution for scenarios - or I'll settle down for an older version for a while...
I was able to use a fixed seed in a playfield.yaml file and have it be the same every time, but it's also part of a fixed sectors.yaml file and not randomly placed via solarsystemconfig.ecf. Not sure if that makes a difference but it's definitely possible. I'm building an instance and using fixed pois built to fit the terrain and it seems to be working.
Start a new game a few times, then compare the maps in Saves\Cache\NewGame_X\Playfields\YourFixedPlanet\map.png. If they're all identical, please give us your recipe ! I use a fixed sector, I don't use the solarsystemconfig.ecf but I use a galaxyconfig.ecf.
Yeah I've started dozens of games testing it with random seeds but now I'll see if it still looks the same after this latest update.
