-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mod Destructors "modTable" is Nil #104
Comments
Question: Unfortunately the lack of modTable in the destructor means that the state which I set up in the Initialization section's modTable cannot be torn down in the Destructor. I basically need to clean up certain things whenever the mod is manually (or automatically based on load conditions) disabled, because the plate mod I'm working on has to hook into and overwrite code of another addon, and then restore it when the mod is disabled. That state is all stored in the modTable. For now, I guess I'll use a _G global table as a workaround for persistent storage. That workaround actually also solves the other issue I was having, which is that the Is there any official way to have a "persistent" state between mod enable/disables in Plater, or any official "teardown" function (the opposite of Initialization)? |
I will look into this. |
Please test against the next alpha version. |
Thank you so much for fixing this bug. I have tested it now, and can confirm that the modTable with its contents is now available in the destructor, so that I can do stuff like "call existing modtable functions to destruct the nameplates" instead of having to duplicate code manually. I noticed 1 Before: Every time you change ANY script in a mod and press Save, the Initializer runs and the modtable is re-created. It also used to run on ANY option change in the Options panel for a mod, and also ran incessantly (way too much in my opinion) when someone was sliding settings-sliders in the Options. After the Destructor modTable commit: Initializer only runs when you enable/disable the mod. The re-save/option change scenarios no longer trigger the Initialization script. This may have been unintentional? I assume the reason the initializer used to re-run every time you saved the script, would be so that the modTable would be constantly re-created with new code while someone develops a mod. The full docs of how Initializer used to behave in the past, was documented by me in my mod, as follows:
What I can see, now Initializer only runs when the user first runs/unloads/re-loads the mods. When saving changes to code, the CONSTRUCTORS still run for all visible plates. It's just the Initializer that no longer runs. So yeah it does seem like the refactoring introduced an initializer bug? |
The behavior change seems to be related to the "hot reload" idea, which apparently recompiles ALL scripts but doesn't wipe the modTable and doesn't re-run the initializer. Is that how it behaves now? I would suggest a different approach in that case:
I do in general like the idea of a persistent modTable between script reloads. It removes the need to store Edit: I've verified this "hot reload" behavior now by making "nameplate added" script print "haha" and then the It printed the exact same HideIcon function reference, but Haha2 now instead. Which means that scripts were recompiled but modTable was kept. So yeah that is a major change, and I like it, it's just very confusing right now. I'd probably think that Initializer should still run, but the mod author can then take the decision to overwrite certain data or not. Otherwise it makes three things very difficult:
|
This is unintentional and should be fixed in the next alpha. |
@cont1nuity Alright, perfect, glad to hear it :) And glad I helped testing! I've edited my comments here quite a bit, so please check if you saw the latest info/ideas for how to solve this. |
|
Ah, okay! Yeah the old behavior was fine. I am downloading your latest commit now to test the change. Is that the entire fix or are more commits needed?
Oh, hmm, nah, I write to The way to fix that, if I remember correctly, is to create a fake Anyway, glad to hear that setting globals to keep persistent values between reloads is a reasonable approach. I'll be keeping 1 global variable where I store the hook state (since I can't be sure |
Testing the latest commit now, c6c88ee
Summing it up:
I cannot see any issues, after quite thorough testing. |
This is intended, it works with the actual Thank you for testing and the reports. |
@cont1nuity Alright, thanks a lot for these great improvements! Really love how much these new changes will clean up my mod. One last question. What is the access limit of |
Certain functions and tables cannot be accessed. |
Gotcha. Thanks a lot for everything. :) |
Game and Plater version
Describe the bug
Plater doesn't pass
modTable
to mod destructors. It passes nil instead. All other values work properly (envTable, unitFrame, etc).The Plater template for Destructors literally includes modTable in the template function definition, so I assume this is a bug.
I've tested all of this with a totally blank, "New Mod", to verify that it indeed always sends a
nil
value.The text was updated successfully, but these errors were encountered: