TelluriumCrystal/ocap-revived

Directory Not Found Error

Opened this issue · 7 comments

Erdemes commented

Version Info

  • OCAP Version: 0.6.0
  • Arma 3 Version: 2.0
  • CBA3 Version: v3.15.1.200418

Hello, I'm testing the OCAP-Revived in our MILSIM dedicated windows server. OCAP seems to be recording when the mission starts as I can see the OCAP frame messages in the .rpt file. When I stop the recording via the trigger, OCAP is unable to move the temporary .json file to the folder I've defined in the config.cpp. Below is the ocap_log.txt describing the error:

29.10.2020 12:15:19 | Moving SAT7_FAPOVO_301020_LAND_SSS.json to C:/OCAP/data/SAT7_FAPOVO_301020_LAND_SSS.json...
29.10.2020 12:15:19 | System.IO.DirectoryNotFoundException: Yolun bir parçası bulunamadı.
   konum: System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   konum: System.IO.File.InternalMove(String sourceFileName, String destFileName, Boolean checkHost)
   konum: OCAPExporter.Main.RVExtension(StringBuilder output, Int32 outputSize, String function)

I think it may be related to the use of "/" and "". First I tried to specify folder as "C:\OCAP" as it is the default windows directory symbol, in the log I saw the disagreement of symbols such as : "C:\OCAP/data/SAT7_FAPOVO_301020_LAND_SSS.json" then I tried with the "/" but again it's still not working, it cannot find the folder.

My second issue is I can't see the recorded operation on my web server. Although the OCAP wasn't unable to move the json file, I've manually got the json file from the temp folder and I've uploaded into the "data" folder of the OCAP in my web server but web server is unable to see the json files for some reason, my operation list is empty in the webpage:

http://sat7.net/ocap/

You can find the ocap_log.txt in the attachments.

Thanks
ocap_log.txt

Erdemes commented

Second issue about operations not showing in the list is resolved with the path correction in the index.php but now I have new problem which when I click the operation "Error: "http://localhost/ocap/data/undefined" failed to load." error shows up.

TelluriumCrystal commented

Sorry for the lack of a response, I haven't had much time to work on this the past few months. I have almost completed what will essentially be a complete rewrite of the entire capture system, so this bug won't be relevant for 0.7.0. Keep an eye out for when that gets released and feel free to give it another go then.

wishmaster86 commented

Hi TelluriumCrystal

Any news about the 0.7.0 version you are working on? We are experiencing the same issue on our hosting.
We have found that editing the dir to "$dir = '\data';" and the ocap.js file contained hard paths to a localhost.
We have tried chaning this. but are stuck. because of the Windows to Linux filesystem conversion. that is my guess.

Does you new version fix that issue?
if so, when are you going to release that version?

TelluriumCrystal commented

@wishmaster86

So 0.7.0 should fix this issue since I essentially completely rewrote the entire exporter. I have also rewritten basically all the SQF logging code to make the system more controllable and easier to use. However, the data format this new logging system uses is fundamentally incompatible with the old OCAP web viewer. I need to find time to modify that to make everything work together again, and with college taking up most of my time right now I really don't know when that will be.

I wish I had better news, but I just don't have the free time to make much progress with this right now.

wishmaster86 commented
TelluriumCrystal commented

@wishmaster86

All my work so far is on the capture-rewrite branch, feel free to take a look. I haven't pushed it to the main branch yet since I have no way of viewing the output data and therefore no way of testing it. Note that the output file format has been changed to a custom format instead of a JSON that is detailed in the wiki on that branch. See here for more details on the objectives of the rewrite: Issue 5

The exporter .dll, while functional, still needs a bit of tidying up. Specifically, the thread it spawns to handle writing the export file needs some kind of termination condition. That's a pretty minor thing though, and thanks to using multithreading it has pretty massive performance improvements over the old exporter.

If you or anyone you know of has time to try their hand at modifying the web viewer I'd be more than happy to help, I just don't have time to do it all myself.

Erdemes commented

Hello guys,

Any update on the new version? Unfortunately I'm not good at scripting I'm not able to help.