Spent some time yesterday between errands to take a deeper look at Stopwatch and think I have it all worked out, will be testing the code later today and getting the teething problems worked out.

Also put all the extra logging back in (Item Pickup, healing, etc) for tf2logs.com, got the basics of the plugin manager piece (the Yo, RTV should not be running during a match piece) want to think about that a bit more to make sure it’s the most optimized it can be.

Also troubleshot a couple issues with the idle config to make sure things go as predicted. Once I get closer to release, I will post the actual config the mod is internally running so everyone can have a reference for it. Things are proceeding pretty as it stands right now.

A bit of insomnia gave me a bit of time to look into the scoring mechanics of Attack/Defend  (and Payload by extension) and came up with the following.

The Win_panel will work, but I will need to look for two very specific events..

The winpanel will need for fire with the roundcomplete flag, this signifies that a round is in fact completed. mp_maxrounds governs how many rounds are in play (usually 2 in most competitions)

So tracking that is trivial to be honest, If you see it once, set a flag that you saw it, swap the team names/scores since the teams just switched, second time record the score, done, end of half.

The crux I am thinking about now, is if a league want to have 4 rounds in a row, not split it up at all, how can I in-code support the scenario.

The other option is I want to see if I can detect a multi-stage map since on occasion some league have different rules. Not certain the actual entity I would need to look at to find out since I am not a mapper, but I am going to think about this and see if I can make this work for multiple interpretations easily.

Got to spend a little bit of time with everything this evening. The basic mechanics of CTF/Arena/KOTH/Push are completed and you can play scrims and the scores work just fine and are tracked properly. Much less code now is involved also so this make me quite happy.

Stopwatch/Payload which are effectively the same game mechanic I will look at when I have a bit more time to troubleshoot, and I will need to write another plugin just so I can pull all the fields in the event to see what is what and when. So that may fall back to this weekend.

