[TOOL] Empyrion Playfield Designer v2.43.0 EXP (Empyrion V1.11.x compatible)

Discussion in 'Planets & Playfields' started by jmcburn, May 5, 2018.

  1. jmcburn

    jmcburn Rear Admiral

    Joined:
    Jan 15, 2017
    Messages:
    1,113
    Likes Received:
    1,759
    Thanks for the report. I'll check it out in the evening. :)

    /jmc
     
    #801
    esditas likes this.
  2. ravien_ff

    ravien_ff Rear Admiral

    Joined:
    Oct 22, 2017
    Messages:
    6,395
    Likes Received:
    12,004
    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.
     
    #802
  3. jmcburn

    jmcburn Rear Admiral

    Joined:
    Jan 15, 2017
    Messages:
    1,113
    Likes Received:
    1,759
    @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. :D

    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
     
    #803
    Ephoie, ravien_ff and esditas like this.
  4. esditas

    esditas Ensign

    Joined:
    Dec 26, 2017
    Messages:
    7
    Likes Received:
    3
    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!
     
    #804
    ravien_ff likes this.
  5. ravien_ff

    ravien_ff Rear Admiral

    Joined:
    Oct 22, 2017
    Messages:
    6,395
    Likes Received:
    12,004
    Thank you!
     
    #805
    Ephoie likes this.
  6. Ephoie

    Ephoie Captain

    Joined:
    Jan 27, 2018
    Messages:
    329
    Likes Received:
    515
    @jmcburn
    Currently, when I start the tool, I get this "LOG Error"
    upload_2020-1-16_11-10-17.png

    The tool starts and functions for the most part...

    When I go to do a check though, I get this:
    upload_2020-1-16_11-14-36.png
    Am I missing something here?
    Is it not supposed to run through a list of checks?

    Thank you for all your efforts!
     
    #806
  7. jmcburn

    jmcburn Rear Admiral

    Joined:
    Jan 15, 2017
    Messages:
    1,113
    Likes Received:
    1,759
    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
     
    #807
    Ephoie likes this.
  8. Ephoie

    Ephoie Captain

    Joined:
    Jan 27, 2018
    Messages:
    329
    Likes Received:
    515
    @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.
     
    #808
  9. jmcburn

    jmcburn Rear Admiral

    Joined:
    Jan 15, 2017
    Messages:
    1,113
    Likes Received:
    1,759
    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
     
    #809
    Ephoie likes this.
  10. Ephoie

    Ephoie Captain

    Joined:
    Jan 27, 2018
    Messages:
    329
    Likes Received:
    515
    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!
     
    #810
  11. jmcburn

    jmcburn Rear Admiral

    Joined:
    Jan 15, 2017
    Messages:
    1,113
    Likes Received:
    1,759
    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
     
    #811
    Ephoie likes this.
  12. Ephoie

    Ephoie Captain

    Joined:
    Jan 27, 2018
    Messages:
    329
    Likes Received:
    515
    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....
     
    #812
  13. jmcburn

    jmcburn Rear Admiral

    Joined:
    Jan 15, 2017
    Messages:
    1,113
    Likes Received:
    1,759
    @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
     
    #813
    Last edited: Jan 19, 2020
    esditas, Ephoie and Germanicus like this.
  14. ravien_ff

    ravien_ff Rear Admiral

    Joined:
    Oct 22, 2017
    Messages:
    6,395
    Likes Received:
    12,004
    I've done a lot of work with space dynamic.
     
    #814
    Ephoie and jmcburn like this.
  15. jmcburn

    jmcburn Rear Admiral

    Joined:
    Jan 15, 2017
    Messages:
    1,113
    Likes Received:
    1,759
    Thx,
    I'll take a good look at Project Eden, maybe I can figure out a few things. ;)

    /jmc
     
    #815
    esditas and Ephoie like this.
  16. Fenra369

    Fenra369 Commander

    Joined:
    Apr 5, 2016
    Messages:
    340
    Likes Received:
    139
    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-
     
    #816
  17. jmcburn

    jmcburn Rear Admiral

    Joined:
    Jan 15, 2017
    Messages:
    1,113
    Likes Received:
    1,759
    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
     
    #817
    Last edited: Jan 22, 2020
    esditas, Ephoie and Germanicus like this.
  18. Fenra369

    Fenra369 Commander

    Joined:
    Apr 5, 2016
    Messages:
    340
    Likes Received:
    139
    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.
     
    #818
  19. jmcburn

    jmcburn Rear Admiral

    Joined:
    Jan 15, 2017
    Messages:
    1,113
    Likes Received:
    1,759
    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:

    upload_2020-1-23_6-42-19.png

    In first Eggstarter you can select these as SpawnNear (+ all the fixed POIs):

    upload_2020-1-23_6-43-14.png

    In second Eggstarter you can select these as SpawnNear (+ all the fixed POIs):

    upload_2020-1-23_6-44-6.png

    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
     
    #819
    Last edited: Jan 23, 2020
    Monroe, Ephoie, esditas and 1 other person like this.
  20. Ephoie

    Ephoie Captain

    Joined:
    Jan 27, 2018
    Messages:
    329
    Likes Received:
    515
    #820
    Monroe likes this.

Share This Page