Trigger Internal Structure

[Eddy-B]

Since wiki is still offline, i'm posting this here.

I've been hacking my way into the outpost triggering system, hoping to find a way to circumvent the victory/failure triggers altogether.
Reason for this is that i found that the triggers are very slow and the events system that i've created runs much smoother, with a significant overall speed increase to outpost 2. I have 1 mission with 2 dozen failure and victory conditions. After changing most of the triggers into events, i found myself running somewhat faster. When i removed ALL triggers, it was running at top-speed again. Since a VictoryTrigger/FailureTrigger needs another Trigger as its param, creating 10 victory and/or failure conditions introduces 20 triggers.

One thing i found, was that each and every game cycle, the system checks ALL triggers, JUST to find the VictoryTrigger entry in a FIXED list, that's always the same, no matter what mission DLL you load. Then after doing that, it browses AGAIN through the whole triggers list, this time to find the FailureTrigger entry. Quite useless, i'd say.

I'm still working on it at this moment, and will paste the results here as soon as i have them. I am updating the DataStructure file Hooman made for the Triggers to include the new findings.

-------------

All Triggers are descendents of _Trigger, which is again a descendent of ScStub as we know already. The triggers are:

0   _Trigger

1   TimeTrigger
2   ResourceTrigger
3   ResearchTrigger
4   OnePlayerLefttrigger
5   RectTrigger
6   PointTrigger
7   SetTrigger
8   AttackedTrigger
9   DamagedTrigger
A   EscapeTrigger
B   CountTrigger
C   KitTrigger
D   EvacTrigger
E   MidasTrigger
F   BuildingCountTrigger
10   VehicleCountTrigger
11   SpecialTargetTrigger
12   OperationalTrigger
13   VictoryCondition
14   FailureCondition

[Eddy-B]

The first user-Trigger has ID 5.

ScStubs 0 upto 4 do exist: they are system ScStubs with their vtable located at 004CFF00.
The routine creating those stubs is MissionInit, located at 00402F20 (calling 00402F80).

... working on it ...

[Hooman]

Hmm, nice work. Is there a significance to your numbering?

Btw, when I took a peak, a lot of things are only handled every 4 game cycles. I remember checking for triggers firing was one of those things. Is this a seperate check that gets done every cycle? Or it is that same check done every 4 cycles?
 

[Eddy-B]

i didn't check how many times it handles. It prolly does every 4 cycles.
About the numbering: those trigger names are actual strings in the outpost2 code. The numbers refer to the trigger classes. They've put them in a nice little array.
The VictoryCondition is ALWAYS positioned at number 0x13 within this array, no matter what you do. So it's pretty useless -ur not gonna believe this- to go thru the whole array, and checking the string name of each trigger type in that array, until it finds "VictoryCondition".

It does this lookup every time it goes thru the victory conditions. Same goes for the failure conditions. Failure conditioned are handled much faster though, since they do not have to update the objectives list etc. If 1 of them has a HasFired of 1, it's over (although -would you expect different?- op2 still continues to scan all the other failure conditions).


-----------------
Continuation of my work today:

It seems when you create a trigger (this doesn go for VictoryCondition and FailureCondition), you actually create 2 of them. This is why we have the use of only 127 triggers: The first trigger you create, creates a trigger with ID=5 and ID=6.

The first one has its boolEnabled set to 2 and its boolNoRepeat to 1, even you create a repeating trigger. I believe this is of type _Trigger with a length of 0x50 bytes. At offset 0x30 it stores the triggerfunction string, so i also think you will really give op2 a hard time when you supply a triggername with >31 chars!
At offset 0x20 it stores a pointer to that string (pointing to offset 0x30)

The second one then contains a pointer to that first _Trigger.
I'll work this out further tomorrow, if i have the time...
 

[Hooman]

OMG that sick. But at least that explains why you pass that string as the "callback function name". I'd wondered about that for a while. Or does it? I'm kinda curious about special cased names here.


 

[Eddy-B]

I've worked out the vtables of all 22 trigger types.
Some functions are the same for all triggers (Enable, Disable, Destroy, GetCallbackFunctionAddress and 2 other ones (@offsets 0x08 and 0x20) that still have to be named). The other 5 (virtual) members differ per trigger.

[Hooman]

Mmm. Post details please.
 

[Eddy-B]

This is what i got so far:


.. i tried pasting it, but TABs don't work well here...

SO: i've attached the file instead.

[Hooman]

Ahh excellent. That's a pretty well written file.    

[Eddy-B]

well - i think YOU were the one that layed out the basis for it
anyway: no problem!

[Hooman]

I just like the amount of detail. And the extensiveness of it. It's really nice having something like that around when you want to do some "fun" programming.