Data storage

[SyB 0]

An interesting topic for sure...

I think the trick would be convincing the 'NetServer' thread that it's recieved a 'createPlayer' for player id 2, named '_SERVER_'. (Apparent from the .rpt file)

This would then mean that upon the first live person connecting to the server to play a persistent CTI or progressive battle mission that there would be...

1 identity connected to  1 player for client named '_SERVER_'

And

1 identity connected to 1 player for client named ‘Ghandi’

Then ‘Ghandi’ would merrily play away and upon disconnecting from the server the ‘onPlayerDisconnected’ event would fire which would run a server-side script that did a ‘saveGame’ command on the player identity called '_SERVER_' thus writing out the rapified current status of all variables and game entities.

An external tool could then monitor the server save game file for any modifications and... do lots of interesting stuff...

It would be highly desireable if BIS just enabled the '_SERVER_' player to create an in game identity by allowing the server.exe to send a 'createplayer' to it's NetServer thread through say a commandline parameter called '-ServerIdentity=true' or something similar... (hint, hint and a wink for good measure)

I guess they may get round to this sorta thing, or even already be doing it... They are busy folks and we should all keep in mind we're only a couple of patches into the fray...

I've already tried doing 'saveGame' command on the player '_SERVER_' and testing if the player even exists, which it appears not as an identity isn't created for it...

Food for thought eh?

Cheers, Sy

Edit: Should read more carefully, just read Unn's post on the first page so disregard this post, the notion has already been posited.

[Nutty_101 0]

Well, i am trying to finish up a persistant map that uses external data to keep track of what areas are captured. It uses a system where you cannot capture a city unless you have a supporting city in your control. Thus creating links around the map. Once this is done the system starts to create a profile of the towns and who is a higher profile. Once the major towns are defined out it starts to change the tactics on how it sends reinforcements to that town. The units are also never in the same place thanks to a neat script that is always keeping them running around the town hiding in random places but not for to long. If you attack one, they will work with each other to figure out where you are and get you surrounded without you noticing. I also am working on a webpage that will show everything going on. So you can see the town status's. A history of when a town was captured, how long the battles took, ratio of units in the town to enemy units. You can also refresh and keep a nice view on the internal transit system. So for people who have more than one monitor you will be able to see where the buses are and figure out how long until they show up. They are quite handy for transporting you and your team around. Also each town has different aspects of what they give you in return for holding them. Pita for example is one of two towns that provide air support. There is the island above but to get to that it will require capturing one of the harbor towns.

I have three versions i am hoping to get working. Only two have a chance of showing up online. The whole idea is so admins can do some data storage. One of them is nothing more than emulating a client connecting to the server. This one is somewhat interesting in the fact that i am trying to build up enough to let the admins use the publicvariable command. (not really working so far but i am trying). At the moment i can however connect to a server and send a chat. Though it has crashed my dedicated server. So who knows.

The second method i have working is a function that sets a variable that is monitored via an external program. This reads and updates the variable to be used. So far we are limited to strings though i am also making some progress with numbers. In the end i hope to make it so we can use the function to store data in an external database live. If a string is good enough to someone to do all their scripting then i may just release something in a bit.

The last one i doubt i will ever release as it could be classified as a hack. However once the application is loaded i am injecting my own code into the game to call a dll that processes functions. I have had some luck but it causes the game to lag somewhat in MP. If i get this working well i doubt i will release it. Though it is the most promissing (this is also the same concept that viruses use. Grin)

If anyone from Bis can give me note on if any of this is even allowed it would help. I dont want to release anything that would be seen as breaking the eula or whatnot. Bioware took a huge stance on the dll injection to do SQL. Thus the reason i doubt that will work.

[sickboy 13]

Totally Wicked

This is opening up so much more, if this really can be gotten to work

Goodluck and if anyone needs some help, just shout

[.kju 3245]

write suma a pm

[sickboy 13]

write suma a pm

Nice of you to drop by again Q ^^

And indeed a very good tip!

[whisper 0]

write suma a pm

As this is "the good idea of the day" (props to Q, as usual ), I took the liberty to do it myself

[SyB 0]

Hmmm... most excellent yes indeed, was thinking along the same lines...

You're 3rd option sounds similar to Keygety's 'FWatch' which hooked the 'loadFile' scripting command and allowed saving of info out to disk...

