Alright, this is a simple question but I don't really know the answer. It's pretty important though, as spawn() is one of the key elements in my game. It's very existance and operation determines whether you win or lose. Sooooo...here it is:
Do sleep() and spawn() hack off decimal places when you use them? For example I use sleep(3.95) in my code, will it sleep for exactly 39.5 milliseconds or will it chop of the decimal in there and sleep for 30 milliseconds? Spawn should work the same way...it would make sense.
ID:180373
 Jul 11 2001, 9:30 am
|
|
On 7/11/01 1:09 pm Deadron wrote:
On 7/11/01 12:30 pm Ghaleon wrote: I think this is a bit misleading the way you wrote it. Yes, they are sleeping for a number of ticks, but the number you give in the call is not necessarily that number of ticks. I used to think it was until I started trying to speed up Dung-Man. I thought I could decrease world.tick_lag and have all sleeps and spawns scale accordingly. However, I learned from experimentation that a sleep and spawn always operate in units of 1/10th seconds, regardles of world.tick_lag. Going back to the reference confirms this. Back to the original question, I learned in my experimentation that a sleep or spawn will "wake up" on the last tick which is at, or before the time it is given. For example, say world.time is 2435 and world.tick_lag is 1. At this moment, I sleep(3.95). The "desired" wake up time is 2438.95, but the last tick at or before that time is 2438. Thus when the sleep wakes up, world.time will be 2438. So effectively, yes, it truncates the time slept. But be very careful if you change world.tick_lag! I ran into all sorts of problems with spawns waking up before I wanted them to, because I was spawning for whole numbers but world.tick_lag was a fraction. I had a lot of processes that looked something like this: obj var/alarm = 0 proc/SpawnStuff() alarm = world.time + 40 spawn(40) if (world.time > alarm) DoSomeStuff() proc/DoSomeStuff() // ... do whatever Basically, I wanted to be able to reset a timer while it was still in the middle of "counting down" (in the spawn). So, calling SpawnStuff() 2 seconds later would reset it to wait for another 4 seconds from that point instead. This was all fine and dandy when world.tick_lag was 1. But when I tried making it 0.9, DoSomeStuff() never happened. This is because the last tick before or at 4 seconds later was actually 3.96 seconds (44 ticks) later. world.time wasn't greater than my alarm time, so nothing. Try the following code in any world or by itself and play around with different values. You'll get a good feel for how these things work and interact. mob/verb/ss(ticks=10 as num) src << "world.time is now [world.time]" spawn(ticks) src << "after spawn([ticks]), world.time is now [world.time]" sleep(ticks) src << "after sleep([ticks]), world.time is now [world.time]" mob/verb/tl(tl=1 as num) src << "world.tick_lag was [world.tick_lag], setting to [tl]" world.tick_lag = tl | |
On 7/11/01 2:15 pm Air Mapster wrote:
However, I learned from experimentation that a sleep and spawn always operate in units of 1/10th seconds, regardles of world.tick_lag. Going back to the reference confirms this. Ack...I recall you mentioning this, but it's not the way I think about it. Probably some number of subtle bugs are related to this. I don't know what the implications would be of changing it, but for me I want it to mean game ticks, not a pure 1/10th a second. | |
On 7/11/01 2:18 pm Deadron wrote:
On 7/11/01 2:15 pm Air Mapster wrote: Alright guys, thanks. I guess I'll have to make a for() loop to lag the proc instead. Simplest way I guess...hehe. | |
In both cases, they are sleeping or spawning for a certain number of "ticks". A tick is a cycle in which code is called. There is no such thing as 1.5 ticks...there are only whole numbers.
A tick happens about once every 1/10th a second.