towsim

The problem is not that easy as some people believe. TS has some big advantages and some big disadvantages. The latter is held partly transparent to DCS users. The first thing is, every multiplayer group needs a communication server. It is necessary, because the voice and data package exchange over the internet cannot be handled by only one server for all groups. A com server has to be up all the time to be available for the users. This implies, that it cannot be bound to a local DCS application.I would not believe, that DSC offers com servers for each multiplayer group in the internet. An advantage for DCS users would be an integrated TS client in DCS. It should offer the same service we got used to, like meeting rooms security management and more.The frequency management could be done internally and would be more reliable because it would be developed directly by the wizards of DCS.The existing mods on the market, like Aries Radio and TARS, do exactly the same with the only one difference. The TS client has to be started manually beside DCS. I admit, it is always an unsafe feeling if a mod is installed which does not belong to DCS basically. You always cross your fingers and hope, that no software change was done anywhere in the background. And even the installation process is too difficult for some users. But what are the disadvantages of TS? TS is used for almost all telephony services but does not support radio communication technology. What we need and do not have in TS is: Frequency management Needs a huge internal administrative effort to control non marked voice packages belonging to different frequencies. Frequency block out and interference Can be done by a TS mod, but difficult. (Easy for DCS) PTT function Fortunately build in Type specific voice degradation Can be done by a TS mod, but difficult. (Easy for DCS) Type and situation specific background noise Can be done by a TS mod, but difficult. (Easy for DCS) Quality loss by range and output power Needs additional data exchange (which is not supported) to calculate the distance between transmitter and receiver.(Easy for DCS) Quality loss by terrain Terrain masking (Line Of Sight) can only be calculated with terrain information from the simulator.(Easy for DCS) All that can be done by external TS mods like it is done by Aries Radio. But it is hardly black magic because there are functions used which are not meant to be used for data exchange.Therefore it is not optimized for that purpose. The other impact is, that you have to keep track of unreported software changes in DCS and TS which can you drive nuts. From my point of view, the most effective way would be, to bring Eagle Dynamics and TeamSpeak together and let them discuss how the API can be extended for DCS purposes. Then DCS should develop a build in TS client which supports radio communication in a optimized way. Developing a complete new com server and the required client software is absolutely waste of time because TS is already there as base and works rock solid. Furthermore, TS has already a possibility to create custom servers and client software from the scratch.The small disadvantage even here is the limited support of radio functionality and that own developed clients cannot communicate with normal TS Servers and vice versa. But I am afraid, that DCS does not hear our yammer. It is quite comfortable and cheap for them to let third party developers do that work. I hope, I could describe what is behind the users simple push of a button.

I am working hard on that. We noticed yesterday the crashes in multiplayer configurations. It does not appear in single player mode. As soon as I locate the bug, I will post a new intermediate version to be used until version 2.0 is released. BTW: We found out, that User Account Control (UAC) prevents inter process communication, which is used extensively in Aries Radio. We recommend to switch UAC to the lowest level if possible. Otherwise some features of Aries Radio will not work. The new version 2.0 will compensate this issue so that it works with all UAC levels. Regards Mike

Since version 1.2.8 (normal and Beta) a very often observed, but never solved bug came up again. As soon as 'Multiplayer' is selected, the entire GUI is displaced so that some important buttons cannot be reached.Since my hardware was not changed between the updates and version 1.2.7 worked without this error on the same machine in parallel, I assume a change in version 1.2.8. Could someone explain how to circumnavigate this situation? It is really annoying if all other players have to wait until my screen works normal after endless trials to select 'Multiplayer'.

Please, be patient. I accepted too much new features. This takes time...

Sorry, my fault. Here the correct link... http://www.ariescon.com/AirRefuelingforBeginners.pdf

http://www.ariescon.com/Air refueling for beginners.pdf

Thanks for the response. I had a short look to the source code of AutoHotkey. It is really a mighty tool. What I found out is, that the module, which sends keystrokes, uses the same procedures as I use in my software. This confuses me a totally, because shamandgg obviously uses AutoHotkey with success. I will examine the source code more precise. If it works there it should even work in mine.

I did not use SendKeys up to now. I used keybd_event and SendInput, where the latter is the newer API function. Both methods go down up to the keyboard interrupt handler and synthesize keystrokes. Windows handles the methods in the correct way and sends the WM_KEYDOWN and WM_KEYUP messages to DCS with the correct parameters. My spy module, which is linked to the DCS message queue, reports the reception and the correct parameters in the messages. But DCS, as application, ignores the messages. They are not processed. My assumption is, that DCS goes another way to the keyboard buffer. A lot of games do that to shorten the time between a keystroke and the reaction of the application.

