Altitude+ server (yet another server manager)

[biell]

I wrote an Altitude server manager program which was originally supposed to support new map testing, Quality Assurance testing, and player satisfaction. The idea was to make it easy for map makers to upload maps to the server, test, make changes, and upload a new version. But, I went way overboard.

The server I wrote facilitates the above, but it also adds a "console" interface to the server making it easy to interact with the alttude server. Most importantly, it adds functionality which map makers can use to create new kinds of game types and map layouts. You can read more about it on GitHub, but first, here are some highlights:

* You can set plane/camera scale, gravity, initial ball score, force players to a specifc team for
coop and these settings will be stored per map and re-activated each time the map loads.

* You can change how players spawn, there are multiple spawn modes, like where a player dies,
in a zone, near to where they dies (nearest to a set of preconfigured spawn zones), or where
the player found their most recent powerup (any powerup, or just health powerups).

* You can allow only certain planes. Make everyone play Biplane, or just disallow Loopies.

* Extended concepts are added: portals (you reach a specific powerup, and are automatically
respawned in another location), doors (you cannot pass a specific powerup until other
powerups representing keys are found), checkpoints (each checkpoint is worth a goal, when
a team gets past enough checkpoints they get 6 goals and win the race).

There are lots of fun game type which can be created using the functions provided by this software. Feel free to contact me with any questions and I will be glad to help. I would love to develop maps using these concepts, but I can't get the map_editor functioning under Linux.

I am releasing the code into the public domain, so you can feel free to use it however you like. You can re-use code, concepts, run the server as is, whatever you like. This is especially important as the whole thing is written in perl, and probably most people would rather re-write it in another language. All of which is OK with me.

You can view the documentation and code on GitHub:

https://github.com/biell/alti-server

I have this code running on my MapQA server. But, I would love to see it running elsewhere and new maps created which take advantage of some of it's features. Some of the maps on MapQA which illustrate some of the features:

* ball_coop_adventure_m - Camera Scale, Plane Scale, Gravity, spawn where you die
* ball_rat_race - Camera Scale, Plane Scale, Gravity
* tbd_construct - Camera Scale, Plane Scale, Gravity
* ball_firepark - Camera Scale, Plane Scale
* tbd_coop_cloud - spawn at location of last health pickup
* tbd_coop_lol - spawn at location of last health pickup
* tbd_coop_beach - doors and keys
* ball_football - Camera/Plane Scale, Gravity, spawn mode "near", no Loopy planes.
* ball_basket_or_else - Initial score set to 4 - 4, only 2 goals to win.

All COOP maps are implemented with force assigning players to the correct team. These settings are interesting tweaks to existing maps, but the capabilities of this server would be better suited to maps designed to use them.

[tomato man]

So many new awesome ideas! How long you worked on this? Cus it looks like a very long and boring work! Anyways, very thanks for all this it should refresh a lot the game, if we manage it well

[biell]

Thanks, I worked on it in my spare time for a couple months, probably averaging just above an hour a day. I like this kind of programming, so it was mostly fun.

[sloppy seconds]

Looking at this Perl code makes me regret choosing C++ for my own server tools. Your code is very compact and expressive for what it provides. I can tell you write a lot of Perl =)

[Brutal]

Awesome. Your coding work has really improved since you hosted that server for me a few months back. I'm impressed. Keep up the good work!

[Oyster]

This is awesome.

Say I wanted to make a racing map where people respawned at a certain location closest to where they died. How do I indicate these 'checkpoints' in the map editor?

[biell]

You use powerups, and tell the server that the specific list of powerups count as a named checkpoint. You can use health, or any other kind of powerup. I would be wary of rockets, because you must make the powerup auto spawning, because you need each player to cross the powerup (more on that later).

So, if you put a line of health powerups across the track (say at 345,500 365,520 385,530 405,550 425,570 445,590 465,590) you would enter this into the server as an admin:

