Pete Dowson

MCPs (Main Control Panels) are not normal joystick type devices, because they have displays and dials. The version of FSUIPC you are using produces a Joy Scan results file (type csv) -- please show that too, as requested in the text in the place you got that version of FSUIPC from. A HidScanner log might also be useful. it would show what "type" of device those MCPs identify themselves as. HidScanner is available in the Useful Additional Programs thread in Download Links. Pete

They must be assigned in FSX. What PFC console. You've not really given much information. What is your "latest FSUIPC" version? The very latest, which improved device scanning is 4.966n (see the Download Links subforum). It might be worth trying that -- but don't assign in both FS and FSUIPC. That will induce conflicts. Pete

I think the mouse tables the macros call inside FS only refer to the currently selected view. That's why it is always best to use the virtual cockpit rather than change views away from the switches to be operated. Pete

There's really no function in FSUIPC aimed at this. ActiveSky has a facility to stop weather changes when near the airport. I'm pretty sure it was in an FS9 compatible version. Wind smoothing isn't related to this. When wind is less than 6 knots or so, FS assigns any runway to AI traffic, so I'm sure that applies to the built in ATC too. Same when the wind is a crosswind with only low components affecting either ends of a runway. Really? That's very poor. I thought it managed ATC itself. I've always used Radar Contact (for many years) till recently when I switched to ProATC/X. PF3 always looked far too cumbersome to me, and I'm surprised it only passes on the FS9 ATC. I'm sure the FSX version doesn't. What sort of "wind shifts"? Smoothing won't stop the wind changing if that's what is set. Maybe I need to enable 'Direct Wind Control' instead? ActiveSky has been using Direct Control for several versions on FSX, where it is very effective. I don't know about FS9. The wind stuff in FS9 is buggy. Pete

When SimConnect does not provide a reply to "SimConnect_RequestDataOnSimObjectType" with SIMCONNECT_SIMOBJECT_TYPE_USER specified within a reasonable time (5 seconds or so). FSUIPC relies on receiving the ID in order to determine when it is safe to proceed with its normal requests. The default is normally the same as the one SimConnect supplies except after starting a multiplayer session, when it changes for some reason. I don't know what the aircraft could do to influence this though. Pete

My own little program "WeatherSet2" (or "WeatherSet") does this, and more. See the "Useful Additional Programs" thread in the Download Links subforum. Pete

Sorry, I have no idea how that scenery is messing up SimConnect, but there's no way I can fix it. It isn't happening within FSUIPC but in the Sim itself. I'm sure other users must also have that scenery. Maybe you need an update for it, or at least a re-install? Pete

Aha! The previous FSUIPC log shows that there was a crash, so FS did not close down properly. The details, actually shown by FSUIPC (instead of Windows) shows the crash was at location 5098183D, which it lists as being in DINPUT8.DLL, which is the Windows library involved in DirectInput. So it seems you have a bad or corrupted Direct Input device -- one of these most likely: 0=Saitek Pro Flight Rudder Pedals0.GUID={6D7C8EC0-0EF7-11E7-8001-444553540000}1=Thrustmaster Virtual Game Controller (root)1.GUID={FABB19E0-8BDC-11E5-8005-444553540000} How it got corrupted is another matter. Have you perhaps had a PC crash, or a power outage, or switched the PC off without closing down recently? Try disconnecting AND uninstalling both devices, including drivers, from the Windows System-Device Manager. Then check loading FS again (saying Yes to the question about running FSUIPC and trying more than once if necessary). If it is okay, connect one device at a time and check after each. The "Thrustmaster Virtual Game Controller (root)" sounds like a driver anyway, not an actual device. Is it software you have installed which does other things with some Thrustmaster device? Can you use it okay without? If so it would be better. Windows native DirectInput drivers are best with FSUIPC (and with FS in general, really). Pete

FSUIPC installing does NOT delete any files, so what happened to the INI and LOG? Did you delete them? If FSUIPC did not run, why didn't FS start? The Windows error you post above says it crashed in AI_PLAYER. That's to do with AI Traffic. Perhaps you have a corrupt add-on traffic file? The Install log isn't relevant or useful. The last FSUIPC log would have been useful though. As the FAQ subforum threads say about FSX not starting with FSUIPC even though FSUIPC never runs, you have to try to tell it to run a few times, sometimes. I think Windows sometimes marks it as bad for some reason, possibly because you are occasionally having FS actually crashing when you close it down -- FSUIPC is often the last part still running. It would be worth your while taking a look art relevant FAQ threads (it's a reference subforum above). Pete

Yes, that statement is still mostly true, though I have investigated how difficult it would be to convert FSUIPC to 64-bit, and it is definitely doable if and when necessary, at least as far as the program interface is concerned. I'd be less sure about some of the user facilities. To start with I'd probably discard all the weather fiddling stuff in the options, which are largely redundant these days with programs like Active Sky, Opus, and so on doing all these things much better. Anyway, I'm on holiday soon for two weeks. Back 26th May. Pete

