Pete Dowson

You can get the axis value in a Lua, but it currently means assigning the axis to execute the Lua plug-in (as well as the throttle as now). It gets the axis value as "ipcPARAM". But that Lua is re-executed every time the axis value changes, so all it can really do is store the value someplace that the true plug-in you need can get it -- either an offset or, better, a Lua global. That's what i meant by complication. If you leave it a week or so, I'll be adding facilities to Lua to read joystick values, and then it'll be much cleaner. Hmm. I'm firmly of the belief that you shouldn't need to check with specific graphics on the screen. That's the idea of detentes on the hardware in the first place. Better, in my opinion, to just tell the axis value to go to the known position for ground idle. But that's your choice of course. Regards Pete

You could write your program in Lua. That's one way. Otherwise you could write a short Lua program, based on the one called "Log Lvars", but write the values you are reading to free FSUIPC offsets (those from 66C0 to 66FF inclusive are available for general use). Then your program could read them via the FSUIPC interface. Or the Lua program could write them to a file which you could read. Regards Pete

Which "last" version? 4.728? Please be specific. I also need to know which version of FSX RTM, SP1, SP2 or Acceleration? Regards Pete

What is this "well known wind problem using ASE"? Are you talking about FS9 or FSX? As far as I'm aware there is one major wind bug in FSX (and FS9) which causes sudden 180 degree wind changes, an error in their interpolation between neighbouring stations, and which Active Sky strives to correct, not make worse! If you need them at all, why would you need to switch therm off? I use them all the time and i never use PMDG aircraft. What's the point? I suppose it might be possible, but it would certainly be very messy as there is no connection whatsoever between aircraft-specific and profile settings and the assorted weather facilities. And the smoothing hook into FS would still need to be in place so it means FSUIPC is still being called every time in order to deal with the winds. I need to understand the reason for such a messy and apparently wasteful change before i even look into it. Regards Pete

"Mouse over it" in Windows Explorer? If Windows says there's a problem it can give more information. i need that information. This is certainly looking more and more like a Windows system corruption, but I want to make sure it isn't something I can avoid in the Installer. I need the information for the "crash" which Windows is reporting, and I need to see the Log as far as it got. Regards Pete

Can you please tell me which version of FS and FSUIPC you are using, please. No. NEVER do that. Tell me what versions you are using and I'll check. I can't really do anything otherwise. Regards Pete

I don't think there was ever any difference. It was always a case of making the whole of a macro file for a specific aircraft in one go. There is most certainly something wrong with your FS installation, or maybe the disk drive or its drivers, then. There is no difference adding one macro or many. Each does exactly the same thing. The software does not 'deteriorate' over time, through use. There is something in your FS installation or disk transfer which is blocking. Regards Pete

So, despite not moving the throttle lever, the Saitek throttle is still sending assorted values to FS, including that 16000 "spike"? If so there is something very wrong with it or its driver. Is it very old and needing cleaning? Pete

It's never been needed. The spike removal already provided is for + or - 16384, values normally impossible. The facility was to remove spikes caused by a software bug at the time, not hardware. Why are you moving the throttle lever during A/T use? Is this to match the A/T positioning? normally with FS you have to park the throttle somewhere without jitter. Pete

Sorry, I'm even more confused now. You are writing a program, and instead of reading the L:Vars yourself you want FSUIPC or Lua to read them and log them in such a way that your program can access them? Perhaps you should tell me what your aim is so I can understand, because it doesn't make sense to me at present. Sorry, but I'm out now, not back till late morning. Regards Pete

Okay. so you know, or can determine, the correct negative FS throttle value for ground idle? That's one of the needed parameters. Yes, i understood all that. what i don't understand is why you want to do it with a section of the forward thrust area of the throttle lever. Yes, you can do it like that -- with a Lua plug-in still -- but what is wrong with simple button programming, via Lua, to do it all in the actual button/detente area, as I suggested? Yes, you can do that, but the hardware axis value isn't easily obtained. This does suggest to me that I should add a new function to the Lua ipc library to read a specific joystick axis value -- it can read button states and hats/POV (point of view) states, but not directly joystick axes at present (without using COM/HID direct device access facilities). The need has never arisen before. I'll put it on my list. Meanwhile, there's more on the rather awkward current alternatives below. Yes, you can do that. You might have to experiment with the timer to match it. What better? You can poll in a loop with a delay, or simply use the timer event facility to call a function at the correct intervals. There are lots of Lua examples installed in your Modules/FSUIPC documents folder, and even more in the User Contributions sub-forum. If you adopted my suggestion of using multiple pressings of the real reverser button instead of part of the forward axis range I could knock it up for you in a few minutes as it is so much simpler. With your method, to read the incoming axis value pre-calibration is not so easy though -- FS stores calibrated not raw values, so you'd either have to manage by using the axis range to set some FS offset, or probably more effectively use another Lua plug-in which stores the axis value as a Lua global so the resident polling one can get it from there. The whole method that way seems cumbersome and complicated comparatively. I'm not sure why you don't like my suggestion? Lua, via the COM (serial port) library does support HID (human interface devices) -- joysticks -- and can read axes, buttons and so on directly. in fact it can read many more than those supported by FSX and FSUIPC nativelyt as it bypasses DirectInput. But that's a rather over-the-top route to what should be solved so much more simply. I'm afraid I'm out for the rest of the evening, so I won't get back to you now till tomorrow (Wednesday), and late morning at the earliest as I have a dental check-up early on. Regards Pete