/add powerup cp1 left 345,500
/add powerup cp1 right 345,500
/add powerup cp1 left 365,520
/add powerup cp1 right 365,520
...
/add powerup cp1 left 465,590
/add powerup cp1 right 465,590

Now, you probably also want to make sure people go forwards through the race, this can
be accomplished by setting these to also be oneway powerups (oneways are not team specific). Given the fact that the line I specifiec is a perfect top left to bottom right angle, I can use compass points. I am assuming here that the race relatively progresses in a clockwise fashion. So, I could specify "ne" here, or 45 for 45 degrees, they both work just as well (for illustration I will use both):

/add oneway 345,500 ne
/add oneway 365,520 45
...
/add oneway 465,590 ne

Now, you have your first checkpoint defined. You can call them whatever you want, but keeping with a naming convention is nice. If you are doing an "A" to "B" race, then you should probably specify 6 checkpoints with the 6th one being the finish line. If you want a 1 lap race, that is also how I would do it. I would spawn the players just to the left of the 6th checkpoint "cp6" with my naming convention.

If you want a 2-lap "A" to "A" race, then you would specify three sets of checkpoints, and spawn players just to the left of the finish line. On a two lap race, a player who fails to keep up will not be awarded a checkpoint if they are behind a lap. So, a player can't sit by the finish line on the first lap, and cross it early. That is why, you must auto spawn the powerups. To ensure the alti+code can keep an accurate track of what lap each player is on.

The first player on a team to cross a checkpoint will earn the goal for that checkpoint. That first player can be different each time. The same is true for the finish line. We could add a mode where the last person counts, but I didn't program it this way. That would be an easy addition.

You will also want players to spawn where died, so they don't fall too far behind. You perform this with the command:

/set spawnMode died

You should make your map of mode "ball" and name it "ball_race_whatever". This will auto clue my server code in to keep track of checkpoints. If not, you would also need to run "/set gameType race" to override the auto-detect feature.

In a crash situation, I spawn you in the exact opposite angle to how you died, so you don't keep on crashing.

One thing I have noted is that making planes smaller tends to affect offensive play substantially. I don't know if this will change with experience, but you may wish to shrink planes to make game play less offensive. You can do this with:

/set planeScale 80

Some planes are overly aggressive. If you wish to eliminate planes, you can specify a list of allowed planes for the race map:

/set planes Biplane|Miranda

Will only allow people to spawn with those two planes. I don't know if this is possible, but it is worth a try if it works. With plane restrictions, you may want to give people time to change planes from the last map. To do this, you could specify multiple Rounds (if it is possible to do that in ball play; I just don't know). That would be cool anyway, best 2 out of 3 races for example.

I hope this helps, please post any additional questions and I will be happy to answer them and update the wrapper code if needed.

[Kafka]

No way man!! I've lived in Delaware pretty much my whole life!

[biell]

I added code to alti+server to keep an internal representation of collidable objects. I can now detect if you died inside a wall, and try to spawn you outside of the wall. If I can't find a place outside of the wall, I will spawn you at your last spawn point. For races, I add a spawn point everytime you go past a checkpoint now, so the absolute worst that will happen is that you spawn there.

I am also logging wall deaths in an effort to root out coop records caused by mis-using randa/rev/rubber . If I find this, I will delete the record and ban that plane configuration on that map. If anyone knows of maps which have large portions which can be skipped with this plane configuration, please let me know so I can disable this plane configuration.

I now check your spawn angle aganst the collidable objects, and turn you until you are at a safe spawn angle (no more guess work like before, I test your spawn angle against the actual map). If you hit perpendicular to where you want to go, I may turn you around, but otherwise you will usually be pointed exactly the way you want to go. I verify your spawn point/angle at 30, 60, and 90 points out, so your spawn velocity won't crash you right away, but you may have to put on the brakes and turn quickly.

I uploaded these changes to Team+ (races) and Coop+ which use the spawnMode of 'died' the most.

