Author Topic: [EVENT] setEventEnabled but better  (Read 735 times)

We have toggleEventEnabled, setEventEnabled, and shiftEventEnabled. The first toggles whether an event is enabled, and the last two set whether a list of events by line is either enabled or disabled, but no matter what, if there's events that trigger more than two options, it always requires ≥2 event lines for each choice, or >n lines of toggling for each n options.

I would like an event where it contains two large spaces for listing events by number, the first field enables all listed, and the second field disabled all listed. Additionally, there would be a check box after which if unchecked, defaults to disable event lines if the line number is present in both fields, and if checked, defaults to enable the line numbers if present in both fields.

That's it. It keeps everything clean and in one line, optimized for when you have more than two choices within the events.

So it's just two setEventsEnabled events but in one line instead?


neato, while looking through the set/toggle code it looks like you can use ALL to toggle/set all events on a brick instead of listing them

So that would be just the text ALL? Also the op is requesting for players to define sets of numbers within the brick since not all of the events need to be enabled or disabled.

Suppose that events 0-15 are support events and events 16-40 are toggled choices. Shifting ALL might very well break the support events.

The fact that we even need this in the first place is a sign that eventing should be revamped blueprint style. Instead of all event routines being forcefully called in order and disabled by eventenabled there should just be a main thread all inputs should just be their own routine block with all the logic instead of line by line so you can disable an entire routine without having to disable each individual line of logic

Right now we got
Ontouch > player > kill
Ontouch > client > centerprint stuff
Ontouch > self > fakekill

And you have to loving enable or deenable each line.
When you could do this

Ontouchtest : ontouch {
    Player.kill
    Client.centerprint
    Self.fakekill
}

And then you could just disable the routine 'ontouchtest' without having to deal with it's innards

Eventenabled is just stuffty spaghetti goto
« Last Edit: May 19, 2019, 04:09:50 PM by PhantOS »

I agree with you there, but asking for a revamped event system is much more than optimization of an existing event.

I agree with you there, but asking for a revamped event system is much more than optimization of an existing event.
the problem is that it's optimizing a stuffty system that is so limited that you need special events just to get around it's limitations

You're entering the realm of control structures in a purely queue based event system that it makes more sense to just redesign the whole system to have a better control structure, like unreal blueprints. Events are a language with no functions or routines much like assembly and the pitfall there is that you need gotos to hack up an actual control structure rather than using a higher level language like cpp
« Last Edit: May 19, 2019, 04:13:46 PM by PhantOS »

Right.... AND I said that we agreed on that point, but I'm just asking for a simple thing that would help optimize things in a small way and I doubt would take very long to put together. Since we agreed, you're wasting your time here derailing a topic now. If you want to set up a rant topic, go for it. Just not here, please.

Edit: I routinely event systems with well over 300 lines of events all put together, so yes, for the last time, a different system would probably be easier, but unless you've heard of anyone making a node-based system for Blockland, I'd prefer to be able to use the systems I know but more optimized.
« Last Edit: May 19, 2019, 05:16:06 PM by SWAT One »

i thought we had torquescript to do more complex things like grouping events together into functions

Suppose that events 0-15 are support events and events 16-40 are toggled choices. Shifting ALL might very well break the support events.
would definitely not recommend using ALL in almost every case possible
it's very rare it'd be useful, but kind of neat it exists

Edit: I routinely event systems with well over 300 lines of events all put together
curious if that's 300 per brick, or total
i normally try to stay under the default 100 per brick quota, but there are definitely times it's useful for it to be higher

300 total. I have one system with >800 events which ran much like a script might for managing slayer teams, where a team leader could have team membership and manage it accordingly. Granted, a script would be more efficient at doing that, but I know what I know and can event it with much more ease.

Right now we got
Ontouch > player > kill
Ontouch > client > centerprint stuff
Ontouch > self > fakekill

And you have to loving enable or deenable each line.
When you could do this

Ontouchtest : ontouch {
    Player.kill
    Client.centerprint
    Self.fakekill
}

There is a style of eventing that somewhat accommodates this method. I almost exclusively event in this way for maximum flexibility. You can use VCE's retroCheck as a kind of pointer to trigger specific lines or batches of lines.
To recreate your example:

Code: [Select]
0 [x][0] onActivate -> Self -> VCE_retroCheck("ifBrickName", "!=", "TRIGGER", "1 3")
1 [x][0] onVariableTrue -> Player -> Kill
2 [x][0] onVariableTrue -> Client -> CenterPrint("stuff", 3)
3 [x][0] onVariableTrue -> Self -> fakeKillBrick("0 0 0", 5)

Obviously, your input for line 0 could be anything you wanted or needed it to be. Then it allows you to just disable/enable that 1 specific line, but disable the subsequent lines.

You can use any VCE logic event instead of retrocheck too
Code: [Select]
0 [x][0] onActivate -> Self -> VCE_ifValue("functionName", "!=", "", "1 3")

What's the point of the checkbox though? There's no point in having an event line in both fields. If you want it enabled, have it in the first only, if you want it disabled, have it in the second only.

having the line in both should be either undefined, or default to the second box, which is disabled
just like current events having an enabling line and then disabling line