13 replies to this topic

[Viproz]

Hi,

I think for the programs using redstone, it would be better if the event redstone return the side where the computer is powered.

just like that :

while true do
  event, side = os.pullEventRaw()
  if event == "redstone" then
	if side == "right" then
	  -- do something
	elseif side == "top" then
	  -- another thing
	end
  end
end

I hope you will add this small thing !

[ChunLing]

Why would it be better? What could you do with this that isn't already trivially easy?

[Wouto1997]

ChunLing, on 06 January 2013 - 05:59 AM, said:

Why would it be better? What could you do with this that isn't already trivially easy?

Ofcourse this gives more redstone inputs to 1 computer, though I just prefer using it with redpower and having 16 outputs/inputs per side...

[Cloudy]

You have the same inputs... You just need to check the status of the ones you care about once the redstone event has been received.

[Luanub]

This will do exactly what you asking for

while true do
  os.pullEventRaw("redstone")
  if rs.getInput("right") then
	-- do something
  elseif rs.getInput("top") then
	-- another thing
  end
end

You can also do it with the bundled cables and specific colors.

[arg]

ChunLing, on 06 January 2013 - 05:59 AM, said:

Why would it be better? What could you do with this that isn't already trivially easy?

The biggest problem is that while events are queued, rs.getInput isn't. This causes problems if say, the redstone signal comes in while you are doing other things. You end up getting the event, but by the time your program gets around to checking it, the state has changed.

I've run into this problem many times in some of my more complex programs and would love some info in the event itself!

[Cloudy]

arg, on 07 January 2013 - 01:27 AM, said:

ChunLing, on 06 January 2013 - 05:59 AM, said:

Why would it be better? What could you do with this that isn't already trivially easy?

The biggest problem is that while events are queued, rs.getInput isn't. This causes problems if say, the redstone signal comes in while you are doing other things. You end up getting the event, but by the time your program gets around to checking it, the state has changed.

I've run into this problem many times in some of my more complex programs and would love some info in the event itself!

Unless anything you're doing takes longer than a minecraft tick (0.05s) then you won't have an issue. Having said that I'll think about it and speak to dan - but I don't think its likely.

[arg]

Cloudy, on 07 January 2013 - 01:55 AM, said:

arg, on 07 January 2013 - 01:27 AM, said:

ChunLing, on 06 January 2013 - 05:59 AM, said:

Why would it be better? What could you do with this that isn't already trivially easy?

The biggest problem is that while events are queued, rs.getInput isn't. This causes problems if say, the redstone signal comes in while you are doing other things. You end up getting the event, but by the time your program gets around to checking it, the state has changed.

I've run into this problem many times in some of my more complex programs and would love some info in the event itself!

Unless anything you're doing takes longer than a minecraft tick (0.05s) then you won't have an issue. Having said that I'll think about it and speak to dan - but I don't think its likely.

That is the main case where I've had that problem. The other case is when there are multiple signals coming in around the same time or where I'm also processing user input (user input at same time as a signal causes the problem). My solution has been to break processing up to prevent that and to introduce timing signals to regulate input, but that always feels like an ugly hack and in general the whole "queued event with expectation of checking a non-queued state" thing always feels like a timing issue just waiting to happen.

[Cloudy]

You should probably run your redstone processing in a separate coroutine to alleviate some of those problems. The easiest way to do that is using the parallel API.

Honestly I can't imagine what sort of processing you're doing which could cause this type of issue.

[arg]

Cloudy, on 07 January 2013 - 07:11 AM, said:

You should probably run your redstone processing in a separate coroutine to alleviate some of those problems. The easiest way to do that is using the parallel API.

Honestly I can't imagine what sort of processing you're doing which could cause this type of issue.

Anything that requires a delay to function (like say, driving an redpower filter) comes to mind.. though easy enough to get around that one with timers.

Parallel processing looks neat (I haven't really played with the parallel API yet) and would probably minimize the problem, but I'd still love to see the info right in the event so it can queued with no fear of getting lost. At a minimum the redstone event stands out as most of the other events give you event specific data (key event gives you the key pressed, peripheral gives you the side, etc..)

Anyway, I get that this is probably not a common problem and so may not warrant dev time, just wanted to add a second voice as someone who has also been annoyed by this problem ;p

[Cloudy]

... why would driving a redpower filter cause your code to delay at all? If you're using sleep to delay - there's your problem. Sleep eats events.

[ChunLing]

Okay, I'll grant that revising some basic program for outputting timed pulses so that it runs off a general event loop with timers rather than just using sleeps isn't "trivially easy".

It's still very possible and well worth doing if you are trying to get inputs at the same time as you're sending outputs. And, if you're losing events then you're losing the event you want anyway.

There is an issue with how yielding works, such that in an environment where a lot of computers are running code that doesn't yield very often, you can end up returning to a computer's thread to grab a redstone event some seconds after the event in question. My sense is that the upcoming changes in how processing time is shared should alleviate this (along with some other similar problems). If it ends up not doing so, then this suggestion would more definitely become a possible solution to the particular problem of redstone events.

[Feuermurmel]

I just want to add my voice as I also noticed problems with delays between the "redstone" event being fired and the application having a chance to read the inputs. I've implemented a serial line protocol on top of plain old redstone connections with a minimum pulse length of two game ticks (so that I could use redstone repeaters). When my computer was lagging, I often lost pulses with the minimum length. I could work around this, as long as there's only one input line on a single computer (i.e. just _assume_ that that single input changed). But when a computer has multiple input lines (e.g. to create a network), that doesn't work anymore.

It seems very odd to me that most of the events, like "peripheral" and "peripheral_detach", pass more information, even though that information is completely redundant there too.

I would also argue that the game's logic behaving noticably different when my computer is lagging is also breaking the fourth wall.

[Cloudy]

I'm just going to go ahead and lock this as nothing more useful is coming out of this, and it isn't going to change any time soon.