Trigger and Scriptobject

[beni]

I figured I'm a bad example for not writing about my work and not even have a post about the triggers and the script object. I also have to admit that they are far from completion, but I'll guess that I can soon deliver something which is usable.

Triggers and the script object are part of the game logic and with them much should be possible. On the other hand they should be easy to use and not be stuffed with functionality which is not needed.

Triggers are object in the 3D environment which react to some event and trigger another event. Such a triggering event could be the player approaching a pirate base with the triggered event of the take off of a couple of pirate fighters to stop the player. It could also be a cut scene or anything else the script object can do.

The script object is at the moment quite limited. Apart from loading another level file and including it into the existing level, there is not much it can do. What it should be able to do is quite interesting. It should be able to access objects in the level and react on or trigger triggers.

Those two objects are therefore basic elements of the game logic and necessary for the mission design.

[beni]

I worked on the triggers the day before yesterday.

I compiled a small list of features:

• A trigger can be activated or deactivated. It is never triggered when deactivated and does not react on anything but its activation.
• Each trigger has a list of children, other triggers.
• A trigger can only be triggered if all its children are triggered in a certain fashion.
• The way the children have to be triggered so their parent is triggered can be set with a trigger mode.
• Trigger modes are AND, OR, XOR, NOT or all children, at least one, exactly one or none have to be triggered.

What's missing right now:

• The triggers do form a tree and there mustn't be any loops. A test or precaution for this has yet to be implemented.
• At the moment the trigger has only an isTriggered function. This is only useful to test if the children of a trigger are triggered, but not to actually trigger an event.
• The trigger does not save its state and does not stay in its triggered state when something in the triggering condition changes. This is yet a design flaw which has to be dealt with immediately.
• I plan two inheriting classes: DelayTrigger and DistanceTrigger. The DelayTrigger has a timer included which delays its triggering for a certain set time. The DistanceTrigger has a target (all NPCs or the player or all players or whatever) and is triggered after the target has approached as close as a given radius.

I'm happy to hear criticism and even happier when there are some helpful hints or suggestions how I can solve problems or tasks.

[x3n]

rigger modes are AND, OR, XOR, NOT or all children, at least one, exactly one or none have to be triggered.

maybe NOT should be an extra option, additionally to the AND, OR and XOR modes (bool invert_ or something similar)

The triggers do form a tree and there mustn't be any loops. A test or precaution for this has yet to be implemented.

I disagree, triggers should definitively be able to form loops. But you're right, you have to detect loops, but this is quite simple: if a trigger checks itself, it returns it's old (or current) state.

I plan two inheriting classes: DelayTrigger and DistanceTrigger. The DelayTrigger has a timer included which delays its triggering for a certain set time. The DistanceTrigger has a target (all NPCs or the player or all players or whatever) and is triggered after the target has approached as close as a given radius.

I'd love to have the delay feature in ALL triggers. This should be a basic feature.
Nevertheless, implementing different triggers will still be needed, but the only thing that differs is the triggering event.
Possible events are:
- an object is within a given zone (~DistanceTrigger)
- an other trigger gets triggered
- an object (maybe within a given zone) is visible (raytracing)
- a special consolecommand (maybe "action" or "activate" or "use" or something else) get's called
- a simple trigger that get's triggered as soon as the level starts (combined with a delay you could trigger 10 minutes after mapstart or so)


I don't know exactly which features are already implemented, but there are some features I'd like to have (some I've already mentioned):
- delay (you'll need something like a queue)
- invert (just return !state)
- switch (each activation changes the triggers state)
- stay triggered (never go back to false again)
- number of possible activations (0 = infinite)

Sounds like much work, but in fact most features are pretty simple. The only tricky thing is the delay. You'll need a really good concept for this, because you can't just put every tick into the queue (think about a 1h delay ). Only statechanges have to be queued. More, your current decisions mustn't rely on the current state but on the queued state.
Good luck

[beni]

New stuff!!

Firstly I created the DistanceTrigger, which does work as intended now.

Additionally the Trigger has now a delay feature. A queue with all the state changes is administered by each trigger for a given delay. This has also shown to be implemented quite correctly. Needs some testing yet, but I'm pretty sure, it is correct.

Further on a Trigger has now an On/Off state and a Triggered/Untriggered state. The trigger changes from On to Off if the Trigger is triggered. Before it changes its On/Off state again it has to be untriggered first.

Also according to x3n's hint. NOT is now to be set separately as a mode.

Trees are now problem anymore. A boolean checks for updating.

To come:
A raytracing trigger has yet to be thought about, however a console command or similar has to be able to trigger a certain trigger as well. Also the simple trigger which triggers itself could be easily implemented in a few days.
Also the feature with the possible activations (or trigger events?) is planned. (stay triggered is just possible activation = 1)

However, I'm in my holidays and the program is fairly dense. So I probably won't get too much time to work on it.

[x3n]

ok, cool

just a quick note:

stay triggered is just possible activation = 1

not exactly:

1 activation: ___|||___...
stay triggered: ___||||||||...
(where _ is 0 and | is 1)

[beni]

I've got to change that quite a lot, still.

As we have 4 states now, the system gets a bit more complicated than before. Especially the tree hierarchy gets more complicated because of updating problems etc.

I'll figure out a solution to this problem soon.

[patrick]

Nice stuff these triggers! Much more advanced than the last one we had