Pete Dowson

Except for VRi and GoFlight, FSUIPC does not see buttons unless the device is recognised as a normal Joystick type device by Windows. If it was that type of device you wouldn't need SPAD. I was considering adding Saitek button support too, when they reneged on their licensing agreement for FSUIPC use. Are they standard joystick type devices, or simply keyboard replacements? That appears to be because Saitek's software is sending those specific FS controls. Neither FSUIPC nor SPAD is involved. Ok. That looks correct EXCEPT that the key up parts are sent at exactly the same time as the keydown parts. Maybe there needs to actually be enough time for something to detect the keypress correctly? If it is SPAD doing this, can you not program it to send the press when you press the button, and the release when you release it? I am combining the next two examples with the relevant parts only showing so you can see that they are identical except for the timing: The only difference between these two is the timing of the KEYUPs. In the one that works the KEY releases are following a little later. In the one which doesn't they are occurring in the same millisecond as the keydowns and the mouse macros. I think the panel, is sensitive to both the key combination being pressed (which it won't see as you've programmed it to do something else -- send the mouse macro) but also the key release. You either need to get SPAD to send the key releases later (eg when you release the button) -- in which case it should work without Mouse macros (and without FSUIPC being involved at all) -- or, maybe, if that's not possible, you could assign the key release to something else, something completely harmless, in FSUIPC, so the panel doesn't see it and therefore mess up its obedience of the mouse macro. Again illustrating the difference in timing of the release, only. Pete

That statement has me completely confused I'm afraid. If the aircraft panel res[ponds to known keyboard combinations as you say, why would you need to resort to the FSUIPC mouse macro facilities? Why not use the keyboard combinations provided? Seems much cleaner, even if the panel is written in a way which will support mouse macros. Arh, is SPAD that freeware program for interfacing the Saitek gear to FS or FSUIPC? So what actual 'commands' are you making SPAD send? Keys or buttons or offset changes or what? Sorry, something is very confused there. Mouse macros don't have key comninations. Mouse macros instigate calls directly in C/C++ coded gauges. Please explain what you mean. So this merely confirms that the default Wilco Commands (Ctrl +Shift +F7 & Ctrl +Shift +F8) work as Wilco intended, I assume? So now SPAD is sending those keystrokes? So far FSUIPC has nothing to do with it. Correct? So SPAD isn't doing what you asked? Where is FSUIPC involved? Right. I am now thoroughly lost. Sorry. You have a panel which can be operated by keystrokes. So why not assign buttons to send those keystrokes? Where do mouse macros come into it, and what is SPAD being used for? As the documentation tells you, in some implementations it is not the simple click of the mouse which finishes the action. The detection of the code to be called is the automatic part of the FSUIPC programming facility, but then, sometimes, you have to experiment with the parameter part too. Some switches need to see both mouse button press and release, separately, and so on. The documentation of the mouse macro facility gives a list of the parameters you can add, manually, to get different actions. And you may need more than one, in which case you may also have to edit them into the macro manually (to make a multi-line macro). But why even try using mouse macros if keypresses work? It doesn't make sense to me at all. You seem to have already programmed a double action of the Ctrl_Shift_F7 key. The '31' added to the macro call is one of the parameters I was talking about.-- it's the code for a single Right Click. The Ctrl_Shift+F8 combination is just sending the second part of what the earlier one did. A single right click. I don't know how you arrived at these, but more to the point, if the default Wilco commands are Ctrl+Shift+F7 and F8 as you state, and they work, why even try to reprogram the same key combinations to use Mouse Macros which you'll need to experiment with in any case to make work? Pete

Yes. There should be no difficulty. All of the shifts usable in Lua are also usable in the assignments -- the same core routines are used by both in any case. What was the difficulty? I just tried assigning a button to "ctrl+shift+win+A" and it worked fine. Well that's what the normal ipc.keypress function does. The ipc.keypressplus was added for two things only: 1. To try to get keys pressed whilst in FS menus or dialogues where FSUIPC is normally halted because of the modal nature of the dialogue, and 2. To optionally move the keyboard focus to FS and afterwards back to the original owner, for use when sending keypresses to external programs. For your use "keypress" is quite adequate and normal. If it works with assigned keypresses from the real keyboard there's no reason I can think of that it won't work with keypresses assigned to buttons in FSUIPC. Regards Pete