No spawn logic is going to be perfect, but if you see anything which looks pathological, then please let me know. I am confident I have this better than it used to be. But, there may be edge cases I need to account for.

[biell]

Alti+ now has an additional key feature for doors. This feature is inspired from the thread 10154 discussion.

A new type of key is added which does not affect the old type. In fact, if you were to have both types of keys defined on a map, then they would each work independently of each other. The new type of key allows players to cross through a door only if they are carrying a powerup from a predefined list.

Imagine your map has a section which requires a shield and a wall, and you only want players with one of these two objects to be able to enter that section. You would define the door the same as you always would (Assuming the door is called "Gauntlet", and it applies to the left team):

/add door Gauntlet left 348,1029

Then, you would create two keys, one for each powerup type for the left team to the Door named "Gauntlet":

/add key ShieldKey Gauntlet left Shield
/add key WallKey Gauntlet left Wall

Now, if a player is carrying one of these two items, they can pass through. If a player does not have one of these two powerups and runs "/list doors", the door will be listed as being locked. However, if a player has one of the two items and runs "/list doors", the door will be listed as being open.

Any powerup can be specified except Health, as it is auto used and cannot therefore be carried.
You may also use the shortcuts "Charge" for "Demolition Charge", and "Missile" for "Homing Missile".

Although the behaviour is well defined, I would recommend against using both types of keys for the same door.

[biell]

In support of LewisH's server patches (see http://altitudegame.com/forums/showthread.php?p=197750), alti+ now supports setting the score in TDM.

The setting "ballScore" has now been renamed to "score". If you still have "/set ballScore" in a maps plus.txt file, don't worry. The server will still recognize that setting name there. From now on, you should use "/set score # #" in your settings file. Also, your json_stash will be automatically upgraded the first time you run the new alti+ version.

This new feature is especially helpful if you wish to create a tdm_race map. The one annoying thing about ball_race maps is that there is always an indicator telling you where the ball is. This disappears with tdm_race maps. Also, you can now set an arbitrary number of checkpoints to win. The only thing to keep in mind is that TDM has a timer, so you want the race to reasonably be finished before the timer runs out. Your server will require LewisH's patches for this to work I have an example tdm_race_clouds up on Map QA. The only real negative of this game mode for races is that the initial Altitude TDM screen message lasts for quite a while.

Also, now you can set the winning score in TDM such that the score is met, or the timer runs out (whichever comes first). This new feature works on all alti+ servers, with or without LewsiH's patches.

Anyone wishing to create a map using these new features which needs help, just reach out to me and I will be glad to help you.

[biell]

Anyone running an alti+ server will need to pull the latest source code.

To keep from trying to automatically restart a failed server against a down master server, I was performing a ping check of vapor.nimblygames.com before starting the server. The new master server is not pingable, so this was keeping alti+ from attempting to restart. I updated the code to comment out this check, and now everything is back to normal.

Sorry for any inconvienence. Map QA, Team+, Coop+, Coop+ Advanced, Football+ (US & EU) are all back up now.

[Karl]

Fixed. You can now ping the new vapor server.

[biell]

You didn't have to do that, but thank you. I added the ping check back to the code.

[biell]

I added a new game type "tag" to the alti+server code base. Just set the "gameType" parameter to "tag", and it will automatically enable the tag features. It only really makes sense for ffa game modes.

Logan dug up ffa_hide_and_destroy. We had fun playing it, but it does get annoying keeping track of who has been tagged. Now, the server does that for you. Additionally, if a player has been tagged it for more than a minute, the server will tell you what region of the map they are in. Then, after 2 minutes, it will provide exact position information. If players are killing non-it players, the server will remind them that is not how to play the game.

If the player who is tagged as it leaves the game, the server will randomly pick another player and assign them as being it.

After the timer expires, the server will add up for how long each player was tagged it, and list the 5 players on a leader board.

If you want to try it out, check out ffa_hide_and_destroy on the "Map QA" server.

[Kafka]

Originally Posted by biell

