Pete Dowson

How many video screens do you have on your Client? Haven't you noticed that the Windows in your showtext.lua start at horizontal coordinate 1280? On my client that's on a separate screen to the right of the main Windows one. The Lua plug-ins I provide are just examples. Examples are to be learned from, not copied and used without thought. The Window is created where you tell it be. If that is off screen, you won't see it! The second Lua example you include above doesn't use the Window facility. Display operates differently. You do really need to refer to the Lua documents provided, especially the description of the functions FSUIPC provides, which are all fully documented in the Lua Library document. Pete

Oh yes. Sorry. I missed that. There was nothing for you to "get your head around" originally. You have just made it seem complicated. When you set "AutoAssignLetters=Yes" that was ALL you needed to do. I did say in my first reply to that that you could leave it at that, it would work fine. Anyway, now, either just delete the duplicate lines you've inexplicably added, or replace it all with what I give above plus, yes, that 2.GUID line. The only time you really ever needed to edit this section would be if you wanted more sensible letters assigned than A, B, C. For instance P for pedals, Y for yoke and T for Throttle. That would be without "Auto" assigning letters. The autoassignletters method means you just change one "No" to a "Yes" and have done with it. This whole subject takes only one page in the user guide and has always been adequate. What was there not to understand there? Pete

All of your assignments will still be there, just with the wrong joystick Id number. You could either try to locate each in the INI and change the ID used, or, probably easier, use the JoyID utility to change the IDS. Either way, once they are correct, change to using Joy Letters, so FSUIPC can track devices when you disconnect and reconnect them. Pete

Ok. Thank you for the explanation. Let's hope L-M get it fixed in the next update. Pete

It doesn't read the flight pln, it merely has SimConnect notify it when a flight plan is loaded, along with the filename, so it can be placed in the relevant offset for applications to know. Okay, thanks for the clarification. It would have helped if the chap who was suffering the problem had been made aware of this. As it was it appears he thought you were saying it was FSUIPC at fault. Pete

Well, yes in two ways: 1. You have two identrical lines for the names of A, B and C. Does no harm, but only one is read. 2. You have no A.GUID, B.GUID or C.GUID lines. The example in the User guide is clear in this. All you needed to do was make a copy all the lines, and replace 0, 1, 2 by A, B, C in the copies, thus getting this: 0=Pro Flight Cessna Rudder Pedals0.GUID={CBD93CA0-D99E-11E5-8002-444553540000}1=Controller (XBOX One For Windows)1.GUID={1706B0B0-8CC1-11E6-8001-444553540000}2=Saitek Pro Flight Yoke A=Pro Flight Cessna Rudder PedalsA.GUID={CBD93CA0-D99E-11E5-8002-444553540000}B=Controller (XBOX One For Windows)B.GUID={1706B0B0-8CC1-11E6-8001-444553540000}C=Saitek Pro Flight Yoke Actually, I see you have no GUID recorded for the Saitek Yoke -- seems that wasn't connected, or not seen last time you ran FS? Pete

Well, if this entry is in the SCENERY.CFG file: [Area.647] Title=LICJ Palermo Local=Addon Scenery\LICJ Palermo\Scenery Remote= Active=True Required=False Layer=316 then MakeRunways will certainly have processed it PROVIDED that it is continuous with other layers -- i.e there are layers 1 to 315 with none missing AND sections [Area.001] to [Area.646] with none missing. As far as I knew FS processes in the same way -- until there's a gap in numbering. Then it stops. Perhaps you'd etter post your SCENERY.CFG file so I can check? And was there no mention of Area 646 or 647 in the Runways.txt log file. No mention of Layers up to 316? What was the last layer processed as shown in that file? Pete

The assignment options in FSUIPC are mostly not FSUIPC's, but the ones listed by P3D. It just happens to list all of them, and by their internal names, FS/P3D has never had any controls specifically named for helicopters, but the help provided with the program should have the details. Last time I looked helicopter implementations in FS, if actually implemented as a helicopter (rather than, as some were, as aircraft with extremely low stall speeds), then I seem to remember that the helo's throttle control is operated by the prop pitch axis in the sim, whilst the collective is operated by the throttle axis. So, yes, you use the throttle axis as you seemed to know already. Don't get tied to the names of controls. All of the control axes operate exactly the same, so the Throttle could be named "Throttle/Collective", except it isn't. Pete

Not "replace" so much as "copy and replace". You need the number lines there too -- i.e. 4 lines for each device, two numbered, two lettered. The idea is that FSUIPC matches them up on each new session in case the ID has changed. Pete

The GUIDs should be duplicated with A, B, C as well, but they're not essential when all the devices have different names in any case. What's more important is that the assignments have been correctly automatically lettered in place of the numbers. Pete

You don't need my software. Try using your devices in FS without it first. FSUIPC is not the first "port of call" for any device. FSUIPC only sees the same devices as FS itself. It just offers more once you know that you want more. But it isn't the place to start! Note that entitling your thread "Newb with questions" doesn't do you any favours. If you put a more appropriate title in, related to your actual question, you'd more likely attract additional assistance from others. Pete

