Pete Dowson

The installer detects FSX-SE bcause your registry says it is installed, though it points to the same folder as FSX. See here: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Games\Flight Simulator - Steam Edition\10.0 Parameter"SetupPath" ... >>> OK! FOUND FSX-SE! <<< ... SetupPath=C:\Program Files (x86)\Microsoft Games\Flight Simulator X\ This cannot get into your registry without something putting it there, so evidently someone's been at your PC without you knowing? The registry is exactly as it would be without FSX but with FSX-SE only. For the next version of the FSUIPC4 Installer I will try to deal also with this crazy case. There seems to be many ways in which folks can get their Registry in a mess! :sad: If you cannot wait for a revised installer, the only solution for you with the current installer is to use Regedit to delete the complete key (and subkeys) at: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Games\Flight Simulator - Steam Edition As far as I am aware that cannot be created by anything other than using the Steam FSX-SE installer. Either way, so I can make the right changes, can please you tell me exactly what the FSUIPC Installer does -- the text file ends abruptly! There would have been a message or something, and maybe an option to do something, but the text file is still incomplete. I need to know why. What you saw, and what you did! PLEASE! Pete

Please write to me by email explaining your product and its use of FSUIPC. petedowson@btconnect.com Pete

Please do NOT post pictures of text files, but paste the entire text file instead. I need to see the entire file -- the part you captured is incomplete and shows no failure at all. Why do you think it fails? And please also explain the history which led to there being two pointers to FS, one for FSX and one for FSX-SE -- that's not possible if you never had FSX-SE at all. You can save the file using "Save" in the File menu, assuming you cannot find the FSX Modules folder where it will have been installed. Pete

You only had to search the offset listing installed in your FSUIPC Documents folder for "altimeter", to find offset 3324. This is not true altitude, but the reading on the instrument. It might be feet or metres depending on the user setting. It's a 32-bit integer. Pete

Hmm. Not sure what Linda is doing to cause a crash. I assume there's a support forum for Linda? Pete

I can only suggest you try it. The way FSUIPC applies these things tends to work with the original reasons for sudden extreme wind shifts -- errors in the interpolation between the three WX stations involved in the current triangular area, but that was with FS9. With FSX and the advent of direct and global weather control most weather programs seemed to be able to operate smoothing more subtly, within their own settings. I have not heard of any real problems with FSX winds for a long time. I have REX for cloud and wave textures,, OpusFSX for cameras, but ASN for weather and real and accurate weather radar. I pick the best bits from each program! ;-) Pete

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