Pete Dowson

The User Contributions subforum has some practical examples with real add-on aircraft, sadly not the one you are interested in at present. But perhaps they will help. And once you've solved your problems perhaps you you post your solutions there too? Sorry, I don't quite know what you mean. What "keyboard shortcut"? Mouse macros can be used from buttons, keypresses, programs or plug-ins, just like any other macro or control. If you mean execute a macro or Lua plug-in via the FSUIPC programmable interface, then of course it is possible. It is done via offset 0D70, as documented. You can also execute macros from a Lua plug-in using the ipc.macro function, also in the documentation. Other ways exist too, like having a program or Lua plug-in use a virtual button in the offsets 3340 (and following), then programming that button in FSUIPC's assignments to execute the macro. That gives you a little more flexibility for different aircraft, as FSUIPC can switch assignments according to aircraft loaded. You could of course read the aircraft name and do that switching in an external program or Lua plug-in, but it starts getting rather complicated the more aircraft you want to handle that way. Regards Pete

Maybe it uses FSUIPC for something else? Just not to inject AI objects. Regards Pete

No, FSUIPC contains no facilities to inject AI objects. The only facility vaguely sounding like that is the one to place multiplayer objects into the FSUIPC TCAS tables (not into FS) so they show up on TCAS gauges reading from FSUIPC. FSUIPC has never had any facilities for creating AI, or MP. That program must be using SimConnect to create objects. The fact that FSUIPC apparently doesn't appear in the AddOns menu might indicate a broken SimConnect. Regards Pete

I only spotted this query by accident. Please post support questions to the support forum. You posted to the "User Contributions" subforum, which is where folks have produced something or solved something and wish to help others by publishing it. That's because many applications need to place parts in assorted Windows places, like the Registry, and add entries to files like DLL.XML and EXE.XML. Which version? Nothing earlier than 4.60 I hope, or it isn't supported. How did you "let it search"? There's no option for that, only to enter registrations, delete them or check them. Does it say it is registered or not? Is WideFS registered? Is it enabled? Look at the main options screen in the FSUIPC Options. Does it provide a button to enable or disable WideFS? Without any information I cannot hazard a guess at present. Regards Pete

FSUIPC does not monitor the mouse. If the APU switch in an add-on aircraft is implemented in a way you can read it and set it by programme, yes, you can do it. But I don't know the aircraft. If it uses FSUIPC offsets for all of its added switches and controls then, indeed, it should be possible. But you'd need information about how they've done it. Maybe Wilco provide an SDK? I know that for some Wilco or Level D aircraft Nico Kaan made a driver which interfaced to FSUIPC. Perhaps you could check in that direction. The other possibility, which is more likely if they use XML to build their gauges, is that the states are stored in "L:Vars", which can be read and written vis Lua plug-ins to FSUIPC. For almost everything implemented inside FS itself you can find ways via FSUIPC - see the documentation provided in the FSUIPC SDK. However, add-on aircraft often have their own subsystems implemented erntirely weithin their own code. Whether you can access that or not is an entirely different matter. Regards Pete

I don't know what it means because it isn't an FSUIPC message. It sounds like something else needs FSUIPC and it isn't installed. I don't know CumulusX, nor AI Carriers. I don't think they would be anything to do with FSUIPC in any case. Have you installed FSUIPC? If so, did it say it installed correctly? Please check that 1. You are using a supported version of FSUIPC for FSX: version 4.60 or later. (There's a later version, and a later installer in the Download Links subforum). 2. There is a Modules folder in FSX, with an Install log file. Show me that Log file. 3. There is an FSUIPC4.LOG file. If there is not then FSUIPC4 has not run. If there is, show it to me please. You can paste the text from the Log files into messages here. Regards Pete

VSPE is only needed when you want some or most functions to be dealt with by another piece of software, like a driver specifically for it. If you want to take complete control, do all of the display outputs as well as the button and knob inputs, then you are effectively replacing that driver with your own program. In this case you can certainly do quite a lot with the COM library provided for Lua plug-ins. One of the problems might be that you don't know how to interpret the commands arriving from the device, nor how to drive the displays. In this case then VSPE might come in handy just so you can run it with a known aircraft with a driver supporting it, and just log what it sends and receives, whilst passing them through, from one port to the other and back. You can then figure out what it is doing. An alternative to using VSPE for this, and one I prefer, is using a Serial Port monitor program, like those from AGG (www.aggsoft.com). You can get their serial port monitor on a trial basis I think. They also do a USB monitor which I've found very useful. Regards Pete

