Pete Dowson

There is no difference between 4.939D and 4.939 except the Installer and FSUIPC now both recognise the new build, and I revised the "successful hooking" messages to be more identifiable, preceding them with "--- " in the Log file. Are you sure it isn't simply the SimConnect bug, and FSUIPC isn't actually even getting to run. See if there's a log. If you want any further help I'll need more information, like log details and crash details. Pete

What do you want me to say? If a weather program really wants to cause severe wind shifts even FSUIPC's hooks can't totally prevent them. With ActiveSky the smoothing is helped by their own smoothing actions. Since using FSX with ASN I've not sen any wind shift problems. When I was using weather programs with less wind control than ASN I used something more like that shown in the picture from Stephen, though with something like 2-4 seconds per knot/degree change. Still some got through, especially on the boundaries between wind layers where smoothing is a more precarious business due to the possibility of having the actual targets swapping regularly. Pete Pete

What works and what doesn't? You need to be a bit more explicit. Generally you need to use a trim wheel OR a time up/down button, unless the trim up/down can turn the trim wheel to maintain the same values -- otherwise the two will conflict. If the trim wheel is perfectly stabile (gives no readouts until moved) you might just get away with programming the trim up/down buttons to increment/decrement the trim offset, rather than use the trim inc /dec controls, but it's a bit precarious. Try using FSUIPC's logging so you can see precisely what is happening -- enable event and axis event logging, and console log. Run FS in windowed mode so you can see the log window, then operate the trims. Pete

No, it simply ignores those after the first 127 in the list. 127 as I already said. Delete the unused mcro files from the Modules folder. Then delete the unused lines in the Macro files list in the FSUIPC INI file.BEFORE loading FSUIPC. Delete all those later than 127 in the list too. They will reappear in freed up positions. You should get no where near 127 really. If you are not trying to preserve any existing mascros, but just making new ones, best to delete all the mcro files and the INI and start again. They are the same in any case. Pete

The setbtnstate functions operate in conjunction with the ButtonScreen facility, which is only provided in WideClient. That's why the Lua program must be running in the Client, not in the FS PC. There is no reason why you cannot do what you do on the FS PC on the client instead. jYou could use one of the user offsets (0x66C0-0x66FF), as follows: On the FS PC: if ipcPARAM == xx then RemoveChocks() ipc.writeUB(0x66C0,255) end On the WideClient PC: function ChangeChocksToggle(off, val) if val == 255 then ipc.setbtnstate(177, 0) ipc.writeUB(0x66C0,0) end end event.offset(0x66c0, "UB", "ChangeChocksToggle") Save that Lua in the same folder as WideClient and it will run automatically. Pete

Hmm. That is the location of the Terrain error I was trying to plug, so your results confirm to me that it doesn't work. I might have another look at that area to see if I can understand why, but meanwhile, yes, please make sure DTG have the details of this one -- yours does seem consistent. I know they said they were looking at it, we want to make sure they are looking in the right place. Pete

Apologies. Fixed in 4.939d, now available. Pete

Big ouch! My bad. Because FSUIPC now accepts 12944 as the latest, it stupidly assumed anything before was version 2.4 not 2.5. Silly error, one character, actually, in one of the declarations. I shall fix this immediately and release 4.939d. Apologies! --- 4.939d now released. Pete

At present FSUIPC (registered only) will only even attempt to trap one specific Terrain crash the option is selected. I had planned to remove that option, as I thought it not working, but if you want to try it you need to set SteamTerrainPatch=Yes in the [General] section of FSUIPC4.INI before starting FSX-SE. If this does help, let me know, and I'll default it on as for the G3D trap. Pete

Strange. I'm just checking ... ... no. Here I get 0AF4 = 1715 (decimal), making the value 6.6992. Just check the value in 0AF4. You can monitor it with FSUIPC's logging-tab monitor, very easily. I'm not familiar with this way of coding, sorry. But if the variable _fuelWeight.Value is defined as a "short" then it cannot handle fractions in any case. The division by 256.0 should convert the end result into floating point (it would do so in C/C++), but try copying it to a declared floating point variable before dividing. Pete

I just checked, and it doesn't look like the SimConnect interface (which is what FSUIPC relies upon) provides that value at all. Doesn't the weight per gallon vary with altitude, due to pressure differences affecting volume? Pete

No, don't do that, though the offer is very generous, it would be a waste as I'd not use it except for this one purpose. Thanks. I'll be asking you to test the 777 data mapping if I do it, if it is possible. Hopefully the P3D version of the NGX won't change the way their data is mapped. That would be best. Previously they did actually supply the 737NGX whole, but that was so long ago I've lost contacts. And I've not even reinstalled the NGX since I changed PCs. Pete

