Protocol: Support `|deinit` message

[pkmn]

Protocol: Support `|deinit` message

[scheibo]

You might have trouble with the tests - you need to subpkg link to make sure the packages interconnect to each other (this is coincidentally why GH reports the repo as failing currently, its not set up to do the subpkg link step and instead is dependent on new packages being released. This is somewhat intentional - it's valuable to have a way to verify the released packages work with each other, but when developing locally you want them all to be linked together). Furthermore, to run the tests just from the protocol package you'll want to run subpkg test protocol from the root. I think https://github.com/pkmn/ps/blob/master/CONTRIBUTING.md covers more of this.

[scheibo]

I'd welcome any PRs in this space. I'm only confident I've reverse engineered the undocumented messages relevant for simulation, but messages relevant to creating a client are also desirable (consider also just opening a pull request against the upstream PS repo so that everyone benefits for any messages you have found that have slipped through the cracks)

[scheibo]

OK, from git grep send.*\| I find the following:

• |deinit| - seems to indicate a room should be closed
• |selectorhtml|{selector}|${content} - where selector is some string, don't know if its range is limited, and content is an arbitrary string
• |refresh| - tells the client to refresh the page
• |tempnotify|${key}|${message} ?
• |tempnotifyoff| - seems like the second arg is always pendingapprovals in the case of the show command, but can also be a room id when used to notify a rank?
• |noinit| - blocks joining a room. seems like it can optionally take the form |noinit|${type}|${message}?
• |hidelines|${type}|${userid}|${linecount} where link can either be unlink, delete or hide and linecount is optional?
• |expire|${message} - sent when a room has been deleted (really i feel PS shouldn't need a deinit, noinit AND expire message, but what do I know?)
• |modaction|${msg} / - |c~| - can't tell if actual protocol or just hacky internal crap?
• |askreg|${userid} - asks the winner of a rated battle to register

There's also all the MiscArgs which weren't documented either:

ps/protocol/src/index.ts

Lines 643 to 654 in 4ff6f1e

	export interface MiscArgs {
	'|unlink|': readonly ['unlink', Username] | readonly ['unlink', 'hide', Username];
	'|raw|': readonly ['raw', HTML];
	'|warning|': readonly ['warning', Message];
	'|error|': readonly ['error', Message];
	'|bigerror|': readonly ['bigerror', Message];
	'|chatmsg|': readonly ['chatmsg', Message];
	'|chatmsg-raw|': readonly ['chatmsg-raw', HTML];
	'|controlshtml|': readonly ['controlshtml', HTML];
	'|fieldhtml|': readonly ['fieldhtml', HTML];
	'|debug|': readonly ['debug', Message];
	}

Let's see if we can't find someone to document this mess upstream...

[taylorhansen]

Maybe for now I could just add them to MiscArgs and Protocol.parse. Would anything have to change in the import scripts?

[scheibo]

No. To add support for the args you need to add them to MiscArgs (and make sure theyre corrected typed), to the map tracking all the protocol keys in the same file, and then add support to the verifier to validate the messages type at run time. If you want to take a stab at this that would be great, otherwise I will probably crank something out tomorrow before the release

[taylorhansen]

Sure, I'll see what I can do.