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.

One thing I have formally decided on, with regard to the config files, is the usage of an “Idle.cfg” file for the configs. Idle.cfg is going to be required as part of the league config sets, and is designed to restore the configuration to their default values (of the engine). The League config framework already has this page in and I use it mainly as reference so you can take a look there. How the config sequence will work is this

1. Execute Match config
2. Disable unnecessary plugins
3. Play regulation
4. Execute overtime config
5. Play overtime
6. Execute idle config
7. Reload plugins
8. Execute config stored in serverconfigfile cvar (usually server.cfg)

This will allow us a fairly easy method to move a server in and of the match configs without having to think about to much.

The plugins I will discuss in a further post in the next couple of days.

Since the shortcut files are not likely to exist anymore. I am going to expand the conventions used my the mod a bit to support all the possible game modes.

The following is the config files that MUST exist for Matchmod to properly use the configuration set.

• push.cfg – 5-CP map
• push-overtime.cfg – 5-CP map overtime
• stopwatch.cfg – Attack/Defend map
• stopwatch-overtime.cfg – Attach/Defend map overtime
• ctf.cfg – CTF map
• cft-overtime.cfg – CTF map overtime
• pl.cfg – Payload map
• pl-overtime.cfg – Payload map overtime
• plr.cfg – Payload race map
• plr-overtime.cfg – Payload race map overtime
• koth.cfg – King of the Hill map
• koth-overtime.cfg – King of the Hill map overtime
• arena.cfg – Arena map
• arena-overtime.cfg – Arena map overtime
• tc.cfg – Territory Control map
• tc-overtime.cfg – Territory Control map overtime

Since some of these are new or seldom used (not often do you see a Payload map in competitive settings, let along Territory Control.) the League Config framework will be expanded to have examples of all the possible game modes.

The way the config file management piece is coded, it will need to verify the existence of both the config and overtime config in order to allow the mod to start. I may come back and make it a bit more intelligent later on.

As previously stated, a main goal of this is to simplify things quite a bit. Here are some of the goals I have set for myself.

• If possible, remove the need for the shortcut files
• Less config files necessary

Those alone would makes things quite a bit easier for everyone, but here is how some of this will shake out.

There will be three main commands that allow one to begin the match sequence. Each has a specific function and assumptions along with it.

• sm_pug <password>

Begins a Pick-up game, which will follow these guidelines, No advanced ready up, Single half and no overtime. This will run out of the default config set included with the mod download.

• sm_scrim <password>

Begins a Scrimmage, which will follow these guidelines, No advanced ready up, Single half with overtime. This will run out of the default config set included with the mod download.

• sm_match <password>

Begins a Match, which will follow these guidelines, Advanced ready up, specified periods and overtime, use the specified config file set and specific number of players. A menu will show up to ask the questions to get things rolling without the need to remember a lengthy command line. Examples of simple key bindings will be published so you can quickly get moving.

The entire goal is to now have much in way of configurations ones needs to touch. That being said I am taking a serious look at the server name changing and relying on the game description override to define everything. This was a neat feature but caused some headaches.

Also the default team names will be assumed to be RED and BLU. They will be allowed to be changed via the sm_teamname command by the players. Neat feature but the extra config editing was not really worth it in many peoples eyes.

One of my own biggest gripes about MatchMod was the fact it seemed very daunting to setup and configure. There are a lot of moving parts at play for this mod to do what it was designed to do, and many players on the teams are not server admins so the logic as to why I chose to implement aspects of the mod can be elusive.

Most plugins have very little configuration to get running, drop the .SMX file in and you are good to go. This is a very simple setup.

Other plugins, have a few more files, but it’s simply a load and go scenario (SOAP TF2DM for example) I simply copy some files up and everything just begins to fire.

MatchMod was always interesting in that there were a lot of config files in various places that one might need to look at to ensure things are running properly.

Quit some time ago, when I was building this mod, I wanted to make sure we can support multiple league formats, and all the features. This decision is what added a ton of complexity to the mod. For example:

• Some leagues supported 2 periods
• Some leagues had Overtime periods, some with only 1 periods others with two
• Some leagues allowed matches with a player down as opposed to the full six
• Keeping track of the score in the matches was oddly difficult at times so adding scoring to keep the players informed of where things were at to keep it easy
• Different weapons whitelists and so forth
• Full on ready up

From a coding perspective, these all added a lot I had to worry about, and personally I wanted to keep things simple. This lead to the config files being fired in multiple chunks. For Leage X running a 5-cp map. The mod would run [league]-push.cfg which configures the matchmod variables. Such as how many periods, if an overtime exists, and how many players per team, as well as the actual league configuration files.

