ivanwfr

Just couldn't resist this time to say and repeat that the worst virus on earth are anti-virus... They turn people into a frightened herd of addicts. If I were one of those who build such "tools", I would sponsor a whole bunch of vicious "geniuses" to spread more of those stinking fancy threats. If your refrain from clicking on everything that pops under your pointer, you won't plague your system. And when in doubt: http://www.virustotal.com/ Here! I just got my rant fix of the day.

Not that I am 100% positive about this, but you should have a look at the training .miz trigger zones with Mission Editor. When nothing happens, that means some trigger will never get activated as you missed some expected path and you probably have no way to catch up as long as you're expected to keep your heading :huh:

Don't extract their contents, they should remain zipped, and kept with their miz extension as they will be unzipped by the sim on the fly.

Your experience could be the reason why your are not afraid. In fact that's all that matters. The major difference between an experienced programmer and any casual one is that the first is prepared to deal with many more issues than expected by the second. You can't be disappointed by problems along the way, you should love them :wacko: ...so perverse!

Hi, No bother at all! You are one of the few who dare put their fingers into that as a non-programmer! So, I'll always be ready to help ;) The MSU and MSD wont work as long as they are used as modifiers in DCSW_main.tmc SetShiftButton(&Joystick, S4, &Throttle, MSU, MSD, 0); But don't hesitate to ask if I can help...

:rolleyes:Don't do that! Piloting a flying couch with a women's hair band to hold your TrackIR is nearly too much. Adding gloves and a uniform would be over the top unless you can lock the door so that no one can see the picture ;)

The idea is to use S3 (long press) as another shift modifier asking the Slew axis to calm down just before a click. ...see js/js_MO.tmc where this is defined ...and axis/axis_THR_SC_MOUSE.tmc where the axis sensitivity is set to a minimum as long as you keep S3 depressed... kind of 7th layer as if IOUMD was not enough ! I like it, it works like PAC does when it turns the hog all by itself into a big gun aimed at the bad guys ;) You should have a look in there in order to play with the default 200ms delay because you could miss nose wheel steering activation if you hold S3 longer !!! And about the dynamic friction control sensitivity, (that I also like) I had to rework a pure TARGET macro version that was not smooth enough to be usable. The current version was a challenge as you can see in axis/axis_THR_SC_KEYS.tmc. That was not a big deal when you have some software experience but this is not friendly to main TARGET audience. In fact this scipting is a nice programmer's toy as long as TM did not place the usual boundaries other manufacturers put there to avoid criticism and questions. ED Mission Editor seams to be the same kind of tool, in many aspects. You can use the GUI only but miz files can be opened and LUA code edited if you know what you're doing.

Here is what wiki has to say about this :smartass: : Identify the constraint (the resource or policy that prevents the organization from obtaining more of the goal) Decide how to exploit the constraint (get the most capacity out of the constrained process) Subordinate all other processes to above decision (align the whole system or organization to support the decision made above) Elevate the constraint (make other major changes needed to break the constraint) If, as a result of these steps, the constraint has moved, return to Step 1. Don't let inertia become the constraint.[5 ...the full story is here: Theory of Constraints

I enjoyed it too, and this got me involved in using the mission editor for the first time to add some layers of difficulty to such a point I crashed every time: crosswind landing by a stormy night! :huh: Well, I dropped the night and some clouds and I can make it but not thanks ILS! I still need to see the runway at least for one minute before the final's dance steps. But I know I really miss something when I look at the HUD and realize that this would be all I could rely on with less visibility... What am I supposed to do with a TVV pointing a few hundred meters from where I'm supposed to go? I know I have to dig manuals to get that strait! that's just where I am right now and I like the challenge. As a related point, I had a first, quick and dirty, try at Prepare'ing the mission to configure VHF for Batumi so that I would not have to do that every time and I got that working but ILS and TACAN are not restored as expected... ? Here too, RTFM :book:, I know, but some times it's too much reading! I don't feel the urge for things that go boom but I can't just keep reading, so I go boom myself for a change :pilotfly:

You must be right.

