[BUG FIXED] RTT Remote - Freezing
-
Sorry for my previous post, it seems that the behavior is very random, what I have been able to verify is that sometimes it works all the time well and others not. For example in the Instant Action mission of AA or in the mission of the Harm when a time passes it hangs regardless of changing from MFD to HAD, TGP, etc. At least that’s what I see, on the contrary in Dogfight its goes well.
PS: I do not see anything reflected in the error log since the simulator does not crash, it is only the extractions of the MFDs. -
Hi
Not sure if that is a real solution but since I have switched to the 32 bit version of RTT it has been working fine - approx 6-7 missions recently.
Also in another thread I found someone suggested to insert this line into falcon.cfg from 4.34 version - set g_bDoubleRTTResolution 1 . Might nothing to do with the issue and recent better behaviour but worth to try. /the lack of this in 4.35 may explain why RTT works well in 4.34 and not in 4.35/Cheers
-
Hi
Might nothing to do with the issue and recent better behaviour but worth to try. /the lack of this in 4.35 may explain why RTT works well in 4.34 and not in 4.35/Cheers
As I do a bit of development around Display exratction from my understanding g_bDoubleRTTResolution has no effect or impact in 4.35 at all.
I have taken 4 image snapshots directly from Shared Memory. These are the images the Extraction tools read and then split in order to Render MFD,RWR,DED(for DED/RWR only if image Rendering is used as F4Sharedmem also has a textual representation of those values)4.35 with g_bDoubleRTTResolution 1 in config
4.35 without g_bDoubleRTTResolution
4.34 with g_bDoubleRTTResolution 1
4.34 with g_bDoubleRTTResolution 0
as Expected the first 3 are identical with a resolution of 1200x1200 only the last one in 4.34 with 4.34 with g_bDoubleRTTResolution 0 is half the Resolution 600x600
So setting it in 4.35 as long as one of the Devs doesn’t correct me has no effect nor anything to do with RTT issues
Not sure if that is a real solution but since I have switched to the 32 bit version of RTT
Same issue with freezing, best tested with the Harm Training mission, turning on HAd and or TGP instant freeze
-
Dear Oak
You are right
It should have no effect and may be there isn’t at all
Most likely the 32bit RTT Client was the solution for me - or mere luck.
Still, another thread found this strange coincidence and seems to work for me. No harm trying.Cheers
Gekko
-
Guys,
It is a BMS issue… You can use as many 3rd party software as needed, that won’t change much…
The randomness of it makes diagnostic very hard but don’t worry, BMS teams are working on it.
For now, I would strongly suggest to turn RTT export off but you can still use your instruments displays using shared memory…
Cheers
-
I did a test and noticed that if I lose the focus of Falcon, for example by clicking on discord I regain fluidity.
I am using Helios extractions.
See my video. Maybe a lead for developers? -
Are you running in full screen mode? I have no export stutters when I set it to borderless (until the export freezes at some point).
-
set g_bDoubleRTTResolution
This option has been removed completely not only from the config, but also from the code. Hence it’s not doing anything in 4.35
-
Let me share my experience too.
I have the same problem no matter if i am running the RTT software or MFDE. When i am in a SEAD mission for example at EMF theatre after a period of time Falcon freezes, both image and sound. I have noticed that the problem has nothing to do with how much time you are in 3D but may has to do when you are sending callbacks in order to hand off a threat for example.
For my convenience i had copied all my setup from the previous version in order to be ready to fly without setting all things from the scratch.
I think that is the problem for my situation. I have putted all the vanilla files in the config folder and that’s it. I managed to be over 20 minutes in the cockpit and verify also that a frigate is able to hit my harms.
So everybody who have the same problem try this and let us know.
-
@Bad:
set g_bDoubleRTTResolution
This option has been removed completely not only from the config, but also from the code. Hence it’s not doing anything in 4.35
This config option certainly affects my install. See post #9 in this thread.
-
This config option certainly affects my install. See post #9 in this thread.
The only way set g_bDoubleRTTResolution could influence is if you had MFDE running in 4.34 running with g_bDoubleRTTResolution 0 resulting in a F4TexSharedMemory image size of 600x600 pixel and then running the same MFDE instance with 4.35 without having the MFDE config options openend and either use the Recover or Apply option or having the BMS Installation Folder in MFDE Performance advanced option still pointing to 4.34. All those would result in using MFDE user.config file in %appdata%/local/MFDEExtractor/Instance subfolder not beeing refreshed and therefore the behavior that MFDE working with wrong coordinates.
In none of those cases adding g_bDoubleRTTResolution to a 4.35 config would have any impactthis is the image MFDE reads from the Sharedmemory and with 4.34 the image could either be 600x600 or 1200x1200 depending on g_bDoubleRTTResolution
So it always includes the HUD and as i explained it’s MFDE reading from the wrong region but the fix for MFDE is NOT by adding g_bDoubleRTTResolution to 4.35 but to let MFDE update it’s user config while running 4.35 -
This post is deleted! -
-
In my case whenever i have this line (set g_bExportRTTTextures) equal with value “1” bms freezes no matter if i am running any extraction tool or not.
Everybody who still have problems try to fly without the export line enabled.
-
There is nothing about it in 4.35 code anymore.
So it is Voodoo … Magic, or placebo.
Give it any name you want, it’s happening.
Regards Oakdesign’s informative reply, I no longer have 4.34 installed, and to be sure that MFDE wasn’t "storing"anything, I uninstalled it, deleted %appdata%/local/MFDEExtractor/Instance, and reinstalled MFDE. Result, the
same as before. What is interesting is that YAME does not require “set g_bExportRTTTextures”, although the fonts are distorted on my Nvidia machine.Anyway, it’s late here, tomorrow I will put together a short video.
-
In my case whenever i have this line (set g_bExportRTTTextures) equal with value “1” bms freezes no matter if i am running any extraction tool or not.
Everybody who still have problems try to fly without the export line enabled.
Technical Explanation is if g_bExportRTTTextures is set to 0 BMS won’t write the image containing to the shared memory. Display Extraction is not turned on or of by either running one of the Extraction Tools. If you have g_bExportRTTTextures 1 BMS will write the the SharedMemory regardless of RTT,MFDE or YAME running. We’ll have to wait for a BMS Update to be released to fix image based Display Extraction. That’s i.e why MFDE or Yame still work for other gauges as they read their date from another region of sharedmemory written by BMS
-
Give it any name you want, it’s happening.
Regards Oakdesign’s informative reply, I no longer have 4.34 installed, and to be sure that MFDE wasn’t "storing"anything, I uninstalled it, deleted %appdata%/local/MFDEExtractor/Instance, and reinstalled MFDE. Result, the
same as before. What is interesting is that YAME does not require “set g_bExportRTTTextures”, although the fonts are distorted on my Nvidia machine.Anyway, it’s late here, tomorrow I will put together a short video.
If you have MFDE installed and have started it set g_bExportRTTTextures 0 but have MFD extraction enabled it will change your config itself. So if you start YAME afterwards g_bExportRTTTextures might have been changed from MFDE even without you changing it
private void WriteBmsConfigSettings() { //FileInfo file = new FileInfo(Path.Combine(_bmsPath, "FalconBMS.cfg")); var file = new FileInfo(Path.Combine(_configPath, "Falcon BMS.cfg")); //Falcas 04/09/2012 if (file.Exists) { var allLines = new List<string>(); using (var reader = new StreamReader(file.FullName)) { while (!reader.EndOfStream) { allLines.Add(reader.ReadLine()); } reader.Close(); } var rttFound = false; var batchSizeFound = false; for (int i = 0; i < allLines.Count; i++) { var currentLine = allLines[i]; var tokens = Common.Strings.Util.Tokenize(currentLine); if (tokens.Count > 2) { if (tokens[0].ToLowerInvariant() == "set") { [color]if (tokens[1].ToLowerInvariant() == "g_bExportRTTTextures".ToLowerInvariant()) { currentLine = "set g_bExportRTTTextures "; if (chkEnable3DModeExtraction.Checked) { currentLine += "1"; } else { currentLine += "0"; } allLines[i] = currentLine; rttFound = true; } else if (tokens[1].ToLowerInvariant() == "g_nRTTExportBatchSize".ToLowerInvariant()) { currentLine = "set g_nRTTExportBatchSize " + udBatchSize.Value.ToString(); allLines[i] = currentLine; batchSizeFound = true; } } } } if (!rttFound) { var newLine = "set g_bExportRTTTextures "; if (chkEnable3DModeExtraction.Checked) { newLine += "1"; } else { newLine += "0"; } allLines.Add(newLine); } if (!batchSizeFound) { allLines.Add("set g_nRTTExportBatchSize " + udBatchSize.Value.ToString()); } using (var writer = new StreamWriter(file.FullName)) { foreach (string currentLine in allLines) { writer.WriteLine(currentLine); } writer.Flush(); writer.Close(); } } else { MessageBox.Show(this, "A FalconBMS.cfg file could not be found in " + _bmsPath + ". Changes could not be made to this file.", "Error", MessageBoxButtons.OK, MessageBoxIcon.Error, MessageBoxDefaultButton.Button1); } } [/i][/i][/color][/i]</string>
-
Same here, the HARM training mission locks up after I go in hot and change targets. This just happened so I can not discern a pattern yet.
-
After several tests I think that I have a solution for my problem at least.
In my opinion i think that in many PCs (including mine) the imaging shared memory can not be handled and this is why the RTT and the game freezes. Even if you edit your Falcon Bms config in order to export the mfds for example when the game feels that this is not possible then crashes the RTT or the game generally. This can be spotted in the User file. When the sim feels that bug then it’s changes by itself the falcon bms.cfg file. The odd thing that I have noticed is that next to these lines “set g_bExportRTTTextures” “set g_nRTTExportBatchSize” the description is missing and the file is obviously unintended changed.
In order to help the sim to deal with the image shared memory i limited the fps in the RTTClient.ini to 20 and I changed the “set g_nRTTExportBatchSize” to 5. Now the exported MFDs have slowest update but they do their job without crashing at all even in a harm mission. Generally i think that the thing the thing that stresses the sim is the quick change of MFDs pages or the TGP image.
All the above are just thoughts and for now for me at least is a solution.
Note that i use the RTTclient x32 with admin rights and in the RTTClient.ini I have also set the RENDER = 2 as suggested above.
That’s all for now. Merry christmas!!!
-
Great finding,
as I have run and tested all Dsiplay Extraction tools always with g_nRTTExportBatchSize 1 so basically in sync with the game FPS I went in 4.35 up only to g_nRTTExportBatchSize 2 as my thinking was:
if the issue is a BMS internal timing with the shared tey memory setting it to half the FPS should be enough.
Apparently not.
I went with a g_nRTTExportBatchSize 10 and was able to have both TGP and HAD on in the Harm Training TE without freezing External MFD.
So now to test how low I can go.Edit: Setting higher g_nRTTExportBatchSize just prolongs the time until a freeze might occur but still occurs