Respect sign translation fallbacks for Meteor key spoofing#6187
Respect sign translation fallbacks for Meteor key spoofing#6187Zitrone30 wants to merge 1 commit intoMeteorDevelopment:masterfrom
Conversation
AbstractSignEditScreenMixin was turning Meteor translation keys on signs into the raw key string every time. That broke vanilla behavior for signs that include a fallback, since vanilla returns the fallback when the key can’t be resolved. This keeps the existing key protection, but if the sign text is translatable and includes a fallback, it uses that fallback instead. If there isn’t one, it still uses the raw key. This makes Meteor behave like vanilla for fallback-based sign checks and fixes the detection issue.
|
this hotfix is still flawed as it does not take server resource packs into account in my opinion it is better to outright remove it at this time with #6186 to let dedicated mods such as exploit preventer handle it |
|
sure then pull the changes of yours please |
|
Honestly you should simply allow servers to be able to block this. If they are blocking it's because they don't want anyone to use it. :) |
|
This is not only flawed because server resource packs but also for the with thing with variable elements. The best way is removing the faulty protection and use ExploitPreventer. If people really care about it now: Use my meteor-client fork. There is a release that removes that already and then you need to install a mod that protects against that properly. |
hi pedro yea that's the plan mostly we dont intend to push a full fix though it is encouraged for donutsmp to start detecting meteor more heuristically instead of relying on client exploits as we will eventually (within the coming months) be switching to our own translation format separate from minecraft's |
4 participants
Type of change
AbstractSignEditScreenMixin was turning Meteor translation keys on signs into the raw key string every time. Which broke vanilla behavior for signs that include a fallback. Vanilla returns the fallback when the key can’t be resolved.
This change keeps the existing key protection. But if the sign text is translatable and includes a fallback, it uses that fallback instead. If there isn’t one, it still uses the raw key. This makes Meteor behave like vanilla for fallback-based sign checks and fixes the detection issue.
How Has This Been Tested?
Gone on a server with a detection and not detected
Checklist: