Working on redstone sulfur cube

[PainterFlow]

---

^{Need help on this PR? Tag /codesmith with what you need. Autofix is disabled.}

---

Summary by cubic

Add entity-powered redstone. Sulfur Cubes now emit power 15 when carrying/swallowing a redstone block, and circuits can read signals from entities overlapping a block.

• New Features
  • Entities can store and emit redstone power (0–15) via vsq:powerRedstone (saved to NBT).
  • Signal checks include entity power by scanning the block AABB and taking the max with block power for both indirect and direct signals.
  • Server levels track a powered-entity count to skip scans when there are no powered entities.
  • Neighbor updates fire when an emitting entity’s bounds or power changes, and on removal.
  • Sulfur Cube sets power from its BODY slot: minecraft:redstone_block → 15, else 0; updated on AI tick and load. Tags added: sulfur_cube_swallowable and sulfur_cube_archetype/fast_flat with minecraft:redstone_block.

^{Written for commit 5342c18. Summary will update on new commits.}

[PainterFlow]

/codesmith

[blacksmith-sh]

I'm on it! Give me a moment to analyze the code and I'll respond shortly.

 

_{For changes to be attributed to you in commits, consider linking your GitHub account to Blacksmith.}

[blacksmith-sh]

Reviewing redstone sulfur cube PR context

[blacksmith-sh]

@PainterFlow

/codesmith

Reviewed the redstone sulfur cube change end to end. Since this repo has no CI, I set up a JDK, built it, and booted a dedicated server to actually exercise the mixins. Good news first: it compiles, and a server boots cleanly on Minecraft 26.2 / Fabric Loader 0.19.3 with all three mixins applied and no injection errors (ran 60s idle, then I stopped it). I also verified against the 26.2 remapped jars that every @Inject target exists with the right signature: Entity#load/saveWithoutId/onRemoval/tick, Mob#customServerAiStep(ServerLevel), Level#updateNeighborsAt(BlockPos, Block, Orientation), Level#getEntities(Entity, AABB, Predicate), and SignalGetter#getSignal/getDirectSignal. The last two are default methods and neither Level nor ServerLevel overrides them, so the interface injection genuinely lands on server signal lookups.

A few things worth your attention, roughly in priority order:

1. Performance: entity scan on the two hottest redstone primitives. SignalGetterMixin adds a getEntities(...) AABB query (plus a fresh new AABB(pos) and a lambda) to every getSignal and getDirectSignal call, unconditionally. Those are called constantly during redstone propagation, and right now everyone pays the entity-lookup cost on all their redstone even when no entity in the world is carrying power. Consider a fast path: keep a per-ServerLevel count (or set) of powered entities and short-circuit to the vanilla return when it's zero, so the common case stays free. VSQEntityRedstonePower already has the natural choke points to maintain that counter (set/clear on power change, tick, and removal).

2. Behavior: getDirectSignal makes it a strong power source. A real block of redstone only emits weak power (it powers adjacent dust/components but does not strongly power a solid block through to the far side). By augmenting getDirectSignal as well as getSignal, a sulfur cube overlapping a solid block will strongly power that block, i.e. it's stronger than the redstone block it's swallowing. If the goal is to mimic a redstone block, only getSignal should be augmented; if "strong omnidirectional 15" is the actual intent, that's fine, but it diverges from vanilla so it's worth a deliberate call given the "preserve vanilla behavior" guideline.

3. Missing tag translations (guideline). The two new item tags have no en_us entries, which trips the Fabric warnings your guidelines call out (you already translate sulfur_cube_food). I prepared the fix but couldn't push it: workingOnRedstoneSulfurCube is a protected ref and the push was rejected by a repo rule. Ready to apply (the / in the archetype path becomes .):

"tag.item.minecraft.sulfur_cube_swallowable": "Sulfur Cube Swallowable",
"tag.item.minecraft.sulfur_cube_archetype.fast_flat": "Sulfur Cube Fast Flat Archetype",

4. Minor nits.

• In VSQEntityRedstonePower#getSignal, the predicate's entity.getBoundingBox().intersects(blockBounds) is redundant. getEntities(entity, aabb, predicate) already returns only entities whose bounding box intersects aabb.
• EntityRedstonePowerMixin#vsq$initEntityRedstonePower just sets the fields to their default 0/null, which Java already does, so the <init> inject can be dropped.
• SulfurCubeMixin has two @Inject(method = "customServerAiStep", at = TAIL) handlers; harmless, but they could be merged.

