SITREP #00009

reported by Joris-Jan van 't Land on April 30, 2013

FROM: Project Lead
TO: Alpha Users
INFO: MP security, Dedicated Server files, audio and lighting tweaks


For most of our Alpha testers, last week has mostly been about the multiplayer service being interrupted by servers manipulated with scripting exploits. The situation was worse than single servers being hacked, since it easily spread to clients, who would then also bring it to the next server they connected to. In the Operations section I've detailed some of the steps we've taken so far, and those we'll take from now on to improve the situation. A lot can be said about the root of the problem we're facing here - perhaps a good topic for a blog at some point. It boils down to the concepts of freedom and security and how badly they often mix.

We pride ourselves on the open platform that Arma games are built on. Unfortunately this extremely flexible platform can both be used for creative modding and malicious purposes like MP griefing. Most solutions for improved security mean taking away freedom and putting restrictions in place (there are obviously many real world comparisons to draw here). For a very practical example of this you can see the response to deliberately removing three scripting commands: improved security, but broken community content.

I do not believe for a moment we can have both freedom and fully secure MP without serious restrictions. The only seemingly valid method would be an approach taken by the DayZ project via its MMO architecture. Keep in mind this concept does not gel with Arma 3 as it was designed - it means all client actions are validated on a server, and this makes client-side modding and scripting much more difficult. Acceptable for DayZ, not for Arma 3. We will however do our best to improve security, reduce vulnerabilities and walk the fine line between freedom and security based on your feedback.


A more extensive description of lighting tweaks was posted via lighting expert Pavel Guglava. It also serves as a feedback thread for the team. Data configuration is still rolling out in steps, but a large portion is available on Development branch now.

The Community Focus widget now has an archive (linked via the widget header), so you can see which community projects were put in the spotlights so far.

To repeat a point made previously: it is futile to argue we should not be working on e.g. lighting tweaks while security is compromised. Different people, different specialties, different roles. Even within the programming department it is simply not as easy as reassigning someone from rendering to netcode. That's not how it works and it never will.


We have deployed into Development branch a first set of measures to make this simplest form of security breach harder. Compiling scripted functions as 'final' is generally beneficial. Custom function designers will be able to re-compile for debugging using a description.ext parameter. The removal of certain script commands was deliberately done without transitional deprecation systems, to gauge effectively how widespread their use is. These specific commands were originally introduced to support never-supported functionality. We are looking into further methods of dealing with these and similarly vulnerable commands (also taking into account interesting proposals posted on the forums). One part of this is to better document alternative approaches to scripting methods. This has started on a page about the Functions Library.

It is planned to update the default branch with the current hotfix this week (target: Thursday). It should: reduce the ease with which this exploit spreads through all servers and it should stop this most simplest form of scripted exploit. It will definitely not: stop all hacks in Alpha MP.

Dedicated (third-party) anti-cheat solutions have not yet been added during the Alpha for which we have our reasons. As soon as we can, we will start rolling these out. This should help with some of the more advanced hacks.


Today we'll publish to Development branch, but then we will halt updates for two days. Publication should continue this Friday. The reason? We are making significant and extensive changes to the way audio and volume balancing are handled. These changes affect all assets with sound, and we want to make sure it all gets published in one go. There will also be a detailed description of the changes and what to test afterwards.

The Development branch now contains the Dedicated Server binary and required files. It can be run without needing to run a Steam Client, but has a significant known limitation at the moment: it is able to run one instance per machine. The data organization may change later once we go for a separate package.