A 100% clean way of getting External Data in and out of ArmA2... almost there!

After sitting and thinking long and hard I have formulated a 100% clean means of getting external data in and out of ArmA2.

That is to say without the use of the clipboard or any external programs like ArmaLib or anything similar. First off, such a system would have many obvious uses. What I've personally got in mind is a dynamic campaign where the results carry over from mission to mission. There is a decent chance of this data system ending up as an Addon so I posted this here in the Addon Discussion area. If you're interested hear me out! :D

Getting External Data into ArmA2

This part is easy. Simply utilizing the loadFile command and parsing the data with CBA string functions.

Getting ArmA2 data out

This part's harder, but I finally figured out how to make it happen! It all has to do with the "report file". Here's some info on it:

http://community.bistudio.com/wiki/Crash_Files

Turns out the diag_log command will write to this report file. So we can reliably pass data out of ArmA2 into the report file. Good so far!

Trouble is, the report file is located out in the AppData folder, which as far as I know currently, ArmA2 cannot get to via the loadFile command. As far as I'm aware (and please correct me if I'm wrong) , in terms of scripting ArmA2 can only access folders and subfolders within:

1. The main ArmA2 folder - example:

	_text = loadFile "\userconfig\MRU\MRU_DD_Config.hpp";

2. A mission folder - example:

	_text = loadFile "Library\MRU_Distance2D.sqf";

Note the difference being the lack of the leading back-slash.

As far as I can discern, you can't go UP and thus outside these two specific types of areas, like this:

	_text = loadFile "\..\..\TestFile.txt";

Nor can you simply go anywhere specific, like this:

	_text = loadFile "c:\Temp\TestFile2.txt";

Please someone tell me I'm mistaken about this and you can get to the AppData folder somehow and then we've got it!

-OTHERWISE-

Fortunately (although a less ideal solution), you can temporarily relocate the report file location to where ever you want, via the -profiles tag in the ArmA2 startup parameters:

http://community.bistudio.com/wiki/Arma2:_Startup_Parameters#Profile_Options

Now, there are some advantages and disadvantages to relocating the report file.

• Disadvantage first: ArmA2 expects your profile info (key setup, etc) in the new location as well. Not a huge deal though, you can just make a quick copy.

• Advantage: Because "-profiles" is a startup tag, you only load that way when necessary. (i.e. if the mission requires, etc)

So in theory we should be able to:

1. Relocate the Report File to somewhere ArmA2 can access (hopefully not necessary if someone knows how to access files outside two aforementioned key areas)

2. Pass Data from ArmA2 to the report file via diag_log

3. (optional step) Extract the data from a report file via an external app

4. Pass Data from external file to ArmA2 (either directly from the report file or from a processed txt file the external app created)

Awesome!!!

The only trouble I'm having right now in trying this out, is with the "-profiles" tag. My startup line looks like this:

"C:\Games\Arma 2\Arma2.exe" -profiles=C:\arma 2\Profiles

Unfortunately, because I have a space between "Arma" and "2", it's not working. Placing quotes around the path does not work (i.e. it seems to expect no quotes):

"C:\Games\Arma 2\Arma2.exe" -profiles="C:\arma 2\Profiles"

When I try the next line as a test, the report file ends up in the right place (but of course I need it somewhere down past the main ArmA2 dir):

"C:\Games\ArmA 2\Arma2.exe" -profiles=C:\Temp\A2_Profiles_Test

Anyone know any way of making this "-profiles" tag work given the space in the path?

Also, back to the idea of getting the loadFile command to see outside the main ArmA2 folder and individual mission folders... this is the ideal way to do it (because you wouldn't have to move the report file at all in this case). Anyone know if there is a way?

So close!!! :)

Try "-profiles=C:\arma 2\profiles" works that way for -mod for example.

Kick ass Sickboy! That worked! :)

How about getting loadFile to see outside main ArmA2 folder and mission folders? Anyone accomplished this feat?

What I've personally got in mind is a dynamic campaign where the results carry over from mission to mission.

