Currently, I am developing a plugin to assist my coworkers in the development of our project, Creatures of Sonaria, which leverages a recent setup for the game scripts where the game provides registries of data in the form of modules. Many of these registries are static and constant, but will be updated between versions of the game, and the plugin needs to be able to see these changes in realtime due to its use of them.
The plugin right now leverages the existence of these registries to provide more context-aware data on what the game is or isn’t capable of, such as what abilities exist, what status effects exist, etc. To do this, it calls require on the game scripts in places like ReplicatedStorage.
When updating these modules, an issue comes up with the caching behavior of require - updating a registry will not reflect changes to the plugin unless the place or both the module+plugin gets reloaded.
There are a number of workarounds to this, but all of them are less than ideal:
-
Add tracking to which modules are required, manually remind scripters to click the “Reload Module” button in the script editor, and then add a plugin button to re-require all of the modules.
-
Duplicate the modules into the same parent when requiring them, and destroy them after.
By providing plugins with a means to call require “fresh” on a module, these workarounds can be avoided, and the plugin can more naturally interact with the game’s code.
3 Likes
How would your plugin know when to reload? You’d have to dynamically require the dependencies so it runs on each plugin action rather than as a static dependency (e.g. at the top) of your plugin code. There’s no way they can make it dynamically update existing Lua pointers in running code consistently, that one seems off the table.
At that point, there is little lack of elegance to the workaround #2 you mention, you already need to call require again anyway every so often in the implementation. Just add a small wrapper around require that you call in-line rather than statically with the module script. Or write a small wrapper so that you can use an event-based approach to listen for changes (even if your feature request is implemented, you would still want to write this part anyway!)
Not saying the feature request is invalid, but the impact of this is minor due to the workaround #2. It only avoids copying a few objects and writing a few extra lines of code, and even if they have a require that forces a refresh, you likely still want some sort of difference detection mechanism that this request wouldn’t solve on its own.
1 Like
Yeah, that is a fundamental issue with this request. I didn’t mention the largest part of this use case which is in TC sessions, namely where script ownership is employed (and so simple duplication + destruction of the outdated module is not fully possible). I initially was going to, but I am still not sure if that falls into the scope of this request (for example, I think it’d be better to request that modules are reloaded at the same time the Apply Changes button is clicked, assuming that doesn’t happen already. By “reloaded” I mean the same button at the top of the script editor in modules that says “Reload Script”, not this feature request.)