Pete Dowson

For now just break the string in msgs[1] if it is longer than x characters (your choice of x). something like this (replacing that one line wnd.text(w2 ...) x = 80 --my example of how many characters you want, max mycopy = msgs[1] --make a copy for me to use len = string.len(mycopy) if len > x then --need to split mycopy = string.sub(mycopy,1,x) .. '\r' .. string.sub(mycopy, x+1) end wnd.text(w2, n, mycopy) Now I don't guarantee the above -- I've not tested it here, and I make mistakes just like any other programmer. Always check the Log file (in the same folder) to see if any errors occurred. The above MIGHT work better as two separate lines (ie two separate wnd.text lines). But try the above first. Pete P.S. Please don't expect much more from me in the way of direct programming. The whole idea of Lua being added to FSUIPC was to add to all the things that users could do for themselves, rather than me having to program them. Lua is easy enough to learn. I recommend getting a starter guide to Lua programming. "Beginning Lua Programming" is a good book, widely available. Pete

Both. I want to see whether FS truly does ignore gaps in numbering. All my experience says it doesn't. Let me see your file and I'll create similar types of gaps in my own file to test. Best program I found for both renumbering your SCENERY.CFG properly and tidily, and also for moving things up and down properly too, is SceneryConfigEditor.exe. (https://sourceforge.net/projects/fs-sceditor/) Pete

Yes, of course. That is really the main point of Profiles. Provided all your assignments are made in FSUIPC, none in FS, then there is no need to disable any controls or disconnect any. Just don't assign them in the profiles in which they are not to be used. Be sure, however, to use Joystick Letters to identify them (see the chapter on this in the User Guide). That way they stay with the sme assignments even if they do get disconnected. Axes and Calibrations only apply to the Profile they are made in. General ones are ignored when in a profile. It is a little different with Button and Keypress assignments. You can have a set of general assignments which apply all the time EXCEPT when overridden by different assignments in the current profile. This makes sense for buttons and keys because if they are not pressed then have no effect in any case, but this cannot be allowed for axes and calibrations as those may interfere with normal flying. Such controls always have a "position" (with some, even when disconnected, because some drivers send back an extreme value, as from a broken joystick). Pete

There's absolutely no difference in FSUIPC between FSX-MS and FSX-SE. If anything, FSX-SE is faster and more efficient. You need to say how you are assigning your Hat switch, and whether controllers are disabled in both FS's. Also, is the frame rate comparable? That has a bearing. Pete

There are two things you could try. First is to make the font in that window smaller. That's set by the line wnd.font(w2, WND_ARIAL, 17, WND_BOLD) 17 is the font size. Try making it smaller. You could also try normal text instead of bold: wnd.font(w2, WND_ARIAL, 17) The other is to split the text yourself. The text is displayed by this line wnd.text(w2, msgs[1]) You'd need to use some string functions to find a suitable place in the string in "msgs[1]" to insert a new line character (\n or \r). I haven't really got time to do this for you at the moment. The Lua string library is part of the main lua language and is fully documented on the lua website. Try a smaller font first. Pete

It might be that FSX is indeterminate between surface wind and the first upper layer, but really it shouldn't affect the wind smoothing. I suppose it is possible that the wind variation nd gust changes are somehow compensating for or acting against the slow changes which the wind smoother would normally be allowing. Pete

Sorry, there's no way to do that at present. I really wanted to divert both completely -- not have anything left at all on the Server, but I found that if I did that with the Menu then SimConnect didn't return the selections to the program whose menu it is. But if I could have found a way, I would have and will still do If it's a desperate need you have to leave the original displays alone AND have copies on the Client, I'll see what I can do. But may I ask why? The whole point for me was trying to avoid the loss of realism having a menu pop up on the scenery in front of you, and the same goes for the line at the top of the screen. What is your motivation? Pete

Your registration might have been lost when SimFlight changed servers and software systems. I think a lot of folks lost access temporarily. Probably the conversion of the database only included users active within a certain period. Pete

Yes. Pete

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