-
Notifications
You must be signed in to change notification settings - Fork 131
feat: Remove energy throttling and evenly distribute energy #1239
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
WalkthroughAdds per-IOMode push/pull checks, removes energy input throttling, centralises machine energy distribution into TransferUtil.distributeEnergyEvenly, makes distributeResources overridable, and updates callers and storages to use the new distribution and drop input-throttling logic. Changes
Sequence Diagram(s)sequenceDiagram
participant Machine as MachineBlockEntity
participant Transfer as TransferUtil
participant Level as Level/World
participant Neighbor as NeighborBlockEntity
Machine->>Transfer: distributeEnergyEvenly(level, pos, canPushTo)
Transfer->>Level: inspect adjacent positions
loop directions where canPushTo(dir) == true
Transfer->>Machine: obtain self IEnergyStorage for dir
Transfer->>Neighbor: obtain neighbour IEnergyStorage for dir
alt both handlers present and compatible
Transfer->>Transfer: record EnergyStoragePair(self, receiver)
end
end
Transfer->>Transfer: compute total available energy from primary self handler
loop distribute until exhausted or receivers full
Transfer->>Neighbor: insert share into receiver
Transfer->>Machine: extract actual transferred energy from source
Transfer->>Transfer: update remainingEnergy and receiver state
end
Transfer-->>Machine: complete
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
enderio/src/main/java/com/enderio/enderio/foundation/block/entity/legacy/LegacyPoweredMachineBlockEntity.java (1)
198-200:shouldPushEnergyTois dead code and should be integrated into the energy distribution predicate.The
shouldPushEnergyTo(Direction)method and its overrides inSolarPanelBlockEntityandCapacitorBankBlockEntityare never called. ThepushEnergy()method uses onlyenergyIOMode.canPush(getIOMode(dir))in the distribution predicate, bypassing the multiblock check that the Javadoc indicates this method was designed to enforce.Since subclasses provide meaningful implementations for this check, integrate it into the predicate:
Suggested fix
- TransferUtil.distributeEnergyEvenly(level, worldPosition, dir -> energyIOMode.canPush(getIOMode(dir))); + TransferUtil.distributeEnergyEvenly(level, worldPosition, dir -> energyIOMode.canPush(getIOMode(dir)) && shouldPushEnergyTo(dir));
🧹 Nitpick comments (2)
enderio/src/main/java/com/enderio/enderio/foundation/io/energy/MachineEnergyStorage.java (1)
5-5: Remove unusedMachinesConfigimport.The
MachinesConfigimport on line 5 is unused after throttling logic was removed. Consider removing it to keep imports clean.Suggested cleanup
-import com.enderio.enderio.config.machines.MachinesConfig;enderio/src/main/java/com/enderio/enderio/foundation/block/entity/PoweredMachineBlockEntity.java (1)
7-7: Remove the unused IOMode import.The
IOModetype is not directly referenced in this file. AlthoughgetIOMode(dir)is called on line 145, the return value is only passed to another method without any explicit type reference toIOMode.🧹 Suggested removal
-import com.enderio.enderio.api.io.IOMode;
Shouldn't happen, but nice to be safe
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@enderio/src/main/java/com/enderio/enderio/foundation/io/TransferUtil.java`:
- Around line 151-167: The loop in TransferUtil.java uses integer division
(shareAmount = energyRemaining / toShareWith) which yields 0 for early receivers
when energyRemaining < toShareWith; change the share calculation to use ceiling
division so any remaining energy is distributed as evenly as possible (e.g.,
shareAmount = ceil(energyRemaining / toShareWith)) before calling
transfer.receiver.receiveEnergy, keep using
transfer.self.extractEnergy(inserted, false) and decrement energyRemaining and
toShareWith as before so receivers never get skipped when energy remains.
enderio/src/main/java/com/enderio/enderio/foundation/io/TransferUtil.java
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
enderio/src/main/java/com/enderio/enderio/content/conduits/type/energy/EnergyConduitTicker.java (1)
74-75: Sorting order contradicts the comment.The comment states "Try to fill smaller buffers first", but
Integer.compare(b.right(), a.right())sorts in descending order, placing handlers with larger receivable capacity first. If the intent is to fill smaller buffers first, the comparator should beInteger.compare(a.right(), b.right()).Please verify which behaviour is intended and either fix the sort order or correct the comment.
🔧 If filling smaller buffers first is intended
- // Try to fill smaller buffers first. - insertHandlers.sort((a, b) -> Integer.compare(b.right(), a.right())); + // Try to fill smaller buffers first. + insertHandlers.sort((a, b) -> Integer.compare(a.right(), b.right()));🔧 If filling larger buffers first is intended
- // Try to fill smaller buffers first. + // Try to fill larger buffers first. insertHandlers.sort((a, b) -> Integer.compare(b.right(), a.right()));
🧹 Nitpick comments (1)
enderio/src/main/java/com/enderio/enderio/foundation/io/TransferUtil.java (1)
163-168: Consider handling the case where extraction fails after successful insertion.The code assumes
extractEnergywill always succeed afterreceiveEnergysucceeds, but if extraction fails (returns less thaninserted),energyRemainingwould desync from actual available energy.This is likely a theoretical edge case given the
@apiNoteassumption of a single shared buffer, but adding a defensive check would improve robustness.♻️ Optional defensive extraction handling
int inserted = transfer.receiver.receiveEnergy(shareAmount, false); if (inserted > 0) { - transfer.self.extractEnergy(inserted, false); - energyRemaining -= inserted; + int extracted = transfer.self.extractEnergy(inserted, false); + energyRemaining -= extracted; }
4937c61 to
3253269
Compare
Description
Removes energy throttling for energy inputs and makes machines that output energy do so evenly.
Closes #1225
Breaking Changes
Generator blocks will now always output energy by default, something that used to be the case but broke when we started to rewrite machines. This is now the desired behaviour.
Checklist
Summary by CodeRabbit
Configuration Changes
New Features
Improvements
✏️ Tip: You can customize this high-level summary in your review settings.