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

Corporea string item loading is done client-side #4249

Open
wants to merge 7 commits into
base: 1.19.x
Choose a base branch
from

Conversation

gamma-delta
Copy link
Contributor

@gamma-delta gamma-delta commented Dec 20, 2022

This closes #4248 and also has some other nice effects:

  • We no longer load the I18n on the server (which shouldn't be happening anyways, strictly speaking)
  • Players in different languages can now request items in their language (tested, but the special-cased stack of and such are still Englishy)
  • Requesting this now uses a CorporeaItemStackMatcher instead of searching for the name of the item

I've done some tests and the following works:

  • Requesting items in various different languages
  • Intercepting foreign-language requests
  • Maintaining foreign language requests across lang changes:
    • Request 64 stone with nothing in the system
    • Have an interceptor get it
    • Switch language to Toki Pona
    • Put stone in the system and replay the request with the retainer, and it arrives
    • Do the same in reverse; requesting 64 kiwen in Toki Pona gives you the stone after switching back to English

Todo:

  • Check you can request items with custom names
  • Check keybind requests still work
  • Check that intercepted requests from old versions still work when loaded (I made some changes to the storage format and added a legacy check to still try its best; is this a goal we need to test?)

@gamma-delta
Copy link
Contributor Author

whoops I very cleverly put backticks in the last commit name so it tried to interpret them as commands. it should say "make matching this use NBT in the same way the c keybind does"

@gamma-delta
Copy link
Contributor Author

Say I have an iron ingot in the system called Foobar. If I request an iron ingot, is it expected behavior to recieve the renamed ingot?

(I'll run spotless at the end)

@gamma-delta
Copy link
Contributor Author

One problem I thought of: it won't work nicely with items that have a different display name per stack irregardless of the display name, like hexcasting scrolls...

@artemisSystem
Copy link
Collaborator

Check that intercepted requests from old versions still work when loaded (I made some changes to the storage format and added a legacy check to still try its best; is this a goal we need to test?)

Yes, i'd say this is a goal. Currently not feeling very well but if i get better in the next few days i can test whether it works currently

One problem I thought of: it won't work nicely with items that have a different display name per stack irregardless of the display name, like hexcasting scrolls...

Can you rephrase? I don't get what you mean

Say I have an iron ingot in the system called Foobar. If I request an iron ingot, is it expected behavior to recieve the renamed ingot?

I think you already got the answer to this but, for posterity: No, it shouldn't return the renamed item.

@Alwinfy
Copy link
Member

Alwinfy commented Dec 23, 2022

One problem I thought of: it won't work nicely with items that have a different display name per stack irregardless of the display name, like hexcasting scrolls...

Can you rephrase? I don't get what you mean

Consider an item that changes its display name by its NBT, such as a fluid tank that may be named "Empty Tank" or "Tank of {X liquid}"

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

Successfully merging this pull request may close these issues.

Corporea index doesn't localize
3 participants