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.

Originally, I was very much against this, but over the past couple of years, I think this may in fact be a better approach long term.

MatchMod is going to be split into a couple of different plugins when the function may make sense to have external as it may benefit other plugins. As a quick example.

The Advanced Ready up function of MatchMod, I am going to port externally to it’s own plugin and expose Natives to other plugins to call to initiate a ready up and define the rules of how it is going to handle things easily.

Other aspects I am planning to separate is the STV Recording features, scoring routines and announcer, and possibly the config file/map detection routines.

I have not completely decided what aspects will be separated out which ones are integrated in, but the core plugin will simply process a match from first half, to second half, to overtime and close itself out.

I have decided to hold off on a release until version 2.00, there are a couple things going on here that relate to this decision. I wanted to address this before the next release.

Code clean-up, The code base is a bit of a mess at the moment, I was not consistent in how I address variables, the structure of the code doesn’t really lend it self to easy edits and difficulty in tracking exactly where a particular feature showed up especially in the scoring routines.

I also have been asked recently about a few different scoring options people want to try that really are not possible as the code-base sits right now.

Lastly, I wanted to add features in for the backend piece, allowing teams to register on sites and reserve servers and select their sides and so forth. Since I did not want to run the backend, this feature will likely be based of a fairly portable service that can be quickly adapted to other features.

Also, I did want to add stat tracking to the mix internally as well as maintain the lengthy log the mod currently uses. Again, allowing live-stats to a website relatively quickly. We’ll see how this aspect goes.

I also always wanted to look at Berni’s map detection routine a bit more and see if there were better ways to detect. Right now it mainly uses the map’s file name, a few maps out there don’t use the proper prefixes and so forth, so I am toying with the idea of expanding this to use maps internal entities that TF2 is using to determine the rules at play. Not sure if this is realistic, but we will see.

Branding is something I have been wanting to do for a while, as opposed to everything saying [MatchMod] I wanted to give the ability to modify that particular string.

Lastly, I have been asked to port the mod to other games, not certain if I am going to do those aspects, but want the code base to have the option.

That’s the current status. If you have any suggestions, please let me know.