Event Input Options: Repost

[Space Guy]

I posted this a while back, some people were interested in it then the topic died for no reason. I think it'd be very useful to event makers to avoid having to use hacks like "ifProjectile" with all the abuse Variable Events is open to.

One problem I have with the system is that that no input events have "Options" you can set: If I wanted to be able to detect when a specific kind of projectile (and no other) hit my reciever, I'd have to write code for these events:

onProjectileHit (generally)
onGunBulletHit
onAkimboBulletHit
onRocketHit
onTankShellHit
onArrowHit
....
onRadioWaveHit
onPongBallHit
onPinballHit
...

Would it be possible to extend or change the system so you could select one or possibly two options for an input event? There is already enough space on the menu for an extra selector box for the "<NAMED BRICK>" target, so a text box or selector might fit in the same space for choosing the input. I imagine it would look something like this:

[Ad Bot]

[M]

This should be part of the base events system, definitely.

But what would you end up using for the input event arguments?

Code: [Select]

RegisterInputEvent(fxDTSbrick,"onProjectileHit","Self fxDTSbrick\tPlayer Player\tClient GameConnection\tMinigame MiniGame","{datablock projectiledata} == {Projectile getDatablock()}");If you're not quite getting that:

Code: [Select]

RegisterInputEvent(classname, input, targetlist, arguments);Where the arguments are formatted as:
{selectable value} logic {comparison value} TAB {selectable value} logic {comparison value}

Selectable value is something like an output event parameter, possibly within those, comma-separate for certain things. The comparison value is {input trigger object SPC method or value}.

Another thought would be that if you wanted configurable logic, you would use
{selectable value} {logic list} {comparison value}
ie;

Code: [Select]

RegisterInputEvent(fxDTSbrick,"onProjectileHit","Self fxDTSbrick\tPlayer Player\tClient GameConnection\tMinigame MiniGame","{datablock projectiledata} {== !=} {Projectile getDatablock()}");A list of possible logic comparisons, selectable by the user.
Another example:

Code: [Select]

RegisterInputEvent(fxDTSbrick,"onActivate","Self fxDTSbrick\tPlayer Player\tClient GameConnection\tMinigame MiniGame","{int 0 3} {== != > < >= <=} {Self getTrustLevel(Player)}");That should be fairly obvious (albeit that I don't remember if fxDTSbrick::getTrustLevel(%obj) is valid).

Also, input trigger objects - like $InputTarget_["targetname"], you use $InputTrigger_["triggername"] - in this instance, $InputTrigger_["Projectile"] is the projectile that hit the brick. Assumedly one would also (in good practice) set $InputTriggers for the four targets as well - or perhaps simply use $InputTarget values instead of another set.

I dunno, it all seems like a decent idea in my mind, but things come out wrong all the time.

Note: After rereading that, I'll leave it there, but add this - the arguments in that way might be a bit too restricted. Perhaps an open format would be possible, with support for and/or systems and the like, but that might be a little... over the top, to say the least.

[Space Guy]

A simpler method might be this:

Code: [Select]

registerInputEvent("fxDTSBrick", "onProjectileHit",
                                     "Self fxDTSBrick" TAB
                                     "Player Player" TAB
                                     "Projectile Projectile" TAB
                                     "Client GameConnection" TAB
                                     "MiniGame MiniGame",
                                 "datablock ProjectileData");

Code: [Select]

function fxDTSBrick::onProjectileHit(%obj,%projectile,%client)
{
   ...
   %obj.processInputEvent("onProjectileHit", %projectile.dataBlock, %client);
}When you register it, you specify a type it should be, then when it's triggered you put in the value it should check that against. In this case it checks a projectiledata against the one that hits its' datablock.

Not many types of fields would fit in that space, the most you could do is two boolean or integer fields - the rest would end up being too long.

[Technoscubed]

Do want. This sounds epic.

[Space Guy]

Yeah. I think that this is possible but I'd prefer it to be a default Blockland feature - then everyone can take advantage of it rather than hacking the events GUI so it breaks next version...

[Melting Plastic]

This would be sweet. Another addition would be to have a wrench events dialog in the minigame window for processing global game-play parameters and such.

[Space Guy]

Yeah, I thought of that a while back. Events like "onMinigameReset", "onPlayerDeath", etc. would help a lot for making special games.

[funinabox]

Bump. Make this possible :C

[Bob777]

DANG YES!

[XenocideII]

No,just no.

[Jaydee]

No,just no.

Yes. You = No.

[Isjix]

No,just no.

There is something wrong with you.

Anyways this looks very useful.