Author Topic: Event system should be reworked.  (Read 2316 times)

I've been saying this for years and I've just been ignored :/

edit: Here, I'll just paste my original OP here.



Wait what
How did you make the window transparent.

Wait what
How did you make the window transparent.
He didn't.
Truce made that image.
In loving 2009.

That image is from Truce's topic which I linked to in that post.

http://forum.blockland.us/index.php?topic=94935.0

I think the simplest change that would help the most is GUI-side: one input event can have many output events.

It seems players get flustered when they see this mess of inputs and outputs, and have a hard time sorting out what's logically happening.  Let's look at a door:

Code: [Select]
[x] onActivate > Self > doorOpen
[x] onActivate > Self > playSound > dooropen.wav
[ ] onActivate > Self > doorClose
[ ] onActivate > Self > playSound > doorclose.wav
[X] onActivate > Self > toggleEventEnabled > 0 1 2 3

What we've really got is toggleEventEnabled as a ghetto way of grouping functions.  If we start thinking of it as functions, and we start thinking of the input events as function calls, it'd make more sense to have it laid out like this:

Code: [Select]
[x] onActivate
     Self > doorOpen
     Self > playSound > dooropen.wav
     toggleInputEnabled > 0 1

[ ] onActivate
     Self > doorClose
     Self > playSound > doorclose.wav
     toggleInputEnabled > 0 1

That would be awesome. Actually DrenDran's event GUI might do that.

What would be even nicer is a sort of purely client-sided "event IDE" which behaves like the above and lets you save things, then before sending them off to the server, it would compile them into the traditional event format.

What would be even nicer is a sort of purely client-sided "event IDE" which behaves like the above and lets you save things, then before sending them off to the server, it would compile them into the traditional event format.
sounds amazing
who would actually do it

sounds amazing
who would actually do it

It wouldn't be that hard and I would do it if I didn't already have a million projects.

That image is from Truce's topic which I linked to in that post.

http://forum.blockland.us/index.php?topic=94935.0
I don't care how do I do it

No idea.

Does anybody have any suggestions for the OP? Additional things that need to be changed?

What would be even nicer is a sort of purely client-sided "event IDE" which behaves like the above and lets you save things, then before sending them off to the server, it would compile them into the traditional event format.
It wouldn't be that hard and I would do it if I didn't already have a million projects.
True, but challenging part would be decompiling events so they are easily editable in this event IDE.

Also I like multiple output per input idea.

We could also make branched events, for example if-else. This would go well with VCE-like variable system which could be build in right into BL (don't see reason why). Then, we could do something like that:

Code: [Select]
if ([playerScore] > 15)
    |
    |----OnActivate >> self >> door >> Toggle
else
    |
    |----OnActivate >> Client >> CenterPrint("You must have more than 15 points to open this door!")
endif

You'd need to put endif at end of statement to make it work properly (it'd still work if if statement is at the end of your event code, as it would close it automatically, but it'd tread all subsequent event calls as part of else/if in case statement doesn't have else part, so it's better to close it off).
System variables (score, BL_ID, etc.) would be enclosed in square brackets.

bump. Also your quote is messed up ^.

What about an event implementation system? Sometimes, I have, say, 50 lines of vce, but then I realized I needed to implement an entirely new line between 30-31, and in order to do that, I literally have to do the whole thing again.

Yes. Events should be reworked like this.

It wouldn't be that hard and I would do it if I didn't already have a million projects.
Greek, I'm not kidding at all when I say I'll pay you if you do this.