ivanwfr

As far as I know, when you use TARGET, your joystick and throttle is not seen by Windows anymore as their USB drivers are disconnected. They are replaced by a Combined USB virtual device. W7 -- Control Panel -- Set up USB game controllers From there, I don't see how it could be possible and those who talked about this did not care to mention how. So, TARGET has to take care of each and every button handling for a single USB virtual device. But it is quite doable, and this is exactly what Thrustmaster is expecting us to use their scripting environment for. Reproducing the default Plug and Play bindings is the ideal exercise leading to mastering this tool. I'm sure Thrustmaster has provided the solution in this particular parallel universe where people think first, shoot later!

Yes, and you're welcome to ask for clarification if necessary at using script attached to this thread: TARGET - Advanced programming. I use them as a feedback to acknowledge some actions like Gear lock and IOUMD shift keys activation... If you have ideas on how to make them useful for something, let us know. And BTW, no luck here, just good old work hours ;)

I'm the perfectionist kind myself. And I can say why with an example. My point will be only about the common issue of muscle memory that plays a huge part in this sim as well as in racing games. What only looking for perfection can accomplish is making your fingers do the right thing at the right time on their own while your brain is available for tactics or strategy issues. I'll try to illustrate how this approach can lead to places where others, that choose not to go that way, will never reach... My example won't be sophisticated at all, I'm talking about Dirt 2... A simple go fast and faster... Yes but to the extreme, if you are very! obstinate like I think I am, you can go as far as to discern the devs coding for each curve. An other way to put it could be that I can add up the 3-4 parameters to consider at each curve entry point... Speed + orientation + acceleration + steering = good/bad = +/- time bonus/malus. Problem is - with my example - that when your are there with say Dirt2, you stop playing it :wallbash: There's nothing beyond this point. What remains is to do the same thing for another circuit ... only to reach the same boundary. And I mean 500/1000 times each! The only way to "feel" each curve "in the zone". With DCS we're talking about something so rich that I feel that everything I learn will become a base camp for all I will be doing next. This is where DCS make a big difference with my Dirt2 example, which I consider is doing a good job in its category as I enjoyed my quest for handling perfection. Reaching the limit, or feeling as much, was when I felt that any fight for improvement I could make at that stage was all about getting around the failing parts of hardware and software approximation. For instance the simple fact that an input lag of 200ms make you cannot drive like if it were your car. You cannot correct, you can only "have done it the right way"... If you slip... too bad... and too late! And mind you, it takes "some" time to avoid every "programmed" mistakes and when you do... that's the end of perfection. At this point, I can say that I have DCS A-10C since nearly 2 months and I still have to drop my first bomb :D But I can talk about my TM Warthog HOTAS and its TARGET software ! And I enjoy having months and months of a learning curve before me! ...going on my own path... TARGET - Advanced programming

Here's my nicely working Logitech G27 Rudder solution: Deadzone 10% along with a smooth curve around both pedals released position (attached screenshots). In fact, one of the required deadzone is the Saturation X zone, the one at the max value end, near slider max. The only catch was: There is a weird little issue about how Saturation X is displayed when you select both Slider and Invert options. This was in fact the only reason why it took me some time to have this racing wheel Clutch and Accelerator behave (nearly) as a perfect rudder. I say nearly only because you can't touch one pedal without first completely releasing the other. Activating both results in a mixed flow of values that apply at random in opposite directions. To my understanding, to reflect what happens in-game, the displayed Saturation X portion should change side when you check the Invert option, quite like how the red dot does. I'm ready to open a Trouble Ticket about that if I get confirmation from others who would successfully take advantage of this reversed-Saturation-X solution.

Try R_CTL+Num0 to lock snap views ... then Num1...Num9 to select a snap view ... then (when done) RCTL_+Num0 to unlock snap views

