Global Tick Schedule for Zones?

[Melting Plastic]

In my ZoneEvents mod I have been simply using a combination of triggers and physical zones around bricks and accessing the onTickTrigger callback for all my OnInZone events.  Of course Torque doesn't sense projectiles at all within a trigger so I tried doing a container ray cast for projectiles within the onTickTrigger callback for each trigger. - but onTickTrigger only gets called if a player of vehicle is already in the trigger..

my question is: is it worth it to have a global schedule that does container raycasts on each zone?  Or would it be too laggy on the networking side of things?  I want to keep Zones as fast and clean as possible.  Any Thoughts?

[Ad Bot]

[Destiny/Zack0Wack0]

A global tick instead of a seperate tick for each trigger is the least laggiest method, yes. From the work I've done with TorqueScript schedules; they don't actually lag much.

Short period schedules should not be in server-standard mods, no. Honestly I can't even think of any good reasons behind my answer right now. But I guess if one person starts doing it everyone starts doing it. Then we end up with multiple mods using short period schedules.

There are a few cases of course, AI mods (Zombie mods.. bot events.. etc) and Space Guy's portal gun. I'm not sure where Badspot and Ephialtes even sit on this. Some mods using fast ticks have been failed while things like the portal gun which uses fast ticks remains allowed.

[MegaScientifical]

You stole my idea, though... I made this, then Trader got it failed, then I tried it his way and gave up... I left BL for a while, came back and you had made this...

... Yes, global... do... it...

[Iban]

I'm curious. What makes the global method better than the individual method? The code is more or less the same. The only difference is, in the global routine, you're having to shift through a simgroup and in the local routine you're making more schedule events.

[Destiny/Zack0Wack0]

I'm not sure. Just from what I've done with schedules, the global tick lags less. I'm fairly sure there is a schedule limit, too.

[Tom]

Well doing a container search multiple times a second on many bricks will get laggy.
The onVehicleTouch events did something similar and got failbinned.

[Iban]

Well doing a container search multiple times a second on many bricks will get laggy.
The onVehicleTouch events did something similar and got failbinned.

I think this just supports the local routine even more. If you have 100 trigger zones, would it not be better to have each zone firing off independently as opposed to them all going off at once?

In ZAPT, the Zombies think at different paces. The typical thinking time is 500ms, so the Director schedules out their thoughts over that span. If there are 50 zombies out and about, there will be a 10ms lapse between each zombie thought schedule. This was added to reduce workload and I think there was a noticeable increase in speed.

[Space Guy]

Having lots of schedules running at the same time can be laggy. What I've found to be the most effective way is a global 33ms (shortest amount of time a schedule can actually happen on) schedule that runs a counter doing e.g. one in ten bots each time. That has the same effect as doing a 330ms schedule for every bot, but is easier on the server.

new SimSet(ZoneSet);

(... ZoneSet.add(%trigger); when created)

function blahtick()
{
   schedule(33,0,blahtick);
   $counter = ($counter+1) % 5;
  
   for(%i=$counter;%i<ZoneSet.getCount();%i+=5)
   {
      %trigger = ZoneSet.getObject(%i);
      doContainerChecks(%trigger);
   }
}

[Iban]

How do you know that this is the best method?

[Space Guy]

It's not doing all the work in one single step (global schedule by itself as you said) and the engine is not trying to check the times of a hundred schedules simultaneously. I don't remember where, but I remember hearing that schedules are low-level and really laggy like this.

[Iban]

It's not doing all the work in one single step (global schedule by itself as you said) and the engine is not trying to check the times of a hundred schedules simultaneously. I don't remember where, but I remember hearing that schedules are low-level and really laggy like this.

So the happy medium. Makes sense.

[Truce]

33ms (shortest amount of time a schedule can actually happen on)

Just did a test, seems like 15 is the lowest.

==>function endtest() { cancel($testloop); echo("Ran " @ $testtimes @ " times."); }
==>function testtick() { $testtimes++; cancel($testloop); $testloop = schedule($testdel,0,testtick); }
==>$testtimes = 0; $testdel = 33; testtick(); schedule(1000,0,endtest);
Ran 29 times.
==>$testtimes = 0; $testdel = 16; testtick(); schedule(1000,0,endtest);
Ran 58 times.
==>$testtimes = 0; $testdel = 15; testtick(); schedule(1000,0,endtest);
Ran 61 times.
==>$testtimes = 0; $testdel = 14; testtick(); schedule(1000,0,endtest);
Ran 61 times.
==>$testtimes = 0; $testdel = 13; testtick(); schedule(1000,0,endtest);
Ran 61 times.
==>$testtimes = 0; $testdel = 1; testtick(); schedule(1000,0,endtest);
Ran 61 times.
==>$testtimes = 0; $testdel = 0; testtick(); schedule(1000,0,endtest);
Ran 341073 times.

[Space Guy]

Just did a test, seems like 15 is the lowest.

Oh. I was basing it off this message I got - this is several updates ago so maybe it's changed since then.

Your Weapon_PortalGun add-on sets up a script loop called "SpaceTick" that fires every 10 milliseconds.  The game simulation only advances every 32ms so you are doing more than 3 times as much work as necessary even at the greatest possible fidelity.  I would recommend updating this as soon as possible.

[Iban]

Oh. I was basing it off this message I got - this is several updates ago so maybe it's changed since then.

Correct me if I'm wrong, but there's a difference between the game simulation and the scripts. Meaning, scripts are limited by processor and the game simulation is graphical rendering.

[Space Guy]

Code: [Select]

==>function testTick(){if($sim::time > $starttime+1){endtick();}else{$testcount++;schedule($testamt,0,testTick);}}
==>function test(){$testcount=0;$starttime = $Sim::Time;testTick();}
==>function endtick(){echo("Ran " @ $testcount @ " times.");}
==>$testamt = 100;test();
Ran 10 times.
==>$testamt = 32;test();
Ran 30 times.
==>$testamt = 15;test();
Ran 59 times.
==>$testamt = 10;test();
Ran 61 times.
==>$testamt = 5;test();
Ran 119 times.
==>$testamt = 1;test();
Ran 119 times.
==>$testamt = 3;test();
Ran 118 times.
==>$testamt = 0;test();
Ran 845819 times.
Without two schedules at once I get a limit at 5ms, also many more runs at 0ms.

In any case the time should be set as high as you can for the same functionality rather than lower - 100-200ms preferred to 5ms as other mods and wrench events will be running schedules at the same time.