Feature #9436

Implement Basic I/O so ArmA can talk to other applications

Added by oktane over 5 years ago. Updated about 2 years ago.

Status:Duplicate Start date:03/05/2010
Priority:Normal Due date:
Assignee:Dwarden % Done:


Target version:-
Affected ArmA II version:Please select... First affected ArmA II version:
Reproduced by another DH user:No Single / Multi Player?:
I am using some Mods:No BIForumURL:
I am using: NGUrl:
Reproducible for you:No WIKIurl:
Related to content of DLC:


This feature is a core concept in the 'OFP/ArmA/ArmA2 as a platform' which I think BIS is starting to realize over time. The idea is to sell a very flexible combat simulation 'engine' for gaming. Perhaps this wasn't their original intention with OFP, but with so many 'open' features added to the engine over the last 10 years, as well as the brilliant work of the community extending it, I think it has evolved into this.

That said, an important feature missing is:

Simple data input/output from external applications

Currently we have the clipboard, which we could treat as a single 'string' variable which can be read and written to from a 3rd party app. We also have the 'diag_log' but it is output only.

The clipboard has the following limitations:
  • It is extremely cumbersome to use as an inter-process communication device, it wasn't designed for it.. it's like using a banana as a screwdriver.
  • If it is used, the clipboard cannot be used anymore.
  • It has a limited size.
  • It is limited to strings. So any data that is non-string must be encoded some way.
  • It has to be polled in the game, lacking event system
We can hook the game to do anything we want, via injection or other similar means, but there are even worse limitations:
  • There are very few ArmA community people who have the skill to write code to do this. (I can think of 2, both of which are MIA)
  • Malicious/cheat apps use techniques like this
  • BattleEye will not allow it due to memory modification..
  • Hook has to be updated every single patch/beta because of the new arma.exe
  • The act of doing this is frowned upon by devs and others. May be violation of EULA too, due to reverse engineering.

The only solution is IPC. (Inter-Process Communication)

Ideally we need a simple IO system which has some of the following ideas embraced:
  1. External read/write access to variables
  2. Just a few 'known' variables would be enough (ipc1, ipc2, ipc3..), we don't need access to every variable in use at runtime.. nor would we want that, as it could be exploited easily by cheaters.
  3. Variables would support of all ingame data types, where feasible. (example, objects may not work.. prehaps they would be sent as a binary stream?)
  4. As for the actual transport, an ideal one is probably Named Pipes, but there are others http://msdn.microsoft.com/en-us/library/aa365574%28VS.85%29.aspx
  5. At minimum, a way to see if the IPC is connected. (bool)
  6. Optional, but important: A simple event system to run compiled sqf when IPC is connected, disconnected, data is received, etc. Similar to an onPlayerConnected type of event.
  7. Optional, but important: Ability to retrieve simple text from a web site host. (HTTP GET) Imagine if we had this, missions could always use the latest versions of script libraries, etc. Retrieve dynamic info, etc. Should be trivial to reuse the squad xml HTTP GET code.
  8. Optional: Assuming Named Pipes, allow addon dev to specify CreateNamedPipe parameters such as pipe name, accept network clients yes/no, anything relevant. http://msdn.microsoft.com/en-us/library/aa365150%28VS.85%29.aspx

In the past, others have hacked this into the game (Keg's ArmALib, Nutty's DSTS) but as explained before: This hooking is not an ideal or sustainable solution, and it relies on a 3rd party.

BIS, If you do this, the community can do the rest... extending the game even farther. We are living in a world connected more and more every day, but our favorite video game is still on an island by itself, unable to talk with other applications.

If you are asking yourself 'What's the point of implementing this??', then you have vastly underestimated the creative genius of the community which supports you... The applications are nearly endless.

Thank you for reading and voting.

Related issues

