towsim

Yes, this is planned. But it depends on the standards used internally with the Hawk. We need specific radio interfaces of a model available through clickableData.lua and devices.lua.

You experience the crash on the receiver side. That points to the Horizon bug in version 1.973. The Horizon is calculated every time a voice package arrives. Before you start the communication within a mission, open the dialog in TeamSpeak: Plugins/Aries radio/Radio Communication Quality In the dialog press ‘Game Master’ to get the right to change the configuration. Now unpush the Horizon button. As last action push ‘Send’ to make the new configuration active. Be advised, the dialog is available only during a running mission.

Chromium is right. The DLL, producing the Aries panel, is still connected, even if you disable the Aries DLL in TeamSpeak. You find the right function in the TeamSpeak menu under: Plugins/Aries Radio/Eport.lua entry on/off. Unpush the 'Connect' button to disable the entire Aries software in DCS.

Sorry for answering late, but yes, the eavesdropper will have a hardware PTT.

The normal user (non administrator) access rights for the registry are: HKEY_LOCAL_USER read/write HKEY_LOCAL_MACHINE read only Unfortunately, all important setup data for Aries are in HKEY_LOCAL_MACHINE. We plan for version 2.0 to migrate to HKEY_LOCAL_USER to avoid these troubles. I did not find a way to change the access rights programmatically. Therefore, there is no way for the moment without administrator rights to use the software.

It seems, that the C-101 is in an early development state. As soon as the standard devices are available, Aries will support the C-101 automatically. Beside the radios, we will even support the IFF/SIF for our ATC/GCI radar software.

@Looney Thank you for the good news. It let me sleep relaxed last night.:)

Yes, that is what I mean with selecting a radio. But I had a second look to the issue and found a real bug in the key activation. You can circumnavigate the situation if you set the checkmark: ‘Radio Keyboard Control for Clickable Cockpit’ In the configurator. The bug will be solved with the next release.

You obviously did not select the radio . The radio must be selected first with the key or button you use even for aircraft simulation. To get over the fright, I tested it out. It works normal as desired.

I stopped playing E-Guitar already 1971 when my kids were born. The reason was the music scene at this time and later and the order of my wife. It made me cry. Instead of playing my guitar I started software development. It is not that noisy. But back to 5.1. I cannot produce the error in my development environment. It all works fine, even with 5.1 settings. So I am a bit lost for this bug…

Thank you, valuable information.

To describe it more clear: After a mission start a dialog is available in the TeamSpeak menu: Plugins/Aries Radio/Radio Communication Quality Push the ‘Game Master’ button to get the control over the quality setting. Unpush the ‘Horizon’ button in the lower row Push the ‘Send’ button to publish the new configuration. The handling of the quality dialog is described in detail in the Radio User Manual on page 25. Unfortunately you have to do it for every new mission start. The horizon Bug is already solved in our internal version 1.974. Even the quality configuration is stored so, that it needs not to be repeated for every mission start. Version 1.974 is already delivered to our beta testers.If no issues come up for the rest of the week, we will deliver this version as bug release next week.

A combination I would assume is, that Common PTT was activated. In this case the ‘PTT + select Radio Box 1, 2 and 3’ act as radio select only. To start a transmission you have to select the radio first (the yellow LED is on) then push the button to talk you have defined for common PTT. Another possibility is, that Voice Activation was selected accidently in the configurator, but not in TeamSpeak. In this case, manual PTT is not recognized and the entire transmission is suppressed. I hope, it is not a Cyrillic character set issue.

@Chichco The button number is a display issue only. All vendors start the numbering with 1 but internally the numbering starts with 0. They are afraid, that the users could be confused if they see the number 0 for a button. The numbering you see in the configurator comes directly from Direct Input and these numbers are expected by Direct Input if a device is installed. So actually, no translation is required. You can test this, if you select the fire button of a joy stick. The fire button is standardized the public number 1. But it is internally handled as button 0. And this is what you see in the configurator.