Do you have any Lua plug-in scripts running? That's the usual problem fixed this way. That/s the Sim's "user interface", mainly used for menus, so it's a bit odd. Pete

You'd need to use a small Lua plug-in to do it, assigned just to the ON event. So you'd only have two lines in the assignments, both facilitated in the Options (no need for INI editing operations), The Lua script would simply send the control (ipc.control function) then sleep(2000) then send the control again. Three lines of script, that's all. Pete

Well it has been, for several weeks, yes.. But with my latest changes I think all will be well -- provided nothing is getting in the way. From your description whatever IS in the way is messing up P3D's ability to read it properly as well. Sounds just like a toggle switch assignment to some shortcut provided by your add-on aircraft. It isn't implemented in P3D itself that I know of. However, I don't know why you'd even consider using the nose wheel steering on the rollout. Just the rudder should do to keep you straight on the runway, including the turns for those "high speed turnouts". For other turnouts you should surely be well under 30 knots in any case. With most aircraft (not the VRS?) you could actually assign your steering axis to FSUIPC's own direct steering control, which uses the rudder, but for which you can use calibration to adjust the effect separately to the rudder axis input. Then, once you are on the ground, FSUIPC gradually changes from using rudder to steering input for the sim's rudder control, between 60kn and 0kn, with them about level at 30 (the 60 limit is an INI parameter). This makes things feel very realistic, both for takeoffs and landings. Oh, and sorry, but I don't really have time, especially this week (away early Wednesday) to investigate the link you provide, but if the normal steering controls in P3D don't operate to steer your aircraft you'll need to find out how to do it. For that their website would seem more appropriate in any case. FSUIPC can only directly support those things implemented withing the sim itself. Pete

There is ALWAYS an INI as well as a LOG file. The INI file is where all your settings are stored. You have Windows hiding filetypes from you so you'll have files just called "FSUIPC". As stated in the FSUIPC installation, and in the User Guide, it is best to turn that annoying and stupid option off (or, possibly turn ON "show filetypes", I don't recall which way around it it). Meanwhile an INI file might just be described as "configuration settings" (which should be a good clue in any case!). FSUIPC reads everything that the device provides, it doesn't pick and choose. It arrives in one block. The fact that it is getting anything shows that it is using the correct information, the GUID in particular. Both X-55 Stick and Throttle provide 2 each, and one on each reads nothing. You were luckier than some having 4.966c get the right GUID without me having to mess in your Registry. (4.966m fixes it by determining in advance which GUIDs work and which don't -- this is the story tabulated in the Spreadsheet csv file you provided. I think you have some Saitek software running which is interfering with the ability of both P3D and FSUIPC receiving all of the data. You either need to uninstall it, or program things correctly in that software. Alternatively you need Saitek support. I am testing X55 here with NO Saitek software or drivers or anything from tthem installed at all, and they work perfectly. The names listed for controls in the assignments are those provided by P3D, not by FSUIPC. I don't even know what the all do, but in this case, even if I hadn't tried it, I would have thought it obvious that steering is relaled very very closely to the nose wheel steering. What else could it be if not? No idea what you mean by HI/LOW gain, sorry. If you did that just to provide this file you wasted your time i'm afraid. The JoyScan file is purely concerned with recording all the stages involved in detecting and setting up the devices in the first place. It completes its job with the writing of the [JoyNames] section in your (unrecognised) INI file, which is also when the Log file underscores the end of the "Joystick Device Scan" section. Pete

No, it isn't at all. Look at the evidence: 1. BOTH logs show completely successful sessions with FSUIPC running and closing normally. 2. The error Windows shows that FSUIPC wasn't even loaded:What is "P4: FSUIPC4.dll_unloaded" What is happening is that it isn't being loaded -- something is stopping it, yet SimConnect, the part of FS which is loading it, still tries to enter it. This causes the "BEX" error which is basically attempted execution of data or rubbish as if it were code. If you read the FAQ about this (in the FAQ subforum) you will see it is always best to tell it to try running. It often recovers. The error on loading, occurring even before FSUIPC starts, is generally caused by a previous session which crashed on exit rather than closing down correctly. When the sim is closed properly, FSUIPC has threads which are among the last to close. These are threads doing things like tidying up any loaded plug-ins, ensuring connected applications know what is happening, and, if WideFS is being used, notifying the other PCs so that the closure is tidy all round. So, next time it happens you need to look for a PREVIOUS crash, not "FSUIPC_Unloaded", which might help explain what caused a crash on exit. Pete

As I said, I was lucky enough to get the similar X-55 donated for testing. To start with one part worked, and the other didn't. Then I got them both working and my USB hub blew! With the new one they decided to change GUIDs quite oddly -- one took a GUID previously associated with the other. Weird. They've actually changed in ways that FSUIPC would have lost them at least twice. Anyway, in the end I decided my code was too complicated and i didn't understand it any more. It's grown horribly over the years. So I chucked it all and started with a fresh plan. This was on Wednesday night. I completed it yesterday, tested it and did some corrections this morning, and I've just uploaded it as 4.966m for folks to try -- but, as I said, I'm away on Wednesday for two weeks so I don't want any feed back till 25th May! ;-) Please see the Download Links subforum for details. DO keep your current FSUIPC4.DLL and INI files safe to restore in the event of problems. When you do (later) send me feedback (positive, hopefully!) please include not only the LOG and INI files but also the new FSUIPC4.JoyScan.csv file. That files saves a real heap of logging! Pete

