Simtime

[Pie Crust]

Could I get a clear explanation on simTime and what I can do with it?
inb4 color=transparent

[Ad Bot]

[Headcrab Zombie]

There's two similarly named variables/functions, both return time elapsed the application was started, but one returns in second, the other in milliseconds

You can use it for anything that needs...what it measures...
A common application is making sure a certain amount of time had passed before allowing something, such as a spam filter

[Pie Crust]

So, by the way it works, it isn't a viable replacement for Schedule, right?

[Crøwn]

You can make command cooldowns with it. Set when the last time a person did a command to the simTime and if it hasn't been long enough then don't let them run the command again.

[Headcrab Zombie]

Schedule is for stuff you want to execute after x time
Sometime checks is for stuff that could be called whenever, but you want to make sure they can't do it until x time

[Pie Crust]

Oh well. Thanks!

[Kyuande]

Here's an example of using it.

//Command /SayHi
function serverCmdSayHi(%client)
{
   //$Sim::Time : Seconds
   //getSimTime() : Milliseconds

   //We get the current sim time and subtract from the client when it was recorded.
   if($Sim::Time - %client.lastTime < 3) //Must be at least 3 seconds to bypass the timeout
      return;

   %client.lastTime = $Sim::time; //Set a new record for time
   serverCmdMessageSent(%client, "Hello everyone!"); //Send a hello message using /MessageSent
}

[TheBlackParrot]

getRealTime() is the same thing, except that it doesn't take I/O lag into account if I remember right.

[Xalos]

getSimTime() is the "physical" time.  It's affected by things like timescale.  getRealTime() is the "real" time.  It's the computer time, meaning it's completely unaffected by timescale.  As a result, getSimTime() is appropriate for things like physical loops, where you want to nullify the in-game gravity of a vehicle or find the new position of a moving StaticShape.  getRealTime(), on the other hand, is appropriate for things like clocks which are supposed to remain synced to real time regardless of the timescale.

As of yet, in my mind at least, no one has ever made a sufficiently strong argument against using getSimTime() or getRealTime().  $Sim::Time has been preconverted into a decimal format, meaning that it has lost all precision beyond the first six decimal digits.  With getSimTime() and getRealTime(), however, it's possible to retain the full precision through various means.

%threeSecondsFromNow = (getSimTime() + 3000) | 0;
%seventeenSecondsAgo = (getSimTime() - 17000) | 0;
%timeSinceLastCheck = (getSimTime() - (%last | 0)) | 0;

Regardless of what method you choose to use, it's worth noting that these values all, at their heart, rely on a signed 32-bit integer.  As a result, these values will eventually become negative, after exactly 24 days, 20 hours, 31 minutes, 23 seconds, and 647 milliseconds.  This can cause problems, so if you expect your script to be running on a server that will stay up longer than this, it may be prudent to make the script resistant against these types of problems.

[portify]

Generally I'd recommend using $Sim::Time over getSimTime() as it is way more precise by default, and will take a thousand times longer to overflow at 999999.

[Shift Kitty]

Generally I'd recommend using $Sim::Time over getSimTime() as it is way more precise by default, and will take a thousand times longer to overflow at 999999.

Yeah but you lose precision before it overflows, correct?

[Kyuande]

Yeah, but after that time xalos posted, the avatar system and pretty much everything else breaks