Pete Dowson

Wow! That has just got to be the largest INI file with the most duplication I've ever seen!!! I did offer to help tidy it, but it might take me a while. Better give me your email address and I'll send you the result, but I cannot promise when I'll finish it! Because you have "UseProfiles=No" set. The default for that has been "Yes" for several years now, but you were using Aircraft Specific before this, so it stuck. Also, and the worse thing, is that you have: ShortAircraftNameOk=No whereas the default became ShortAircraftNameOk=substring a much longer time ago, and even when you first started the recommendation was to set this, then shorten the names in the INI so, for instance, "737" matched all 737's. As it is you have complete sections for every single aircraft even if its only a lick of paint different. You should always back up your INI file in any case. With all that work involved you wouldn't want to lose it, surely! Have a go, by all means. But the direct conversion which FSUIPC can do for you won't be any shorter because it cannot tell which aircraft to collect together to make sensible profiles. I'll try to do something for you. Pete

Well of course those offsets are the actual Axis input values, after calibration, NOT the brake pressures at all! You need to have assigned brake axes to get them set. You can write to offsets 3BB4 and 3BBC, and assign and calibrate these to the left and right toe brake axes. These are used by my PFC driver for that purpose. It wouldn't matter if there were methods to do this (and there are) because you say ProSim reads offsets 3416 and 3418, which are NOT brake pressures but axis input values, as documented. Those axes may even be disconnected (using another offset) but they'd still reflect the axis input. That's the whole point of those offsets. If ProSim wanted brake pressure it would read different offsets. Pete

Ah, aircraft specific is the ancient facility which was effectively replaced by Profiles years ago. You must have set your system up with those a long time ago. Aircraft specific settings are still valid, and everything I said still applies except it's a little more complicated deleting them in the INI file -- but as I explained, you don't have to. I assume you don't have every single aircraft, in every possible livery, all individually "specific"? I hope you took advantage of the facility to make them more generic, by using only part of the name so that one entry applied to all? eg 737 for all 737's, etc? If you change the profiles option to Yes then FSUIPC will automatically convert your Specific settings to Profiles, but all it can do really is make a separate profile for every different specific setting so it would still really need tidying up. If you'd like to paste in your FSUIPC4.INI file here, in a message (enclose it using the <> button above the Edit area), I'll try to sort it out for you. Meanwhile it might be a good idea if you perused the current edition of the FSUIPC User Guide. Maybe there's a lot more you've been missing? ;-) Pete

No. Battery life isn't relevant in flight in any case -- you have generators. You aren't flying an electric aircraft, are you? And if there was no electric power you'd have no instrumentation anyway. Why would the COM radios survive? FSUIPC doesn't operate radios itself. It has offsets which can be used by application to directly set and read the frequencies, of course, and it can pass on radio commands just like when they are assigned in FS directly. But it has no manipulations of anything itself. Ask Sim-Avionics support more about what they do. They surely must be able to help if their software is managing the radios. However, most such packages leave radios to the normal FS facilities, as in general there is nothing wrong with them and no reason for even sophisticated cockpit software to interfere -- unless they want to simulate faults of course. I use Project Magenta and also Prosim737 and in both cases the radios are normal FS radios, interfaced to my hardware through FSUIPC using normal FS controls. They'd be the same without either package. Pete

