AAR (After Action Review - replay of your battle in Arma2)

[DZR_Mikhail 14]

Hi boom!

I'm glad my project can help you. Have a look. As far as your messages are not bigger than 4096 bytes, you can even use my whole system but on the broadcasting stage reproduce not my playback algorythm, but like your own "reading.sqf".

Your task is a little bit simpler than mine, but at the same time may encounter the same obstacles. Using log for dumping messages is a workaround but it's no good for me. There must be way to use all the JayArma2Lib potential and aquire more stable and flexible data transfer by using the named pipes.

I'm still discussing the issues with Jaynus and ACE devs. No progress yet. I guess Jaynus is the only hope for me. He knows Arma2 engine and his ArmaLib like no one else and can help creating a very efficient workaround.

[Mack. 58]

Ive been playing with the alpha and just wanted to say its got fantastic potential, thank you for releasing it.

Im looking forward to the next release

[DZR_Mikhail 14]

Thank you, psychobambi.

I'm waiting for it as well)))

[Muahaha 10]

Voted at Dev Heaven... hoping it will be resolved or circumvented. Great work !

[DZR_Mikhail 14]

Thank you, Muahaha.

[rcdxph 10]

What is improvement ？

[DZR_Mikhail 14]

Issue is pending here for two weeks. Still no reaction from Jaynus, I can't do any further steps until this bug\error is solved.

In fact, I can't build or plan any coding cycles and algorithms until I know how exactly I shall use JayArma2Lib when sending my data to a named pipe and not loose messages randomly.

Very sad, but cannot continue any further without the help from Jaynus or someone who uses JayArma2Lib in the same way I do.

[Mack. 58]

Ive read up about the VBS2 AAR and the method they use is to record the network packets.

Is this a possible workaround for the data transfere problems?

[rcdxph 10]

well, VBS2 may used the tech of "HLA,high level architecture",so they can record data of "PDU,Protocol Data Unit".

So,zvukoper,you can study the distribute simulation system of Russia army!

may be you can find the method.

[rcdxph 10]

What is the improvement ？

[rye1 21]

This sounds really cool.

This a version of ours on the MSO. :D

Yours sounds very large if it will replay the whole mission etc, sounds complicated - would probably lag the MSO out. Haha!

http://dev-heaven.net/projects/mso

[Mack. 58]

well, VBS2 may used the tech of "HLA,high level architecture",so they can record data of "PDU,Protocol Data Unit".

So,zvukoper,you can study the distribute simulation system of Russia army!

may be you can find the method.

My techincal knowledge is limited but I guess as long as you start a network game the data packets travelling from the server could be recorded?

[rcdxph 10]

Yes,you can research the software "VR Link of MAK" ,they can do this. This is the addr. http://www.mak.com/products/vrforces.php

Edited January 8, 2011 by rcdxph

[Mack. 58]

Any news on this fantastic project?

[rcdxph 10]

What is now ?

[DZR_Mikhail 14]

Still no progress. Too busy with my squad atm. We launch new roleplay story this saturday. Getting ready the scripts for it. Right after the first episode I'll start testing the pipes configurations which are supposedly the main reason AAR is unstable.

So, till next week. On the next Saturday I think I will have results (bad or good who knows)

---------- Post added at 04:59 PM ---------- Previous post was at 04:39 PM ----------

Yours sounds very large if it will replay the whole mission etc, sounds complicated - would probably lag the MSO out.

One of the core principles of this project is preserving the treasured fps and game stability without any sever impact on the performance. I know it's possible. At this point I use almost realtime events capture which is too powerful, really enormous and overclocked, but gives the same cool level of replay. At any point where the system will get clogged by such unrestricted rate of recording\playback I'll tune the overall quality down. I also planned make this easily configurable. Anyone will be able in a simple way to choose any FPS for his replay which suits him.

From some feedback I already know that some people have no impact and no lags at all, some people experienc it only few seconds after AAR starts... I have no lag or impacts at all.

My techincal knowledge is limited but I guess as long as you start a network game the data packets travelling from the server could be recorded?

Well this is beyond any of my darest dreams))) System networking and such level of programming is the darkest matter to me. I'm scared of it :) Arma engine at least is friendly for noob programming and all the higher programming is already done by the devs (and some genius guyz like Jaynus). So I'll stay here to at least be able to guarantee any positive results to you. Diving into higher programming can raise risks of this project get disappeared in it's depths along with me :p

[kremator 1064]

Keeping fingers crossed that you get a chance to work on this.

[DZR_Mikhail 14]

Nothing helped. It seems adding a simple setting flag to my data transfer channels (as one of users advised me at dev-heaven) is not enough. Again, waiting for I0n0s and Jaynus to reply to my help requests.

In short, if I write data to a replay file too fast (24+ fps) it has a major data loss. If I add tiny pauses between writes - the data seems to come complete but the fps drops to 1-2 or less thus useless. It still replayes the battle, but looks terrible and vehicle get destroyed of course (if a chopper at high speed is given a freefly fo these 1-2 fps then it flies uncontrolled...)

[DZR_Mikhail 14]

I gave up trying to optimize the named pipes technique. Cannot deal with those Delphi jungles :mad: Jman from Kellys Heroes is working on the PersistentDB for arma and his project gave me a good idea. I changed my writing a replay file to dumping everything to an sqlite database using SQLite functions in JayArma2Lib.

The result was better than I thought. :eek: First of all - no data loss. Works smooth and seems more reliable and easy for me than these mysterious named pipes. But there was a similar drawback with fps. It registered not every frame I requested, but skipped from 5 to 11 frames per record.