Assuming your axes are properly calibrated, to the maximum, then the controls are operating exactly as designed for that aircraft. If you want to tailor an aircraft to your own liking you need to edit its AIRCRAFT.CFG file. If you've not calibrated properly, which seems more likely, do it again. There are step-by-step directions in the User Guide. Pete

Ah, good thought Paul. fuzevt: you can list the L:vars being used as a static list in the Log by assigning a keypress to the "List local panel variables" control in FSUIPC. If you list for each switch position you might see whether one is changing value, and also get the values, which you can use in a Macro File to write the appropriate values. There's also a slightly smarter way to see what the L:Vars are doing. Get the Log lvars.lua plug-in from the Examples ZIP in your FSUIPC Documents folder, assign that to a key, and when it is running it will display on-screen the L:vars as they change. Pete

It scans for AFD BGLs is any folder which is included in your operating Scenery.CFG file. It reads through the Scenery.CFG file and find BGL is all the scenery folder listed there, , and in the order listed (because that's the priority order). So, your problem is that your "FS9\airport" folder isn't listed in the Scenery.CFG file as a scenery to be loaded. And there's no default 'airport' folder either -- you or an installer must have created that! You are going the wrong way about solving such problems. Your problem is that your Scenery.CFG file is wrong. It does not reflect the scenery you want FS to load. Sort that out, don't use bad work-arounds which don't solve the real issues. The log file, the one called "Runways.TXT", tells youthe lines being read from Scenery.CFG, in the correct order, and how they are processed including the AFD BGLs found there. Pete

The HidScanner output shows you have other OpenCockpits equipment, which surely uses a driver. Device at "\\?\hid#vid_0000&pid_0014#9&14722075&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}" Vendor=0000, Product=0014 (Version 0.0) Manufacturer= Opencockpits Product= MCP V3.0 Serial Number= MCP V3.0 Device at "\\?\hid#vid_0000&pid_000b#8&7242372&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}" Vendor=0000, Product=000B (Version 0.0) Manufacturer= Opencockpits Product= USBEFIS V2.0 Serial Number= USBEFIS V2.0 Device at "\\?\hid#vid_0000&pid_0013#9&287497c2&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}" Vendor=0000, Product=0013 (Version 0.0) Manufacturer= Opencockpits Product= USBFMC V1.0 Serial Number= USBFMC V1.0 So I think whatever OpenCockpits stuff you have installed must be mapping the yokes for you. You need to find out how to make it do it for the rudders too. The 4 "USBAXES PLUS" devices listed by FSUIPC in its Log file appear to have the correct Usage Page, but oddly no Usage value, which FSUIPC (and I think P3D and Windows) expects to be 4 for a Joystick. For instance here's the scanner's results for one of them: Device at "\\?\hid#vid_04d8&pid_0000#9&14e5741c&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}" Vendor=04D8, Product=0000 (Version 2.0) Manufacturer= Opencockpits Product= USBAXES-PLUS V2 Serial Number= USBAXES-PLUS V2 Usage Page: 1 The Usage itself is omitted. Compare that with the same section for a Saitek throttle quadrant: Device at "\\?\hid#vid_06a3&pid_0c2d#7&23aeb000&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}" Vendor=06A3, Product=0C2D (Version 2.0) Manufacturer= Saitek Product= Saitek Pro Flight Quadrant Serial Number= Device is a joystick Usage Page: 1 Usage: 4 In this case HidScanner recognises it as a Joystick type device, as you see, and so its axes are assignable in P3D or FSUIPC. I think you need to refer to OpenCockpits documentation or support. It looks pretty obvious to me that their stuff is designed for their software, not as ordinary everyday assignable joystick devices. Pete

Something makes no sense at all their. What is assigning the yokes? It isn't FSUIPC, and Windows doesn't know how to assign yoke axes in P3D, so either they are actually assigned in P3D, ort your are running some software, probably from OpenCockpits, which does it automatically. Without them being assigned somewhere, they can't possibly be used in P3D nor calibrated in FSUIPC. You can assign as many controls to the same function as you like. When more than one controller is assigned to a main aircraft control like elevator, aileron, or rudder, and the assigned "direct to FSUIPC calibration", then FSUIPC gives priority to the one with the largest deviation from centre, or idle. There's only one calibration per one control, because there's only one aileron, one elevator and one rudder mechanism in any aircraft -- dual controls link to the same aircraft control surface. You can't have two independent controls, so you can't calibrate separate ones. Separate ones don't exist! Well in that case, as you haven't assigned them in FSUIPC, they MUST be active and assigned in P3D! I'll look at the HidScanner results separately. Pete

Yes, as shown here, in the log: Now checking DLL.XML ... ... There is a previous DLL.XML, checking for FSUIPC4 section. ... FSUIPC4 section already exists but will be replaced. (with FSUIPC4_Loader entry) ... FSUIPC4 section of DLL.XML written okay It does this ONLY if it sees that the Loader has been placed into the Modules folder. This is the Modules folder it is using and looking in: G:\Games\FSXW7\Modules\ This is what I don't understand. Might you have two installations of FSX, two Modules folders? Well, something unique must be happening on your system, because the Installer is well tested, and virtually unchanged for many releases. It is used by all FSUIPC users, including on 4 varied systems myself. The code in this area simply tests whether the Loader is present in the Modules folder and if so sets up the DLL.XML file to use it. I'd need to know a lot lot more about your system. I could add more logging to actually show the return Windows gives it when it tests for the presence of the loader, but is this worthwhile? Pete

And trim doesn't work? How have you assigned it? Maybe a sight of your FSUIPC4.INI file would be useful. And if you go to the logging tab and enable event logging, the log of you trying to use the trim would be good. Pete

It sounds more and more like a Mindstar problem then. FSUIPC knows nothing about what that code is doing. There's really no way I can help. The only folks who can help with working out what is going on when you use that page are Mindstar as they are the only folks who know their code. If they refuse to help I don't know how it'll ever be fixed. Pete

Well if the FS controls are being sent, as shown, then the problem with the graphic knob is specific to the code in the gauge. The commands would be the same no matter how you assigned them. If your gauge only operates the graphics with a mouse click, then you'd have to use a mouse click -- or just possibly mouse macros may work if the gauge is written in a specific way. Pete

I seem to remember that those are momentary contact. So you need to use Toggle controls. Pete

Ah, that's more useful. Right. The Windows Crash log isn't directly useful to me, except that it shows that the crash is due to a bad pointer. The FSUIPC log is useful though. First, this part which shows that two options which use API.DLL are truly omitted (the RED lines here do this for me): 811 ------ Setting the hooks and direct calls into the simulator ------ 811 --- CONTROLS timer memory location obtained ok 811 --- SIM1 Frictions access gained 811 --- FS Controls Table located ok 811 WARNING: Failed to install Mouse Macro hooks! 811 --- Wind smoothing fix is installed 811 --- SimConnect intercept for texts and menus option is off 811 --- P3D hack inhibits mask = 0009 811 --- Link check value = 1F6FF (should be 1FFFF) There are other things of interest in the FSUIPC log too. Here's one: 61511 **** SimConnect reconnecting now by request ... **** That means that the special control in FSUIPC to reconnect SimConnect was used. Did you do that? Is so, why? If not, then something you have installed is doing it. But the biggest clue here is this, right at the end, assuming this is where the crash occurred: 97298 Advanced Weather Interface Enabled 144504 .pln The times I've seen the crash occur after this logging it has always been due to corrupt Weather files -- either the .WX file being loaded, or the WXstationlist.bin file in the same folder as your P3D CFG file. The reason such corruption only causes crashes when FSUIPC is installed is that it is one of the very few programs which always requests weather data from SimConnect. There have been lots of threads here about this relatively common cause of crashes in both FS and P3D. Here's a link to one of the most recent ones. I strongly suggest you have a read through it. It has suggestions as to how to verify this (by other FSUIPC INI pararmeters) and what you might do about it: http://forum.simflight.com/topic/82188-p3d-v335-crash/#comment-495519 The .WX file which was probably used is the one associated with the default flight. i.e. this one: C:\Users\Fabrizio\AppData\Local\Lockheed Martin\Prepar3D v3\Prepar3D_Default.wx That and the wxstationlist.bin file can both be safely deleted. Pete

Why click "New Log"? All the essential information at the start is thereby lost. And please remove all optional logging in the logging tab -- none of that Event logging is useful at all for this. All I wanted was the straight forward default log from the start of the session to the crash. And you still haven't posted the Windows crash details. The fact that it still crashes with no API.DLL involvement by FSUIPC whatsoever (thought I can't see confirmation of this because of you starting a new log and losing that information) indicates it is definitely a problem between Mindstar and P3D's API.DLL -- probablty one of them having an uninitialised variable or bad pointer. If Mindstar continue to refuse to assist at all I can only suggest you refer it to L-M. But you will need to supply them at least the Windows crash information. That's a basic essential. Pete

Sounds like you haven't installed the correct FSUIPC version. The current supported version, for the latest P3D3.4, is 4.958. Every time you update P3D always look for a new version of FSUIPC. It has to change each time. Pete

That's not right at all. FSUIPC's installer never used to install the loader at all, it was in the ZIP only as an option, with warnings against using it. In general it should NOT be used, but folks were copying the complete ZIP contents into the Modules folder without reading the instructions, so I changed that so it wasn't included in the ZIP but installed as one of the extras in the FSUIPC Documents subfolder, so it could still be found if actually needed. The installation document, which you should have read, explains where things are. If the DLL.XML file still contained the Loader reference after you ran the installer without the Loader DLL being present in the Modules folder, then something went wrong and the DLL.XML file wasn't properly updated. Check the Install log for errors! I'd strongly recommend removing the Loader from the Modules folder and re-running the Installer to correct the DLL.XML file. If it doesn't you need to show me the Install log AND the DLL.XML file from the AppData folder. Pete