Why can't you assign the encoders and swtches directly to the keystroke combinations? Sorry, I don't understand. How does using keypressplus detect a controller button? And how is it taking two seconds? Why would you be using keypressplus in any case if it were not for the focus issue? The only other use of it is to get keypresses sent to FS menus, which are otherwise modal so preventing normal FSUIPC actions like sending keypresses. Keyboard focus merely refers to the window which currently receives keypresses. It has the user's focus. Since I don't know why you are using Lua I can't say what is up with what you are trying to do. I would have thought the best way to program buttons and rotaries to send keypresses was to just assign them. Your momentary or 2 second hold is achieved then by the repeat whilst held option. In general, for a Lua program, a button press action can be timed and different actions resulting quite easily. Simply have the button push start the Lua and the button release set a flag for that Lua (LuaSet ...). In the Lua code you read the elapsed time, then loop till you see the flag, then read the time again. Act according to the difference. You can of course have a limit on the loop to, for example, exit after 2 seconds in any case. Perhaps if you showed your Lua code it might make it easier for me to understand what and why you are doing what it is you are doing? Regards Pete

Please show me the [buttons] section of the FSUIPC ini file. UIt sounds like you have it set to repeat, so cancel itself, or do the same action on press and release. You can also ebable Button logging (in the Logging tab), then operate it, and show me the Log. That would show what you have wrong. Sorry, I don't understand what you are doing. what is a "NAV module"? Pete

I've corrected it for you. Pete

If it a VERY VERY bad idea to use WordPad for any configuration or program files. Use NotePad, not Wordpad! Wordpad assumes you are dealing with documents, not text files. If there are ANY files with type 'lua' in the FS Modules folder then FSUIPC lists them in the drop-down lists for Buttons, Keys and Axes. This is completely unrelated to what is actually IN the file. So, one of three things must be true: 1. You didn't actually save it with the name JS41.lua. Possible Wordpad saved it as "JS41.lua.doc" or similar, OR 2. You aren't looking for the correct entry. For JS41.lua the entry will say "Lua js41", OR 3. You are using an old usupported version of FSUIPC which pre-dates Lua support. Regards Pete

Having them in the modules folder makes them visible for assignment in the Buttons, Axes and Keys assignments drop-downs. They don't all run automatically! There are two which do run automatically just by being there - ipcInit (run when FSUIPC loads, before FS is ready) and ipcReady, which runs when FS is "ready to fly". This is as documented. To run others you either have to add them to [Auto] section(s) in the INI file -- a general one or one for each aircraft -- or assign a button, switch or key to them as "Lua ... " in the drop downs. They do not run automatically. Assigned Lua plugins are used for sepcific actions you want on a switch or key operation. For things you want running all the time, like monitoring conditions and operating lights or playing sounds, etc, you need to use ipcReady or the [Auto] facilities. Pete

But in order for that to be useful you have to actually run the Lua plug-in. How are you doing that? What if the bit in offset 04F0 changes through some other action? Shouldn't your LED change too? As I explained earlier, you'd do better having it event driven on the offset changing, and saved as "ipcReady.lua" so that it gets run automatically, like so: function set_apFD(offset, value) if logic.And(value, 0x1000) ~= 0 then gfd.SetLight(GFRP48, 0, 7) else gfd.ClearLight(GFRP48, 0, 7) end end event.offset( 0x04F0, "UW", "set_apFD") Assign the button to operate the PM FD by using FSUIPC assignments! That's what the Buttons & Switches tab in FSUIPC is all about! You CAN do it in Lua if your really insist, but I can't see why. (To send any controls you use the ipc.control function, with the control number and parameter. The control numbers for FS are listed in the List of FS Controls document installed in your FSUIPC Documents folder, and the added ones for FSUIPC are listed in the Advanced User's Manual -- you'll find the PM ones there). For ths there's no need to use "event.button" because buttons create their own action, by assignment. That's what the "Buttons & Switches" tab in FSUIPC is for! The button event facility is for use with event-driven plug-ins which happen also to respond to button presses. It would run once and terminate because you had no event to make it stay running! Fine. What's the problem with that? As I keep saying, you don't NEED to! The LED should be driven by the FD going on or off, NOT by the button. You need to separate the two in your mind. The indicators should indicate what is set and what is not set. The switches do the setting and unsetting, but their results are inside FS, or PM in this case. The two are joined by the offset, so it is the offset affected by the button and the LED affected by the offset. Pete

