View Issue Details

IDProjectCategoryView StatusLast Update
0006563The Dark ModCodingpublic23.09.2024 18:20
ReporterMirceaKitsune Assigned To 
PrioritynormalSeveritynormalReproducibilityalways
Status newResolutionopen 
PlatformLinuxOSManjaroOS VersionStable
Product VersionTDM 2.12 
Summary0006563: trigger_inactivity ignores delay when set to 1 second or less
DescriptionThe timer for the trigger_inactivity entity ignores its delay when set to 1 or below: The entity always triggers its targets once every second, even if it's triggered again during this time. I asked other users to run my test case and others could confirm the result.
Steps To Reproduce1. Create a trigger_multiple brush. Give it a wait spawnarg of 0.05.
2. Create a trigger_inactivity entity. Give it a delay of spawnarg of 0.5.
3. Create a toggleable electric light that can be triggered on and off.
4. Link the trigger_multiple brush to the trigger_inactivity entity and the trigger_inactivity to the light.

Expected result: Since the trigger_multiple executes every 0.05 seconds and the trigger_inactivity waits for 0.5 seconds, the player sitting inside the brush for several seconds should not cause the light to change, this should instead happen 0.5 seconds after the player has left the boundaries of the trigger_multiple brush.

Observed result: As the player sits inside the trigger_multiple brush, the light constantly blinks between on and off every 1 second. I get the correct behavior if I set the delay of the trigger_inactivity above 1, but this doesn't give me the short amount of time I need. Linking the trigger_multiple directly to the light makes it flicker based on its wait setting and confirms the trigger itself runs at the desired interval, the issue seems to be with inactivity detection when set to 1 second or below.
Additional Informationhttps://forums.thedarkmod.com/index.php?/topic/9082-newbie-darkradiant-questions/&do=findComment&comment=496328
TagsNo tags attached.

Activities

stgatilov

stgatilov

22.09.2024 15:04

administrator   ~0016836

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)
MirceaKitsune

MirceaKitsune

22.09.2024 16:31

reporter   ~0016838

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.
VanishedOne

VanishedOne

23.09.2024 14:12

reporter   ~0016839

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.
MirceaKitsune

MirceaKitsune

23.09.2024 14:26

reporter   ~0016840

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.
stgatilov

stgatilov

23.09.2024 18:20

administrator   ~0016841

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.

Issue History

Date Modified Username Field Change
07.09.2024 18:45 MirceaKitsune New Issue
22.09.2024 15:04 stgatilov Note Added: 0016836
22.09.2024 16:31 MirceaKitsune Note Added: 0016838
23.09.2024 14:12 VanishedOne Note Added: 0016839
23.09.2024 14:26 MirceaKitsune Note Added: 0016840
23.09.2024 18:20 stgatilov Note Added: 0016841