towsim

Yes, I assumed a typing error. But today I noticed, that the file was deleted on the web server. It is now available again under http://www.ariescon.com/ManualInstallationGuide.pdf

Up to now it runs with the latest version and even with the older versions. But I would wait on the version 2.0. It will be published soon. V2.0 contains a lot of features to make the radio com as realistic as possible in regard to frequency band, range, terrain profile, altitude, emission power and type dependent background noise. It even can be used in non windowed mode and the radio panel, ILS, TACAN and IFF/SIF can be moved to an external computer in the LAN. Regards Mike

Here a quick impression of the coming GCI radar application (under construction). It was possible to generate a topographical map as OGL object, made of 1.2 million triangles. The image shows the radar, configured with the code table, range marks, the compass rose, the window in window (Sochi) and the topographical map. The map is not useful for controlling purposes. But it provides important information of the environment around a target area. It will even be used for preflight planning to show flight plan tracks and target objects. The map can be switched on and off and covers the entire simulation area. In difference to normal maps, the map made by Aries Wings is adapted precisely in 3D to the terrain profile of DCS. The horizontal resolution is 30 m and the vertical resolution is 1 m.

If the path problem cannot be solved, I would recommend to follow the Manual Installation Guide. You can find the Document here: http://ariescon.com/ManualInstallationGuide.pdf

Position_vec3 = YourObject:getPoint() elevation = land.getHeight{x = Position_vec3 .x, y = Position_vec3 .z} now you can subtract the elevation from your position z value.

We just came last week to this problem. So I did three test runs with 4 MK82 in CCRP mode out of 13000 ft AGL. The target approach was exactly the same from east to west in all tests. I tried to follow the ASL as exact as possible. The attached file contains three text files containing the bomb scores for each run and a JPG showing the impact locations as result. If someone has an explanation for the results (except, that I am the worst pilot around), please post. LASTEtest.zip

@HiJack Sorry, could you specify the mismatch? I don't find it...

If you have control over the turn sequence then start with pitch followed by roll. You obviously turn around X and Y instead of U and W. The turn sequence and the axes used are the major reasons for confusion.

Here a first result with a 8 kHz band pass filter. It actually filters only the frequencies above 8 kHz. The lower frequencies are untouched. The techniques used is held very simple to avoid a complete Fourier Analysis. We are still in the tuning phase. UH1_8kHz.zip

You are right. This effect is hard to simulate but I will have a look. It is mainly caused by the use of older radio system. The transport of voice was limited to 8 kHz max at the top. As a result, the listener could not distinguish between the sounds of 'S' and 'F', because these two spoken letters need frequencies far above 8 kHz to be clearly recognized. Therefore, one of the first things a pilot and a controller gets instructed is the use of specific pronunciation for often used words. One example is the number three. In radiotelephony the number three has to be pronounced as tree to avoid the 'th' at the begin. Since TeamSpeak basically samples with 48 khz , the entire voice package has to be feed into a Fourier Analysis to filter the Frequencies above 8 kHz. I will look for a acceptable possibility in regard to calculation performance. If I find a band pass filter, I will build it in.

Aries Radio already covers most of the features: Individual volume control for each radio box. Radio box assignment for left or right headphone. Distance and altitude dependent energy degradation with white noise background and connection interrupts. Transmission end click. Frequency interference. If two parties talk at the same time on a frequency, all other listener will hear interference noise only. Type dependent background noise. This feature was too weak in the first version. It was not audible because of own engine noise. It will be adjusted for the version 2.0. For version 2.0 in addition we implemented terrain masking. It causes connection interrupts if the line of sight is cut by mountains or similar objects. In addition we will have a audible white noise background on all frequencies. So most of the different audible modification are implemented from what I heard daily over 30 years. If I miss something, please let me know. The new version is not released up to now. Additional features could probably be added. Regards, Mike

If someone wants to prepare for the usage of IFF/SIF in DCS, he can download a preliminary manual explaining the technology and the procedures to be used. http://ariescon.com/exchange/IFF_SIF.pdf

There are a lot of news. The next radio version is almost done. It was a conceptual change to offer a clean interface over a LAN, not only for radios, even for additional gauges up to the possibility to control an aircraft remotely from another computer. For the next version the radio, IFF/SIF, TACAN and ILS (if the aircraft is equipped) will be shown in a complete independent window, which can be started on any computer in the LAN. IFF/SIF is included because of the coming GCI radar. IFF/SIF will be an integral part in the radar procedures. The additional display of the panels is not mandatory. The radio will even work without the window. This is the possibility to use Aries Radio and DCS in non windowed mode. The open interface even allows to connect a smart phone via WLAN to control the radio. But this step, for Android and Windows Phone, is still in the planning phase. The attached pictures show the new independent panel window and a first impression of the GCI radar. The radar mode displayed is a combination of raw video target display and secondary radar display. The antenna is located at Sochi and has a range of 60 NM. Terrain masking is supported in dependence of antenna and target location. For the moment, all supported aerodromes in the simulation have an antenna at their aerodrome. They can be selected for use out of a menu. The entire target display is in strict dependence of the antenna used. Secondary radar uses real interrogation of targets. Even mode 4 is supported. The aircraft with an APX72 system onboard receive a visual and audio 'ping' if an interrogation is answered under mode 4 conditions. The radar has an integrated radio communication and is not in any dependence of DCS . The next step is the release of Aries Radio V 2.0. The GCI Radar will follow short after it.