Want me to implement 1, 2, and 4 and land the translations? Since the branch is protected, I'd open a PR into workingOnRedstoneSulfurCube (or main, your call) rather than pushing to it directly.

[PainterFlow]

I will tackle this tomorrow, its lwk too hot atm

[PainterFlow]

all 4 things need to be fixed tho

[PainterFlow]

/codesmith

[blacksmith-sh]

@PainterFlow

/codesmith

Picking this up from where we left off. Your 89d268c closed out items 1, 3, and 4, so the two things outstanding were item 2 (the getDirectSignal strong-power behavior) and the counter data race I flagged in the last pass. I fixed both, and validated: it compiles and a dedicated server boots cleanly on 26.2 with all mixins applied and no injection errors.

What changed (two files):

• SignalGetterMixin: dropped the getDirectSignal injection. A block of redstone is a weak-power source only (it powers adjacent dust/components but does not strongly power a solid block through to its far side). Now only getSignal (weak power) is augmented, so a swallowed redstone block behaves like the real thing instead of being a stronger, strong-power source.
• ServerLevelMixin: the powered-entity counter is now an AtomicInteger instead of a plain int. Entity deserialization (Entity#load -> reconcile -> incrementPoweredEntityCount) runs on EntityStorage's background deserializer thread, so the old plain-int increments raced with the main-thread tick/removal/signal reads. incrementAndGet/updateAndGet/get make it safe (no lost updates, no stale reads), which keeps the hasPoweredEntities fast path correct.

I could not open a PR: the repo rulesets block both paths. Pushing to workingOnRedstoneSulfurCube is rejected (protected ref), and creating a new branch is rejected too ("creations being restricted"). So here is the patch to apply on your branch (from the repo root, git apply this, or just make the edits by hand):

diff --git a/src/main/java/blob/vanillasquared/mixin/world/ServerLevelMixin.java b/src/main/java/blob/vanillasquared/mixin/world/ServerLevelMixin.java
index 6254359..1fffb3a 100644
--- a/src/main/java/blob/vanillasquared/mixin/world/ServerLevelMixin.java
+++ b/src/main/java/blob/vanillasquared/mixin/world/ServerLevelMixin.java
@@ -11,12 +11,16 @@ import org.spongepowered.asm.mixin.injection.At;
 import org.spongepowered.asm.mixin.injection.Inject;
 import org.spongepowered.asm.mixin.injection.callback.CallbackInfo;
 
+import java.util.concurrent.atomic.AtomicInteger;
 import java.util.function.BooleanSupplier;
 
 @Mixin(ServerLevel.class)
 public abstract class ServerLevelMixin implements VSQEntityRedstonePowerLevelAccess {
+    // Entity deserialization runs off the main server thread (EntityStorage's background
+    // deserializer queue), so this counter is mutated concurrently with the main-thread
+    // tick/removal/signal paths. Use an atomic to avoid lost updates and stale reads.
     @Unique
-    private int vsq$poweredEntityCount;
+    private final AtomicInteger vsq$poweredEntityCount = new AtomicInteger();
 
     @Inject(method = "tick", at = @At("TAIL"))
     private void vsq$tickChanneling(BooleanSupplier haveTime, CallbackInfo ci) {
@@ -27,18 +31,16 @@ public abstract class ServerLevelMixin implements VSQEntityRedstonePowerLevelAcc
 
     @Override
     public int vsq$getPoweredEntityCount() {
-        return this.vsq$poweredEntityCount;
+        return this.vsq$poweredEntityCount.get();
     }
 
     @Override
     public void vsq$incrementPoweredEntityCount() {
-        this.vsq$poweredEntityCount++;
+        this.vsq$poweredEntityCount.incrementAndGet();
     }
 
     @Override
     public void vsq$decrementPoweredEntityCount() {
-        if (this.vsq$poweredEntityCount > 0) {
-            this.vsq$poweredEntityCount--;
-        }
+        this.vsq$poweredEntityCount.updateAndGet(count -> count > 0 ? count - 1 : 0);
     }
 }
diff --git a/src/main/java/blob/vanillasquared/mixin/world/redstone/SignalGetterMixin.java b/src/main/java/blob/vanillasquared/mixin/world/redstone/SignalGetterMixin.java
index 9fa454c..e1a0ef1 100644
--- a/src/main/java/blob/vanillasquared/mixin/world/redstone/SignalGetterMixin.java
+++ b/src/main/java/blob/vanillasquared/mixin/world/redstone/SignalGetterMixin.java
@@ -12,6 +12,9 @@ import org.spongepowered.asm.mixin.injection.callback.CallbackInfoReturnable;
 
 @Mixin(SignalGetter.class)
 public interface SignalGetterMixin {
+    // A block of redstone is a weak power source only: it powers adjacent components/dust but
+    // does not strongly power a solid block. Mirror that by augmenting getSignal (weak power)
+    // only, and leaving getDirectSignal (strong power) untouched.
     @Inject(method = "getSignal", at = @At("RETURN"), cancellable = true)
     private void vsq$getEntityRedstoneSignal(BlockPos pos, Direction direction, CallbackInfoReturnable<Integer> cir) {
         SignalGetter signalGetter = (SignalGetter) this;
@@ -19,12 +22,4 @@ public interface SignalGetterMixin {
             cir.setReturnValue(Math.max(cir.getReturnValue(), VSQEntityRedstonePower.getSignal(level, pos)));
         }
     }
-
-    @Inject(method = "getDirectSignal", at = @At("RETURN"), cancellable = true)
-    private void vsq$getDirectEntityRedstoneSignal(BlockPos pos, Direction direction, CallbackInfoReturnable<Integer> cir) {
-        SignalGetter signalGetter = (SignalGetter) this;
-        if (signalGetter instanceof ServerLevel level) {
-            cir.setReturnValue(Math.max(cir.getReturnValue(), VSQEntityRedstonePower.getSignal(level, pos)));
-        }
-    }
 }

If you'd rather I open the PR directly, let the Blacksmith bot create branches (or push to this one) in the repo ruleset and re-ping me, and I'll push it up. With this applied, all four original items plus the concurrency regression are resolved.

[PainterFlow]

@mizius-bot review and give me all issues immediately

[mizius-bot]

Summary

This PR adds entity-powered redstone to VanillaSquared: entities can store and emit a redstone signal (0–15) via a new vsq:powerRedstone NBT field, and Sulfur Cubes automatically emit power 15 when their BODY slot holds a redstone block. Signal queries in SignalGetter are extended to scan entity AABBs, and a per-level powered-entity counter enables an early-exit optimisation when no powered entities exist.

• Entity power storage & count tracking (EntityRedstonePowerMixin, ServerLevelMixin): NBT persistence, increment/decrement bookkeeping, and level-change handling look correct. Unconditional 2-tick neighbor updates fire even for completely stationary entities, which can cause unnecessary redstone recalculations in complex circuits.
• Signal injection (SignalGetterMixin): Both getSignal and getDirectSignal correctly take the max of block and entity signals, gated by the powered-entity count optimisation.
• Load-order interaction (SulfurCubeMixin + EntityRedstonePowerMixin): vsq$setRedstonePowerForContent runs at readAdditionalSaveData TAIL, but vsq$loadEntityRedstonePower runs at Entity.load() TAIL (which wraps readAdditionalSaveData), so the NBT value overwrites the derived value; a freshly upgraded entity without the NBT key loads with power 0 for one tick.

_{Reviewed & summarized for commit 89d268c.}

[PainterFlow]

@mizius-bot review and give me all issues immediately

[mizius-bot]

Summary

This PR introduces entity-powered redstone by adding a vsq:powerRedstone NBT attribute to all entities (0–15), hooking it into the SignalGetter interface so redstone circuits can read signal strength from entities overlapping a block, and wiring Sulfur Cubes to emit power 15 when their BODY slot contains a redstone block.

• New infrastructure (VSQEntityRedstonePower, VSQEntityRedstonePowerAccess, VSQEntityRedstonePowerLevelAccess) tracks a per-level powered-entity count so signal queries short-circuit to 0 when no powered entity exists, keeping the hot path cheap.
• EntityRedstonePowerMixin adds NBT persistence, a reconcile/unregister counter lifecycle on every entity, and fires updateNeighborsAt every 2 ticks and on movement/removal to keep adjacent redstone in sync.
• SulfurCubeMixin derives power from the BODY slot item (redstone block → 15, else 0) on each AI tick and on load; two new item tags (sulfur_cube_swallowable, sulfur_cube_archetype/fast_flat) and matching en_us translations are added.

_{Reviewed & summarized for commit 89d268c.}

[PainterFlow]

@mizius-bot review and give me all issues immediately

[mizius-bot]

Summary

This PR introduces entity-powered redstone: entities can now emit redstone signal (0–15) stored via NBT, and a Sulfur Cube emits power 15 when its BODY slot holds a redstone block. The SignalGetter interface is extended so both direct and indirect signal queries include entity contributions, gated by a per-level powered-entity counter to avoid scans when no powered entities exist.

• EntityRedstonePowerMixin adds load/save, power bookkeeping, and per-tick neighbor-update logic to all entities; ServerLevelMixin tracks the powered-entity count.
• SignalGetterMixin injects into getSignal/getDirectSignal on ServerLevel to merge entity signals with block signals.
• SulfurCubeMixin wires the BODY-slot item check into customServerAiStep and readAdditionalSaveData; two new item tags and their translations are also added.

_{Reviewed & summarized for commit 5342c18.}

[pxlarified]

@mizius-bot review

[mizius-bot]

Summary

This PR adds entity-backed redstone behavior for sulfur cubes. The main changes are:

• Entity redstone power storage and NBT persistence.
• Server-level tracking for powered entities.
• Signal lookup that includes powered entities overlapping a block.
• Sulfur cube redstone-block power resolution.
• New sulfur cube item tags and translations.

_{Reviewed & summarized for commit 80bc52a.}

[pxlarified]

@mizius-bot review

[mizius-bot]

Summary

This PR adds entity-based redstone power for Sulfur Cubes. The main changes are:

• New entity redstone power storage and NBT persistence.
• Server-level powered-entity counting and signal scanning.
• Redstone signal mixins that include overlapping powered entities.
• Sulfur Cube BODY-slot power from redstone blocks.
• New sulfur cube tags and translations.

_{Reviewed & summarized for commit 39c775c.}

[pxlarified]

@mizius-bot review

[pxlarified]

@PainterFlow, please run ingame tests to verify that everything still works as intended, then the pull request can be merged.

[mizius-bot]

Summary

This PR adds entity-powered redstone for Sulfur Cubes. The main changes are:

• New entity redstone power storage and NBT persistence.
• Server-level powered-entity counting to skip unnecessary scans.
• Redstone signal reads that include powered entities overlapping a block.
• Neighbor updates when powered entity bounds or power changes.
• Sulfur Cube tags and translations for redstone block swallowing.

_{Reviewed & summarized for commit 98cf7cc.}

[mizius-bot]

Body Power Updates Lag

When the Sulfur Cube body slot changes outside customServerAiStep, the stored redstone power is not refreshed until the next AI tick. During that tick gap, circuits can read the old entity power and neighbors are not notified at the time the carried block actually changes.

Context Used: AGENTS.md (source)

[mizius-bot]

Abstract Interface Super Call

This override calls SignalGetter.super.getSignal(...), but getSignal(BlockPos, Direction) is the signal contract that worlds implement rather than a default helper body. When this mixin is compiled or applied, the interface-super call has no concrete method to dispatch to, so the mod can fail to build or start.

Context Used: AGENTS.md (source)

[mizius-bot]

Entity Power Becomes Strong Power

This adds the entity signal to getDirectSignal the same way as getSignal, so an entity overlapping a block makes that position look like it strongly powers every queried direction. Redstone dust and components that use direct signal checks can then be powered through a neighboring position as if there were a strong power source there, instead of only reading the entity signal at the intended block.

[mizius-bot]

Dimension Move Uses Stale Bounds

When a powered entity changes to another ServerLevel, this branch unregisters the old level and registers the new one but leaves vsq$previousRedstoneSourceBounds pointing at the old level's coordinates. On the first tick after the move, the bounds-change path can notify those old coordinates in the new level instead of clearing the redstone neighbors in the level the entity left, leaving circuits in the old dimension stale until another block update reaches them.