Pete Dowson

You might need to ask in a PMDG forum. That control is PMDG specific. I don't think it can be a problem with FSUIPC. FSUIPC will simply send on what you specify, as you can prove to yourslef by using Event logging. I suspect it is something to do with those parameters. i think the PMDG file listing the controls also lists the different mouse codes you can use as parameters with them. I don't think mouse codes are as simple as 0 and 1. They would more usually specify left click, or release, or right click, or double click, etc. etc. Pete

It's only the PMDG which has peculiar ways regarding inputs. Sounds like you have Windows operating power saving on that device's USB connection. Make sure you turn all USB power management off (properties of USB in Device Manager). Then it is almost certainly because of all these direct assignments and calibrations: 0=AX,321,D,1,0,0,0 -{ DIRECT: Aileron }- 1=AY,1,D,0,2,0,0 -{ DIRECT: Elevator }- 2=AZ,1,D,22,0,0,0 -{ DIRECT: Spoilers }- 3=AU,1,D,5,0,0,0 -{ DIRECT: PropPitch }- 4=AV,1,D,6,0,0,0 -{ DIRECT: Mixture }- 6=BX,256,D,11,0,0,0 -{ DIRECT: Throttle3 }- 7=BY,256,D,12,0,0,0 -{ DIRECT: Throttle4 }- 8=BR,256,D,10,0,0,0 -{ DIRECT: Throttle2 }- 9=BS,256,D,9,0,0,0 -{ DIRECT: Throttle1 }- 10=CX,256,D,7,0,0,0 -{ DIRECT: LeftBrake }- 11=CY,256,D,8,0,0,0 -{ DIRECT: RightBrake }- which are unsuited to the PMDG aircraft. I was mainly guided by the subject: of this thread: "UNCONTROLLED RUDDER INPUT AND STEERING DEVIATION" You should evidently have started a fresh thread with a more relevant title. Pete

Just try searching the supplied offsets list. "wind speed" finds 0E90 very quickly. The direction is also important of course -- 0E92. Pete

No, because the runway is simply a scenery object, part of the definition of the airport layount. You'd need to find the runway in a database so you can get it's coordinates and do the calculations. If the runway has a VOR\Localiser near the touchdown then you could use its coordinates instead. You would need it turned in on NAV1 or NAV2. See offsets 0874, 0878 or 084C, 0850. Pete

Offset 0505 is part of the area used by Project Magenta. You need to refer to Project Magenta documentation of ask PM support. 07F4 is the autopilot N1 hold switch. It is either true (=1) or false (=0), no other useful value. 07FA is the autopilot RPM hold var. Maybe these only apply to aircraft with RPM/N1 hold facilities on the autopilot? I don't know. FSUIPC is only providing variables available from SimConnect. The valueu I think you may be looking for is, as you say, computed based on many things -- including whether you use a derated value for assumed temperature, different flap settings, V1 values for the runway, and so on. I don't know where that is computed within the Sim code, if it is. I've only ever used it with add-on systems, like ProSim. Sophisticated add-on aircraft will also be computing it themselves. Are you sure that the sim itself uses anything other than max thrust? By all means have a look through the SimConnect "Simulation Variables" available (they are tabulated in the P3D SDK on the L-M website) and see if any of those look likely to be what you want. If you find it, let me know and we'll see if it is mapped to an offset, or if not, put it on the list. I must admit I see nothing likely. Pete

Not that I know of. It must be one of the parameters in the specific Aircraft.cfg file. Of course, you can read it when set by TOGA, in offset 07FA. Wouldn't that be sufficient for your purpose? I would have thought so. Pete

Not sure how those relate at all to FSUIPC. When did those crashes occur? It seems not during the very short session with FSUIPC 4.974 running, as the log you appended shows a normal closure signalled to FSUIPC by FSX. If the problem is geographic, then the problem is likely to be a corruption in your scenery installation. or a corrupted weather file. If there's no problem without FSUIPC running then it is more likely to be the latter (because FSUIPC regularly requests weather data from FSX, and unfortunately FSX doesn't check the weather files it reads. Small corruptions, caused possibly by crashes or some weather programs, can be enough to cause memory corruption, resulting in unpredictable errors. Try deleting the wxstationlist.bin file from your Appdata\RoamingMicrosoft\FSX folder, and also all of the .WX files in your Flight Simulator documents folder. As a last resort, try setting "NoWeatherAtAll=Yes" in the [General] section of the FSUIPC4.INI file. That will simply stop FSUIPC asking FSX to supply weather information. That can affect FSUIPC applications. Pete

UPDATE YOUR FSUIPC! Version 4.949 is very old and unsupported! Current is 4.974. Then, if there is still any problem, obtain the crash details from Windows Event Viewer, and supply the FSUIPC4.LOG file from the Modules folder not the Install log which is irrelevant to the running of FSUIPC. Note also that a crash is either in NTDLL or FSUIPC.DLL, not both simulataneously. Pete

The only ones I've come across arethe more recent ones by UK2000. There was no issue, no difference in the data, at GMMX as I said. Pete