Just to make sure: you ARE aware that there has been commands for this ever since OFP:Resistance, right? E.g. saveVar, saveStatus and saveIdentity. So I'm not entirely sure if doing THAT might be the best implementation of this whole thing; I'm sure there's something else that it can be used for though :)

Regards,

Wolfrug

One day they'll make sendUDPMessage actually work then there will be no end of possibilities including the ability to spool to a file anywhere (using a tool like netcat).

One day they'll make sendUDPMessage actually work then there will be no end of possibilities including the ability to spool to a file anywhere (using a tool like netcat).

True but I envisage the majority of applications would need bandwidth out and there's always loadFile and/or copyFromClipboard for the other direction.

Just to make sure: you ARE aware that there has been commands for this ever since OFP:Resistance, right? E.g. saveVar, saveStatus and saveIdentity.

Those look like they might indeed work for my intended purpose. Very nice. :)

But it appears they only work for "campaign space". I'll have to run some tests in an individual mission and see if anything carries over between sessions.

So I'm not entirely sure if doing THAT might be the best implementation of this whole thing; I'm sure there's something else that it can be used for though :)

In the end, it may turn out that using the report file is the only clean way to pass data in and out of ArmA2 when doing anything outside the confines of an individual campaign. But if anyone can crack this nut in a different way (and in a more elegant way perhaps), by all means let's discuss it here!

---------- Post added at 07:28 PM ---------- Previous post was at 06:22 PM ----------

EDIT:

Regarding saveVar, saveStatus and saveIdentity:

I just tested saveVar and it works as advertised for campaigns while playing in single player (bridging the data from mission to mission). However, surprisingly, saveVar does NOT bridge data from mission to mission in campaigns while playing in multiplayer. Why not? Certainly I think this should work. :eek:

Unfortunately I have a dynamic coop multiplayer campaign in mind. Anyhow, back to attempting to pass data via the report file.

So the only thing you need is an application running alongside ArmA2 which constantly monitors the report file and feeds all relevant infos into a file inside a folder of the mission that is currently playing right?

How would the application know which mission is running?

The basic idea I've got is to achieve the functionality of saveVar (and subsequent retrieval of that data), but only be able to do it outside of "campaign space", and do so without any external app (like ArmaLib, etc) or the clipboard being required.

So the bare basic functionality is this:

1. You call a function to save data, which gets written to the report file via diag_log.

2. In a subsequent mission, you call another function to retrieve the saved data, which gets read in directly from the report file via loadFile.

This ability in and of itself would be extremely useful.

If this can be achieved (which now it seems almost certain it can), that opens the door to something like what you're talking about, where you can interface easily with an external app if desired. I see that as kind of a bonus. External app can monitor the report file and feed info into a file that ArmA2 reads in exactly as you mention.

)rStrangelove;1790711']How would the application know which mission is running?

In terms of feeding data back into ArmA2' date=' you can put the file anywhere inside main ArmA2 directory or an individual mission file, so if you had an external app feeding the data back in I suppose it wouldn't really need to know which mission is running. For instance you could just feed the external data back to ArmA2 in the "ArmA2\FeedIn\FeedIn.txt" file.

In any event, it would be really nice (though not necessary by any means) to be able to break free from that requirement of ArmA2 only having access to main ArmA2 folder and individual mission folders via loadFile, if anyone knows how to do it.

So hopefully I can get a mockup of this thing running sometime relatively soon.

Try creating a symbolic link in the ArmA2 folder to the file of your choice located somewhere else. Pretty certain that would work in Linux but I've never dabbled with Windows symlinks.

Good idea Defunkt. Found some info on "symbolic links" and it's looks like that will work with Win 7.

Symbolic Links in Windows

Will try out Hard Links and Soft Links soon and report back. :)

UPDATE:

So, ready to have a crack at this thing, I relocated my report file to "C:\Games\ArmA 2\Profiles\arma2.RPT" via the profiles tag.

I start out by trying to read in the report file via loadFile:

_txt = loadFile "\Profiles\arma2.RPT";

Not working.... Getting a message that it can't find the file.

So after some experimentation, I rename the report file and try again:

_txt = loadFile "\Profiles\arma2_DEVIOUS_BASTARDS.RPT";

