-
Notifications
You must be signed in to change notification settings - Fork 179
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
Cover API rewrite #2071
Cover API rewrite #2071
Conversation
7f36bf9
to
ca3981b
Compare
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.
What is the main difference between CoverHolder and CoverableView? It feels to me like they are sort of trying to accomplish the same thing.
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.
I am unable to place covers on item pipes, specifically tested with the Large Ultimet Item Pipe and with conveyor, shutter, facade, robot arm.
As for Fluid Pipes, I can place some covers on them, however I cannot place Facade Covers on the fluid pipes.
In addition, placing a cover against a fluid pipe no longer auto connects the pipe to the cover, eg when I placed a pump against a fluid pipe, the cover was not automatically connected to the pipe. Although, using the dubug info in TOP, I think this is just rendering not getting updated for the pipe, because the open status of the pipe does change.
* @param tagCompound the tag compound to write to | ||
* @param coverableView the CoverableView containing the cover | ||
*/ | ||
public static void writeCoverNBT(@NotNull NBTTagCompound tagCompound, @NotNull CoverableView coverableView) { |
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.
This is a behavior change, as previously the covers returned their modified NBT after writing to NBT, to match with MTEs. I had changed covers to return the modified NBT after write for my eventual ™️ implementation of a copy paste tool, so I would prefer if that remained here.
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.
Can't you just store an NBT tag in a variable, pass it into the write method, and then use the tag afterwards?
default boolean canPipePassThrough() { | ||
return false; | ||
} |
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.
Why is this default false? I would think we want this to default true, as most covers allow pipes to pass through them?
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.
Pipe implementations so far have had to specifically add support for specific covers. Making this return true and then not overriding to false on all new covers may cause problems with pipes. Making it "enable only if it's supported" is a better approach in my opinion.
import org.jetbrains.annotations.NotNull; | ||
|
||
/** | ||
* Item Behavior for an Item that places a cover onto an {@link CoverHolder}. |
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.
Do we even have anything that does this?
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.
This metaitem behavior is what all cover "containing" items use to place covers onto things. See CoverBehaviors#registerBehavior
.
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.
This would get me a lot of merge conflicts for mui. So i would appreciate if it gets merged sooner rather than later.
12e51ee
to
64e746d
Compare
64e746d
to
b5e3367
Compare
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.
After updating to the latest commits, facades now are always rendered as stone when placed on pipes and machines. After leaving the world and re-entering, they rendered correctly
When attempting to place facades onto existing quantum tanks (ie tanks that were placed before this PR), they seem like they did not place onto the machine (no rendering, no top), but after leaving the world and re-entering, they are on the quantum tank. On tanks placed after checking out this branch, they do look placed, but instead render as stone like the above.
Still having issues opening cover GUIs on pipes. This was a crafting table cover on a Large Ultimet Item Pipe to be specific.
src/main/java/gregtech/api/pipenet/tile/TileEntityPipeBase.java
Outdated
Show resolved
Hide resolved
src/main/java/gregtech/api/pipenet/tile/TileEntityPipeBase.java
Outdated
Show resolved
Hide resolved
if (this.tickingPipe != null) { | ||
this.tickingPipe.readFromNBT(compound); | ||
return; | ||
} |
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.
This data is never written to NBT, so I don't think reading it here would work
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.
The ticking pipe is only not null when the current pipe has been replaced. That means this pipe does not exist anymore, but if the readNbt
still has gone through to this, we simply redirect it to the replaced pipe.
if (tagCompound.hasKey(NBT_KEY_IS_INVERTED)) { //compatibility check | ||
setInverted(tagCompound.getBoolean(NBT_KEY_IS_INVERTED)); | ||
} | ||
this.redstoneSignalOutput = tagCompound.getInteger("RedstoneSignal"); |
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.
Since we are adding a new NBT read here, we need to check if the NBTTagCompound has this key, because existing worlds will not have this key, so this will fail.
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.
This NBT tag was previously defined in CoverBehavior
and was just moved here. If the tag for some reason was not present, the signal produced would be zero, which should also be the default state anyway.
src/main/java/gregtech/common/items/behaviors/CoverDigitalInterfaceWirelessPlaceBehaviour.java
Show resolved
Hide resolved
...gtech/common/metatileentities/multi/electric/centralmonitor/MetaTileEntityMonitorScreen.java
Outdated
Show resolved
Hide resolved
src/main/java/gregtech/common/pipelike/laser/BlockLaserPipe.java
Outdated
Show resolved
Hide resolved
src/main/java/gregtech/common/pipelike/optical/BlockOpticalPipe.java
Outdated
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.
There seems to be a failure retrieving pipe materials now. I started in a new world, on master
, placed down some Ultimet Item Pipes, attaching conveyors to a couple of the pipes. Exitted the world, loaded up in this PR, the Ultimet Item Pipes had transmuted into Aluminum Item Pipes (the default fallback material).
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.
I can no longer use the overlay grid to adjust the connection of pipes. No matter where I am clicking on the grid, I have to be aiming at a pipe face to change connection.
Since Conveyors (and probably other item related covers) cannot attach to fluid pipes, should they still be able to bring up the overyaly grid on the fluid pipes, since interacting with the grid (or the pipe) does nothing.
This comment was marked as resolved.
This comment was marked as resolved.
c5721e7
to
1ccfb48
Compare
…sult` on server and client
…e()` to get the correct result on the server
b997980
to
54b87ad
Compare
If anyone has the time, I'd like it if they could review the changes I made to fix most of the issues alson recently pointed out, but if no one can do it, that's fine.
|
update holder to new ticking tile switch cover transfer around to be consistent with the rest of the method
Co-authored-by: brachy84 <[email protected]> Co-authored-by: Ghzdude <[email protected]> Co-authored-by: serenibyss <[email protected]>
What
Rewrites the cover API for clarity and ease of maintenance. An ICoverable-like interface will no longer be the top level interface for most of MTEHolder's functionality.
Potential Compatibility Issues
There is no deprecation of the old API, so all addons will have to move to the new API when this PR is released. Existing covers in worlds will not be lost or affected in any way; this is world save backwards compatible.