phogue / potato

Procon 2 is a (long promised and often postponed) second release of the Procon admin tool for gameservers. Once released, it will allow managing several games and automating tasks via plugins.

Potato

Potato is developed by Geoff Green.

About Potato

Potato is a free remote control (RCON) tool for gameservers, currently supporting Battlefield: Bad Company 2, Battlefield 3, Medal of Honor: Warfighter and Battlefield 4. It is developed by Geoff Green and also available as open source software on GitHub.

In addition to providing basic features to control your gameserver, users can extend Potato's functionality using plugins, which can control Potato's behavior and add additional possibilities for gameserver admins. Furthermore, Potato provides a layer system, which allows running plugins and managing admin accounts in a central location instead of distributing it to every admin connected to the gameserver.

Credits & contributions

Potato is developed by Geoff Green.

The Battlefield franchise is a product of DICE.

Plugins for Potato are developed by third parties, credits and responsibilities lie with the respective plugin author.

potato's Issues

Complete game config (BF4)

The BF4 config requires completion with all current maps and game modes.

src/Procon.Net.Protocols.Frostbite/Configs/Games/Myrcon/BF_4.xml

Convert configs/localization to JSON

We currently use XML for configs and support XML and JSON for commands going back and forth over the command server. Every serialization issue so far has been with XML.

If we are to support XML it would require lots of messy tags through out the models. This has already occurred in some models, but when dealing with serialization of interfaces it would mean I would now need to all but implement the serialization myself.

The easier option is to ditch XML and just support JSON. This would mean one serialization type to test, it would be my preferred transport type and a pretty killer library that will handle the serialization for us.

The events disk logging, while optional, is also done in XML. Using JSON will cut a small test section I did by two thirds.

We can use the newtonsoft json library to convert the existing xml config files for BF4 to JSON.

Packages should not load in full trust

Protocol assemblies are currently loaded in Procon's instance AppDomain which runs in full trust.

This should be modified to load these assemblies in an AppDomain which only has access to protocol package path and UDP/TCP network access on the port to the game hostname. This will mean adding a new connection will require all existing connections to restart, but the security is worth the inconvenience.

It's a slightly increased level of trust from a plugin, but only because it needs to do more. It's not exactly a plugin, which is why it's handled elsewhere.

Plugin requires information about the game running

A plugin requires information about the current game running and what actions/events will come from the game connection.

Database: Migration Controller

Migrations simply require a migration model which has a series of queries to issue to the database layer. It's almost just an automated procedure that plugin developers could do themselves, but we will include the helper and format for migration handling.

Standardize NetworkAction objects

Procon.Net.Protocols.Objects.Chat already uses the Then/Now/Scope attributes of NetworkAction but Procon.Net.Protocols.Objects.Kill still uses a very specialized object.