Yes, I understood all that. But then you said which strongly suggests that the axis output is still changing below the detente! Yes, I understood that too --- it was you suddenly stating that the range you are talking about for this was still pressing the button! ("all button-press"). Also, i thought you wanted it increasing not to 0 but to the "ground idle" negative value, whatever that is. How do you arrange that? What is timing this 1 second? Using the term "conditional button" is confusing here because there isn't one. Please instead describe what you are doing to invoke this change. So this non-existent "increase button" is another one like the non-existent "conditional button"? How do these buttons become invented? Surely all you are wanting to do is program different actions according the the state of the real reverser button and the current actual position of the axis? Such things can easily be dne in a Lua program. Certainly all this can be done most cleanly in Lua. Another way, not needing to eat into your normal range of axis movement, would be to use the number of separate presses of the real button to select the next action i.e. first real button press = throttle set to correct -ve value for "ground idle" (you still need to determine that value, as I keep asking). second real button press = repeating 'throttle decr' whilst button held, for reverser application third real button press = increasing throttle slowly to ground idle value The return to normal idle is then the normal movement of the throttle. If you didn't want reverse, only use of ground idle, then you'd not pull back again, only pressing the reverser button the once. The Lua plug-in can be Auto-loaded for that specific aircraft and simply loop monitoring the reverser button at, say, 50 msec intervals.. Regards Pete

So the axis values still change below the detente? That's rather surprising. I did think the button was there instead of axis changes. I assume then that you have to calibrate such that the 0-1024 range only supplies 0 to the sim, i.e. the idle dead zone? Yes of course. But why use this axis range when it all happens because the real button is released? Why not simple trigger the Lua on the button release? What is the negative value the aircraft needs for "Ground Idle"? You need to determine that value first, surely, otherwise how can you hold it stable in ground idle as you said you needed? Pete

The range 0-1024 is all occupied by the button press? I thought the lever axis output would reach 0 before pressing the button and then there would be no more axis changes? This is getting more and more confusing. There must be a recognised input value from the axis, else how can you select this separately from 0 = idle? Hmm. Yes, because "releases!" can't be repeated like presses. So, to get a slow return to 0 (or whatever your "ground idle" is) you'd need to assign the release to a Lua plug-in I think. That could simply loop do small increments with a delay built in till the value for ground idle is reached. See previous answer. You need to determine the throttle input value needed for "ground start2 and program the Lua to return to that. No, it isn't really 'trivial' when you look at what is needed. It isn't just because there's no conditional facilities on the axis range assignments, but also because there's no way to "re-map" the rest of an axis separately without processing all of the values. The normal throttle assignment will be sending values to the throttle unless the area you wish to re-use alternatively is all calibrated as a dead zone returning 0. No. Please see my earlier reply where I pointed out that the whole point of my adding the Lua facilities was to avoid tampering with and possibly wrecking original complex code dating many years. Lua adds ways of doing almost anything, and it is risk-free and much easier. Regards Pete

Yes, that's something in common with pretty much every throttle quadrant. I've known folks to simply glue a small piece of rubber or plastic on the edges of the groove to act as a detente you can feel as you move the lever, but without obstructing the lever otherwise. The problem then is that you have to divert the entire throttle axis through an alternative route, just so you can interfere with that lower region. That is unless you would be happy with all of that being calibrated as "idle" -- i.e. below the not-reverse-zone minimum calibration point. Then it would depend on the actual axis input seen by FSUIPC not changing so it doesn't override what you are trying to do. Really that's pretty similar to calibrating that area as the reverse zone in any case. Are you saying it needs to be sent a negative throttle value to get ground idle? I've never seen anything do that. what negative range constitutes this "special" idle? Right -- that sounds like the actual axis input stays at zero and doesn't change. Since FS/FSUIPC only act upon a change in axis inputs, you have to get to a positive number to get out of reverse. I assume the "reverse button" is released/unpressed when you let the lever go back to the detent? if so you could program the button release conditionally. Trying to use a range is never going to work without a fairly sophisticated Lua plug-in handling the whole axis operation.. Why can't you tie the action you need to the button being released? I thought the point was to let the reverse reduce slowly enough so you don't get the "slam". Why do you need to control it with the lever, how is that 'key'? What do you mean by "pressed" here? The button can be pressed, not an axis range. You can do almost anything with a Lua plug-in. That looks like something which would work okay with a reverse zone set between the lever positions you've labelled 1024 and 0. If the J41 needs a negative throttle value to achieve "ground idle" you'd need that in any case, surely? Regards Pete