No, not at all. FSUIPC calibration has been a facility for many years more than the axis assignment facilities. The latter only came about as a result of needs of folks for having different devices for different aircraft types -- like a yoke for Boeing airliners, joystick for Airbuses, G-stick for helicopters, etc. Axis assignments can be auto-switched according to the aircraft loaded. It also then provided the opportunity to add specialist axes not supported by FS, like reversers, and aileron and rudder trim. I really don't know how the idea that FSUIPC only calibrated its own assigned axes ever arose, and it is very annoying as it seems to make folks use the axis assignments when they'd really be better off sticking with FS assignments. FSUIPC calibration is NOT really AXIS calibration in any case, it is FS CONTROL calibration. It intercepts not the axes but the controls FS is receiving, from whatever source. It neither detects joystick axes nor knows how those controls arise, and it doesn't need to as all it is doing is mapping input ranges to output needs. The only axception to this, which was also a much more recent addition, is the option in the axis assignments to assign "direct to FSUIPC calibration". Normal assignment sends the controls to FS (as in fact it says), NOT to FSUIPC, and FSUIPC calibration intercepts them in the same way as if they were assigned in FS. But the "direct" assignment bypasses the FS controls and calls the calibrations routines directly instead. This can be a lot more efficient (cuts down on a lot of internal activities). But I don't advise it as a blanket thing to do, in preference to the normal assignments, because it can cause some aircraft not to work -- some intercept the FS controls themselves (the add-on Airbuses, for instance), for assorted purposes like fly-by-wire, and bypassing those controls defeats them. Regards Pete

Okay, I see. But do you now understand the method? From your efforts and with the addition of the "sleep" just to read a third value, it certainly seemed as if you didn't. And that was my concern. Not the effectiveness or otherwise of the filter itself. To fix your now-stated problem, you simply need to have a limit on the time for filtering. There's no point in filtering slow changes in any case. Keep a record of the elapsed time (you can read that using an ipc function). Have a timer event to a watchdog function, and if you see the elapsed time since the last update exceed the most reasonable filter time, say 200 msecs (or perhaps more?), send the last saved value. BTW did you ever try the filtering in FSUIPC's calibratiion facilities (the "F" checkbox)? It's a rather more sophisticated mathematical low-pass filtering I found in a book somewhere. Unfortunately I can't remember where now, it was so many years ago. Regards Pete

Yes, but you would get the first value from the first time the function is called, save it, get the second the next time, and the third the next time. Since the function is called EVERY time the value changes, you get precisely ONE new value each time it is called, so obviously you save the previous two -- EXACTLY as you did in your earlier examples. I don't understand why you removed the second "Old" value memory. It can't work without it. But why try reading the current value from 3322 when it is provided for you in newV = ipcPARAM? It makes no sense. Which is exactly as wrong as the last and for similar reasons. Of course it is because it IS the current value being supplied to you! But that just defeats the whole point of having a function which automatically receives EVERY changed value, no matter how fast or slow they happen. All you are doing be suspending the thread for 100 mSecs is preventing however many new values might have been sent to you actually being sent! Having the Sleep simply negates the whole advantage of the provisions I have made. You might as well give up on all the new facilities if you want to do such an odd thing. The "NEW" way to do it is the OLD way. You have two memories, Old1 and Old2. Look, it seems I have to re-print my re-write of your original to illustrate the method. I don't think you could have bothered to look at it yet, else you'd surely understand the correct solution. this is for Throttle1 (the control 66420 = Axis throttle1 Set): new1 = -16384 new2 = -16384 function param(new3) nextV = new3 if not (new2 > new3 and new2 > new1) and not (new2 < new3 and new2 < new1) then nextV = new2 end if not (new1 > new3 and new1 > new2) and not (new1 < new3 and new1 < new2) then nextV = new1 end new1 = new2 new2 = new3 ipc.control(66420, nextV) end event.param("param") Okay? I've used "new1" and "new2" instead of "old1" and "old2", but the code is the same. I've removed the check on whether the value being sent is different or not. As you said once, it should be different more times in any case, except which the filter has filtered it. That works fine here, like your original except faster and smoother. AND you can calibrate it in FSUIPC. Now please explain why you don't understand it and/or rejected it, so i can understand. Regards Pete