Moving Kick/Kill and other NetworkAction objects over to use these three NetworkActionData fields (or creating new fields like "Instigator" and some clever antonym of instigator that I can't think of right now) will allow for multiple actions to be taken on a single object, so a plugin can list 5 players they want to Move/Kick/Kill and the appropriate action will be taken.

The work's already half done, I've just been lazy.

Daemon should require https

The daemon as it is accepts open http connections for commands, but since passwords are exchanged for adding new game server connections or other accounts this should be changed to only accept https connections.

The daemon should generate self signed certificates for users to then upload to the UI so Procon then requires a specific certificate to be used when accepting connections for commands.

Database handling internal to Procon

Database connections and querying should be completely handled by Procon, removing control from plugins to establish and directly query a database. This should ease user setup and tighten the sandbox on plugin actions.

Benefits

• User sets up a database connection once, plugins then just "use a database".
• We can develop a little bit of abstraction so a plugin does not need to know what database is being used for very simple storage (key-value-pair type storage)
• No duplication of connections to a single database
• No permissions issues by hosts on plugin sandboxes
• Simple migration handling can be written for plugins to use
• Plugins can have tables as "Global", "Plugin Specific" and "Connection+Plugin Specific".
• Database is accessed in in a unified way, potentially allowing plugins to share collected data.

Requirements

• No external libraries like NHibernate or other bloatware.
• No ORM. Everything must be remoted as a simple query string from sandbox to procon, so Procon can never accept objects that are not defined in Procon.Core.
• Don't define objects in Procon.Core specifically for ORM in tables.
• No ORM.
• Simple abstraction via CodeIgniter style active records (they renamed it I think). It's not active record at all really, it's simply a query builder that is passed in to different drivers to build a query string.

var sqlQuery = new SqlQuery()->Select("something")->From("somewhere")->OrderBy("column");

var serializer = new MysqlSerializer();

var text = sqlQuery->ToString(serializer);
// Select `something` FROM `somewhere` ORDER BY `column`;

CommandResult result = this.ProxyCommand(..., text);

result.Rows... // or something like this.

• Must support NoSQL and SQL
• Must not be so crazy that it never happens.

Notes

• Anything beyond simple storage will require the plugin to write specific plugins for their target database. The chances are pretty good people will only use MySQL anyway.

Three people have tried to implement something like this in Procon. Some import every library written in .NET to get something sort of working. Others are very specific on MySQL functionality. Keep. It. Simple.

Network Actions should function like Core Commands

It's a relic from the start of the project where actions would have their own object, but a network action object still has a "NetworkActionType" to specialize the action. It makes little sense now to have this double up of methods to dispatch actions within Procon.Net

NetworkActions should remain in place of Commands, as they should really be renamed to "Intents" since they may fail from the protocol not support an action, but it's all asynchronous so you don't get immediate feedback.

Anyway, NetworkActions should remain but the individual objects "Ban", "Move", "Raw" should just be combined into the single (currently abstract) class "NetworkAction" and the only way of dispatching done by looking at the NetworkActionType.

If this is done then Core can then dispatch the command using the name within NetworkActionType and permissions can therefore be setup on each NetworkActionType, allowing for greater fine tuning of permission sets.

Procon.Net.Protocols.Frostbite can be merged with Procon.Net

Since the protocol is maintained by us this project can be merged back into Procon.Net. We still require the functionality for loading external protocol dll's so others can implement their own support for protocols, but it feels messy splitting up Myrcon provided protocols into their own dll's.

We should then create a test Procon.Net.Protocols.ThirdParty, if anything just to show others they can include their own protocol support and how it can be done.

Procon.Net.Protocols.ThirdParty should exist in its own repository.

Complete game config (BF3)

The BF3 config requires completion with all current maps and game modes.

src/Procon.Net.Protocols.Frostbite/Configs/Games/Myrcon/BF_3.xml

Rename frostbite dll to include provider

Since multiple implementations of the same game protocol can exists the frostbite project and namespace should include Myrcon.

Procon.Net.Protocols.Myrcon.Frostbite make more sense, so some one else can implement/release their own version of the frostbite protocol and simple file/namespace naming won't conflict.

TextCommand: Support for players on a team

Support and tests for "Players on US team", "Players on the Russian side" that avoid conflicts with the country name "Players from Russia".

Include support for "Players on the other team"

Service checking for updates twice on restart

Restarting the procon service is checking for core updates twice.

Rewrite Procon.Core.Repositories

The code is a little smelly and should be rewritten completely. This may involve side-by-side development of a new repository software since the other was only supposed to be temporary as well.

The rewrite should be done in a way that can be mocked and tested, instead of the current methodology that required integration testing only.

Change Test Framework

The current build server on http://teamcity.codebetter.com does not support MSTest. There is no build agent having the assemblies installed.

NUnit-Runner is installed and can be used.

Include Guest group as a default pool for players

Include a guest group, that cannot be deleted or have accounts added to it, but can be used to specify permissions a public user has.

Include simple security commands to setup initial accounts/groups/permissions

Given the changes Procon has gone through over the years, instead of relying on hosts to update configs and what not we should make Procon simply define what is required to Stream and be an Administrator.

This way security groups are created, defined and permissions set by the release of Procon being executed instead of relying on outside scripts to define these two common setups.

User initial setup GUI

A GUI should be built named Procon.Tools.Setup.exe as a simple GUI to help the user build the streaming account required for the UI, generate a self signed certificate and potentially setup a community on the UI for the user.

Steps

• Localization. This should be the first question asked and then set as the default language in their procon install.
• Streaming user group, account and permissions if not already setup. If setup then a "create new password" option should be given.
• Administrator user group, account and permissions if not already setup. If setup then a "create new password" option should be given.
• Daemon setup, including port selection
• Certificate generation

Requirements

• The user must choose a username for their Administrator account. No default username should be used.
• The streaming account username & password should be randomized. The user never needs to login to this, but the details need to be supplied to the UI so it can connect.
• The tool must accept simple but extendible command line arguments to complete all actions the UI can, allowing hosts to issue commands to do the initial setup
• All details must be supplied to the user in a way they can copy + paste them easily to the UI
• The user must be presented a wizard style setup, but be able to go to a single step if they want to edit only a single option.
• All steps must function independently of each other.

Details required by the UI

• External hostname
• Daemon port
• Stream Username
• Stream Password
• Generated self signed certificate

Correct output paths of all projects

Some of the projects build in the source folder, others to the /builds/ directory. Some of the later examples and unit tests have not had the output folder set to the builds directory

Investigate move from Remoting to WCF

As title says. We have a working model right now, but as Remoting is listed as obsolete then we should look at modifying Procon to use WCF.

Network: Config for describing teams and squads

Include support much like map pool and game mode but for describing teams and squads.

Like the grouping on a player, this support must allow for arbitrary grouping of players.

Re-implement Source + CallOfDuty

The files were removed from the project for the time being so I could focus on Procon.Net.* without having to maintain these older projects. It's unknown if they still function, but since I can't jump in a server to find out if even basic connections occur they have been removed until further notice.

This is an issue reminding me, once all the refactoring + testing is completed on Procon.Net.* and Procon.Net.Protocols.Frostbite.* to complete the basics for Source + CallOfDuty games again.

Ensure Myrcon.* packages originate from official source

We can't do much about the id's of packages clashing when people have multiple repositories as source, but we can at least prevent people spoofing Myrcon package id's.

We should validate Myrcon.* packages originating from the set default feed and ignore any packages from other sources that begin with Myrcon.*

Since procon looks for Myrcon.Procon.Core to load up it will at least prevent a package being spoofed, the user adding the repository with it and then Procon updating with the new package, restarting and loading a dll in full trust from an untrusted source.

Move SQLite.Interop.dll with build event

I included SQLite.Interop.dll into the project as a temporary measure a few days ago. This file should instead be moved via a build event command, just to keep the project clean.

Expose interfaces in more locations through out Procon.Core/Net

Unit testing at the moment is a little difficult as concrete types are used everywhere. This was done because of serialization issues with xml, but now #39 has been completed we can replace some of the concrete types with interfaces.

Simple configuration via command line arguments

Procon already supports commands and a simple extension of this is command line arguments. An executable can be created for the initial install of Procon to simply execute commands with a local users permission in Procon.

Procon.Config.exe --Command "CommandServerCreateCertificate" --password "pass1"
Procon.Config.exe --Command "VariablesSetA" "VariableName" "VariableValue"

Essentially any simple commands that require arguments of Strings or Integers (a majority of the commands) can easily be dispatched with multiple calls to the config executable.

The executable loads up the Procon Instance, issues the command, saves the config and disposes the service. This process can run on initial installs or later down the track to configure other options.

We can, in the future, add commands or alterations to commands within Procon and the Procon.Config.exe will not require changing.

Clean up test projects

Tests and Implementation have to be split up a bit, because the tests test too much stuff in one test method.

The test projects also contain several types of test scenarios:

• simple unit tests
• extended integration tests
• testing the available infrastructure (filesystem)

These types have to be seperated and for detailed unit tests the infrastructure has to be mocked away, so that the implemented functionality can be tested, and not the working infrastructure on the system the tests are executed on.

Allow plugins to publish generic events

At the moment events are one way across the appdomain, from Procon to the plugin. Plugins should also be able to publish events.

The event model itself may need to be changed to show the origin of the event.

Configs should write out to temporary file

Configs should first write to a temp file, then delete the original config file and rename the temp file. This adds a buffer between losing config settings from locked config files.

The config should have "tmp.1" with the numbers incrementing on failure, but if the original config was successful then all .tmp.* files should be removed.

Before loading a config, the highest tmp.* file name should replace the original file name

Database: Include support for SQLite

The tests for SQLite are mostly included now, but the Serializer and Driver need to be implemented.

While we're at it, the SQLite tests also need renaming (It has two L's at the moment)

