Chat events refactor #1125
Chat events refactor #1125
Conversation
src/main/java/de/hysky/skyblocker/mixins/MessageHandlerMixin.java
Outdated
Show resolved
Hide resolved
|
|
||
| import java.util.regex.Matcher; | ||
| import java.util.regex.Pattern; | ||
|
|
||
| public class SkyblockXpMessages { | ||
| private static final MinecraftClient CLIENT = MinecraftClient.getInstance(); | ||
| private static final Pattern SKYBLOCK_XP_PATTERN = Pattern.compile("§b\\+\\d+ SkyBlock XP §7\\([^()]+§7\\)§b \\(\\d+\\/\\d+\\)"); | ||
| private static final Pattern SKYBLOCK_XP_PATTERN = Pattern.compile("\\+\\d+ SkyBlock XP \\([^()]+\\) \\(\\d+/\\d+\\)"); |
There was a problem hiding this comment.
I feel like we're losing information here by striping the formatting codes. There's a reason hypixel put them in so I think we should keep them too.
There was a problem hiding this comment.
I don't think functionality should depend on formatting codes, as they might be just artifacts left from an older era and stuff would break once they migrate to text objects with styles.
There was a problem hiding this comment.
While I do agree with the above, in order to make the pet cache work with autopet it'd require that section symbols are present for parsing the rarity and whatnot so maybe it would be better to have a note saying to not rely on them unless absolutely necessary.
There was a problem hiding this comment.
If some features have to use formatting codes, those specific usages could do Text#getString with the RECEIVE_TEXT event and do their own thing anyway.
LifeIsAParadox
added
merge conflicts
Refactored most usages of
ClientReceiveMessageEvents.GAMEto useChatEvents.RECEIVE_TEXTandChatEvents.RECEIVE_STRING, or the overlay variants (which are also added in this PR) if they required so, with some exceptions because either their logic was complicated due to handling both overlay and chat messages or they already had a cancelled message fix which worked (I presume).Some usages of
ClientReceiveMessageEvents.GAMEweren't clear in whether they used overlay messages or not, they didn't do anything with the variable. This refactor also clarifies those by using the relevant event.As for why the overlay events are separate instead of being similar to fabric's events, it's because there were way too few uses of action bar messages, it's roughly 4 uses in total compared to 25 something chat message listeners. Each chat message listener had an ugly if check that increased the brain power required to understand. Each overlay message listener had the same if check, but reversed. It's just not good for anybody.
This fix also encourages any future dev to separate their overlay listener and chat listener logic because they're almost always different anyway, keeping them in the same method was complicating it.
Haven't tested.
If you're not satisfied with the event names, please lmk because I feel the same way yet I don't know what would be better alternatives to them.