towsim

To clarify the difference between single dektop and 3 camera setup, I have made a small drawing. It explains the differences in field of view and angular distortion Which solution is finally taken depends on the individual special liking. Single desktop The disadvantage is , that only one flat projection plane exists. All advantages with 3 monitors are lost. You could even take one large monitor to get the same result. A 180° field of view is not possible in a natural way. This can only be produced by zooming out in the cockpit by getting a fish eye result. The second disadvantage is, no edge blending is possible, because there is no variable for it. DCS takes the three monitors internally as one large monitor. To understand edge blending, see the attached image. The advantage of a single desktop is that the scenery is displayed more naturally. The field of view is normally limited to a natural angle. There is only a limited fish eye effect if no extreme zoom out is used. The position of the observer in front of the monitors is not bound to a fixed position. Internally you will get a better frame rate because the graphics engine calculates only one geometry for a frame. The frame rate is limited only by the entire number of pixels on the desktop. This single desktop technology is used by the Matrox tripple head. This setup needs to have the option 'Full Screen' to be checked. 3 Cameras setup The biggest disadvantage is, that the graphics engine has to calculate the geometry at least for some overlapping objects 3 times for a frame. Probably the entire scene is calculated 3 times. Because each monitor has a different observation angle to the scenery. The performance used is found in the CPU , calculating objects attitudes 3 times and transferring the results 3 times to the graphics adapter. The Graphics adapter itself is impacted only by the larger number of pixels compared to a single monitor setup. The position of the observer in front of the monitors is critical. The ideal position would be in the intersection of the mid axis of the monitors. The height of the eye point decides whether you see the horizon as straight line or as a bow if you are not in the ideal position. This even would imply, that the arrangement of the monitors would be 60° to each other. This is normally not possible because of the size of the monitors. So the observer's position and monitor arrangement is a compromise of available space and zoom factor. My experience is, that after a while, the eyes accept this display and take all advantage of the larger field of view. The advantages are, that the field of view can be theoretical 360°, using 6 monitors in a circle. This is practical not possible because the diameter of the monitor circle would be about one meter only. Edge blending can be defined so that the observer really feels like looking out of a window. This setup must not have the option 'Full Screen' to be checked. I hope, this makes the decision easier how to use 3 monitors. I personally prefer the 3 cameras setup because of the flexibility. Regards Mike PS @Kite The most money was spend to the computer , monitors, Warthog Hotas and the pedals. All others is hand made by my self, based on existing furniture and some F104 cockpit trash.

Hi Chris, I just tried to find out how Eyefinity works. It seems to be a nightmare. So obviously, I do not use Eyefinity in my environment. The only service I use is done in' CCC Desktop management', displayed in the CCC image below. It was a hard work to get my normal arrangement back after experimenting with Ifinity. I arranged 3 of my monitors in a row and a forth in the mid below. Whereby the forth monitor is connected to an additional NVIDIA graphics adapter. It was not possible for me to find any combination with Eyefinity which would fulfill my requirements. The Desktop is defined as 5760x1200 and the main monitor is the most left of the three. The usable desktop spans over all four monitors. The only additional definitions in DCSW was, to modify the 3Cameras.lua for the edge blending. The entry of 'viewDx = -1.09' and 'viewDx = 1.09' compensates the monitor frame. The value I use (f 1.09) must be calculated individually for your type of monitor. Measure the overall width of a monitor including the frame and then the width of your visible image area. Divide 'Monitor frame width' by 'visible image width' and you get your individual edge blending value. As you can see in the 'options' image, the 'full screen' is not checked. The resolution and aspect ratio needs probably to be set manually to the values. The third image shows the result. The performance of the graphics is at the limits. If I have a scenery with twilight illumination and a lot of objects, the frame rate drops below 10 frames. The maximum I had was 30 frames in an airborn situation at high altitude. My Hardware is: 3 x LG Flatron W2452TX 1920 x 1200 1 x LG Flatron E2441 1920 x 1080 ATI FX black edition dual GPU CPU i7 980 12 Gb main memory Regards, Mike

Try this. I even use 5760 x 1200. Make sure, that your 3 monitors cover one single desktop. I am not sure whether Eyefinity is active on my computer. I simply aranged all 3 monitors to one single desktop in the CCC. Do not forget to uncheck 'full screen' in the A10 Warthog or DCS World options dialog. Then it should work. Regards Mike 3Cameras.lua

LoGetEngineInfo @AlphaOneSix Hi, works like a charm... Thanks Mike

Thanks for the reply, @BR=55=Sevas I made a first step to get the fuel status from the returned structure. But the returned structure is something.... The only result is, that the script is interrupted from that point when it returns from LoGetEngineInfo(). The Code is: local engine = LoGetEngineInfo() -- gets the table Panels.FuelStatus(engine.fuel_internal,engine.fuel_external) -- sends two values to my DLL fuel gauge Panels.Protocol(0x10,string.format("Fuel: %f %f",engine.fuel_internal,engine.fuel_external)) -- puts the values into a protocol file Where 'Panels' is the interface to my connected DLL showing the external gauges. @AlphaOneSix I think your suggestion will be my solution. It doesn't matter anything where to get the data from. It is only frustrating , that offered interface functions do not work, even over many version upgrades. Thanks to all in any case Mike