Sign all Procon.* assemblies (Strong Name)

I've again run into a security problem that could be easily handled if we could supply the StrongName to the AppDomain creation as a full trust library.

I've googled the argument a number of times, especially storing the the self signed private key in the public repository.

I think not providing the source code in full wouldn't be helpful for plugin developers and others that want to contribute to the project.

We may look at supplying a self-signed certificate in the source, just so the repository can be cloned and compiled with minimal effort, but then use a private key supplied from DigiCert to code sign releases.

Command.ToConfigCommand nulling scope

When saving the config the plugins that are enabled are not being reenabled on load. This is because ToConfigCommand nulls out the scope.

Need a couple unit tests to validate the config can be saved/loaded for the plugin controller correctly.

Investigate why ToConfigCommand is nulling out the scope. I think it's just to make config's look prettier so the scope is not filled with lot's of empty GUID's for no reason.

Perhaps change over so if all GUID's in scope are empty then the scope can be nulled, otherwise the command requires it's scope.

Users should not be able to lock themselves out of the system

It's currently possible for a user to remove their own account, remove their group or set their permissions to a level they cannot recover from.

A user should not be able to do the following:

• Remove their own account.
• Remove their group.
• Set their group's permission to modify group permissions to 0 or undefined.

Remove obsolete Procon.Net.Utils.Http.Request

