Did you include a ":" or similar character in your space description? I only ask because descriptions for space_dynamic works a bit differently than for planets.
@esditas, @ravien_ff Hmm, no there's a little more broken in the random space playfields. Took a look yesterday, they did not get much love yet. Will take a little until I fix those errors. Probably on the weekend. There's even some properties missing (some I haven't even heard of). So best not to use the space_dynamic too much yet. Sorry for the inconvenience. /jmc
yes i know... BUT ...the before file is directly from the game ... the after file is after...save with EPD...ive only change the Descr. in EPD and save it... ^^ ive no edit the files only with EPD... try yourself. @jmcburn Nice! Thank you!
@jmcburn Currently, when I start the tool, I get this "LOG Error" Spoiler: LOG Error The tool starts and functions for the most part... When I go to do a check though, I get this: Spoiler Am I missing something here? Is it not supposed to run through a list of checks? Thank you for all your efforts!
Log error is known and will be removed, nothing to worry about though. Preflight depends on what playfield type you are editing. Preflight checks are only implemented for planetary playfields for now. And even those are far from complete. I need to code each preflight check separately and that also requires that I understand how the playfields work in detail and what is allowed and what not. So coding preflights involves a LOT of try and error on my end. So this will simply take time. In the future more and more preflight checks will be added. /jmc
@jmcburn Thanks for your reply. Would a list of checks for the user to apply not be feasible? They could be predefined, automatically, 'On' for playfields/ 'Off' for orbits, and then if a user wanted, you could turn on various checks, via a preference menu.
Preflight checks are coded modular, but most preflight checks only work either on a planet or in space/orbit, because of the different properties and dependencies in space vs. planet playfield. Of course I could make a checklist to allow the user to decide what checks to run (as a second step maybe), but honestly, if something is wrong in your playfield, why not run all available checks and see what's working and what not? For now you can at least disable all 'Success' and 'Warning' results in options, so you will only see 'real' (red) errors, when you uncheck those. /jmc
The playfield in question is a Orbit. Now, if say I changed the "type" to playfield, would it warn if any prefabs are conflicts? Guess I could just go and try.... instead of buggin you.... yeah..... I'll go do that!
Switching between playfield types is not going to work, this could break your playfield really bad. EPD will throw out all the properties that won't fit in a planetary (respectively space) playfield on save. That's why I removed the playfield type selector in EPD. /jmc
Ah. kk. thanks for saving me from myself. I am trying to isolate the CoQ error I am getting when I access the Galactic Map when on certain playfields. I had hoped that EPD might be able to do such. I have been in touch with the devs, but am just waiting for feedback, and in the meantime, trying to see what I think may be the issue....
@esditas @Ephoie and others who are interested and/or have a good knowledge of how random space yamls work. Especially POI setup. The latest issue esditas brought up with space playfields is a bit tougher than I thought. The main issue with the random space playfields is that all different types of POIs are crammed into a single POI setup with a lot of different conditional properties to describe different types of POI setups. The main problem @esditas (besides that there were are still some properties missing in EPD that were deleted on save) is the 'Pos' and 'Rot' properties in the POIs setup for 'creative' mode in the yaml you were trying to edit with EPD. Those properties got deleted by EPD which lead to the error (argument cannot be null) you were experiencing. Those two properties can only exist (as far as I tested) as 'Default POI' and then only in 'Creative' mode. But EPD couldn't handle these condition(s). Until now EPD could only handle one 'conditional' dropdown property which defines all the other visible properties in its parent object (e.g. a POI). But for Pos & Rot this is not enough. So Pos and Rot were either added to ALL POIs whether 'Creative' mode or not or to none at all. Both causes the game and SSG to crash. Now I needed to implement a multi property conditional setup, where I analyse the values of different dropdows and then evaluate the right properties to display/make editable. So this weekend I implemented a new core function that allows EPD to display and edit properties based on multiple other properties' (dropdown) values instead of only a single one. Still needs some testing, but seems to work already quite ok. TL;DR The thing is: I don't really know, which property combination is allowed for which specific POI setup. At least not for sure. So everything I think of how the different POI setups might work, might be wrong and lead to a crash. So what I'm asking for: Is there someone out, who knows exactly, how the different space POI settings in random playfields work together, which are allowed in which combination and which are not. This would be really helpful, because otherwise this will be a try and error process that could last weeks. Sadly, the example space yamls do not even list all currently available properties, not to mention all the working combinations. Thank you in advance. PS: Until this is fixed, I highly advice against editing random space yamls (space_dynamic.yaml) in EPD. It most likely will break the yamls! /jmc
Honestly if it's that much of a hassle I'd rather remove it so I can at least specify POISpawnNear. I feel this could easily be remedied by having a key index instead of searching the groupname. So: If(you find a first instance of groupname) (in a separate function you call), loop key index of POIList If(groupname > 1) <<cancel any groupname validation>> -fin-
If it was that easy, it would be already in. EPD works completely different than that. It builds its code and UI itself (modular and dynamic) based on the type of property in yaml. That way I can add a new property in a few minutes and all the associated code and user interface gets created fully automatic. This is great as long as Empyrion is in Alpha, because it saves me a lot of time, but it also has limitations. The same code-modules get re-used for many different properties. All new code I add to a module that references other playfield data needs to be compatible with all the other properties, otherwise those get broken. So code needs to be written in a very very general matter. But I was already thinking about it. I'll see if I can find a solution for this in the next few days or week. Maybe I can add a completely new code module just for that property, which seems a bit of a overkill for that prupose, but if I can't manage to do it differently, so be it. But for the time beeing, why not place POIs with same groupname just beneath eachother and place all the SpawnNear POIs just above those two? Different approach would be to move the POI (and maybe also its SpawnNears) up temporarely, edit, and then move down. You can move multiple items in list by selecting them with shift and ctrl. /jmc
The solution you offer is actually something that would break the playfield (you should add a precheck for this!). POI spawn nears cannot be placed above the POIs they are supposed to spawn near; that would cause them to not spawn because the POI they spawn near doesn't exist yet. Remember, POIs spawn from top to bottom of the yaml file, so if I need a POI(1) to spawn near another POI(2), then 2 must exist before 1 is placed. The last alternative is a valid workaround at least, I can try and do that. As a better alternative... Why not just put a preflight error instead of validation? Where we cannot engineer out the defect, we can at least provide a warning.
Good news, finally had an epiphany how to solve this and it seems to work. I Need to do a few further tests though, if anything else broke. So now you can have this setup: In first Eggstarter you can select these as SpawnNear (+ all the fixed POIs): In second Eggstarter you can select these as SpawnNear (+ all the fixed POIs): Although the second EggStarter doesn't show up in the SpawnNear dropdown anymore, because there's already an EggStarter entry in the list on index 2. I think that should work. Good idea, preflight for this is added to TODO. /jmc