It is fixed in an Interim update 4.966m, which you will find in the Download Links subforum soon. But take care -- do save your current FSUIPC4.DLL and FSUIPC4.INI files first so yuo can go back, as there are a LOT of serious changes in this test version and I need feedback for users. Please read the instructions BEFORE downloading! But no feedback till after 25th May please. I'm away till then! Pete

It depends on the assignment and the calibration. With PMDG aircraft in particular, and I think the Aerosoft Airbus, it is inadvisable anyway, no matter how FSUIPC does it, to use FSUIPC calibration for the throttles, because even if it uses events it has to feed them in at a lower priority that those aircraft monitor them. FSUIPC has to do this to avoid feedback loops. Those aircraft take the values at the same priority level that FSUIPC does, though FSUIPC bypasses that level if you elect to "send direct to FSUIPC calibration". Then those aircraft probably don't see it at all, and the FS engine beneath changes without their control -- which may or not be a good thing. Pete

Okay. How are the buttons programmed? To set bits or toggle them? Single bits? Hmm. Good spot. Yes, actually, there is a little logic problem in FSUIPC, and as Thomas implied, originally caused by the strange way FS has implemented those buttons. If you set bit 6 whilst bit 7 is still set. Bit 7 still takes priority. Looks like this problem has been in FSUIPC forever -- strange, either no one else has found it before, or has done and not reported it! I'll fix in the next update (end of the month, unfortunately*). Meanwhile, either use Thomas's suggestions, or simply try toggling both bits -- i.e if you are programming, do an exclusive or of 3122 with 0xC0, so 80 changes to 40 and 40 to 80. For assignments just assign Offset Byte Togglebits parameter xC0 or 192. Toggling the bits is actually logical -- after all the COM1/COM2 button are toggling. You don't seem to be able to turn transmitting off at all, they are just mutually exclusive with one always on. Pete * Since I've changed the code here for this already, it will be fixed in the next interim update, hopefully today or tomorrow. But that one will NOT be a replacement, but a test release. I've completely re-written the Joystick scanning and axis and button identification system because it was all getting too complicated, so much so even I, the author, couldn't understand it! This was precipitated by X-55 and X-56 oddities, but it's been coming. The point is though, I can't yet trust it as a fully working release. I'll only release it for trials and feedback.

No it won't -- the data inside is in a completely different format. And renaming it will probably prevent P3D loading it. Pete

None really. Something else must be sending the idle values. Logging might show what controls are being sent, but the source could be other assignments in FSUIPC or in P3D, or even thid party software. Obviously check first that controllers are disabled in P3D. Pete

They are adjusting as I see more how Traffic is loading and populating. It's a see what happens and adjust thing. Luckily, you can do that by editing the file and not having to restart FS -- just visit the FSUIPC Options and OK out. I don't have my current settings set up yet as I've just upgraded my cockpit PC and screens. I'll be sorting it all out when I get back from holiday at the end of the month. I *Know* that my settings will end up very different to before, because now I'm driving three projectors and struggle at busy airports to maintain the VSync of 25Hz. Pete

But does it look in the flights folder (in Documents)? If it only asks FSUIPC to load the flt file then I can easily fix that by discarding the .flt part. But if it is check that it exists first, that won't work. Pete

The MCP is the "Master Control Panel", and A/T is part of what it contros, along with the Autopilot and other controls. You mean the aircraft is not reacting in time to achieve stability and instead is more and more unstable in the vertical? You need to find a better flight model then! It isn't a function of the controls, which just set the target values. It is a function of the aircraft modelling. If this is that case, you are in the wrong place here. You need to find the correct forum for this, maybe the one for your aircraft. Of course it could be that your throttle quadrant is sending wildly varying thrust requests to the simulator. With the A/T engaged those should be ignored for small changes, but I think with default aircraft the throttle position would be ignored for all changes. But if the throttle was playing up you'd have problems flying normally too, without A/T engaged. Do you? Try different aircraft. see if it's the modelling or your quadrant. Pete

The file format was changed to xml. Most maintained programs deal with it. It is a shame that RC4 is effectively dead. That's one reason I moved to ProATC/X -- at least it's live, AND handles SIDs and STARS, well -- and gates and taxiways -- and gets better over time. I'm pretty sure P3D, like FSX, will load a flight if just given its name without the filetype (.flt or .fxml). If RC is actually looking for a file specifically, then I can't really do much for it, but if it is asking FSUIPC to tell P3D to load a flight with name.flt then I can just strip the filetype off, if I don't already (I'll need to check). Do you know? Does it offer a list of files itself? If so then it is independently of FSUIPC and I can't help. Pete