Pete Dowson

There is no separate WideServer DLL for FSX, nor a separate INI for it. You evidently aren't reading the documentation! Delete them both. In what way is FSX "not responding". Is it loading up? Is there an Add-Ons menu with FSUIPC listed? For WideFS to work? Register wideFS when you install FSUIPC4, then with FSX running, go to the FSUIPC options and enable wideFS. There's no change to the Client end, that is identical for FS98, Fs2000, FS2002, FS2004, FSx and ESP (and CFS1 and CFS2 for that matter). Regards Pete

Okay -- though i don't see that as relevant. It most certainly has nothing to do with any FSUIPC offsets, nothing whatsoever. And how do you know which? Shouldn't you watch all? It is easy enough for you to test if you have even only a single thrlttle. Simply assign it to Throttle 1 instead of the generic Throttle. Maybe you are simply not recognising that the user has twin throttles and you are not looking in the right places? Regards Pete

Correct. All the analogue axes on the Serial Port PFC devices (as opposed to their USB devices) are connected to a controller board which supplies all switches and axes in PFC's own protocol, which is handled, for use in FS, by my PFC modules. However, they operate via FSUIPC, and are thence handled in the same way.

Button activated reverse can only be done by assigning the button to the appropriate "DECREASE" control, probably THROTTLE_DEC for throttle and PROP_PITCH _DEC (or something like that) for prop pitch -- whatever way you do it on the keyboard, it would be the same control. Have it repeating. You probably also need a cancellation control, to set IDLE or zero when the button is released. I don't really know -- ask other Saitek users. FSUIPC's reverse zone facilities are for proper axes with real reverse zones or reverser levers on them. Your Saitek's take the cheap way out by having a button instead. FSUIPC will simply see that as a button, it is up to you to decide what to do with it. I'm really amazed that Saitek don't provide documentation or help on this. What, the Saitek manual? Or FSUIPC? FSUIPC's manual doesn't deal with specific equipment. It is not possible for me to purchase and document the best way to handle each item of equipment you can possibly connect. Regards Pete

This is running SB on the Client PC or the FS PC? In that case you certainly have a registration problem. Either the keys you've got are illegally made, or your system date says they are not valid yet because you purchased them AFTER today's date. I expect it is the latter. Correct your PC's date and it will be okay. Pete

Well, I can't do that off the top of my head like that. I'll try when I have half-an-hour or so to spare. Can you post details to petedowson@btconnect.com, please? Then it'll go in my "pending" list -- nothing here does. Pete

Neither FSUIPC nor PMDG create weather in FS. You need to look at where your weather is coming from if the 124 knot tailwind isn't correct. if it is correct and you are complaining about the flight model (it isn't clear from what you say), then you'll need to talk to PMDG. FSUIPC isn't controlling anything there either. For any steady wind the PMDG model should fly fine -- there's something wrong with it if it doesn't. Pete

For the visible rudder, the control surface, to move, you mean? Are you checking this from outside the aircraft? How do you operate the pedals from outside? ;-) No, there is no way to make the rudder control surface move when the rudder control in FS isn't operated -- unless Level D have a trick they can operate for you. If you have the tiller driving the rudder, as you said you have, check your rudder with that. Otherwise use the rudder for steering and disable the tiller. Regards Pete

Thanks for that. Very interesting. But you might be better off combining some of them. For example: 1. You could also use the event facilities to put all of the little button-activated sequences in one pre-loaded Lua file. Each would be a "function" declared inside that Lua file, and a sequence of "event.button" calls would tell FSUIPC which one to execute on each of those buttons. This actually would be very efficient because the Lua file would be loaded and compiled just once, and be sitting in its own thread just waiting for the calls. The disadvantage would be that you couldn't have more than one of those sequences operating at the same time, as they share the one thread. Preloading is done using "ipcInit.lua" or "ipcReady.lua" depending on when you want them loaded. Those can load other Lua files using the ipc.macro function. 2. Surely there's a lot of commonality between the various planes? Those which are similar or the same could be using the same Lua files. 3. You could have single Lua files per action despite plane differences by testing the plane name -- the name string can be read, and significant substrings (like 767, 747, whatever) checked within them using the extensive and powerful Lua string library. Just some ideas to get over the 127 limit and to make things a little more controllable, tidier, efficient? Please keep me informed on progress. Maybe I could use some of your best results as examples for later updates of the package? Regards Pete