There's no "Demo" and never has been. FSUIPC is and always has been a free install for its prime purpose, acting as an interface into FS for other applications, and add-ons. Registration merely buys access to extra user facilities, and only came about when I nearly had to finish development and get a job because of personal circumstances. Adding goodies and charging for them allowed me to continue developing it from FS2002 to FS2004 and thence to FSX, ESP and Prepar3D. And it is still a full-time job. There is no such Link "provided during installation". The only link is in the "Installing and Registering FSUIPC" guide and that is to this Support Forum. There is no single "FSUIPC3/WIDEFS6 product key", only the offer of a bundle deal if you want both. The main download site, www.schiratti.com/dowson has separate links to each of FSUIPC3, FSUIPC4, WideFS6 and WideFS7 purchase pages. Again, there is no joint purchase page. To get the bundle you have to actually select it. And each of those links works correctly, taking you to the correct page. Really? You've done a survey already? Please, I think you have not explained any issue at all. There's no way I can find that you can possibly go wrong except by explicitly clicking on the wrong links, not reading what you are selecting, and even confirming despite all of this. As far as i can see it is all as clear as it can possibly be. I didn't design any of this, but they've done a good job. If you can identify the flaw you think you've found then I will certainly check it and get it fixed, but nothing you said makes much sense to me at present, and it simply doesn't relate to the reality of what is there! Regards Pete

I'm a bit confused by your question. If you want to see when L:Vars change, there's a Lua plug-in provided in the Examples installed by FSUIPC which logs L:Vars and their changes in real-time to an overlain Lua display window. It's called "log lvars.lua". If you are instead referring to internal FS values, not local gauge variables, then you can monitor the relevant offsets using the FSUIPC monitoring facilities in the Logging section. You'll need to find the appropriate offsets and their types from the documents provided in the FSUIPC SDK. For instance the lights are all individual bits in a word (U16) at offset 0D0C. Regards Pete

"app.dll"? That's the name? There's no such dll in either Windows or FSX. If FSX is crashing within such a DLL you need to find what add-on it belongs to -- certainly none of mine. The Log shows FSUIPC running fine, and terminating normally after an FSX session lasting 945 seconds (over 15 minutes), so FSX certainly couldn't have crashed during this time. Regards Pete

There are no defined reverse ranges on most quadrants. FSUIPC allows you to determine the idle position and reverse section anywhere you like on the lever movement. That's the whole point of its definable centre idle section in the calibrations. How is it achieving this "slam to idle"? What is it sending to do that? Presumbly the axis input isn't changing all this time, remaining zero, so it must be sending something on button release? Can you assign button release to something like a Lua which could do a timed loop to increase the throttle value to zero slowly? Regards Pete

Yes. And it shows a successful FSX session, albeit closed a minute or so after starting. There's no sign of any problem, certainly no "hanging and errors" per your thread title. Regards Pete

No, there's no provision for conditionals in any sections other than the Buttons sections. Anything ambitious elsewhere has to be accomplished by Lua files. I added the complete Lua system, and continue to expand its capabilities with more and more library functions, in order to avoid the complications and more error-prone path of inserting extra facilities into existing mechanisms. Why wouldn't that be possible by simply assigning it in that range? What would another condition add to the condition that the range imposes of itself? There is no reason any reverse zone properly calibrated "slams" to idle. On most aircraft equipped with reverse there is a range of varying reverse thrust, from as much as 25% of full forward thrust (the actual proportion is set in the Aircraft.CFG file) down to zero. Why are you seeing a sudden "slam" movement? Regards Pete

FSInterrogate is actually a contribution by Mr. Liljendal, so he gets your thanks! ;-) Regards Pete

You managed to find and show the Install log. The run-time FSUIPC4.log is a similar file, and in the same folder. Pete

Hmm. you said "when I install ..." and showed the Install log. If FSUIPC4 isn't producing a Log file then it isn't even getting loaded by Simconnect. Please see http://forum.simflig...irst-installed/. If there is a log, please show it to me. Usual reasons for such hangs include SimConnect mismatches, and corruption of WX files. Pete

Thank you for your contribution. It looks useful. did you find the PMDG offsets yourself? Just one comment, hopefully helpful to you. I see that all your events call the same function: event.gfd(lemcppro,"checkallinputs") event.offset(0x622e,"UW","checkallinputs") event.offset(0x62AD,"UW","checkallinputs") event.offset(0x621E,"UW","checkallinputs") event.offset(0x6230,"UW","checkallinputs") event.offset(0x62BE,"UW","checkallinputs") event.offset(0x62BF,"UW","checkallinputs") event.offset(0x62C1,"UW","checkallinputs") event.offset(0x621D,"UW","checkallinputs") That function does this right at the start: function checkallinputs(model, unit) -- retrieve al the values associated with this mode.unit mngspeed=0 gfd.GetValues(model, unit) When that function is called because of a change in one of the offsets, the "model" will be the offset and the unit will be the value in that offset. Therefore when you do "gfd.GetValues" the results will be, er, unpredictable. Luckily it doesn't matter because you don't use any of the values you get from the device in any case -- I assume all the buttons and knobs are assigned more directly?. You could remove the event.gfd which isn't needed, and the gfd.Getvalues, and maybe re-head the function: function checkallinputs() though perhaps the name "checkallinputs" is then also inappropriate? Maybe "checkpmdgoffsets"? Best Regards Pete