TARGET solution in this thread attached archive. The idea is to ignore any other CS input as long as there is already one in progress. I think the code segment below from the end of th/th_MO.tmc is readable enough. The whole script files entry point is in DCSW_PNP_main.tmc, which you have to feed TARGET Script Editor with. It is a "Combined" mapping that mimics Joystick and Throttle PLug and Play functions for DCS A-10C as soon as you import the profile/Combined_ivanwfr.lua that goes with it. The idea is to use that as an entry point for more personal tuning. TARGET DXInput China Hat mapping has the exact same issue as the TARGET-less input. // DXHAT POV mapping (...which has a corner issue for SOI) // CSU_MO = DXHATUP; // CSR_MO = DXHATRIGHT; // CSD_MO = DXHATDOWN; // CSL_MO = DXHATLEFT; This "filtered" solution seems to work pretty well: // ...alternate keyboard mapping [uHJH] [uRDL] ... single key (press and hold) CSU_MO = EXEC("if(!Throttle[CSR] & !Throttle[CSL]) ActKey(KEYON+ USB_U);"); CSR_MO = EXEC("if(!Throttle[CSU] & !Throttle[CSD]) ActKey(KEYON+ USB_K);"); CSD_MO = EXEC("if(!Throttle[CSR] & !Throttle[CSL]) ActKey(KEYON+ USB_J);"); CSL_MO = EXEC("if(!Throttle[CSU] & !Throttle[CSD]) ActKey(KEYON+ USB_H);"); // ...(release pressed key) MapKeyR(&Throttle, CSU, EXEC("ActKey( USB_U );")); MapKeyR(&Throttle, CSR, EXEC("ActKey( USB_K );")); MapKeyR(&Throttle, CSD, EXEC("ActKey( USB_J );")); MapKeyR(&Throttle, CSL, EXEC("ActKey( USB_H );")); [edit] ...answers to a bunch of questions that may come to mind here ;) TARGET - Advanced programming

Same here and I just went through the intensive testing I intended to do about this: First, I made sure TARGET's Device Analyzer reports everything's fine with CS POV when mapped to DXHAT. Then I played with MFCD SOI and functions cycling. After some serious testing and tracing with a script that reported each and every activation event... my conclusion is that it's all my fault! In fact, every time it happened was when I pushed the hat in one of the UPRIGHT, DOWNRIGHT, DOWNLEFT or UPLEFT corners. More to the point for this SOI glitch to the Up or Down left corners. There always was an extra (short!) event instead of the single long-left-press! Too bad we have the POV assigned to this hat because corners are not only wasted here but they are even a problem. From what I've experimented so far, Micro Switch and H4-CMS on the Joystick are not able to get into those corners and would be perfectly adapted to China Hat functions. (Their pushed state seems to be an alternative.) To completely cover the matter, I can say that H2-TMS and H3-DMS are not POV but they can fire 2 closed switch-events at the same time when they are pushed in a corner. Conclusion, either we have to carefully avoid pushing CS in a corner or find a way to discard those events with some TARGET code...

You should not diagnose from reading forum posts as you will get ALL trouble detailed reports and zero no-trouble boring stories! Kind of like sitting at the entrance of some service support center where you could not miss any of the defective units! My own TM Warthog is perfect and it's the first time I tell anyone about it ;) As a long time Logitech customer, and a rather satisfied one, I can tell you they are not in the same league! Go for it and you'll thank me, hehe!

If you need TARGET, it's not for a long time ;) include "target.tmh" int main() { if(Init(&EventHandle)) return 1; GameOutput(&Throttle, OUT_ID_LED_BACKLIGHT, 1); Sleep(500); GameOutput(&Throttle, OUT_ID_LED_BACKLIGHT, 0); return 1; // wrong answer here ! } int EventHandle(int type, alias o, int x) { DefaultMapping(&o, x); }

Bare Plug and Play TARGET script I've just updated my first post's attached archives with a DCS_ivanwfr_110513.zip version. It contains a main script file named DCSW_PNP_main.tmc which makes no references to my fancy functions! It can be used as a clean starting point at using TARGET with a TM Warthog HOTAS with ED's DCS A-10C sim. The only variation is about those 4 unused swtiches: - Joystick S4 (Paddle Switch) not mapped by js/js_MO.tmc - Throttle SC (Slew Control) push mapped to Mouse Left button - Throttle MSP (Micro Switch push) mapped to Escape - Throttle MSU (Micro Switch up) mapped to DX3 Let us know where you get from there as I'm still looking into getting the best from what TARGET has to offer in order to get rid of my mouse and keyboard when in the sky! I'm currently setting up a layout that makes sense at using shift keys to manage IOUMD layers without messing up muscle memory before it's too late. And it's not easy with my last addition of 27 calls to all Function keys combinations needed to access DCS's views :juggle:

Well, I didn't bother getting into any detailed procedure on how your're supposed to switch from a default plug & play use of a perfectly working TM Warthog HOTAS as you're supposed to suffer by yourself a little of the "painful" TARGET aproach :book: and I can deduce from your wording that you did not even considered it any bit :helpsmilie: If I'm right assuming you're not on the geek side, I would say it's safer to keep away from relying on TM scripting as long as you're not ready to tune the code to your liking. Nearly everything I've put in this script I'm not happy with - yet - but I know I can change any part of it in a matter of seconds without even having to restart the sim! And I'm quite sure you would get more frustration than advantages if you can't do that as easily. But, would you ask for any "technical" detail, I'm willing to talk about opportunities to improve or adapt all of this... Tell me if you're ready to get your hands dirty with some C'ish coding ...? Updated first post archive -- Slew keying/mousing tuned by Friction-Control

from keyboard.lua: 'Num4' 'View Left slow' 'Num6' 'View Right slow' 'Num8' 'View Up slow' 'Num2' 'View Down slow' 'Num9' 'View Up Right slow' 'Num3' 'View Down Right slow' 'Num1' 'View Down Left slow' 'Num7' 'View Up Left slow' 'Num5' 'View Center' 'Num0' 'Cockpit panel view in'

TARGET - Friction Control Slider to adjust SC sensitivity (Slew and mouseStick) This TARGET script shows how it is possible to adjust Slew Control and trackpoint sensitivity. Friction Control slider modifies keystrokes down/up time ratio as well as mouse axis curve zoom as appropriate. Joystick S4 activates SC button press In-layer function (as shift key) to toggle between SC ",./;" default key pulses and mouse pointer mapping. In each case, sensitivity can be adjusted by the Friction Control slider. (I can get into more details when/if asked) [edit] After some test, I'm not happy with CPU drain by my REXEC(slewFunctions)...looking for optimization... I crashed twice as the Joystick input was delayed! But it was good not needing the mouse for Aircraft view handling... I had to invert MOUSE_Y="Camera Vertical View" and MOUSE_Z="Camera Zoom View" to make it feel as you were turning the plane around instead of the camera. ivanwfr_slew_110511.zip

Thanks to remind me about the Sync configuration option, I've buried this one among all those yet to digest details of my new hobby. Back to the subject, I can point out that keyboard and DirectInput states may have different effect you could investigate while binding the function. Device Analyzer shows those input current states when EventTester wouldn't when it is started after a key has been pressed and not released... [edit]Looking at this from TARGET point of view PULSE'ing a key when you flick a switch explains very well the situation you describe. (PULSE is the recommended way to handle virtual keyboard events as it avoids stucked pressed keys)... But it's also the best way to keep being out of sync with no way out. Instead, DirectInput two-ways switches are reported through their current on/off states at any given time... leading back to my own concern BTW ;)

If you bind it yourself like this, I think that's all you can do from your side: [656] = { ["name"] = "TGP switch ON/OFF", ["category"] = "Armament HUD Control Panel", ["down"] = 1383, ["combos"] = { [1] = { ["key"] = "JOY_BTN1", }, }, }, When a toggle is bound to a DirectInput switch, its state should be detected by the process if startup is made correctly... [edit]After some more thoughts, I would say that from this point of view, DirectInput has 64 distinct switches input states to report. Sensing only transitions rather than states would be a bad way to handle input events and I don't think DCS does a bad job from what I've seen so far. Could you be more specific on how what you expect is not working as it should? [edit 2]As a matter of fact DCS A10-C cold start does not care about the current state of the Thrustmaster HOTAS Warthog console switches. I first have to sync them to what I see on the screen. This is true even for those 2/3 ways well defined switches like LASTE: APPAT_MO = DX27 APAH = #51 (middle) APALT_MO = DX28 ... you need define only 2 values, the third being a fall-back default. Maybe you won't do better than TM after all.

Thanks swift, I don't know how I could miss that thread! Reading it right now...

TARGET - Advanced programming Hi, after going through this thread, I had to chime in for those ready to put TARGET in the loop as a solution for an effective use of "Save Cockpit Angles" command mapped R_ALT + KP0. I've described my approach in the TARGET - Advanced programming thread and looking for input from members interested. My approach is not the easy one but I can tell that I was happy with the results as I did not expect to solve it this nicely. The snap view handling I put there is based on all I could read around here on the subject and code shared by the few other TARGET explorers. The view extension can have you redefine all 10 custom views and have them saved in one minute with a single hand on the the stick. No keyboard involved. Code needed some doing, but I swear it's clean, as my credo is keeping up with ED's and Thrustmaster level of quality is a must.

