Interface to third-party languages

[Hawk666 0]

Hi,

what do you think about the possibility to provide an interface to other program languages, like c++, python ?

I don't mean, that you can access the arma engine from these languages (would be great, but probably too expensive to build?)

but the other way around: to call some python, c++ etc. coding from Arma scripts.

Reason: you could create (and reuse) complex algorithms in standard languages and use the libraries which are already available etc. (non-visual stuff, of course)

I don't know, how expensive that would be to built, but it would follow a trend, which you can see by other major sdks: They provide the possibility to use scripts for 'easy/medium' tasks and for complex one's you can use c++ etc.

[baddo 0]

Yes yes.

Instead of hacky non-official workarounds (fwatch and others), some official support could be provided for this?

Reasons why it can't be done? Security? Not worth to do by BIS? It should make business-sense for BIS.

[kegetys 2]

That would be a massive security problem, at least I wouldn't want to join a multiplayer server and find out the mission had a script that deleted everything it can from my hard drive :P To make it usable it would need some kind of sandbox, which would in turn propably cause it to be incompatible with most existing code.

A better way to do it would be to have some kind of interface for external applications to connect to the game using TCP for example and exchange data with in game scripts. Live for Speed has a system kind of like this (inSim)...

[baddo 0]

Well security problems came to my mind too as the first reason why not to do it.

It's possible with fwatch, if someone modifies it to do evil things and tells users to use their version without giving source code...

What if only read access to data is provided? Allow an external application to read the game state. Would this be useful enough?

[shinRaiden 0]

You are asking for one or two things, which are bad or worse.

1 - OFP/Arma script has a method to it's maddness, it's closely tied to how the engine innards function. As a result, it can provide much higher performance than relying on an external sandbox like the python or lua scripting seen in various recent titles.

2 - Opening the engine to external API access without having a respectful, disciplined, and guaranteed behaved community would as mentioned previously be inviting disaster of levels as yet unseen.

[Hawk666 0]

@shinRaiden: I understand your arguments regarding performance.

The main problem which I have personally with the 'ArmA Script standalone approach is':

- since it's a proprietary language you cannot use standard libraries (AI algorithms etc.)

- regardless of the capabilities: It's not a clean language: no library , 'thousand' keyword, no real debugging, no OO. Modders who are familar with the script environment since the beginnings of OFP are surely productive. But people like me, which come from 'standard' languages' have a high learning curve. The code from existing, complex, scripts reminds me of Perl: It's very difficult to read if your're not an expert.

And I've doubts that ArmA2 scripts gets a redesign due to high efforts for BIS and the compatibility issue to existing mods.

- there are missing functionalities, like access to file system etc.

Regarding python you might be right, but I think it's not valid if you call c++.

Apart from this: The proposal to enable TCP/IP in scripts (eg. sockets) would be better than nothing.