Reflex tests

ID:151695
 
Aug 12 2009, 2:41 am
I was trying to create a reflex system (make the stinking lazy players actually have to do something :) ), but I am having some hangups. Mainly, the sleep(1) (1/10th of a second tick) is too slow for moving the reflex meter, and sleep() is too fast.

Is it possible (through looping and stalling) to get a tick that is faster than 1/10th of a second?
Aug 12 2009, 3:21 am
You can change the world's tick_lag variable to make ticks take less time. However, you still have to deal with the realities of internet lag, and lower values may make multiplayer work less well.
Aug 12 2009, 9:13 am
I've recently implemented a system like this for resource gathering. Lag is a big problem for things like this over a network though. Being BYOND, it's that much worse.
Aug 12 2009, 9:57 am
In response to Jon88
Jon88 wrote:
You can change the world's tick_lag variable to make ticks take less time. However, you still have to deal with the realities of internet lag, and lower values may make multiplayer work less well.

Messing with tick lag is usually a very ill advisable move.

Unless you're playing on fiber optic connections that go next door, or you're on a lan, it pretty much destroys network play.

To OP:
You can try something like this, I'm not sure how much of a real effect it will have on the time, but it may work for you:
proc/Checker()
 var/Counter=0
 while(world)
  Counter++
  if(Counter>4)
   Counter=0
   sleep(1)
  world<<"Do your keychecks here"


I'll play around with this and a few other ideas to see if I can come up with a way to simulate half a tick...


OOH! GOOD IDEA!
Something I just thought of.
Using the Call() proc to access a DLL causes the proc to pause until the DLL call is completed right? Why not just make a DLL that allows millisecond based sleep times...?
Aug 12 2009, 10:58 am
In response to AJX
AJX wrote:
Something I just thought of.
Using the Call() proc to access a DLL causes the proc to pause until the DLL call is completed right? Why not just make a DLL that allows millisecond based sleep times...?


Because it'll still wait for the next tick to realize the dll has returned. BYOND's command queue system is based around ticks.
Aug 12 2009, 12:07 pm
In response to Nadrew
Nadrew wrote:
AJX wrote:
Something I just thought of.
Using the Call() proc to access a DLL causes the proc to pause until the DLL call is completed right? Why not just make a DLL that allows millisecond based sleep times...?


Because it'll still wait for the next tick to realize the dll has returned. BYOND's command queue system is based around ticks.

Gotcha...

Well. Then yea. I lose.
Aug 13 2009, 4:55 am (Edited on Aug 13 2009, 5:01 am)
In response to Jon88
Jon88 wrote:
You can change the world's tick_lag variable to make ticks take less time. However, you still have to deal with the realities of internet lag, and lower values may make multiplayer work less well.

Changing tick_lag doesn't affect the ticks used in sleep() and spawn(). Try it. When doing something like
verb/test_tick()
    sleep(100)
    usr << "100 ticks!"


The "100 ticks" message will always come up after 10 seconds, even with a tick_lag of 1/10.

As far as I know, the only things that are affected by tick_lag are animation/icon ticks and movement ticks.

Aug 13 2009, 5:05 am (Edited on Aug 13 2009, 5:11 am)
In response to Nielz
Nielz wrote:
Jon88 wrote:
You can change the world's tick_lag variable to make ticks take less time. However, you still have to deal with the realities of internet lag, and lower values may make multiplayer work less well.

Changing tick_lag doesn't affect the ticks used in sleep() and spawn(). Try it. When doing something like
verb/test_tick()
>     sleep(100)
>     usr << "100 ticks!"

The "100 ticks" message will always come up after 10 seconds, even with a tick_lag of 1/10.

As far as I know, the only things that are affected by tick_lag are animation/icon ticks and movement ticks.

tick_lag denotes the multiple in which ticks function. A tick_lag of 1 means that all sleeps/events will happen in multiples of 1 (integers only). If you set the tick_lag to 0.7, you can sleep for 0.7 ticks, 1.4 ticks, 2.1 ticks, 2.8 ticks, and so on.

But as has already been mentioned, this speed cannot be maintained over the Internet.