I plan to offer a simple method for a button to keyboard configuration in the Aries Radio Software. Since the community uses all kind of joysticks and throttles, I was looking for a 'universal' solution. This can be achieved with Direct Input , with the Widows API and some dirty tricks like Queue sub classing. But DCS is even uses some tricks which avoid to catch the control over the keyboard. I hoped, that anybody did the keyboard thing already. So, if not, fate...

Thank you for the info. That is exactly what I want to do. But it is still plan B.I look for a possibility to inject key stroke programmatically into DCS. The button filtering incl. modifier is already done in my DLL. I thought on TARGET because it enables at least the HOTAS Warthog to produce Keystroke which are recognized by DCS. That is what I could not get to work out of my DLL.

This makes sense. I got an error message from TARGET during the test run. It reported, that the requested device cannot be found and stopped the script. It referenced an internal device name which was not found. The script was taken from the documentation without modification and should work. The compiler did not report any error. Strange...

If I say modifier, I mean a combination of device buttons. In this case I used the pinky paddle as modifier and the bomb release button as trigger. Before I answered, I checked the TARGET software again and found a description , which obviously fulfilled my requirements. Before I started to change the example code, I made a test compile to be sure that the procedure works basically. The result after a test run was a disaster. All connected Thrustmaster devices were disconnected and could not be reconnected again. It was necessary to reinstall the entire driver software for all devices and to use a strange procedure to get the bulk drivers to work. For the MFDs I needed to start a repair by windows in addition to the reinstalled new drivers. So finally, as long as I do not know what caused this destruction, I cannot use the TARGET software. But this is not the kernel of my request. DCS does not offer a possibility to connect device buttons to the function keys shown in the Com menus. I wrote a small driver in a C++ DLL which catches the joystick buttons and filtered the required combinations I want to use. In this case the pinky paddle (button 4) as modifier and the bomb release button (button 2) as trigger. Once the combination is recognized, I try to send the keystrokes to DCS. As I stated before, the keystrokes caused the right messages in DCS . I observed WM_KEYDOWN and WM_KEYUP in the DCS message queue on each keystroke sent. But DCS does not process the keys. If there is basically a method to inject keystrokes into DSC that would be a real advantage. I plan to offer such a configuration in my radio software.

Question: Did someone ever manage a simulated keyboard input into DCS out of a LUA script or a DLL? I want to initiate key strokes like F6, F1 (request rejoin) by a single push of a joystick button. I know, for the Thrustmaster HOTAS there is a possibility for a TARGET script. But the script does not support modifiers like Button 4 + Button 3. What I tested so far is the normal windows API with Keybd_event() and faked messages WM_KYDOWN, WM_KEYUP to the DCS message queue. Both methods are recognized in the DCS message queue. I observed this by sub-classing the DCS message queue. But the sent keystrokes are not processed in DCS. DCS obviously uses a secret method to evaluate keystrokes. Every solution is welcome...

Up to now it is definitely not working. It will fully work with third party extensions like Aries Radar. The IFF/SIF outputs will only be visible on the radar screens as secondary symbols and ident flashes. A small cockpit visual and audible feedback will be the mode 4 ping at the moment when the transponder is interrogated by a valid mode 4 signal. If someone is interested in details, he can download the IFF/SIF description from: http://www.ariescon.com/exchange/IFF_SIF.pdf

The results are usually given in radians. To get degree, multiply the result with 57.2957795131. The factor comes from 180.0 / PI. As far as I know, the access to local plane data are only possible via export.lua functions. I never could get it with any MIST function. But I am not a MIST specialist. Via export.lua: local o = LoGetSelfData() -- the ownship data set o.LatLongAlt.Lat -- Latitude in degress o.LatLongAlt.Long -- Longitude in degress o.LatLongAlt.Alt -- Altitude in meters MSL o.Heading -- Heading in radians o.Pitch -- Pitch in radians o.Bank -- Bank in radians

It is possible, but you will feel the latency. It is not that much a visual thing. Your inputs with a remote stick feel like with a rubber band compared to a normal input.

