Patch: Feb 3rd, new maps, new server features for 3rd parties

[lamster]

================================================== ===============
February 3rd, 2010

New official maps: ball_planepark, tbd_planepark (thanks Mandrad)
New official map: tbd_nuclear (thanks Hartz)
New official map: tbd_focus (thanks Esoteric)
Updated ball_mayhem, ball_mayhem2, ball_core (thanks Maimer)

Added "Map Editor" and "Server Launcher" links to the main menu

Servers:

Added console command assignTeam <player> <team> (team -1 is spectator, 0 is left team, 1 is right team)
Added console command serverMessage <message>

Servers now write significantly more information to a special JSON-formatted log file for easy parsing by third-party tools: ~Altitude/servers/log.txt
Note: don't write your own parser, http://json.org/ provides handy parsing libraries for a wide variety of programming languages

You can now execute console commands on servers while they're running by writing lines to the file ~Altitude/servers/command.txt
Example: change the server running on port 27275's current map to ffa_cave
echo 27275,console,changeMap ffa_cave>> ~Altitude/servers/command.txt

Added support for custom voteable commands (edit ~Altitude/servers/launcher_config.xml to define custom commands)
Example: add a 'startLadder' command that requires 60% yes votes to pass:
Open ~Altitude/servers/launcher_config.xml with a text editor
For each server you'd like to modify, replace the line "<customCommands />" (or add a line just before <consoleCommandPermissions> if you're using an outdated config file) with:

      <customCommands>
        <CustomCommandDescriptor name="startLadder" votePassPercentage="60" />
      </customCommands>

You can then set up custom code to monitor the log file and respond to the custom command, for example when a line like this appears in ~Altitude/servers/log.txt:

	{"command":"startLadder","type":"customCommand","time":20428,"port":27275}
	(Note: your script should use a JSON-compliant parser to discover type=customCommand, command=startLadder, port=27275)

You can run custom code to initiate other events, for example show a message, balance teams, start a tournament, and change to a randomly selected map:

	echo 27275,console,serverMessage Initiating ladder game, leavers will be banned>> ~Altitude/servers/command.txt
	echo 27275,console,balanceTeams>> ~Altitude/servers/command.txt
	echo 27275,console,startTournament>> ~Altitude/servers/command.txt
	echo 27275,console,changeMap tbd_core>> ~Altitude/servers/command.txt

Fixed a few bugs

[nobodyhome]

a new patch made just for me!

thanks lam. i feel like mikesol.

[Deathblade]

cool

ilikecookies

[Stormich]

Thanks for the ladder support! <3

[eth]

Thanks a lot for the support, much appreciated

[r87]

I assume all those ball maps are what were on non-official 2...those are great updates and new maps.

[nesnl]

Is there a way to control the size of the log.txt or will it continually grow larger and larger? I am looking for a way to get it to roll over like serverlauncher.log.1, etc.

[lamster]

It currently grows to 4 MB, then rolls over to log_old.txt. I could go back to arbitrary rolling log counts (.1, .2, etc) but it seems like that confuses people.

[nobodyhome]

We often rerun old logs when we implement new features, so it would be nice to have it numbered (so that log_old.txt doesn't get overwritten) or at least to have it customizable somehow.

[lamster]

There's a lot more data in the new logs, so you may not want to keep them all around forever. For now, you can periodically check if the file ~Altitude/servers/log_old.txt exists, and if so rename it to log_<lastModifiedTimeInMilliseconds>.txt, that should ensure you'll have an orderly set of permanent logs.

[Triped]

Wow, this is a great patch.

[bong]

sweet! But i dont see the new maps on all official servers. Even official 3 still don't have fallout.

Thx

[Ajuk999]

I must say that before this update I could't make a server were other IP Addresses (people) could join, but after this Update, I was able to put a concept I had in to reality. I appreciate it Karl and Lam, You guys have made the most exciting game ever! I appreciate it a lot, Good Luck with the Indio Game Challenge, I am sure Altitude will win! I voted 52 times already!

[JDR]

Originally Posted by r87

I assume all those ball maps are what were on non-official 2...those are great updates and new maps.

planepark is the new tree, auto-changeMap

[spc]

is the link in the main menu for the server launcher supposed to send me to the altitude wiki? isnt it supposed to launch the servers?

[-MH-CaptainVogez]

I must say that this is a comprehensive list of critical little things in the game that you have managed to fix up well - Looking forward to being able to test it out when I get back online in the near future!

Kudos

[phong]

Good stuff lam

[phong]

What details currently being output to the log and are they written immediately?

[nobodyhome]

I too would like to know if the log reports are put out immediately. When I first examined the logs to see, it felt like there was a bit of a delay, not sure if this is true or not.

[lamster]

I'll post a list of log entry types soon, but you can figure out most important stuff from a glance at the logs (each entry has a type=<string>, for a given type the other parameters generally don't change)

