Server Patches

[LewisH]

I've been working on deobfuscating the source code of the altitude server software, and recently found a use for my work - making small modifications to add functionality not possible through the API exposed by the default server.

https://gitlab.com/alti2d/server_patches

To use the patches, replace your `game.jar` with the version in the release directory in the repository, and copy `mods.hjson` and `permissions.hjson` to the `altitude/servers` directory. Most things are disabled by default, have a look at mods.hjson to see what can be changed.

As well as the patches, the repository contains the libraries and game.jar needed to compile these and any future patches. A makefile is included, which calls javac with the game.jar and libraries added to java's classpath, then constructs a new `game.jar` with the patches applied ^^

Suggestions for new patches are always welcome.

[biell]

Very nice, it looks like this could very easilly be modified to enforce different level requirements for ACE 0 vs ACE 1-10.

[LewisH]

Added the commands patch, which includes infrastructure for adding new server commands. For now, these commands can only be executed through the commands.txt file. (The server knows about the commands, but they're not sent to the client)

make build_commands
7z a /path/to/game.jar out/commands/*
# re-launch server
echo "27276,console,setTime 0" >> /path/to/altitude/servers/command.txt

Included Commands:

setTime <value>
Overrwrites the elapsed time in timed games. The single parameter is an integer number of ticks, where there are 30 ticks in a second.
e.g. In a game with 7 minute rounds, `setTime 0` will set the elapsed time to 0, so the remaining time will be 7:00, `setTime 12600` will end the round.

[LewisH]

Originally Posted by biell

Very nice, it looks like this could very easilly be modified to enforce different level requirements for ACE 0 vs ACE 1-10.

Indeed, there's also quite a lot of extra information that I haven't exposed through `JoinReqInfo`, mostly because I'm not quite sure what it all is yet ^_^

[biell]

Can you update log entries? These are the 4 things I really wish could be changed:

* When a turret or base is destroyed, log the X and Y coordinates of that object,
* when a powerup is picked up, log the velocityX and velocityY of the player,
* make Hoops show up and log when a player goes through them, and
* fix the powerup bug so newly joined players don't see powerups which aren't there.

If it is in your power to fix any of these, I would love to see it.

[LewisH]

Originally Posted by biell

Can you update log entries? These are the 4 things I really wish could be changed:

* When a turret or base is destroyed, log the X and Y coordinates of that object,
* when a powerup is picked up, log the velocityX and velocityY of the player,
* make Hoops show up and log when a player goes through them, and
* fix the powerup bug so newly joined players don't see powerups which aren't there.

If it is in your power to fix any of these, I would love to see it.

The first two should be simple enough, I'll add those tomorrow morning. I'm not sure about the other two, at a glance I don't see any specific code in the tutorial game mode related to the hoops, nor is there anything blocking it with an instanceof test, but I'll look into it more.

Edit:

Added turret position to structureDestroy log event:

{"positionY":609,"port":27276,"xp":10,"time":80622,"type":"structureDestroy","player":0,"target":"turret","positionX":3549}

The turret class (Ww.java) is a bit of a mess at the moment, inner classes are decompiled as seperate classes, with a bunch of synthetic static methods added to the main class to access it's members. To recompile, they need to be inner classes for the outer class to access their private constructors, so for now I've made them static inner classes, and left the synthetic methods in. I might get around to refactoring this at some point, but it works well enough for now. Note that the turret serialisation class also uses these synthetic methods, so that'll have to be fixed too.

Edit:

Added the same for bases:

{"positionY":475,"port":27276,"xp":30,"time":896715,"type":"structureDestroy","player":0,"target":"base","positionX":3184}

Added player velocity to powerupPickup event:

{"powerup":"Ball","positionY":661,"playerVelX":12.97,"playerVelY":-5.22,"port":27276,"velocityX":0,"time":15239,"type":"powerupPickup","velocityY":0,"player":0,"positionX":1800}

[LewisH]

Added a new log entry, playerInfoEv, triggered every time the server receives a player info event. The client sends this event when they change plane setup, change team, level up, change ace, or leave the server.

For now, the entry contains only some of the data included in the event. A couple of examples:

edit: The format has changed a little, see two posts below.

{"isJoin":true,"plane":"LOOPY","playerNo":0,"ace":0,"level":1,"port":27276,"perkGreen":0,"perkRed":0,"team":"Blue Team","time":273735,"type":"playerInfoEv","perkBlue":0}

{"isJoin":true,"plane":"LOOPY","playerNo":0,"ace":0,"level":2,"port":27276,"perkGreen":0,"perkRed":0,"team":"Blue Team","time":281959,"type":"playerInfoEv","perkBlue":0}

The perks are an integer, where 0 is the first perk in the set (e.g. tracker), 1 the second, and so on. I have no idea why the plane names are in capitals, I though I was reading that the same way as the other log entries, which use mixed case.

[biell]

Why not follow the same convention used in the "spawn" event? Where, perks are text strings and teams are integers? Also, why not "player", which is standard in other log entries?

I didn't notice your edits to add my requests. I will play around with running the patched code and adding these fields to my alti+server script.

Thanks.

[LewisH]

Ah, I don't actually use the logs much myself, so I hadn't noticed that perks were different - I was using the default toString for everything.
https://gitlab.com/xalri/server_patc...328ceafccc1661

This should fix it - every field which is also used in other log entries now uses the same format, and playerNo has been renamed to player. I had a look at the previously named `isJoin` field of the event, and it's actually quite the opposite - it's only false just as the client is leaving, so I've flipped it and renamed it to `leaving`. Some new example entries:

// Joining the server
{"plane":"Loopy","ace":4,"level":60,"port":27276,"perkGreen":"Heavy Armor","perkRed":"Double Fire","team":2,"time":435644,"type":"playerInfoEv","leaving":false,"perkBlue":"Turbocharger","player":1}

// Joining Red team
{"plane":"Loopy","ace":4,"level":60,"port":27276,"perkGreen":"Heavy Armor","perkRed":"Double Fire","team":3,"time":486878,"type":"playerInfoEv","leaving":false,"perkBlue":"Turbocharger","player":1}

// Switching planes (without spawning)
{"plane":"Explodet","ace":4,"level":60,"port":27276,"perkGreen":"Flexible Wings","perkRed":"Thermobarics","team":3,"time":532207,"type":"playerInfoEv","leaving":false,"perkBlue":"Turbocharger","player":1}

// Leaving the server
{"plane":"Loopy","ace":0,"level":1,"port":27276,"perkGreen":"No Green Perk","perkRed":"Tracker","team":2,"time":576477,"type":"playerInfoEv","leaving":true,"perkBlue":"No Blue Perk","player":1}

There's still a lot of overlap with existing events - but without introducing more state it would be difficult to tell from within the event whether it's a duplicate. The original use case is tracking level ups for a tutorial server ^^

edit: Note that in the leave event, the plane type and perks are always set to 0, so perkless tracker loopy.

[biell]

I was updating my alti+server code to opportunistically take advantage of your changes (if pickup playerVelX exists, use it instead of calling logPlanePositions and calculating direction when that comes in). Everything still works without your patches, so now I need to install your patches and test out the new code paths. I should get to testing against the patched server this week.

A couple things I noticed:


1. In playerInfoEv, you use "ace", but clientAdd uses "aceRank", it would probably be good to stay consistent with clientAdd.


2. With your custom join code, how hard would it be to allow for new XML entries in the AltitudeServerConfig entry in the launcher_config.xml. Next to minLevel and maxLevel, there are a number of options, one could be minAce or maxAce. I actually don't know how the server responds. But, if you were level 10, ace 10 and maxLevel was set to 30, would you be allowed in? If so, people could ace up and go abuse some newbies. It would be nice if a server could be configured for max ace level 0, max level 59. Then, you would have to smurf to abuse the newbies. Also, what I would like to see are minNoviceLevel and minAceLevel whereby the former counted only for Ace0 players and the latter was for Ace1-10. I might be OK with level 8 Ace 5 players in a game, but not want level 30 Ace 0 players. I think this will depend a lot on the XML parser code inside the server. If the data structure is auto-generated from the XML file, this may not be too much work. If there is an XML content specification somewhere, then this would be much harder.


3. When a turret kills a player, the log lists the "source" as "turret", and the "player" ID as "-1". The Altitude server doesn't log when a non-player destroys a structure "if(entity instanceof mN)" and I would prefer it to be more like turret kills of players. Is it possible to remove the dependency for an the damage source to be an insance of mN? I would like to know when a structure is destroyed by a turret by seeing a log with the player ID of "-1". My "ruin" game type has to be very carefully designed right now to ensure turrets cannot kill structures. If I can handle those events, it will make the ruin game type easier to design.

4. During server initialization, you may want to add a field (or add your own new log entry afterwards) which lists the existence of your add-ons. For example, it would be easy for me to read that and use it to know if your "setTime" command is available for use. I want to opportunistically take advantage of your enhancements without requiring their existence. Even though nobody else uses my code, I want to keep it easy to use in case that changes.

[biell]

Originally Posted by LewisH

Added player velocity to powerupPickup event:

{"powerup":"Ball","positionY":661,"playerVelX":12.97,"playerVelY":-5.22,"port":27276,"velocityX":0,"time":15239,"type":"powerupPickup","velocityY":0,"player":0,"positionX":1800}

Can you add "powerupAutoUse" to cover health?

[LewisH]

Originally Posted by biell

1. In playerInfoEv, you use "ace", but clientAdd uses "aceRank", it would probably be good to stay consistent with clientAdd.

Originally Posted by biell

Can you add "powerupAutoUse" to cover health?

Originally Posted by biell

3. [...] Is it possible to remove the dependency for an the damage source to be an insance of mN? I would like to know when a structure is destroyed by a turret by seeing a log with the player ID of "-1".

Done, done, and done, and updated the readme with new examples ^^
I also added positions to `structureDamage` events, but they (the damage events) still only trigger when the entity is a player.

Originally Posted by biell

2. With your custom join code, how hard would it be to allow for new XML entries in the AltitudeServerConfig entry in the launcher_config.xml

Adding to the main `launcher_config` is non-trivial, but putting that data in a separate file (similar to what the current example of a whitelist does) works.

I've added a new (completely untested, but it compiles) example to `custom_join` which implements this, uncomment line 18 and comment line 19 to switch from the whitelist to the level restriction. The comments above each function describe how they work.

It looks like a general re-loadable configuration file which can be used by any mods would be very useful, I'll try to implement that at some point.

Originally Posted by biell

During server initialization, you may want to add a field (or add your own new log entry afterwards) which lists the existence of your add-ons. For example, it would be easy for me to read that and use it to know if your "setTime" command is available for use. I want to opportunistically take advantage of your enhancements without requiring their existence.

It's probably possible to add a global list of mods, then add an entry to it statically from one class in each mod, but that would be rather messy. I'll look into a proper solution for this later.

Originally Posted by biell

Even though nobody else uses my code, I want to keep it easy to use in case that changes.

FWIW, I use a local alti+server for solo coop runs, so there's at least one other person using it :3

[biell]

Originally Posted by LewisH

Done, done, and done, and updated the readme with new examples ^^
I also added positions to `structureDamage` events, but they (the damage events) still only trigger when the entity is a player.

Thanks, thanks, and thanks. I tested all three and they are working good. It will take me some time to work in the structureDestroy to my code, and I think I will read the log entry you are working on to add extra features.

Originally Posted by LewisH

Adding to the main `launcher_config` is non-trivial, but putting that data in a separate file (similar to what the current example of a whitelist does) works.

I've added a new (completely untested, but it compiles) example to `custom_join` which implements this, uncomment line 18 and comment line 19 to switch from the whitelist to the level restriction. The comments above each function describe how they work.

That is cool, I don't currently have a absolute need for this, what I have works well enough. I will take a look at it in more depth soon.

Originally Posted by LewisH

It looks like a general re-loadable configuration file which can be used by any mods would be very useful, I'll try to implement that at some point.

It looks like you are already working on this, is that what the JSON parser code is for?

Originally Posted by LewisH

It's probably possible to add a global list of mods, then add an entry to it statically from one class in each mod, but that would be rather messy. I'll look into a proper solution for this later.

This looks to be coming along pretty well. I was going to settle for something sent to stdout, but the "serverPatches" log entry looks pretty good. I am really keen on getting to be able to assignTeam bots, this will help out for an issue in my capture-the-flag game type. So, once that feature is listed in "serverPatches", then I will start coding it up.

I can't get "setTime" to work anymore. I know it used to, but not anymore. Is it still working for you? I was pulling from gitlab as you were working, so I pulled from multiple commits, including after you removed the "Testing" message.

I have the mods running on my Map QA, Team+, and Coop+ Advanced servers. I will add it to Coop+ when it is empty. Really great work.

Originally Posted by LewisH

FWIW, I use a local alti+server for solo coop runs, so there's at least one other person using it :3

Good to know, let me know if you have any questions. If you want to compare any of your settings with Coop+ or Coop+ Advanced, you can get my server and map settings from http://altiplus.glaciated.org/ .

[LewisH]

Originally Posted by biell

I am really keen on getting to be able to assignTeam bots, this will help out for an issue in my capture-the-flag game type. So, once that feature is listed in "serverPatches", then I will start coding it up.

Everything with bots is still a WIP. You can assignTeam them, but as soon as you do they switch back to whichever team they think they should be on. I'm still looking for the main bot control code, I expect once I find that, the rest will come quickly, most of this is removing some if statements which filter out bots ^^

My plans for bots are pretty simple:

- An option to disable their default team switching behaviour - when enabled bots will stay in whichever team they're assigned to
- Allow bots to be selected in any command which takes a nickname (only really useful for /assignTeam, kicking/banning bots is not a good idea) (done)
- Allow bots to join tournaments (done)
- Adding and removing bots with commands (`/addBot` & `/removeBot`)

With a bit more exploration I should have a better idea of what else is possible, and hopefully a more clear picture of the joining teams/spawning process in general. I'll post about this when I've implemented the points above.

Originally Posted by biell

I can't get "setTime" to work anymore. I know it used to, but not anymore. Is it still working for you?

Yeah, it still works here. I've refactored it a little this morning, moving the generic command stuff to inside `base` and the setTime command to it's own patch. Speaking of refactors, for anyone else reading this thread:


Added base Patch

A base patch has been added containing some common code, which all other patches depend on:

- A patch initialisation system - All patches are initialised as the server launcher starts, they add themselves to a global list of installed patches and run any initialisation code they need.
- The infrastructure for adding commands has been moved from `commands` to the base patch. The setTime command is now in it's own patch.
- A global configuration system for mods. Configuration is kept in mods.hjson and can be reloaded at any time by running the `/reloadModConfig` command on any port through commands.txt.

[biell]

Originally Posted by LewisH

Everything with bots is still a WIP. You can assignTeam them, but as soon as you do they switch back to whichever team they think they should be on.

That is OK with me, I actually want to assign them back to whatever team they are on, to force them to respawn after a flag is captured. This simulates what happens in a ball mode game when a goal is scored.

Originally Posted by LewisH

- Allow bots to be selected in any command which takes a nickname (only really useful for /assignTeam, kicking/banning bots is not a good idea) (done)

/overrideSpawnPoint would be nice too.

Originally Posted by LewisH

- A global configuration system for mods. Configuration is kept in mods.hjson and can be reloaded at any time by running the `/reloadModConfig` command on any port through commands.txt.

I opened up a gitlab issue about the location for that file, if you would rather I put that stuff here, just let me know.

[LewisH]

Permissions

A new non-hierarchical permissions system has been added, which works with built-in commands as well as custom commands defined in `custom_json_commands.txt`.

make build_all
7z a /path/to/game.jar ./out/**/*
cp ./{permissions.hjson, config.hjson} /path/to/altitude/servers/

A set of groups are defined, each containing any number of users identified by their vapor IDs.
Each command then has a list of groups which can use that command, with the special group names 'all' and 'vote' being used to allow anyone to use the command, or anyone to call a vote for it, respectively.

Permissions can be reloaded using the `realodPermissions` command.

An example permissions file:

{
   // user_groups: Define groups of users to give permissions to use
   // specific commands. Groups can have any name and any number of users,
   // each group is a list of vapor IDs.
   // The group names "vote" and "all" are reserved for /vote commands
   // and all users respectively, and cannot be overwritten.
   // Admins defined in launcher_config.xml are part of the 'admins' group.
   user_groups: {
      admins: [
         00000000-0000-0000-0000-000000000000
         00000000-0000-0000-0000-000000000000
      ]
      moderators: [
         00000000-0000-0000-0000-000000000000
      ]
      my_amazing_group: [
         00000000-0000-0000-0000-000000000000
      ]
   },

   // Specify which user groups can use specific commands.
   // Use 'vote' to allow commands to be used through /vote or 'all' to
   // allow anyone to use the command. Leave the array empty to disable
   // the command.
   commands: {
      reloadModConfig: ["admins"]
      reloadPermissions: ["admins"]
      setTime: ["my_amazing_group"]

      vote: ["all"]
      castBallot: ["all"]
      listMaps: ["all"]

      drop: ["admins", "moderators", "vote"]
      changeMap: ["admins", "moderators", "vote"]
      balanceTeams: ["admins", "moderators", "vote"]
      startTournament: ["admins", "moderators", "vote"]

      /* removed most commands to keep the post short,
      * see the full file in the repo ^^ */
   }
}

[LewisH]

Things have changed -- The mods are no longer split up into patches, for easier matinence.

I've added the overrideTdmScore, which works in the same way as overrideballScore but for TDM ^^

[LewisH]

Some recently added features:

• A game.jar with the patches included is now available in the repository
• The nickname changing bug, where nickname changes were not shown int the JSON log has been fixed
• Latency for commands.txt is now virtually zero -- it watches for changes to the file, rather than polling every 250ms, so commands should be executed instantly.
• More commands have been added ^^
• More information has been added to the JSON logs.

More information is in the repo's readme: https://gitlab.com/xalri/server_patches

[LewisH]

A few recent additions:

- Implemented a workaround for the config packet size limit.
- Added commands for controlling bots (adding and removing them, as well as individually setting their plane setups).
- Added commands for resetting the ball (as if it was lost), respawning it in either a given location or the ball spawn point of a given team.
- /assignTeam can now be used in FFA for respawning players and changing their colour.
- Player stats are tracked per-life as well as per-round, and are logged when a player disconnects.

https://gitlab.com/xalri/server_patches ^^