Yes, you said that part -- it was just the FS9 part which was missing. It could be that the mouse macro needs a parameter, as described in the FSUIPC documentation. I can't really advise you on that, it needs experimentation. Otherwise I suppose there's a possibility of it using L:vars or those extra FS controls which the FSX one uses. Might be worth investigating. I hope you can find someone using the FS9 PMDG 747 who can help. I'm afraid I don't use any add-on aircraft only a slightly revised FSX 738. One day I may move to the PMDG 737NGX when it finally arrives, but I don't think that will help with the FS9 era PMDG aircraft. Since you are offered keyboard short-cuts, why not just use those and assign them to your buttons and switches? That may be what everyone else does. Otherwise, it might be worth re-posting with a clearer title mentioning FS9 so that the right folks respond. You could also try the MyCockpits and PMDG forums where there should be plenty of users. Mycockpits is at http://www.mycockpit...orums/forum.php Regards Pete

It might be a good idea to state whether this is for FS9 or FSX. If for FSX, I think you'll find the EFIS fully covered by the contribution made by guenseli in the User Contributions subforum. Regards Pete

Er, I am taking "it" easy! Sorry, what do you mean? I'm still only trying to provide helpful advice. If you don't want any, say so. The value supplied to the function by the event will always be different, as documented. The event is only triggered by a difference, so it can't be otherwise. Yes, but, sorry, i don't see the relevance of that to anything I said? So, you knew the answer to that question, then? Sorry, I think you've lost me. Oh dear; sorry: now I know you are still confused. Your latest code won't work because you are only comparing old1 with the new value. In this section: nextV = ipcPARAM if not (newV > nextV and newV > old1) and not (newV < nextV and newV < old1) then nextV = newV end since newV = ipcPARAM (by definition), and nextV = ipcPARAM too (by your code), that if contdion results in: if not (nextV > nextV and nextV > old1) and not (nextV < nextV and nextV < old1) then nextV = nextV end In other words, it does nothing. To make it work you need THREE values, the new one (newV) and two previous ones -- you only have one old one now. For some reason you lost the other. This is your problem. why delete the vital second previous value? To recap: the new value IS the parameter provided to the function, which IS the same as ipcPARAM. That value IS the latest value from the Axis, if you've assigned the axis to "LuaValue". What is the difference between that and the one which you erstwhile read from 3332, except the later is post calibration whilst the former is direct from the axis, which is why I suggested sending it as the FS control, not writing to the offset, so you can still calibrate it.? I'm not intending to. Things are all working as they should. It's you not seeing this which worries me, and i'm trying to find out why! Find your way around WHAT? This is what I don't understand! What is it you are doubting? Please ask questions instead of apparently making assumptions. Assuming you assigned the axis to "LuaValue ..." naming this Lua plugin, the values from the axis are coming into your function as the parameter, your "newV" (which = ipcPARAM). They ARE the new values, and different each time the axis changes. It works exactly as I've been saying, and as documented. What is it you don't understand? Please ask the questions which you appear to be harbouring and not stating. Oh dear, what is it you are thinking? How are you assigning the axis, how are you "reading the axis right after the function". I see now that I have utterly confused you. Why not please review the straight conversion of your routine i provided yesterday, earlier in this thread? Just use it for, say, Throttle1 (assigned to LuaValue xxxx1), and use your original for Throttle2, assigned as you did before (or vice versa). Then compare the filtered throttle movements, on screen, side by side. You'll see immediately that the new ipcPARAM event driven method is smoother and faster. If you don't understand how things work, please ask questions. You seem to be making all sorts of incorrect assumptions at present, and I don't understand why because you don't state them. Believe me, I'm only trying to help here, and i'd like to know what it is you don't understand because I might need to document things a little more explicitly somewhere. Pete

