[XML Markers] Save Marker Protobins from GDScript

[AsherGlick]

Currently there is a way to save marker files after they have been edited in-engine. However this only works because you can currently only have one .json file of markers open, and when you save you just save that one file.

Now that there are multiple files we must rely on the "selected" category for editing a category.

However when a user wants to save their changes there are a few questions, should ALL changes be saved?
Even ones that are not in the currently selected category?
Additionally should changes to markers not on the current map be saved?
If there are changes on the current map and the player transitions, should we automatically save so that when the player returns their changes are persisted?

The saved protobin files will clearly be able to be opened again by the user, but eventually they will also be able to be exported so that other users may access them too. So the answers to the decisions above must be correct for both an end user and a marker pack designer.

[klingbolt]

I think a potential solution for this is to have a separate folder that contains local data when any changes are made. i.e.

xml_converter/protobins/*.data
xml_converter/local_protobins/*.data

We could have burrito load up local_protobins/*.data first if it exists and then load protobins/*.data and skip any paths or icons that have the same GUID. This would allow the user's edits to persist between maps and between sessions without the pack data being changed.

For saving, I think there should be a specific dialog to confirm that you want to overwrite the file. I think this should be done so that saves are intentional. So I'm thinking of a dialog for Local Edits that shows all the categories that have been edited in the current map. The user would then select a category and press a button on whether to save the data to the main file or delete the local data.

[AsherGlick]

Something irks me about using GUID to skip paths, idk exactly what yet. Can treat the local_protobins folder as a "recovery" or autosave folder. So if files in that folder exist we ask "do you want to load the previous unsaved markers?" If they click yes we just load those protobins instead of the normal ones? Maybe some sort of filtering still needs to exist for like if you edit one marker pack you might not want other marker packs to be edited (aka reverted) when you load your previously saved marker packs after upgrading a different external pack? Maybe the filtering is on marker category instead of GUID? We could also implement an autosave feature where x seconds after your last change it saves to local_protobins unless there is another change within that time.

[klingbolt]

I found a flaw with using GUID. If they deleted a path or icon, we wouldn't have a way of knowing and the next load would bring it back.

[klingbolt]

Do we want to strongly encourage saving changes? We could have a popup before a new map is loaded saying "You have unsaved changes in old_map_id. Do you want to Save, Discard, or Save Later?" I agree that having some form of autosaving makes sense.

As for what is actually saved, what if we saved per marker pack? So burrito receives a signal that something has been changed and it causes everything in that marker pack to be saved. Then when loading, we can ask if you want to load the unsaved changes first. We could even show this in the tree. That would allow new marker packs to be converted to proto while there is unsaved data. If we go off of the individual category, what happens if you decide to delete that category (adding and deleting categories in the editor isn't a feature yet but seems like a reasonable addition)

root
- marker_pack_1(*)
- marker_pack_2
- marker_pack_3

[AsherGlick]

We dont have any way to prevent a gw2 map for loading ingame, it would be better if we handled whatever was needed in way that the user could continue playing the game without interrupting the user.

Has not given this much more thought then what is written. Think about possible user situations, and choose the least opinionated solution possible that accomplishes the ones you can think of