Pete Dowson

That's an option in that aircraft set-up, is it? I have the same option for Project Magenta, but generally it can be left enabled always. In my cockpit, and I assume that in sophisticated models like those from Wilco, if you aren't reasonably close to trimmed (so the yoke is set so you can take your hands off with the aircraft still following the current path) then the A/P cannot be engaged to hold the relevant modes. Sounds like either you weren't enough in trim to engage the A/P, or the yoke was sending erratic inputs to the sim. The option you unchecked should merely tell it to ignore the yoke inputs. Regards Pete

Okay, I can reproduce the Win7 dialogue box coming up asking if I want to shut down the system or not, but when I press Cancel, it simply finishes closing FSX and that's it. Not so drastic, but still wrong. I've no idea how I can get Windows to do that! Weird. Investigating now ... Pete

Try correcting the system's date! 2002 was before your Registration (before FSUIPC3 and any registrations, in fact, as they didn't start toll 2003). The bad date makes the Registration look invalid. Earlier versions would also not have worked completely either, but fail in subtle ways instead, less easy to detect but the same cause. Pete

I don't know, but possibly not, depending how Microsoft programmed it. Try enabling Event logging in FSUIPC's options (logging tab). If you run FSX in Windowed mode (temporarily) you can also enable the console log and see the results in real time. Otherwise check the FSUIPC4.LOG file after operating the switch. If it activates a control it will be logged. If not, there are two other possibilities: 1) Unlikely, but maybe the mouse macro option will detect it. Try it to see. 2) Slightly more likely, maybe it is controlled with a local gauge variable (L:var). Try the assignment option to list L:Vars and see if you can see it. There's also a Lua plug-in provided with FSUIPC which logs L:vars on screen as they change. If there is one, maybe a macro to change it will work. It is still a long shot though. Regards Pete

I'm not saying they have, but the images previously show assignments made in a global mode, not aircraft or profile specific. The log shows you operating the buttons using an aircraft for which you have made explicit assignments which override those you keep showing pictures of, and those are not even to any trim controls but instead to Key Presses which, in FS, operate the elevator (not the trim). Not for that specific aircraft -- those buttons are most certainly assigned to elevator up and down key presses -- not controls and not trim. Yes, but they are not current when you fly that specific aircraft. Please do read what I write, else I am wasting my time. If you do not understand any of this, please simply do as I have suggested. Delete the INI file and start again, and try not to use facilities you do not understand. Regards Pete

This log shows something completely different from the pictures you posted previously. You have the two buttons programmed Aircraft-specifically for the Cessna Skyhawk 172SP Paint1 to send Keystrokes to FS -- not the controls you showed in your pictures -- and they also show those keystrokes doing the selected action (ELEV UP or ELEV DOWN) on FS. Neither of those are Trim functions, but elevator functions, as you have assigned the buttons to he keystrokes NUM 8 and NUM 2 (elevator controls). Both pictures you showed before are NOT aircraft-specific assignments, but generic ones which wil be over-ridden when you load the Cessna Skyhawk 172SP Paint1. I think you are confusing yourself enormously by making all sorts of odd random assignments which you are then forgetting. Please do yourself a favour: delete the FSUIPC INI file and start again. But please be sensible. If you don't understand what you are doing, don't do it! Regards Pete