Hi, does anyone know an equivalent for LoGetEngineInfo() ? After seeking around is seems, that this function does not work. It only causes the enclosing LUA script to be stopped by error. My intention is to reproduce external engine gauges, separated from the simulator in an own process. Every idea is welcome. Regards, Mike

The attachment contains a tanker mission with only one aircraft. The hog is already in trail and almost in 'precontact position', but not configured. The tanker frequency is 132.0 MHz on box 1. The frequency in the briefing window is wrong. In addition a small tutorial with my hurtful experiences on the way to a complete refueling. Regards Mike Refueling.zip

You probably loaded down the same mission I got. Have a look into the mission editor. I found out, that the tanker frequency is 132.0 Mhz instead of 150.0 Mhz as instructed. Regards Mike

As I said, I did not test it. I had to rename some items and therefore some mismatches. #define DllExport __declspec( dllexport ) This is simply a macro for a Microsoft specific export declaration. You could even use __declspec( dllexport ) directly. In a big DLL not only one function must be accessible. Then the shorter form DLLexport is more comfortable. static expression In the LUA library header files, the typical LUA callable C function is declared as static. So I have to follow this requirement. Otherwise the LUA loader would reject the table with an error message. Static simply means, that this function has a fixed memory address over the entire session. Therefore its address can be used as address of a constant to be stored in a table. I even used this construction in other projects (not with LUA) without the static declaration. It works... Name Mixup In the DLL source code, "My Dllfunction" must be replaced with "OwnShipPosRep". This was a mistake while adjusting the source. (sorry) "Radar" Actually the C functions are accessible under two names. One is the name of the local variable 'local Aries = require('LUAext')', the other is 'radar'. So a function call could be aries.EOapp() or radar.EOapp(). The only difference is, that 'aries' is accessible only in CockpitExt.lua while 'radar' is a public variable, accessible from all other LUA scripts. That even means, you can call the DLL C functions out of other LUA scripts without any additional coding. The parameters for ' lua_register ' are the state variable (manly used for stack management) and a user definable, public name for the table. In this case I used "radar" . The third variable is the address of the table itself. regards Mike

Here a short example. I cut this out of a project and reduced it to the important items for the example. Use caution, I did no test on it. The attachment contains a LUA script and the source for a small DLL. Regards Mike LUADllExample.zip

So I finally found out how the DLL extension works. Situation You want to call a self developed DLL (C/C++) out of a LUA script. The LUA script is invoked out of EXPORT.LUA with a 'dofile' instruction. Your DCS simulator is a 64 bit application and runs under Windows 7, 64 bit. Solution DLL First the DLL has to fulfill some requirements. The DLL project must be a 64 bit version. You have to link the library lua5.1.lib to your project. No other version is accepted. The lua5.1.lib must be the 64 bit version! The entry point in the DLL is the next critical point. The entry function must be exported with 'DllExport'. The name of the entry function in your DLL is a combination of a keyword (lua_open_) and the name of your DLL module. If, for example, the DLL is named CockpitExt.DLL, the function must be: DllExport int lua_open_CockpitExt( lua_State *L) { ...... } So renaming the DLL afterwards will cause a 'file not found' error. No link library is necessary for the DLL. in the Linker's advanced settings, set the 'Base Address' to 0x68100000. I do not know the reason for it, but a LUA documentation specified this entry to be necessary. To avoid the construction of a C++ wrapper module, I would recommend to use pure C code in the DLL. Ensure, that only release versions are given to other users. I made the experience, that debug versions are sometimes rejected by the loader module. Solution LUA script In your LUA script you have to add the following statements to load and connect to your DLL: Depending on the location where your DLL resides, extend the search path of the lua loader module with package.cpath = package.cpath..";.\\Config\\Export\\?.dll". This statement includes the Export folder in the search logic for DLLs. It implies, that you copy the DLL to the Export folder. To load the DLL and to invoke the entry function add the statement: local MyDLLfunctions = require('CockpitExt') If that all is done, the DLL should work as expected. The further code to register your C functions to LUA and the data exchange should be taken from the LUA documentation. There are no specifics for DCS. Good luck, Mike

I am sorry for this stupid question. Is A10 version 1.2.0 a standalone update or is it for A10 in DCS World? Regards Mike

Being tired of fighting against the unpredictable behavior of LUA scripts, I created a DLL to be invoked with the 'require' statement out of a small LUA script. After a view experiments I got it to run and it worked perfect. All complicated logic under the control of my own C++ program! I was happy for a short time. This DLL served my private cockpit extension. For my ATC radar project I needed a second DLL which should serve the network communication. And then the problems started up. The LUA interface seems to accept only one specific name for a DLL which is 'LUAext.dll ' all other names are rejected by the 'require' statement. I can bring the second DLL to run by simply renaming it to from LUAnet.dll to LUAext.dll. Is it the truth, that there is a naming convention for DLLs and I found the right name like a lottery win? I would be really happy if someone could explain this odd behavior. Regards Mike :helpsmilie:

SmokeyTheLung is right. You need to hold the button down until the indication is lit. The indication light tells you, that the takeoff trim is established. In almost all cases you will find, that the indication is lit immediately when pressing the button. It simply tells you that the stick was in the propper trim position already. Regards Mike

http://forums.eagle.ru/showthread.php?t=88859

Hi all, today we made a very successful beta test with our new ATC tool. We were simulating ASR and PAR with several aircraft under radar control. My special thank goes to Gremlin77 who gave the key tip so that we can use the IFF/SIF codes for identification. Thanks Mike

@Kenny Darf ich fragen wie deine Framerate bei 3 Monitoren ist ? Ich fahre auch mit 3 x 1920 x 1200. Die Framerate wird bei komplizierten Szenerien grenzwertig. Es ist gerade noch zu ertragen. Wenn man airborne ist geht's fast normal weil durch die LODs die Berechnung vereinfacht wird. Ich habe auch einen Versuch gestartet mit 2 zusätzlichen Monitoren a 800x600 (also insgesamt 5) um die MFDs auszulagern. Die Monitore wurden so angeordnet, dass insgesamt die kleinst mögliche Fläche abgedeckt wurde. Das Ergebnis war niederschmetternd. Die Framerate konnte an einer Hand abgezählt werden. Die Renderoptionen sind bei mir sehr weit runtergeschraubt. Ich habe eine ATI doppel GPU Karte mit 2 Gb Grafikspeicher und im Hauptrechner werkelt eine i 7-980 mit 6 Kernen. Mich würde interessieren, ob eine bessere Hardware etwas bringt oder ob es spezielle Einstellungen gibt. Ein Versuch mit einer modifizierten d3d9.dll aus dem Forum hat zwar die Framerate merklich angehoben, hatte aber Probleme bei der Darstellung von Partikelsystemen. Jedes mal, wenn irgendwo im Spiel eine Maverik abgeschossen wurde, ist mein Programm abgestürtzt. Gruß Mike

Hi Gremlin77, that worked!! We are able now to handle realistic identifications in our radar ASR application. Excellent! Mike

Hi , thank you for the response. Unfortunately it did not work. After I inspected 'performClickableAction.lua' it seems, that 'get_argument_value' is implemented only for the main panel. The IFF has only 2 functions: 'performClickableAction' and 'SetCommand'. But it may be, that my interpretation is not right. There is almost no possibility to determine the error source if a function does not work. Regards Mike

Hi Brydling, is the product still available? If yes, could you send me the pricing in Euros and the data for the payment? I didn't get get a response on 'farbror_brydling@hotmail.com'. Regards Mike

Hi, does someone know how to read out the current IFF/SIF code and switch setting with a LUA script. Something like a LoGet... function or similar? As alternative it could be the 'group' and 'own ID'. I would need the values for a identification procedure in a GCA radar application. Regards Mike

Hi Headspace, Many thanks for your answers. I see, I have to go my own way. Best Regards, BOSSHOG

Hi Headspace, is that the technique TARS uses or is it a suggestion how to exchange information? Today I made several tests with two TARS clients talking out of the cockpit. I catch the callback 'ts3plugin_processCommand' in my ATCradio plug in. The function was never invoked . It would not be that complicated to define an own protocol , but I am bound to the TARS standard because at the other end of the ATC radio will be TARS clients. Best Regards, BOSSHOG

Hi Headspace, my question bases on assumptions. So I assume, that a certain kind of additional information must be given from a connected TARS client to all other TARS clients. This additional information would be the frequency a client is talking on. So the receiving client can filter out the voice stream (packages) of frequencies which are not tuned in his local boxes. I made several test on different callbacks in the plug in to evaluate the receiving information. I had no luck up to now. What I am planning to do is to connect my existing radio application via shared memory to my TS3 plug in. Based on the selected channel on the radio GUI, I would suppress all voice streams which do not fit in my channel composition. Vice versa, the transmitted voice must be earmarked in any way, with the frequency information of the channel, which is selected on the radio GUI. Finally, I do not know what screw I have to tighten. Best regards BOSSHOG

ATC Radio Hi Headspace, I just started the development of a standalone ATC radio box. Since our community (vJaBoG32) uses TARS for radio communications, the best way would be to use the same standards that TARS uses. At the moment I develop the application frame as TS3 plug in. It all works so far. The next step would be to evaluate and set the frequency information in the received and transmitted packages. Do you see any possibility to provide the necessary internal information how to modify and evaluate the voice packages out of a TS3 plug in? It would help our community to integrate tower and radar control in the simulation. Best Regards, BOSSHOG