It's a helper class that's been with Procon since the beginning, but now we're out of .NET 2.0 it's just a bloated mess of a class.

At the moment it is being used in some unit tests and Procon.Core.Repositories.

Procon.Net.Game config handling is clumsy

Protocol game configs should be rethought, avoiding the current entanglement issues. We should also standardize the configs and use existing XML serialization techniques.

A Game should still be able to decide when it's config should be loaded, as is the case with BFBC2: Vietnam that required a connection and a result from the version command before it knew to load a different config from the standard BFBC2, that is to say the Game should still be able to support mods.

The goal of this task will be to clean up Game and GameImplementation objects from some rather strange serialization and events firing through others very simple code.

Add localisation for new vehicle kill codes in BF4

Procon 2 should also be updated with the new vehicle RCON codes and DLC weapons, as well as default localisation.

Network: complete bf4 team & squad name config

Include a config with the default team names and squad names.

Procon.Tools.Repository requires a makeover

Procon.Tools.Repository was hacked together for testing purposes only. This tool requires a better GUI with additional errors reported.

It does not need to be anything snazzy, but it does need to be functional.

It would also be neat if it accepted command line arguments so plugin developers can automate publishing their plugins.

Replace obsolete "Additional" within IProtocol

This property was made to store extra information a protocol may require but was a simple string because of limitations on the command parameter at the time of writing.

We now have a way of accepting generic params within a parameter, so this generic string value and processing within Procon.Net.Protocol can be removed.

Database: Unit test database controller

This issue relies on SQLite support to be completed, therefore small databases can be made/deleted for unit testing easily.

CommandServer: Refactor

Clean up the code and tests for the command server. The command server at the moment only has integration tests which is difficult to identify problems running the tests on other computers.

The CommandServerController should be refactored so it can be unit tested.

Add exception logging

Much like Procon 1's implementation, but hopefully more stable. Unhandled exceptions should be minimal in Procon 2 due to limited try-catch usage, most have shown during it's long development.

Still, if an error occurs that isn't handled by the Procon 2 instance appdomain it should be logged by the service.

TextCommand: Simple alternative to fuzzy parsing

The fuzzy parser, while neat, might fail brilliantly for some users or some situations where a command requires a few parameters.

It's always been in the plan to include a simplified parser that works much like a router. The syntax for command definition will look something like:

kick :player
move :player :team
kick :player :text
ban :player :number

Available parameters:
:player
:team
:text
:number
:country
:weapon

The results of which comes through just like the fuzzy results.

Ignore GamePlayerlistUpdated and GameSettingsUpdated logging

The logs files are currently filled with GameSettingsUpdated and GamePlayerlistUpdated events. These events occur at regular intervals and shouldn't be logged to file, just so relevant information can be read in these log files instead.

Database: Write example & tests for Plugin support

Once SQLite support is included & tested an example plugin can be made to show developers how to interact with a database from a plugin.

Add readme

Include project summary, contact details (twitter/webpage/facebook etc) and other various bits of information

Accounts should be able to set their own language

Accounts at the moment require permission to change their preferred language, but permission should be ignored when an authenticated account is setting their own accounts language.

Switching to current .NET Framework

Ever thought about moving to the current framework 4.5.1 or perhaps 4.5 to have a better async support?

Examples: Include logging example and tests

Include example on using log files and the plugins own logging directory.