related to ARMA2 Community Issue Tracker - Feature #11743: Simple UDP Communication - sendUDPMessage Assigned 07/07/2010
related to ARMA2 Community Issue Tracker - Feature #17496: Provide a simple interface to support community addon dow... Assigned 02/09/2011
related to ARMA2 Community Issue Tracker - Feature #28539: Official support for Mumble's LINK - open plugin interfac... Assigned 02/09/2012
related to ARMA2 Community Issue Tracker - Feature #11201: Dedicated Server SDK Expired 06/13/2010
related to ARMA2 Community Issue Tracker - Bug #11701: sendUDPMessage function doesn't work Assigned 07/05/2010 12/01/2010
related to ARMA2 Community Issue Tracker - Feature #25915: Official support for 3rd party plugins (dll's) In progress 10/27/2011
related to ARMA2 Community Issue Tracker - Feature #5892: Implement faceAPI Assigned 11/16/2009


Updated by oktane over 5 years ago

Example C++ code: http://msdn.microsoft.com/en-us/library/aa365588%28VS.85%29.aspx

Example BIS-Script pseudo code:

// Note this is just a basic example.. a better programmer could stomp all over this.

// CreateNamedPipe script command (String Pipe Name, Bool RemoteAllowed), returns code from C++ command (ok, fail, busy)
_ret_code = ipc1 CreateNamedPipe("tube", false);
if (_ret_code == INVALID_HANDLE_VALUE) then {
    player globalchat "Failed to create pipe.";
    exitWith {false};

// event for data incoming, vars _name and _data are set
ipc1 onDataRecieved = "player globalchat format['Incoming data from pipe name: %1 Data: %2', _name, _data];" 

// isConnected returns true if the pipe is okay and a client is connected
isConnected = {
    _ipc = this;
    _connected = false;
    // ConnectNamedPipe attempts to connect..
    _ret = _ipc ConnectNamedPipe;
    if (_ret == PIPE_CONNECTED) then {_connected = true;}

// we would wait here, and external app would attempt to connect.. if none after some 'timeout', then fail?
// external app would connect to \\.\pipe\tube, or if over lan \\computername\pipe\tube

if (ipc1 isConnected) then {
    player globalchat "Pipe Connected!";
    // now send some data to the pipe,
    _test = 123;
    _ret = ipc1 sendIPCData _test;
    if (_ret) then {
        player globalchat "Sent data to pipe!";
    } else {
        player globalchat "Failed sending data.";
} else {
    player globalchat "Failed to establish pipe";

Updated by Sickboy over 5 years ago

I would love it too, however, maybe they need to consider VBS? If you can do all the pro stuff in ArmA, who buys VBS?
The ClipBoard link is a cheap way of doing it in ArmA 2, but i'll admit, aint a real solution either.

Updated by oktane over 5 years ago

Sickboy wrote:

I would love it too, however, maybe they need to consider VBS? If you can do all the pro stuff in ArmA, who buys VBS?

This isn't all the VBS stuff, its a single thing that a lot of popular games support these days. It can be done with the clipboard, but its a royal pain in the ass and not reliable. Who buys VBS? Military people. You think they are going to cheap out and use a 'game' version of their simulator? I highly doubt it. Arma isn't even close to VBS in the added functionality it provides, and besides the military likes to spend money. One is a game for us, the other is not a game and has many non-game features they need. Also consider BIA provides support to VBS customers, BIA/BIS aren't going to provide anything to a military saying 'Uh we don't know how to set up your ArmA2 game to train our soldiers on, can you help?'.

The VBS point is totally moot imo, and only serves as a thinly veiled excuse for them - not to implement it.

Updated by kju over 5 years ago

  • Category set to API
  • Status changed from New to Assigned

Updated by Nou over 5 years ago

I agree this would be awesome, but the VBS2 thing is the main concern I believe.

Oktane, its not that a lot of games use it or not, but that BIS and BIA can artificially limit it to create a higher price point for a more premium product.

Updated by oktane over 5 years ago

Comon already with the VBS riff.. VBS is not ArmA2. Companies that buy VBS do not buy ARMA2. When big companies buy expensive software like that, they also buy support. BIS is not going to support an enterprise/military using Arma2. It's a non issue, please stop bringing it up. It's like you guys want to protect BIS from a totally unsubstantiated what-if. (as in 'what if a big company buys A2 instead of VBS for training, they would lose money') It's up BIS if they view it as a threat.

There is a very large misconception in the community that VBS is almost identical to ArmA2, when it is not other than cosmetics. It comes from the same code base/engine but the two products serve completely different purposes. The two are not even developed in the same country. They are forks, with occasional code merges when applicable, but they are separately developed. The features are not artificially nerfed in Arma, and they are priced according to what they were designed to do. (IE, their purpose)

Look at it this way, BIS provided us with a 3d editor in A2. VBS also has a 3d editor. It's irrelevant. Some features overlap but the target audiences are entirely different and other features reflect that. Would you guys say that BIS shouldn't have included the 3d editor, because it might affect their VBS sales? They didn't seem to think so.

Updated by mr.g-c over 5 years ago

Furthermore, it is forbidden to use Arma2 for Military Training by its TOS, so professional customers have no other choice than to use VBS2 for professional training anyway. Not to speak about the tons of other features Arma2 will never have, which are essential for proper military training.
So this discussion about this proposed feature and VBS is pointless IMHO :-)

Updated by Mikhail over 5 years ago

This feature is the most awaited thing for Arma2... We could handle almost everything with armalib in Arma1. But since it's gone and BattleEye is limiting other injections, such kind of official implementation would be fantastic boost to Arma2 modding development (although it's already the highest like in no other modding community)

Updated by mr.g-c over 5 years ago

I think a related Post by Ohara (BI-Dev) appeared in BI-Forums (link: http://forums.bistudio.com/showpost.php?p=1579085&postcount=110):

With DLL aded to engine, this is there in VBS long time. Its design decision to not add it into game version of RV, same as restricted functions for disk & file operations.

Updated by oktane over 5 years ago

That thread is a typical disappointment. It is a request for a bunch of totally far fetched features and dependencies for those features. Those people are better off writing their own milsim with all the features they want. They can spend 10 years arguing about what core scripting engine to use before it can even draw a triangle. I think that thread serves better as amusement for BIS developers or developers in general, along with the requests to add melee weapons, bayonets, etc. :)

I think what happens a lot on the forums is someone requests something, and a bunch of me-too's come in and tack their shit on it. This is one of the reasons I didn't even make a thread about it.

On the other hand, our request here is a simple and straightforward, for BIS to take a moment and think about external IO. It doesn't have the extra baggage or religion.

This feature request is intended to be a professional discussion from the developer side of things. End users won't even see this feature. They will get a 3rd party developers Teamspeak addon or whatever, and use that. Or the feature will be used on a dedicated server and would be totally transparent to the end user. All support using this IO feature is handled via that 3rd party addon/utility/mission developer, not BIS.

If they pull the VBS card, it isn't like we didn't see it coming. (Or give and reinforce that excuse, much to my amazement here.) I think perhaps it's the only answer that people believe. I don't buy that it's a (game) 'design decision' though. Sure, the game audience wants some of the features from VBS but not the other way around, and the Professional audience is still not going to use the 'game' for their purpose, they will always use the Professional version. Does a design house use The Gimp/Paint.Net/MSPaint instead of paying for Adobe Photoshop?

Similarly, almost all of the gamers that play ArmA would never buy VBS, no matter if you can shoot golden unicorns out of 6 different types of LAV's. It's just TOO expensive for a game. (And it isn't a game really.) Therefore, they aren't losing money. And they don't have to make it compatible at all with anything VBS wise, thereby making the wall between the two skus even higher.

Updated by kju over 5 years ago

This is one reason for the CIT. To get a more decent level of discussion and suggestions.

Like every decent person, BI is probably also able to review their standpoint based on good arguments.

Updated by mr.g-c over 5 years ago

I have also spoken with Ohara about that issue over PM, and well yes it was a design decision to not add it to Arma2 because of, like he expressed it, "monetary policy", in others words "VBS2". He said however that they are working on a more simplified Version for Arrowhead for a special/internal purpose i didn't understood, but he is not sure whether this will be/stay in the Final Game at all.

Please BIS let it stay.... cry

Updated by CarlGustaffa over 5 years ago

Such a system would allow me to use a2ts addon in multiplayer, without it messing up my clipboard. Voted yes, but I'd vote HELL YES if I could :)

Updated by sbsmac over 5 years ago

I am very keen to see some kind of IPC implemented. Amongst other things, this would provide the ability to automate some aspects of ArmA from external applications (with help from internal scripts). To give an example of the kind of thing I have in mind...

  • A league mission is modified to include scripts to report player movement and state (1) via IPC to an external application.
  • After the game is completed, the external application can then restart ArmA in windowed mode using the same map.
  • With help from scripts in the mission, the external application can be used to 'replay' the players movements during the match, including rewind, fast-forward, change camera-angle, annotate , create movie-sequence etc.
  • It's a lot easier to create these kinds of 'control' applications in .NET vs ArmA scripting
  • The ArmA renderer is used for visualisation - clearly far superior than trying to create arepresentation of the map in an external application.
Other possibilities...
  • an external 'games-master' could monitor and control events on a server.
  • Game-state could be easily preserved for some kinds of episodic games.
  • An application could act as a 'bridge' between two servers - for example supply of munitions on the Utes mission might be affected by the situation in a matching game on Chernarus.

Obviously all these things require helper scripts within the mission but that is do-able once the IPC mechanism is in place.

(1) I'm aware that animation state is not recorded for non-local objects but basic position and direction is still interesting.

Updated by yery over 5 years ago

Hey guys, you might not notice, but in A2OA a new scripting command was introduced:

sendUDPMessage ["",4444,"udp message"]

It sends a message to the given IP address using UDP protocol. Broadcasting is supported as well.
This will allow you to implement messages over OSC protocol as well. Size of the message is limited to 1024, however you can send many of them in one frame, each to a different address/port.

UDP support is output only, option to send data to ArmA is not present.

Another - bit "hackerish" - option is to use pair of commands copyToClipboard & copyFromClipboard, already documented in community wiki. In many cases it might be a sufficient solution :) .

Updated by kju over 5 years ago

  • Status changed from Assigned to Feedback

Great news Yery. :)

Feedback by community devs on this please.

Updated by messiah over 5 years ago

Have anyone checked sendUDPMessage? Is it really working?

Updated by oktane over 5 years ago

kju wrote:

  • Status changed from Assigned to Feedback

Hi, can you reassign this ticket to BIS? The udp command is nice and all, but it doesn't apply directly to this. If it were two-way, that may apply. I don't think it was even implemented based on this feature request. There are many technical/practical reasons discussed in the wave.

PS: Thank you for the info yery! Do you know if it was created for this? It will sure come in handy later for instant score logging, external map apps, and things of that nature. Cheers
(sorry everyone for all the 'edit' email notifications)

Updated by oktane over 5 years ago

messiah wrote:

Have anyone checked sendUDPMessage? Is it really working?

I couldn't get it to function, did you have the same experience? Used wireshark, no traffic to the filter matched port at all.

Edit: You have to set up a proper listening UDP client. Please see the wave discussion. Still not working, please continue sendUDPMessage discussion on it's own ticket: #11743

Updated by messiah over 5 years ago

oktane wrote:

I couldn't get it to function, did you have the same experience? Used wireshark, no traffic to the filter matched port at all.

My OA copy is still in transit, so I can't check myself... was really surprised, that something like that was (or will be) implemented, but you say that it's not (or at least yet) :(

Updated by oktane over 5 years ago

messiah wrote:

was really surprised, that something like that was (or will be) implemented, but you say that it's not (or at least yet) :(

Here is a ticket about the udp feature, let's continue the discussion for that there so that they remain separate and this ticket can be allowed to stand on it's own. Thanks! #11743

Updated by kju over 5 years ago

  • Status changed from Feedback to Assigned

Updated by firefly2442 over 4 years ago

Perhaps this is something that could be added as a feature in Arma3?

Updated by MavericK96 about 4 years ago

This would be AMAZING to have in ArmA2:OA. It would mean that it would be much easier to use mods like ACRE without having to wait for user-made hacks to get it to work right for every new beta build.

Updated by Dwarden almost 4 years ago

  • Status changed from Assigned to In progress
  • Assignee set to Dwarden
  • Target version set to 1.61 BETA

miracles may happen

Updated by Sickboy almost 4 years ago

This is now a dup of #25915 ?

Updated by MadDogX almost 4 years ago

  • Status changed from In progress to Duplicate

Yes, #25915 covers this completely. Marking this one as duplicate, since #25915 has more recent info and dev activity.

Updated by kju almost 4 years ago

  • Target version deleted (1.61 BETA)

Also available in: Atom PDF