Pete Dowson

This seems to be pretty much identical to another thread with a different title! Please note that this is the Support Forum for FSUIPC, WideFS and my other programs, yes, including MakeRunways. But it is not the support forum for Aerosoft scenery! So, sorry, seems there are two threads posted in the wrong place? Pete

If it isn't in the P3D selection menu, and not in the MakeRunways lists, then it is not defined correctly in the Scenery. So you need to go to the support forum for that product, right? Not sure why you'd report it here? Pete

Are you using FSUIPC's application interface with something you've programmed and which is now being marketed? If so please email me (petedowson@btconnect.com) and we will discuss it. I shall need some details. If you mean the use of FSUIPC as any user might use it, with a normal paid-up licence from SimMarket, there is no other requirement. Pete

I don't know of an NMEA program for FSX. The GPSout facility built into FSUIPC does provide NMEA output, to a serial port. Is that what you are thinking of? Pete

There's no "default profile" -- I assume you mean default settings, which of course are outside any Profile. Default settings apply to aspects of an aircraft's assignments which aren't overridden by Profile entries --axes and calibrations are overridden if there are relevant applicable profile settings, KeyPresses and Buttons are only overridden where the same keypresses and buttons are assigned in the profile. This latter allows common switches and operations to e programmed for all aircraft with certain keypresses and buttons specific to Profile aircraft. Pete

Did you look at the log? See: 88281 *** LUA Error: ...X\steamapps\common\FSX\Modules\linda/system/init.lua:29: module 'linda/libs/._lib-fallback' not found: no field package.preload['linda/libs/._lib-fallback']linda/libs/._lib-fallback no file 'C:\FSX\steamapps\common\FSX\modules\linda/libs/\_lib-fallback.lua' no file 'C:\FSX\steamapps\common\FSX\modules\linda/libs/\_lib-fallback\init.lua' no file 'C:\FSX\steamapps\common\FSX\modules\lua\linda/libs/\_lib-fallback.lua' no file 'C:\FSX\steamapps\common\FSX\modules\lua\linda/libs/\_lib-fallback\init.lua' no file 'C:\FSX\steamapps\common\FSX\modules\lua\linda/libs/\_lib-fallback.dll' no file 'C:\FSX\steamapps\common\FSX\modules\lua\loadall.dll' no file 'C:\FSX\steamapps\common\FSX\modules\lua\linda/libs/.dll' no file 'C:\FSX\steamapps\common\FSX\modules\lua\loadall.dll' I don't know Linda at all, never used it and cannot support it, but it looks to be like you are missing most of it! Isn't there support for Linda somewhere? Pete

Assignments, you mean? Have you tried simply deleting them? Joystick axis assignments and calibrations made for a Profile replace all those made outside the Profile, so there is no problem there. So I assume you mean button assignments? There again, if you assign them to something else in a Profile, the non-Profile assignment for the same buttons will be ignored. The only buttons and keys which will be active in your profile are those assigned IN your profile, plus those assigned outside the profile but not in it. In other words, there's never any clash or problem with using a profile and leaving old assignments alone. However, if you really must delete default (non-profile) button assignments, you need to: 1. Go to the FSUIPC Options, Buttons & Switches tab, 2. Make sure the 'Profile-specific' tick is clear -- click on the option if not to remove the tick and let the dialogue show non-profile assignments, 3. Press the button you want to un-assign 4. Click on the Clear button below the assignment(s) 5. OK, done. Pete

What's being multithreaded? Serial ports are serial devices. The output to them is serialised. There's no way it can "get mingled up". But in any case, surely you aren't using three separate Lua plug-ins, one for each light? You only need the one, with three events. Events can't interrupt the flow, pendng ones will queue till your processing is done. This sort of thing is actually quicker to try than worry about questioning. Haven't you tried? Pete

It's a bit pointless posting pictures. The INI file tells the correct story. But as you can see, NONE of those axes are processed, not even for Engine 1, so why bother checking the "map 1->234" option? So, how are you assigning your throttle (where, and to what?), because it isn't to any of the Axis throttleN set, ThrottleN or ThrottleN set controls. You haven't even bothered pressing a SET button in order to calibrate either. "Normal defaults" are for all the other options. There's no such thing as "normal defaults" for assignments and calibrations. If you don't want FSUIPC to do any of that it is easiest simply to delete the FSUIPC4.INI file before running FS. Pete

If you know the <name> of the profile, just find and delete the complete sections with the titles [Profile.<name>] [Axes.<name>] [buttons.<name>] [JoystickCalibration.<name>] [Keys.<name>] [Auto.<name>] Or, if you are using Profiles=Files, delete just [Profile.<name>] in the INI and the <name>.ini file in the Profiles subfolder. To merely remove a specific aircraft from a profile, just delete its entry in the [Profile.<name>] section. Pete Pete

Sorry, I don't understand -- you want to delete assignments in FSUIPC? Have you tried? Pete

This is nothing to do with FSUIPC. The module "xuipc.dll" is a regular part of FSX and is not in any way I know related to anything FSUIPC does. I've never even heard of a crash in that module, but you might want to go and search in the AVSIM FSX CTD forum to see if anyone else has experienced this. Pete

That's one trouble with using more realistic simulations -- you need to understand more about what is going on! I get similarly misled myself too sometimes! Pete

Are you using some sort of Migration tool? Please try FSUIPC 4.939g, the current version, as I made some changes to the installer to try ot deal with some of the messes they seem to make. Pete

You can try using logging, there are lots of options -- see the Logging tab in FSUIPC's options. There's no need to mess in FSUIPC INI. But you need to know what you are looking for. I'm afraid I don't know SPAD and cannot support it myself. Isn't there a support place for it, or any documentation? Pete

