Magi Log 'N Load! The Ultimate Save-Load System!

[Adiniz / Imemi]

Money well spent, and ModdieMads has been incredibly kind and professional! The system is insanely fast and efficient, versatile, and keeps surprising me in every way possible. (In a positive way, of course.)

 

[RaMs]

Couldn't load the map, it says this:

 

[moddiemads]

Couldn't load the map, it says this:

View attachment 504284

Ah, my apologies. That's an Action from Extended GUI that somehow slipped by me. Uploaded a new version that should work without it.
Thanks for letting me know!

 

[moddiemads]

Thanks to a bug report, the following fixes were made in v1.02:

• Fixed a bug in the Old Type Id -> New Type Id replacement system
• Fixed a bug when making an empty variable saveable if it would later contain a table.

 

[Bribe]

In your Config file you really don't need to do the MagiLogNLoad prefix nor the do...end block, you can inline your variable set lines all into the creation of the object itself.

I would highly advise annotating your main script with ---@param Emmy Notation, as your variables are otherwise guesswork for readers. The lack of descriptive parameter names it not always helpful in that case either.

Another thing to keep in mind is that it's not always a virtue to have all code in one file. You have over 4000 lines of code in one script, and generally even after several hundred lines you should start asking if something should be de-coupled from the same script, if not far fewer. Getting the utility functions out of there would be a start.

I don't see anywhere in your demo map that you are using the Hashtable API wrappers. But it also needs to be accompanied by Influa (Lua-Infused GUI) to prevent memory leaks with persistent keys when handles are removed from the game.

 

[moddiemads]

Thanks for the feedback!

In your Config file you really don't need to do the MagiLogNLoad prefix nor the do...end block, you can inline your variable set lines all into the creation of the object itself.

It started like that, but once during development there was a need for a table of prefixes/codes to be created by a loop and everything had to be pushed out of the table creation block. That loop was later made unnecessary, but the out-lining remained. The mandatory do...end is a harmless good habit that I don't want to weaken.
It's a little verbose, granted, but also somewhat friendlier to JASS/vJASS/GUI users from what I could gather.

Another thing to keep in mind is that it's not always a virtue to have all code in one file. You have over 4000 lines of code in one script, and generally even after several hundred lines you should start asking if something should be de-coupled from the same script, if not far fewer. Getting the utility functions out of there would be a start.

I agree that monolithic code has fallen out of favor, but I really like the gains in performance and ease of installation that comes with it. Keeping the code all in one file saves me from caching the utility functions locally wherever they are used. I understand where you are coming from (and that many-files-few-lines is the current metagame for programming), but I would ask you to consider the advantages of having as little "bureaucratic" code as possible in a performance-first resource.
I know that the microseconds gains are laughed at these days, but I really feel like they are understimated when present in large numbers.

I don't see anywhere in your demo map that you are using the Hashtable API wrappers. But it also needs to be accompanied by Influa (Lua-Infused GUI) to prevent memory leaks with persistent keys when handles are removed from the game.

They are at the bottom of the InitGUI() function (loc: 3514+).
I noticed the persistent keys and implemented an auto-cleaner for the references (look for the code containing the tabKeyCleaner table) that works in the same 30s interval of Lua's GC.

I would highly advise annotating your main script with ---@param Emmy Notation, as your variables are otherwise guesswork for readers. The lack of descriptive parameter names it not always helpful in that case either.

I was hoping I had made the parameter names more descriptive this time. Will take this into consideration for future updates and resources.
The --@param notation, unfortunately, is the single most dangerous thing one can do to their code in this age of AI gobblers. I fully understand how convenient they are, and I am more than willing to make up for it and clarify/explain anything when asked about it. DM me and it will be no problem.

 

[moddiemads]

Version 1.03 - [BUG FIXES]

• Fixed a bug preventing terrain tiles, upgrades and player resources to be saved correctly.
• Fixed an issue that caused collisions in the log hashes in rare cases.

 

[moddiemads]

Version 1.04 - [BUG FIXES]

• Fixed a bug preventing units that entered and left preplaced transports from being saved when savePreplacedUnits = false.

 

[SoyMante]

