 |
Perhaps caused by this in tdm_triggers.script: void trigger_inactivity::countdown(entity me, float threadnum) { if (timer > 0) timer = delay; else { if (triggerOnStartTimer) activateTargets(self); timer = delay; while (timer > 0) { sys.wait(1); timer--; } activateTargets(self); } } I guess someone thought 1 second of granularity is OK for everyone. What I don't understand here is: why not just do this instead of waiting in a loop: if (timer > 0) sys.wait(timer) |
 |
Is that limitation in the main script necessary, and if not can it be removed? If a mapper wants to use 0.1 seconds instead of 1 second I don't see why the script should be trying to stop them. I generally don't know why some of the default entities were coded as they were, but looking at that snippet even to me it seems overly convoluted for something simple, a few of the old definitions seem to be like that unfortunately. For now I'll wait to see what happens: I tend not to write map scripts for simple triggers over using the default entities, only advanced map specific functions that can't be done otherwise. If it becomes necessary I can duplicate the whole thing, it just wouldn't feel right to copy an existing entity only to work around an artificial limitation that seems like an oversight, thus I hope the original can be fixed. |
 |
It's years since I looked at this, but I think the idea is that if a countdown is in progress, another call to countdown() resets the timer variable and then exits. That's why the timer is manually decremented inside a while loop. There are certainly other ways, like killing the original countdown thread and replacing it, or checking the difference between initial and current time, but you can't just wait a fixed period and then continue execution unconditionally. (Whatever's used also needs to avoid activating targets again when the countdown's reset in cases where triggerOnStartTimer is true.) sys.wait(1) probably has 1 because it allows the next line to be a simple timer-- and the whole thing to run in seconds; if you change one line but not the other it'll count down in some other unit. |
|
|
I think the relevant question would be: Is there any existing FM that used a trigger_inactivity with a delay of less than 1, which relies on the code ceiling it to 1 in order to work? Unless a mapper mistakenly set the spawnarg to 0.x and forgot it that way, which thankfully seems unlikely, it looks like fixing it shouldn't break anything. From what I can tell it's an artificial limitation placed long ago, likely a developer at the time thought you don't need a delay of less than 1 and decided not to let anyone use it, till it seems just now I found myself needing a more tightly timed trigger setup that does require that to work right. |
|
|
Can you replace the lines with: sys.wait(0.016); timer -= 0.016; And check that it works as intended? By the way: as of now, it seems this feature is not anywhere at all. |
- Anonymous