One mechanic I need to work on is the team swapping, swapping the players is fairly trivial and the code is written, but I want to dig into the Stopwatch game mode a bit more to make sure I have a good way to track the team swaps at the appropriate time (some swaps will happen internal to TF2 and I need to track the scores and when those swap occur. So i am hoping to have a nice simple method that works across all scenarios.

I am on track to have the scoring done this weekend, so I can immeadiately get into actual testing with actual teams and looking at the logs. fingers crossed.

I did get a few more things done this evening, and the beginning of the scoring routines. Specifically the announcer is back. Basically the messages that will tell you who is winning/loosing at the start of the rounds and the time remaining.

I did dig into the actual scoring routines, the skeleton is there, I am internally storing the info, I just need to work out the best possible method to get the score information.

What was happening in the past was each mode had it’s own very specific rules that each did something slightly different. For 5-CP maps, I tracked the end of round events, for Attack/Defend I looked at the Win Panel events, for CTF the flag captured events, arena had its own set. As I was looking onto the anomalies in Attack/Defend I noticed during the 2011 CvP event, it became apparent, this was simply NOT the way to do this. So I have been spending time lately thinking about this issue. How your TF2 client interprets these things is via the events. These events come down the network stream to make your client display the Kill notices, The Win Panel (round MVPs) and the score of the round. My line of thinking along these lines is I should be able to get all I need simply by watching the Win panels only, and going from there. THis will allow me to dramatically streamline the code base.

I will need to spend some time looking at all the game modes with all the event info dumping out to see exactly what is happening.to prove my theory that this will work, but I am fairly confident that it will in fact work out. Plus I will have the added benefit of having things generally in place in case a new game mode gets added or something equally bizarre.

The other major thing about the scoring, a lot of times, when playing two periods, it was easy for teams to forget exactly where they were, how I got around this was tracking the scores internally and using the announcer to tell you the status, this works great int he first half, the second half was a little less awesome. I actually forcefully ended the match via code rather then TF2 cleanly exiting. What I discovered just recently, was I am allowed easily to modify the scores in the game. So i can arbitrarily set the scores. This has the advantage of simply being intuitive and things will simply work as people always expected them to. So here is how things are planned to work as an example:

1. The first half is played, and the score is tracked. mp_winlimit is set to the half-time break score (3 in ESEA rules)
2. Second half mp_winlimit is set to 5, but the team scores are via mod plugged in, so the scores are already up to date and the scoreboard and game mechanics will work based on the actual score. No special code or ugly breaks to get things to work.

I hope to have a Vid of exactly how this works for everyone to see in a week or two. One of my kids has the stomach flu so it’s not easy to spend time in front of the computer so this week is going to be slow, especially if I get the flu also, but we will see.

As far as config files go, I have decided to simply integrate almost everything directly into the MOD itself for the competitive world. So there will be only one config file and just about everything in it will be optional.

As far as supporting a bunch of different leagues and so forth, that will likely be integrated into the plugin for the leagues that people ask for. So how is this going to work at the end of the day?

The most used commands (sm_pug and sm_scrim) will work the same, a scrim allows for overtime to ensure someone wins.

For league matches, I am planning to add new commands, sm_<league>, that will set all the rules appropriately for you just as easily.

The hook to the lobby system will still exist, but I am going to take that and expand it’s options for other lobby type systems to have more control over what is happening. A sm_custommatch command will be created that allows you to define the matchmod options but supply your own config files or use RCON like tf2lobby.com. This way anyone that can build a lobby system can easily get their league matches played accurately and efficiently.

The Whitelists are going to be an exception, since these must be a file on the server as it stands currently, There will be some from the common configurations (ETF2L, ESEA, UGC). The default Pug/Scrim configs will use a base set that can be customized, but will be set to ESEA rules off the bat.

I am hoping to have an early Alpha this weekend, that will allow me to make sure the match flows are in-fact working appropriately, the new map detection schemes and the core logistics of the mod. Once that is set, I will jump back into the scoring and window dressing aspects a bit.

Testing out how the commands will work, still not particularly happy with how things work.. So I suppose I will need to make a decision. I would like to keep things very simply.. in chat !scrim password or !match cevo password and things simply work. Hopefully without the need for the gory details or extra config files and so forth, but I think the command structure is a bit wonky to get things moving properly as it sits now.

For scrims/pugs it quite simple actually, but for matches, it’s a bit more complex. Keeping track which have halfs, which have overtimes and the different rules sets.

I am toying with a few different ideas in my mind

• Keep the lousy shortcut configs (not keen on this at all)
• Add a custom command with a bunch of variables to enter (i.e. sm_match cevo password half overtime ready) whcih seems darn hard to remember
• Another option was to create codes that could be fired like 1101 to say half overtime no ready up stv etc.. but again this doesn’t seem like it will work out
• Build a menu that asks questions and gets input for every single match (have tried this, general reaction was neat but seems wonky.
• The other option is to hard code the various leagues into the mod itself, so you could fire sm_cevo password and things just work.. so instead of an extra config I can keep things in-code which might be easier to some extent.

Been debating this in my head a lot and shifting back and forth between some of the options.. One aspect is to code the entire league configs into the mod directly and have it execute a bunch of commands as opposed to config files. This got suggested but I am really leaning against it.

In other news, the code base is moving to GitHub as opposed to google code, Git just seems easier to work with to be honest.

Updater plugin, the one that relies on SteamTools is not going to be the primary update mechinism. This plugin is very worth it in a lot of different ways.

The TF2Logs.com extended logging is also going to be included, code here is done.

Plugins in general will be handled differently, I am going to hard-code a whitelist of plugins that are safe for a match, the mod will then list all active plugins and unload anything not on the whitelist so there should be no need to modify extra config files to unload plugins. It is in the plan to allow customization of the whitelist, but right now I am looking at:

• admin-flatfile
• adminhelp
• adminmenu
• basebans
• basecommands
• matchmod

I may include Sourcemod Anti-Cheat if it is on the server and configured since it does a good job of cleaning up lobbies and if it’s not installed no huge loss. and sourcebans since it seems common in the wild so to speak.

I am leaving a placeholder for internal stats and a backend database. Have some aspects at the PoC level, but that is as far as I am planning for the next release.