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.

Version 1.1.9 /1.2.0 should see some good features, here is what I am working on

• Added more logging, this time for the item pick-ups, again this to keep the logs relevant to TF2logs.com.
• I have a Proof of Concept code addition that can upload the .DEM files to a given webserver.
• Same PoC also uploads log files to a web server.

I am really leaning to see if I can work something out with Barncow of TF2Logs.com and see if there is an easy method to have your servers synced up to your account and just dump the logs up as you want them.

As far as the Demo’s, I have space here, but am curious how many may actually show up since ~100 downloads of the mod occured, so it’s entirely possible we could see 50-60 STVs a week. If I limit it to Matches only it might work out better, but I will see what the options are.

I haven’t really looked at the config auto-download stuff as of yet, will see what I can get together.

But as it stands right now, I am working to get the code a bit more robust and ready for prime time.

V1.1.6 is in the hopper at the moment, quick preview

Extended logging of all commands
Added a !extend # command to allow you to easily extend the time limit of a round for the fun games
Added !restartround to allow you to restart any given round if something crashes and so forth

I am currently ensuring when !restartround it fired it doesn’t reset the clock back to 30 minutes, after that it’s a bit of regression testing and it is on it’s way out the door. Hopefully sometime this weekend.

The next release is waiting for one more feature I want to stick in if your curious why it is not released.

The majority of the support issues has been around getting all the necessary plugins into the prematch.cfg file. That being said, I am debating ways to handle it. What I am thinking directly, is to have the mod hard coded with a “Whitelist” of approved plugins (warmode.cfg plus matchmod.smx basically) and anything else will be unloaded by the mod automatically. Simply making the prematch.cfg and postmatch.cfg basically irrelevant, plus go further to my goal of have very little configation to utilize the mod.

Once I get a chance to figure out how to enumarate the active plugins, the next version will go out the door. The next version will include 3 packages.

• Mod Only release (similar to all previous releases)
• Windows Server Package (MetaMod/Sourcemod/Matchmod all setup and ready to be uploaded to a windows box)
• Linux Server Package (MetaMod/Sourcemod/Matchmod all setup and ready to be uploaded to a Linux box)

The bottom two are geared to allow server admins to get up and running with a typical match server very quickly.

One of the most intensive aspects of MatchMod is maintaining configs, and ensuring servers have the latest version available. So, initially I am looking at two potential options to handle this.

• MySQL Database designed to store all the league configurations.

The DB connection to the central DB would be hard coded for ease of use of the teams. All the configurations would basically be dropped from the release package. I will need to add the MySQL stuff to a relatively hi-available back end. Might be security issue to be perfectly honest.

• Adding Socket’s as a requirement and utilize a custom service

Basically a custom TCP/IP port opened and the configs downloaded. Main drawback is many people dislike the sockets plugin.

I am leaning toward the DB solution at the moment, but need to find out the security issues with a Read-Only MySQL instance publicly available. or if Sockets is the easiest way to handle the situation. A lot of admins are not fond of the sockets implementation, but for the overall feature set I am looking at, it may prove to be the easiest to implement and maintain.

A few months back I discussed this plugin and the needs of various leagues with a couple of different people. These mainly centered around what would a league realistically need to ensure things can progress smoothly and easily.

Here is the feedback I got:

• We need a method to authenticate the players against the league’s backend. Ensure only players suppose to be there are in fact in there.
• Automating the reporting aspect of the matches.
• Automating the config deployment to ensure each match has the correct config
• Getting some hard log from the server on the match for reference and aid in disputes.

On this same token, the players also had some suggestions that would be beneficial to them:

• Web based statistics from each match
• Automated STV uploads to website
• Scorebots
• Live stats for websites

Now, all of the above sounds awesome and honestly is feasible but here is where things begin to get a bit ugly.

The first major hurdle is many players/teams in the TF2 community are very skeptical of having Sourcemod or other server plugins on the servers. CSS and other games have historically been more plugin/addon friendly to ensure things run smoothly. However, Lange release SOAP TF2DM many people appear to have softened their stance.