Hope Suma provides you with some positive feedback...

Any assistance you might need drop me a line.

Cheers, Sy.

[suma 8]

The last one i doubt i will ever release as it could be classified as a hack. However once the application is loaded i am injecting my own code into the game to call a dll that processes functions. I have had some luck but it causes the game to lag somewhat in MP. If i get this working well i doubt i will release it. Though it is the most promising (this is also the same concept that viruses use. Grin)

Injecting a code in the memory is basically the same as modifying the exe file, only via other means, this is something we are not definitely willing to support or allow. It may even cause copy protection or cheat detection to react to perceived hack, which in fact it is (same method is often used by hacks and cheats).

[sickboy 13]

Injecting a code in the memory is basically the same as modifying the exe file, only via other means, this is something we are not definitely willing to support or allow. It may even cause copy protection or cheat detection to react to perceived hack, which in fact it is (same method is often used by hacks and cheats).

Does this mean we can expect hooks or functions which we can use to access or even write to external files and or databases etc. etc? We do not seem to find these functions atm... same for being able to use a key on the keyboard to execute a function/action etc?

It would be extremely helpful and great for ArmA to have these functionalities simply because it will open up the World for ArmA!

Advanced Statistics...Advanced Special Leagues, Advanced Competitions, saving gamestates even for MP... and much much more.

I really think its every OFP/ArmA's addon and (MP) mission makers dream to save data and/or read data from external sources. Even only reading and writing to files or 'a' file would already be the little thing we need to accomplish MUCH much more.

[whisper 0]

Not counting it could open a whole area of inter-games communication (I'm thinking for example with futur LO-BlackShark)

[VictorFarbau 0]

Very true - I have dreamt about this for a long time. Saving and loading complete scenarios (all objects & variables) in SP and MP games would enhance gameplay considerably in my mind.

You cannot expect people to play more complex war scenarios in one session only. Then again it's boring to start all over again each time since this does not value any accomplishments made so far. Exchanging data through files would open a new perspective on mission design altogether. I'd say we need it  

[crashdome 3]

Not counting it could open a whole area of inter-games communication

They already have this... it's called VBS2

...which is why I am pessimistic about any support from BIS.

Nutty, PM me if you need help or ideas.

[UNN 0]

There may be a less controversial way, someone already mentioned the *.rpt file. It is possible to add an entry to this without raising any errors in Arma.

For example this line of code:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">PP="Data Test" CreateVehicle [0,0,0]

Results in this entry in the ARAM.RPT log:

Quote[/b] ]Cannot create non-ai vehicle Data Test,

I'm sure there are other ways to.

This way, with the appropriate post-fix you can locate and export at least text and numbers, if not actual objects.

But the problem with the rpt file is, there will be lots of additional lines to wade through before getting to the important stuff. But I'm sure a little bit of house keeping will keep it to a minimum?

Anyway, something else to play with.

[.kju 3245]

keep in mind that the arma.rpt is deleted automatically once its gets over 2mb (or some similar algorithm) (however just once the process has been stopped i guess)

[Nutty_101 0]

There may be a less controversial way, someone already mentioned the *.rpt file. It is possible to add an entry to this without raising any errors in Arma.

For example this line of code:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">PP="Data Test" CreateVehicle [0,0,0]

Results in this entry in the ARAM.RPT log:

Quote[/b] ]Cannot create non-ai vehicle Data Test,

I'm sure there are other ways to.

This way, with the appropriate post-fix you can locate and export at least text and numbers, if not actual objects.

But the problem with the rpt file is, there will be lots of additional lines to wade through before getting to the important stuff. But I'm sure a little bit of house keeping will keep it to a minimum?

Anyway, something else to play with.

Not sure the report file is a good way to go. There is so much junk in that file during a mp game. Plus you have to unlock it and everything else just to read the file. On top of that I don't think that the file is written out constantly. It has some buffer before it spits the lines out. So who knows.

[Maximus_G 0]

