The Persist behavior has unexpected blindspots that are not (and should be) documented.

Post reply
0 favourites
  • 5 posts
From the Asset Store
Fighting Template: A (Not So) Basic One
$24 USD
25% off
2D fighting template based in the game that defined the fighting games genre.
danuyos's avatar
danuyos

  • You would think that the straightforward nature of the Persist behavior means it works as intended all the time right? After all, it barely even warrants a page in the documentation, and it doesn't have any parameters. It just makes things remember how they were when moving back into a layout after all.

    Except it does have at least 2 issues that do not work as expected and are not documented anywhere in the behaviors page:

    1. It doesn't work with the Pin behavior. I can at least understand that this is because Pin is dependent on 2 objects, and there is no guarantee that both objects also contain Persist... but if they do, it should work properly, or at the very least this should be noted in the documentation instead of forcing users to figure it out on their own, since (to my knowledge) Pin is the only built-in C3 behavior that contains an incompatibility with Persist.
    2. Objects with Persist do not remember their template names. Unlike the previous issue, I don't see any reason for this, it's just something you have to find out the hard way on your own. Yes, it's easily worked around by simply storing the templates name in a local variable, but I shouldn't have to do that, or (again) at the least this issue should be documented.

    -Signed, an annoyed dev who spent a couple hours tracking down why his supposedly persistent templated doors didn't work and could not be picked using previously working code.

  • My biggest issue with Persist behavior is that "Reset persisted objects" action resets all objects on all layouts - which makes it pretty much unusable in large projects.

    There are also lots of bugs when objects with Persist behavior are in hierarchies, restored from save state etc.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • I have had a hard time with hierarchy and persist. I make up a family called myPersist (or whatever name) and to be in the family you have persist on. This didn't fix the pin trouble, but it helped with some of the hierarchy problems.

  • My biggest issue with Persist behavior is that "Reset persisted objects" action resets all objects on all layouts - which makes it pretty much unusable in large projects.

    There are also lots of bugs when objects with Persist behavior are in hierarchies, restored from save state etc.

    What are some of the issues you've run into regarding saves? I'll need to keep an eye out on those in my project as well. I did run into hierarchy issues on my end too, which I had to solve with some failsafes.

    Persist feels more and more like it is more trouble than it's worth. I've avoided using it in other projects because of it's monolithic nature, and only did so this time because developing my own tracking methods was previously such a pain that I figured this would be better.

  • I was working on a project with lots of persisted objects and lots of complex hierarchies, and there were quite a few bugs:

    github.com/Scirra/Construct-bugs/issues/6389

    github.com/Scirra/Construct-bugs/issues/5523

    github.com/Scirra/Construct-bugs/issues/6019

    github.com/Scirra/Construct-bugs/issues/6225

    They all have been fixed, but we still have occasional unexplained problems when the game is loaded from saved state. I can't report them because there's no repro..

Post reply
  • 5 posts
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)