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?

want to buy... Hi rel4y, sent you an e-mail to mtwsims@tutamail.com 7 days ago an did not get an answer. Are you still in business? Regards, TOWSIM

Unfortunately not...

Today I ran into the following trap: I noticed, that the mouse cursor is not longer synchronized with the screen resolution. To reach a specific button I had to click a position right of the shown button. The first idea was, that the selected screen resolution in the options menu does not match the physical screen resolution. So, I started to play with the different resolutions. Now the trap. By surprise, I configured a screen setup, where all the important buttons are positioned right outside the displayed DCS screen. The most important button, the ‘OK’ button in the options menu, is not longer available. With other words, I cannot store the selected values nor revert the last made changes. Even the normal way to end the program is not possible. The entire program is not usable anymore. What I tried out so far: I searched for a specific LUA file which contains the faulty resolution. No success… I renamed the ‘Config’ folder in saved Games to force the use of the default ‘Config’ folder with the old, default values. No success… I renamed the ‘MonitorSetup‘ folder and started a ‘Repair’. I got a new ‘MonitorSetup‘ folder but the error remained. My question is, is there any black magic available to set the resolution and aspect of the DCS opening screen? Thanks in advance, BOSSHOG

https://forums.eagle.ru/showthread.php?p=3189705#post3189705

For those, who have troubles with the HUD visibility against a white background, even seen in VR. I think, I found a solution for the HUD visibility, as long as DCS does not solve the bug: Instead of changing the color values, we have to suppress the alpha functionality. For the A10C: • Open the file C:\Program Files\Eagle Dynamics\DCS World 2 OpenAlpha\Mods\aircraft\A-10C\Cockpit\Scripts\HUD\Indicator\HUD_definitions.lua. • Set all definitions containing ‘additive_alpha’ to ‘false’ For the M2000: • Open and edit the following files C:\Program Files\Eagle Dynamics\DCS World 2 OpenAlpha\Mods\aircraft\M-2000C\Cockpit\VTH\ HUD_definitions.lua. C:\Program Files\Eagle Dynamics\DCS World 2 OpenAlpha\Mods\aircraft\M-2000C\Cockpit\VTH\ HUD_base_appr.lua. C:\Program Files\Eagle Dynamics\DCS World 2 OpenAlpha\Mods\aircraft\M-2000C\Cockpit\VTH\ HUD_page_base.lua. • In the files, set all definitions containing 'additive_alpha’ to ‘false’ After that, you will see the HUD as it was before the update. Before you make the changes, create a save copy of the mentioned files. It is even expected, that the modified files will be overwritten with the next DCS update. It even helps to set the Gamma slider to a lower value to avoid the extreme misty air condition which causes the white background along the horizon.

Hi guys, I am sorry for answering that late. I am bound to the Weekends for private activities. If you you have troubles with the current version, please have a look to the following directories: C:\Program Files\AriesWings\PRCL\ApplicationData And to the Directory, where you started the Installer. Both directories contain a HTML log file. If cannot find a logical reason in the reports, you may mail the log files to support@ariescon.com. I will have a look to it. Sorry…

So, what I found out so far: With the latest version, TeamSpeak changed the entire directory structure for plugins, which is not compatible any longer with Aries Radio. Even the API internals have changed. Since the TeamSpeak API manual is as thick as the cookbook for hot water, it would take too much time for the moment to convert the software to the latest version. Sorry…

Sorry, I did not check the latest TeamSpeack versions since Post 1308. Nevertheless, I will have a look to it. I will post the result here…

Schaut mal im SetUp nach, ob die Achsen von anderen Devices zugemüllt sind. Das passiert regelmäßig bei neuinstallierten Flugzeugen.

Sorry for answering that late. Christmas stress. After reviewing all the symptoms, I came to the conclusion, that there must be something wrong with texture transparency. All the shadows, even in the cockpit are opaque. The outer scenery is always covered with mist of different strength, which can be a transparent texture or a fog function in DirectX. Since we have no mist or fog in a cockpit, all the cockpit scenery is displayed as expected. As long as no shadow covers a cockpit object. It does not explain the source of the bug. I assume a bug in the DirectX layer which must be made especially for the Surface 4 GPU. The technical description of the i7-6650U CPU does not specify, that it shares graphics memory with the main memory area. The CPU and the embedded GPU can have 32 Gb each as maximum. DCS seems to handle the Fog function correct, because it works on other computers. So, I will have a look in a Surface 4 Forum. Probably somebody else observed a similar bug. Thanks for all answers…