This was compounded by the fact that leagues did not really define overtime configs or anything differently. Ughh.. So I was no longer just writing a mod, but re-writing many of the league configs to work.

At this stage, I was looking at the whitelists and how they were actually used for matches. Simple answer was, they really weren’t being used. At the time the whitelist was only processed at map change, and rarely did teams even upload the whitelists even when a league had them. This is where I chose to spend a lot of time to make my life a bit easier.

I released the “League Config Framework” packages. This is simply an excel spreadsheet that can be imported to Google Docs or used on your own machine to see all the CVARs and options, with explanations. I took the configs for a few different leagues (CEVO/ETF2L mainly) and reviewed all the CVARs that they defined, and made a master list of all settings that the leagues would generally hit. Robin Walker and I then swapped a few e-mails for some of the CVARs to see if they were actually relevant to TF2 or if they were here simply because they were relevant in Counter-Strike. Some CVARs were dropped, some were sighted as working but nothing Valve tests anymore (mp_fadetoblack) so it would be best to leave them off and others I just needed a solid idea of what the CVARs really did. Around this time I discussed some scoring possibilities that were discussed by the community and the whitelist implementation. Valve was gracious enough to add a couple key things.

• Whitelists are processed when mp_tournament 1 is fired as opposed to map change. This made it much easier
• Also a CVAR to define what whitelist it should be processing.
• Added CVARs to allow for a “mercy” rule, You need to score at least 2 points ahead (like volleyball). This one to date I don’t know if anyone really has used yet.

This process took a bit of time and the league config framework was released, I was surprised at the amount of people that downloaded the spreadsheet.

To make thing even easier, I made a separate spreadsheet to be the general server config for a match server to use. This, surprisingly, was also downloaded quite a bit.

About this time, most of the features of MatchMod were implemented and it generally was a process of keeping with with the league configs.

Then, for those that know me should come as no surprise, I decided to see how the other game modes might play out competitively. One of the communties I was with was running a 2v2 tournament in the Arena gametype. I got an e-mail that said matchmod did not work with the arena gametype and decided to take a look. As it turned out, the game mode would work fine with the scoring routines and everything else. One just needed a decent config file that was tested. (Allowing players to choose the team, disabling the first blood components and so forth. This is when it got hammered home even more, that if the league configs were not set correctly, the mod takes the blame. So I decided to dig into all the game modes that TF2 has, and get things working.

I went through all the game modes, Arena, Payload, Payload Race, Territory Control, and see how things worked out. I spent some time on CommunityFortress opening up discussion threads that saw a lot of discussions on the rules and formats which helped get a good feel for things. The output here was the League config framework was expanded to include all game modes and the mod was tested with all the modes.

As one can see, MatchMod evolved into a mostly league config creation thing. The most daunting aspects was the pace that Valve was releasing new weapons made the whitelists a lot of grinding to keep updated.

So, I am spending a lot of time while I am re-coding aspects of the mod, trying to come up with an easier way to stay on-top of things, and allow server admins an easier time get things working. Honestly, One aspect I am tossing around is keeping all the configs in a MySQL Database and the mod downloads the settings on the fly. Another aspect I was looking at seriously is scaling things back a bit and take a much more passive approach. Turn MatchMod into a pseudo “PuG” mod. Some aspects can be seen in how I interface with the TF2Lobby.com system where the mod simply provides some scoring code and records the STVs and the lobby system is handling the configs and so forth.

So as I sit here re-coding how do I actually take everything mentioned in this post and turn it into something more usable for the server admins.. Please send feedback on some of your pain points with the mod and I will see what I can work in.

I put my development server back up to begin testing the new code. I have a few modules once troubleshooted I will go ahead and release since they are independent and can be used by any mod to be honest.

• Advanced Ready Up
• SourceTV Recording

Truth be told, these two are very small plugins, the Advanced Ready up offers two natives, one to begin the ready up and one to end the sequence. In the native you can define how many players are required and just wait and see.

At the end of the ready-up, it fires the mp_restartgame to restart the map for all intents and purposes. I believe it will work on CSS/DODS so it might come in useful.

The STV exposes natives to begin and end recording. I pulled this one seperate mainly so I can work on the STV features in a sandbox seperate from the mod so I can work in Uploading the STVs and so forth over time.

I also am digging into the SourceMod APIs a bit more and using some of the newer functions and features to make sure I am not using something slightly more expensive then I really need to.

Expect to see these in few days.