Oh, they said they were releasing it yesterday afternoon. Strange. Never mind, The current 4.939 works fine with 12942, 12943 and 12944. You'll just get a warning from the current installer as it doesn't yet know about anything after 12942. Version 4.939c is being released within the hour with a revised installer. Pete

If that aircraft has a standard FS autopilot, assign to the appropriate FS control, of course. If it is non-standard you'd need to find an alternative method. Does it provide keyboard shortcuts for instance? What about Mouse Macros or L:Vars? Have you looked in the User Contributions subforum to see if others have solved it? Pete

There's also now 12944. Though the Installer warns you about this, it doesn't prevent installation and having just checked here, FSUIPC sees to work fine. I'll do more thorough checking over the weekend and update the installer. Pete

Ouch! This is the problem: In 4.939 I carefully modified the Installer so it would recognise the fact that the Registry points to both FSX and FSX-SE in the same folder, which is what happens when you uninstall FSX and FSX-SE and reinstall. somehow bits get left set. After the installer was fixed to handle it completely correctly with none of these problems, you managed to defeat it completely by fiddling the FSX-SE install to install as FSX (thge coexistence bit), but you forgot to remove the FSX-SE installation entry to match! HKEY_CURRENT_USER\SOFTWARE\Microsoft\Microsoft Games\Flight Simulator - Steam Edition\10.0 Parameter"AppPath" ... >>> OK! FOUND FSX-SE! <<< ... AppPath=D:\Steam\steamapps\common\FSX\ ************ BUT this is the same path as for FSX! Will only install for FSX-SE ************ Delete that entry and it will be more like a correct non-coexisitng FSX-SE! Looks like I'll have to deal with another combination of fiddled results -- maybe look for FSX.CFG as well as FSX-SE CFG even when just installing for a supposedly FSX-SE only installation! Pete

No, FSUIPC has no facilities like that, excepting perhaps the ability to reduce the amount of AI traffic. Doing things like changing resolution doesn't usually help, at least with more recent video cards. You may find that FSPS Fiber Accelerator achieves pretty much what you want, even if not in ways ytou were thinking of. http://www.thefsps.com/fsx/54-fsps-fsx-fiber-accelerator.html Pete

The G3D crash trapped by FSUIPC is just one of many different ones which plague FSX in general. It just happened to be the most common one and the only one easy to patch around. The optional Terrain.DLL patch I put in for FSX-SE only did not sem to work so well so hasn't been continued. And it was only one specific crash out of several I've seen reported. What Jordan seems to be saying is that the G3D fix I added seems to also fix the specific Terrain problem he was having -- which might be different to yours in any case. Pete

As well as what Paul said, any control or value that can be sent by a device through assignment and calibration can also be sent by program through FSUIPC's application interface, using, for example, the offsets 3110/3114 for FS control number ("key event number") and parameter value. Pete

This sounds like the (thankfully rare) SimConnect bug. Please see the FAQ subforum thread FSX fails to run after FSUIPC4 first installed Pete

I could have a look at mapping the 777 offsets, assuming PMDG have implemented a similar mechanism, but i don't really want to purchase the 777. I wonder if PMDG can be persuaded to let me just have the SDK portion. I'd then need someone with the 777 to test the results of course. Pete

I seem to have just read exactly the same question is a different thread! :sad: In that one I said I didn't know PMDG had implemented a similar data export facility for the 777. I don't have the aircraft and therefore not the SDK either, so at present I am unable to implement anything similar I'm afraid. No one has mentioned this before either. Pete

Is a log produced? I'd need to see that too, please. And please try again with the very latest test version, Install FSUIPC4939b_TEST so that any crash data you get will match my current code. Pete

Thanks Thomas. I've just installed the second hotfix (taking P3D2.5 to build 12944, and it seems okay. All the important hooks work fine still. I'll be checking everything more thoroughly over the weekend and update the installer when I've done. Pete

That looks exactly like the crash you get when you have a corrupted .WX file (weather file), or WXStationList.bin. Try deleting the latter one first -- you'll find it in the same folder as your FSX.CFG file. If that doesn't work, you'll need to delete the .WX files associated with the flights which cause the crash on loading. These files are binary files and are not properly checked by SimConnect when it is being asked to supply weather information by FSUIPC. Sorry, but FSUIPC did not crash. It closed normally as you can clearly see from the Log. FSUIPC closes normally when you close FS, which you did. Pete