@WarriorX: TARGET could be better, and BTW all of us could as well ;) I agree with your critics about the Combined limitation. This must be the result of a tough compromise between ED and TM when Plug and Play functionality was at stake. But my interest, for the moment, is mostly about what's good with TARGET. If I were to look for bad, I'm pretty sure I could write pages about what I've struggled with so far. It does not mean that I am the "positive thinking" kind of guy, I'd rather say that I'm looking to see what we get from TM scripting when pushed to the limit. When I'm done with that phase, I will join those asking TM to move on! What i'm going to say is off topic but as audience is here, I'm going to take advantage. :smilewink: first I need to repeat that I don't work for TM, I just like doing things the right way, as if my life depended on it... immersion! Here is my collection of facts (no opinion there, all this is about working features): NUMBER OF KEYBOARD BINDINGS: There is exactly(!) 256 keyboard shortcuts bindings in DCS A-10C. - (DCS/Config/Input/Aircrafts/A-10C/keyboard/default.lua) Unless a good part of them are superfluous, we are going to use our keyboard at some point. And I don't think we can rely on modifiers to handle all those commands from the HOTAS. MODIFIERS: Using a switch as a modifier means loosing its default function. A script can help at keeping this default function when it detects a short click of that switch and use it as a modifier (/reformer/shift) when held down to alter other buttons handling. WHAT SCRIPTING IS GOOD FOR: It's all about tuning and customization! Associate switch release events to a custom function Short - Long press switch differentiation (there could even be more than 2 with some more coding) Experimenting with adjustable custom delays (put our experience at good use) Custom sensitivity (instead of single default values) On the fly dynamic sensitivy adjustment (depending on what we are doing at the moment) Smart handling (i.e. VOI: get us back to our current selected snap view after taking a look to another) Layer structured by topic as an ergonomics goal: A modifier (/reformer) opens the door of each topic-related layer of functions: (After some time, I expect mode selection will become muscle memory) Up In : Desktop(Alt-Tab) ...misc accessory controls Up Out : TrackIR, [DCS Pause,Accel,Slow], Script log ...gameplay controls Middle In : COCKPIT SNAP VIEWS smart handling (select,look,save) ...smart view handling Middle Out : STANDARD DCS Plug and Play---] -- (Middle Out layer) ...this is the default layer -- what we have without TARGET. - DCS does all the work for us, because we are lucky owners of a great sim! - And this is where some experience at using TARGET (or the lack of) will help to cope with other games bindings (or not). - (*) Down In : Function keys F1-F12 +LR_MOD-] -- ( Down In layer) ...display layout controls Down Out : Function keys F1-F12---------] -- ( Down Out layer) ...camera controls [*] ...you name it (...in fact this is exactly what I'm looking for!) WHY ADVANCED SCRIPTING : About structure polishing beyond obvious simplicity promoted by the manual: extensive use of include capability: ...file architecture by function (the black box paradigm) ...consistency of calling files (a small amount of lines covering all script features) ...focused included files contents (all contents code focused on the subject at hand) custom int function() calls instead of CHAIN and EXEC macros: ...those generate hidden multi-threading issues. ...they are interpreter inputs, meaning CPU resourses wasted at doing the same thing over and over. ...more to say here but it would be realy, realy! :geek: out of topic! Exactly each of those topics deserves further consideration and discussion in order to satsify more than a single user needs or preferences. This is another good motivation for scripting. All those who are satsified enough with the default behaviour will have no means to compensate for the obvious immersion drag coming fro having to rely on a keyboard. And I am happy to be able to try something when I feel the urge of keeping my hands where they are at times where my eyes and my TrackIR are busy. Keyboards are the worse ergonomics device of all times aside of the TouchStream Fingerworks exception that led to Apple Multitouch technology. Touch screens with gestures could be worth exploring too. * BTW, TARGET does not make us loose anything from the P&P functions. To make that happen (TM SHOULD HAVE DOCUMENTED THAT), Joystick default layer has to be mapped to the related keyboard shortcut and Throttle has to get all DX-Input bindings available and that's it! This is written nowhere and I still do not understand why! - Joystick has only transcient switches, just like a keyboard, unless we keep our finger on, it won't send keystrokes. - Throttle on the other hand can drown us with any keystroke bingings we put there... just don't. Even better: Direct input is ready to handle idle state transitions which aren't even part of the 256 defaults and DCS detects them quite well.

@Revvin: My point was limited to the CH Editor part, not about scripting capabilities I don't know. And I would not take CH's editor capabilities you mentioned as beeing an asset we could consider at the same level as scripting languages features. The editor is just a tool and I even don't talk about TM's counterpart as I never used it either. About CH's vs. TM's hardware choices, I'm no experienced sim user and I will digest what others like you have to say about before I pretend having any valuable point to share.