Well, i am trying to finish up a persistant map that uses external data to keep track of what areas are captured. It uses a system where you cannot capture a city unless you have a supporting city in your control. Thus creating links around the map. Once this is done the system starts to create a profile of the towns and who is a higher profile. Once the major towns are defined out it starts to change the tactics on how it sends reinforcements to that town. The units are also never in the same place thanks to a neat script that is always keeping them running around the town hiding in random places but not for to long. If you attack one, they will work with each other to figure out where you are and get you surrounded without you noticing. I also am working on a webpage that will show everything going on. So you can see the town status's. A history of when a town was captured, how long the battles took, ratio of units in the town to enemy units. You can also refresh and keep a nice view on the internal transit system. So for people who have more than one monitor you will be able to see where the buses are and figure out how long until they show up. They are quite handy for transporting you and your team around. Also each town has different aspects of what they give you in return for holding them. Pita for example is one of two towns that provide air support. There is the island above but to get to that it will require capturing one of the harbor towns.

Thumbs up!

I'm very glad to see someone working on these features.

I personally can't stop thinking of a persistent "gamezone" since i've bought Arma. Though i have slightly different ideas on the gameplay.

Anyway, saving data and combining human and AI players is desperately needed.

[UNN 0]

Quote[/b] ]keep in mind that the arma.rpt is deleted automatically once its gets over 2mb (or some similar algorithm) (however just once the process has been stopped i guess)

Yeah, thats why I mentioned house keeping. The file could be striped of anything that wasn't needed. A lot depends on how and when you wanted to grab the info.

Quote[/b] ]Not sure the report file is a good way to go. There is so much junk in that file during a mp game. Plus you have to unlock it and everything else just to read the file. On top of that I don't think that the file is written out constantly. It has some buffer before it spits the lines out. So who knows.

Like I said, it's something else to look at. It was worth mentioning just as an additional debug tool for long or complex scripts. In some cases it might be handy for extracting lots of data from Arma. Although I would prefer to use something other than the create vehicle commands. Even if it's not creating an actual object, I'm sure it has it's over heads.

As a quick test, I knocked up this script:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_EndTime=Time+20;

WaitUntil

       {

       _Null=Format ["Time:%1 Pos:%2 Dir:%3",Time,GetPos Player,GetDir Player] CreateVehicle [0,0,0];

       Sleep 0.01;

       (Time>_EndTime)

       };

Hint "Done";

Starting with an empty rpt file, it came to about 51.3 KB. Here is a section of it:

Quote[/b] ]Clearing multiplayer statistics

Cannot create non-ai vehicle Time:4.005 Pos:[2538.71,2519.41,0.00143909] Dir:2.35279,

Cannot create non-ai vehicle Time:4.038 Pos:[2538.72,2519.55,0.00143909] Dir:16.2431,

Cannot create non-ai vehicle Time:4.071 Pos:[2538.75,2519.68,0.00143909] Dir:23.339,

Cannot create non-ai vehicle Time:4.104 Pos:[2538.81,2519.8,0.00143909] Dir:31.0353,

Cannot create non-ai vehicle Time:4.137 Pos:[2538.88,2519.92,0.00143909] Dir:37.9211,

Cannot create non-ai vehicle Time:4.17 Pos:[2538.96,2520.02,0.00143909] Dir:40.8433,

Cannot create non-ai vehicle Time:4.203 Pos:[2539.05,2520.12,0.00143909] Dir:41.1036,

Cannot create non-ai vehicle Time:4.236 Pos:[2539.14,2520.23,0.00143909] Dir:41.1036,

Cannot create non-ai vehicle Time:4.269 Pos:[2539.23,2520.33,0.00143909] Dir:41.1036,

Cannot create non-ai vehicle Time:4.302 Pos:[2539.31,2520.44,0.00143909] Dir:41.1036,

Cannot create non-ai vehicle Time:4.335 Pos:[2539.4,2520.54,0.00143909] Dir:41.1036,

Cannot create non-ai vehicle Time:4.369 Pos:[2539.49,2520.64,0.00143909] Dir:41.1036,

Cannot create non-ai vehicle Time:4.402 Pos:[2539.58,2520.75,0.00143909] Dir:41.1036,

Cannot create non-ai vehicle Time:4.435 Pos:[2539.67,2520.85,0.00143909] Dir:41.1036,

Cannot create non-ai vehicle Time:4.468 Pos:[2539.75,2520.96,0.00143909] Dir:41.1036,

Cannot create non-ai vehicle Time:4.501 Pos:[2539.84,2521.06,0.00143909] Dir:41.1036,

Cannot create non-ai vehicle Time:4.534 Pos:[2539.93,2521.16,0.00143909] Dir:41.1036,