Why are you using it then? You have nextV = ipcPARAM but, as documented, ipcPARAM is supplied to you as the parameter, newV. Why not simply use that? That line is the same as "nextV = newV", but why bother? Why not call the parameter "nextV" and be done? Did you not even bother to try my version, using these facilities, posted here earlier? And why is this back? nextV = (nextV / 2) + 8192 And why not just send the result as the Axis Throttle1 Set control so you can calibrate it? Pete

Line 1 toggles button flag 15,2 -- i.e. button 2 on joystick 15. Why are you toggling that when you don't test it anywhere? Or is your joystick A number 15? In the compound lines you are testing the same button's own flag, A,2. That flag is automaticaly toggled every time you press the button. So if A = 15 you are toggling the flag twice every time it is pressed . The result of that will be that the flag never changes. The "toggle flag" control (1005) is one of the set of flag manipulating controls intended to allow you to use sets of flags for buttons you don't truly have, out of the 16x32 = 512 possible buttons. But for merely having an alternate action from a button the auto-toggling of real button flags is fine. So, if A=15 remove line 1. Otherwise, I don't know. You'll need to switch button logging on -- that will tell you what is happening. Regards Pete

Done in FSUIPC 4.654, now available in the Download Links subforum. Pete

Updates now available. The Lua plugins package is also revised. Regards Pete

What? I gave you the answer you asked for, where to find FSUIPC. And earlier pointed out that unless you use FSUIPC I can't really help with your add-on problems, and that in any case there's no way I can answer questions on other folk's aircraft. It seems to me that you came here by mistake and once realising it sought to cover your embarrassment by being downright insulting and rude. I think that is ignorant behaviour and you should think again before repeating it or even confirming it as you have just done. Please go elsewhere when you want help with things I have nothing to do with, and take heed of my answers when they do contain useful information, which you've obviously overlooked or simply ignored! I'll leave this thread be for a while but will probably delete it entirely later as it only clutters up the concentration of useful information in the Forum with a lot of time-wasting nonsense. Pete

Sorry, you are mixing two separate issues. Whether you handle all throttles in one plug-in (and therefore one thread) or multiple plug-ins (multiple threads) is a programming issue, how you construct the code. It is nothing to do with whether you use events or never-ending loops. As I said, if you change to use the ipcPARAM method, as per my example, you have no choice but to use separate plug-ins for each throttle, because the parameter value you receive on changes is indistinguishable. You can't tell which throttle it came from. A single plug-in is a single thread, yes, of course. What else? The timer operates for the thread. But that is no reason why there can only be one timer per thread (plug-in). I could implement as many as needed, but it makes things more complicated, adds more overhead, and is certainly not needed, because you can feed different things at different multiples of your one timer, as needed. If you continue to use the disconnect method it would be better to keep the disconnect action for each throttle in its own plug-in. Jst add the timer event and the disconnect function to each throttle plug-in, with different bits set accordingly. It's a waste having a third unnecessary plug-in. Not to the Lua plugins, they still need to be pre-loaded, but to the new control "LuaValue" for the plugins. The updated versions of FSUIPC will be uploaded this afternoon. Regards Pete

I was interested in how you found the Support Forum FIRST, instead of going via the DOWNLOAD site as most certainly do! What is so odd about my being curious? It was in no way intended as sarcasm or a put-down as you have taken it, but genuine surprise and curiosity. Evidently you write as one who has never even bothered to read any of the exchanges here and the timely constructive responses I strive to provide. Yet I still waste my time talking to people like you who evidently, from what you say, should know better. Please don't bother coming here again. Rude and unthinking reactions like yours are uncalled for and unwelcome. Pete

I'm surprised that you can manage to find this Support Forum without ever visiting any sites carrying FSUIPC, nor referring to the documentation which also tells you? How did you get here? The main download site is www.schiratti.com/dowson, which carries all the official current releases, whilst the Download Links subforum here contains interim updates and lots of other useful stuff. Pete