The radio panel you see when you are in the spectator mode is normal. DCS does not send a specific signal when starting a multiplayer mission. In the spectator view, a signal is received, which is used as mission start in single player mode. The consequence is, that Aries Radio assumes a CA vehicle being active because the mission was obviously started but no position reports are received. At the moment, when the server really starts, the position reports for a real aircraft are received and Aries Radio changes to the right model. This is confusing, but the only method to pass the startup sequence. This afternoon we will do an additional test session with the new information received. I will post the results as soon as possible.

I got the same information from the Italian wing AVMI. Now I think, I have to accept that there is a bug. The thing is, I cannot produce the situation. All tests I did worked perfect. Could you please check, that the radios are powered and switched on correctly? There is a known bug, if you are in a cold and dark cockpit. In this situation there is not frequency filter active.

The attachment contains three files necessary to run Aries Radio together with TeamSpeak 3.0.14. It does not run with earlier versions of TeamSpeak. Proceeding 1. Update TeamSpeak to version 3.0.14. 2. Exit TeamSpeak . 3. Copy AriesRadio.dll to C:\Program Files\TeamSpeak 3 Client\plugins 4. Copy AriesRadio.luac to \DCS World\AriesWings 5. Copy AriesAirborneRadio.dll to \DCS World\AriesWings Version 1.9 is an intermediate release which is not tested extensively. If you experience errors, please report it to support@ariescon.com. Aries19.zip

Only to show how it is specified in real air traffic, not to know it better: Configurations for taxiing is regulated in almost all wings in the LOP (Local Operating Procedures). It depends on the outside air temperature first. The commander may decide 'open canopy' from 25 Deg C on. But the most important reason comes from the technical side. Most canopies of the fighter jets are unsecured in the open position. The actuator mechanics are not designed for absorbing shocks which can be experienced during taxi procedures. The Tornado, for example, was additionally secured with a strut, mounted manually as soon as the canopy was in the open position. But I have to admit, it's simply cool to taxi with the canopy open.

I found a solution. Tomorrow night we will test the version with the 10th Gunfighters. If no issues come up then I will publish an intermediate upgrade as version 1.9 on Tuesday. Version 1.9 can only be used with the latest TeamSpeak version 3.0.14.

Problems with TeamSpeak The new TeamSpeak version includes some significant changes with version 3.0.14. What I noticed is, that the client SDK was deleted from the package and the new version does not accept the AriesRadio.dll anymore. Since I cannot adjust the software without a valid SDK , I recommend not to upgrade to TeamSpeak version 3.0.14, if Aries Radio shall be used. Sorry, I am looking for a solution...

Yesterday, I did some additional tests to verify the beacon list. The beacon I used was Lazarevskoe (LA) on 307 kHz. The received Morse code was that for LA. The positive surprise was that, what I found. Eagle Dynamics modeled a NDB antenna exact at the beacon's location. I really love these details. To motivate other users to check out the beacons, I supplemented the beacons list with a description of the procedure, how to use the AN/ARN-83 as navigational device. The new document can be downloaded as http://www.ariescon.com/NavigationalAids.pdf. But there is still a missing color in my rainbow. As you can see in the example for a cross bearing I used in the document, the two beacons used are in a distance where you would never receive a signal in the real world. Especially the second beacon known as Beslan inner Marker is a low power NDB used for marker locations. This shows, that Eagle Dynamics did not limit the beacon reception range. This is a disadvantage while tuning to a selected beacon, because all frequencies are received at all positions in the simulation area. To find the right beacon on the right frequency is sometimes impossible. But nevertheless, have fun.

As promised before, the topographical map for the DCS simulation area is done in version 1.0. It includes all supported aerodromes and navigational aids as well. Al fixes are listed in the document I posted before. Since all the Nav Aids are computer generated from beacons.lua, I had no possibility to check the consistency. The only check I did, was to place a self made NDB at Sochi aerodrome and made a successful bearing with the AN/ARN-83 in a UH1. So I can say, the beacons.lua has a valid content. The other potential error source is the translation from Cyrillic to western character set. It may be, that the Morse code in the labels do not match to the audible Morse code if the beacon frequency is tuned in. Therefore it would be helpful to report any experienced mismatch to my support e-mail address: support@ariescon.com I will incorporate the report immediately. The map can be downloaded free from: http://www.ariescon.com/DCSnav.jpg The map has a size of 22.5 Mb and the resolution is 16384 x 9474.

The attachment contains a computer generated list of all NDB and VOR navigational aids supported by DCS. All fixes will appear at the given location in the navigational chart prepared for the GCI system. Marker beacons are not included because they are used mainly for ILS and have a limited power output. The document is mainly for the support of helicopter jockeys. NavigationalAids.pdf