I appreciate that Lua developments may not top priority, but I offer the following thought for when/if the next Lua iteration gets released.
Currently, key.wait only looks for one key. I believe it would be better if key.wait could include a list of keys that are ORed, ie one of the list of keys would trigger wait to continue ie
key.wait([key.1], [key.2], .... [key.n])
Update: plus would it be possible to have key.wait act in a similar way to the key event handler, i.e. when the wait key is detected, key.wait can either handle the key normally or ignore the key.
Had a thought overnight and have spent some time reading keys.lua and believe this may be a way forward.
Thanks @a1ex for providing well commented examples.
Not sure if using keys.lua will allow my script to remain 'simple'. I think it will, as long as I ensure the key event handler is deregistered when my script completes.
@a1ex
I'm looking at tweaking your keys Lua module for my own needs and trying to understand one line within one of your functions. The function is:
function keys:anykey()
local started = self:start()
--ignore any immediate keys
task.yield(100)
self:reset()
while true do
local key = self:getkey()
if key ~= nil then
if key ~= KEY.UNPRESS_SET then
break
end
end
task.yield(100)
end
if started then self:stop() end
end
My question is: what does the KEY.UNPRESS_SET do?
That's not my code; dmilligan wrote this function.
I'd have to experiment in order to find the answer. That is, I'd have to comment out the UNPRESS_SET and find out in what situations it would fail. That check might actually be unnecessary, or it might be there to handle some corner cases. Without comments from original author, and without reserving half an hour or so in order to run this test, I don't have any quick answer.
@a1ex
I'll be looking at it myself as well.
With all your other commitments, please don't 'waste' your time on this one ;-)
Cheers
Garry