[BUG FIXED] RTT Remote - Freezing
-
-
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
-
Because the problem is within BMS….
-
As promised, a short video demonstrating how the “set g_bDoubleRTTResolution” option will disable, or enable display extraction. On my machine at least.
Apologies for the quality, it was my first attempt at recording video.
-
@oakdesing try to set the antilising setting to lower value. My setting is 2
-
Gents,
Try as much voodoo stuff as you like but as long as an update fixing the code issue is not published, you won’t have a proper fix…
Cheers
-
As promised, a short video demonstrating how the “set g_bDoubleRTTResolution” option will disable, or enable display extraction. On my machine at least.
Apologies for the quality, it was my first attempt at recording video.
Ok now I see. You are using MFDE 0.6.3.0 compiled before August 6 2019 which still reads the g_bDoubleRTTResolution value from the BMS config in order to determine the coordinates. So with your version g_bDoubleRTTResolution 0 assumes to image size rendered by shared memory to be 600x600 or g_bDoubleRTTResolution 1 to be 1200x1200.
With the latest commit as of August 2019 this has removed from MFDE and even MFDE doesn’t use that parameter anymore calculates the RTT areas directly from the values from the shared memorycommit message from latest release
…
-use RTT coordinates from sharedmem (not from config)Most obvious visaul difference to see which version of MFDE is in use
old has still has option for MFD #3 and #4newer one has those removed as well as not relying on g_bDoubleRTTResolution at all
-
@oakdesing try to set the antilising setting to lower value. My setting is 2
1. it’s already clear that there is no workaround without BMS code fix
2. changing antialiasing doesn’t make technically any sense as it would have no impact in sharedmemory data writing -
1. it’s already clear that there is no workaround without BMS code fix
2. changing antialiasing doesn’t make technically any sense as it would have no impact in sharedmemory data writingAfter one hour in the 3d I had a freeze again. So guys you are right but it was worth digging the problem to the bone.
-
Ok now I see. You are using MFDE 0.6.3.0 compiled before August 6 2019 which still reads the g_bDoubleRTTResolution value from the BMS config in order to determine the coordinates. So with your version g_bDoubleRTTResolution 0 assumes to image size rendered by shared memory to be 600x600 or g_bDoubleRTTResolution 1 to be 1200x1200.
With the latest commit as of August 2019 this has removed from MFDE and even MFDE doesn’t use that parameter anymore calculates the RTT areas directly from the values from the shared memoryMost obvious visaul difference to see which version of MFDE is in use
old has still has option for MFD #3 and #4newer one has those removed as well as not relying on g_bDoubleRTTResolution at all
I had no idea there was another version of MFDE available. At least that explains what I was seeing.
-
I just did another testing flight and neither RTT nor komurcu’s app froze for me during this flight (same TE as used above). I know this doesn’t exactly make debugging this issue easier, I’m just adding data points
All the best,
Uwe
EDIT: Using blk52s for what it’s worth
I have the same Issue and in my case I am using Komurcu app. I configured RTT based on: https://www.benchmarksims.org/forum/…l=1#post557243. Also, I used F16 CM-40 and flight a Harm attack and after 10 minutes everything went freeze. Once the FalconMFDServer ( the Ap that works as a server to manage the MFDs) was closed by the system. I read several potential solutions but I understood that no one is conclusive and we should wait the coming of the BMS team with a solution. Am I right?
-
Yes you are correct. You have to wait for an update. All current available tools for MFD display extraction use the same underlying technique to read the MFD Data and as it’s BMS itself that stops providing the data none of the tools using the shared memory can do anything to fix it
Gesendet von meinem SM-G930F mit Tapatalk
-
Thanks for your input.
A clear message and thus we avoid being each one of us going around making a mess in our BMS.
-
It’s a bug. Turn off RTT export in your BMS config and enjoy hours a fun without freezes