search

LVPlayground / nuwani

Canonical repository for the Nuwani IRC bot framework
MIT License
0 stars 0 forks source link

[report] message format to reflect gamemode changes #11

Closed mblokker closed 8 years ago

mblokker commented 8 years ago

As of https://github.com/LVPlayground/playground/commit/98af5ce240bd7b2a230d8dce540396440f56c11f, a player name might be send with the [report] message. This means we can either have: Suspected player: \3 (Id:\4) - Cheat/reason: \5 with format: %s %d %s %d %s, or Suspected player: \3 - Cheat/reason: \4 with format: %s %d %s %s (what we have now).

Somehow Nuwani should know that when [report] is used with 5 parameters, the first format applies. For 4 parameters, the second format should be used.

mblokker commented 8 years ago

I see now that Saber handles this!

debuggest3 commented 8 years ago

How can I be sure that the 4th argument is an ID and not part of the cheat/reason message if the message starts with a number?

My suggestion would be to always send an ID with the [report] message. If no ID is known, use 255 or -1. It can be filtered out manually.

mblokker commented 8 years ago

The gamemode takes care of the parsing and will either broadcast an IRC message with 4 or 5 variables, so Nuwani shouldn't have to worry about that. It can just count the number of parameters supplied and act on this.

debuggest3 commented 8 years ago

That won't work if the reason contains multiple words.

mblokker commented 8 years ago

I see now. We used to have this problem with [gang] as well if I remember correctly. Maybe we can use a similar fix for this?

debuggest3 commented 8 years ago

That uses this syntax: [gang] playerId playerName gangId gangNameLength gangName message

It adds the length of the gang name right in front the gang name itself, because both gangName and message can contain spaces. That solution won't work in this case unfortunately, as a parameter in front of the message (the reason) is optional. In the [gang] message, all parameters are always there, making parsing a lot easier.

RussellLVP commented 8 years ago

It looks like we've got two options here:

  1. Always pass the Id of the player (255 when unknown)
  2. Use a different message prefix depending on whether the id is known or not.

Both work for me, but I'm inclined to prefer option 1 because it avoids some duplication, and an id of 255 makes it clear enough that it's not real. Option 2 would be slightly cleaner from an aesthetic point of view, but that's not something we have to optimize for too much.

/cc @Xanland

xhoogland commented 8 years ago

For both of them is something to say to be honest.

I had option 2 in my thoughts, since something like that was also used somewhere a long time ago. Although option 1 is not bad either, although 255 could be a problem perhaps in the far future. 😜

xhoogland commented 8 years ago

Since /report has been rewritten into a javascript-variant, this issue seems invalid.

When users want to report players who are at that time not in-game, they can always use @msg so they can be more specific.