Pete Dowson

FSUIPC's settings are all contained in its INI fle, in the same folder as FSUIPC. Deleting that before running the Sim will make them all vanish and revert to default. Pete

What logging are you enabling in Wideclient.INI? Best to leave it defaulted please. If we need special logging we'll say so. More importantly, WideClient is only one end of the connection. You should show the WideServer.LOG from the server end too (in the same folder as FSUIPC). maybe the FSUIPC log too -- all of course relating to the same period. Pete

FSUIPC rescans devices if you go into the FSUIPC options. It also receives notifications from Windows if you unplug the device and plug it back in again. By either of these methods there's never a need to restart P3D. have you tried either? The only cause of such behaviour I know of is the action of Windows USB power management. Go into the Windows Device Manager, find the USB section, and go through all the devices (especially those described as hubs) and in the right-click Properties make sure power management is turned off if that option is available. Pete

That's a relief, but we'd still like to know what you find, please! Pete

It isn't really strange. Why would you think that? There are always default parameters created in the INI -- see the [General] section for a really large example. There will alsways be default sections as well. There is no problem with this. Pete

I don't see anything wrong with the syntax, though it is easy to miss something (one reason I don't like XML -- it's too fussy, unlike INI or CFG files in plain parameter= format). So are none of those add-ins being loaded? I see that apart from FSUIPC there are still the Captain Sim sound and Carenavigraph ones enabled. One test you can easily do: rename that DLL.XML so it can't be loaded, and re-run the FSUIPC Installer. It will make a clean new DLL.XML with only it included. Pete

There's smething wrong with it then. Perhaps you could paste it here so we can check? Pete