I personally believe, if you don’t believe the opposing team will give you a fair fight, get off the server and find another team. The presence or not of a MetaMod, Sourcemod, Mani, Beetles is a simple to justify crutch to the intial question. Do we trust each other to play fair?

So if any solution was presented, we will need a way to ensure both the players and the league that things were on the up and up. One method is to force matches to private servers owned by an entity. This is basically the route ESEA goes by having all matches on its servers with its MetaMod plugins running.  The other way is much more difficult but it would require the plugin is released and trusted by both players and leagues. And have a function built into the plugins that can systematically verify the match environment is up to standard. Whichever method is ultimately chosen really shapes what is possible.

That moves us to the large technical hurdle. What I intended for MatchMod was to enable teams to play matches to league rules with minimal overhead of running a match, in nearly any given league as long as the configuration files can be viewed and the few CVARs MatchMod requires are set properly.

Now, if we introduce many of the features above as an in-plugin feature, we now introduce features that are not globally relevant. In that I mean it would appeal to only a percentage of the user base, and require custom development to get the plug-in to talk with that particular league’s back end to fulfill some of the features. This adds even more complexity if multiple leagues and back ends are need to be supported. As one can see the mod will quickly get very complex very quickly.

So the logical alternative would be to code a single interface to a central back end. The back end can then tie into the leagues and pass information back and forth in a middleware scenario. This basically is a Web Service scenario, which opens quite a bit of doors if one follows this approach. Let’s look at a theoretical process of running a match on the system.

Two teams log into the league website and determine the match time, server information and passwords.  Once determined, this information is push by the league to the MatchMod backend where we store the ServerIP, Time of the match, server password for the match, and details of the two teams involved (TeamIDs and Player IDs of all those on the rosters). The back end stores this information and returns to the league a acknowledgment and a ID to give to the players that could be used if they chose to play the match on the automated system. (The option to manually enter all the data would obviously still exist)

A player on the server executes a command and a given MatchID number.  MatchMod would then query the backend for that MatchID and verify that it is the correct server IP, is within the timeframe of the match (15 mintues before), change the map, and set the server password. Then we could download the team rosters, automatcially set the team names and validate every one that connects is considered part of the match according to the league rosters downloaded into the system.

We can then download the latest configuration files for the league from the central back end to ensure the server is set up properly and ready to go for the match.

MatchMod could then notify the back end of the match status (Pregame has started for Red vs Blu etc). We will then authenticate every steam ID in the server, as well as anyone connecting if they are legitimately part of the match, otherwise kick and ban to clear them off the server.

The match would progress normally in MatchMod at this point. teams would play the game, scores would be pushed out to the MatchMod back end for live stats and scores. Upon completion of the match, it would contact the back end and upload the raw server log of the match that the mod makes. A list of all SteamIDs in the server, and a list of any active plugins on the server at the time of the match. And possibly upload the SourceTV recording to the backend.

The backend at this point would push the data back into the leagues system to  report the match and record the records on the servers. As time goes on we could push statistics back to the league backends also, or even the STV demos if they so desire as the solution matures.

This keeps the mod itself as small and universal as possible, while allowing the leagues and myself to have much smaller things to develop to integrate them into the system.

What we can then begin to do, is develop match histories for teams, STV libraries and so forth that teams can link to on their websites to automate a lot of processes for themselves. Leagues can get timely reports in directly from the servers, and players would have very little to do other then schedule and play their matches.

For Scimmages, players could simply say what league config they want to use, the servers would only record who played, logs and STV upload and store the results.

Pick-up Games would generally be left as they are currently, I would really recommend these go through tf2lobby.com for the very nice stats package Floor master has running. Hopefully we can find a way to tie things in with them down the road a bit more.

There is a LOT involved in accomplishing above, the first step is to determine the best formats to store the data, get things running and tested. Once we have a solution, begin to work with a league to test out the feasibility of such a scenario.

if you have any ideas or feedback on this, please comment, I would love to get as much feedback as I can before I get these things setup. The roadmap I maintain for the mid says most of the backend is supposed to be completed for the 1.2.0 release, but I don’t yet have a timetable for it.

What do you all think?