Pete Dowson

While installing FSUIPC? There's no possibility of such a message originating from the installer! It simply places the updated module in the Modules folder (creating it if necessary) and installs updated documentation and other goodies in the FSUIPC Documents subfolder. Please explain more carefully exactly what you see and when you see it. Note that the Installer creates a Log showing every step it takes. It is called FSUIPC4 Install.log and you'll find a copy in the Modules folder and also next t the Installer itself, wherever you ran that. Please view that Log or paste it here so I can help you and reassure you that the installation was good or otherwise. There are two checks made when FSUIPC4 is run -- i.e. when you start FSX. Nothing to do with the Installer. The messages which can arise then are one of these: Pete

PFPX and TOPCAT, together. Moving map, charts, etc is Aivlasoft EFB. Pete

As far as I am aware, you cannot calibrate throttles for the PMDG 737NGX in FSUIPC, because that model demands to see the throttle inputs at a higher priority level. In order to calibrate the throttles FSUIPC has to intercept the inputs at that level, manipulate them according to your settings, and send them back to FS at a lower level. This creates direct conflicts in the NGX because there are two competing values arriving. To check calibration of your throttles in FSUIPC, select a default aircraft, or at least not a PMDG one. The full range being RECEIVED from your throttle lever should certainly be in the region of -16384 to +16383. That would be for a well calibrated (in Windows) axis, or a modern digitally controlled axis with no Windows calibration. The IN values shown on the calibration tab should increase gradually from the one to the other. All FSUIPC does is use the positions you SET as Minimum and Maximum to work out how to map that movemetn to the OUT values needed by FS, which are also -16384 to +16383, or 0 to 16383 for the No Reverse Zone option you've chosen. So, big question: do the IN values change slowly as you move the axis slowly, or do they jump in the way you've said they do in the aircraft? All that does is create a dead zone. It cannot change the behaviour of the input values. Check that the IN values change smothly as you move the throttles. If so then your only problem is trying to calibrate in FSUIPC for an add-on aircraft for which this is a no-no. If the throttle lever gives input values which jump, maybe all the way or maybe at the half-way point, then this is a typical Saitek installation error which is corrected by a Registry edit -- for this see the FAQ subforum thread http://forum.simflight.com/topic/79464-some-saitek-axes-only-provide-partial-movement/. Pete

Active Sky, in its earliest forms, used FSUIPC to control the weather, and could therefore interface via WideFS too. The later versions which used SimConnect on FSX were also FS9 compatible and automatically used FSUIPC on FS9 and SimConnect on FSX, but could use WideFS for FSX if told it was interfacing to FS9 even though the Server ran FSX. The current version of ActiveSky, ASN, is all SimConnect AND direct control into FSX/P3D -- it puts its own hooks in. It is this which allows is such precise control over the weather and especially in cloud placement (which is also why its weather radar is so accurate, down to specific rain cloud areas). Quite honestly, ASN runs best, and very well too, on the same PC as FSX, but it can be run on a SimConnect client. The instructions for doing this are quite clear I think. You still need also to install it on the Server so that it can use its direct hooks. Pete

You are adding to a 2-year old thread which was in error as it was. This thread was about removing FSUIPC, not about any error message, so why are you posting here? You provide no information except that you get an error message. What version of FS or P3D are you using? FS2002, FS2004, FSX, P3D? What version of FSUIPC are you using -- the number, please. I really cannot help without information. Pete

Why are you posting the same question twice, and in different threads? Please see my reply to your earlier message. Pete

FSUIPC3., the one for FS9, has not been updated for years, so what exactly do you mean by "the last two updates"? You need to look elsewhere. Perhaps you are running FS "as administrator" and AFCAD normally, or vice versa? That would prevent them communicating. If you think there's a problem I'd need to see the FSUIPC.LOG file, from the FS Modules folder -- but close down FS first. Pete

You should start the new log near the 6 hour point! Pete

