I don't feel 100% competent in answering this, but here's some opinions:
Quote:
Originally Posted by Violet CLM
Should that window have limitations? Should events 1-32 not be allowed, or just show a warning if you try?
|
Well, nothing would be broken permanently. Maybe just a note in the documentation to avoid messing with events 1-32 would be enough.
Quote:
Originally Posted by Violet CLM
What about when the script (or an included library) already overwrites the ini event for a given event ID? Like ///@Event 164=Beams|-|Trigger|Beams? Should you be allowed to try to overwrite the same event ID in both ways?
|
Usually this kind of stuff is handled by order of the code being loaded, right? I imagine it's not going to be a common occurence for two (or more) such libraries to be clashing.
Quote:
Originally Posted by Violet CLM
But under the above model, for multiple objects, you'd see something like:
Code:
void onPlayer(jjPLAYER@ play) {
SlowFeet::onPlayer(play);
Poison::sometimesInjurePlayer(play);
RecolorableSprings::checkYSpeed(play);
MLLE::WeaponHook.processPlayer(play);
}
|
I like this one, even if it's not the cleanest option - it's probably good to have a discrete list of what exactly is going on in the code, step by step.
Quote:
Originally Posted by Violet CLM
On a related note, one idea Faw suggested was not using .asc files for custom objects at all, but embedding all their code in the j2as, so the scriptwriter could easily make any level-specific changes they wanted. But again, that introduces a lot of room for the scriptwriter to make mistakes...
|
.asc files are good in theory (i.e. easy to distribute, just by uploading to J2O), and are good practice for organised releases i.e. HH packs; but also: for singular levels, we've been doing just fine with copy-and-pasting all the relevant code from one j2as to the other. And in this case, resolving event ID clashes as mentioned above would be a lot easier (I guess).
|