Something that stands out to me is the scope of this feature. It looks like the problem it's addressing is something I've been pondering before -- for the longest time we've been facing an issue where people would like external code to work automagically, without requiring users to understand AngelScript at all, not to mention how to incorporate a particular, likely undocumented library into their script. Every time the main issue is the same: JJ2+ does not provide tools to register multiple hooks of the same type from a single source. I've been thinking about solving this by allowing scripts to run new script modules with a
#pragma, or adding built-in hook collections, or, reluctantly, allowing hook registration through metadata. I consider code generation something of a last resort, but of course it also works. The parametrization through a UI is, naturally, invaluable either way, so some support from MLLE would've been required regardless.
So my perception is that, at its core, this feature is about configuring and running "modules" -- independent external snippets of code that can hook into any aspect of the game. This raises a question: why (attempt to) scope it to objects?
My latest single player level, Transantarctic Mountains, features multiple scripted events. Besides custom objects, I also used modified Hurt events, as well as the following curiosity:
Code:
///@Event 254=Delet This |-|Modifier |NOT |v
void deleteUnwantedEvents() {
int width = jjLayerWidth[4];
int height = jjLayerHeight[4] - 1;
for (int i = 0; i < height; i++) {
for (int j = 0; j < width; j++) {
int event = jjEventGet(j, i);
if (event == 254)
jjParameterSet(j, i + 1, -12, 32, 0);
}
}
}
void onLevelLoad() {
deleteUnwantedEvents();
}
This code makes it so that any event placed directly under the custom event 254 gets permanently deleted at the start of the level. Sounds silly, but by selecting the difficulty of this event, I can achieve much better control over what objects to spawn at what difficulty. In particular, easy and hard modes can now delete events rather than only add them, removing a notorious limitation of vanilla JJ2. During HH24 development, as I shared this snippet, FawFuL commented he wished this was a built-in feature in MLLE, and brought up a discussion he had with you -- presumably the same that inspired this thread.
As far as I can tell, the proposed feature would support this event perfectly well as it stands, despite the fact that it is most certainly not an object. It would also support the custom Hurt events and various other custom events falling firmly into the categories of "areas" or "modifiers" that don't actually produce any objects. This alone doesn't really provoke design changes -- it's a good thing that the design allows for this -- but it does make the naming seem silly. People will most likely use the feature for this purpose if they realize they can.
It doesn't stop there though. It seems entirely reasonable that someone may want to import a script that defines no events at all, but rather modifies the game more globally. Perhaps to give the level toroidal topology like in Hyperspace, or a complex weather condition like in Under The Weather, or even to do something super simple that doesn't take that much code but is just preferable for them to do with a UI. Now the design of the feature remains technically suitable but at the same time begins clearly getting in the way. I don't actually need to overwrite an event for this, but I'm forced to, and presumably MLLE helpfully prevents me from recycling event IDs, so I'm limited in terms of how many of these modules I can actually import, and my event list is filling up with dummy entries. These drawbacks seem like they wouldn't be enough to actually discourage this kind of use, merely make it a little annoying.
What this suggests to me is that this system is much too powerful and potentially useful to be limited to objects by design. You mention that scripts may want to use the API to define multiple objects (really events) at once, and I claim that they may also want to define none, so I wonder if it would be beneficial to do away with this default of exactly one, or even the assumption that defining events is the objective of the system, rather than just one of things it can do.