I'm leaving the community for a few weeks and when I come back I find this! Lots of potential!

 

[sanuan]

I am using your save system very well.
I had to save my map and use your system.

Thank you, "ModdieMads"

I want see your 'DM' link
But I see that
"You do not have permission to view this page or perform this action."

 

[Pyrogasm]

I want see your 'DM' link
But I see that
"You do not have permission to view this page or perform this action."

Click their name, wait for the small window to show up, then click the red "start conversation" button. You can also create a PM directly and add them as a recipient.

 

[moddiemads]

• CHANGELOG:
• v1.08
• - Added parallel bursting sync streams. Load times can be up to 50x faster.
• - Added filename validation to prevent users from shooting themselves in the foot.
• - Added internal state monitoring capabilities to the system. Errors should be much easier to track.
• - Added the option for the map-maker to set a time limit for loading and syncing. The loading will fail in case it's exceeded.
• - Added progress prints for file loading. They should show up at 25, 50 and 75% loading progress.
• - Changed the default behavior for MagiLogNLoad.WillSaveThis. Ommitting the second argument will default to <true>.
• - Fixed a possible jamming desync when multiple players are syncing at the same time.
• - Fixed a bug involving some weird Blizzard functions, like SetUnitColor.
• - Fixed a bug involving unit groups that could cause saves to fail.
• - Fixed a bug involving proxied tables that could cause saves to fail.
• - Fixed a bug causing real variables to sometimes save as 10x their normal value.
• - Fixed a bug causing research/upgrade entries to sometimes not load correctly.

 

[moddiemads]

• CHANGELOG:
• 1.09
• - Fixed a bunch of linting bugs thanks to @Tomotz.
• - Fixed a bug preventing huge reals from being saved correctly. S2R and R2S appear to still be faulty.

 

[Tomotz]