I think other programs in those days (FS9? So long ago! ;-) ) wrote to the acceleration offsets instead, to brake aircraft at different rates. There was one famous program (which I don't even remember now) which used those values for catapult launches and tailhook braking. Pete

Right. So I misunderstood your questions right from the start when I tohught you were trying to assign a 3 way switch. Pete

Right. And the reason is not clear from the Log because it only shows the first 1 hour 20 minutes. This is from the very start of the log file. Within 7 seconds of everything being "ready to fly", Simconnect is already floundering, not able to keep up with the demands mad on it. This one is recoverable. But then: That's 60 seconds later. Looking through, this failure repeats every 60 seconds. Don't you notice any pauses every 60 seconds? I suspect this is due to a flight being saved at 60 second intervals. The PMDG aircraft are notorious for taking ages to collect all the data to be saved and created large files with the state of everything. Unless your system is really very well set up for disk caching and with fast writing disks, then this appears to take too long. Quite honestly, if you are using some autosave program, or the Autosave in FSUIPC, I would advise against it when using PMDG aircraft. But alternatively, you can change the SimConnectStallTime parameter in FSUIPC's INI file from its default of 1 (second) to something larger. This will make it be more tolerant during such episodes, but perhaps at the cost of upsetting client programs. The rest of the log shows the same things continuing, and it finishes after a mere 1 hour and 20 minutes. So there's no information there about what happens after 6 hours. The performance of your system doesn't look too good though -- how do you manage to tolerate it for 6 hours? ;-) Rather than submit a 6-hour log, with the 60 second repeated re-connections going on and creating a massive log file, when you get close to the 6 hour point, go to the FSUIPC Logging tab and click "New Log". That'll save the log till then and start a new on. Pete

This is confusing! So you are NOT trying to assign actions to a real hardware 3 position switch? You are just using ordinary buttons? If you want one button to move through different controls each time you press it you just need to make use of the offset condition. Use a free user offset, such as 66C0, increment it cyclically with an Offset Byte Cyclic Increment control, and make the condition based on that value. The example in the FSUIPC4 Advanced User's guide uses two buttons. here, I've pasted it for you to save you the bother (but you should read the section on button programming in any case): The two button method allows selection of any of the positions, becase the extra button preselects the one to be actioned. But you could use just one button if you always want to operate the complete cycle. For that you'd simply assign the cycllc increment action to the same button, so the above example becomes: 32=B66C0=0 P117,6,C1 030,033=B66C0=1 P117,6,C1 034,0 34=B66C0=2 P117,6,C1 038,0 35=B66C0=3 P117,6,C1 042,0 36 =P117,6,Cx510066C0,x00030001 Note that I moved the increment to the end, so it executes last. Assuming 66C0 startsequalling zero. Pete

You give lots of rather irrelevant information, but nothing about FSUIPC. For example, what is the version number of the FSUIPC you are using? Have you made sure it is the latest, the only supported version (4.945)? What tells you that FSUIPC has "stopped working"? Just because your ACARS program stops does not mean FSUIPC has stopped. Does the FSUIPC entry in the Add-Ons menu disappear? What tells you to blame FSUIPC? If there is any problem which FSUIPC detects it will be logged. That is what the log is for, so next time it happens, first check whether the FSUIPC entry in Add-Ons is there, and, either way, grab the FSUIPC4.LOG file from the FS Modules folder, and take a look inside -- paste its contets into a mesage here for me to check it for you, if you like. Pete

You can make as many assignments to the same button as you wish. FSUIPC executes them in order. But if you have a 3 position switch, surely each position is detected seperately -- or at least one position = "released" and the other two different button numbers? If not, then the wiring of the switch is all wrong, with all three positions, or at least two of them, wired together! I think you are rather confused here. The FSUIPC macro facility is a method of allowing a single or sequence of commands, whether L:Var writes or simple control or keyboard assignments, to be stored in files (.mcro files) with names which can be assigned in the Buttons & Keys tab. Maybe you are assuming that "macros" always means "mouse macros". Mouse macros are a specific type of macro which operates mouse action areas in gauges which are suited. But that is only one type of macro (and the most recent addition to the range of things macros can do as well). I think you need to review some of the documentation and examples. Also browse through others' work in the User Contributions subforum. Pete

Please always post support questions in the Support Forum. You are lucky I saw these posts! Axes are not read nor transmitted by WideFS, only buttons and switches. This is documented. If you want to send axes from a client PC you'd need to write a Lua plug-in to do it. Pete

And they are? Anyway, I checked on the default A321 in FSX, with "Event Logging" enabled in FSUIPC so I could see what controls it used. The SPD adjustment knob, when pushed, actually sends "AP PANEL SPEED HOLD". I don't know how to "pull" it. The control is a toggle, so each time you press that knob it turns the mode on or off. Likewise the heading adjuster, when pressed, sends AP PANEL HEADING HOLD, another toggling control. Unsurprisingly the ALT knob operates the toggle AP PANEL ALTITUDE HOLD. I think these controls are pretty universally used on aircraft with MCP-type displays for their Autopilots. They are certainly easy enough to find in the FSUIPC assignments, and of course in FS's own assignments, though FS doesn't use the formal names in its menus. Pete

With FS's auto-rudder set, you steer on the ground using your aileron control. There's nothing FSUIPC can offer to do any differently if you have no rudder or steering tiller. You just have to practise more. Pete

If you mean the autopilot mode buttons for speed select, heading sleect and altitude slect, then the FS controls for those are clearly listed in FS and in FSUIPC. In FSUIPC they would be one or more of these AP_AIRSPEED_HOLD 65859 AP_AIRSPEED_OFF 66094 AP_AIRSPEED_ON 66093 AP_HDG_HOLD 65725 AP_HDG_HOLD_OFF 65815 AP_HDG_HOLD_ON 6580 AP_ALT_HOLD 65726 AP_ALT_HOLD_OFF 65816 AP_ALT_HOLD_ON 65808 [LATER] There are also "PANEL" versions, AP_PANEL ..." of some of these. Please see the list installed in your FSUIPC Documents folder, or just look through the AP controls in the assignment dropdown. Those names are as listed in FSUIPC's drop downs and are the internal names FS uses. The numbers are the actual control numbers sent in messages. However, if you are using an add-on aircraft, like the Aerosoft Atibus, they might have their own autopilot controlled by their own controls. Many such add-on aircraft do their own thing and you'd need to research that separately. ete

The Lua file you have written runs once, then terminates. There is nothing there keeping it running, so why bother to have it loaded in an [Auto] section? It will there presumable operate with a zero parameter? Is that what you intend? I assume so because you've no assignment with parameter 0. I offered two alternative ways of doing what you wanted and you seem to have tried to combine both. Why? Why are you writing the same L:Var at the start, every time, to "set to zero"? Maybe there's not enough time between the two writes to the same mechanism? Apart from that, there is no difference for the Lua actions between parameters 0, 1 or 2, so any differences you are seeing must be functions of the add-on. Try using the Lua debug/trace option (in the Logging tab) to see exactly which lines are actioned and what the values are. Pete

Please send the request by email == petedowson@btconnect.com -- and I'll look at it. But it won't be till early October now, at the earliest. Pete

You don't actually ask a question. But I assume you have found that those FS controls do not work on the PMDG 737NGX. There was no need for all those pictures, a few words would have sufficed. The assignments you've used would work on any normal add-on or default aircraft, but PMDG implement all of their own controls. There's a list provided in one of the files in their 737NG SDK folder, and you can assign them by number using the <custom control> selection in FSUIPC. Pete

Sorry, i don't know such a file. It isn't anything to do with FSUIPC. Pete

Why did you delete files being updating FSUIPC? There's never any need. FSUIPC updates simply replace programs and documentation. They never change your settings. Everything you've setup in FSUIPC4 is stored in the FSUIPC4.INI file, unlesx you are using Profiles and have selected the Files option, for separate Profile files. If you like, paste its contents in a message here and I'll try to find what you've set wrong. Pete

No, and there's no point. There has not been any change in FSUIPC's treatment of axis assignments and calibrations for many years. It is all standard DirectInput stuff. Ddn't you follow the link I gave? Pete

You can either have multiple small Lua plug-ins, one for each assignable function, and just assign those buttons appropriately, or you can have one larger Lua plug-in,loaded initially (perhaps by an [Auto] entry in the INI file), and have that do different things according to the PARAM value, the Parameter you provide when assigning a button or switch, In the former case you assign to "Lua name" in the second to "LuaValue name". Your choice. Whatever you find easier. I doubt there's much difference in performance or efficiency. Pete