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.

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.

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.

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.

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.

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.

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.

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 :-)

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)

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.

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.

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.

Benefits:

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.

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

sendUDPMessage ["192.168.1.255",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 :) .

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)