Adjusting and Saving Cockpit Angles ruled by thumb Starting from the structured mapping code attached - and updated - to my first post, I could introduce an automated handling of DCS\Config\View\SnapViews.lua. DCS Command is: [save Cockpit Angles] category [View Cockpit]: [save current cockpit camera angles for fast numpad jumps] <install_dir>\DCS\Config\View\SnapViews.lua: This feature does not seem to be fully implemented yet as the configuration is not saved in user profile space as it should... for instance: C:\Users\<your_login_name>\Saved Games\DCS Warthog\Config\View ...would be appropriate, I guess. Instead, your views are saved in one of DCS program default configuraton folder: <install_dir>\DCS\Config\View in a file named SnapViews.lua This is where the 10 snap views corresponding to Num0-Num9 of the Number pad are defined (and can be adjusted) (and 3 more views are there for mirrors). But, in fact, they're never saved, anywhere, as this can happen only after you unlock the feature as explained below. <install_dir>\DCS\Config\View\View.lua: Another little but weird detail to consider, is that you need to modify a variable defined in the View.lua program file you can find in the same folder in order to have the command effectively do something! Even if you map some input event to "Save Cockpit Angles", there is a default directive telling the program to ignore this command. To change this, you have to modify one line of View.lua. Line 50 says: UseDefaultSnapViews = true ...and it should read: UseDefaultSnapViews = false ...as we want our SnapViews.lua file used instead of the one named SnapViewsDefault.lua! At this point, we can hit R_ALT + Num0 and have our SnapViews.lua updated when program exits. (Beware, this file is created only when you terminate your session). As a side note some helpful information can be found in SnapViewsDefault.lua but unfortunately, there is a twist in the comment you find there (merely a missplace punctuation in fact): User-made snap views for all his missions are saved in the Config/View/SnapViews.lua file if the parameter DisableSnapViewsSaving = true in the Config/View/Cockpit.lua file. Default snap views come from the Config/View/SnapViewsDefault.lua file. ...should read: User-made snap views for all his missions are saved in the Config/View/SnapViews.lua file. If the parameter DisableSnapViewsSaving = true in the Config/View/Cockpit.lua file, default snap views come from the Config/View/SnapViewsDefault.lua file. ...and that's precisely what we don't want! Using [save Cockpit Angles]: Still, even if you can redefine your views, it's not a friendly process. If ED did not advertise much about this it's for a reason, and I guess it's because the procedure is currently pretty tricky: When you hit [R_ALT + Num0], what you're saving is the last selected predefined view you've displayed before you started ajusting the camera. This means you must not inadvertently use any of those views while you're making your camera adjustements. If you do, you're going to modify the wrong one. TARGET: This is where my TARGET script comes to the rescue... Well it will be adequate only for those who are ready to use TARGET with a compatible HOTAS! ...and get their hands dirty during the process ...and are still reading. I based the Save Cockpit Angles function on the SNAP VUE [LOOK]-[sELECTION] mechanism I've put in there earlier. What it does right now is this: - The selection of one of those views can be made with the 4 HATS/POV of a Warthog HOTAS. - After having carefully adjusted the position of the camera in the cockpit, the next HAT-SELECTED view can be instantly modified (and later saved) by pressing [s4 + S3 + S2] (cat + drunk-pilot proof combos!). ... just follow the maze: S4 (Middle-In layer shift) -> see [H1234] mapping of js/js_MI_view.tmc -> will call view_look_start, view_look_end, view_select, unlock_view of view/view_cockpit.tmc S3 (Up-In layer shift) -> see [s2] mapping of js/js_UI_view.tmc -> will call view_save_selected of view/view_cockpit.tmc These steps are not frienly either (at first) but I wanted to share my raw results early. If they draw more than my own curiosity, I'm ready to get into more details for those interested. Quick steps to make that work: ;) (Dont' shoot, I will elaborate/adjust on request...) - Combined_ivanwfr.lua: In order to have TARGET virtual HOTAS work at least like the TM Warthog 2 separate devices mapping with DCS A-10C, you have to import those DCS corresponding commands. It comes as the result of an initial mapping session profile with a keyboard shortcut bound to each Joystick button keeping all 32 DX-input available for Throttle mapping. (BTW... have a look there to see a note about [Flight Control] JOY_BTN3 messed up between joystick and throttle... still have to issue a ticket about that.) - Launch TARGET Script Editor and load and run view_main.tmc or DCSW_main.tmc - Then do some reading of the most relevant code in these files: - view_main.tmc - js/js_MI_view.tmc - js/js_UI_view.tmc - view/view_cockpit.tmc I think I've much to do for all that to make sense to no geek-like-me but it's all a work in progress. ...don't hesitate to ask about all that I intentionally avoided to talk about... (this post is long enough ;) ) [size="2"] DCSW_main.tmc Makefile view_main.tmc | +---assoc | util_assoc.tmc | util_assoc_init.tmc | util_assoc_keys.tmh | util_assoc_log.tmc | util_assoc_main.tmc | util_assoc_map.tmc +---axis | axis_key_map.tmc | axis_map.tmc +---js | js_declare.tmc | js_map.tmc | js_MI_view.tmc | js_MO_LED.tmc | js_MO_standard.tmc | js_Release.tmc | js_UI_view.tmc | js_UO_LED.tmc +---th | th_declare.tmc | th_map.tmc | th_MO.tmc +---util | util_led.tmc | util_log.tmc | util_usb.tmh +---view view_cockpit.tmc [/size]

