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

Add /locraw support #19

Open
4 tasks
TGWaffles opened this issue May 23, 2023 · 4 comments
Open
4 tasks

Add /locraw support #19

TGWaffles opened this issue May 23, 2023 · 4 comments
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@TGWaffles
Copy link
Member

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?
@TGWaffles TGWaffles added enhancement New feature or request good first issue Good for newcomers labels May 23, 2023
@hannibal002
Copy link

hannibal002 commented May 23, 2023

Maximum threshold (ms) for hiding a locraw response from user chat? (balance possible lag vs accidentally showing locraw)

Why bother with a threshold for hiding this at all? Just hide it every time the message pops up. If other mods send /locraw, they can still read their message even if we hide it from the player.

Maximum threshold (ms) for re-sending /locraw if another mod sent it?

Why would we want to resend locraw? We send + detect it on world change, why bother if another mod is doing it as well? It can't corrupt data, only update the data faster on accident.

@TGWaffles
Copy link
Member Author

TGWaffles commented May 23, 2023

Why bother with a threshold for hiding this at all? Just hide it every time the message pops up. If other mods send /locraw, they can still read their message even if we hide it from the player.

Not sure if this behaviour is wise - if nothing else it could be irritating to developers trying to test with locraw who aren't aware that the core mod is hiding it from them. In 1.8.9 I don't know of any mods that always block locraw, we should probably try to keep the behaviour similar.

Why would we want to resend locraw? We send + detect it on world change, why bother if another mod is doing it as well? It can't corrupt data, only update the data faster on accident.

As in, don't resend if another mod sent it recently, not that we should resend - that is exactly the point (if you read the 4th task you'll see that was what I said).

The threshold value means: how long ago should another mod have sent locraw before we consider that data "stale" enough to warrant us running it instead? e.g. if another mod sends a locraw at T+800ms, and we want to send one at T+900ms, we should not send that command as the data the other mod just got is probably up-to-date enough.

@wiviw5
Copy link
Contributor

wiviw5 commented May 24, 2023

The optimal solution here is to keep with proposed #12 Skyblock detection with a few extras.

#12 Relies on Scoreboard name detection (So, receiving "SBScoreboard") to know whether or not we are in Skyblock or not.

This already gives us fast & up to date info for almost every single scenario (exceptions are for limbo/network lag)

IMO the solution is an implementation of /locraw on top of the existing infrastructure.

So, to break it down:

  1. On world load, we first start up our 500ms (or however long) timer for waiting for other mods to send their /locraw commands, and receive any versions they get back. If we don't get any, we will send our own.

  2. Scoreboard packet comes in, updating us that we are either in Skyblock, or a lobby, giving us an update window without relying on that 500ms (or however long) window for /locraw to come in.

  3. If we don't ever get a scoreboard packet, then finally, our own/a mods /locraw packet activates, giving us info that we are in limbo or just extremely laggy, removing us from being "in Skyblock". After the lag is done, and we get the scoreboard packet, we then "join skyblock" again once we've confirmed its just lag, as its a built in "done with lag" detector, or if we never recieve it, we know we are in limbo with a ton of lag possibly if we never recieve back a /locraw response, or if we do, just know we are in limbo.

These 3 simple steps can easily allow us to cover all bases, without possibly breaking other mods, without sending extra unnecessary commands to Hypixel, and giving the user the best possible experience of mods with the fastest in Skyblock detection.

@KyllianGamer
Copy link
Contributor

Why all this "waiting x millis" stuff? Why not just apply following logic:

  • On world join / change send the command and set some variable that indicates the mod's awaiting a locraw response.
  • On locraw response, consume it if that variable is true, if not, don't consume it.
    This would make it so that:
  • If another mod also sends the command, worst case it just gets a later response than the core mod. It wouldn't prevent the other mod from getting the response as the command would've been sent twice. Unless you exceed the limit, in which case that would require some extra step.
  • If the player itself sends the command it would also not consume it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

4 participants