This is true. The files show me nothing useful at all. The excessive number of EVENTs are being generated automatically by your Aircraft panel. If you test again, after you have your joysticks working properly in FS, be sure to run with a default aircraft. I cannot deal with add-ons initially. you must get things working by default first. Your main problem at present appears to be nothing to do with FSUIPC, and it certainly cannot be just due to changing from 4.4xx to 4.5xx. You've had something else change. I repeat, FSUIPC CANNOT stop FSX seeing joystick buttons, only YOU can do that by disabling them in FSX. If neither FSX nor FSUIPC can see them, then you have something else wrong, presumably with the joystick's drivers. (I'd love to be able to stop FS seeing joysticks I'm controlling, as it would save a lot of problems supporting folks who get things duplicated, but I cannot do so). Don't forget to test your setup with a default aircraft. Sophisticated add-ons like the Level D 767 make things much more complex to resolve. Pete

FSUIPC takes control of nothing unless you tell it to! And there is absolutely no way it can take control away from FS -- this is why you have to disable controls in FS when using them via FSUIPC, or else you get duplicate actions! There is no way I know for any program to stop FS reading joystick axes or buttons. As far as I know it is just not possible. You evidently have disabled them in FS. From what you now say, I really don't think they will be of any use at all to me. You have something else wrong which is absolutely nothing whatsoever to do with FSUIPC! Get your controls working in FS, leave out FSUIPC4. When you have them working, only then look at FSUIPC again. Pete

WideClient, on your Networked PCs is the same. You don't need to alter those. WideServer is gone, not used on FSX. The WideServer functions are built into FSUIPC4 and need registering separately with a WideFS7 key. You can purchase FSUIPC4 + WideFS7 as a bundle from SimMarket. Pete

In FS the steering tiller controls the rudder (there's no nose wheel control), so one way is to check the rudder using the tiller instead. There is another offset I provided for Project Magenta to read for the rudder, which reflects the rudder input even when it is the steering tiller controlling the rudder. I don't know what software you are using to display the controls but maybe it can use that too? It was suggested by one user that I could let the pedals control the rudder whilst stationary, and suddenly change to 100% tiller as soon as there's any ground speed, but I fear this will give odd results (the changes won't be instantaneously coincident) whilst taxiing and braking, and in any case most experts I've talked to say that these checks are most often performed WHILST taxiing, so that wouldn't be any good after all. Regards Pete

Well, maybebut a problem at present would be to find time to re-design the existing dialogue just to fit another option in, even just for one conditional button. If i have to make the dialogue page bigger it affects all of the pages and they all need more work. It is a much bigger job than it may look to you. If I could relegate some of the options to another page, maybe. For instance, split the assignment to key presses from the assignment to controls (separate pages). But this makes assigning say a keypress for "press" and a control for "release" impossible, or extremely difficult. Don't forget, with just one condition you have to have twice the space, because there could be twice the number of actions per button. And some folks have more than one condition -- each one doubles it. And then why give preference to this feature? What about all of the cases where folks want a button press to do several actions, or the same one repeated several times? According to the feedback I get here I would say this is probably more common. To accommodate that on the same page I have to allow a list of controls or keypresses, or both mixed. And all of this for one or more conditions. And how are the conditions expressed? By pressing another button, or by giving the button number? Button numbers aren't easy without FSUIPC scanning them and showing them, so it would have to have a subscan in the middle of a normal scan. And then there are the Button Flags -- used in conditions probably just as much as the direct button press itself, as you can use the button flag to signify the condition is "latched" -- multiple flags allow one button to cycle all the others through several different modes. How would i deal with that on Screen in an easy to understand dialogue? From feedback over the years all of these things are just as important as each other. I couldn't embark upon a design for a dialogue without taking all of these things into account, and really the mind boggles at the thought. Now, if someone good at designing dialogues which make complex things look simple would volunteer a design, I would certainly consider it, even if it meant having a button on the Buttons page saying "go to BIG options page" which draws a larger dialogue, or possible runs a "Wizard" to get the settings done by questions and answers. Regards Pete

Oh, you mean as a "shift", or "selector" for conditional operation of other buttons! Sorry -- I use the word "Switch" like "button" -- a button is something you push and release, a switch is something you toggle. A switch is usually latching, a button isn't. else they are the same. Yes, I know what you mean. And designing such a dialogue which is easy to use is the hard bit. I'm afraid user interface design is not my area of expertise (as you may have noticed). The versatility of compound conditionals in the button parameters is not very easy to translate into a usable dialogue design, At least it isn't without restricting it too much. There are designs for multiple button conditions, not just one as you have, and there are designs for handling graycode encoders which are even more difficult to fathom out simply enough for put into a dialogue format. It ends up being a question of time spent doing a partial job, which may help one or two folks but not do the real job of making the complex things easy, or a lot (and I mean a *lot*) of time trying to design something easy and flexible. I just feel my time is better spent on doing things I'm good at rather than those I am not. Regards Pete

Er, sorry. What is not possible for a switch at present? I don't understand your request. Pete

What do you mean, "disconnected". Nothing in my code can cause that. 4.432 cannot be supported, it includes some bugs in any case. What is a "Cougar"? I suspect you have something programmed which did not work correctly in 4.432 and you are making use of something which should not happen in any case. Going back does not help. Please reinstall 4.50, and update to 4.506 (from the Updates announcement above), so we are both using the same version. Then, in FSUIPC's Logging options, enable Button logging and Event logging (not Axis). Close FSX and reload it, so it starts off with the logging enabled. Now reproduce the problem (making careful note, please, of what buttons you are pressing and what you expect to happen), then close FSX, and send me all the details -- ZIP up the FSUIPC4.LOG file, and the FSUIPC4.INI file. Send to petedowson@btconnect.com. I will take a look. Regards Pete

Yes, but if you want them retained you need to number them too. e.g. 23=; my comment The number will ensure it is retained and keeps its position. You really need to number them in the order you want them. They can sometimes get re-ordered otherwise. Just edit the oder to what you want, then renumber the lines accordingly. Remember that where you have sequences for one button, the order matters. Regards Pete

Yes. 127. Phew! Are these all for different things? I'm amazed that anyone is finding so much use for this facility. Perhaps you would describe your uses to me some day, please? I'd be most interested. I've not had any feedback till recently, and now this!:-) I'm afraid the limit is fixed at 127. I never thought that would be an effective limit -- seems I'll need to document it. The reason is the way Button and Key assignments are encoded into a single 32-bit word. What with macros (also limited to 127) and all the Offset handling controls, conditionals and so on, I only had 7 bits left to encode the Lua number -- this was by pinching half the range originally assigned for Macros. In turn, of course, this is a result of software growing up bit by bit, adding new facilities, never conceived earlier on, to an existing design. If i started again I'd do it differently! ;-) Regards Pete

No. Writing it as one structure, in one Write, would work. But a lot of folks use languages which don't support structures very well, and Write things separately. I don't mean separate Process calls (which would work, but is slow and rather dangerous in case something else intervenes). If separate writes are used, since the requests are processed in order when received (via the Process call), then Parameters for Commands always need writing first. Writing it all as one structure averts any of that complication, but makes your code a little more complex, to work with structures. That's all. No. If you Clear the weather every time you'll get horrible flashing weather effects on screen. Ugh. If this is for FSX only, setting Global weather mode should be enough, but it is probably a good idea to CLEAR as well, to start off with a blank canvas, as it were. For FS9 it is more complex. Unless you CLEAR every time all FS9 weather develops into Localised weather, and then GLOB fails to change it. In FS9 there's no "GLOBAL" mode. The only sure way to control FS9 weather for continuing periods is to write all of the nearby Weather stations. If you aren't worried about FS9, it is easier. Just set GLOBAL mode -- added especially by Microsoft after our complaints about not being able to pre-determine weather properly for training purposes. Read area, of course. All the Read interaction is done in the Read area, all the Write interaction is done in the Write area. Both may be happening simultaneously. You may not even be the only program doing these things at the same time! Regards Pete