@effte Aries radio is not server dependent. Only the clients must have Aries installed. This applies to TS Servers and Game servers.

Since these two functions are handled on the receiver side, it can be implemented. You can expect it with version 1.976 which is already in the queue.

@Baltic_dragon We observed a similar error during development tests. It is probably caused by a “ghost rider”. A ghost rider is a function with erratic behavior. It overwrites data anywhere in memory . The target location depends on your personal memory layout. Therefore it causes different effects on different computers. In version 1.973 we have a known error in the horizon calculation which behaves like a ghost rider. As I wrote in a previous post, disable the horizon calculation in the communication quality dialog.In addition you should disable the protocol creation in the configurator. If it does not help, follow HMA’s suggestion to reinstall the software from the scratch.

The function is already implemented in the yesterday’s internal beta release.

To all Aries user, during the tests of our internal beta versions we found a bug, which could be the source of instability and bad receiver quality on short distances. The horizon calculation has a bug in angular calculations. Since the horizon limitation is not that important for the simulation, we recommend to switch off the horizon feature in the communication quality dialog until a new version is available. It would help us if the users, who had stability troubles, would report here in if ‘horizon off’ enhances the stability. Sorry…

@NeilWillis I have dug deep in my source code to find the reason for your problem but had no success. Does the problem still exist?

@Ramstein I assume, you are using version 1.973. Start the configurator program (ARD) from your desktop. Set the checkmark for “Enable Protocol Message File generation (HTML)” Push “Save” then “Exit” Start a DCS Session with TeamSpeak up to provoke the crash. Now you should find the following protocol files: \DCS World\AriesWings\logs\AriesAirborneRadio_log.html and C:\Program Files\TeamSpeak 3 Client\plugins\AriesRadio\AriesRadioLog_log.html On a Teamspeak crash you should even have a DMP file at: C:\Users\[your user name]\Documents It should look like ts3_clientui-win64-1407159763-2015-02-08 14_42_23.734054.dmp Please send all three files (if present) to support@ariescon.com. I will try to find out what is going on.

The presets in the AriesAirborneRadio.ini are leftovers from one of the first Aries versions. They are not read correctly into the system. If you change the channel with the cockpit selector then you get the value from the Aries presets. If you change the channel out of the Aries panel then you get the value from the UHF_Radio.lua.This is a confusing situation. Whatever the Aries panel shows, the cockpit box holds the frequency from UHF_Radio.lua . This is important to know if you contact any ground unit for service. DCS has obviously no standard for the preset frequency definition. The UH 1 seems to be an exception and a change in the UHF_RADIO.LUA works. Some other Aircraft/Helicopter can be configured with the mission editor.But I am not the omniscient LUA guru. If someone knows how to configure the presets in any LUA file for the different models, I would integrate it in Aries Radio.

I will have a look...

It is an automatism. If you click the Aries Window to change the frequency, the focus is forced to the Aries Window by the operating system. You need to have the focus to get the mouse click message to the Aries message queue.It is up to the user to suppress this situation by hiding the Aries window. If the widow is switched off, no focus change caused by Aries will be expected.

DCS is pretty stable since version 1.973. Only TeamSpeak seems to have some trap doors. I am working on it. On JayPee’s stimulus, I am thinking on a system which separates the logic between DCS and Aries. Up to now it can happen, that DCS honks in the jungle of Aries threads. Especially at mission end. If the connection is simplified down to a data transport only, it could enhance the stability.TeamSpeak is another business. It is not made for radio communication. The entire frequency management has to be done with black magic. This is always a potential source for bugs. If I would find another VCS, which supports voice packages with position information marks, I would change over.The Alt-Tab process change is mostly impacted by DCS itself.The window focus and the Z-order management of DCS is not predictable. To take over the focus control is like walking in a minefield. So Aries takes care only for the situation when the Aries Window is clicked. It pushes the focus back to DCS thereafter. Otherwise, all devices, like joystick, throttle.. would be disconnected from DCS. It keeps complicated. But I like it to fight.