Redstone...

[rs2k]

Any ideas?

My guess is on every server tick the server checks every power giving redstone device for redstone wires up to X distance and follows them giving power to any device it's attached to within that distance?

[FakeTruth]

My guess is the same as you, but instead of every tick only when the circuit changes

[rs2k]

so, an on_circuit_change() class called whenever someone places a redstone torch, uses a lever or button/pressure plate, a block is changed within 1 square of a redstone device then?

Something like:
the class will check all blocks within 1 square doing something different for vertical blocks based on the device in the center square.
If a redstone device in that square is changed it calls the class again on the new square with a direction or position put into the class.


Something like a repeater will have to call the class after X server ticks based on what its setting is.


The class will change the redstone meta device meta data and move on if needed.

[rs2k]

What functions might there already be in place for a block to look at the contents of the blocks around it?

[rs2k]

Recursive, or something else? It won't be too difficult to make redstone work recursively, just really annoying. I've already figured out how to make a new redstone torch update all redstone wires around it. Have to think of a way to avoid infinite loops though.

What about something else though?

All wires belong to a virtual circuit.

Example:
2 redstone wire blocks at 0, 0, 120 and 1, 0, 120 belongs to virtual wire 1211 that connects to device piston 120 and power device redstone torch 219

if power device 219 turns off and no other virtual power devices are attached to virtual wire 1211, then all redstone wire in virtual wire 1211 are set to meta value 0 (off state). and all devices attached to virtual wire 1211 are checked for other power sources, if none are found then the device is turned off.

I can find a way to make this work with MySQL and PHP, and I'm positive there's a way to make it work with c++, I'm, just not sure how yet. I read something about has tables that might do the trick.

Each "state change event" should only happen once per tick or the server will do nothing but update redstone wires. I'm pretty sure this is how the notch server works which is what causes the lag when using repeaters. The problem with the notch server is the 16 wire length because of the recursive nature of his redstone design. The virtual circuit would eliminate that problem since the circuit won't care if the blocks are 16 or 16,000 blocks away. It will only calculate changes based on the devices attached to the wire being changed, not every 32 blocks per redstone device.

I'm not sure how you would import a redstone circuit yet. I guess when an unattached redstone device was found the redstone class would need to recursively recalculate the entire circuit all at once and load it as a new virtual circuit.

Virtual redstone circuits would either need to be saved in a file, or recalculated and put into memory every time the server was started. I think the later would be the safest way to do it, but would cause lag on VERY large circuits.

[FakeTruth]

Are you sure you want the redstone to behave differently in MCServer? AFAIK redstone is just a floodfill with special behaviour calculated for special blocks at the beginning/end of each tick

[rs2k]

I started with the recursive 4-point x 3 vertical planes fill method for redstone wire. The current logic is rather dumbed down, but it's a start.

I started with functions placed in cClientHandle.cpp to see if it would work, I then attempted creating a cRedstone class by looking at other class files FakeTruth created. This is my first real C++ class, so I'm sure I did a lot wrong. Any advice to clean it up would be greatly appreciated. IT does work at the very least.

I haven't added it to VC2010 yet. I really need to get my programming programs more in line with this project. What do you use to create the makefile with? I've been modifying it and the VC2010 files by hand. I'm also using nano and vim quite a bit which is probably messing up some of the tabs. I'm going to most likely change my test environment to VirtualBox for linux while keeping the more stable versions for the linux server. Once the project gets to a certain point (before minecraft 1.0 is released I hope) I intend to keep a 24/7/356 server up on my linux server.

[FakeTruth]

Just some things I noticed

Code:

Redstone.cRedstone::ChangeRedstoneTorch( PacketData->m_PosX, PacketData->m_PosY, PacketData->m_PosZ, false );
Should be written as
Redstone.ChangeRedstoneTorch( PacketData->m_PosX, PacketData->m_PosY, PacketData->m_PosZ, false );

You do this in many places

________________________________

You store a cWorld pointer in the cRedStone class, but still you use cRoot::Get()->GetWorld() to get a world pointer... You can simply use m_World, because that's where you stored it.

Code:

cClientHandle.cpp:
cRedstone Redstone(m_Player->GetWorld());

cRedstone.cpp:
cRedstone::cRedstone( cWorld* a_World )
        :m_World ( a_World ) // This is the same as writing m_World = a_World; but faster
{
}
...
void cRedstone::ChangeRedstoneTorch( int fillx, int filly, int fillz, bool added )
{
...
        cWorld* World = cRoot::Get()->GetWorld();
...
}

___________________________

I just manually edit the makefile with a text editor, and the Visual Studio project is edited through Visual Studio

Alright, carry on

[rs2k]

I forgot to make that change to cRedstone.cpp and included the same problem in cPiston.cpp. Oops


I think the redstone class should be changed to not update blocks, but to build a queue of blocks that need to be changed and send all the blocks that need to be changed to the world tick queue.

Anyone else have any ideas on this?

Also, now that I have a working fill algorithm, I should probably change it to a more efficient one. I used the easiest one to program in as a proof of concept. Currently, a 10x10x1 block of redstone requires 344 block replacements instead of just 100, and I don't know how many times it checks each block. Probably more than 344 times

[rs2k]

Success!

Redstone torches can now be used as a NOT gate and you can create redstone clocks. Redstone torches that are to be updated join a queue that the world tick goes through. The queue is pretty inefficient right now as a torch can be placed in it several times. The whole recursive nature of this style of redstone is really inefficient, but it works.

Still need to update several redstone device to work correctly when found and placed into a circuit. (Torches aren't completely done)