You are still using globals (ipc.get and ipc.set) unnecessarily, though. That makes it a lot jerkier than it need to be, because every get and every set is a multi-threaded synching operation -- it actually has to get and put the values from/to a separate thread, every single access! All you need to do is replace the global references by direct variable names. i.e. old11 = -16384 old12 = -16384 prev1V = -16384 etc, throughout. The parameter it refers to being changed is the ipcPARAM specific to this current plug-in. It isn't a shared global accessed via get and set. You obviously would need to have separate plug-ins for each throttle if using the "param" method. with your method you could combine the throttle actions for all throttles into one plug-in using tables. But not using ipcPARAM because you can't tell which throttle sent it. No, you are misunderstanding the whole advantage of the event methods. The fact that you've established one or more events keeps the plug-in loaded, ready-compiled and ready to run. It is merely 'sleeping', with its event functions being called as needed according to the events defined. It's truly like adding code to FSUIPC. If, in the functions, you eventually cancel all outstanding events (via event.cancel), only then is the plug-in "unplugged". Regards Pete

So you are assigning in FS, not in FSUIPC. I cannot possibly support that in any case. If you want help here please always make sure you are up to date. The oldest supported version for FS9 and before is 3.98, as I said. if you don't know, then you are not. And if you are not using FSUIPC then the reverse thrust can only be achieved by pressing the F2 key repeatedly, or assigning a button on your controls to the throttle decrement control in FS and using that. You purchased FSUIPC? Or do you mean the yoke? There's really no point in purchasing FSUIPC if you don't mean to use it! By whom? You have others using your simulator program? If you've no idea why you have FSUIPC or whether you've used it for anything, I suggest you look in the FS Modules folder for the FSUIPC.INI file and delete it. That will at least ensure that FSUIPC has nothing whatsoever to do with anything you are experiencing. I can't really help any further here I'm afraid. Without knowing what you've done, what you are using, and with such an old version, there's little point in me giving any further advice. Really it looks like I already gave you the best advice in my first reply -- get everything working on a default aircraft first. Then ask for support from the add-on suppliers. Regards Pete

Put really fat people with heavy locker luggage in the last 12 of the 61 places available to you to simulate more normal loads in rows 62 to 73? Regards Pete

There's one other thing. I think you should only be setting the throttle when it needs changing. Continually writing the same value, whether to the Throttle offset or via ipc.control will both result in lots of unnecessary messages flying about through the Windows message queue. With a complex aircraft that's the last thing you want to do -- there's usually far too many already! Just keep a copy of the last value sent and only send the next when it is different. That'll remove most of the unnecessary stuff going on. I've also just completed changes to provide the direct method of setting ipcPARAM that I hinted at. Basically then all you need to do is assign the axis to "LuaValue xxxx" where xxxx is the name of your ready-running Lua plugin for that throttle, and you can do it all from ipcPARAM. There's also an event.param so it can be properly event driven without bothering with timer adjustments (unless you want to add more sophistication for filtering only fast changes, not slow ones. Here's your Throttle 1 Lua re-written using the new facilities: new1 = -16384 new2 = -16384 prevV = -16384 function param(new3) nextV = new3 if not (new2 > new3 and new2 > new1) and not (new2 < new3 and new2 < new1) then nextV = new2 end if not (new1 > new3 and new1 > new2) and not (new1 < new3 and new1 < new2) then nextV = new1 end new1 = new2 new2 = new3 if nextV ~= prevV then ipc.control(66420, nextV) prevV = nextV end end event.param("param") You can still calibrate, and set NRZ if you wish, as this sends the Axis Throttle1 Set control just like FS would. Note that "PrevV" is used to stop it sending non-changing values, though in fact this is less necessary because the event.param function will not call the operating function ("param") if ipcPARAM doesn't change. The function doesn't even need to read ipcPARAM because its value is supplied as the parameter to the function. The versions of FSUIPC3 and FSUIPC4 with these facilities should be ready for release tomorrow (Wednesday), or the day after at the latest, I hope. It will also contain new Lua functions: ipc.togglebitsUB, ipc.togglebitsUW, ipc.togglebitsUD ipc.setbitsUB, ipc.setbitsUW, ipc.setbitsUD ipc.clearbitsUB, ipc.clearbitsUW, ipc.clearbitsUD Those will also feature in a revised WideClient. Regards Pete