The log is buffered to minimize I/O overhead, but the stream is flushed (all progress immediately written to disk) after a couple special log entry types:
1) tournamentRoundEnd -- to ensure match results are immediately ready at the conclusion of a ladder or tournament round
2) customCommand -- custom console commands exist solely for processing by 3rd-party server scripts, so the log is flushed upon execution to give the script a chance to read and react immediately

[nobodyhome]

That is a brilliant optimization, and causes no problems to my parser at all. Thanks for the info.

[nobodyhome]

Actually, thinking about it more, I might want it to flush more often, because in the future there might be an implementation of a "server status" page on the altitude website. These commands might be needed for such an implementation:

1. When people join or leave the server. This is so people can see who's on the ladder servers without actually having to go on altitude and joining the server. This feature is already there through the autobalance mechanism, but it would be a cleaner implementation to switch it over to the JSON logs rather than the debug logs. This feature could be further extended to an app that alerts you with sounds when 8 people are on or when 10 people tell the app that they want to play ladder (IT'S LADDERIN' TIME!) so you don't have to sit in the ladder server and wait.

2. When startTournament happens. This is so I can indicate on the server status page that a ladder game is in progress, and show what the teams are. This also helps for people who want to play--if they see 10 people on but the game has already started, they don't have to join altitude right away.

3. When changeMap happens. This is so I can indicate what the map is during a tourney game on the server status page.


The above are the minimum desirable log items that I would need to be flushed immediately if I were to implement a server status page. Of course these items are already available on the debug logs, but it's cleaner to have it all on the JSON logs, and I don't see why it would cause an excess I/O load on the game if it already flushes this information to debug logs.

Here are other things that would be a nice luxury to have flushed immediately:

1. Bomb hits. This is so I can track remaining base HP on the server status page so people will know how long a game has until it's finished.

2. Pretty much everything else--kills, powerup gets, powerup usage, bomb pickups. This is so I can go crazy with the server status page and display the actual scoreboard on the website, and then log all this stuff in real time so people not in the game can actually see what's happening through a scrolling log of powerup pickups and uses and kills etc. Or to go even crazier I can display graphically where the planes are on an image of the map and have little icons indicating kills, etc, so you can actually see a dinky jerky version of the game in a stop-motion animated way.


I'm not sure how bad on I/O having these things flush immediately would be, but I'd like this to happen if it's not bad.

[lamster]

I'll flush the logs to disk every 500 milliseconds next patch, should still be pretty friendly on the I/O and should be plenty quick for "play by play" style output (you can always hold the playback a couple seconds behind the actual action and then use the "time" stamp on each JSON entry for exact relative timing between "live" events).

[phong]

I also noticed if I move the log and recreate, the file I renamed it to continues to grow, not log.txt

ie #mv log.txt log.1.txt && touch log.txt

Logs now get dumped to log.1.txt, not log.txt.

Clearing the logs with something like #cp log.txt log.1.txt && >/home/jaredo/altitude/servers/log.txt

Log gets cleared, then all data from the previous log gets dumped back to log.txt.

Also I'm not sure if I like how players are identified in the logs. When a player joines then get assigned a playerID, which is then used throughout. In order to parse I'll have to put something together to constantly check the player ID and see who last logged in and was assigned that ID. Overall a big pita to parse, same withi teamID.

Are teamIDs static? IE team 3 is always red, 4 blue, 5 green etc?

[nobodyhome]

Originally Posted by phong

Also I'm not sure if I like how players are identified in the logs. When a player joines then get assigned a playerID, which is then used throughout. In order to parse I'll have to put something together to constantly check the player ID and see who last logged in and was assigned that ID. Overall a big pita to parse, same withi teamID.

Have you tried this?

1. Every time someone joins the server, create a Player object (that contains vaporId, name, or whatever else information you want), and then put it in a "players in server" array with the key being the playerId that it gets assigned to.

2. Every time someone leaves the server, remove said Player object from the array.

