Bundles Cables do not generate events

As far as I understand in 1.3 Bundles connected to a CC computer do not generate events that can be captured by an os.pullEvent(). It would be nice to have an event launched for any color in a wire that changes state. Also for some reason whenever i press enter, i do not go to the next line on this forum … pretty annoying.. VV

You could write a function that checks if a bundled cable's state has changed and then generate your own event for that by making use of os.queueEvent.

Edit: Just to prevent any misunderstanding: Everytime redstone signals change, the "redstone" event is created which you'd then use to create your custom event, along with the changes that actually occurred within the bundled cable in question.

Edit 2: Here's a little example of how you could achieve this (although as you will notice, I didn't make use of os.queueEvent at all^^).
Take e.g. this code…

local tCableState = {}  -- Holds the state of all bundled cables on the computer.

-- Get the current state for all 6 sides.
for _, v in pairs( rs.getSides() ) do
  tCableState[ v ] = rs.getBundledInput( v )
end

-- If a bundled cable changes its state, then this function returns the event 'bundled_cable' and a table.
-- The returned table contains only sides that have changed and it has this format: { side = { new_value, old_value } }
function pullEvent()
  local bStatesChanged = false
  local tChangedCables = {}
  local event, p1, p2, p3, p4, p5 = os.pullEvent()
 
  if event == "redstone" then
    -- Iterate over all 6 sides of the computer.
    for _, v in pairs( rs.getSides() ) do
	  local nBCInput = rs.getBundledInput( v )  -- Get cable input for current side.
	  if  nBCInput ~= tCableState[ v ] then  -- Has the state changed?
	    tChangedCables[ v ] = { nBCInput, tCableState[ v ] }  -- Add the changed side + its new and old values to the return table.
	    tCableState[ v ] = nBCInput  -- Update the local state table.
	    bStatesChanged = true
	  end
    end
  end
 
  -- Turn the 'redstone' event into a 'bundled_cable' event if the state of a bundled cable has changed.
  if bStatesChanged then
    event = "bundled_cable"
    p1 = tChangedCables
  end
 
  return event, p1, p2, p3, p4, p5
end

… and save it as 'bc' or something.
We're going to use this as an API, to save the state of the bundled cables across programs.

Then make another program with this example-code and replace 'bc' (at beginning and middle of the code) with whatever you named the API above…

-- Load API
if not os.loadAPI( "bc" ) then
  error( "Bundled-Cable Event API could not be loaded. :unsure:/>/>" )
end

while true do
  local sEvent, p1, p2, p3, p4, p5 = bc.pullEvent()  -- Here we call our customized event listener bc.pullEvent(), instead of os.pullEvent()

  if sEvent == "bundled_cable" then
	-- p1 will contain a table with all the sides that have changed, mapped to their new and old values, i.e. p1 := { "side" = { new_value, old_value } }
	local new = 1
	local old = 2
	for side, tValue in pairs( p1 ) do
	  print( "\""..side.."\" has changed from "..tValue[ old ].." to "..tValue[ new ] )
	end
  end

  if sEvent == "char" and string.lower( p1 ) == "q" then break end
end

Start it and change the state of some bundled cables.
It should tell you exactly what cable changed and to what it changed.
bc.pullEvent function returns a table with key = side ( that changed ), value = { new value, old value }.
Writing this it just came to my mind that it might be useful to return the former state, which would just be a trivial change in the code.
If you find the above code useful at all for your purposes and would like to have the former state of the bundled cable be returned as well, just give me a holler. B)/>/>

Edit: I've changed the return table, so that now it not only contains the new but also the old value.
Edit: Changed tCableState to not use a numerical index for its keys, but the side-strings of rs.getSides()

Esper, i friggin love you man(pause)…you don't know how much this forums needs and appreciates you. Just the small stuff like this…

FuzzyPurp, on 04 March 2012 - 12:18 AM said:

Esper, i friggin love you man(pause)…you don't know how much this forums needs and appreciates you. Just the small stuff like this…

*headscratch*
Hmm, I never know what to say to something like that. Thx? I guess?
I'm sorry if my reaction doesn't seem appropriate, but my mind didn't come with a proper compliment() function. It doesn't return any values, so I have no idea what to say when someone calls that function. I hope you don't mind. :unsure:/>/>
I'm glad you find it useful though. Just trying to contribute to the idea pool when I can, and I'm always looking forward to other people's ideas.

You attempted to index a nil value! lmao

Thanks for the code ESPER, but i dont think it even generated a "redstone" event. i need to verify this.

Found this topic looking for the very thing in the OP. Been trying to create a detector for machines, and ic storages. Thanks!

With regards to ideas; I always think in terms of what practical but hopelessly complex devices or information can be created and reported on? Since so many of us find ourselves in complex environments with BC/IC, and given the total amount of information one could pull out with redpower mod; why not construct a matrix for 1. control 2. messengers & information 3. automation. The lines are a bit blurred because of the nature of their integration.

Figure 6 pages (for 6 bundled input sides) of control and status indications. Perhaps a page (bundled cable line) could have two modes; controller (sends commands) or reporter/messenger (for tripping banks of lights/displays or audible alerts via noteblocks) – or triggering events across terminals or via circuits.

Sounds as if such a matrix could end up becoming a network of MC Super Computers which are likely to become sentient… since it would a. automate, count, sort, and serve your food; mine & manufacture your tools & armor, convert raw materials into useful resources, control power distribution, and facility security & lighting …it may one day choose to kill you by ceasing food production, opening all the doors, and turning off all the lights. Come to think of it, this should also be a mode. …or even a gamemode.

sleep(10000)
BaseAI do(kill_residents)

Anyway, the example turned story is more of a use case for having a complex series of commands, controls, triggers, and information at your fingertips. A process for controlling your in-game process and gives you solid control & metrics. I think it would be a considerable challenge, at least for me.

Sounds like a fun project; something I'm going to attempt as I learn.

vvenaya, on 04 March 2012 - 10:25 AM said:

Thanks for the code ESPER, but i dont think it even generated a "redstone" event. i need to verify this.

No problem, glad to help. And I tested it beforehand, bundled cables definitely produce a 'redstone' event.
But please do test it, I'd appreciate any ideas to improve or add to it. B)/>/>

Evis, on 04 March 2012 - 11:04 AM said:

-snip-

Sounds like a fun project; something I'm going to attempt as I learn.

As long as you take your time to create something solid and useful out of your idea, I'd say go for it!
And if it furthers your understanding and knowledge along the way, even better. :unsure:/>/>

Hello Espen,

the code works very well but i am stuck on a way to get the color of the changed cable. Goal would be to record the state change of an Item pipe to count the items going through using redstone event and bundled cable.
I think the picture describes it best.


EDIT: i found the solution.

…
for side, tValue in pairs( p1 ) do
print(colors.test(redstone.getBundledInput(side), colors.white)) – returns true
print( """..side.."" has changed from "..tValue[ old ].." to "..tValue[ new ] )
end

…