Skip to content
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

Merged
merged 21 commits into from
Nov 12, 2023
Merged

Cover API rewrite #2071

merged 21 commits into from
Nov 12, 2023

Conversation

TechLord22
Copy link
Member

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.

@TechLord22 TechLord22 added the type: refactor Suggestion to refactor a section of code label Sep 4, 2023
@TechLord22 TechLord22 added this to the 2.8 milestone Sep 4, 2023
@TechLord22 TechLord22 requested a review from a team as a code owner September 4, 2023 22:20
Copy link
Contributor

@ALongStringOfNumbers ALongStringOfNumbers left a 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.

src/main/java/gregtech/api/cover/CoverableView.java Outdated Show resolved Hide resolved
src/main/java/gregtech/api/cover/Cover.java Outdated Show resolved Hide resolved
Copy link
Contributor

@ALongStringOfNumbers ALongStringOfNumbers left a 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.

src/main/java/gregtech/api/cover/CoverDefinition.java Outdated Show resolved Hide resolved
src/main/java/gregtech/common/ToolEventHandlers.java Outdated Show resolved Hide resolved
* @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) {
Copy link
Contributor

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.

Copy link
Member Author

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?

Comment on lines +131 to +134
default boolean canPipePassThrough() {
return false;
}
Copy link
Contributor

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?

Copy link
Member Author

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}.
Copy link
Contributor

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?

Copy link
Member Author

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.

src/main/java/gregtech/api/cover/CoverSaveHandler.java Outdated Show resolved Hide resolved
Copy link
Contributor

@brachy84 brachy84 left a 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.

@TechLord22 TechLord22 changed the base branch from master to 2.8 September 24, 2023 06:36
@TechLord22 TechLord22 force-pushed the tc-cover-rewrite branch 2 times, most recently from 12e51ee to 64e746d Compare September 24, 2023 06:52
@brachy84 brachy84 mentioned this pull request Sep 24, 2023
Copy link
Contributor

@ALongStringOfNumbers ALongStringOfNumbers left a 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/block/BlockPipe.java Outdated Show resolved Hide resolved
Comment on lines +361 to +375
if (this.tickingPipe != null) {
this.tickingPipe.readFromNBT(compound);
return;
}
Copy link
Contributor

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

Copy link
Contributor

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");
Copy link
Contributor

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.

Copy link
Member Author

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.

Copy link
Contributor

@ALongStringOfNumbers ALongStringOfNumbers left a 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).

Copy link
Contributor

@ALongStringOfNumbers ALongStringOfNumbers left a 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.

@ghzdude

This comment was marked as resolved.

@serenibyss serenibyss force-pushed the 2.8 branch 2 times, most recently from c5721e7 to 1ccfb48 Compare October 31, 2023 02:37
@ghzdude
Copy link
Contributor

ghzdude commented Nov 11, 2023

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.

Now, the only issue i can see is that newly placed covers on item pipes cannot be open their GUI before you reload the world, where the GUI is opened properly. Otherwise, the pr looks good to me. I have fixed this now.

ghzdude and others added 2 commits November 10, 2023 19:47
update holder to new ticking tile
switch cover transfer around to be consistent with the rest of the method
@TechLord22 TechLord22 merged commit fe618cc into 2.8 Nov 12, 2023
2 checks passed
@TechLord22 TechLord22 deleted the tc-cover-rewrite branch November 12, 2023 22:04
serenibyss added a commit that referenced this pull request Nov 23, 2023
Co-authored-by: brachy84 <[email protected]>
Co-authored-by: Ghzdude <[email protected]>
Co-authored-by: serenibyss <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: refactor Suggestion to refactor a section of code
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants