UPDATE (v1.57.9) CHANGES: changed/fixed: splitted cleaning/reInit routines into the different playfield types to have different cleaning routines for each playfield type. changed: Default Terrain after creating a fresh playfield is now A8's random terrain, not 'Temperate' anymore. changed: enable/disable list buttons (Edit, Delete, MoveDown, MoveUp) based on if an item is selected. added cleaner routine for Pos (Fixedplayerstart) and SpawnPOINear/Avoid FIXES: fixed: Cleaner and ReInit bugs, especially with Space playfields, but also some for planet playfields fixed: After saving, some list buttons (Edit, Move, ...) did not activate, when an item was selected fixed: added NullChecks to the recently added Preflight checks. (Caused crashes on space playfields) fixed: Space playfields: On a second save, planet properties were added to space playfield yamls. (Cleaner/ReInit bug), thx to Rexxxus for noticing fixed: SpawnZones' ExcludeBiomes was not initialized correctly. Thus adding 1st item to empty list was not possible. DOWNLOAD LINK: https://www.dropbox.com/s/jvyohw0a14fjzr0/EPD_v1579_public.zip?dl=0 /jmc
UPDATE (v1.58.0) CHANGES: added new SplashWindow instead of SplashImage on Startup (to make it possible to show text on splash). changed: now showing version on SplashWindow changed: DBItems ToString() method used in yaml emitting and listbox display now correctly returns ItemName (ingame name) instead of localname. Please check if there are any regressions. So far, i could not see any. added entry 'None' to dropdown boxes. So now you can 'unset/clear' a value previously set in dropdown boxes. FIXES: fixed: SpecialBiome's AvoidBiome always defaulted to first entry in biomes list, even if it should be empty. DOWNLOAD LINK: https://www.dropbox.com/s/00djeckxlhx4yxu/EPD_v1580_public.zip?dl=0 /jmc
UPDATE (v1.58.1) FIXES: fixed: localizations weren't working anymore PlayfieldType Selector wasn't showing playfield type on localized UIs. fixed: PlayfieldTypeSelector was not initialized correctly on localized UIs. KNOWN ISSUES: still non translated items, buttons, messages, and UI in general. DOWNLOAD LINK: https://www.dropbox.com/s/ekml8sl58b5yo5y/EPD_v1581_public.zip?dl=0 /jmc
v1.58.1 and 1.58.0 just crash for me when I click on either save or save as. Had to revert to 1.57.9.
Just tested with all kinds of playfields and Save/SaveAs both worked just fine for me. Are there any specific steps to reproduce this? Couple of questions to isolate the issue: * could you please zip and upload EPDs log found in the logs folder AND the playfield causing the issues. * Are you using EPD in a non english localization (german or french)? * Possibly this is playfield related. Does this happen on all playfields? * Does this happen only on _dynamic, space_dynamic, _static playfields? /jmc
Hi jmc, unfortunately I have the bad habit of SHIFT+Delete things from my gaming computer (small SS drive), so I don't have the logs and I won't be able to do any testing till probably next week (work reasons). Here's what I can tell you for now: 1.- I'm on a Windows 7 (64bit). It's got a motherboard issue, but for the most part works fine. 60 something gigs or RAM, old i7 processor and just a few games on it. 2.- I was working on a very old version of your program (1.3 I think) but I kept getting errors. It was a playfield I started a long time ago and had neglected till yesterday. So decided to start from scratch and looked up to see if there was a post alpha 8 version. 3.- I began with 58.1, loaded the Example planet from Empyrion's folder, added a bunch of POIs, configured the player start (on structure) and inventory, clicked Save As and I got EPD has stopped working Windows is checking for a.... Damn! 4.- Opened it up again, changed nothing and tried Saving As... Same result. Tried again with a different template (TemperateNEW I believe) same issue. 5.- Restarted computer, opened EPD, clicked Save As and it worked! Changed only one thing (gravity I think) clicked Save (not Save As) and crashed again. Tried a few different templates (temperate2, temperate legacy, etc.), tried copying the template to a different directory, same result with each one. 6.- Came back here, downloaded 58.0, attempted the same tests crashed every time. 7.- Came here again, downloaded 57.9, attempted tests. No problems and kept working till about 7 in the morning with no issues. Unfortunately this is the only playfield I've ever worked on so I couldn't test it with others (besides the Example and/or temperates that I used as templates). Hopefully next week I might be able to come back to it and test a bit more. In a nutshell, it's a very simple playfield with few orbits and planets at the moment, it does however, contain some pretty beefy (large) blueprints, but I can't imagine that would have any effect. Cheers!
Thank you for the infos so far. I found a bug now that causes EPD to crash on save, if you open and save a playfield_static.yaml in EPD. This bug will be resolved in the next version. Maybe that will resolve your issues as well (most likely). The thing is, there now is a completely new workflow in EPD since 1.36, as there are basically 3 files now you can edit and also the new SolarSystemGenerator in Empyrion. You should never open a _static file in EPD directly. Because when you save it, it won't be a _static anymore and would not work in the game anyway. I think I will remove the possibility to open those directly in EPD. You need either a playfield.yaml or a playfield_debug.yaml to beeing able work with EPD. If there is no such yaml in the playfield folder (just static and dynamic), you can generate one in the SSG (SolarSystemGenerator) found in Empyrion's main folder. Here's how: If you want to create a fixed scenario playfield, simply work now on the (generated) playfield.yaml or playfield_debug, as you did before in v1.36 and save that as playfield.yaml. If you want to work with random playfields, you still need to open the playfield.yaml/playfield_debug.yaml as base file. But from that one you can export a new _static.yaml via the menu 'File' -> export static. The _dynamic can be opened either via double clicking in the tree directly (into the new dynamic editor, this will also open the corresponding playfield.yaml, as those are linked to eachother in EPD). Or, if you already have the corresponding playfield.yaml/_debug.yaml opened in EPD, via menu 'File' -> edit dynamic. With those edited _dynamic and _static files, you can also go back into the SSG if you want and tweak/preview your playfield and POIs/Resources for certain seeds, then export yaml again and go back to EPD. It needs some time to get into all the new playfield editing stuff, but you can create completely different and more complex things now. Hope this helps /jmc
Having heavy epic armor set as an starting armor gives out this error and prevents editing of the playfield.yaml. However, this value (ArmorHeavyEpic) will work in game without issues. Code: 9/20/2018 10:46:18 AM | ERROR in: YamlDotNet | Exception: (Line: 155, Col: 14, Idx: 3732) - (Line: 155, Col: 28, Idx: 3746): Exception during deserialization | INNEREXCEPTION: System.ArgumentException: Requested value 'ArmorHeavyEpic' was not found. at System.Enum.TryParseEnum(Type enumType, String value, Boolean ignoreCase, EnumResult& parseResult) at System.Enum.Parse(Type enumType, String value, Boolean ignoreCase) at YamlDotNet.Serialization.NodeDeserializers.ScalarNodeDeserializer.YamlDotNet.Serialization.INodeDeserializer.Deserialize(IParser parser, Type expectedType, Func`3 nestedObjectDeserializer, Object& value) at YamlDotNet.Serialization.ValueDeserializers.NodeValueDeserializer.DeserializeValue(IParser parser, Type expectedType, SerializerState state, IValueDeserializer nestedObjectDeserializer) | STACKTRACE: at YamlDotNet.Serialization.ValueDeserializers.NodeValueDeserializer.DeserializeValue(IParser parser, Type expectedType, SerializerState state, IValueDeserializer nestedObjectDeserializer) at YamlDotNet.Serialization.ValueDeserializers.AliasValueDeserializer.DeserializeValue(IParser parser, Type expectedType, SerializerState state, IValueDeserializer nestedObjectDeserializer) at YamlDotNet.Serialization.ValueDeserializers.NodeValueDeserializer.<>c__DisplayClass3_0.<DeserializeValue>b__0(IParser r, Type t) at YamlDotNet.Serialization.NodeDeserializers.ObjectNodeDeserializer.YamlDotNet.Serialization.INodeDeserializer.Deserialize(IParser parser, Type expectedType, Func`3 nestedObjectDeserializer, Object& value) at YamlDotNet.Serialization.ValueDeserializers.NodeValueDeserializer.DeserializeValue(IParser parser, Type expectedType, SerializerState state, IValueDeserializer nestedObjectDeserializer) at YamlDotNet.Serialization.ValueDeserializers.AliasValueDeserializer.DeserializeValue(IParser parser, Type expectedType, SerializerState state, IValueDeserializer nestedObjectDeserializer) at YamlDotNet.Serialization.ValueDeserializers.NodeValueDeserializer.<>c__DisplayClass3_0.<DeserializeValue>b__0(IParser r, Type t) at YamlDotNet.Serialization.NodeDeserializers.CollectionNodeDeserializer.DeserializeHelper(Type tItem, IParser parser, Func`3 nestedObjectDeserializer, IList result, Boolean canUpdate) at YamlDotNet.Serialization.NodeDeserializers.CollectionNodeDeserializer.YamlDotNet.Serialization.INodeDeserializer.Deserialize(IParser parser, Type expectedType, Func`3 nestedObjectDeserializer, Object& value) at YamlDotNet.Serialization.ValueDeserializers.NodeValueDeserializer.DeserializeValue(IParser parser, Type expectedType, SerializerState state, IValueDeserializer nestedObjectDeserializer) at YamlDotNet.Serialization.ValueDeserializers.AliasValueDeserializer.DeserializeValue(IParser parser, Type expectedType, SerializerState state, IValueDeserializer nestedObjectDeserializer) at YamlDotNet.Serialization.ValueDeserializers.NodeValueDeserializer.<>c__DisplayClass3_0.<DeserializeValue>b__0(IParser r, Type t) at YamlDotNet.Serialization.NodeDeserializers.ObjectNodeDeserializer.YamlDotNet.Serialization.INodeDeserializer.Deserialize(IParser parser, Type expectedType, Func`3 nestedObjectDeserializer, Object& value) at YamlDotNet.Serialization.ValueDeserializers.NodeValueDeserializer.DeserializeValue(IParser parser, Type expectedType, SerializerState state, IValueDeserializer nestedObjectDeserializer) at YamlDotNet.Serialization.ValueDeserializers.AliasValueDeserializer.DeserializeValue(IParser parser, Type expectedType, SerializerState state, IValueDeserializer nestedObjectDeserializer) at YamlDotNet.Serialization.ValueDeserializers.NodeValueDeserializer.<>c__DisplayClass3_0.<DeserializeValue>b__0(IParser r, Type t) at YamlDotNet.Serialization.NodeDeserializers.ObjectNodeDeserializer.YamlDotNet.Serialization.INodeDeserializer.Deserialize(IParser parser, Type expectedType, Func`3 nestedObjectDeserializer, Object& value) at YamlDotNet.Serialization.ValueDeserializers.NodeValueDeserializer.DeserializeValue(IParser parser, Type expectedType, SerializerState state, IValueDeserializer nestedObjectDeserializer) at YamlDotNet.Serialization.ValueDeserializers.AliasValueDeserializer.DeserializeValue(IParser parser, Type expectedType, SerializerState state, IValueDeserializer nestedObjectDeserializer) at YamlDotNet.Serialization.Deserializer.Deserialize(IParser parser, Type type) at YamlDotNet.Serialization.Deserializer.Deserialize(TextReader input, Type type) at YamlDotNet.Serialization.Deserializer.Deserialize[T](TextReader input) at EPD.YAMLFile.ImportPlayfield(String filename) | LineNumber: 0
Oh didnt get a ping notice… Well adding planets can be done easly by adding them in the sectors.yaml. Just edit the sector.yaml in the save folder otherwise they wont show up. Adding pois to a existing planet, cant be done. POIs spawm on first visit of the planet. U dont have to wipe whole server just wipe the planet u want them on.
Well, my afternoon meeting got cancelled so I have the rest of the day technically off (although there's always stuff I should be doing...). Yes, I was certainly working with playfield_static yamls in every case I mentioned. That explains that, but like I said, I managed to create my playfield with no problems using version 1.57.9 using a static yaml as a template and saving it as simply playfield.yaml, although I am getting errors about biome IDs... But it's probably unrelated. I noticed that, that's why I decided to start from scratch to avoid incompatibility issues, but to be honest I'm out of my depth! I tried using the SSG but I couldn't open any of the playfields I wanted and since you can't edit the POIs I thought I might as well use your EPD, which at least I've used in the past, in combination with EmPlayfieldGenerator to create the orbits. Yes I do! For over a year I've been wanting to create this single player scenario with a parallel story to Empyrion's mainline, but I left it too long and now I'm not so sure what I'm doing... I've forgotten most of the things I researched and learned over a year ago.... I'll give SSG another go, but I'm afraid of destroying what little I've already accomplished i.e. correct placement of POIs (sometimes joined to each other) and multiple SVs and HVs inside the POIs... It's hard enough finding a flat area large enough for a city! That sounds great and I know what you mean. Can you recommend a place where I can get some help with this? Under Scenarios maybe? Thank you for your time!
Was a new feature/enhancement, so this only caused issues after 1.57.9. It's fixed again in next version. Not really unrelated. Saving a static file as playfield.yaml might work without erros in certain situations, but EPD will create a playfield.yaml where the non-existent properties of a static file will simply be filled with 'null' values, which mostly again won't be written out to the yaml, as yaml syntax 'hides' empty/0/null values by default. This could work, as the game itself again fills empty/non-existent values with it's own default values. But that's not working correctly for all of the values and might lead into strange errors like the one you described. I would highly advice against that workflow. Although I do run those new PreFlight checks now on save, which should protect you of the most common mistakes, there are still a lot of combinations and values, that I (or maybe even the devs) don't know about, that can make a playfield crash on load. SSG can't place POIs or resources and such (yet). That's why there still exists EPD. As long as the SSG isn't 'finished', both programs will co-exist and complement eachother. SSG is great for previewing terrain, POI and resource distribution (done in EPD) for any given seed. And also to create playfield.yamls with slight randomization of the same global type of a planet. It also can be used to create a whole scenario. Similar to the EPG you used now created by Jascha. The SSG can only work with and thus open the dynamic and static files. That's why the modes to edit/export those exist in EPD now. Background: Basically the 'old' playfield.yaml has been split into two files: - playfield_dynamic resp. space_dynamic.yaml - playfield_static.yaml If you export a (playfield.)yaml in SSG, it takes the two files (_dynamic and static), randomizes new values out of the the range properties of the dynamic file and then copies both the result of the randomization and the static file into a single new playfield.yaml. The dynamic files contain the biomes section of the yaml and also new, now randomizable ranges of previously static values. The _dynamic files are used by the SSG and also the default single player game to create variations of the playfield on every fresh game start on the fly. The _static yaml files are simply just fragments of the main playfield.yaml (containing the old resource, POI, Drones, Creature, ... sections). So that's why exporting those from a playfield.yaml is possible, as I just only export some of the properties of a playfield.yaml. And that's also the reason why you still need a playfield.yaml to work with EPD: Simple workflow: Some like to only work with EPD and the normal playfield.yaml, that's the easiest workflow and the same as in EPD 1.3.x. If you want to work that way, you still only need to edit the playfield.yaml and can safely ignore the static and dynamic files. But then you won't be able to create randomizable worlds for the single player game or use the SSG to preview and edit. 2nd workflow including the SSG: Some like use the SSG as well and want to create random worlds. And as some of the properties exist in both the main playfield and also the dynamic/static files, I decided it would be best to work on all of the three files at the same time. So you only have to edit a property in one file, and if the same property exists also in the static or dynamic file, EPD will change it in the other files as well. The advantage is, that if you, at one point, decide that you want to work with the SSG, you can, as you always have all three files available. I'd suggest, copying the 'Default Akua-Omicron' scenario and go from there. It has all the necessary files set up to start a game. For first simple terrain tests of a playfield, i'd suggest leaving the playfield files still in the content\playfields folder and work in there. Start up game to main menu, enter the console, type 'loadplayfield <playfieldname>' and your playfield will be loaded, but only the terrain and deco part. That way you can fast load a playfield, without the start sequence and such. BUt as I said, no POIs, no resources, no creatures, it's just a terrain test. After you're mostly happy with the terrain and deco, copy your playfield over into your new scenario, edit the sectors file in there accordingly (use 'Akua' entry in there as reference, as it has a player start configured). Start up game, and from now on edit the yaml file in the scenario instead to test POIs, resources, creatures, drones, ... Drawback is now that loading will take a lot longer. I'd suggest setting up the player start to Position 0,0,0 instead of Escape pod to speed up the game start for testing. EPD creates backups on every save. Good advice is, only make very small changes at a time in the beginning, because if you make a mistake and the game crashes on load, it's extremely hard to find the error if there were too many changes. For the SSG, I'd suggest making backups of the yaml before exporting a new playfield.yaml. But it's great to set up and preview humidity, temperature and biome distribtuon based on those values with the sliders ion the bottom. But as i said, make a backup before exporting, as it overwrites the playfield.yaml, you used in EPD. /jmc
Just wanted to throw in my thoughts here. Right now i'm about to redo the PvE side on my server, where we go from 10 playfields to about 60-70. The way i do it and imo the easiest way, using SSG to make the raw scenario. When that done i start my server up with that scenario, and close it again. From there i can grab all the playfield.yamls in the save folder(Templates) and move them to the playfield folder in the scenario and make the changes in EPD. For moving playfields around in the sector file i use EmpPlayfieldGenerator with the nice UI that makes it easier. In short, all the tools is usable in different ways and works well together
First of all thank you for taking the time, this all very informative! Yes, the error I'm getting is "Error when reading biome data biome id 1", but it's not crashing the game, I just see the error in the console. Naturally I would prefer not to have any errors at all.... Right, I understand now. I was aware of some of the limitations of the current SSG, that's why I have avoided it, but it seems to make planet generation a lot easier! OK, I suppose the best way then would be to use all 3 programs. The problem for me is that the great many guides and tutorials I find on the Net are for people running servers, multiplayer and random scenarios. Whereas what I'm trying to create is the very opposite of this: it is a singleplayer, completely static, story-led scenario. So structure positions are crucial (for example my character starts off on a cemetery and then has to find a farm which is on the opposite side of the planet to the main city. There's also a mission to deliver a package to a terraform station high up on a mountain near the pole, at some point he/she needs to drive across the city to the airport, which is a different blueprint, so the motorways need to be connected, just to give some examples). I had most of this setup last year, but then left it because I was waiting for some requests to the devs to make this scenario possible. Then, last week, made the mistake of trying to edit it with SSG and broke the planet.... So I'll take your advice and start from scratch again! I managed to get quite a bit done with the PDA the other day so I really want to get this right! But I have a few question if you don't mind: 1.- Can I use SSG to create playfield orbits? I haven't managed to load them up... 2.- How do I create a static world with these two new file systems? i.e. a planet that looks exactly the same every time and that it's not affected by seeds or randomised? At the moment it's not accepting my seed in EPD... (sounds naughty!) 3.- Is there an extra setting to make sure the scenario never gets randomised? Since the structures are so dependant on terrain... So far I understand that I need to: 1.- Open default Akua with SSG 2.- Create the planet that's suited for that part of the story 3.- Export to my new scenario folder under playfields 4.- Open with EPD to add structures, player start and inventory/loot objects But here on number 4, which file do I open the static or the dynamic? Presumably the static, but then do I delete the dynamic to avoid number 3 above? I highly appreciate your help!
No, you can only preview them on the Orbits screen - Sitch to 'Orbit' top left, then select the desired template on the right, enter seed and click generate - Or click load and select a playfield.yaml/playfield_debug.yaml. Dynamic won't work here. -> Exception That's a bit tricky. For the SSG to work, you need only the _dynamic and _static files and the SSG can't make use of the playfield.yaml, except export one created from the _dynamic and _static file. But if you don't want to get anything randomized in the end, you must not have _dynamic and _static files in the final playfield template folder in your scenario. So I guess, you would need a 'design scenario', where you have all three files (_dynamic, _static and playfield.yaml) in your playfield template folder. If you're finished, I would copy the design scenario folder to a new 'final scenario' folder and delete all the _dynamic and _static files in the playfield folders and just leave the finished playfield.yamls in there. That way the game can't randmize anymore. What seed is it refusing. That's a bug for sure. Except number is too high or negative. I guess 1000000 is max atm. As I said, only use the playfield.yaml in your template folder, Don't put any _dynamic or _static in the final scenario template folder, then the game can't randomize anything. Copy the Akua-Omicron scenario folder first and rename it to somenthing new e.g. MyScenarioDesign, ... If you don't have a playfield.yaml yet, either create one from scratch in EPD, or copy and existing playfield template to you scenario under a new name e.g. MyPlayfield. Then use the SSG to create a playfield.yaml from the _dynamc and_static file in your MyPlayfield folder. Edit those three files (_dynamic, _static, playfield.yaml) with SSG and EPD to get the terrain and basic setup right. Exactly. You can always use the SSG to preview placement of POIs and such for any given seed. Choose seed 0 (or same number) for all playfields, so that the seed for all playfields is the same so you see the final result. In EPD, for adding POIs and such, only use the playfield.yaml, no _dynamic or _static. You just need those in the same folder as the playfield.yaml for final previews in SSG . If you want to see your results in SSG, just export a new _static file in EPD via file menu->export static. That creates a fresh _static file from the changes you made in the playfield.yaml. Hope this helps a little. /jmc
Fabulous! I look forward to having a day off to work on this again! I might (or may not) come back with more questions, but actually your reply was pretty good and thorough! Thank you very much again!
Ok I have a question. On playfield dynamic, regarding the planet size and propabilities, if i set them all with the same probability, do I get truly random sizes for my planets or does the seed has to do with the outcome too?
There are two seeds nowadays: - gloabl, which controls all planetary seeds. - planet seed, which defines the planet itself Same global seed means that all planets always get the same planet seeds. As far as i know, same (planet) seed = exactly always same planet. But the SSG generates seeds for each planet when you create a fresh game based on the set global seed, which in return define the planet and thus also planet's size. So yes, I think that seed has an influence on the planet's size. But how this all works exactly inside the SSG and the game, no idea. /jmc
If you use the same seed when generating a scenario in the SSG, you'll get the exact same planets, same POIs, same solar system, etc. Thus if you want a new random system, use a new seed.
