Question about transferring 'signals'

Hi, I want to make a way to have a bunch of different cubes, and a signal could start on any cube, and a signal would travel down the line. The issue is that if I just use basic methods to transfer signals, it will sporadically travel back and forth through the same line, and it won't work...Can someone help?

 

What is a "signal" in this context? Do these cubes have some script on them that you want to invoke in turn, or do you want them to change color, or what?

Also, do you want this signal propagation to happen immediately, all in one frame? Or do you want it to happen slow enough that the player can see it?

 

Sorry, I should have been more clear. In my context, a 'signal' would just be a cube propagating a boolean to all of the ones around it. So, for example, if a cube was on, it would set a variable in all of it's neighbours to true. Not immediately, but maybe every quarter second or so. The issue with this, though, is that the signal would easily propagate back and forth between two cubes

 

That's true. But maybe it only transmits the signal when its status actually changes? So cube A goes from false to true; it tells neighbor B to do the same. Cube B goes from false to true, so it tells cubes A and C to be true. But cube A sees that it was already set to true, so it does nothing.

Do you know how to code this, or are you still stuck?

 

I know how to code this; I guess what you mean is to make it so that it can only turn on every other quarter second?

 

Right, your Signal or CubeState or whatever script will have a "nextUpdateTime" property, which is the Time.time at which it should update its neighbors. When the state is changed, set this to Time.time + 0.25f. And when TIme.time > nextUpdateTime, update your neighbors.

Or at least, that's one way to do it.

Another way — which would be more like how actual computers work — would be to have a global master clock. This would actually do two things on each clock cycle: first, it would tell all cubes to compute their next state; and then, it would tell all cubes to actually update to the previously-computed state. And it would do these things every 0.25 second (or whatever update rate you want). This approach avoids race conditions and makes sure that, for example, signals don't propagate more reliably in one direction than the other.