Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: General Battuta on April 15, 2012, 11:03:18 am
-
Short version: I think events with a high trigger count eventually stop evaluating.
Before I set off alarms, though - can anyone see anything wrong this SEXP?
$Formula: ( when-argument
( any-of "Alpha 1" "Alpha 2" "Alpha 3" )
( and
( or
( and
( has-primary-weapon
"<argument>"
"0"
"Repair System"
)
( is-primary-selected "<argument>" 0 )
)
( and
( has-primary-weapon
"<argument>"
"1"
"Repair System"
)
( is-primary-selected "<argument>" 1 )
)
( and
( has-primary-weapon
"<argument>"
"2"
"Repair System"
)
( is-primary-selected "<argument>" 2 )
)
)
( < ( hits-left "<argument>" )100 )
)
( repair-subsystem
"<argument>"
"Hull"
1
)
( set-weapon-energy
( -
( weapon-energy-pct "<argument>" )
3
)
"<argument>"
)
)
+Name: EQUIP: Repair System
+Repeat Count: 1
+Trigger Count: 1410065407
+Interval: 1
Or with this one?
$Formula: ( when-argument
( any-of
[bunch of ships]
)
( and
( targeted "<argument>" )
( key-pressed "2" )
( = @artilleryslaved?[0] 1 )
( not ( = @toutatisready?[0] 1 ) )
( >
( mission-time-msecs )
@nextNumberPoll[-1]
)
)
( modify-variable @taxSexpRan[0] 0 )
( when
( and
( is_tagged "<argument>" )
( = @taxSexpRan[0] 0 )
)
( ship-untag "<argument>" )
( modify-variable @taxSexpRan[0] 1 )
( when
( and
( not
( has-departed-delay 0 "Vikrant" )
)
( not
( is-event-true-delay
"[redacted]"
0
)
)
)
( send-random-message
"Vikrant"
"Normal"
"Vikrant: target cleared"
"Vikrant: target cleared 2"
"Vikrant: target cleared 3"
"Vikrant: target cleared 4"
"Vikrant: target cleared 5"
"Vikrant: target cleared 6"
)
)
( when
( and
( not
( has-departed-delay 0 "Toreador" )
)
( not
( is-event-true-delay
"[redacted]"
0
)
)
( has-departed-delay 0 "Vikrant" )
)
( send-random-message
"Toreador"
"Normal"
"Toreador target cleared"
"Toreador: target cleared 2"
"Toreador: target cleared 3"
)
)
)
( when
( and
( not ( is_tagged "<argument>" ) )
( = @taxSexpRan[0] 0 )
)
( ship-tag "<argument>" 1 999999 )
( modify-variable @taxSexpRan[0] 1 )
( when
( and
( not
( has-departed-delay 0 "Vikrant" )
)
( not
( is-event-true-delay
"[redacted]"
0
)
)
)
( send-random-message
"Vikrant"
"Normal"
"Vikrant: target registered"
"Vikrant: target added 2"
"Vikrant: target added 3"
"Vikrant: target added 4"
"Vikrant: target added 5"
"Vikrant: target added 6"
)
)
( when
( and
( not
( has-departed-delay 0 "Toreador" )
)
( not
( is-event-true-delay
"[redacted]"
0
)
)
( has-departed-delay 0 "Vikrant" )
)
( send-random-message
"Toreador"
"Normal"
"Toreador: target designated"
"Toreador: target added 2"
"Toreador: target added 3"
)
)
( unprotect-ship "<argument>" )
)
( key-reset-multiple "2" )
( modify-variable
@nextNumberPoll[-1]
( + ( mission-time-msecs ) 250 )
)
)
+Name: fire control target picker
+Repeat Count: -1
+Trigger Count: 1215752191
+Interval: 0
+Team: 0
Both of these events seem to 'jam up' and stop working at some point in the mission. They no longer send diagnostic messages attached which makes me think they're not triggering at all any more.
-
Could it be that for some reason the SEXP switches to KNOWN_TRUE or KNOWN_FALSE and therefore doesnt evaluate anymore?
-
I had to set up the first event in Fred before I could analyze it, and I haven't looked at the second one. But it doesn't seem like there's anything wrong.
My only advice: MOAR TRIGGER COUNT!!!!
-
I had to set up the first event in Fred before I could analyze it, and I haven't looked at the second one. But it doesn't seem like there's anything wrong.
My only advice: MOAR TRIGGER COUNT!!!!
It's at the maximum.
I think a good diagnostic here might be to switch these to if-then-else statements so I have diagnostic messages for evaluations true and false.
-
I had to set up the first event in Fred before I could analyze it, and I haven't looked at the second one. But it doesn't seem like there's anything wrong.
My only advice: MOAR TRIGGER COUNT!!!!
It's at the maximum.
I think a good diagnostic here might be to switch these to if-then-else statements so I have diagnostic messages for evaluations true and false.
Unless I am missing something, the max trigger count is MAX_INT which for us is 2**31 (2,147,483,647). Either way though, if I am following how trigger count works, you are still looking at 1.4 billion ticks, which should be somewhere around 270 days worth of mission time.
-
Yeah, you shouldn't be able to run out of trigger counts until we can get the engine running at something like 100,000 FPS. :p
-
As unlikely as you've made it seem, is there any chance that the multiple logical possibilities that you are testing for are each counting as a trigger per tick instead of being evaluated as a whole? The second event has a lot of nested conditionals and logic states. Has it been shown that this doesn't affect event behavior?
Just trying to come up with ideas. :nervous:
-
As unlikely as you've made it seem, is there any chance that the multiple logical possibilities that you are testing for are each counting as a trigger per tick instead of being evaluated as a whole? The second event has a lot of nested conditionals and logic states. Has it been shown that this doesn't affect event behavior?
Just trying to come up with ideas. :nervous:
There are enough triggers here for loads and loads of game time. We're talking absurdly large amounts - years I think, possibly more.
And unfortunately the first SEXP also seems to crap out. What's weird is that similar SEXPs in our capship command missions don't...although many of them do use every-time...
Maybe we could swap to every-time and create a fake interval using a rapidly incrementing milliseconds var.
-
There are enough triggers here for loads and loads of game time. We're talking absurdly large amounts - years I think, possibly more.
Maybe you should test this assumption? Have some sort of counter that increments each time the trigger fires, and see what it's at when it stops firing?
-
There are enough triggers here for loads and loads of game time. We're talking absurdly large amounts - years I think, possibly more.
Maybe you should test this assumption? Have some sort of counter that increments each time the trigger fires, and see what it's at when it stops firing?
I definitely need to do more rigorous testing - I've been doing 'regular' FRED instead of hunting down this bug. I'll put this on the list of diagnostics to run Captain
-
Today I tested the following SEXP.
$Formula: ( if-then-else
( and
( or
( and
( has-primary-weapon
"Alpha 1"
"0"
"Repair System"
)
( is-primary-selected "Alpha 1" 0 )
)
( and
( has-primary-weapon
"Alpha 1"
"1"
"Repair System"
)
( is-primary-selected "Alpha 1" 1 )
)
( and
( has-primary-weapon
"Alpha 1"
"2"
"Repair System"
)
( is-primary-selected "Alpha 1" 2 )
)
)
( < ( hits-left "Alpha 1" )100 )
)
( when-argument
( any-of
"Alpha 1"
"Alpha 2"
"Alpha 3"
"Beta 1"
"Beta 2"
"Beta 3"
)
( and
( or
( and
( has-primary-weapon
"<argument>"
"0"
"Repair System"
)
( is-primary-selected "<argument>" 0 )
)
( and
( has-primary-weapon
"<argument>"
"1"
"Repair System"
)
( is-primary-selected "<argument>" 1 )
)
( and
( has-primary-weapon
"<argument>"
"2"
"Repair System"
)
( is-primary-selected "<argument>" 2 )
)
)
( < ( hits-left "<argument>" )100 )
)
( repair-subsystem
"<argument>"
"Hull"
1
)
( set-weapon-energy
( -
( weapon-energy-pct "<argument>" )
3
)
"<argument>"
)
( send-message
"#Command"
"High"
"repair on"
)
)
( send-message
"#Command"
"High"
"repair off"
)
)
+Name: EQUIP: Repair System - TESTING
+Repeat Count: -1
+Trigger Count: 1410065407
+Interval: 1
As you can see, this is simply the previous SEXP #1 slotted into an if-then-else. If the SEXP evaluates true, it will send a message saying 'repair on.' If the 'else' branch triggers, it will say 'repair off'.
For most of the mission - sometimes the entire mission - it behaves this way quite happily.
Often, however, something baffling occurs. When the Repair System bank is not selected, it continues to print 'repair off.'
When the Repair System is selected, however, nothing happens.
This is impossible, of course - the event must either be 'if' or 'else'. Yet somehow the event is recognizing that its conditions are fulfilled but not doing anything about it.
I don't know what to make of this, except to think it's likely a problem with when-argument, not trigger count.
-
Why do I get the feeling that this one will possibly wind up drawing blood from you? :p
-
Yeah, you shouldn't be able to run out of trigger counts until we can get the engine running at something like 100,000 FPS. :p
I give it a couple years.
-
The plot thickens..... You're not matching speeds with something when it fails, are you?
But seriously, that is odd. The fact that it sometimes works and sometimes doesn't makes it a lot harder to track.
-
The plot thickens..... You're not matching speeds with something when it fails, are you?
Why would that have anything to do with it? :confused:
-
I think that may have been a reference to the render engine bug of DOOM that was fixed ages ago.
-
I have no time this week to help debug this, but I can offer two suggestions:
1) use the simplest possible sexp to reproduce the bug
2) read the sexp help carefully (in particular, if-then-else might surprise you if it's not nested underneath another conditional)
-
I have no time this week to help debug this, but I can offer two suggestions:
1) use the simplest possible sexp to reproduce the bug
2) read the sexp help carefully (in particular, if-then-else might surprise you if it's not nested underneath another conditional)
Why would if-then-else's behavior change in the middle of a mission?
Anyway: please find attached a test mission using only retail assets. It contains the first listed event. Unfortunately, I have been unable to trigger the bug using this test mission. This could be for one of several reasons:
1. I simply haven't run the mission enough to hit it.
2. The bug depends on the mission being sufficiently complex (for example, N number of SEXPs or something else evaluating per frame)
3. The bug interacts with some BP assets such as a script or new HUD code
[attachment deleted by a ninja]