Sorry, where are you looking? All of the links in the Download Links subforum "Documentation" thread seem to be okay. If you mean that the ZIP downloads okay but you can't open some of the contents, I think you must have a corrupted download, because they all open fine here. Try downloading it again. If you've installed FSUIPC 4.60 the documents are already installed for you in your FSUIPC Documents folder, in the FS Modules folder, as stated in the Installation guide. Pete

Thanks for posting it. I've taken the liberty of enclosing the code part in code parentheses, to make it easier to identify and select. Code parentheses are put on by selecting text and using the <> button just above the edit area. Regards Pete

Of course. You can do almost anything you like in a Lua plug-in, if the facilities are there. Yes, that is easy. But if the switch can be programmed by normal assignment you might want to consider leaving that as such. Because if the LED is indicating the status of some condition you would want it to reflect that status even if the switch was in the wrong position (such as after loading a new flight, perhaps). With LEDs indicating status you'd normally want these Event driven (usually by event.offset), so they'd actually be running the whole time -- maybe all inserted into the Lua called "ipcready.lua" which is automatically run when FS is ready to fly. But if you are happy having the LED merely reflect the switch position, go for it! I'm not sure from what you previously say where offsets come into it. Is the switch action not for a normal FS control? Regards Pete

I thought the fuel loading did, but, yes, certainly not the payload. This is why the offsets for payload in the FSUIPC offsets list is annotated thus: Perhaps you missed reading this? Don't you use the documents provided in the FSUIPC SDK? The only way to force the issue is to enter the payload menu and okay back out. The values ARE there, they just don't promulgate. I never managed to narrow down the internal FS code sufficiently to identify what could be done automatically. Regards Pete

Have you looked in the User Contributions subforum? I think others have done some work with the PMDG J41. Pete

It won't work on most parts of all of the default FS aircraft because Microsoft did not follow their C/C++ SDK rules in making their gauges. And most new FSX aircraft add-ons use XML gauges (but not all -- some PMDG aircraft being major exceptions). Those gauges may be suitable for L:Var manipulation ("Local Variables") but certainly not mouse macros. That is exactly what you expect if the mouse location you click is not supported by the standard C/C++ gauge table structures. Regards Pete

Please, could you make a new thread for your project in the subforum called "User Contributions". Then it won't get lost. Please make the title really informative so folks know what they see. Better clearly mark it for FSUIPC4 (FSX) because those new offsets are not available for FSUIPC3 (FS9). Thank you! Pete

Didn't you find the FS controls called "toggle elect fuel pump ..."? There are 5 of them -- a generic one for all pumps and four separate ones, for each engine. They are certainly in the assignment drop-downs and listed in the "List of FSX controls" installed in your FSUIPC Documents folder. One way of determining whether there is an assignable control is to enable Event logging in FSUIPC (on the Logging tab). Then, in FS, operate the switch - with a mouse - and then look in the FSUIPC log file to see what Event was logged. If there was none logged then you are right, there's no direct FS control for that operation. If you run FSX in Windowed mode (albeit temporarily) you can enable FSUIPC's console log window too so you can see immediately on screen what is happening. Since I don't know the aircraft at all (the "Carenado Bonanza F33" I think you said?) I cannot really say. I cannot test every aircraft there is out there. You have to see for yourself whether any of the documented techniques will work for it. These include: FS controls: as already mentioned. These are sometimes applied by third party aircraft makers, but sadly not enough. Worth a try first, for sure. Mouse macros: these are usually successful on C/C++ written gauges, but many new aircraft for FSX use XML or other techniques instead, so success is doubtful for newer aircraft. L:Vars ("Local Variables"): these are more and more successful now, as aircraft gauges are written in XML in particular. The FSUIPC documentation covers these topics, but after you've researched it a bit, if you still have questions by all means ask. But bear in mind I cannot actually do the work of investigating your aircraft. You could visit the "User Contributions" subforum for help too. I just looked and whilst there's no contributions (yet) for that aircraft, there's plenty of examples about what can be done. In fact if (or I should say when) you succeed perhaps you could post your solution as a thread there too? The other place to look must surely be the Carenado support forum. Others may have already asked similar questions there and been answered. Regards Pete

