towsim

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…

For demonstration purposes, I installed DCS on a Surface Pro 4 with 8 Gb main memory. The graphics adapter has 4Gb memory. As soon as the sim starts, only black and white is visible outside the cockpit. The only objects visible are white clouds on a totally black background. If a shadow hits an object inside the cockpit it is covered by an opaque, black shadow. Has someone the same problem and solved it probably ?

67 here. Started with VC20 and Blue Max.

Ich habe DCS auf meinem Entwicklungsrechner und auf meinem Testrechner gleichzeitig am Laufen, unter Benutzung eines Accounts. Bei der 1.5… Version habe ich mir eine zweite A10 zulegen müssen um meine Applikationen zu testen. Bei der 2.0… Version konnte ich alle Modelle parallel benutzen. Allerdings habe ich schon lange nicht mehr getestet. Vielleich hat jemand eine ähnliche Konfiguration mit der letzten 2.0… Version ausprobiert?

Im Bild 1 ist die Batterie offensichtlich eingeschaltet und APU Generator und Triebwerksgeneratoren sind aus. In diesem Zustand ist nur das UHF Radio benutzbar. Das soll dem Luftfahrzeugführer bei einem Kaltstart ermöglichen eine Startup Clearance einzuholen. UHF deshalb, weil der westliche, militärische Funkverkehr hauptsächlich über UHF läuft. Auch hier ist Voraussetzung , dass die UHF Box eingeschaltet ist. Die VHF Boxen brauchen mindestens die APU mit eingeschaltetem APU Generator. Vorgehensweise: 1. Am electrical Panel Battery Power On 2. UHF Box linker Drehschalter auf Main 3. UHF Box rechter Drehschalter auf MNL 4. UHF Box Frequenz des lokalen Kontrollturms einstellen Am Intercom Panel 5. Intercom Panel Drehschalter auf VHF stellen 6. Intercom Panel VOLume zeigt nach 12Uhr alle anderen zeigen nach 8 Uhr Das UHF Radio sollte jetzt benutzbar sein. Für die VHF Radios (Battery Power ist bereits ON): 1. Am electrical Panel: Inverter Schalter auf STBY 2. APU einschalten und warten bis die APU Drehzahl 100% erreicht. 3. Am electrical Panel: APU Generator Schalter auf APU GEN PWR stellen. 4. VHF 1 Box: rechter Drehschalter auf TR 5. VHF 1 Box: Linker Drehschalter auf MAN 6. VHF 1 Box: VHF Frequenz des lokalen Kontrollturms einstellen. 7. VHF 2 Box wie VHF 1 Box einstellen. Über VHF 2 kann der Kontrollturm nicht Kontaktiert werden, da dieses Frequenzband nicht von ATC abgedeckt wird. Alle Funkgeräte sollten jetzt normal funktionieren.

Es klingt zwar unsinnig, aber DCS wertet auch die Lautstärkenregler am Radio und am Intercom Panel aus. Sind diese runtergeregelt, werden die Funksprüche nicht durchgereicht. Der Drehschalter am Intercom Panel entscheidet, welches Radio auf PTT (ThrustMaster Mic Forward) reagiert.

To explain the problem of Sticher: The attitude of an aircraft can be described with the three values of yaw, pitch and roll, expressed in degrees. Whereby yaw should not be mixed up with heading and roll cannot be taken as bank. Why? Imagine, an aircraft goes with heading 360, straight and level. In this case yaw, pitch and roll are all at zero degree. If you lift the nose by 100 ° then you cross the 90 ° vertical attitude and finally your nose points a bit backwards. If you analyze this attitude you will find that yaw = 0, pitch = 100 and roll = 0. But your heading would be 180. The magic behind is, how axis turns are handled. The standard for calculations is, first yaw, then pitch and last roll. If the sequence is mixed up, a complete different attitude would be the result. Another fact is, that the axis turns are not done around the X,Y,Z axes. They are done around the U,V,W axes. Where U is the lateral axis, going through the wings (pitch), V axis is vertical (yaw) and W is the longitudinal axis, going along the fuselage (roll). Now the surprise, if you maintain your heading of 360° and lift the nose by 45°, a subsequent roll is done around the lifted W axis (not Y), which has some confusing results. If we take an aircraft, flying straight and level on heading 180°. The question shall be, what values for yaw pitch and roll must be used to bring an aircraft into this attitude. If the standard sequence of yaw, pitch and roll is maintained, one solution could be: yaw 180, pitch 0, roll 0. But there is at least a second possibility: yaw 0, pitch 180, roll 180. Now the special behavior of the DCS values. In regard to the first example (yaw = 0, pitch = 100, bank = 0), as soon as pitch crosses the 90° border, they count the pitch backwards by switching to the second possibility: yaw = 180, pitch = 80, roll = 180, which results exactly in the same attitude. But a motion platform in this case, would almost kill a sim pilot by because the roll of zero switches suddenly to 180°. The only exact math solution would be to evaluate the content of the required 3 by 3 turn matrix, which contains the unique positions of the U,V,W axes expressed in Sine and Cosine. Regardless what yaw, pitch or roll was used. But this is a real tricky process which requires a deep understanding how matrices proceed. I am sorry, that I cannot help for the moment because my job holds me busy for the next time. But there could probably be a math genius in the community, who can solve the problem. To the other problem of side forces: In an exact coordinated turn, no side forces are noticed. Only the G forces are present which are felt as an exact vertical increase of weight. To simulate this forces, a calculation including gravity and centripetal forces are required. An exact simulation of the increase/decrease of G forces is not possible with a fix mounted simulator. Please apologize the length of this article. I had already direct contact with Stitcher in the past. I only want to specify the details for a possible solution.

I cannot make any estimate for the moment. Since I will start in my new full time job as ATC coach next week, I am busy with my facility rating which I have to finalize in a given time period. When this is done, I will make a new time schedule.

@John-John Just did the test under the described conditions and can now confirm a bug. If the Mirage is reentered after a crash, it experiences a frequency mess up. I did not find the reason up to now. It will be solved with the next release together with the F-5E support. Since I can reconstruct the situation, your log files are not needed. Sorry…