Yea, and the most part of your time is spent jumping on your keyboard and mouse as if you had not enough buttons on the HOTAS and TM or CH scripting features were not there. But I agree, I also believe that Logitech is right. they give you the minimum they can with each of their product and spend their energy on the next one that will get them more profit... They are smarter than Thrustmaster indeed, when it comes to business, they seem to know that scripting is mostly unused.

Well, as I don't have this error, there must be some difference between your working environment and mine. The reported error is about OUT_ID_LED_5 which is defined in the file hid.tmh (line 102) which is automatically included by target.thm. Those tmh files can be found in this installation folder: C:/Program\ Files\ (x86)/Thrustmaster/TARGET/scripts. target.tmh defines.tmh hid.tmh sys.tmh You can check your own folder location under this Script editor dialog: Options->File Paths. I don't know what's wrong but it should not be too hard to find out. It could have been a question of interpreter version, but I have the only available one which is installed by TARGET_v1.0.exe. Have a look into hid.tmh to see if you find the missing symbol. Maybe you will find something wrong on the way. ivan

When in mention emacs and gvim, i guess I can't be wrong, kind of like comparing a Mercedes or a BMW to some custom car. I'm sure CH never claimed to provide any editor for programmers otherwise, I would have heard about it years ago. But please let's just put an end to this digression, my point was about TARGET, not CH and certainly not how we put characters into a script file. -- Back to the topic -- When TM, and CH, take the time to build advanced scripting tools, some users have to show they appreciate the effort and this is what I'm talking about in all my posts, even this one that I did not want to be just another reply. Effectively using TARGET does not come easily to people who are not familiar with any programming language. And, even though I know nothing about it, I'm sure that with CH tools, difficulties are the same. This is real-time multi-threaded programming, and even for experienced professionals, it will always be a challenge. This is why I know it can't be made easy through any kind of friendly editor. Once again, trial and error, learning ant talking about scripting is the way to go! Quite like any other subject discussed in this community. People ask for help, those who understand the question and have some experience to share try to answer them. I'm no pilot and I appreciate what those who are have to say about avionics. The ease that comes with years of real life experience cannot be missed when your read their explanations. My domain is about software and I am not interested at discussing about what or who is best for the sake of argument. I'm willing to be helpful on subjects I know, that's all. So, if there is a real point in comparing TM to CH, I will step back as long as I miss one half of the experience and let you help those who are facing that choice.

Thanks and true, and that's why I don't talk about it. What I'm saying is all about something I'm working with and would like to share and exchange experience about, not just opinion or evaluation of what I know that others don't. Maybe what CH has to offer is better than my TM device and its environment but it was not the subject. When considering TARGET scripting language, editing capabilities are not involved, they are just the collection of tools used to organize coding instructions and I simply don't use TM tools to generate my tmc and tmh files, I won't bother to compare them to CH counterpart. In short, you are right, I don't ;)

I agree with this type of observation about TARGET and I would say that more of them are obvious. As a programmer IRL I can tell this scripting tool is overkill to say the least. But driving a Ferrari to go shopping wont heart anyone, first gear is OK back and forth. Not everyone needs to use all others but for those who care learning how to, it's a blessing. About an integrated GUI, I would say that to the point where TARGET is opening advanced features, Thrutmaster is well advised not to try replacing some real editor like Notepad++ , gvim or emacs. All of us here are committed enough to read -and learn- a 600+ page manual to play with VHV, UHF, CDU, ... gauges and trouble handling... TARGET requires users to learn how to use an effective editor. I don't know what CH environment offers but their editing tools cannot compete with a one that has been use for ages by professionals... and TARGET needs one indeed... if you want to go beyond Target Script Editor manual which is just about the first stages into what you can do. Once more, as a conclusion, we all have to understand that TARGET is overkill and each has to set boundaries to the exploration area.

Hi hreich, at the moment, my files are meant to be friendly only to users who have studied TARGET programming to the point where reading my code makes enough sense to get what each line is suppose to do. This does not mean they can't be used at all if it is - not yet - the case, but to make that easier, I need to take some time to describe each of my bindings logic. In the mean time, you can just launch DCSW_main.tmc with TARGET Script Editor. It will provide the mapping illustrated by the attached DCS_Bindings.zip html file (see: IOUMD). You can check Throttle DX-Input bindings with Device Analyzer and Joystick generated keyboard events with EventTester. * DCS controls have to be adjusted by importing my TM_Warthog_Combined_1108_ivanwfr.lua that goes with what the code sends when switches are activated * I planned to further describe all this code at some point and I was expecting to do this through some dialog with those interested by the subject, but it looks like I am still the only one who cares. Let me know if I can clarify something if you have any kind of difficulties. I am pretty sure there is matter for improvement about many aspects, as for example the one about yesterday evening snap views handling that was sometimes erratic until I found that 32ms key sampling time was too short when DCS is running.

