AutoReferee

AutoReferee

9.1k Downloads

Referee Plugin Channel Messages

authorblues opened this issue · 10 comments

commented

This is a work-in-progress account of the referee plugin channel protocol. Events can be sent at any time before, during, or after a match. Replies will be sent as the response to a corresponding request.

Events

Player Events

  • player:<player>:hp:<health> - health in half-hearts
  • player:<player>:armor:<armor> - armor in half-sheilds
  • player:<player>:obj:+<blockdata> - player is carrying objective
  • player:<player>:obj:-<blockdata> - player dropped objective
  • player:<player>:kills:<num> - number of kills total
  • player:<player>:deathpos:<coords> - comma-separated coordinates for player death
  • player:<player>:deaths:<num> - number of deaths total
  • player:<player>:dominate:<name> - sent when player is dominating another player
  • player:<player>:revenge:<name> - sent when player takes revenge on another player
  • player:<player>:accuracy:<num> - accuracy as a percentage (percent sign not sent)
  • player:<player>:streak:<num> - killstreak this life (zero will be sent to reset on death)

Team Events

  • team:<team>:init - initialize team
  • team:<team>:name:<newname> - change team's name
  • team:<team>:color:<colorcode> - set team color code
  • team:<team>:player:+<player> - player joins team
  • team:<team>:player:-<player> - player leaves team
  • team:<team>:obj:+<blockdata> - set blockdata as an objective
  • team:<team>:obj:-<blockdata> - remove blockdata as an objective
  • team:<team>:state:<blockdata>:<state> - update state of an objective
    • none - wool is in fleecy box. This is the default state. This state will never be sent, but is assumed
    • found - fleecy box has been opened, but wool is not necessarily being carried
    • carry - a player is carrying this wool. This will revert to found if the wool is dropped.
    • vm - the wool is on the victory monument. This will revert to found or carry if the wool is removed.

Match Events

  • match:<world>:init - initialize match
  • match:<world>:map:<map> - map name
  • match:<world>:time:<time> - current match time (hh,mm,ss)
  • match:<world>:countdown:<sec> - number of seconds until the 3-second countdown begins
  • match:<world>:start - match begins
  • match:<world>:end:<team> - match ended, winning team
commented

The health and armor of every player should be send with the list of players too. A referee might relog or something like that and he has to know the health and armor or otherwise it displays 10 hearts and 0 armor all the time. I'm not sure if this is done already.
Preferably I want the team info as a player event: player:<player>:team:<teamname>. It would work better too because players can keep joining a team before a match. It would be nice if they are added (in my mod) immediatly when they join a team.

Also I want the color of the team,

team:<team>:color:<colorstring> - the color string is for example §3 and should be able to get by the ChatColor class in bukkit

team:<team>:name:<name> doesn't seem to make any sense except if the name of a team changes. Because it's name is passed two times: as <team> and as <name>. If it's for name changing, it's just a bit confusing but it's alright. I'm gonna handle it so that if there's a team event from an unknow team, it will create that team.

And I think the number of teams is not needed (match events)

Last but not least: Can you give me an example of the time format you work with?

commented

Currently implemented (on my mod):

Player Events:

  • hp,
  • amor,
  • obj (both + and - but I'm not so sure if it works)
  • team (see my comment above). If the team(Name) doesn't exist yet, it will be created.

Team Events:

  • name (as a change of name for a team, to add a new team, pass the team-color-event),
  • color (see my comment above)

Match Events:

  • map

Status on other events

Team Events:

  • obj and get will be implemented

Match Events:

  • time will be implemented, I only need the format to know how to.
  • teams: not planning on implementing unless you give me a reason why.

Not sure if it works 100% because the server still sends the old format :D

And I made something else work but I want to keep the surprise (and you have to fix the events first), so if you have time and you want to know and you see me online, just ask for it :D

commented

My original intent for team:<team>:... messages was for the <team> to be a team number, but in hindsight, that doesn't make sense in any context, since teams are stored in unordered sets. I've modified the protocol to support some of the things you're looking for. Let me know if it improves things any.

When a referee joins the server, they will be sent an updated version of everything out of sync with everyone else (the message will only be sent to the joining referee), so I don't think the protocol will need to change. Just expect the messages to arrive at any time. When a referee joins, you'll get something like:

match:<world>:map:<map>
match:<world>:time:<time>
team:<team>:color:<color>
team:<team>:players:<playerlist>
player:<player>:hp:<hp>
player:<player>:armor:<armor>
...
team:<team>:players:<playerlist>
player:<player>:hp:<hp>
player:<player>:armor:<armor>
...
commented

Ok. I'm currently waiting to test some of my features for the correct format. But take your time. I have other things to work on. I'll check my code to make sure events should be able to arrive at any moment.

Can you clarify the time format you use?

commented

I clarified it at the top. hh,mm,ss, and expect to receive that message a LOT. I might not send it once per second (so you might need to simulate the time if you want to show it at the granularity of one second), but I'll probably send it once every 5 or 10 seconds. That will be enough to show it at a granularity of a minute.

commented

My bad.

commented

Something that could be really useful is just a temporary/debug command to let me send my own events to the client for testing purposes while I wait until the real format has been implemented. Eg /autoref debug player:caske33:hp:15 would send a plugin message "player:caske33:hp:15" to my client. That would be so useful :D

Btw I might be able to use the kills and deaths, accuracy, dominating, revenge and kill-streaks-events (if you have time to implement them).

  • player:<player>:kills:<numberOfKills> Sent everytime a player gets another kill + at the beginning of the match
  • player:<player>:deaths:<numberOfDeaths> Sent everytime a player dies + at the beginning of the match
  • player:<player>:accuracy:<accuracy> I probably just want the string that you use in the table too. (This is less important but can be useful IMO. Shouldn't be sent everytime a player fires an arrow but maybe like every five minutes.
  • player:<player>:dominating:<name> name = the name of the player who is been dominated
  • player:<player>:revenge:<name> name = the name of the player who has been killed
  • player:<player>:killstreak:<numberOfKillsInCurrentLife> this would be sent while the player is alive if possible. When he dies, player:<player>:killstreak:0 should be sent.

Even less important at the moment but other events I could do something with (to know where the objectives are):

  • team:<team>:VM:<objective> this would be sent when a wool is placed on the VM
  • team:<team>:safe:<objective> this would be sent when a wool is been considered safe (probably only when placed back in another chest than the fleecy box chest, maybe also when the wool is placed somewhere else although it's not always safe then eg DT it could burn if placed on the netherrack blocks).

This would help to have 5 states for the wool (If you don't want to implement the last event, I'm fine with 4 states)

  • In the fleecy box
  • Touched (Somebody got some wool from the fleecy box) but it is not on a player
  • On a player
  • Safe
  • On the VM
commented

Added a ton of new events. If I didn't include it above, I am choosing not to implement it. Situations such as "wool is safe in a chest" would be a pain to code for, and within the time constraint, I will choose not to code for it. The rest should be exceedingly easy to handle, and I'm happy to take care of it.

commented

This should now be fully implemented, with the notable exception of objective state changes. The framework is there, but the code hasn't been written yet. I have uploaded a new JAR with all of these messages working as expected (hopefully).

commented

I think the armor-event and the player-objective-event doesn't get sent when a referee logs in. I haven't tested them all yet. (Killstreak, kills, deaths, health get sent. I've never really seen the accuracy been sent but I haven't done any long tests yet so it could be because of that.)
And I think you don't send a "init" message when you do /reload