2.3.x Save Compatibilty For Professional Projects

Comments

5 comments

  • Ricardo Zangrandi

    Even GMS2 2.2 doesn't grant the assets' index won't change. If you add/remove a resource, the index will change no matter what. I don't see how YoYo Games could "freeze" the assets' index in a reasonable way. If the index is locked. Remove assets will increase the index count and end up creating a lot of waste the engine will have to loop through, which is not desirable.

    In a proper save system, you want to store the room names (room_get_name) and resources names (xxx_get_name) to make sure you are recreating the correct rooms/objects when loading.

    0
    Comment actions Permalink
  • Cameron Anderson

    I don't think the space of removed assets is an issue, especially if the developer has the option to "refresh / collapse" the tree.

    That being said, I'm really not looking for "here is X janky workaround".

    If you don't agree a save-able tree is a good addition, that's fine.

    0
    Comment actions Permalink
  • Ricardo Zangrandi

    I didn't mean to offer a "janky workaround", but the proper way of handling a save/load system now considering how GMS used to work in previous versions, how it works right now (2.2) and how it will most likely continue to work (2.3).

    I doubt YoYo will consider a feature to "lock" the asset's index. But hey, maybe I am wrong and they actually could do it? There's definitely nothing wrong in asking them.

    0
    Comment actions Permalink
  • Cameron Anderson

    Ok, I see. Perhaps it's just not really necessary here - I'm not posting in programming help, or looking for justification / workings of the current system.

    I dont expect a drastic change, but just hoping it will pique some interest on their side is all.

    0
    Comment actions Permalink
  • Harold Myles

    I would agree with Ricardo and storing resource names in 'save data'  is a better option than the internal IDs used by game maker.  The user has control over names.

    It is easier than any other method/fix for both YoYo and the user developer.

    Storing IDs like that should be avoided in general for portability.  e.g. A bone/animation exporter will typically reference bone names, not bone indexes, to allow bones hierarchies to change and bones to be added removed.

     

    0
    Comment actions Permalink

Please sign in to leave a comment.