Cannot create non-ai vehicle Time:4.567 Pos:[2540.02,2521.27,0.00143909] Dir:41.1036,

Cannot create non-ai vehicle Time:4.601 Pos:[2540.1,2521.37,0.00143909] Dir:41.6686,

Cannot create non-ai vehicle Time:4.634 Pos:[2540.19,2521.47,0.00143909] Dir:45.9018,

Cannot create non-ai vehicle Time:4.667 Pos:[2540.29,2521.57,0.00143909] Dir:49.253,

Cannot create non-ai vehicle Time:4.7 Pos:[2540.39,2521.66,0.00143909] Dir:52.2596,

Cannot create non-ai vehicle Time:4.733 Pos:[2540.5,2521.74,0.00143909] Dir:54.8919,

[Nutty_101 0]

Humm. not bad, still cannot import data though. Thats the sucky part if you ask me.

[sickboy 13]

Humm. not bad, still cannot import data though. Thats the sucky part if you ask me.

You could drop by Kegetys to ask him how he hooked his fwatch to see if you could get anywhere with that option?

(If im not mistaken we could do some basic read/writing with it, at least for what I heard... I didn't use it for that myself )

[Nutty_101 0]

We can read the variables live via a packet monitor. Writing to the apps is the issue. Without hooking or memory reading i dunno.

[sickboy 13]

Just been thinking...

How about the General Scripts folder? Does it also work on dedicated servers?

This aughta be: Your Profile Folder\Scripts (e.g my documents\arma\scripts or my documents\arma other profiles\your name\scripts)

If this could be readable by dedicated server aswell... then you could put scripts or update scripts in there, and exec(vm) them to get the variables!

For single player this should already work!

[crashdome 3]

Humm. not bad, still cannot import data though. Thats the sucky part if you ask me.

You could drop by Kegetys to ask him how he hooked his fwatch to see if you could get anywhere with that option?

(If im not mistaken we could do some basic read/writing with it, at least for what I heard... I didn't use it for that myself )

My understanding is that this no longer works in ArmA, but I could be wrong.

The general scripts folder is just about the easiest way to import data because you can format it as code ahead of time. Simply "calling" it in the engine is the only thing to do.

As everyone can probably tell by now, getting info out is the hard part. I like the idea of the rpt file, but the fact it is in use already makes it a poor hack. Although, it seems to be the best alternative at this point...

[sickboy 13]

The general scripts folder is just about the easiest way to import data because you can format it as code ahead of time. Simply "calling" it in the engine is the only thing to do.

As everyone can probably tell by now, getting info out is the hard part. I like the idea of the rpt file, but the fact it is in use already makes it a poor hack. Although, it seems to be the best alternative at this point...

Roger that... but as readable here, there is a packet monitoring option to get the data....

Quote[/b] ]We can read the variables live via a packet monitor. Writing to the apps is the issue. Without hooking or memory reading i dunno.

 While writing to the app (reading in the app) was suggested to be an issue

Do you know of any other methods for reading from external files, other than the scripts folder (and do you actually know if this works in MP too? ) (im gonna test it this weekend anyway )

[crashdome 3]

Quote[/b] ]The second method i have working is a function that sets a variable that is monitored via an external program. This reads and updates the variable to be used. So far we are limited to strings though i am also making some progress with numbers. In the end i hope to make it so we can use the function to store data in an external database live. If a string is good enough to someone to do all their scripting then i may just release something in a bit.

I like this idea. I can write a serialization script for ArmA which will convert any data to XML. If the strings have zero limits (like the OFP 4096 bytes) than I think this is an awesome idea. I can also write an app which will produce SQF code as a method of returning any data.

By converting the data to XML, it is by far the easiest for non-developers to use across any platform.

[KeyCat 131]

There may be a less controversial way, someone already mentioned the *.rpt file. It is possible to add an entry to this without raising any errors in Arma.

Nice find UNN

As already stated this may not be the prefered way to do it but at least we now have a simple way to export data to an external file.

Should be easy enough to create some simple "co-op ranking system" by using the score command on each player when the mission ends, write the scores to the *.rpt for parsing by an external app. and then over to a DB or a web-page.

That being said, hopefully there will be a better way in the future for getting data IN/OUT of ArmA...

/KC