an excellent new feature, thanks

Oh great. Instead of finally giving us vendors that sell all the stuff so we're actually able to fully and thoroughly test ****, they throw in another toy. Sorry to rain your parade, Cryptic, but you definitely need to have a look at your priorities.

It's a cool feature, there just are more urgent matters to attend to. If you were still in school, teachers would have told you something like "sit, F, missed the subject".

i would like the to be able to login to my actual fleet channel

Ok I finally managed to understand how to "join" the MUC version of TTS and have the server (which is definitely is a self-coded implementation and not ejabberd) accept my presence for it.

While the concept is good.

Your xmpp implementation for it is totally un-standard/wrong and will cause a lot of hassles with most xmpp clients out there and since I'm kind of knowledgeable on the matter I'll explain you why:

1) In your implementation the server to accept the presence stanza required to join the MUC for the in-game channels require the Nickname supplied to be exactly equal as the In-Game handle. I dunno if this is some sort of security measure but it seems a bit useless (see below) and believe me if you don't explain that throughly you'll find yourself cluttered in support requests.
2) In-Game someone talking from the xmpp service is tagged as: "Resource-Name@Handle". Now if you made it so we are unable to change the nickname with the MUC join presence stanza. You must be aware that it's very easy to do so client wise modifying the resource name. Perhaps I don't see the point of not using the "XEP" compliant way of it ^^.
3) I'm very happy that you want to use XMPP to allow out-of-game "in-game communication" accessing, but making your self-implementation fully compliant to the standard is always the best choice.

+1 Though and hope you accept my feedback as a positive one.

Unsurprising and explicitly allowed by the specification. Also supported fine by pidgin, and should work with any client that implements the optional reserved nickname features.

They must indeed be aware of it, seeing as how it's documented in the OP.

This isn't something covered by any specification.

No compliance issues here.

EDIT: The problem is I don't get status codes back when I input a different nick from the handle, but I'll have to check throughly about the compliance, talking with a few people about it.

EDIT: Removed about the Nick reservation, even because It's what isn't happening and should happen which is why I didn't see any "sign" of it.

EDIT: Useless as there was a bug in the XMPP service presence stanza handling with Self-Presence. Miiru submitted the bug report.