Now that one works like a charm. Contents of the renamed report file read in and display just fine in all their glory (and a new impenetrable report file is generated).

Just to be sure, I repeated this phenomenon multiple times and the results are clear.

Apparently BIS specifically blocks read access to the report file via loadFile.

Foiled!!! BIS are simply devious bastards.

And I say that with all due respect. They actually thought ahead that someone would cook up this scheme and actually try this. Gotta love em.

In any event, I hereby admit defeat.

[btw- I hope if nothing else I got a good laugh out of a BIS dev or two. Thanks again for making the best games on the market, and I mean that. :) ]

Ok, so we need another app running in the background making renamed copies of the report file? :)

Apparently BIS specifically blocks read access to the report file via loadFile.

I expect it's just a by-product of the file being used and open for constant update where your duplicate is not already being accessed by ArmA.

But, didn't someone invent an addon which could write to entire tables of external data, with SQL for both ways? Not Jaynus' thingy, someone elses?

)rStrangelove;1791393']Ok' date=' so we need another app running in the background making renamed copies of the report file? :)[/quote']

Well, I guess the entire point was to do it all native without any external app for the basic functionality (and why I was calling it "100% clean"). I don't know about you, but I'm always leery of running someone else's exe file. :)

But maybe creating a simple external app in AHK or similar and provide the source code to users isn't so bad.

I expect it's just a by-product of the file being used and open for constant update where your duplicate is not already being accessed by ArmA.

That occurred to me later on. I probably jumped the gun a bit. Yeah, look at me going all conspiracy theorist, and calling out BIS as involved in a intricate and cunning scheme to thwart budding mod creators. :alien: I can hear the white coats transmitting inside my head as I write this. :D

My bad BIS, I recant my prior allegations pending any truly irrefutable evidence.

So yes, in all likelihood you're probably right, but do we really understand the mechanics of why this isn't working? I mean, it's not like loadFile should be attempting to open the file with write access... it should just be reading it, right?

But, didn't someone invent an addon which could write to entire tables of external data, with SQL for both ways? Not Jaynus' thingy, someone elses?

I recall Fwatch from long ago, that handy little app. Is there something else for ArmA2? If you are reading Sickboy, does CBA provide anything like this? (If so, guess I've just missed it til now.)

You do realize that the report file can get several megabytes large?

Even if you do manage to open the file with loadFile the behavior will be undefined at best.

But, didn't someone invent an addon which could write to entire tables of external data, with SQL for both ways? Not Jaynus' thingy, someone elses?

You mean this?

http://forums.bistudio.com/showthread.php?t=96524&highlight=sql

Not sure what happened to it :P

You do realize that the report file can get several megabytes large?

Even if you do manage to open the file with loadFile the behavior will be undefined at best.

Yes it's a pretty big file. And I do have questions regarding performance when reading the data back out of it. But I wouldn't call the behavior "undefined". Should work like a charm, if we could only get it open.

Now, having said that, it appears the report file is of fixed length. So if you had a repeating error (say from a faulty addon script) that went on and on and on being written to it, that could theoretically push out the data you wrote in. Easy solution in that case though: Fix the thing causing the report file to blow up.

Anyhow, the reason I'm so fixated on the report file is that it's the only way I can think of to get data out and back in using no external apps. Sadly, it sure seems this particular method isn't viable after all.

You mean this?

http://forums.bistudio.com/showthread.php?t=96524&highlight=sql

Not sure what happened to it :P

Very interesting. Plus in the thread he mentioned the source was posted.

You mean this?

http://forums.bistudio.com/showthread.php?t=96524&highlight=sql

Not sure what happened to it :P

Yeah, that was it. Good find. But seems to be gone ....

What's wrong with using external tools anyway, especially since they provide the functionality you are after.

Nutty's tool is (was?) basically like jay's armalib etc.

One reason I could think of is that you have to wait for an armalib update, at betas and patches.

However how long is that usually? And there's now also auto-update built-in to jay's lib.

Agreed. If this report file method was viable and worked without any drawbacks, that would be ideal. However...

Good thing folks are working on these external tools, because unless there’s another way to skin this cat, there’s really no way around using them anyhow. :)