3. In the middle of the game, always refer to the player by its player ID. If you need the vaporId of the player, get the player object and then get the vaporId.

[StarkJohan]

I'm a noob when it comes to altitude with my 30-something hours of play but this kind of logging is really adding another level of fun to the game for me and as I see it, to the altitude community.
All I've seen so far when it comes to altitude is ranking by KD-ratio and that is a very rough way of calculating the "skill" of a player. So is number of kills, total time of play and so on. I used to run a counterstrike server back in the day and I always loved playing around with the ranking and stats. After testing a couple of ways to rank my players I came to the conclusion that the psychostats (PS) model is my preferred way of performing the tast. At that time PS basically used the ELO model which is a very sophisticated way of comparing competitors based on result. Since then PS has abandoned ELO for a simpler, yet effective algorithm. I think that both algorithms is superior to a simple KD-ratio factor based rank.

What these models use is a "skill" value that ranks individual players. This value is changed with every kill/death. Depending on the killers and victims current skill value the new value is calculated. E.g. if a highly ranked player kills a player with a much lower skill value the difference is small. Should the kill be the other way around the difference is bigger. This makes playing hours less important and who you kill, who kills you, how many times and at what point the main ingredient in the skill recipe. Every new player enters the ranking with a basic skill value to even things out and to avoid negative values.

Ultimately won rounds, bombed targets, defused bombs, blocked bombs and so on would be incorporated in a players skill value. My suggestion is that these events have a static bonus value that is added to the players skill value and divided by playing time but this is probably not the best solution.

Another thing to be aware of is bot kills. One take is to simply not count kills where bots are involved, another to give the bots a basic skill value that is used to calculate the players skill change.

Is there anybody out there already using other models than KD-ratio for ranking? What are your thoughts on ranking? What servers, if any, even bother with ranking? Is there any interest at all in this kind of discussion or implementations? I would love to see what models is already being used by altitude server admins but I haven't been able to find much info (except the NES webpage).

References:
Psychostats: http://www.psychostats.com
ELO: http://en.wikipedia.org/wiki/Elo_rat...ential_variant
NES: http://vihart.com/NEStats

[Pieface]

If you haven't already you should check out the Altitude Ladder thread, as that is by far the biggest ranking system yet attempted for the game. I'm sure they'd welcome any input or feedback you have to offer!

[nobodyhome]

The altitude ladder (http://altitudegame.com/forums/showthread.php?t=2469), built before this patch was implemented, uses the Elo system (modified to incorporate team-based games) to implement a ranking (and was a big part of why this patch was written).

So far we only incorporate tracking of wins and losses (which was the only thing we could do with the old logging system). With this new patch however, we are planning to incorporate more sophisticated stat tracking in the future.

[StarkJohan]

I've noticed the ladder and I'm very interested in your thoughts on how to attack the new logs as the old system is very static. With extended logging virtually any game could be incorporated into the skill value, not only 5v5 matches.

The objective, as I see it, is developing an easy way for server admins to follow and implement the "altitude" gold standard when it comes to ranking. This way rankings can be easily compared and even joined between servers in a "fair" way.

I'll dive deeper into the ladder thread a.s.a.p.

[phong]

I'm just about finished with PALP (PHP Altitude Log Parser), which I'll be making public here shortly and should give all server admins a mysql backend to build frontends on.

Once my own frontend is completed, Ohjeah! servers will be renamed "Premier" with advanced stat tracking. It's taking me longer to implement since I haven't found anyone to help me with testing.

[StarkJohan]

phong, that is great news. I have no server logs to help you out with testing but I'm looking forward to having a look at your parser. Is it calculating anything or just pushing the data into the db untouched for easier handling?

[phong]

Just to a db, though I'll release a generic front-end for it eventually.

[jetfire]

planepark and the other new maps and server are amazing i love planepark its one of my favorite maps. It must of took of lot of graphics and detail to put in one map. PLANEPARK+AWESOME.

[phong]

I finally got around to testing out some of the custom commands and tbh the fact that you have to type /custom "command" makes them very limited in their usefulness. If custom commands acted like normal commands (IE /startladder vs. /custom startlader) then it would be good. There would just have to be checks in place to ensure custom comands cannot overwrite/conflict with existing commands.

The other issue is with having these commands hard set in the config, making the votepasspercentage difficult to adjust on the fly. If anything it would be more ideal to just pass non-integrated /commands directly to JSON logs to let parsers do all the work, and create a new console command to call votes and return the results.