The most reliable way to tell whether we're in Skyblock or not is via /locraw. We have been advised to use it by Hypixel admins, and no one has any qualms as long as it is implemented properly.

This issue details an implementation of /locraw handling, sending, parsing, and storing.

Tasks

• Implement listener for /locraw responses (and hide from user chat if we sent /locraw in the last few seconds and haven't received a response).
• Parse & set variables from locraw responses (whether we're in skyblock and possibly island type).
• Create trigger that runs /locraw when switching lobbies (worlds).
• Add channel listener that blocks sending /locraw if another mod (or this mod) sent it recently (open for consideration on how long this window should be, I'm thinking 500ms).

Considerations for discussion

• Maximum threshold (ms) for hiding a locraw response from user chat? (balance possible lag vs accidentally showing locraw)
• Maximum threshold (ms) for re-sending /locraw if another mod sent it?

Config File

Currently the config is saved as SkyblockCoreConfig.json, which is already in conflict with our naming scheme and should be SkyBlockCoreConfig.json if we're keeping that style.

Some users have proposed we change the naming style to camelCase instead. We should have a quick discussion about which is preferred, or if we should have another change altogether.

Config Classes

The files ModConfig.java and ConfigManager.java are both stored in the events package - I don't feel like this is a good design, they should probably have their own package (config?) or be moved somewhere more fitting (even the util package is a better fit).

Also, personally - I'm unsure of the name ModConfig considering we've decided this shouldn't be treated as a standalone mod. New class names for that are also being accepted.

Checklist

• Decide on a new naming convention for the config
• Rename the config
• Decide which package the config files belong in and/or if they should be renamed
• Move the config files to the new package (and possibly rename them too)

I suggest to add dungeon flow events. I've already made the code for a personal version of Skyblock-Core, but I am suggesting it be added to the main version. I am making an issue because that's what I was told to do, to make sure that this is actually something that would be wanted, before I go making a pull request.

Here is a list of events I already have:

• Enter dungeon
• Dungeon started
• Dungeon ended
• Left dungeon
• Wither key obtained
• Wither door opened
• Blood key obtained
• Blood door opened
• Entered boss fight (edit)

I noticed that when I join for example the hub when not coming from Skyblock it still triggers the leave event. Please fix this logic.

Putting this in client tick seems like a REALLY bad idea. Would this not be better eg in tooltip event so it's only triggered in a gui and when we're hovering over an item?

Could possibly also just mixin over the method that colours the focused slot?

Originally posted by @TGWaffles in #12 (comment)

Why?

I believe that an API wrapper is a vital function to a "core" mod. Mods can register with the wrapper using their production (or personal) key on client initialize. I am willing to put time into this, as I believe it will really entice mod developers. Currently, we don't really have much to offer. This could change that.

How?

I propose that we start off with a base HypixelResponse<T> interface that we implement for each endpoint. We could cover all SkyBlock endpoints, plus some generic ones like network level and account information.

Checklist

• /player
• /status
• /resources/games
• /resources/skyblock/collections
• /resources/skyblock/skills
• /resources/skyblock/items
• /resources/skyblock/election
• /resources/skyblock/bingo
• /skyblock/news
• /skyblock/auction
• /skyblock/auctions
• /skyblock/auctions_ended
• /skyblock/bazaar
• /skyblock/profile
• /skyblock/profiles
• /skyblock/museum
• /skyblock/bingo
• /skyblock/firesales