The name of the Server, DON-PC is supplied by WideServer (inside FSUIPC) by a broadcast message. Then WideClient gets the IP address belonging to that name from Windows. So it is Windows, or more likely your DHCP server (likely your router) which is giving that incorrect IP address. There is a thread in the FAQ subforum about this sort of problem (look for the title "WideFS Server names translating into incorrect IP addresses". As one of suggestions thee says, try setting the correct address as the "ServerIPaddr" parameter in the Wideclient.INI file. Please also refer to the WideFS User Guide. There's a section in that which explains configuring your network and the options available. Pete

That's a bad migration tool! It should at least clean up its mess when it has finished. It makes the Registry point to your P3D installation for FSX, and also seems to put an FSX.EXE there (or renamed Prepar3D.exe), which makes the confusion even worse! The end result is: There is really no way a decent installer can untangle the sort of mess this is in! Your so-called "migration tool" should only do its fiddle temporarily, whilst you are using stupid installers which can't work things out correctly. Then the "migration tool" should put things back correctly so that normal well-written installers can find the right things in the right place! Okay. I think you should only "activate" the tool when installing things which don't understand what they are doing, then deactivate it afterwards for normal use. Pete

And what was your previous install version? I need to see the Install log to determine why that occurs. What version of FSX do you have installed? Sorry, what are you trying to install, then? I'm now confused. Do you ONLY have P3D, no FSX? Because the error you mention says that your registry points to an FSX installation. So, what is the problem? Please explain! don't you believe it? Oh, no! Not one of those horrible migration programs which renames the progeam so that FSUIPC and other programs can't even tell what is going on? When you say "it doesn't work" can you expand on that. What "doesn't work" about it? If FSUIPC running? Just paste contents of text files into your messages. Use the <> button above the edit area to enclose them. And the main file, for installation problems, is the install FSUIPC log file. I also suspect FDC can't work with a renamed P3D installation. You need to undo whatever your horrible migration tool is doing to mess everything up! Pete

It's ready earlier than I originally planned, version 4.939g will be released today (Sunday 22nd March). Pete

The conditional part of the entry is the same no matter what the "action" in the tail end is. Why do you think it doesn't support it? There's no difference in any part before the "C" or "K" indicating "Control" or "Keypress".. I see one problem in your assignments, though. Look, when I pair things up for the same button it shjould be glaringly obvious what's wrong: 9=P66,4,CM1:10,0 15=CP(+2,0)66,4,CM1:4,0 11=P66,8,CM1:8,0 17=CP(+2,0)66,8,CM1:13,0 12=P66,10,CM1:7,0 16=CP(+2,0)66,10,CM1:3,0 What do you think happens when you press buttons 66,4 or 66,8 or 66,10, no matter whether you "shift" (2,0) is pressed or not? The first of each pair is set to ALWAYS operate. If the shift is pressed too, the so with the other of the pair. If that is not what you want you should have the condition "shift button not pressed" on the currenty unconditional one of each pair, i.e. 9=CP(-2,0)66,4,CM1:10,0 15=CP(+2,0)66,4,CM1:4,0 11=CP(-2,0)66,8,CM1:8,0 17=CP(+2,0)66,8,CM1:13,0 12=CP(-2,0)66,10,CM1:7,0 16=CP(+2,0)66,10,CM1:3,0 Pete

But those offsets, 3370-3373 are just diagnostic values provided by my PFCFSX.DLL driver, which is only useful with the appropriate PFC manufactured hardware -- the 737 cockpit, in fact, the only serial port device they made with a motorised trim. As for your SIOC declarations and so forth, I'm afraid they are lost on me. I do not use and never have used SIOC and i don't know anything about it. Sorry, Pete

If you'd like to wait for the next FSUIPC4 release, possibly next week, then I'll have added an offset for the current Profile name (if any). It will be 0x9540 and will be limited to 63 characters plus zero terminator. If the current aircraft is not assigned to a Profile, or Profiles are not being used, then this will be a null string (i.e. just starting with the zero terminator). Pete

I think the only problem with some of the PMDG axes is if you assign "direct to FSUIPC calibration", because that bypasses the part of the aircraft code which wants to read the values. If you assign to the regular FS controls (axis throttleN set for each engine N) then the PMDG add-on cannot tell the difference between FSUIPC assignment and FSX assignment. They may also not like some axes being calibrated in FSUIPC, because this results in a lower level feed into FS of the post-calibration value. this may differ from the value the aircraft code picked up earlier. so causing conflict and/or weird behaviour. Pete

Sorry, I really do know absolutely nothing about instant replay. I used to use FSRecorder on occasion, but these days the facilities actually built into the nVidia "Geforce Experience" package for snapshots, frame rate measurement and video recording, far exceed anything I've ever used built specifically for (or into) FS. Pete

Hmm. Sounds like clarification is badly needed here! Never have controllers enabled at all in FS if you intend assigning axes in FSUIPC, otherwise it is always a major source of conflicts! Just trying to de-assign them in FS is no good. FS will often reassign them automatically. The only safe way is to disable the controllers in FS altogether, -- and even check now and then that they stay that way (which they should, ... but!). However, if you aren't using FSUIPC to assign controllers differently according to aircraft type or profile there's not necessarily all that much advantage in assigning in FSUIPC in the first place. I'm not sure why so many do so "as a rule" rather than out of some purpose, like automatic selection of correct control configuration. It doesn't matter whether you assign in FS or in FSUIPC, you can still calibrate in FSUIPC if you want to -- and that was the original function of those user facilities in FSUIPC, not for axis assignment! Pete