Open TGWaffles opened 1 year ago
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.
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.
The optimal solution here is to keep with proposed #12 Skyblock detection with a few extras.
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:
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.
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.
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.
Why all this "waiting x millis" stuff? Why not just apply following logic:
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
Considerations for discussion