You want an abrupt change, just like that? won't that happen if you turn off all of the FSUIPC facilities and just set that into FS's weather menu? It was to prevent such unrealistic things that the visibility graduation facilities were added to FSUIPC. Well, yes, but it shouldn't be so abrupt. FSUIPC provides a transition. ErI don't understand any of the above. Sorry. The graduated visibility region operates from the top of the restricted visibility layer, eg 10,000 feet or wherever FS or you set it, gradually increasing it, linearly, to the upper visibility at the very top altitude. In other words you get three regions: 1. ground to level 1 (top of FS's restricted layer) == visibility x 2. level 1 to level 2 (usually very high, above max flight levels) == linear smoothing from x to y (so halfway it will be (x + y)/2). 3. above level 2 = FS's defined max according to current option settings. Not affected by FSUIPC. Bear in mind that the values computed in this way are the target values. If you also have smoothing enabled, then there may also be a delay according to the smoothing settings. This is the way it has worked for years, in FS2002 and FS2004 (unfortunately not in FSX though*). Please do also check the documentation. I'm sure it explains it there already better than I can here. Regards Pete * I couldn't find any way to directly control the visibility graphics in FSX, and SimConnect's weather control is rather unpredictable and arbitrary in this area, resulting in unpleasant effects when such things are tried.

Of course it is possible. I just explained how! Look: you said Now take a look at 59 and 78. If you put them next to each other it should be obvious what is wrong: 59=PA,4,C66153,0 78=CP(+A,5)A,4,C66154,0 FSUIPC sees button 4, so it obeys line 59. After all, what is stopping it? It also sees button 5 too and still button 4, so it also obeys 78. Therefore it does a "next sub view" and a "prev sub view". Result? No change in view -- they cancel each other!! Your other combinations are doing the same, it is just that they don't cancel each other so obviously. Example, Brake -- Parking Brake. The latter takes over from the former, but they both happen! If you only want one or the other to happen, you have to set the condition for that! FSUIPC cannot read your mind. Try this change: 59=CP(-A,5)A,4,C66153,0 78=CP(+A,5)A,4,C66154,0 Now do you see how the two are mutually exclusive? Instead of both actions occurring when button 5 and 4 are pressed, only one, the second one can happen, because the first only happens when button 5 is NOT pressed. If you don't tell FSUIPC that button 5 must not be pressed, there is nothing stopping both lines from activating! The same applies to some of your other settings. Pete

This is almost always a video driver problem. There are some hints which may help that I've seen recently, especially if you are using Vista: set your desktop Icon for FSX to "Disable desktop composition" and "Disable visual themes." That must surely be a timing or memory arrangement coincidence, because FSUIPC is doing nothing at all in regards to the actions you mention. in fact, unless it is being actively used by an add-on application, it really is dormant in any case, simply receiving stuff sent to it by SimConnect, none of which relate to switching between screen modes are changing focus. Possibly it is more to do with whatever is using FSUIPC? After all, its main function is a "window" into FS for other programs. What else is running? What is this hardware which actually requires FSUIPC? Perhaps you can carry out some process of elimination to see what is actually the cause? Regards Pete

Yes. "Next view" and "Prev view" cancel each other out! With combinations the action only takes place when the combination is true -- you get that right. But you forget that the button-alone actions are ALSO occurring. For button 4 without button 5 you have to have the condition "not button 5" -- that is what the "-" facility is for, opposite of "+". All button actions relevant for a button are execured, not just the one you want, but all those which are valid. you have to eliminate those you do not want as well as select those you do. You could find this out yourself using FSUIPC logging -- enable Button and Event logging and see what happens in the Log file! Regards Pete

Then so must AutoSaved flights, because they are using the EXACT same facility as you! I repeat, AUTOSAVE does NOT save flights -- FS itself saves flights. All AutoSave does is call the same facility that you do, on a timed basis. Pete