If these reflex tests are on a per-player basis, I would suggest looking into Flash, which functions client-side and would not be affected by latency. Just be careful to check any exports the Flash game is supposedly sending, as players may try to spoof it to bypass the test.
Aug 13 2009, 8:01 am
In response to DarkCampainger
DarkCampainger wrote:
tick_lag denotes the multiple in which ticks function. A tick_lag of 1 means that all sleeps/events will happen in multiples of 1 (integers only). If you set the tick_lag to 0.7, you can sleep for 0.7 ticks, 1.4 ticks, 2.1 ticks, 2.8 ticks, and so on.

You are wrong. Nielz is correct.
You are also misunderstanding the meaning behind the explanation of tick lag...

For one:
Setting tick lag to a value less than 1 will NOT allow you to sleep for less than one second.

Sleep will always be measured in 1/10ths of a second, as it so clearly states in the help file.

A quote from tick lag's definition:
This is the smallest unit of time (one server tick) measured in 1/10 seconds. The duration of events that take some finite amount of time (like sleep) will be rounded to a whole number of ticks.

This means, that if you set tick lag to 3 and sleep for 1,2 or 3 ticks, it will always be calculated on the third tick.


But as has already been mentioned, this speed cannot be maintained over the Internet.

Again, nothing to do with anything. You can't sleep for less than 1/10th of a second.


Nielz wrote:
As far as I know, the only things that are affected by tick_lag are animation/icon ticks and movement ticks.

Sleep and spawn are also affected by tick lag, as mentioned above. You just can't specify sleeping periods in anything but 1/10th of a second measurements.
Aug 13 2009, 8:18 am
In response to AJX
AJX wrote:
Setting tick lag to a value less than 1 will NOT allow you to sleep for less than one second.
(You meant one 1/10 of a second)

Why wouldn't it, exactly? As you've quoted from the Reference yourself, things such as sleep times are rounded to a whole number of ticks. So if a tick takes the timespan of less than one tenth of a second (which it would if you set tick_lag to less than 1), you can sleep for less than 1/10 sec.

Sleep will always be measured in 1/10ths of a second, as it so clearly states in the help file.

(Which, of course, doesn't mean you couldn't specify a time smaller than 1/10 of a second in it.)
Aug 13 2009, 8:21 am (Edited on Aug 13 2009, 8:26 am)
In response to Kaioken
Kaioken wrote:
AJX wrote:
Setting tick lag to a value less than 1 will NOT allow you to sleep for less than one second.
(You meant one 1/10 of a second)

Why wouldn't it, exactly? As you've quoted from the Reference yourself, things such as sleep times are rounded to a whole number of ticks. So if a tick takes the timespan of less than one tenth of a second (which it would if you set tick_lag to less than 1), you can sleep for less than 1/10 sec.

Sleep will always be measured in 1/10ths of a second, as it so clearly states in the help file.

(Which, of course, doesn't mean you couldn't specify a time smaller than 1/10 of a second in it.)

You bring up an interesting point. I have never tried using sleep(0.1) I was always told that decimals weren't allowed in sleep, but that could just be with default tick lag. I'll test this in a minute.

EDIT:

Well. Crap. You're right. You can put in 0.1 and it works out appropriately. o.o.
There was a whole discussion on this a few months ago... You could go and prove all of them wrong. :D

EDIT Again: Well, I digress.

1: Sleep will in fact always be measured in 1/10th of a second
2: You can however enter decimals as values to do smaller calculations
3: From the slight amount of testing I've done, sleeping for 150 centiseconds can actually report 14 deciseconds because you are updating faster than the world timeofday. Weird.
Aug 13 2009, 2:53 pm
In response to AJX
Thanks all for the info. I was thinking along the lines of the dll call, but I guess it won't happen.

I got it to where it works ok. Would like it to be faster, but alas, no go in BYOND. I was looking to do it in flash, but I like coding in BYOND, and I was just getting back into it. Ah well.

Thanks again.
Aug 13 2009, 3:51 pm
In response to Jik
Jik wrote:
Thanks all for the info. I was thinking along the lines of the dll call, but I guess it won't happen.

I got it to where it works ok. Would like it to be faster, but alas, no go in BYOND. I was looking to do it in flash, but I like coding in BYOND, and I was just getting back into it. Ah well.

Thanks again.

Read the other side of this thread.

You can set tick lag down and then sleep(0.5). I'd say set tick lag to 0.5, instead of 0.1 as some others suggested. See if that works for you.