rapidly calling os.pullEvent()

Hello,

this might be an odd question, but how many times can os.pullEvent() can be called?
20 times in a second, based on the minecraft game ticks?

Basically, i am having an os.startTimer(0.1) running all the time, catching and freshing it with os.pullEvent every time.

local delay = os.startTimer(0.1)
while true do
local e = { os.pullEvent() }
if e[1] == "timer" and e[2] == delay then
delay = os.startTimer(0.1)
end
sleep(0)
end

That works!
Furthermore, i am receiving rednet messages (up to 4 per second in the final program i think) and catch them with the same os.pullEvent()

local delay = os.startTimer(0.1)
while true do
local e = { os.pullEvent() }
if e[1] == "timer" and e[2] == delay then
delay = os.startTimer(0.1)
elseif e[1] == "rednet_message" then
-- checking if the message is correct, saving information in an array as well as saving it into a file if the chunk gets unloaded
end
sleep(0)
end

It allmost every time stops my timer now when i am receiving a rednet message.
If there can only be every 0.05 seconds an os.pullEvent() activated then i am only having 20 actions per seconds to work with.
If this is true a solution would be pulling the timer every 0.05 seconds and refreshing the timer when a rednet message gets received as well. This would take a while to implement so i ask first here.

Let me know if someone knows more about it.
Thanks
unobtanium

Don't sleep in event handling loops. You're probably throwing away your timer event there. I'm surprised the first code even works. Also, what could you possibly be doing that would require resuming every tenth of a second?

Okay thanks i am going to try that out.
I am basically switching the redstone output on various sides to change the direction of iron pipes. And redstone cant be changed every 0.05 seconds, based on the 10 ticks for redstone.

edit: sleep(0) really was the problem.

Just a quick note e[2] == "rednet_message" won't work. It should be e[1]

Yeah that's right :D/>
Wrote the example above really quickly… derp derp :P/>

Redstone can be changed 20 times a second.

Check out Gundershot's YT channel for a tutorial.

The limiting factor is how often you can create an event. I did a quick test using the code below, I got 256 os.pullEvents in about a tenth of a second. Now, this code obviously has rather large issues, so don't use it in an actual program, but you get the idea.

print('...')
for i = 1, 257 do
os.startTimer(0.1)
end
os.pullEvent()
print('Starting')
local startTime = os.clock()
for i = 1, 256 do
os.pullEvent()
end
print('256 pullEvents in '..os.clock()-startTime..' seconds')

Printed '256 pullEvents in 0.1 seconds'

Anything higher doesn't seem to work. So, unless someone can prove me wrong, asume 256.

oeed, on 15 January 2014 - 09:06 PM said:

That was in an emulator, so it might be a bit different to in game.

Its definitely different in-game. for these types of tests never do them in an emulator!

theoriginalbit, on 15 January 2014 - 09:10 PM said:

oeed, on 15 January 2014 - 09:06 PM said:

That was in an emulator, so it might be a bit different to in game.

Its definitely different in-game. for these types of tests never do them in an emulator!

Yes, you're quite correct. I tried it again in game and I've edit my post with the correct results.

Thanks a lot for that research.
So there is a slight chance that multiple events can happen at the same time and just the first one gets pulled? (just a theoretic question!!)

In the Minecraft Wiki 20 ticks per second are called Gametick and allmost everything works with it (mob spawning ect). Redstone ticks are just every second gametick so in the end only 10, which are 0.1 seconds :S

UNOBTANIUM, on 16 January 2014 - 06:49 AM said:

So there is a slight chance that multiple events can happen at the same time and just the first one gets pulled? (just a theoretic question!!)

No. it is an event queue. each time you call one of three functions to dequeue an event (os.pullEvent, os.pullEventRaw, coroutine.yield) you'll get one event and the rest are maintained in the queue ready for the next time you pull an event…

Oh yeah that makes sense. Honor that guy who invented that xD