Good! Glad to hear it. Good flying Pete

Did you run the FSUIPC Installer? If not, do so. If so, show me the Installer Log file please -- just paste its contents into a message here. You'll find it in the same folder as the Installer you ran. Don't delete files. That never helps. The installer needs to be used. Pete

Perhaps I can explain what the problem is, so you can understand. The PMDG aircraft do not get their control inputs in the normal way, from the Sim. They appear to be intercepting these inputs on arrival in SimConnect -- in the same was as FSUIPC -- and use those values. In order to provide calibration and other facilities, FSUIPC does the same thing. It then calibrates the values as instructed and sends them on the the Sim. This latter action has to be done at a different level, otherwise there would be an infinite loop continually calibrating with no end result. So, if you calibrate in FSUIPC, the aircraft ends up receiving two values which, because of the alteration calibration makes, will normally be different. Even if they are not different, which is unlikely, there could be a slight timing difference in their arrival, resulting in stutters. The answer is, therefore, sometimes to NOT use FSUIPC calibration for these aircraft. This means either assigning in the Sim instead of FSUIPC -- an unsuitable choice if you are assigning for other aircraft, in other profiles, in FSUIPC - or assigning in FSUIPC but to the regular AXIS ... FS controls. Then don't calibrate. Luckily, because FSUIPC offers the Profile system, this doesn't need extending to other aircraft, only those prone to this problem. Incidentally, in the past the main reported problems with PMDG assignment and calibration have not particularly mentioned rudder problems. More usually jittering throttles. But even saying that I've seen reports from some folks who've managed. ------------------------------------ Looking at your FSUIPC settings, you do appear to have assigned the rudder to the regular AXIS control: 12=CR,256,F,65764,0,0,0 -{ TO SIM: AXIS_RUDDER_SET }- You have also calibrated, at least nominally: Rudder=-16287,0,0,16383 Looking at that, I'm thinking that possibly your main problem is really that you've calibrated with no central neutral zone. It is very rare to come across rudder pedals which always centre exactly. If you are going to try calibrating you do really need to do it properly -- take a look at the numbered steps in the User guide. Pete

"FSUIPC.dll_unloaded" actually means FSUIPC isn't there, it's been closed along with the rest of P3D. So it cannot actually cause a crash. FSUIPC sometimes does get the "blame" for closing down crashes because it is usually the last to still be there -- some of its threads run around tidying things up for the external FSUIPC interface and any WideClients which may have connected. I don't know how such an error arises -- normally the way to nail it is to follow a process of elimination to see which component is responsible, but you already have that identified -- the OpusPDK_v45.DLL module. You could try a different loading order in the DLL.XML. In otherwords, move this section <Launch.Addon> <Name>FSUIPC 5</Name> <Disabled>False</Disabled> <Path>D:\Prepar3D v4\Modules\FSUIPC5.dll</Path> </Launch.Addon> before the OpusPDK_v45.DLL entry. I see that the FSUIPC log isn't complete -- FSUIPC hasn't even received notification that P3D is closing. If that is where P3D crashed then FSUIPC wasn't "unloaded" and you hadn't requested P3D close down. So, are you sure that's the right log? Within the log I see another problem. Starting from about 58 minutes into the session one of your USB devices started playing up: ***** HID USB device reconnected: re-initialising FSUIPC connections 3501333 HID: Vendor=045E, Product=0745 (Version 6.99) 3501349 Manufacturer= 3501349 Product= Microsoft® 2.4GHz Transceiver v7.0 3501364 Serial Number= this repeated every second, and in fact the Log finishes at the end of one such episode. Perhaps this has something to do with it? Do you have other PCs wirelessly connected to the session? WideFS clients perhaps? I see you have WideFS registered. Perhaps the WideServer.log is relevant? The "unloaded" error might just be messages arriving for FSUIPC after it has closed down -- whilst FSUIPC's WideServer does try to close everything tidily, some autonomous parts of the TCP/IP linking softare, in Windows and in the Mobo drivers, are in the process of sending something when FSUIPC is forced to close along with all other parts of P3D -- it imposes a time limit. So, another avenue to investigate is to set all WideClients to close themselves down, along with programs they started, when signalled by the Server that the session is ending. Is Opus using the network links too? Pete

Assuming you'd calibrated properly, and the controls are definitely disabled in FSX, I suspect that the time available for FSUIPC to read, calibrate, and post on the values for the controls is just not available. Also, FSUIPC limits its polling frequency to avoid impacting performance. The rate is set by the "PollInterval" parameter in the [Axes] section. Now see this from your log above: Average frame rate for running time of 185 secs = 219.1 fps That's an obscene frame rate! FSUIPC would need to poll 2-3 times more frequent to keep up. It also means FS is less able to spend time on other things than generating your views. You will probably find that mundane things like scenery texture loading lags behind if you ever go faster that the Skylane takes you. Consider limiting the frame rate of your sim using the built-in limiter and / or Vsync options in FSX. You don't need more than 60 fps, and many folks are happy with 30 fps. I run my P3D installation at 25 fps. Pete