I had no time this morning for further tests and while going at work and Idea came to my mind. The cycle in which I gather data on every unit is linear, I mean, for each unit I do gathering and write to db. Why not making it asynchronous! I mean, Launch a separate "thread" by sending an instance of data gathering script to memory by using [unit, frame] execVM "gather_unit_data_and_write.sqf"!!!

Thus the main loop will not be an obstacle for the rest of the code, it will not skip frames. It will just initiate the execVM rapidly and go on further, while these execVM's will do their job in background.

I thought of it's tricky nature and I guess some data will be written not in the order of request due to game lags or some minor delays while collecting data. For this purpose you see me dropping the frame value to the execVM thus timestamping the portion of data.

Even if the order will be not sequential I can still use SQLite features and later just sort the database by the frame value, and all the records will arrange in timely sequence!

At this moment there are no convenient ways to convert database to aar replay file. Only manual exporting of DB to csv and there selecting it and copypasting to aar file. Playback works, not data corruption or syntax errors and I'm glad :)

So the next step, try to experiment with launching multiple execVM's and look what's happening) There's a huge chance all will work and finally I will be able to continue AAR project.

[Gunter Severloh 3950]

This sounds very interesting, and I like what you have come up with, something we can use for sure for missions.

Thank you for adding this incredible feature to the game, and looking forward to when it gets completed!

This works on Arma2 only or CO altogether?

[DZR_Mikhail 14]

As a backup and as a useful tool I plan to start a project of AAR Lite or AAR Event Log. Here's the project home at Dev-Heaven.net to track it's progress.

This projects is hell of a lot easier than current full fps AAR, but would be very useful for squad leaders.

The idea is simple.

After AARLite is launched all the major important events of the battle are dumped to a database.

You will be able to choose which events to track or create custom events.

I plan to involve After Action Report interfaces from MSO so that any soldier's report will be caught by AARLite and dumped together with all the situation on the battlefield.

Main usage concept

On mission start

• Open dialog
  
• Choose events to capture (default ALL)
  
• Hit start
  

During the mission

• Open dialog
  
• Hit "Save to AARLite" - and current situation is saved as event to AARLite (manual event)
  
• Hit "STOP" to stop capturing events.
  
• Open soldier's After Action Report interface (MSO), supply info, hit SEND and it's saved to AARLite database as AAR Event.
  
• Perform an action which is tracked by AARLite and it's stored to db.
  

At any time after mission

• Launch editor or (mp)mission
  
• Open AARLite dialog
  
• Choose the log
  
• Events list is loaded
  
• Click an event - all the data, markers etc. are loaded and displayed on interface map.
  
• Click any marker for a full info on object.
  
• Hit "Information" and see the textual information about the event and statistical data.
  
• Soldier reports are highlighted differently and contain information supplied by a player as well as global events and full info on the reporting player.
  
• Click generate report and the system will create a readable text version of the event log.
  

I will not spawn offtopic here about this project anymore. As soon as it will be of any interest or usable I will make a separate thread on forums. Now it's too early.

---------- Post added at 02:26 PM ---------- Previous post was at 02:18 PM ----------

This sounds very interesting, and I like what you have come up with, something we can use for sure for missions.

Thank you for adding this incredible feature to the game, and looking forward to when it gets completed!

This works on Arma2 only or CO altogether?

Thanks) Still too early to thank me, because ti still unusable... I hope I can get it completed too :)

It is designed initially to work in Operation Arrowhead only and Combined Ops of course. The reason is that Arrowhead is an enormous and historical extension to Arma2 and it brought amazing scripting and other tools for modders and developers and we cannot stick to Arma2 only anymore, it's frozen and "degrading". And I'm also cannot imagine AAR without CBA and ACE, sorry. And these addons are also developed for OA\CO and frozen for Arma2 standalone.

I think on community request it's possible to filter some code and have some limited AAR version for Arma2 standalone, but I don't think I'm willing to spend time on this.

Edited February 28, 2011 by zvukoper
errata

[DZR_Mikhail 14]

I tried asynchronous recording today. I spawned a separate preprocess function for every unit's data collecting in background. No dataloss, BUT...

But for some unknown reason the main timer (manually coded) SLOWS DOWN! :eek:

While it must count some 50 fps it counts 10-15! And the major problem that palyback is garbled of course, because in playback the timer is as fast as it must be and the whole replay is replayed at a superhigh speed.

I tried both Database dump and Named pipes methods - result is the same.

I will try to find some other syncing method. May be the system\game time is not affected and is not slowing down. I will try to bind this to some more constand variable or research the CBA perframe handler...

I'm losing hope to get it working. :butbut:

[DZR_Mikhail 14]

Well, SickBoy again helped. And thanks to ARMASTACK.info for such a platform for easy knowledge sharing...

Here's the question with discussion http://www.armastack.info/index.php/770/write-data-named-pipe-using-jayarma2lib-loop-without-pauses#q770

In short, There is a very good chance of solving every current AAR problem by implementing the ideas SickBoy (and DeanosBeano of course) suggested.

The other little problem for us is that my current squad state requires AAR in two months for the next Roleplay episode. So I think I will try creating AAR light (mentioned above) and the return to this project and fully dedicate myself to it for the rest of the year.

[Muahaha 10]

Great to hear you are back at this. Eager for your AAR final product.

[kremator 1064]

^^ agree. Gettingsomething out is great thenworkin goon it later would be cool.