[shadowfyr]

There is an irony in that. The whole point of a non-shared variable space, or more specifically plugins, in the first place was to "prevent" interference between different sections of code, which might be using the same variables, for one reason or other. You can end up with a lot of problems when that happens. It does create some complications when passing data between different scripts, but there are methods to do it, and they are like most applications, in that they are "specific" to implementation, not just, "Through it all in the same basket and don't worry about what happens." We used to have code run in a single space, as one language, just in the master script, but, due to how it worked, it was a) hard to add to, b) could clobber existing variables, and c) if injected via a trigger or such, existed only temporarily in the code space, while executing, unless you created a function to call (it was these temporary injections that caused errors in data, since someone throwing together a scrap of code might use 'count' for something, only someone's script, added in earlier to the main file, also used it, and thus the injected code would screw up what ever the master script was trying to track.

In short, we concluded that this was actually a "disadvantage", and suggested strongly that it shouldn't happen. The only real drawback is that you then have to treat your scripts are "actual" separate code, and create a function to a) register compatible plugins with each other, b) process data passed between them, into the correct data space for the plugin that needs it. Hardly a huge problem, though perhaps initially complicated, since there is no "standard" code to do those things. The biggest issue has been load order, where if the plugin that needs to load last doesn't, it can lose track of what is loaded or not. But, the solution has been to simply have it ask on connect, or some other condition, where all plugins "must" have been loaded already. Though.. I think I might have an idea on that...