New saving system idea

[HitCoder]

when it comes to save formats, everyone is pushing towards EGM, completely understandably. However, issues addressed are that you have to save the entire project when you want to apply changes to the project file. Now, another issue people have is program crashes and loss of data- this happens on every piece of software from time to time.

I have an idea for the ideal (or at least ideal in my opinion) saving system;
It should be like Visual Studio structurally: Save the sprites in a sprites folder, etc.. all in a project folder.
Every time a script is edited, as soon as the green tick button is clicked it should save that particular file.
Now, in place of the old save button, we should have an "archive backup" button, which saves to a .EGM file (or something).
Say, you had a project you were working on and were happy of the beta state, you click "archive backup". Then you make changes, break something, and you can revert whatever it is you changed.
Now, in place of save as should be either a "compress version" button, or leave it as "save as" but save the project in a new directory.

When opening a project, opening an egm file should behave as it currently does, and do open the branching folder type should be an index file. Maybe an extension like .EPL (Enigma Project Loader)

Just an idea, tell me what you think, not sure how anyone would go about making this but I'm sure it's possible. I might go ahead and do this in the IDE I am going to start making for Enigma in the next 2 years (yes, I know it's a long time but I start college in September, I only have personal experience with Visual Studio, so if I start now I'll have to rush back and polish things up).

If you read this all the way through, thank you for your time, and I hope I didn't just make you feel like you wasted it.

Thank you all

[TheExDeus]

This has been discussed and proposed before. Basically an extracted EGM (called EGX probably) which would be GMX counterpart from GameMaker. There are is basically one issue to fix: Make room data non-binary.
After that it's the ball in LGM territory to make the loading and saving. I have pushed for this for more than a year now, as I have projects that use ENIGMA on GIT and I cannot version properly without an extracted format. I am willing to pay money for this if people actually implement this in LGM. I can make a writer/loader in C++ if needed (the CLI part).

I personally think this shouldn't be that complicated as we already have EGM format - which is a zipped file structure. EGX is the same thing without zipping. It means making EGX would require deleting parts of EGM saving/loading code and virtually no additions.

[Goombert]

Your thinking is actually correct HitCoder, this is what GMX and EGM are both designed to be like. It's just a huge task as TheExDeus explains and LGM was designed around GM8 and earlier formats. It also can make compilation faster by having a CLI load the resources not loaded in the IDE directly from the disk (though as I've explained before, it's still quicker to pass them through memory/RAM if they are already loaded in the IDE).

I have started a 16b5 branch recently for LGM, it is intended to be the stable branch.
https://github.com/IsmAvatar/LateralGM/tree/16b5

After considering concerns of people like TheExDeus, I've decided to retroactively develop 16b5 with the help of Rusky and Josh. They are manually reviewing each and every commit. According to this branch, GM: Studio does not exist and GM8.1 is the holy grail. I am only pulling in solid fixes from any of the releases I've made, with fixes from sorlok and egofree and others. From now on, master branch is going to be considered experimental and eventually the stable branch may replace master. You will not see a million commits from me like "cleanup, cleanup, cleanup cleanup" with 2000 changes that you can't read through. I am isolating each issue and solving them independently. I am also following the style guide of LateralGM and paying careful attention to whitespace and other formatting concerns including marking of non localized strings.

Hopefully, we will have a more stable LGM project soon.