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

Patch suggestion: Phantomface to GT Blocks displayed name issue #40

Closed
ChromaPIE opened this issue Jan 11, 2025 · 3 comments
Closed

Patch suggestion: Phantomface to GT Blocks displayed name issue #40

ChromaPIE opened this issue Jan 11, 2025 · 3 comments

Comments

@ChromaPIE
Copy link

局部截取_20250111_164329

Using s-chinese as in-game language but the problem should be obvious. The fluid phantomface was bound to the quad input hatch above it but it failed to fetch the displayed name of the block, instead shows unnamed.name, same for every Phamtomface varieties and every other GT tile-entities. That's yet another consequence of the method GT took to deal with its massive amount of registries.

But seems like AE2 has worked this around, as the names are shown as unnamed Interfaces' titles on the Terminal with no problem, so maybe we could check their code, see how it handles this and patch it with Labs.

@IntegerLimit
Copy link
Member

Fixed in a0ad77f.

@ChromaPIE
Copy link
Author

Additional patch suggestion to this:

Image

When a Phantomface is connected to ME storage exposer, which has both item and fluid capabilities, the status shows as Bad Connection but it'll function with no problem, only proxies the item part. I assume the Fluid Phantomface also acts this way.

Would be better to make it show as

Connected (Partial Function)
The connection point does not fully work with this device, will only handle the compatible part.

@IntegerLimit
Copy link
Member

IntegerLimit commented Feb 6, 2025

Fixed in 86c00b9. An exposer handles both item and fluid simultaneously. The phantomface does not check to make sure ONLY that capability is available, otherwise all blocks with energy capability would fail.

The actual issue, as seen in the commit, was that the ME Storage Exposer does not expose its capability on the client. This is acceptable by NAE2, but AA checked this on the client for the HUD.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants