towsim

I used a trip with a PiMax 8, from Büchel to Wunstorf to get a first impression of the Cold War map. The takeoff in Büchel looked impressive to me because I built this airport a couple of years ago for another simulator in the scope of ATC training. Because Büchel is at the western limit of the map, the details on the ground were limited. Nevertheless, the composition of forests and meadows together with the detailed altitude profile made me feel like I was in Germany. As soon as I came to the east, all the expected details like roads, cities, and railways came into view. In this first version, dead reckoning navigation is not that comfortable. Some rivers end suddenly in the green, and the road network is not fully completed. Landing in Wunstorf showed a detailed build of the aerodrome environment. All hangars were in place with impressive interiors. From the technical side, the computer load (7 years old, 64 GB, NVIDIA RTX 2080 Ti) was within acceptable limits. Only an old error, noticed a couple of updates ago, erased a color from my rainbow. As soon as I move the view boresight, the entire view starts to wobble. My conclusion is that the map is an excellent start. With the announced updates, we can expect more landscape details and additional aerodromes. Hopefully, even my preferred home base Kaufbeuren in Bavaria.

I have the same problems and up to now, no final solution for it. It’s indeed frustrating when performance hiccups affect the overall experience. Let’s break down some of the points you’ve raised: Billboard Management and Background Images: I have identified that billboards, which serve as background images for distant scenery, play a crucial role in performance. Holding existing billboards in memory when the horizon remains relatively stable is a smart approach to reduce unnecessary recalculations. The discrepancy between frame rates with and without head movement suggests that billboard creation during head movement impacts performance significantly. Local System Impact: The issue seems localized to certain systems, as not all users experience it. CPU clock rates alone don’t explain the drastic frame rate drop, ruling out CPU performance as the sole culprit. GPU and DCS Update: The GPU could indeed be a factor, but my observation is, that the bug coincided with a DCS update (specifically the new Cola map) is crucial. ORBX’s complex scenery likely triggered the need for a new function in the DCS image generator. ASOBO’s successful resolution of a similar issue in the Microsoft Flight Simulator highlights the importance of addressing this at the software level. Memory Management: Upgrading system memory (RAM) from 32 GB to 64 GB might help, especially if billboards are being swapped to virtual memory. Moving the page file to an SSD can improve swap times, but it won’t fully solve the issue if the bottleneck lies elsewhere. DCS Solution: Ultimately, a solution from DCS would be ideal. Their expertise in flight simulation software development could address this issue comprehensively.

Meanwhile I got a solution. The reason was a malware attack from an unknown source. Windows defender posted a warning only when the infected module was started. This is obviously the case when DCS was started. Since Windows Defender cannot repair the infected modules, I used AVIRA for a total system scan. It took about 6 hours. Overall there where 59 infected modules. AVIRA did not only quarantine the modules, it even repaired the infections. After that, malware warnigs were history. The reported module were still in place and worked normal.

Yes, today I got the same message for the F15. So I tried to solve the problem with Microsoft Defender. After a total offline scan, I got the same message again. There were several possibilities for actions. I selected ‘Quarantine’ . Results: · The F15E_CPT.dll was removed from DCS. Obviously moved to a Quarantine Folder. · On DSC start the message appears, that the F15E cannot be initialized. After that, DCS worked normal with all other aircraft. · With the latest DCS update, there was a new AV8B_CPT.dll, which does not cause any problem. This is the prove, that the virus ‘GameHack’ or ‘Packunwan’ was hidden in AV8B_CPT.dll, which was overwritten by a new, uninfected version and is now found in F15E_CPT.dll. A question to Microsoft Copilot, what ‘GameHack’ or ‘Packunwan’ means, returned the answer: Win32/Packunwan is a generic detection for potentially unwanted programs (PUAs) that use software packing. These applications can range from being merely annoying to posing a severe threat to system safety. Windows Defender often identifies programs bundled with adware or those without a publisher as PUA:Win32/Packunwan. Examples include software like PowerISO, KaOs packs, or cracked applications. Most of these flagged programs are unsafe, and some users have reported data compromise due to them. Conclusion: The only solution for the moment seems to be to remove the infected DLLs and to accept, theat the related aircraft is not available for the moment. I did not find the source for the infection. It could probably be another application, which starts the infection procedure. But the Defender did not give any information about this situation. With the experience up to now, I am looking for a possibility to copy an uninfected DLL back to DCS. But I have no idea where to find such a DLL.

Thanks for all the replies. In the Wednesday update, a new DLL was delivered for the Harrier. With that, the warning by the Microsoft Defender,disappeared.

Thank you for the reply. I want to make sure, that there is no threat to be expected. I removed the DLL from the folder. DCS runs normal with the exception, that the aircraft cannot be initialized anymore. I hope on an DCS update that makes the aircraft usable again.

I will quarantine the reported DLL until further notice…

Since I installed the latest Office 365, which includes the Microsoft Defender, I get a warning from the Virus & Thread Protection, that the DCS World OpenBeta\Mods\aircraft\AV8BNA\bin\AV8B_CPT.dll has a potentially unwanted behavior. Does someone observe the same message and has probably an explanation for it?

Yesterday, we made another test to use frequency-based voice communication in DCS. We experienced the following with tree members in the group: After the configuration was done, we started the test on the FA-18 radios. On the first trial, we could get into contact on the desired frequency with the exception of one member. We noticed a fluctuating member indication in the “Blue Coalition” menu display. Members appeared in gray and sometimes in bold white. The other two had contact as expected. All members could see the PTT indication in red or green while talking on the frequency. Even the disconnected member could see the PTT activity (to avoid questions, we made it sure, that he was on the right frequency). To avoid interferences with other voice communication software, we started the second test without TeamSpeak in the background. The result was almost the same. Almost means, that nobody could establish contact on any common frequency. Since we had at least contact once in the first test, and we did no change in the DCS configuration, we could not determine any logical reason for this behavior. My question is: Is there any magic configuration or handling we missed? Did anybody experience the same troubles?

Thank you for the reply. Since the taskbar works now and then, I got it in a normal working situation so, that the buttons were available. After a change to 1600 by 900 dimension, the DCS graphics appeared in a 1600 by 900 window, but remained in a 1920 by 1080 resolution. Therefore, no buttons available. In VR mode, the bug could be solved because the VR window on desktop is vertically smaller than the desktop and the VR window reflects the the actual VR view. The taskbar is far away and does not disturb anymore.

I experienced the following situation during a trial to enter a multiplayer server. All worked normal until I reached the point to connect to the server. The connect button was covered by the windows task bar. So, no chance to connect. Unfortunately, under Windows 11, the taskbar cannot be moved to any other position on desktop. Even the windows checkbox ‘Automatically hide the taskbar’ does not work. The taskbar does not disappear. The next idea was to configure a smaller DCS window size so, that the button would not be covered. But the ‘OK’ button in the DCS configuration menu is covered by the taskbar too. How can I get out of this dead end street? In windows 10, I had a similar problem during a VR session. I wanted to switch the oxygen supply switch in the F18 cockpit. I ended on the taskbar. Here I had the possibility to move the taskbar to the top of the screen, which is not possible under Windows 11 anymore. Would it be possible for DCS to catch the mouse cursor clicks exclusively, when the cursor hovers over the DCS window? Or any other solution to avoid clicks on the taskbar?

If you interface DCS from a DLL or even from any external application running on the same computer, the code shown below works very fine. First of all, you need the window handle of the DCS window. This is done once with GetDCSwindowHandle(). The naming "DCS" and "Digital Combat Simulator" is critical because DCS changed the window name and the window class name several times over the years. The handle is used to switch the keyboard focus to the DCS window before any key is sent. In SendKeyToDCS the focus is switched to DCS first with the API function SetForegroundWindow. After that, the key can be sent with the virtual keycode VK_... and the corresponding keyboard scan code. The latter is language dependent because there are different positions for some keys on different keyboard layouts. For the proper function, the key must be sent twice. The first for a key-down and the second for a key-up signal. Between the two signals a wait of 100 ms is inserted (works even with 10 ms). FindWindow, SetForegroundWindow, and keybd_event are windows API functions. KEYEVENTF_KEYUP is a constant defined in WinUser.h. [color="DeepSkyBlue"]HWND [/color]DCSwindow = [color="Magenta"]NULL[/color]; [color="DeepSkyBlue"]BOOL [/color][color="DarkRed"]GetDCSwindowHandle[/color]() { [color="DeepSkyBlue"]BOOL [/color]rval = [color="Magenta"]FALSE[/color]; [color="DeepSkyBlue"]if[/color](DCSwindow = [color="darkred"]FindWindow[/color]("DCS", "Digital Combat Simulator")) rval = [color="magenta"]TRUE[/color]; [color="deepskyblue"]return[/color](rval); } [color="deepskyblue"]void [/color][color="darkred"]SendKeyDownToDCS[/color]([color="deepskyblue"]char [/color]VK_virtualCode, [color="deepskyblue"]BYTE [/color]KeyboardScanCode) { [color="darkred"]keybd_event[/color](VK_virtualCode, KeyboardScanCode, 0, NULL); } [color="deepskyblue"]void [/color][color="darkred"]SendKeyUpToDCS[/color]([color="deepskyblue"]char [/color]VK_virtualCode, [color="deepskyblue"]BYTE [/color]KeyboardScanCode) { [color="darkred"]keybd_event[/color](VK_virtualCode, KeyboardScanCode, KEYEVENTF_KEYUP, NULL); } [color="deepskyblue"]BOOL [/color][color="darkred"]SendKeyToDCS[/color]([color="deepskyblue"]char [/color]VK_virtualCode, [color="deepskyblue"]BYTE [/color]KeyboardScanCode) { [color="deepskyblue"]BOOL [/color]rval = [color="magenta"]FALSE[/color]; [color="deepskyblue"]if[/color](DCSwindow) { [color="darkred"]SetForegroundWindow[/color](DCSwindow); [color="darkred"]SendKeyDownToDCS[/color](VK_virtualCode, KeyboardScanCode); [color="darkred"]Sleep[/color](100); [color="darkred"]SendKeyUpToDCS[/color](VK_virtualCode, KeyboardScanCode); rval = [color="magenta"]TRUE[/color]; } [color="DeepSkyBlue"]return[/color](rval); }

Dear Modders, I need help for the remote control of the pressure setting turn button. What I tried up to now: Export.lua: From devices.lua (included via ‘dofile’) I found the AAU-52/A as index 26 Altimeter = GetDevice(26) From my DLL (included via: warrior = require(‘spinWarrior’) I get the step value to the variable ‘val’, which works reliable. val = warrior.AltimeterSetting() val can be a positive or negative step value, depending on the turn direction. In command_defs.lua I found the only AAU-52/A command as 3000. Therefore, I make the next call in export.lua, text line 51: Altimeter:performClickableAction(3000,val) At this point, LUA detected an error in the call. I inspected the DCS log file and found the entry Export.lua"]:51: attempt to index upvalue 'Altimeter' (a number value) In another project with the A10, this procedure sequence worked very well. Does anybody know, how to get this turn button under control?

Here, what I experienced. Gear setting becomes unreliable and flaps do not work...

Landin Gear Animation Dear ED, please review the landing gear animation in the left MFD. It is not funny when the gear and the flaps do not react in the normal way. Probably a virus in your team?