Working well (and also magi is great and helping me with all the custom stuff I'm trying to do with it)

 

[Antares]

Ctrl F ";" Ctrl H ""

--Documentation has been kept to a minimum following feedback from @Wrda and @Antares.

I am confused as to how that is what you took away from our conversations.

The algorithms used here are beyond my understanding and I'm not a madlad like @Wrda who likes to turn over every line twice, so I can't comment much about them.

What I noticed:

• The deaths of preplaced units are not recorded, while those of units created later are. Is this intended, the result of some config option, or a bug?
• The strings in the config are not explained. You should write that these are reroutes to the GUI variables and you can just replace them with a value.
• A short explanation of the MAX_ config options would be nice.
• The system is producing a lot of print messages and even prints those for the players who are not doing the loading. Ideally, I think, these messages should be part of some onLoad callback function that can be customized in the config.

• transp = nil;
  u = nil;

  This is not JASS, my guy .

 

[Wrda]

Spoiler: Sacrilegious

WHY TEST MAP NO WORK AND WHY IT ISN'T SET TO 2 PLAYERS AT LEAST????? IT'S A SAVE LOAD SYSTEM WITH PURPOSE OF MULTIPLAYER NERDING

MagiLogNLoad = {configVersion = 1080};

What is the configVersion member for?
I find it a bit unintuitive that MagiLogNLoad.Init() is initializing with GUI support, but initializing without it requires to pass arguments.
That being said, I tested the system with Antares, so part of what he said is also what I think.
The system looks to be flawlessly with a single caveat, whether it is intended or not (Antares #1 point).

The algorithms used here are beyond my understanding and I'm not a madlad like @Wrda who likes to turn over every line twice, so I can't comment much about them.

Give me my 1 hour of life back!

 

[moddiemads]

Thanks for the feedback!

--Documentation has been kept to a minimum following feedback from @Wrda and @Antares.

I am confused as to how that is what you took away from our conversations.

I thought that there was a call for reducing the ramblings and keep it as focused as possible. I have to say, I kinda like the terseness of the docs more now.
-

• The deaths of preplaced units are not recorded, while those of units created later are. Is this intended, the result of some config option, or a bug?

This was very much intended, however at some point I added the option for them to be saved, but that was not working very intuitively.
Issue fixed! There is now a way to instruct the system to save the death/removal of pre-placed units (please check the changelog)
-

• The strings in the config are not explained. You should write that these are reroutes to the GUI variables and you can just replace them with a value,

This tidbit has been added to the documentation, and a few lines were added to clarify any possible confusion.
-

• A short explanation of the MAX_ config options would be nice.

Short explanations added.
-

• The system is producing a lot of print messages and even prints those for the players who are not doing the loading. Ideally, I think, these messages should be part of some onLoad callback function that can be customized in the config.

This was always in the plans, and now it's a reality. Please refer to the changelog for more details.
-

• transp = nil;
  u = nil;

  This is not JASS, my guy .

Indeed. These nil assignments were a "what-if"-decision that I could not find a verdict on. Those have been removed now.
-

What is the configVersion member for?

This is used for "customer support". It's not so rare for someone to update just the MagiLogNLoad script and forget about the MLNL_Config script. This allows me to quick diagnose the problem. In any case, I am now also using it to check on Init() if the MLNL_Config file is present.
-

I find it a bit unintuitive that MagiLogNLoad.Init() is initializing with GUI support, but initializing without it requires to pass arguments.

I was gnawing at that decision for a while during development, but I stand by it.
It's much easier for a Lua map-maker to provide additional arguments to functions than a GUI map-maker. It also helps that Lua devs have a much easier time understanding code and reading the docs than GUI, so yielding the defaults to GUI is probably the more productive path.
-

The system looks to be flawlessly with a single caveat, whether it is intended or not (Antares #1 point).

Give me my 1 hour of life back!

Thank you very much for the compliment!
Indeed, this caveat has been fixed, and there's now an option to save the death/removal of pre-placed units. Please refer to the changelog. Also, excellent time on evaluating this system. It takes me one hour just to bring myself back to speed on it, and I'm the freaking author!

 

[moddiemads]

CHANGELOG
1.10
* [FEATURE] MagiLogNLoad can now unload units from transports seamlessly when loading a save-file.
Maps using this system require the custom ability 'AUNL' (customized 'Adri').
Please refer to the provided test map and the MLNL_Config file.

* [BREAKING] MagiLogNLoad.CreatePlayerSaveFile has replaced MagiLogNLoad.SaveLocalPlayer.
YOU MUST UPDATE ALL YOUR <MagiLogNLoad.SaveLocalPlayer FUNCTION CALLS.
It's now sync while updating references, then it becomes async when saving the actual file.

* [BREAKING] Mode <savePreplacedUnits> has been renamed to <savePreplacedUnitsOfPlayer>
GUI config string has been changed to SAVE_PREPLACED_UNITS_OF_PLAYER. Please update your triggers.
Functionality unchanged.

* [BREAKING] Mode <saveAllUnitsOfPlayer> has been renamed to <saveNewUnitsOfPlayer>.
GUI config string has been changed to SAVE_NEW_UNITS_OF_PLAYER. Please update your triggers.
Enabling this will only saved units that have been created at runtime.

* [BREAKING] Mode <saveDestrsKilledByUnits> has been renamed to <saveDestroyedPreplacedDestrs>.
GUI config string has been changed to SAVE_DESTROYED_PREPLACED_DESTRS. Please update your triggers.
Functionality unchanged.

* [BREAKING] MagiLogNLoad.ALL_CARGO_ABILS has been replaced by MagiLogNLoad.ALL_TRANSP_ABILS
It now contains 2 arrays: CARGO, with all <Cargo Hold abils in the map; and LOAD, with all <Load abils in the map.
All units are assumed to have just one abil of each category.

* Added the mode <saveDestroyedPreplacedUnits>.
Save ALL destroyed pre-placed units as long as a logging player is defined when the destruction happens.

* Added a way to change the commands "-save" and "-load" to arbitrary strings in the config file.
* At the request of @Antares, added the following callback functions to ease integration and message editing:
MagiLogNLoad.onSaveStarted
MagiLogNLoad.onSaveFinished
MagiLogNLoad.onLoadStarted
MagiLogNLoad.onLoadFinished
MagiLogNLoad.onSyncProgressCheckpoint
MagiLogNLoad.onAlreadyLoadedWarning
MagiLogNLoad.onMaxLoadsError

 

[Antares]

The save preplaced units does not seem to work.