I don't give a dam for Guillemot image. I'm not and to clearly show it, I'm ready to say anything that I could not do if I were: ;) For instance, "my boss is a dumb ass, he does not understand anything to TARGET and I wrote it in the main DCS community forums so that everybody would not about it! " As to CH scripting, I don't know and, as I have a TM Warthog, it's not relevant to me. Maybe it's even better than TARGET and, if it the case, I'm happy to have another manufacturer caring more than Logitech does in opening for customization "that works".

:shocking: You see, once more! a reassuring advice to steer away from TARGET. Why that ? Why did Thrustmaster did care to give us this customization tool ? Why would they bother to take customization into account when they read this from simmers ? Please would you care to explain this promotion of passivity ?

P&P - plug and play... ...as in open your wallet, purchase, plug then play. ...as not in learn how it works, what you can do with it and get involved in order to play superman without a keyboard. This is what we do with this sim and with HOTAS being the main piece of hardware involved, it deserves some effort. And about the scripting feature, I am so surprised they did something Logitech considers completely unnecessary (look at Setpoint openness - or lack of) + how - even simmers - don't care to use even the "easy" GUI customization tool... This is obviously a commercial mistake! ... this energy could obviously have been spent into some useless marketing effort with the same results ;)

A better answer would be Yes! ...Unless you want P&P. TARGET gives you scripting capabilities you will never get from any other manufacturer. So much so that very few are those who use it in these forums. From a commercial stand point, is is obviously uncalled for and they won't do the same mistake twice. ...I feel so lonely looking into TARGET - Advanced programming :cry:

This is how: include "target.tmh" int main() { Exclude(&HCougar); Exclude(&T16000); Exclude(&LMFD); Exclude(&RMFD); if(Init(&EventHandle)) return 1; th(); } int th() { MapKey(&Throttle, SC , DX1 ); MapKey(&Throttle, MSP , DX2 ); MapKey(&Throttle, MSU , DX3 ); MapKey(&Throttle, MSR , DX4 ); MapKey(&Throttle, MSD , DX5 ); MapKey(&Throttle, MSL , DX6 ); .../... MapKey(&Throttle, IDLERON , DX31); MapKey(&Throttle, IDLELON , DX31); MapKey(&Throttle, CSU , DXHATUP); MapKey(&Throttle, CSR , DXHATRIGHT); MapKey(&Throttle, CSD , DXHATDOWN); MapKey(&Throttle, CSL , DXHATLEFT); } int EventHandle(int type, alias o, int x) { DefaultMapping(&o, x); } If you would like to see this working in Device Analyzer, the completed code is in a file named th_DX_main.tmc in the archive DCS_ivanwfr_110607.zip attached to the bottom of this post. All you have to do is to run this file in TARGET Script Editor and launch Device Analyzer. However, to actually have it working with DCS A-10C, controls have to be altered by loading the related configuration file TM_Warthog_Combined_1108_ivanwfr.lua which goes with it. This would be the equivalent of the P&P Throttle part. As for the Joystick, no need to reserve DX slots for that one - a good thing BTW as there are no more available ;) - keyboard mapping is quite natural as all its switches are the pulse type and keyboard event mappings are absolutely the way to go.

I would suggest mapping DirectInput values to all those Thottle switches and let DX API detect OFF states by design. Keystrokes are on-off transitions with synchronization issues and they defeat the very purpose of the device. Even worse, allowing depressed keys to be persistent will inevitably have devastating results when keyboard focus gets directed to the desktop or any application window.

Based on last patch Input Keyboard default.lua changes, I would suggest theses keys: [813] = { ["combos"] = { [1] = { ["key"] = "[b][color="Red"]B[/color][/b]", ["reformers"] = { [b][color="red"][1] = "LAlt",[/color][/b] }, }, }, ["name"] = "View briefing on/off", ["category"] = "General", ["down"] = 1536, }, [814] = { ["combos"] = { [1] = { ["key"] = "[b][color="red"]\\[/color][/b]", ["reformers"] = { [b][color="red"][1] = "RShift",[/color][/b] }, }, }, ["name"] = "Show debriefing window", ["category"] = "General", ["down"] = 1537, },