Question
mgood7123 opened this issue ยท 7 comments
i am making my own redstone power map (basically re-implementing redstone) and i am wondering as to what areas of your code deal with what functionality in terms of power propagation, state tracking, block tracking, power source tracking, etc
this is my current implementation
https://github.com/mgood7123/Infinity-Wire/blob/main/src/main/java/smallville7123/modid_infinity_wire/client/redstone/RedstonePowerManagement.java
it is basically an implementation of redstone that does not loose it's input power over-time
i plan to add more functionality to it but the power map needs to be stable since everything will depend on it for correct power management
(basically the vanilla redstone becomes self-powering if it's decay is removed, which quickly becomes a problem as it cannot be de-powered until physically destroyed)
currently direct and indirect power sources work correctly for both wire placement/destruction and when building next to an existing wire (and then optonally destroying that wire)
(which is simply states PLACED, REMOVED, and NEIGHBOR_CHANGED)
and i have yet to implement stair-case power detection
EDIT: "shared power" has been implemented - mgood7123/Infinity-Wire@a1b9616
(per vanilla, POWER must NOT be removed from the map if it is still providing power to any existing WIRE)
eg
POWER, WIRE
WIRE
if either WIRE is removed, the POWER should not be removed because the other WIRE still relies on this POWER
Alternate Current does all its power calculations "on the fly". Most of the logic for that is in the WireHandler
class. The only areas of Vanilla code that are modified are:
RedstoneWireBlock
to intercept and replace power calculations done when a wire is placed/removed/updated.ServerWorld
a limited world view is stored here, and this world view stores theWireHandler
that does all the power calculations.- Several block classes, to add methods that check if said block can provide strong and/or weak power in a given direction.
There is no extra information stored in the world/chunks. I made this choice because it was easier to implement and in my case it had no performance penalty, since accessing information in chunks is quite slow. I did experiment with storing the networks in the chunks so they did not have to be built up every time a wire was updated, but I had validation issues which could (in obscure cases) completely mess up the network.
Alternate Current does all its power calculations "on the fly". Most of the logic for that is in the
WireHandler
class. The only areas of Vanilla code that are modified are:* `RedstoneWireBlock` to intercept and replace power calculations done when a wire is placed/removed/updated. * `ServerWorld` a limited world view is stored here, and this world view stores the `WireHandler` that does all the power calculations. * Several block classes, to add methods that check if said block can provide strong and/or weak power in a given direction.
There is no extra information stored in the world/chunks. I made this choice because it was easier to implement and in my case it had no performance penalty, since accessing information in chunks is quite slow. I did experiment with storing the networks in the chunks so they did not have to be built up every time a wire was updated, but I had validation issues which could (in obscure cases) completely mess up the network.
also you mean the Mixin's ? eg https://github.com/SpaceWalkerRS/alternate-current/blob/main/src/main/java/alternate/current/mixin/RedstoneWireBlockMixin.java
Alternate Current does all its power calculations "on the fly". Most of the logic for that is in the
WireHandler
class. The only areas of Vanilla code that are modified are:* `RedstoneWireBlock` to intercept and replace power calculations done when a wire is placed/removed/updated. * `ServerWorld` a limited world view is stored here, and this world view stores the `WireHandler` that does all the power calculations. * Several block classes, to add methods that check if said block can provide strong and/or weak power in a given direction.
There is no extra information stored in the world/chunks. I made this choice because it was easier to implement and in my case it had no performance penalty, since accessing information in chunks is quite slow. I did experiment with storing the networks in the chunks so they did not have to be built up every time a wire was updated, but I had validation issues which could (in obscure cases) completely mess up the network.
alright :) i will take a look tomorrow :)
also you mean the Mixin's ?
Yes. That particular Mixin is the most complex one, injecting code into several methods. The other Mixins just add new methods to the classes.
also you mean the Mixin's ?
Yes. That particular Mixin is the most complex one, injecting code into several methods. The other Mixins just add new methods to the classes.
why are mixin's needed?
in my one i simply calculate via signal level from existing blocks that can provide such signal instead of using mixins
also i gtg bed, talk tomorrow :)
Perhaps we should continue this conversation on my discord server. I'll close this issue for now.