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

Improve canConnectToExternal() #111

Merged
merged 2 commits into from Mar 22, 2023

Conversation

Pilzinsel64
Copy link

Fixes a case where at loading the Grid sometimes the conduits may not connect.
I've tested this case with all conduit types and all me cables and some buses and mashines, still work as it should.

Before:
grafik

After:
grafik

@Pilzinsel64 Pilzinsel64 requested review from a team March 21, 2023 19:45
@Pilzinsel64 Pilzinsel64 changed the title imrpove canConnectToExternal() Improve canConnectToExternal() Mar 21, 2023
@@ -174,6 +174,9 @@ public boolean canConnectToExternal(ForgeDirection dir, boolean ignoreDisabled)
if (node == null) {
node = part.getGridNode();
}
if (node == null) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That looks a bit suspicious tbh. What if this part w/o grid node is facing the conduit?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure. But with my Ultra Dense PR I had to change the code of this method. However, my change with this PR here adds a missing case from the code BEFORE my Ultra Dense PR to cover a few cases where ME Conduits wont connect anymore now (one example shown on the picture).
I know it looks bad, but not sure how to merge the code more without having some lines twice.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@repo-alt See the previous code here: https://github.com/GTNewHorizons/EnderIO/blob/b22915cc9cc2903fed7f3d9cb4936025b30df644/src/main/java/crazypants/enderio/conduit/me/MEConduit.java#LL155C37-L155C37
It doesn't even check the node itself. With this PR I cover the case that the node is empty. In this case it probably can connect (at least most of the times I know), as long as the conduit is not Ultra Dense.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't quite understand, sorry

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@repo-alt I'm sorry, let me try again...

Before my PR that adds Ultra Dense Me Conduits the code was this:
https://github.com/GTNewHorizons/EnderIO/blob/b22915cc9cc2903fed7f3d9cb4936025b30df644/src/main/java/crazypants/enderio/conduit/me/MEConduit.java#LL155C37-L155C37

Then I had to adjust the methode canConnectToExternal() to get a similar behavior as the AE2 cables.

But this adjusted method doesn't catch the case anymore that the GridNode can be null, so it won't connect to AE2 cables in a few cases (one shown in the picture at the top).

Now, with this PR I want to fix that by handling this simple case again where there is no GridNode.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I understand that, I just asked if it is possible to have a part w/o a grid node (how is that even possible?) facing the conduit. Obviously it should not connect in that case, and that was checked before.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@repo-alt Ah ok.
I don't know why a part can not have a GridNode and I also don't know why that even happens here. I got it via debugging and did see that it can't find a GridNode. I also see that original Ender IO code also just look for the part and the code for Ender IO for v1.12.2 also looks similar.

My guess is that some Conduits get loaded before a GridNode for specific parts does exist. But that is only an idea.

For more I probably haven't the knowledge in Minecraft modding and in AE2 code.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, the only thing we could do here is to provide a method like canConnectFrom(direction) via the AE2 API and shrink the code of this method canConnectFrom() here probably to a few lines.

But I suggest to do that in another step and I suggest to merge this as first step as otherwise some ME Systems can break softly.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You see, the code you add only works in the situation where there is a part attached to the cable, but in the picture you provide there is no part, so, how exactly can that change affect the situation on the picture?
Also, maybe there is an easy way to reproduce it? If so I might have a look what's going on there

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, now I understand, I think...
There is of course a part on the picture: PartGlassCable. This is what the debugger tells me.

To reproduce:

  1. Put three me interfaces and connect them via a fluix glass cable. Then put a another glass cable below, as shown in the picture. Then, under this cable now put a me conduit (normal or dense) and see it connects.
  2. Save & Quit
  3. Load world again
  4. See the conduit doesn't connect unless you trigger a reconnection (e.g. with the wrench or by placing it again)

If you want I can provide you the test world shown on the picture.

Please let me know what you found out! :)

@repo-alt
Copy link

That's what will happen if the change is implemented as is
image
at least you should check if there is no directional part in that direction.
I don't like that at all, but I don't see an easy solution, because EIO and AE use different initialization modes and grid nodes may be either present or not at the time of the conduit initialzation. Better solution would be to have a way to reset AbstractConduit.connectionsDirty in case when the derived class encounters "neighbours are not quite loaded" situation.

@Pilzinsel64
Copy link
Author

Ah, I see. Hm, not sure what a "directional part" is, but you second idea sounds good.
Check my latest commit needUpdateConnections, is that what you mean? @repo-alt

Sure it's not a good way how I implemented it at all yet, but it seems to work. What do you think?
grafik

@repo-alt
Copy link

That is at least more universal solution

@Dream-Master Dream-Master merged commit 1fd7ae7 into GTNewHorizons:master Mar 22, 2023
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants