Suggestion: Housing Action Management

[ixnoahlive]

I 100% understand this suggestion is quite large, hence why I think it's probably not worth looking into for the Hypixel Team until this project is a bit later down the line, that's not up to me though! I'm just the messenger!

What & Why?

Hypixel's Housing gamemode has an action system comparable to Scratch's block-based coding. Players have developed tools that allow them to use external programs to generate macros that automatically import actions to speed up their workflows.

These tools are in a grey area with the Hypixel rules, they help a ton with minimizing repetitive work and minimizing the amount of mistakes players make when coding by making debugging easier. Unfortunately, due to the aforementioned grey area and the fact it is a macro they can be quite slow, which I'm hoping to propose a fix to with this suggestion.

How?

My proposed system is a new way of importing actions through the Mod API's plugin message system. This allows Hypixel to not have to worry about false-banning players for macroing despite them not doing it for malicious purposes, while also helping out players by having import times drastically improved because there's no more long clicking through menus.

The Messages

Be warned, netcode is not my strong suit! I am mostly going off of what I personally would find most pleasant to use! Plugin messages can send any data but I'll just be using JSON for simplicity and consistency's sake. I'll be prefixing the channel keys with h_ as Housing is the only Hypixel game starting with a H, so it differentiates the gamemode finely.

h_perms

Clientbound

Returns key-value pairs with the client player's permissions with their current group in the house. Triggers after a group change and when the client joins.

{
  "FLY": false
}

Permissions are useful, because it allows mods to see what operations they can and can't do without needing to poke the server with a dummy command like secretly running /editstat with no arguments. It could possibly contain some group metadata too, but due to the data size limit I am hesitant to propose it.

h_a_ctx

Clientbound

Returns 2 or more messages with info about the opened action context, fires to the client whenever a new context is opened.

{
    "type": "metadata",
    "holder": "functions",
    "id": "XXXX-XXXX-XXXX",
    "name": "My Cool Function"
}

Now, below is the data of the current actions. I'm not too good with encoding stuff and used Base64 here but I think something similar to how Actions is stored in NBT could work because we've already reverse engineered that to hell and back. Position property is in the possible case we exceed the maximum message length, I know it'll already send in order but it just makes it a bit more convenient. ID is also there for convenience.

{
    "type": "actions",
    "id": "XXXX-XXXX-XXXX",
    "pos": 0,
    "data":"W3sidHlwZSI6IlNFTkRfTUVTU0FHRSIsIm1lc3NhZ2UiOiJIZWxsbyEifV0="
}

h_a_write

Serverbound

Okay, here's the whole point of the proposal! Writing actions into an action holder! The client would send a payload with the following data to initiate the process. The target is an ID of a function, or if left blank would simply target the current context. The ID is a sort of "process ID" that we'll use to make sure multiple mods don't conflict imports with eachother. It could also contain the mod's name to inform players, more on that later.

We are initiating in an independent message, because that way we won't have any nasty issues if something goes wrong with successfully terminating a previous import. I'll talk more on this later.

{
    "type": "initiate",
    "target": "XXXX-XXXX-XXXX",
    "id": "AwesomeImportMod-1234"
}

Now we've made first contact and hopefully got back success, we can start telling the server what we actually want to write. I believe it's best to send it as encoded as well, but I'll leave it unencoded just for your clarity. And to remind you: We've already reverse engineered the action format to hell and back as a community so that's the spec I'll be using as an example here.

We aren't supplying a pos because let's just assume that if devs are competent to code a mod that they're also competent enough to send their packets in the right order.

{
    "type": "payload",
    "data": [
        { "type": "SEND_MESSAGE", "message": "Hello!" }
    ],
    "id": "AwesomeImportMod-1234"
}

Here we terminate our chain! This'll tell the server we're all done supplying the actions we'd like to write and also lets us supply a mode. I think it'd be neat if we had an append mode, which writes to the end of the pre-existing actions and a set mode that overwrites the actions as usual.

{
    "type": "terminate",
    "mode": "append",
    "id": "AwesomeImportMod-1234"
}

What we do now is let the server handle the rest. We do NOT want malicious mods just randomly importing so it's a good idea if before this import Hypixel gives mod users a confirmation prompt that shows the actions that are about to be imported, how they'll be imported and where they'll be imported. This prevents abuse while also letting players double check if everything went right.

If the actions being appended or the actions being set go above the limit of allowed actions of a certain type, it should return an error and just stop right there. Same with invalid parameters or other formatting issues. If the player chooses not to import it should also give an error.

Conclusion

This is a ton of waffling, and I probably missed some stuff. I encourage you all to leave your feedback down below and to remind you: I don't expect this to get added any time soon or even at all. The tech needed here is insane, but it'd be well worth it in my eyes.