To clarify what Thomas has explained, Profile setttings only override any non-profile settings is and when you make profile settings. The idea is that you can have, say, different or additional button or keypress assignments for profiled aircraft whilst many more general button or key assignments which you don't override will still apply. The only exception is if you make any profile axis assignments. then none of the general ones will apply to such aircraft. this is done because otherwise they could cause conflicts. Axes are active all the time, whilst buttons and keypresses only actually operate when you use them. I think those parameters are defaults (the two in the [Axes] section certainly are). It looks like you have no general axis assignments or calibrations in any case, so those parameters aren't doing anything. If you make axis assignments and calibrations for the CRJ then they will be overrideen, for the reason just explained. (That isn't the case for buttons and keys. also just explained). Pete

Do you mean the "modules map" showing what DLLs are running in P3D? It sounds like there's a problem occurring after FSUIPC has started. Please check the Modules folder for the FSUIPC5.INI and FSUIPC5.LOG files. If they are there, then FSUIPC has started but can't get as far as adding its menu entry. Please show us the log itself (you can paste its contents into your message -- it is easier for us and you than uploading a file). If there are no such files being made then FSUIPC cannot access the Modules folder, and we would be back to the permossions not being set correctly still, as John said earlier. This would mean that you didn't quite get the process correct. It might be that as well as what John says you need to also add EveryOne and full access in the Security tab of the folder properties. One way of checking whether it is a permissions problem is to run P3D by right-clicking and selecting "run as administrator". If FSUIPC is not even being loaded (by SimConnect) then we'd need a SimConnect log. There's a thread in the FAQ subforum which explains how to get one of those. Pete

I MOVED YOUR SUPPORT REQUEST OUT OF THE FAQ REFERENCE SUBFORUM, WHERE YOU ARE LUCKY IT WAS SEEN. PLEASE ALWAYS POST SUPPORT REQUESTS TO THIS, THE SUPPORT FORUM!! The problem is that the previous good run of FSX-SE did n ot terminate properly -- crashed or hung for some reason. FSUIPC tends to be the last thread still running when FSX is forcibly closed, so it is blamed, incorrectly. This is then marked in the Registry. Please refer to the FAQ subforum (where you incorrectly posted), look for the threads about difficulties like this, where detailed help is provided. This thread in particular: FSX automatically mistrusts modules (FSUIPC not loaded) - solution

Well, if you'd have looked in the log, which is where errors would be listed, you would have surely immediatelt seen: 37797 *** LUA Error: F:\P3D\Modules\multiaxis.lua:7: unexpected symbol near '/' Look at the Lua file: function applyaxis(val) cntrl = ipc.readUD(0x66c0) ipc.control(cntrl,val) end event.param("applyaxis") [/CODE] Line 7 is the [/CODE] line. That is NOT a Lua statement. It is evidently the end of a "code" section which you get when using the <> bracketing method (see editing options above). For example, to do this function applyaxis(val) cntrl = ipc.readUD(0x66c0) ipc.control(cntrl,val) end event.param("applyaxis") [/CODE] Please do always look at Log files yourself, and ALWAYS check anything you extract from messages. Don't take things blindly. Pete

I found this question placed in the User Contributions subforum where it could easily have been ignored. The subforums are generally repositiories of reference information, not for support (except for Paul Henty's .NET DLL support forum). I've move it to this, the Support Forum itself, so it can be answered. Yes, you are correct in that you'd need to write a program which interfaced to your equipment via the serial port, and to FSUIPC using FSUIPC's defined interface (in its SDK). There is no native serial port data access in FSUIPC or FSX. But you don't need to run such a program before the simulator -- best to have it starting at the same time, or when FSX is actually ready. FSUIPC includes facilities to run programs when FSX is ready. It would be possible, also, to write such a program as a Lua plug-in for FSUIPC. The Lua facilities provided by FSUIPC are documented in the FSUIPC Documents sub-folder, but for more help with the Lua language and libraries you'd need to refer to the Lua website. Pete

You don't need to, and cannot in any case. The Email + Name + Key are irrevocably tied together. The email isn't used for email at all, it is only part of the identification used to create the key. Pete

I think that, maybe, because if they used the regular controls for those actions the affect in the default Sim code could affect their aircraft too, they instead "invented" the use of an otherwise unused control (no 4th Engine, right?) to operate those facilities. If that is the case then I would assume that the parameter would differentiate between the actions. Well, the best would be to get your driver to react to the Throttle4 setting being made. he value should appear in the Engine 4 N1% offset. Otherwise you could have a Lua program to trap those Throttle4 controls (event.control) and write whatever offset you wnted. BUT if your driver needs the original A/P function offsets to be set then be aware that this might mess up the aircraft's operation -- there's presumably a good reason for them to have avoided changing them. Pete

Sorry, yes it is still the case that there's no 'protected' own display. There is really no way with the single line display to prevent it being overwritten by others. However, much less use is made of the multi-line display facility (which is a different window facility in SimConnect). This is used if you include more than one line (or just a "\n" (new line) code maybe followed by a space). The only other way would be to keep re-displaying your text, regularly (e.g by a function called by an event.timer function). Pete

Just to clarify, are these buttons on the "3D cockpit" clicked with a mouse on screen? Or on your custom made hardware A/P panel? If the latter, then I can't help with this information because I've no idea how you've programmed those buttons. If you mean buttons on the screen cockpit, then I think there must be a fault in that add-on aircraft code. You go on to say: You talk about "offsets", but how are you using such? Are you monitorin the offsets documented for the data you want? Are you only concerned about lighting an LED, or about the function being performed and indicated by the LED? Or perhaps you are mixing up "offsets" (which are locations in memory, listed on the provided offsets document), and "controls" or "events". The log parts you show are Events or controls, nothing to do with Offsets. So your Mobiflight (which, I'm sorry, I know nothing about) is some sort of hardware driver which you configure by specifying offset values? There are defined offsets dealing with the default built-in autopilot, including APR, BC, SPD (as you say, 0800 for APR). So i'm assuming that the add-on aircraft you are concerned with has it's own autopilot programming and doesn't use these built-in FS facilities. If that is correct then you are dependent upon whatever information is available from the aircraft makers. They are most unlikely to be mapped into FSUIPC offsets. If you can operate those modes by buttons on your hardware then you may only be able to set or clear the LED indications depending on whether you set or clear the mode. Pete

That looks okay. None of that would explain this: That's do do with how the flight you are loading was saved. Save when the throttles are at idle. And Thomas is correct. The levers have no effect at all until you move them, so move them off idle and back again. Your "Delta" (the smallest change which is used) is set to 512 (see the [Axes] section). Change all those to 256, which I think is normally the default. Sounds like there's something else wrong then. Have you checked that everything works okay with other aircraft? You need to determine if this is just that add-on or a more general problem. All the axis velues which can be sent are -16384 to +16383, and those are what are sent for the entire range of axis movement after proper calibration. So at the lowest position is will be sending -16384 or close (= zero thrust). What values does your add-on aircraft need for this "shut off setting?" (Use FSUIPC Axis logging and see what gets logged when uoiu use the mouse or keyboard to operated the throttle to "cutoff"). On the Turboprop quadrant from PFC there's a "centre" idle zone, with a notch. Below that is the reversing zone. I don't know the CRJ. What exactly is the "shuoff" position? Nor a reverse, evidently, with that name. If it is a fuel shut-off, what are those two red-knobbed levers below, in the normal jet fule idle/cutoff switch position? Pete

Well you'd need to delete the Profiles folder as well as the INI file, but, yes, FSUIPC would revert to standard default option settings and you could start again. But if you already have a lot invested in some of your profiles, the only with more generic application, then following my advice in my earlier reply is very safe. Pete

Do you want to delete the profile altogether, or just dis-associate it from a specific aircraft? If the latter then just remove the line with the aircraft name in it listed in the [Profile.XXX] section of the main INI file where XXX is the profile name. If you really want to remove all trace of it you'd need to remove the entire [Profile.xxx] section. The related file in the Profiles folder will then be completely ignored and can be deleted if you've definitely no further use for it. Pete

As Thomas says, it's EITHER PFC.DLL (32-bit) OR PFCcom64.DLL (64-bit) for a serial port PFC device, depending on which Flight Sim and FSUIPC you are using. However, if this is a new PFC yoke then surely it is a normal USB devce, looking like a Joystick to Windows? The older PFC products were serial port based and using one of those two drivers I produced, but I thought all of their recent stuff was more universal? The PFCHid.DLL and PFChid64.DLL drivers were made for non-joystick type PFC USB products which adhere to the Windows "Human Interface Device" standards (hence 'HID'), such as the Cirrus consoles. Pete

Yes. Look through the assignment drop-down for button release. Pete

There's no default aircraft exists which knows the difference. If this is an add-on which has such a setting you need to find what value the engine parameter needs to be in order to set it. The "controls" to which you referred merely set engine thrust values. The "cut" one effectively sets a 0 engine thrust value. If you know the exact value you need you can send it for most aircraft using "throttle1_set" (or 2, 3 or 4 for the other engines) with that value as the parameter. Pete

You should have attached or pasted your settings file (the FSUIPC INI), as we could probaly help more positively seeing what you have. Very relevant information includes whether this is the same for all aircraft, whether you are using Profiles, and, probably most significantly, whether you're using Joy Letters (letters assigned instead of numbers). Oh, and have you updated Windows or unplugged devices, as both can change IDs assigned. This is what "Joy Letters" is meant to get around. Pete

What are you assigning it to? The nornal parking brake control is a toggle action, meaning it turns it off if it was on, or on if it was off. You need to start with it synchronised to your switch state. There's no way to "reverse" it. When you say: what exactly do you mean by "both" dropdowns? A parameter of 0 is default in any case, and it wouldn't be used for such a toggle operation. The standard control is the same one used for the default keyboard shortcut (Ctrl + .). Does that work okay for you? Pete

It's very inefficient having a Lua plug-in loaded, compiled and executed repeatedly -- especially so often. As John says, you can design you Lua plug in to operate at regular time intervals easily by using event.timer. You only have the plug-in loaded and compiled for you just the once that way -- loaded probably by an [Auto] section command. Are these Q400 values obtained from L:Vars? If so then just use the event.Lvar function instead, one for each of the LVars you need to monitor. The minimum monitor time there is currently set to 100 mSecs, not 50, but with two of them operating you might meet your 50 mSecs target. Pete