Events Replacement - How would you prefer?

[M]

Okay, it's hard to explain what I'm on about with such limited space as the topic title, so I apologize for the ambiguity there.

I've been thinking recently (as have several other people) about making a replacement system for Wrench Events, at least clientside (though it would probably be much easier to replace the whole serverside system as well rather than try to make a different system generate compatible output).


So I'm pitching a question to you, the eventers around: How would you prefer a replacement system to work? Something like the current system but with extra features such as integrated logic and variables? A more free-form, textual editor (this would be basically requiring you to learn to script, in some ways)? Flowgraphs? (This third option is ludicrously unworkable GUI-wise. The system of each element plugging into another wouldn't be too hard, but making it look good would be hrrlbrblr.)

It's just that the dropdowns, once you get a fair few items in them, can take quite a while to navigate. That and the system is quite non-extensible; there's a perfectly serviceable clientside GUI that could support us without needing any extra code, but serverside we can't tell clients when to use it, so we can't do anything with it. (for instance pushing the events dialog to show inputs for Minigames; brick hack workarounds to use minigame events are a stuff way to do it and they clutter the dropdowns even further)


Another thought, for you modders out there, who may have published an event or two in the past; would you move over to a new system? Compatibility between the two would be nice, but it's often a lot of work to give an inferior experience to stubborn or uninformed cretins as opposed to simply ordering them out the door like any well-to-do establishment should. But a new system having support from more modders is basically a must; if it has no content, it will also have no users.


Badspot, if you read this; would you ever consider accepting a community-made events GUI replacement that adds value to the current arrangement? Or at the very least adding a clientCmd to push the events dialog with inputs for whatever class name? Rejiggering it to do what you want without remaking the entire thing is a load of work when you could basically do it in five minutes, notably with the new revision system.
Ideally, we'd be able to quite simply push the events dialog to a client with a given classname and automatically send the events from an object (passing a string for the classname or an object, which would then use its class for the input list and send its events over - after all, the event system is pretty much universally available)


So I pose these questions to you all, hoping for coherent answers. Somehow I feel already disappointed, for my question isn't all that coherent itself. I should probably sleep or something. Wabbajack.

[Ad Bot]

[Cajetan]

This is false forum, mai boi. Your post goes to Suggestions & Requests.

Also:
Would be nice, but still (in my opinion) not willing me to change to this new system. i prefer the classic old one that we still use.

[Lugnut]

I would like to have this new system parallel to the old one, where its a click of a button (or two) to switch between the two

[M]

I would like to have this new system parallel to the old one, where its a click of a button (or two) to switch between the two

Would probably be a lot of work, and if the system were any good this wouldn't be needed. Ideally it wouldn't stray too far beyond what's known, but some people might want it to.

This is false forum, mai boi. Your post goes to Suggestions & Requests.

Also:
Would be nice, but still (in my opinion) not willing me to change to this new system. i prefer the classic old one that we still use.

Discussion of potential things goes in GD, not suggestions, since I'm asking about interest in something like this as opposed to asking someone to make it.

[Munkey]

I would love it to be a small text editor, it would make everything go extremely faster for me.

[Colten]

Current system is extremely tedious, I wish there was a way to set, say, an onactivate that affected multiple bricks so instead of:

Code: [Select]

onActivate -> pixel1 -> setColor -> red
onActivate -> pixel2 -> setColor -> red
onActivate -> pixel3 -> setColor -> red
onActivate -> pixel4 -> setColor -> red
I could just do something like

onActivate -> pixel1, pixel2, pixel3, pixel4 -> setColor -> red

I dont care how I get it to that, weather it be using the default way or one of the ways you suggested but itd be a nice feature. Out of your suggestions Id suggest some sort of coding-esque way of writing out events, maybe like

Code: [Select]

onActivate
    pixel1
    pixel2
    pixel3
    pixel4
        setColor
            red
or maybe a more efficient way.

[Munkey]

Code: [Select]

onActivate
    pixel1
    pixel2
    pixel3
    pixel4
        setColor
            red

This would be great, also.

[Chrono]

Code: [Select]

onProjectileHit: swordProjectile
self
disappear: [10]
b: trigger1 &
b: trigger2 &
b: trigger3
fakeKillBrick: [0 0 0] [10]
client
centerPrint: ["You have opened the door by cutting the rope."] [5]
Now we just need room for delays! :)

[Pentium]

You mean like a scripting language as an alternative for the eventing system? Yes please.

[otto-san]

Code: [Select]

onProjectileHit: swordProjectile
self
disappear: [10]
b: trigger1 &
b: trigger2 &
b: trigger3
fakeKillBrick: [0 0 0] [10]
client
centerPrint: ["You have opened the door by cutting the rope."] [5]
Now we just need room for delays! :)

I would love that.

[Lugnut]

If its a scripting language, I would really prefer it was external.
I have poor fps, and any typing is difficult ingame, as it takes time for the game to register that I typed.

[Chrono]

If its a scripting language, I would really prefer it was external.
I have poor fps, and any typing is difficult ingame, as it takes time for the game to register that I typed.

If typing is a problem then you should probably hold off playing till you get a better computer.

[Lugnut]

In actuality, the game runs fine, I just get poor fps on laggy servers.
I also don't have a problem with ingame chat, the problem is with the events gui.

[M]

How it could be done without it being RIDICULOUSLY different from the current system and/or RIDICULOUSLY hard to make: event scopes.

A scope would be an input or a logic clause. A 'container' for outputs (some of these outputs can just be more scopes with attached logic).
So say you have

Code: [Select]

onActivate
+ if client.bl_id == 4332
  + player -> kill
+ client -> centerprint("nothing important",2)that makes two scopes - scope 0 is for onActivate then scope 1 is for that logic clause. When you process the onActivate scope it has a little reference in its first slot saying to look at scope 1. The code then looks at scope 1, sees it has logic attached, checks to see if that logic works out and if it does, it will then schedule that scope to be processed after this one is done. Then it continues. Delays could also be attached to scopes, for instance "in 1000ms" or "in 5s" or "in 2m" as opposed to or possibly in addition to an if statement (in 100ms if client.bl_id == 4332 || player.health < 50%; delay would have to come first since it's only one piece to it)

We then add the integrated things to set variables, and allow inserting of variable references into any field.

When adding events you'd still have dropdowns containing everything (though when you click the dropdown, typing would filter it, pretty sure that's possible by focusing a textbox, and when you select from the menu it inserts your selection, or if you hit enter it inserts the first option. if you click off it it cancels)

[Lugnut]

I dunno. I'm liking Chrono's example about halfway up the page.

(though when you click the dropdown, typing would filter it, pretty sure that's possible by focusing a textbox, and when you select from the menu it inserts your selection, or if you hit enter it inserts the first option. if you click off it it cancels)

this is looking really attractive, even if nothing else changes.