Timer Name For Easier Use

It would be great, if you could just pass a string to os.startTimer() (eg: os.startTimer(1, "pistonDelay")) and then
get it back when a timer event is fired. How it is now, you need a additional variable just to store the timer id
and it's not intuitive.

I'm hoping to see something like this in the future. :P/>

- Jan

PS: here is some example code of how it would be: (Except it is a pretty useless code but w/e)

os.startTimer(1,"onEnter") --this should be called when someone walks over a preasure plate
while true do
local event,id,string = os.pullEvent("timer")
if string == "onEnter" then
  os.startTimer(1,"openDoors")
  os.startTimer(3,"turnOnLights")
elseif string == "turnOnLights" then
  redstone.setOuput("top",true)
elseif string == "openDoors" then
  redstone.setOutput("back",true)
elseif string == "onExit" then
  redstone.setOutput("top",false)
  redstone.setOutput("back",false)
end
end

os.startTimer returns a number ID of the timer, which is the first parameter of timer events. You could easily make a system with a table to have strings mapped to each number.

While this can be done otherways, I think this would be really useful.

oeed, on 17 May 2014 - 02:26 AM said:

While this can be done otherways, I think this would be really useful.

how? why?

Question: In what instance is this

while true do
  local event = { os.pullEvent() }
  if event[1] == "redstone" and rs.getInput("right") then --# assuming pressure plate input is on the right
	os.startTimer(1, "onEnter")
  elseif event[1] == "timer" then
	if event[2] == "onEnter" then
	  os.startTimer(1, "openDoors")
	  os.startTimer(3, "turnOnLights")
	elseif event[2] == "turnOnLights" then
	  rs.setOutput("top", true)
	elseif event[2] == "openDoors" then
	  rs.setOutput("back", true)
	end
  end
end

more useful than this?

local onEnter, openDoors, turnOnLights

while true do
  local event = { os.pullEvent() }
  if event[1] == "redstone" and rs.getInput("right") then --# assuming pressure plate input is on the right
	onEnter = os.startTimer(1)
  elseif event[1] == "timer" then
	if event[2] == onEnter then
	  openDoors = os.startTimer(1)
	  turnOnLights = os.startTimer(3)
	elseif event[2] == turnOnLights then
	  rs.setOutput("top", true)
	elseif event[2] == openDoors then
	  rs.setOutput("back", true)
	end
  end
end

Answer: none.

theoriginalbit, on 17 May 2014 - 02:38 AM said:

–snip–

Well, it just makes it a little more intuitive and easier.

Also, having two files starting timers makes it easier to know. As I said, not necessary but it makes it more obvious.

cupcode, on 16 May 2014 - 08:14 PM said:

How it is now, you need a additional variable just to store the timer id and it's not intuitive.

So you want CC to store your string id in some internal variable instead.
Buggy if code of several programs would try to use the same name simultaneously.
Unique Id, returned by system, will never allow such situation.

Sebra, on 17 May 2014 - 06:49 AM said:

cupcode, on 16 May 2014 - 08:14 PM said:

How it is now, you need a additional variable just to store the timer id and it's not intuitive.

So you want CC to store your string id in some internal variable instead.
Buggy if code of several programs would try to use the same name simultaneously.
Unique Id, returned by system, will never allow such situation.

Actually that's a very good point, hadn't thought about that.

oeed, on 17 May 2014 - 07:39 AM said:

Sebra, on 17 May 2014 - 06:49 AM said:

cupcode, on 16 May 2014 - 08:14 PM said:

How it is now, you need a additional variable just to store the timer id and it's not intuitive.

So you want CC to store your string id in some internal variable instead.
Buggy if code of several programs would try to use the same name simultaneously.
Unique Id, returned by system, will never allow such situation.

Actually that's a very good point, hadn't thought about that.

If names are necessary, for some reason or other, you can likely overwrite startTimer, pullEvent and have a table that provides a name for each ID.

Well, again, as theOriginalBIT said, you can already assign custom names to timers, by storing the value returned by os.startTimer() into a variable of your choosing. I don't see any benefit to changing to what you are saying, since it can already be done in a different way.