Added Buffers (item and power) #455
No reviewers
Labels
No labels
Area-Assets
Area-Backend
Area-Conduits
Area-Datapacks
Area-Lang
Area-Mod Compat
Area-Parity
Area-Rendering
Good first issue
MC-1.19.2
MC-1.20.1
MC-1.20.4
MC-1.20.6
MC-1.21
MC-1.21.1
Modtoberfest
P-0-High
P-1-Medium
P-2-Low
Status-Awaiting Response
Status-Behind-Flag
Status-Blocked
Status-Cannot Reproduce
Status-Duplicate
Status-Help Wanted
Status-Incomplete Report
Status-Invalid
Status-Needs LTS Backport
Status-Needs Updating
Status-Stale
Status-To Implement
Status-Triage
Status-Wontfix
Status-Wontmerge
Type-Backport
Type-Bug
Type-Documentation
Type-Enhancement
Type-Question
Type-RFC
Type-Suggestion
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Team-EnderIO/EnderIO#455
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "my6.0.11"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Description
I've been absent for a long time now but I've been following your amazing bug fixing adventures...
During this time I worked on buffers (Item + Power) which allows the player to have a 3x3 item buffer and a power buffer that allows the player to control I/O energy rates from the block.
It implements an improved version of the energy textbox widget that I showed you on PR #364 so when this gets in the code base, I will close #364.
I'm not sure about everything in my code as usual so I will be taking your suggestions into consideration :) I've commented that in the code so you will understand what I'm talking about...
Closes #150 , #364
Checklist:
Initial review :)
@ -0,0 +1,98 @@package com.enderio.machines.client.gui.screen;Probably should use lang instead of Raw string
You can probably use
onInventoryContentsChangedon BE instead of containerTick. Can someone confirm which is more performant ?@ -0,0 +1,98 @@package com.enderio.machines.client.gui.screen;Use lang
@ -0,0 +93,4 @@try {DecimalFormat decimalFormat = (DecimalFormat) NumberFormat.getInstance(Locale.ROOT);decimalFormat.applyPattern("#,###");What happens when we use big numbers like 1M? Maybe future proof it since the widget can be used somewhere else
@ -0,0 +1,240 @@package com.enderio.machines.common.blockentity;Put NBT keys in CoreNBTKeys file
@ -0,0 +93,4 @@try {DecimalFormat decimalFormat = (DecimalFormat) NumberFormat.getInstance(Locale.ROOT);decimalFormat.applyPattern("#,###");I tested this function in a normal java program just to see how the decimal format behaves and it works fine with bigger numbers
@ -0,0 +1,98 @@package com.enderio.machines.client.gui.screen;I don't think so, we are not updating the inventory when updating I/O rates
@ -0,0 +1,98 @@package com.enderio.machines.client.gui.screen;my bad. use Editbox setResponder()
@ -0,0 +1,98 @@package com.enderio.machines.client.gui.screen;I've implemented a version with the setResponder().
However now it updates whenevr a new value is in the textbox but I want them to be updated if and only if the textbox is not selected meaning that the player has fisnished setting the value
We might go back to this version and improve it if we cannot do this we the responder
@ -0,0 +1,98 @@package com.enderio.machines.client.gui.screen;you dont need this anymore. instead create 2 functions where you set input and output values to BE and use these functions as EditBox responders
@ -0,0 +1,98 @@package com.enderio.machines.client.gui.screen;Yes this is what was done.
But I need this to automatically reset and format (to have comma separator ) the content to 0 or max energy use when the player removes or upgrade capacitor
@ -0,0 +1,98 @@package com.enderio.machines.client.gui.screen;Yeah do all of that in the functions not in containerTick
@ -44,0 +44,4 @@public static final String BUFFER_MAX_INPUT = "BufferMaxInput";public static final String BUFFER_MAX_OUTPUT = "BufferMaxOutput";Use Generic ENERGY_MAX_RECEIVE and ENERGY_MAX_EXTRACT instead.
@ -0,0 +59,4 @@@Overridepublic boolean mouseClicked(double mouseX, double mouseY, int button) {if (mouseX >= getX() && mouseX <= getX() + width && mouseY >= getY() && mouseY <= getY() + height) {super.mouseClicked(mouseX, mouseY, button);Are you sure this mouseClicked result can be ignored?
@ -0,0 +93,4 @@try {DecimalFormat decimalFormat = (DecimalFormat) NumberFormat.getInstance(Locale.ROOT);decimalFormat.applyPattern("#,###");Look into
EditTextBox#formatterandFormattedSequence. Is that something that should be used instead?@ -0,0 +110,4 @@if (mouseX >= getX() && mouseX <= getX() + width && mouseY >= getY() && mouseY <= getY() + height && !isFocused() && maxEnergy.get() != 0) {guiGraphics.renderTooltip(displayOn.getMinecraft().font, Component.literal(getValue() +"/" + maxEnergy.get() +" µI/t"), mouseX, mouseY);}}Not required anymore
@ -0,0 +54,4 @@addDataSlot(outputDataSlot);inputTextDataSlot = new StringNetworkDataSlot(this::getMaxInputText, input -> inputTextValue = input);outputTextDataSlot = new StringNetworkDataSlot(this::getMaxOutputText, output -> outputTextValue = output);Why are both the value and string form synced separately ?
@ -0,0 +100,4 @@if (level != null && level.isClientSide) {clientUpdateSlot(outputTextDataSlot, maxOutputText);} this.outputTextValue = maxOutputText;}There is no point in syncing the text. It should be completely client sided. The server needs to know only the final Integer.
@ -0,0 +139,4 @@}} else {if (otherHandler.get().canReceive()) {dirs.add(side);Will this take care of neighbors being full or empty ?
@ -0,0 +175,4 @@int received = otherHandler.get().receiveEnergy(Math.min(energyPerSide, getExposedEnergyStorage().getEnergyStored()), false);// Consume that energy from our buffer.getExposedEnergyStorage().extractEnergy(received, false);Shouldn't these be simulated first ?
@ -130,4 +131,4 @@builder.pop();builder.push("drain");Usage/Consumption ?
Will not be merged into dev/1.20.1 - needs rebasing on 20.4+ to for this :) (I know you're likely busy - I'm writing this for tracking purposes)
Closing due to PR age - thanks for your work and I hope we're able to revisit the buffers in future :)
Pull request closed