FIRST, PLEASE NOTE THAT I'VE HAD TO MOVE YOUR POST BECAUSE YOU PLACED IT IN THE REFERENCE SUBFORUM 'FAQ' WHERE IT WON'T GET ANSWERS! ---------------------------------------------------------------------------------- If you mean delete their assignments in FSX-SE, then there's no need to do that in any case. Instead, if you intend to assign only in FSUIPC, then you should disable each of the controllers explicitly. This is because, even if you delete all the assignments, FSX will made new assignments automatically if at any time it thinks the devices are newly connected and therefore waiting for defaults. Pete

Two points here: First, if you did purchase FSUIPC3 then that registration is not valid for FSX. You would need to purchase a new one for FSUIPC4. Second, this is a Support Forum. We don't issue registrations. That's all done by SimMarket. You need to open your SimMarket account, then you will be able to access registrations codes for all purchases you ever made there. The FAQ ("Frequently Asked Questions") subforum above includes help in this matter. See these entries, for example: Pete

Sorry, what you say seems to be a bit confused. You said that the Cut Off button assignment you had was not working, so you reassigned it, but it still isn't working on the 747-400? So I assume you mean you are using spearate profiles for these two aircraft, and what you seem to be saying is that you've only assigned Cut ff in one of them. Are both of these from PMDG? If so, why aren't you using the custom controls supported by the PMDG Boeings? I think you need to tell us more, andmore clesrly. Which flight simulator? Which version of FSUIPC? Also, you do really need to show us your FSUIPC settings (the FSUIPC INI file, found in the FS Modules folder. Pete

I don't think that matters. Lookng at the part you supplied these interruptions are occurring at intervals: **** No SimConnect events or states being received! Re-connecting now ... **** That occurred 4 times in the short log segment you provided. That is terrible. Each time SimConnect stops sending data to FSUIPC for a while, FSUIPC has to decide that the connection is gone and it reconnects. That involves a complete re-initialisation, so itself takes some time. There is a parameter in the FSUIPC4.INI file which determines how long it waits before deciding things are wrong, but whilst you could try increasing that, i think first you should work out why it is that your setup cannot cope. FSUIPC needs continuous data being updated by SimConnect in order to carry out many of its operations. Generally these particular SimConnect problems occur because the system is massively overloaded, so perhaps you could list the AddOns you are using too? You may be using an advanced cockpit like those from PMDG or Aerosoft, and have the Autosave option enabled -- either in FSUIPC or in another program. Most such aircraft also save a few files detailing the state of the cockpit, so a simple FSX-SE flight save turns out to be several seconds of disk operations. Sometimes an increase in FSUIPC timeouts will help with that. Finally, your ACARS program needs to allow for more of a delay in receiving data, to overcome periods like that described. It does sound like it is in need of a bit of improvement. Pete

It doesn't. That would be a waste. The only time it re-reads any parts are the specific assignments sections, when the "reload" button is pressed on the appropriate option tab, including any Lua or Macro files needed for to completely list the possible assignments, and also the Traffic section each time the options are visited. (That latter is really not needed now that all those options havetheir own Tab now). Pete

Sorry, you misunderstood. The centre position would be just the OFF for both the others. All you need is for two to be recognised. You can program the off for either or both.

Forget it. I've compared GMMX results with MakeRunways 4.840, 4.891, and 4.892 with the OLDNDRAW parameter. They are all completely identical. So if ProATC/X has a problem with GMMX then I'm afraid ithey need to fix it. I can't help. Pete

I don't really understand the last part of this question, but regarding FSUIPC assignment, is each position on the 3 way distinguishable in the assignment tab? The centre may be 'off' for both, but the other two should signal different button numbers. It's not normally necessary to delete the macro. if you don't want to use it, don't assign it. If you just want to delete things you aren't using, for some other reason, the macros are recorded by name in the file named. i.e the assignment drop down might say "A320:switchx" which simply means the line(s) starting with switchx in the file named A320.mcro. Pete

Yes, you could do it in a fairly short Lua plug-in. There is a another way which should work, and that it to use a conditional assignment based on the throttle offset for the engine to are dealing with (or just engine 1 if you have only one throttle for all engines). This would entail editing assignment lines in the INI files [Buttons] section. See the section in the FSUIPC Advanced Options entitled "ADDING OFFSET CONDITIONS". You'd had a confition one the repeat setting for Throttle Decrease which tests whether the throttle value is =0 before it starts decreasing, and an entry for a non-repeating press with the condition that it is <0. Pete

I've re-titled your new thread more appropriately. The subject of your question is not about "Jacob Wiqvist" is ut? Please always choose a more appropriate title! A shortcut just points to a "target" program to be run. So you set it to run the program directly. If you want to add a parameter, which is what I think you mean, just add it to the end in the normal way, or enclosed in "". Please see the Advanced User manual. The section entitled 2Programs: facilities to load and run additional programs" does actually give such an example -- about half-way down the page. Pete

So GMMX fails with the command line option set to make 4892 act like your old version? But GMMX is okay with the correct encoding (4891 or 4892 without the option)?