If you want to try it out, check out ffa_hide_and_destroy on the "Map QA" server.

I highly recommend it. We played a few rounds of this last night and it was a lot of fun

[biell]

The alti+server has a new spawnMode setting map. Frankly, I am embarrased that it took me this long to think of it. I have spent hours working out map aware spawn code for my "died" method to ensure you don't spawn into a wall, and the result is that in some instances, you end up spawning backwards. Which, it not cool on a race map.

The spawnMode map is pretty straight forward. You create a new view named exactly Spawn. On this view, create new walls/hulls/geometries (whatever you like to call them) which trace the path you want the plane to fly. You can use any layers you want on this view to organize them. Each point/vertext is a spawn point. The spawn angle is calculated to be directly to the next spawn point (so, visually, you can follow it by following the line on the screen). If you place any hull points off the playable map, they are ignored. Additionally, if you set a point's "alpha" color value to 0, it is ignored. I only look at the alpha part of the color you can set the rest to whatever you want.

If you get into a tight spot where you are afraid 2 points are too close on either side of a wall, you make a point less likely to be chosen by changing its alpha to something between 0 and 255. If you set a point alpha to 128, it is treated as being an extra 50% distance from the plane crash.

I recommend setting these walls to not be visible, that way they won't change the map for players.

This feature is most helpful for race maps, as they are tight and issues from other spawn methods are prevalent. Spawn points are for all players and cannot be team specific. If you need team specific spawn points, continue to use a spawnMode of zone.

So far, I have updated ball_race_gauntlet and ball_race_asteroids only, I will do the rest as I have time. Next is probably Oyster's ball_race_rainbow_road, as it continues to have spawn backwards issues due to how tight it is.

If you have any questions about how to use this feature, just let me know and I can go over it in more depth. This code was merged into git last night, so you have to download the latest code to use this functionality. Currently, I only have it running on Map QA and Team+.

[tomato man]

Awesome!! Finally a solution to sucide spawns on race maps! Nice work Biell!

[biell]

Alti+ server has the following enhancements when used in combination with Xal's (x.x, LewisH) patches:

Timer updates
Alti+ can now set the server times (for timed game modes) to 1 hour in the launcher_config.xml. You can set the map time on the server console for standard game modes, and extended Alti+ game types. For example, setting the tag game type timer to 20 minutes is:

/server set gameTime tag 1200

Map specific timers can be set when the map is loaded with:

/set gameTime 420

When setting the time, the server adds the warmup time to whatever parameter you provided, and that is what the timer is set to. So, 360 becomes a 6 minute match even after warmup.

Bot updates
When using a patches server, the number of bots on a map can be set with the command:

/set botCount #

Also, by default, the number of bots is set for the generic case. For 1-life Coop, the botCount is set to 1, and for other Coop, race, tag, and mdg, it is set to 0. Once I get this code loaded on Coop+, I will probably be putting the original better together back on the server with the map configured for 1 bot.

This is really nice for tag, b/c it ensures only one player is red on the whole server. Before, bots could show up as red.

Notification Engine
I added a notification engine for Alti+. The server recovers from most errors, and restarts the Altitude server, but I thought it would be nice to know when that happens. So far, there are two kinds of notifications, "info" and "warn". Both go to a file, and "warn" types can be send via either email or pushbullet. The log file is modeled after the altitude log.txt file, and looks almost identical.

I have only tested the mail notifications with gmail, but it should work with most SMTPS providers.

password protection
If you have a database password, email password, or pushbullet token, these are a little better obfuscated now. Before, I would just use the old WebSphere XOR with "_" trick. Now, I create a pad to XOR against using SHA512. By default, the pad uses informatiwarningson common, but unlikely to change from your server to seed the SHA512 hash. So, if you change a network card or a hostname, you may have to re-enter the password. You can also set the seed manually using the ALTITUDE_SALT environment variable. Or, you can request the alti+ server stop during bootup and request a passphrase to seed the SHA512 hash.