Redstone Simulator Blocks Placed/Destroyed

[keyboard]

Hi All,

I'm finally back! sorry I've been away from the forums. It's just that there were big changes in my life this last couple of months. But anyway, I'm back!

So going back to business, redstone simulator. I've been working on the simulator to make it event based, and I noticed something that I wish to ask you guys opinions. Currently simulators only get notified of a change via the check function in the block handler. This function calls the Wake Up functions on all simulators in order to signal them. The only issue that I see is that simulators doesn't really know if a block was being placed or destroyed or modified, they only know that they are being wake up due to a change. So I wanted to propose that we add some functions to the base class of the simulators in order to handle these events and also to add the calls to the block handler. I was thinking of something like this on the base class of simulator:

BlockPlaced(int a_BlockX, int a_BlockY, int a_BlockZ);
BlockDestroyed(int a_BlockX, int a_BlockY, int a_BlockZ);

and also we would leave WakeUp function to be called during checks. So the idea is that when a block is placed, BlockPlaced is called on all simulators for the placed block, and the WakeUp function is called for all the neighbors. The same would be true when the block is destroyed except that BlockDestroyed would be called instead of BlockPlaced.

What do you guys think?

[xoft]

Hi, welcome back!

I'm wondering, for what reasons would you need such information.

Also, with the multithreaded nature of things, it is possible (though improbable) that multiple changes occur at the same block before the simulator has the chance to react. Would the type-of-change information be useful in such a case?

Also, simulators are (still, I know I'm slow here) planned for quite a rewrite - they'd gain access to raw chunk data, without the need of querying through cWorld or cBlockArea; they will be run as part of the Tick thread while the entire world is locked. Therefore they will also need a per-chunk storage of "events" so that processing is fast enough.

[keyboard]

Hi xoft,

Thanks for your reply!

well, the reason is to properly calculate what the simulator should do in each case (placing a block, destroying a block, changing metadata, block updates) instead of the simulator trying to figure out what happened and then decide what to do. For example, it's easier for a redstone torch to signal the stop of a redstone current when the torch is destroyed than for a redstone wire to determine if it still has, by looking at all its neighbors, a power source that it is providing power every time there is a block update.

I think that in the case of multiple changes before the simulator has a chance to react, I don't think it will help any extra. It will help in a sense that each event is processed faster since each device knows what happened. Also, I was planning the simulator to have a queue of events that get processed per tick (kind of like the current Redstone simulator is).

Also, I was also planning to implement the device handlers (base class, and subclass for each device, like torches, wire, etc...) the same way we are implementing blocks. So they are not storing any data specific to any coordinates. They only implement the behavior of each device type. These handlers only interface to cWorld by making calls to the simulator. This way any world update goes through the simulator so it can be easily converted to supporting chunk updates by creating one simulator object per chunk.