Multiparts disable interfaces #1059

Closed
CandiceJoy opened this Issue Mar 21, 2015 · 8 comments

Comments

Projects
None yet
3 participants
@CandiceJoy

When I put a glowstone nook on an Interface, the interface ceases to function. It happens if I put a multipart anywhere in the block beneath it. Place a multipart, there's 31 interfaces in the terminal. Remove the multipart, there's 32 interfaces in the terminal. Place it again, there's 31. It's a very obvious correlation.

@thatsIch

This comment has been minimized.

Show comment
Hide comment
@thatsIch

thatsIch Mar 21, 2015

Member

Can you post a screen shot to clarify it?

Member

thatsIch commented Mar 21, 2015

Can you post a screen shot to clarify it?

@CandiceJoy

This comment has been minimized.

Show comment
Hide comment
@CandiceJoy

CandiceJoy Mar 21, 2015

The normal interface: http://puu.sh/gJ9s2/8b7e378987.png
The interface terminal count: http://puu.sh/gJ9sM/64ab4eda25.png
I want to stress that NO OTHER CHANGES were made other than the single change pictured below.
The multipart'd interface: http://puu.sh/gJ9u1/1ac554560d.png
The new interface terminal count: http://puu.sh/gJ9v5/5daa9cc608.png
Again, only THAT SINGLE CHANGE is made.
Back to the normal interface: http://puu.sh/gJ9xX/64b3709599.png
And the new interface terminal count: http://puu.sh/gJ9yn/47acc460b7.png

It may do this with other blocks as well, maybe even cables. However, I only tested this effect with interfaces. This is very very very bizarre to me, and it took us quite awhile to figure out why all of our interfaces weren't available.

The normal interface: http://puu.sh/gJ9s2/8b7e378987.png
The interface terminal count: http://puu.sh/gJ9sM/64ab4eda25.png
I want to stress that NO OTHER CHANGES were made other than the single change pictured below.
The multipart'd interface: http://puu.sh/gJ9u1/1ac554560d.png
The new interface terminal count: http://puu.sh/gJ9v5/5daa9cc608.png
Again, only THAT SINGLE CHANGE is made.
Back to the normal interface: http://puu.sh/gJ9xX/64b3709599.png
And the new interface terminal count: http://puu.sh/gJ9yn/47acc460b7.png

It may do this with other blocks as well, maybe even cables. However, I only tested this effect with interfaces. This is very very very bizarre to me, and it took us quite awhile to figure out why all of our interfaces weren't available.

@thatsIch

This comment has been minimized.

Show comment
Hide comment
@thatsIch

thatsIch Mar 21, 2015

Member

Thanks for the pictures, I am trying to reproduce this. A multi-part from FMP should not alter this. Is there by some chance a "new" entry in that list, which replaces the 32th interface?

Member

thatsIch commented Mar 21, 2015

Thanks for the pictures, I am trying to reproduce this. A multi-part from FMP should not alter this. Is there by some chance a "new" entry in that list, which replaces the 32th interface?

@yueh

This comment has been minimized.

Show comment
Hide comment
@yueh

yueh Mar 21, 2015

Member

It just changes the name to "tile.multipart". As the interface is using the order of ForgeDirection, it means DOWN > UP > NORTH > SOUTH > WEST > EAST as order for obtaining the name (if the interface is not renamed itself).

Not sure, if I want to see an exception just to handle FMP differently.

Member

yueh commented Mar 21, 2015

It just changes the name to "tile.multipart". As the interface is using the order of ForgeDirection, it means DOWN > UP > NORTH > SOUTH > WEST > EAST as order for obtaining the name (if the interface is not renamed itself).

Not sure, if I want to see an exception just to handle FMP differently.

@thatsIch

This comment has been minimized.

Show comment
Hide comment
@thatsIch

thatsIch Mar 21, 2015

Member

But why is "tile.multipart" a valid inventory?

Member

thatsIch commented Mar 21, 2015

But why is "tile.multipart" a valid inventory?

@yueh

This comment has been minimized.

Show comment
Hide comment
@yueh

yueh Mar 21, 2015

Member

Maybe FMP defines every TE as inventory to be able to actually handle inventories inside it?
And I am not sure, if the interface really cares about an inventory or just an adjacent TE with some name.

Member

yueh commented Mar 21, 2015

Maybe FMP defines every TE as inventory to be able to actually handle inventories inside it?
And I am not sure, if the interface really cares about an inventory or just an adjacent TE with some name.

@CandiceJoy

This comment has been minimized.

Show comment
Hide comment
@CandiceJoy

CandiceJoy Mar 21, 2015

Yeah, it shows up as tile.multipart.

Yeah, it shows up as tile.multipart.

@CandiceJoy

This comment has been minimized.

Show comment
Hide comment
@CandiceJoy

CandiceJoy Mar 21, 2015

This problem doesn't happen with cables as far as I know, although multiparts DO make cables and things in the same block take a LOT longer to break, but the effect is not limited to just AE2 cables. Thermal Dynamics cables too, at least, do the same thing.

This problem doesn't happen with cables as far as I know, although multiparts DO make cables and things in the same block take a LOT longer to break, but the effect is not limited to just AE2 cables. Thermal Dynamics cables too, at least, do the same thing.

@thatsIch thatsIch added the type-bug label Apr 3, 2015

@thatsIch thatsIch self-assigned this Apr 3, 2015

@thatsIch thatsIch added this to the rv2 milestone Apr 3, 2015

@thatsIch thatsIch closed this in bb1c341 Apr 4, 2015

thatsIch added a commit that referenced this issue Apr 4, 2015

Merge pull request #1187 from thatsIch/b-1059-fmp-disables-interfaces
Fixes #1059 FMP like TileEntities are not valid Interface targets anymore
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment