riojax

True vs magnetic heading bug?

It is good to hear it. I want to trust HB, and optimizing the JUI is a good way to do it, but don't forget to make an active open communication, fix all privacy/network issues, AV detection, and all other dozens of bug reports like the radar performance and the actual jester skill.

Check the bug reports, as for example, the data sent to id.google.xx is telemetry. Ok, please, next time when you see those problems that can affect the trust, make a public statement with all the research information at the moment that you have knowledge of them. It is not good for the trust to wait several weeks asking for this and only get the response that it is a "false positive" when a lot of trustworthy AV vendors say otherwise. It is not a thing about likening; embedding CEF has a lot of cons too, for example, the huge RAM and CPU usage, and you demonstrated in your F-14 module that all can be made using the DCS UI except the video tutorials and the manual, which are totally optional. It would be great to have a checkbox to disable CEF and not load it on CPU and RAM, disabling the manual and browser.

I can't understand why it turns into a defensive to ask for a truthful, accurate, serious, unequivocal and firm response (as you say in court) and was not my intent; as a customer, I only want a proper research, public communication and fix. Ok, if you are dealing with it, us too, and as you can understand, for us as clients to deactivate the AV is not a fix. Yes, but it was a nasty surprise for some. If you want to embed a web browser in a product that don't need it as a flight simulator, please, communicate it as some clients can decide to no purchase it because don't want to have it. Ok, and thank you. This is an initial proper response, but it is also welcome to research what the VMProtect is doing and why AV vendors are marking it as unsecure, and finally make a proper fix that allows us to use our AV and your product at the same time.

It is also frustrating to have the same response that it is a "false positive" without any technical detail, which is why a lot AV vendors are marking this as unsafe. Privacy is important, and also a basic right for EU citizens, and your product is still sending unsolicited telemetry and data to Google and other third parties as reported here (and do it with the "offline mode" selected and the DCS GDPR-compliant check marked, in a clear violation of it) Fix the privacy issues to be fully GDPR-compliant, and also work on the packer problem detected by AV vendors. This is not a bug like the dozens of pages reported; the GDPR violation is a serious issue.

Right, this is a basic right; independent of whether you want it or not, I don't need your permission. But it is not very good as an official response to a client on a legit question. I think that it is productive to have a good response about why a lot AV vendors are marking this software as unsafe after recent updates. I don't know if it is ED who makes this packer, but my AV detects that it is VMProtect, and I do not trust on this product as equal lot AV vendors.

Are you completely sure that is a false positive? Is this your personal opinion, or is this an official Heatblur statement? Assuming that the original code is clean, how do you know that the used packer that is closed source doesn't inject malicious code as the AV is pointing? Would you maintain these same words on trial?

The bombing table uses Google's Chromium Embedded (libcef) you can probably get this DLL crash looking in the Windows Event Viewer.

And will do it?

Nope, it is enabled with the offline mode selected sending data to id.google.xx It do it exaclty at 70 seconds from the full module load, running and unpaused. Also the past version sent data to heatblur.matomo.cloud and cdn.matomo.cloud and I didn't have so much time to check it in the latest. It is sadly to know it as others support it. No linux, no money. Likely adding a LUA interface it work on linux without problems.

HBUI is a Chromium Embedded Framework (CEF) web app/instance with Google telemetry enabled, and it has a lot problems with WINE (also proton) and Windows <10. Probably your best bet is look for an older version (Compatible with WinXP) on Spotify CDN but probably it didn't work as the API and ABI change a lot between CEF versions. I miss a lot the Jester 1 using the DCS API without loading a full Google browser.

Try to turn off the radar, the current radar implementation is very CPU demandant.

Is it possible to add an option to use a small and compact squared text only interface with a big offset to right/left ?

As I know, yes. By that if HB implement this fix in some way will be better for all.

IDK. I did copy it to Saved Games\DCS.openbeta\Liveries and select the ScarClearWhiteText livery in the rearming window.

Yep, also the G damage as it only breaks wings from 20G and also seems impossible to hung/damage/break the stores.

I have this problem too and I have the global illumination option enabled, and this mod fix the issue for me: https://www.digitalcombatsimulator.com/en/files/3338024/

I have this problem too and I have the global illumination option enabled, and this mod fix the issue for me: https://www.digitalcombatsimulator.com/en/files/3338024/

Same, in my setup is clearly visible, like 1s maybe more. I disabled the "Stick force blending" special option and now is like 300..500ms

Thank you, I gathered interesting info in this post, please review it:

When I turn on the radar, my FPS goes from 60 to 14 due CPU BOUND. My CPU is a 16-core AMD Ryzen 9 3950X, but I did also test it on an Intel i9 with same results (and also the problem that one thread was assigned to an E-Core) This is the top thread usage for DCS with RADAR STANDBY: And this with RADAR ON: As you can see thread 11260 is always using 100% per core CPU on RT priority (as I have 16 cores this is a 6.25% total CPU) With RADAR ON the 11748 is taking 100% also in high priority, also threads 6520 and 8904 + 3784 and 6264 takes 100% for two cores (they are running in the same core) This is the backtrace of threads 11260 and 11748 with RADAR STANDBY: And this with RADAR ON: This is the backtrace of threads 6520 and 8904 with RADAR STANDBY: And this with RADAR ON: This is the backtrace of threads 3784and 6264 with RADAR ON: Also this TID is taking a lot CPU with jester menu closed, probably is generating the jester static and waiting for and event (please, add a special option to disable the jester static)

Fixed in latest OB null

I'd see errors on servers running the main DCS thread at 100% CPU core usage, in this case, the server can't process in real time and sometimes the plane is moving when it must to be static (some people thinks that is a netcode problem when in reality is a server issue)

^THIS.

- Seeker info: Doug Richardson (Janes Missiles and Rockets) in his article “Iraqi heat-seeking Gainfuls found” - Rocket info: me