Altitude Game: Forums  

Go Back   Altitude Game: Forums > Altitude Support > Dedicated Server

Dedicated Server Discuss technical issues related to hosting your own servers.

Reply
 
Thread Tools Display Modes
  #1  
Old 06-28-2016, 08:38 PM
LewisH LewisH is offline
Senior Member
 
Join Date: Mar 2012
Location: Earth
Posts: 215
Default Server Patches

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.

Last edited by LewisH; 06-27-2017 at 10:59 PM.
Reply With Quote
  #2  
Old 06-28-2016, 09:50 PM
biell biell is offline
Senior Member
 
Join Date: May 2015
Posts: 168
Default

Very nice, it looks like this could very easilly be modified to enforce different level requirements for ACE 0 vs ACE 1-10.
Reply With Quote
  #3  
Old 06-29-2016, 02:39 PM
LewisH LewisH is offline
Senior Member
 
Join Date: Mar 2012
Location: Earth
Posts: 215
Default

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)

Code:
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.

Last edited by LewisH; 06-29-2016 at 04:17 PM.
Reply With Quote
  #4  
Old 06-29-2016, 02:41 PM
LewisH LewisH is offline
Senior Member
 
Join Date: Mar 2012
Location: Earth
Posts: 215
Default

Quote:
Originally Posted by biell View Post
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 ^_^
Reply With Quote
  #5  
Old 06-30-2016, 11:18 PM
biell biell is offline
Senior Member
 
Join Date: May 2015
Posts: 168
Default

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.
Reply With Quote
  #6  
Old 07-03-2016, 09:34 PM
LewisH LewisH is offline
Senior Member
 
Join Date: Mar 2012
Location: Earth
Posts: 215
Default

Quote:
Originally Posted by biell View Post
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:
Code:
{"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:

Code:
{"positionY":475,"port":27276,"xp":30,"time":896715,"type":"structureDestroy","player":0,"target":"base","positionX":3184}
Added player velocity to powerupPickup event:

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

Last edited by LewisH; 07-04-2016 at 11:10 AM.
Reply With Quote
  #7  
Old 08-25-2016, 07:42 PM
LewisH LewisH is offline
Senior Member
 
Join Date: Mar 2012
Location: Earth
Posts: 215
Default

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.

Code:
{"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.

Last edited by LewisH; 08-26-2016 at 12:47 PM.
Reply With Quote
  #8  
Old 08-25-2016, 11:36 PM
biell biell is offline
Senior Member
 
Join Date: May 2015
Posts: 168
Default

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.

Last edited by biell; 08-25-2016 at 11:39 PM.
Reply With Quote
  #9  
Old 08-26-2016, 09:47 AM
LewisH LewisH is offline
Senior Member
 
Join Date: Mar 2012
Location: Earth
Posts: 215
Default

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:

Code:
// 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.

Last edited by LewisH; 08-26-2016 at 12:46 PM.
Reply With Quote
  #10  
Old 08-29-2016, 04:59 PM
biell biell is offline
Senior Member
 
Join Date: May 2015
Posts: 168
Default

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.
Reply With Quote
  #11  
Old 08-30-2016, 03:15 AM
biell biell is offline
Senior Member
 
Join Date: May 2015
Posts: 168
Default

Quote:
Originally Posted by LewisH View Post
Added player velocity to powerupPickup event:

Code:
{"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?
Reply With Quote
  #12  
Old 08-30-2016, 06:17 PM
LewisH LewisH is offline
Senior Member
 
Join Date: Mar 2012
Location: Earth
Posts: 215
Default

Quote:
Originally Posted by biell View Post
1. In playerInfoEv, you use "ace", but clientAdd uses "aceRank", it would probably be good to stay consistent with clientAdd.
Quote:
Originally Posted by biell View Post
Can you add "powerupAutoUse" to cover health?
Quote:
Originally Posted by biell View Post
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.

Quote:
Originally Posted by biell View Post
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.

Quote:
Originally Posted by biell View Post
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.

Quote:
Originally Posted by biell View Post
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

Last edited by LewisH; 08-30-2016 at 11:43 PM.
Reply With Quote
  #13  
Old 08-31-2016, 02:36 AM
biell biell is offline
Senior Member
 
Join Date: May 2015
Posts: 168
Default

Quote:
Originally Posted by LewisH View Post
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.

Quote:
Originally Posted by LewisH View Post
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.

Quote:
Originally Posted by LewisH View Post
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?

Quote:
Originally Posted by LewisH View Post
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.

Quote:
Originally Posted by LewisH View Post
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/ .
Reply With Quote
  #14  
Old 08-31-2016, 04:30 PM
LewisH LewisH is offline
Senior Member
 
Join Date: Mar 2012
Location: Earth
Posts: 215
Default

Quote:
Originally Posted by biell View Post
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.

Quote:
Originally Posted by biell View Post
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.

Last edited by LewisH; 08-31-2016 at 05:37 PM.
Reply With Quote
  #15  
Old 08-31-2016, 09:34 PM
biell biell is offline
Senior Member
 
Join Date: May 2015
Posts: 168
Default

Quote:
Originally Posted by LewisH View Post
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.

Quote:
Originally Posted by LewisH View Post
- 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.

Quote:
Originally Posted by LewisH View Post
- 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.
Reply With Quote
  #16  
Old 09-02-2016, 07:09 PM
LewisH LewisH is offline
Senior Member
 
Join Date: Mar 2012
Location: Earth
Posts: 215
Default

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`.

Code:
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:

Code:
{
   // 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 ^^ */
   }
}
Reply With Quote
  #17  
Old 12-16-2016, 09:51 PM
LewisH LewisH is offline
Senior Member
 
Join Date: Mar 2012
Location: Earth
Posts: 215
Default

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 ^^
Reply With Quote
  #18  
Old 02-18-2017, 05:44 PM
LewisH LewisH is offline
Senior Member
 
Join Date: Mar 2012
Location: Earth
Posts: 215
Default

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

Last edited by LewisH; 02-18-2017 at 05:52 PM.
Reply With Quote
  #19  
Old 03-10-2017, 07:28 PM
LewisH LewisH is offline
Senior Member
 
Join Date: Mar 2012
Location: Earth
Posts: 215
Default

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 ^^
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Altitude+ server (yet another server manager) biell Dedicated Server 18 03-12-2017 05:21 AM
DONE - Server maintenance: November 19th, upgrading server hardware Karl News 6 11-21-2013 09:11 PM
Balance Changes in recent patches listie Suggestions 11 05-12-2013 07:11 AM
Can't read server log while server is open LewisH Dedicated Server 1 08-14-2012 11:58 PM
How do i post a server message in my server without joining the server? Knight Dedicated Server 22 09-27-2010 10:02 PM


All times are GMT. The time now is 06:43 AM.


Powered by vBulletin® Version 3.8.2
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
2008 Nimbly Games LLC