It´s unbelievable, I have the real stop watch on my home cockpit panel. But yours looks simply better than mine.

@ Yurgon I have to admit, that my knowledge could be antiquated as you can see with may banner and avatar. The question is, what reliable information can be forwarded to a pilot with a minimum interpretation procedure expressed in time. I can remember situations when my ATC radar showed me an enemy mass attack while it was only a bird flock interpreted by my digital target extractor. Or a helicopter was overtaken by another object undercutting the separation minima when it turned out it was overtaken by an ICE. The difference from that what the engineers praised to the real usage was very often a surprise. Nevertheless, I appreciate it if you found the usage in the Falcon very effective. Regards, Mike

An airborne radar, directed to the ground , makes no sense. The only image the pilot would see is a lot of ground clutter which makes the expected targets disappear. The reflected energy cannot smell metal, wood or human beings. The only information received is reflected energy with a continuous changing amplitude. For some extraordinary objects like buildings, towers or bridges, the pilot would recognize the type. There is no chance to see vehicles or persons in an average modeled terrain. Another case is the usage against flying objects. There is no other background which causes clutter on the screen. However, even here there is no possibility to recognize the type of object on a simple analog screen. Therefore the usage of the TGP is way more effective. An airborne radar can be compared to a TGP with 100 by 100 pixel resolution. In the past, the reconnaissance fighter like F4 used the so called side looking radar. It produced a black and white image on which the terrain was shown like on a picture. Even here, it was difficult to see small object. The dream of a radar engineer is to produce a screen like the TGP offers. The attached picture shows a pilot flip chart for night low level flying. The right side on the map shows the radar picture for the current leg. It can be compared to the current image on the radar screen to support the orientation. So someone my try to find any interesting object on the radar picture.

I hate it to admit, but the reason was by myself. By advice of a fellow pilot, I set the "Textures" combo in the options screen to "HIGH" (was medium) and I got the quality as I had before. So I beg your pardon for my crying.

I would not think, that it depends on FXAA. Some neighboring elements like gauge scales are shown very clear. The error can be seen on the console panels textures only. The blurred text display seems to come directly from the texture file. DCS stores the labels in an own DDS texture file and there in the alpha channel. If you look at this textures, you can see, that the fuzzy display is already in there.

Did someone notice or know the reason why the texture quality of the consoles were decreased? The right part of the attached image shows a screen shot of the IFF panel taken last year. The left part is a screenshot taken from the actual version. Even the beta version 1.2.7 shows the same quality loss. I even inspected the original texture MIZ file and found these fuzzy text labels. I cannot believe that it is a performance issue because the old textures and the new are of the same size of 2048 by 2048.

LUA scripts may be compiled. The result is not necessarily a compact binary, but it is not any longer readable in a text editor. The new created file has the extension LUAC. DCS does accept LUAC files without any problem. Back to the syntax check. Every compiler run is preceded by a syntax check. The compiler stops and shows the bug location and its reason. Unfortunately, the scope of variables cannot be checked in LUA by nature. If a function or variable is located anywhere in another script, LUA automatically assumes an external object. The missing possibility to declear objects can be a pain. Another advantage is the LUA library for C developers . If you plan to create a DLL for your mod, you need to include the LUA library (64 bit version!) to implement the interface for LUA scripts. The compiler is part of the free LUA SDK. It contains the SciTE IDE and the necessary binaries. Compiler runs can be initiated with a simple mouse click. Check the following links: http://www.scintilla.org http://www.lua.org

http://ariescon.com/changeLog.pdf

There is one in the queue but it will take a couple of weeks more. We are working on the radar extension which will be partly an add on in the AirborneRadio.dll. This is mainly the transport of IFF/SIF data and the direction finder strobe to the different radar screens. A second task is the promised rework of the configuration program. The new version will be released together with the new GCI radar. Regards Mike

VHF frequency bug seems to be solved. I observe the correct values if I manually change the frequency on all digits in box1. Edit: I was too enthusiastic. After I removed my small correction patch, the frequencies are still messed up when crossing a 10th boundary. Sorry

The script uses' world.event.S_EVENT_SHOT'. This definitely does not recognize gun fire. I tested this extensively. All other ordnances are observed. I did not find any other usable event in MIST to handle gun fire. S_EVENT_SHOT' is not bound to zones. Every object can be used as target as long as MIST returns a coordinate for the object. The event is triggered if any aircraft releases an ordnance. Scoring is a different logic based on ordnance tracking and target object location.

Thats right. It is a well known DCS bug you experience. Even if you write a frequency with set_frequency() , a complete different value is found in there. Following the rumors, it will be fixed with the 1.2.7 update.