ivanwfr

And you would be wrong trying to ingest more than you can digest... you'd better slow down, walk the dog or something...

As you said, and it's a smart move on your part, there's always another way to do things and I tried your code just for the fun of testing the auto zoom idea... It works and is kind of fun to play with. But guess what... I had some issues ;) I won't get into details here but the point was about delays handling when you press the trigger 1 + 2 stage all the way in at once in a very short time. What happens is that the sim gets the second stage "Space" press but misses the release, resulting in Gun sustained firing. I found a solution but with a level of coding using DeferCall() instead of Sleep(): The difference is that Sleep() just freezes everything and the Space key input is rushed down to 1 or 2 milliseconds. Instead, DeferCall() is just postponing our zoom keys release and the space pulse keeps its default duration. Another point would be about the effectiveness of this combined actions... as a first impression, it is more about fun than efficiency... but fun is good ;) I included this util/util_PAC.tmc version into attached archive or this thread: TARGET - Advanced programming // PAC & ZOOM // Note: // Using sleep() instead of DeferCall() would make any intervening // user key input duration down to 1 or 2 millisecond. // Result is that key release is missed by the sim. // ... In this case if you press Trigger first stage and second stage at once, // Gun won't stop firing. int pac_zoom_state = 0; int pac_zoom_toggle() { // see js/js_MI.tmc for H2U mapping pac_zoom_state = (pac_zoom_state == 0); // toggle if(pac_zoom_state > 0) { flashLED(1); // see util/util_led.tmc } else { flashLED(0); PAC_out(); } } int PAC_in() { // see js/js_MO.tmc for TG1_MO press ActKey(KEYON+ USB_P); // PRESS [P] "Gun Trigger (first stage)" [HOTAS] if(pac_zoom_state > 0) zoom_in(); } int PAC_out() { // see js/js_MO.tmc for TG1_MO release if(pac_zoom_state > 0) zoom_out(); ActKey( USB_P); // RELEASE } // --------------- // PAC ZOOM IN-OUT // --------------- define ZOOM_PRESS_TIME 800 define ZOOM_IN_KEY USB_KP_ASTERISK define ZOOM_OUT_KEY USB_KP_SLASH int zoom_in() { ActKey(KEYON+ ZOOM_IN_KEY); DeferCall(ZOOM_PRESS_TIME, &deferedKeyRelease, ZOOM_IN_KEY); } int zoom_out() { ActKey(KEYON+ ZOOM_OUT_KEY); DeferCall(ZOOM_PRESS_TIME, &deferedKeyRelease, ZOOM_OUT_KEY); } int deferedKeyRelease(int key) { ActKey(key); }

Yea, I thought so and I did put my fingers in those files and replaced the original after some global editing with a programmer editor. This can spare you many tedious clicking in ME and helps with some smart regex juggling instead of having to adjust a whole bunch of waypoints altitude or the like. But I could not make it all the way to the point where I get the whole big picture. I was looking for logic, not piles of data and you can see the logic is not there. Even the data seems to have issues sometime like heading, speed, altitude... you have to gess whether you have air speed, ground speed, in knots or meter/sec, with heading being 360 complements! For instance, I could not even find how to correct first version of Sabre-TLA BFT09_Instrument_Approach_and_Landing_V1.0.miz after hours of tuning and test flight ... was fun though but it became boring by frustration for not learning anything worth to get you some reusable experience. I did not try his new BFT09_Instrument_Approach_and_Landing_V1.1.miz version, but I will definitely look at what has been corrected. If you're looking for a way to spend some of your time with, this is one, but you'd better be prepared to get back to square one at the end.

I tried making sense from the mission files where everything is stored inside the miz archive; - All you find here are your mission value tables, no trace of the code that use them. - LUA table stringification does not order keys... you have to deal with a pile of rubish an try to guess what to make of it. ... good luck

As you can do pretty much anything you want with AutoHotkey, I' m sure there would be a way to do that... But you have to tell how to make the difference when you need to address what nomdeplume described to interact with the clickable cockpit buttons. That could be through some delay policy, modifer key, combined TARGET scripting...

My Event Viewer is full of Logitech explosions, and I don't care anymore ;) TARGET GUI is a nice tool as long as you don't reach one of its boundaries and, unlike with other manufacturers configurator, when you do, you have a way out! The script way is not an easy one but it will get you to a point where you feel in control with more answers than questions. And this is not something to be neglected in computerland where most people believe bugs are like flees in Africa and the only thing you can do about it is to keep your mouth shut and breathe by the nose. The only thing I can't get working correctly with TARGET at the moment is about interacting with games that have stubborn joystick-Windows input bindings with no USB/DX-Input/default device in their controls customization. In those situations however, the script gives the opportunity to bind any keyboard event to all our buttons. I still have to solve poor or nonexistent axis mapping like built-in DCS Invert or Slider-offset. But I know that TARGET has all the necessary features to handle the situation ... at the price of some hard work, again.

Ok, good to know that this could be the norm with LOGI in the loop then. Kind of low profile issue we have to feel lucky with as it could be worse. These are times when the TM HOTAS looks even more alien on my desk.

The only action I could see having some effective results when something goes wrong with my G27 at times has been selecting it as "Game Controllers-> Advanced...->Preferred device". Still, sometimes a dialog pops up telling me that Logitech is sorry for the inconvenience and asks me if it's ok to send a dump of something to them about an issue that crashed my Logitech Profiler (LWEMon.exe) ... And yes, it's related to TARGET hijacking of 2 USB devices replaced with a Virtual one when I spam F5 to reload some modified script ... But this does not happen very often! And as my kb is an MS Ergo, it's all I can contribute on this one. I've always appreciated what Logitech has to offer (at a price!) and own way too much of their stuff. But it looks like they are as bad at driver/software as they are good at hardware design. I'm at a point where I expect anything to happen to my LOGI hardware when something moves near my desk. [edit]As USB device<->driver are registered with their respective entry-number, you could try to shuffle connectors and see if some combination may work better. * When you plug some device in one of your USB connector, Windows assigns a default driver to that entry (MS "optimization" policy I presume ;) )

The only one I know of is TARGET_SCRIPT_EDITOR_basics.pdf ... but the ones you need most next to this one are any .tm* files that works with some explaining for what is not looking like copy / paste from the manual. DX-Input and Keyboard shortcuts are all still looking for some documentation in order to be usable by normal people. My point is that both ED and TM are to blame for having skipped the integration part. DCS keyboard shortcuts and TMW HOTAS technical design are perfectly specified to work as a KB+DX-Input bundle. The only thing that's missing is the Plug And Play mapping I've attached in my previous post. I think of it as the complement to an unfinished business, not more not less! I have invested, by personal taste, a pretty large amount of my time to experiment with this script language. This is why I can tell that if you also intend to spend time on the subject, you'd better understand what you're doing. Because, if you skip the learning period, you will end up looking for things that do not work as expected for hours. I would be glad to answer any question, as it would put all that I've learned to good use.

CONTROLS - Rudder - - Logitech G27 Racing Wheel - - - JOY_Y;JOY_SLIDER2 - - - - AXIS TUNE Axis Tune: JOY_Y (right pedal) - - - - - Deadzone = 0 - - - - - Saturation X = 90 - - - - - Saturation Y = 50 - - - - - Curvature = -50 - - - - - SLIDER = [Checked] - - - - - Invert = [Checked] ... red dot (pedal pushed then released once) full left rest position, near top of curve, goes down+right when pushed and moves black square from its full right start position to the left up to the center and has very little effect from mid-to-full pedal excursion. Axis Tune: JOY_SLIDER2 (left pedal) - - - - - Deadzone = 0 - - - - - Saturation X = 90 - - - - - Saturation Y = 50 - - - - - Curvature = -50 - - - - - SLIDER = [Checked] - - - - - Invert = [unchecked] ... red dot (pedal pushed then released once) full right rest position, at origin of curve, goes left+down when pushed and starts moving the black square from its middle rest position to the left when it reaches 1/3 excursion. But JOY_Y graphics are all wrong as the "Invert=checked" option is not correctly applied here... and works perfectly in-game! ( I did file a ticket about that but who cares :( ) In fact, , with Invert=unchecked to compensate, aside from a "center-point-symetry" representation, JOY_Y (right pedal), display shows that we can move the black square : - from full-right to center with JOY_Y (right pedal) - from center to left with JOY_SLIDER2 ... center being the rightful Rudder rest position Just go on experimenting with all this and you could get something working from all this mess in-game with "RCtrl+Enter" (Show controls indicator)

Hi, I did this exact same trip a while ago and reported my findings here: TARGET - Advanced programming And here is solution for a comprehensive DX + KB-shortcuts TARGET working base in the attached bundle: PNP_ivanwfr_110818.zip There are two ways to deal with TARGET: The first is through the learning curve (my way with programmer.background=1) The second would be to try to understand what you can and ask for explanations about what does not make sense (programmer.background~=0) (In fact, there is a third one that would be not to read anything from the manual and those .tm* files and just ask but I would not recommend it as it may piss off some people along the way)

As I recall, you've just missed the most important part about this mixture spice. Everything is in the curves near those red dots. Nothing must happen there: NEARLY NULL CURVATURE does the magic... Kind of DEAD ZONE where both pedals keep doing nothing until you touch ONE of them (never both, no matter how lightly) *** If you don't do that, they keep fighting against each other, no matter how small values are involved, they just flood the sim input resulting in random and useless deviations. Try to make them look like mine and tell us about the result. BTW... what is your native language, it could be we have the same ;)

Maybe if you attached the same relevant screenshots, we could see where the IN and OUT dots are when pedals are at rest. Then as - SO SADLY - Logitech "drivers" are in also in the loop, plus your mod, each adding to this rather tricky scaffolding :music_whistling: But let's look for a solution...

Here is the trick to catch the catch! Press the Wheel Brake On/Off 'W' key. Do not release it Hit the 'Pause' key Release the 'W' key Unpause the sim At this point, from the sim point of view, the 'W' key is held down until you release it with an extra key press-release.

Some other info that may help here: Olgerd's User files A-10C Cockpit arguments and this Speed's LUA thread post of mine about Exporting to TARGET socket attached solution (...that worked quite well before 1.1.0.9 patch ... )

L_WIN + KP_#(*) ... to select the "[u]Snap View of Interest[/u]" R_ALT + KP_0 ... to "Save Cockpit Angles" for that view * KP1 ... KP9 : Is the Snap View of Interest that remains in effect until you explicitely do something to change it! ... meaning: this is the one you're going to redefine when you hit R_ALT + KP_0, no matter what you do in the mean time (...so, you can do anything you want BUT KP related). And here are some details on how it works, in order to translate it precisely enough for TARGET to understand what you want.

I agree with the positive way to look at things in general, and it would easily apply here as far as we have to deal with smart people, no need to repeat that again and again. But even smart people can have their moments or priorities in need of some comments that may help looking for balance. I know that because I'm smart, just like everyone here ;) and I DO mistakes. I'm even sure I do more mistakes than others. Those that do not do much of anything, just to keep on the safe side. In fact, I'm just trying to help here, isn't that obvious ?

One thing I remember after I got that working pretty fine was that I had to give up expecting to have a feedback at some stage... The GUI part is just a little below the minimum it should be! (this is an internal usage tool we're not supposed to have ... the kind that never gets finished ;) ) Try to do each step just as if you'd have been granted an acknowledge right after having done what you are expected to... you won't get it at some expected time but I could make it as soon as I understood that...

As I understand it (with a rather limited ranged experience) the use of dostring in any recurrent function is the best way to create :doh: unoptimized piece of code in lua where any other scripting language would put some bytecode to replace it at first pass. What I'm trying to underscore here is how far ED decision has damaged this kind of work for the time being. I hope this is just a temporary situation but I can't be optimistic as long as I see that Developer's journal - Lua exporting in DCS page sitting there with large portions of it being so obsolete for years! Even worse, nobody cares to delete it :huh: But I'm sure you learn a lot, just like I used to, from all those not so technical parts around computers. Silicon based are easier to deal with than carbon based after all, everybody knows that!

GG! Happy to know you could find a solution on your own.

Yea, the _G table is the very means to isolate access controled threads in LUA with setfenv(0, nerfed_G) ... It looks more and more like you' re digging a tunnel between your bed and your bathroom As long as ED wont give back the door handle, all this looks like a waste of hard work. If I say that, it's because I could not go on with what I planned to do with TARGET on my side ... so

Well, that's really not a good sign they're sending to the community and I will keep that in mind. For those who are expecting to attend Le Bourget Meeting at the end of this month, this has to be reported to TM representative as something difficult to swallow for their customers who could not miss your report in these forums. I once had some issues of the same kind with a monitor arm from The Human Solution with a Gas-spring cylinder and they just sent me 2 spare parts with no charge to France. I think you should just hang on until you reach the right person to talk to!

I've posted something about wrong heading triggers in that mission (post #200) and got no reaction of any kind.

Yeah! Nice question dodging facing a 600+ pages answer ;)

Did you ask TM to simply send you the missing part? I'm pretty sure their QC expects some mistakes of this kind to occur, be solved and reported as such in these forums! Cause, bad service support can ruin any marketing campaign. I'm no TM related in any way, so, please, tell us how they behave from now on. It's always good to know what to expect in case of trouble.