Sorry, you'll need to explain that bit of 'logic' for me, because I cannot follow it. What "proves" it isn't hardware, again? Hardware can change on its own, but software cannot. Sorry, I've no idea, but multiple assignment seems to be the most likely, assuming the hardware is actually okay. Why not enable the FSUIPC axis logging and see what is going on? Certainly there's no possible relationship between views and joystick inputs in FSUIPC. It has no idea about what views you select, and no need to care. Regards Pete

They are all added PM controls as described in the Advanced User's guide for FSUIPC. They are all based on PM offsets documented in the PM documentation, as I pointed out. You mean where you assigned button 256,28 to send hex 49 (decimal 73) to a 1 byte offset at 04F2? According to my PM offsets list, offset 04F2 is a 2-byte (WORD) value, not a one byte one. Value 73 is documented as being K-code for the VOR2 seelctor You seem to have assigned this to be sent both when you press the button and when you release it. Why? Note that you could have more easily (and more reliably -- because FSUIPC follows PM's queuing protocol for these inputs) assigned the same control by using "PM MCP Kcodes (by param)" with a parameter of 73. I'm sorry, but I really have no idea what you are up to, nor why you added those large pictures. I certainly did understand your original question,but you evidently did not understand my reply. Regards Pete

Sorry, I don't understand any of that. You really do need to separate "keyboard" and "mouse" to start with. You seem to be very confused over those terms. They are two different devices on your computer -- to be sure we are both talking about the same things, the keyboard is the device in front of your computer which has lots of keys marker with "Q W E R T Y", or "A Z E R T Y" etc. The mouse is something separate that you move about on your desk to move the little pointer on screen, with buttons (left, right, maybe centre) you can press to select things. Buttons can be assigned to send controls to FS, or to send key presses to FS. Both of those are facilities in FSUIPC. If you want to use buttons to operate mouse movements and mouse clicks you need different software, such as "key2mouse", which allows you to make keyboard presses operate the mouse actions. Pete

What macros for PM? Many PM functions are directly assignable in the FSUIPC dropdowns. I don't provide any PM macros, and the PM controls added just manipulate PM offsets. In general on PM matters, you would be better off asking PM support, or at least vitiing the PM section of "MyCockpits" (http://www.mycockpit...enta-User-Group) You really need the PM offsets reference, or at least the list of PM added FSUIPC controls in the Advanced User's guide for FSUIPC. I just checked there, and there's only the facility to set DH or set MDA modes. I guess the only way to then INC or DEC the values is by sending it a keypress. I have my MCP + EICAS switches interfaced directly to the PM MCP program, so I'm not really familiar with that part of PM. If you mean the added PM controls, they simply change the offsets noted in the Advanced User's guide. I think, long ago, when this was first done (in FS98/FS2000 days) they pretty much all used to work fine, but I suspect that as PM has been developed the support for some has fallen by the wayside, or been dislocated in error. Yes, they are from the PM documentation. Sorry. And they are not what we call "macros" in FSUIPC terms, but simple names for controls added to those from FS by FSUIPC. The parameter field is set to the number in the list for the associated function. As it says in the document: Not really any more than documented. That's why the documentation is there. This one merely writes the parameter number to offset 04F2. The rest is up to PM, as documented by PM. Regards Pete

Okay. Fixed in 3.989t, available now in the Download Links subforum. There was a chunk of code actually missing! I've no idea how that happened! Regards Pete

Your window must have keyboard focus. I did add facilities to the FSUIPC Lua facilities to temporarily change focus to FS then back to the originally focussed window ("keypressplus"), but they aren't available to WideClient. The point of the keypress facilities is to send keypresses to whatever has the focus, which with a remote app is normally going to be FS on the server. If you want to do things in FS with a focussed app on the server then at present you'd need to use a Lua plug-in. You can use offset 0D70 to make a plug-in run. Regards Pete

It looks like a bug in FSUIPC3. I can reproduce it here. It works find in FSUIPC4, so I'll take a look to see what the difference is internally. Back soon ... .. actually it's getting a bit late here, so I'll tackle this in the morning. Sorry. Regards Pete

Sorry, I am not really anything to do with SimMarket. Please raise a Problem Ticket there. I must say I've never heard of any similar problem being reported. It would be serrious for SimMarket if no one could buy any of the thousands of products! Regards Pete