Once you've assigned an aircraft to a Profile you can only unassign it by deleting it from the Profile's list of aircraft -- in the [Profile.<name of profile>] section of the FSUIPC4.INI file. However, it is not necessary (which is why there's no option for it) -- just load an aircraft which has not been assigned to a Profile and assign there. That assignment will then apply to all other unassigned aircraft. However, for each different existing profiles you will still need to repeat the assignment. But only once per profile, of which it is unlikely you have many. Just load once aircraft of each profile. Pete

Well obviously something has changed. Are you sure FSX hasn't re-enabled its controller assignments and it interacting with your FSUIPC assignments? That's the most usual cause. It tends to do this sometimes when it thinks the controller is newly attached. Otherwise I can only think you have a bad connection or a faulty yoke, which gives occasional disconnections -- that would result is such a bad reading and no doubt it would be intermittent. Have you tried just watching the values in the assignments or calibration tabs, or in Windows own calibration applet (game controllers or whatever)? You can use FSUIPC's axis event logging, in the logging tab, to see what is going on. If you (temporarily) run FS in Windowed mode you can enable also the Console Log, and see the changes in real time on screen. Pete

Well you had the most recent supported release. It's just that odd things need updates between main releases, and the offsets in error reports then no longer tally. I look forward to seeing the error data with 4.937d. Yes, thank you. It is only to see what might be interacting with FSUIPC, assuming the error data you will be supplying makes little sense to me. Of the DLLs being loaded, I assume the new one, pertaining to the ORBX scenery you just installed, is this one: <Launch.Addon> <Name>ObjectFlow.dll</Name> <Disabled>False</Disabled> <ManualLoad>False</ManualLoad> <Path>C:\FSX\ORBX\FTX_AU\FTXAA_ORBXLIBS\Scenery\ObjectFlow.dll</Path> </Launch.Addon> Maybe, just to verify that this might be the source of coflict, after getting a CTD with 4.937D, you could see if it goes away when changing this line: <Disabled>False</Disabled> to be "True" instead of "False"? Thanks, Pete Regards Pete

Pan View is assigned in Axis assignments, not in Buttons and Switches. The latter facility would be used where you wanted different specific views for each different side of the hat. Panning is an analogue action, like other axes. Just assign to Pan View as an axis then it's the same as in FS. Pete

That info would be very useful if it occurred with my very latest update. Could you, please, download FSUIPC4937d and try again, so I have accurate data which will likely pinpoint the location for me and therefore the data in error? Could you also list the other DLL's being loaded -- i.e. those enabled in your DLL.XML file? Thanks, Pete

All of the top left set buttons on all of the calibration pages do the same thing, It's just exactly the same code. if it worked for you with the rudder it simply must do the same for all of the others. It's just a standard Windows dialogue, and the button is processed by Windows which sends the event to the same code in every case. Please go through all of the pages, all 4 positions on each, pressing SET then RESET for each which has one, and tell me exactly what you see each time -- which ones operate and which don't. Maybe, if there's a pattern, we can work out what's wrong. At present I cannot think of anything which can do this. It's a first for unchanged code lasting these last 14 years or so! Pete

Tell me how you have assigned the brake axes: what type of assignment (direct to FSUIPC, or to FS?), and which actual drop-down selection did you use? The "Axis not processed" message is ONLY displayed until you press the Set button. The calibration can always be set, because it processes FS controls, NOT the axes, so it doesn't even matter if it isn't assigned. Pete

It just means that whatever corruption is causing the crash or hang is affecting something with less of an outcome due to timing. Problems caused by minor timing differences are notoriously difficult to track down. To fix it at all you need a consistent result, which sounds like the G3D crash you get 'normally'. Sorry, no. It could be any one or more of the assorted graphics items loaded and processed whilst you were using FS. It'll be a process of elimination. A friend of mine recently had a similar problem which eventually turned out to be due to one corrupted bitmap file in just one livery of one of the many AI planes being used by his add-on traffic package. Once it was identified a simple reinstall of that one aircraft livery fixed it. Sometimes re-installation is quicker, but if you aren't getting crashes whilst using FS, only when you've finished, you might not think it worth the hassle. Pete

In fact there are very many more controls assignable in FSUIPC than there are in FS's dialogues. You are simply not looking hard enough if you are not finding ones you expect. Didn't you find "Toggle beacon lights"? Just search for the word "beacon" and there it is! The control names listed by FSUIPC are those used in FS's own assignment tables, in its files. The FS dialogues for assignments are descriptions, not names, and are different in each language. FSUIPC gets the list from FS itself (in CONTROLS.DLL), which ensures that it contains every single one, and then also adds to it. If you want to search, use the List of Controls document supplied in your FSUIPC Documents folder. Another way to find the names is to enable Event logging in FSUIPC's Logging tab, and then using the control (by mouse or keyboard) and seeing what is logged. If you temporarily run FS in Windowed mode and enable the Console Log, you can see what happens there in real time. Pete

How do you accomplish startup with just keyboard and mouse? Do the same thing after enabling Event logging in FSUIPC. If you temporarily run FS in Windowed mode and enable the Console Log, you can see what happens there in real time. If the model is using regular FS controls they will be logged. Mouse macros only work on gauges which are written strictly to the C/C++ gauge SDK -- they rely on specific structures being in place. Many gauges do not do this, even including many default FS gauges. Check into local panel variables (L:Vars). You can log these. There's an assignable FSUIPC control to List them into the log, as a static list with current values, or you can run a supplied Lua plug-in which logs them as they change, both to screen and log. Please see the Lua plug-ins package in your FSUIPC Documents subfolder, in the Modules folder. Pete

Okay. In that case I think you have a corrupted file -- whether an aircraft or scenery file I couldn't say. I expect when you solve that it will also fix the hang. Corrupted graphics files can result in other corruption in memory and give other results which depend on memory usage and layout at the time.. There's probably no conflict at all between your add-ons, just the basic fault you need to find and fix. Pete

It's a helicopter? I didn't know. Isn't this still to do with the mixture control (as a "conditon" control)? For instance on the King Air you have a full cut-off, a maximum for full rich, and an idle zone. The FSUIPC3 User Guide talks about this on page 49 under calibration "Notes & Exceptions" == the 4th bullet point. It isn't an area I know much about I'm afraid, only that provision was made for it -- assuming of course that the add-on uses standard FS controls. If not, then whether it can be solved with Lua programming or mouse macros or simple keypress assignments, or even some other way, would need more knowledge about the specific add-on's implementation. Regards Pete

As I just showed you! No, as I certainly stated it goes into a section called [Programs]. Please see FSUIPC docs for more info, if needed (which you don't really as I gave you the answer already).. So why did you say it was ASN? Now it might be the 777? I doubt it, really, as all these add-ons are very frequently used by many folks. Maybe your FSX installation is corrupted someplace? In your earlier message you said it hangs on exit AND a G3D error. How can it be both? Either it hangs or it crashes, it can't do both. If it's a crash in G3D it is likely to be down to corrupted textures or medel files, related to scenery and aircraft visuals. There's nothing in FSUIPC which interacts in any way with G3D. Pete

Hmm. I'm using ASN with no such problems. How are you loading it? I just checked, and I use FSUIPC to start ASN, and also KILL it forcibly when FS is closed. Here is the line in my [Programs] section: RunIF1=KILL,"C:\Program Files (x86)\HiFi\ASNext_FSX\ASNext.exe" This works fine for me. Regards Pete

Where did you find FSUIPC.dll version 4.93? Two errors there. FSUIPC.DLL never got to version 4.93 -- that module is for FS9 and before and the latest is 3.999z8 or 3.999z9. If you really meant FSUIPC4.DLL, then you should not download anything other than the complete ZIP with the Installer, and the currently supported version for FSX and P3D is 4.937. You can't extract files from a DLL, so your first part must have been wrong. And it shjould be 4.937, not 4.93. The error you are getting means your installation of FSX in wrong -- the Registry is not correctly pointing to the location of FSX, which is why FSUIPC's installer cannot find it. I don't know how you got that messed up -- did you move FSX without uninstalling and reinstalling? Anyway, why not simply do as it says -- find the FSX.EXE for it so it knows where it is. It couldn't be much simpler. If you do that it will also correct your Registry for you. The idiot's guide is in the ZIP. It looks like you ignored it. It is the Installation and Registration document whjich tells you everything you need. The rest is simply folowing instructions on screen. It is pretty much all automated for you! Pete

See the bit above which says: VID_06A3 or VID_0738, if you know the specific PID number or your device then you only need to delete the string that matches the VID and PID. If you want to know the VID and PID of a USB device, try running my free HidScanner program, downloadable in one of the subforums here. Pete

It isn't FSUIPC information you need, but plain and simple MS Flight Sim help. If you learned to fly in FS, before worrying about adding controls, you would find that FS's jet fuel idle / cutoff is controlled simply by the mixture controls -- mixture rich being idle and mixture lean being cutoff. When you think about it it makes complete sense. I've never heard of a "fly" setting. Sorry. Pete

You haven't supplied the WideServer log file, just two copies of the client log! However, the lack of any connection is obviously because your PCs are in different workgroups and you haven't bothered to tell the Client the name and protocol of the Server. Please read the part of the WideFS user guide which advises you to read it in RED letters. It is easy enough to fix, just check the documentation. I cannot see how any of my software is involved in Multiplayer as it knows nothing about it. Maybe it is the AIBridge program which injects this data into FSUIPC's tables for other programs to read, in which case your problem does resolve down to lack of attention to configuring WideFS. Pete

The current and supported version is 4.937. I cannot support old versions. You need to update. FSUIPC doesn't know anything about multiplayer traffic, only about AI. And there are separate tables in FSUIPC for ground AI and airborne AI. I've no idea what the programs you are using are doing. Sorry, are you reporting a problem with WideFS or with multiplayer traffic? I am now confused. If WideFS won't connect it may be a firewall problem or simply ports already in use. I can't help without information -- WideServer log from the FS PC and WideClient log from the client. close both ends down first. Paste the log contents into a message here. Have you tried FSC support? If WideFS isn't connecting I assume FSC isn't using WideFS? Pete

Well, you might be able to do what you want, but I don't know. I don't have the 777, sorry. You'd need to research with other users and with whatever PMDG provides. I can help you do what you want to do once you have the information about how the lights are controlled. I don't know where you got the impression that FSUIPC supported facilities in every possible add-on to FS. It is primarily an interface into FS for external programs to get information and control those things FS does, not other add-ons, and secondarily a way of assigning and calibrating switches and joysticks and other controls more flexibly than can be done with FS alone. The program can be installed and the documentation read before purchase, so that is the best way to understand what it can do. Pete

I doubt very much that the PMDG 777 provides any way for a program designed to work with FSX's own controls can operate it's independently programmed systems. For the PMDG 737NGX they published an SDK which allowed me to map data to FSUIPC offsets for display. They implemented their own controls, outside of the normal FS range, to control all sorts of things, including lights -- FSUIPC supports these as "custom controls", but for these you need to work out the control number to use from the information in the NGX SDK. So, does the PMDG 777 also come with an SDK and equivalent information? I don't know, I'm afraid. Maybe there will be someone who can help in PMDG's own relevant forum? Pete