Here are some of my major proficient elements good to consider when dealing with TARGET scripting. And I mean when you want to go beyond Thrustmaster FAST SCRIPT BASIC document. The intent is to add some clues to what comes out from experimenting with the language after having read this and messed up with what you think the meaning was. The main intent of the author seems to be about making explanations as simple (i.e. short) as possible in order to avoid frightening readers... Results is there are so many missing parts that your guesses are the only way out, like if 20% of A-10's cockpit buttons were not documented. My starting point was to use TARGET to improve the use of a perfectly working HOTAS that does not require it in any way. To do that, I had to come up with a clean working base. And the documentation was not helpful here. To start with something immediately useful, here is the most basic lesson I learned from the experience: Making good use of preprocessing include directive helps at improving readability in several ways: - Lightens and compacts calling code with the effect of displaying the big picture. - Confines related code into a dedicated file where it can be isolated from irrelevant code. Here are a few topics organized into their own separate files: [size="2"] [color="RoyalBlue"][b]include[/b][/color] "target.tmh" // Target's own definitions [color="RoyalBlue"][b]include[/b][/color] "js/js_map.tmc" // ...separate custom code [color="RoyalBlue"][b]include[/b][/color] "th/th_map.tmc" // ...throttle mapping detail [color="RoyalBlue"][b]include[/b][/color] "axis/util_axis_map.tmc" // ...MapAxis() calls [color="RoyalBlue"][b]include[/b][/color] "axis/util_KeyAxis.tmc" // ...keyAxis() calls [/size] ...those files can use their own relevant include organization as well. Optional functions files may be included too: [size="2"] [color="RoyalBlue"][b]include[/b][/color] "view/util_view.tmc" [color="RoyalBlue"][b]include[/b][/color] "util/util_led.tmc" [color="RoyalBlue"][b]include[/b][/color] "util/util_log.tmc" [/size] ...activating and deactivating those optional functions would only require commenting out a one-liner call to the freezed function from main code. The alternative beeing a whole bunch of freezed commented code lines. The standard main script entry point specifying two modifier switches for IO and UMD layers: [size="2"] int main() { // Init Exclude(&HCougar); Exclude(&T16000); Exclude(&LMFD); Exclude(&RMFD); if(Init(&EventHandle)) return 1; SetKBRate(25, 33); // [u]Layer shift switches S3 and S4[/u] SetShiftButton( &Joystick, S4 // devI , indexI , &Joystick, S3 , 0 // devUMD , indexU, indexD , 0); // flag (IOTOGGLE + UDTOGGLE) [/size] ...&Joystick, S4 Means holding joystick S4 switch down while activating another js or th switch asks TARGET to generate it's I(in) layer mapped virtual input event (instead of the default O(out) one). ...&Joystick, S3 Same idea applies for the U(up) layer mapping. , 0 is where an D(down) layer modifier would be specified. ..., 0 - Default (0) has layer shift while holding shift buttons (modifiers / reformers) - IOTOGGLE, UDTOGGLE toggles layer combination in effect on/off each time you hit one The mapping part: [PHYSICAL SWITCHES] to generated [PROCESS INPUT EVENTS] (keyboard + DX-Input): [size="2"] printf("DCSW_main:\xa"); // A clue about script activity in editor's trace panel js_map(); // Calling a function defined in the included "js/js_map" th_map(); // ...same for throttle mapping util_axis_map(); // ...and axis mapping util_KeyAxis(); // ...virtual keyboard events based on specified axis values init_LED(&Throttle); // ...playing with console LEDs printf("...ready\xa"); // Just to know we're there, not trapped into some dead-lock [/size] Handling [button press / release] entry point: [size="2"] int EventHandle(int type, alias o, int x) { if(log_level > 0) { if((x < IN_POSITION_AXES) & o[x]) log_event(&o, x); } DefaultMapping(&o, x); } [/size] Here we have a chance to interfere before the virtual input mapped to each switch gets delivered to the focussed process (*). In this case, the code does not change anything to the standard handling. It just calls a function that prints details about what's happening when switch activation handling is carried out. The log_event() function is in the "util/util_log.tmc" included file (shows selected layer, switch number, ...). In fact, this is where we can add some tricks that would override standard TARGET features (...) I have more experimental (painfully obtained) information to share but it will be better discussed when appropriate rather than adding to this first post... that I hope it's still readable ;) (*) During script test sessions, your focused window will direct generated virtual events to the owning process. A good idea is to always click EventTester's window before pressing any button as it is prepared to ignore anything you throw at it. [size="2"] [u]DCS_ivanwfr.zip[/u] (111222) ...updated TM_Warthog_Combined_1111_ivanwfr.lua ... * DX Input OFF button events have no effect :( * (110924) + H2U + TG1_MO + flashLED() // PAC auto zoom (110818) + H4U_DO = USB_QUOTE; // Score window + H4R_DO = USB_QUOTE+ L_SHIFT; // Show debriefing window + H4P_MI = USB_M + L_CTL; // Master Caution (110803) ... js_SHIFT() & th_SHIFT() called later, in order to override earlier standard mapping. ... Console back light Intensity & On/Off ... Up-Out layer updated: Eject, Respawn, Frame rate, Active Pause ... [b]Joystick[/b] with SetCurve(zoom) with [b]S3[/b] - Hold S3 = Joystick Precision temporary mode (like TrackIR does) - Hold S3 + Friction Control : Adjust and retain zoom (Full forward = 100% deviation) - ... removed curvature adjustment (no need for TM Warthog) ... Adjusted snap-views key down timer from default 32ms to 50ms - (110613) [i]* works much better (as in [u]every time[/u]) with my rig (i7 960 + W7x64)[/i] ... Adjusted hat corner handling -- Throttle CS and Joystick H[1234] [uRDL] - (110612) ... Added th_DX_main.tmc for a simple DirectInput Trottle Mapping [i]* needs loading related profile *[/i] ... Adjusted P&P profile for Patch-1108 ... China Hat that won't go in corners (...and disrupt [i]Left Long Press[/i] = SOI) ... Hats in corners ... Slew keying/mousing tuned by Friction-Control ... DCSW_PNP_main.tmc as a bare PnP starting point ... Slew / Trackpad mouse pointer freezing with S3 for a stable Left-Click. [u]PNP_ivanwfr.zip[/u] ...TARGET [i]Combined[/i] plug and play as an alternative to separate USB devices [i]Joystick+Throttle HOTAS Warthog Game Controllers[/i] [u]DCS_Bindings.zip[/u] ...Keyboard dynamic HTML for IOUMD layers bindings [/size] Note : All of this has been smartly sabotaged with patch 1.1.1.1. :cry: PNP_ivanwfr_110924.zip DCS_ivanwfr_110924.zip DCS_Bindings_110924.rar PNP_ivanwfr_111222.zip DCS_ivanwfr_111222.zip

I too remember my "playing" with FS, a long time ago, and just to show who's talking, I know how much i know nothing about planes when I remember what I had to go through in another demanding discipline involving taking a car engine appart, everything all around the bench, reparing some and put them back together and be prepared for the first vrooom :pilotfly:... or clang :joystick: ! If I've been pretty close of this kind of plane, I never touched any! So with all this stated, I manage to keep my mouth shut on subjects requiring a big part of a professional life before you can say anything good enough to be said. This is typical of those who claim that the majority is always right... In this case, that will never be true... he just lost an occasion to shut up :doh: I'm quite new in sims... and I enjoy those months of hard work before me :harhar:

After I asked oritpro if it was alright for me to use his document as a starting point to come up with a version containing as many references as possible to get closer to the source of information about all those acronyms we have to swallow... I was sooo bored turning those >600 pages looking for some switch location or the meaning of a bunch of uppercase letters, sooo many times read and forgotten... Here is what I could do so far: The format is HTML so I can play with CSS stylesheets and keep going with improvements as I can think of more or someone suggest any... [edit - link updated] I shared it via Google docs --12MB WinRAR archive :book: -- Comments & ideas are welcome