Hmm. Strange. I don't know any way, programmatically, I can make that happen. There is some shutdown code in WideClient (for use on multi-PC systems when when you close FS you want the Clients to close too), but there's nothing similar in FSUIPC at all. Didn't you try ANY version between 4.602 and 4.615? That's a huge number of changes! :-( I'm out tonight, but I'll try setting my system up with some VRi devices tomorrow and see if I can reproduce the problem. Anything special I should know? Will just one connected MCP-Combi do? Do you have a Lua program running for it? Maybe a sight of the VRi parts of your FSUIPC4.INI file would help me reproduce it? Regards Pete

Things can't simply "stop" working when nothing changes. That's obviously self-contradictory. Something changed. I'm afraid you need to explain morewhat do you mean by "not working"? The current interim release is 3.988. Install that, run FS9, Close FS9, show me the FSUIPC.LOG (from the modules folder). And explain what is and what isn't "working". Please don't just say "SIOC" because that means nothing to me. For SIOC support you need to go to SIOC support. Regards Pete

So it's something to do with the aircraft, not hardware or FSUIPC. Do Wilco support that aircraft? Have you checked the default 737? Pete

Not sure where the throttle comes in, but almost nothing in the default FSX aircraft can be driven by mouse macros. Microsoft did not obey their own SDK gauge-writing rules even in FS2004, and most of the FSX aircraft are written in XML not C/C++ in any case. It sounds like all the functions you wish to operate have FSX controls for them, so you can assign them in the normal drop-down assignments list. That's not true. How do you do it on the keyboard, for instance? You press F2. F2 sends the FS control "Throttle decr". You can assign that to any button. Set it to repeat whilst held. If you want separate reversers use Throttle1 decr, Throttle2 decr, etc. You can easily find the FS name for any control using FSUIPC's event logging. Enable it (in the Logging tab in FSUIPC options), then operate the control (mouse or keyboard), and then look in the FSUIPC4.LOG (in the FSX Modules folder) to see what EVENT occurred. The name will be there. If you (temporarily) put FSX into Windowed mode you could even use the "console log" option to show the output to the log in real time, on screen, as you operate things. Regards Pete

Using what, buttons on joysticks, or the buttons on screen, in the gauges themselves? You could enable Event logging in FSUIPC and check the log to see what controls are being sent. And what version number do you have as "the latest"? The term "latest" is meaningless, folks use it to mean the last one they saw. Check the Announcements at the top of the Forum please. Regards Pete

No, the SET commands all set a given value, the parameter. All of the joystick Axis commands are "SET" commands, for example. These are not my names for them. The list is produced from tables in the FS CONTROLS module. They are the control names chosen by Microsoft. Possibly. But you seem to be interpreting things slightly oddly in any case. I don't know why one would assume you had to send another command to stop an action which is performed by holding a button down. The mere act of releasing it stops the repetition, just as it does with keys on your keyboard. Okay. Those are fine. You can check for yourself quite easily. Go to the FSUIPC options, select the Logging tab, enable "button" and "event" logging (don't touch anything else there). OK out. Operate your buttons, then look in the FSX Modules folder. In the FSUIPC4.LOG file you'll find the results of your button pushing. Show this to me and I'll tell you what is going on. It is sounding like a dual assignment, that you have something still assigned elsewhere, possibly in FS. Version 4.57 is certainly out of date and unsupported. It it most certainly NOT the "latest". As I said, folks need always to quote version numbers as "latest" is as meaningless as it turned out to be here. :-( Please do review the Announcements here in this Forum which tell you these things. You did NOT "buy" 4.57 but FSUIPC4. I only support current versions. Please update to 4.60 at least. There's a later update in the Updates announcement but you need to install 4.60 first. Regards Pete

What have you programmed the other button to do? Obviously if it is a two-way centre off switch it will be signalling TWO buttons to FSUIPC, not ONE. It sounds like you've cleared the release of one of them, but completely forgotten about the other -- and not only that you've programmed both to do trim down. Regards Pete

And what is "the latest"? Please always report the VERSION number. "Latest" is meaningless to me. Folks have said that evidently meaning "the latest I have noticed", and in some cases they were a year out of date! Version numbers are important and not at all difficult to find. Yes, and as your picture very clearly shows, you programmed the release of the button to send an "elevator trim set" with a parameter of zero, which will re-centre the trim every time you release the button. Take a look at the picture yourself! Hiw can you miss seeing it? I don't know why you've done this, but FSUIPC is obeying your every command correctly. Regards Pete

Fixed in the current interim updates, 4.615 and 3.988. Regards Pete

That means the place you are trying to program isn't susceptible to this facility. As it says in the documentation, only "some (sorry, not all) of those Panel switches and buttons and knobs" can be handled this way. The mouse macro facility can only intercept and handle calls to Gauge routines written using the standard C/C++ gauge SDK. Many aren't these days, especially not Microsoft's own gauges, and certainly no gauges written using XML. Regards Pete

I wasn't back till quite late last Monday (the 24th), but there was no email from a "cspencer" address seen here. Want to try again? I assume you mean @ where you have an > in the address? Pete

Why is it not clear? I cannot provide instructions on Windows networking -- that's Microsoft's job and they do it at great length throughout the help files and so on. Install it and try it. If your Network is working and you haven't got firewalls blocking things, and both PCs are in the same workgroup, then it should work with nothing else for you to do -- that's how it is designed, install-and-go. I hope your wireless connection is good. Wireless links seem to be quite troublesome for many. If the Laptop is near enough I'd recommend using a wire. Pete

You can have any number of joysticks assigned to similar or even conflicting axes, provided only that they do not send any inputs when not being used. The problems with disconnecting joysticks altogether are twofold: 1. Without taking precautions, like using FSUIPC's joystick lettering facilities, disconnecting and reconnecting USB hardware can make Windows assign different IDs each time. This could make a complete mess of your assignments. 2. A joystick which is not connected but which still has an opoerating driver in Windows could provide spurious values on interrogation. This certainly almost always happens with Game Port devices, but I think this should be less of a problem with USB. Aside from that, if both joysticks are connected, with conflicting assignments, just be sure the levers or axes not being used are left "parked" in a position where no changes are ever seen. For a throttle this means having a generous enough idle dead zone to avoid any sort of jitter resulting in changes. FSUIPC only reacts to changes on the inputs. The other, cleaner, way of tackling this is to have two profiles, one using one throttle and one using the others. The restriction you have then, of course, in on aircraft assignments, as profiles are selected automatically for the aircraft assigned to them. If you wanted to fly the exact same aircraft with either profile, you'd need to duplicate that aircraft with a different name. However, the same aircraft with different liveries, for example, can be assigned to different profiles -- the name is the distinguishing factor. Yes, but only when they changed values. That isn't the way in any case -- for different assignments and calibrations it is best to use different profiles. Regards Pete

So, 90% N1 is the TO/GA RPM rating for that aircraft. Isn't that what you were after? It probably wouldn't be set BEFORE you press TO/GA because it is an autopilot target setting. Regards Pete

Please never try to download updates from out of date threads, at least not without checking first. Take a look at the Updates announcement in this Forum. That's where the latest tested updates are always available. We are up to version 4.614 now. However, since you are not using the facilities which appeared to exacerbate the problem, I very much doubt that anything changed in FSUIPC will affect the error you are getting. Nevertheless it is worth updating to the latest version. Try it and see. Pete

It never changes when you use the controls to change it? That makes no sense. The value you are talking about is probably set in the AIRCRAFT.CFG file. Regards Pete

WideFS is nothing whatsoever to do with screens or views. It is a multi-PC expansion for the FSUIPC application interface. You are confusing it with WidevieW by Luciano Napolitano. And yes, that uses multiple PCs too. Pete

fixed here, but there's a couple of other minor changes I need to finish off. I am planning a release, in the Updates Announcement above, either late Monday, or Tuesday latest. Regards Pete

What VRInsight devices? I am no expert. I don't actually use them myself, I only programmed a facility to allow buttons and switches to be assigned in FSUIPC. What are you having difficulty with? I am not for hire, and I'm not mobile -- my eyesight is so poor I am not allowed to drive and have not been for years now. If you want help, please explain the problem to me first. If you want help in person I can only suggest that you pay me a visit instead of me you. But be aware that I do not have add-on aircraft which supports some of the VRI devices such as the CDU. And setting things up so that you can assign buttons in FSUIPC only amounts to a couple of steps once you have the VSPE program. More details please. Regards Pete