Pete Dowson

The FSUIPC parameter doesn't change with different Active Sky versions. To check that the method is working why not just cahgne the path to a local one to check? Also you could use the parameter for the BMP (bit map) path so you have a viewable confirmation (assuming you can locate a suitable weather area). PEte

This is normally a result of the Lorby export program creating an incorrect MakeRunways_Scenery_CFG file. Can you check that please, in your main Sim folder? If you want me to look, paste it here, or zip and attach if it is big 9which sounds unlikely). Also show me the Runways.txt file (again Zip and attach if too big). Yes, that's normal. If you have no add-on scenery installed via the Addons XML method that will be fine. The Lorby program just finds and organises the addons correct and adds them to that special CFG file so that MakeRunways can process them. If you ran that way AFTER the first, correct, way, please run it the correct way again before showing the files. Pete

"Crashes the download"? But you downloaded it? Do you mean when you RUN makerunways it crashes? FS9? FS2004? It may be that you don't have the right MS tools installed. Which version of Windows are you using? MakeRunways has been developed using modern tools. You may need a much older version. Pete

Please try the BETA version: MakeRwys510BETA.zip Pete

Well, here are the taxipoints as in the BGL (converted to XML): <TaxiwayPoint index="3859" type="NORMAL" lat="33.649608604609966" lon="-84.42822799086571" orientation="FORWARD" /> <TaxiwayPoint index="118" type="NORMAL" lat="33.6220857873559" lon="-84.42451402544975" orientation="FORWARD" /> <TaxiwayPoint index="117" type="NORMAL" lat="33.62211797386408" lon="-84.42436695098877" orientation="FORWARD" /> <TaxiwayPoint index="62" type="NORMAL" lat="33.6495465785265" lon="-84.42684665322304" orientation="FORWARD" /> So MakeRwys is getting those right. BUT there are no paths listed linking those points! So, there is evidently an error in my code which is linking points which shouldn't be linked! Seems to only occur with these very large airports (in terms of taxipoints). So, back to debugging ... [LATER] Aha! Found it! Taking the first bad pair, this is what it should be: <TaxiwayPath start="3859" end="4214" ... Now before MSFS there was effectively a limit of 4095 taxi points, 1-4095. See that 4214 - 4096 = 118, the taxipoint MakeRwys is using. Ouch! I'll need to delve into it to see what happened to the other value stored in the same place denoting a runway attachment. A new Beta of MakeRwys should be available later today. Pete

Unfortunately, whilst moving to 64 bit has dealt with the memory problem causing me not to get any taxiways in certain airports, The problem you illustrated in your pic is still there. I now need to work out whether it is the data in the BGL which is wrong or my interpretation. You provided this from your analysis: Taxiway A4(line 537) point 9 to next point is 3.1 km Taxiway A4(line 537) point 11 to next point is 3.1 km Taxiway A4(line 538) point 2 to next point is 3.3 km Taxiway A4(line 538) point 3 to next point is 3.2 km I'm trying to understand this . The T5 file lists A4 this: KATL,A4,25.00,33.650642,-84.428642,1,25.00,33.650631,-84.428688,1,25.00,33.650578,-84.428833,1,25.00,33.650471,-84.428963,1,25.00,33.650341,-84.429039,7,25.00,33.650166,-84.429039,1,25.00,33.649990,-84.428963,1,25.00,33.649879,-84.428825,1,25.00,33.649746,-84.428604,1,25.00,33.649609,-84.428230,1,25.00,33.622086,-84.424515,1,25.00,33.622116,-84.424370,1,25.00,33.649548,-84.426849,1,0.00 KATL,A4,25.00,33.650642,-84.429962,1,25.00,33.650608,-84.429771,1,25.00,33.650528,-84.429611,1,25.00,33.621677,-84.425858,1,25.00,33.649990,-84.428963,1,0.00 I assume your point numbers count from 0, else it makes no sense. So, just taking the first two pairs: 33.649609,-84.428230 -- 33.622086,-84.424515 = point 3859 to 118 33.622116,-84.424370 -- 33.649548,-84.426849 = point 117 to 62 and, indeed, i can see the big change is location, very noticeable. Armed with just this I can determine whether the problem is in my extraction from the BGL, or in the BGL itself. My current feeling it the latter as so many airports are okay. But that's for tomorrow. Getting late here. Pete

MakeRwys has no installer! Just copy the EXE into the main Fs folder and run it there. Pete

Good! Wish all questions were that easy! 😉 Pete

Try, as a test, without the ",run1" on the Keysend parameters, but with Notepad with keyboard focus first. It my be that Notepad doesn't like the way the keys are posted. There's are also other ways of addressing the program to receive the keypresses -- ClassNames and Window titles. I use the facility with Pilot2ATC, for the PTT and other actions and it does work 100%. But it can be more difficult with some programs. These are the parameters I'm using: UseSendInput=Yes KeySend110=112,16 ; F1 Press PTT for P2A KeySend111=112,24 ; F1 Release PTT for P2A KeySend112=121,16 ; F10 Press Sayit for P2A KeySend113=121,24 ; F10 Release Sayit for P2A KeySend114=117,16 ; F6 Press Sound device for P2A KeySend115=117,24 ; F6 Release Sound device for P2A But P2A is not the same as all programs -- it sees the presses even when it doesn't have the focus. You could also try "PostKeys=Yes" instead of "UseSendInput=Yes". Pete

Okay. I managed to get an MSFS T5.csv file processed by P2A this morning (fiddled it, overwriting my P3Dv5 file with one generated on my MSFS PC). I get NO taxiways drawn at all at KATL. I don't know how P2A has got that strange drawings for you, but I have found out what the problem is after getting the same for LFPG (first reported on the P2A support forum). MakeRwys is currently a 32-bit program. Dating as it does from FS98 days that's not really surprising. In order to produce all those files with the airports all in alphanumeric order, it builds up all of the information in memory. It turns out that some of these MSFS versions have huge numbers of taxipoints -- over 4000 for KATL and over 6000 for LFPG. It simply doesn't get enough memory. It fails 'gracefully' rather than crashing. If I thought there was ever a danger of running out of the 4Gb 32-bit process memory I would have added appropriate error messages as well as acting gracefully, but this has never arisen before -- no where near, in fact. I'm working on a 64-bit version, but it isn't easy and very error prone (especially because structures in the assorted BGLs are all still packed as if 32-bit), so it's going to take a while and will need another Beta test period. I'll put an announcement up when a Beta version is ready. Pete

As well as what John said, it should be noted that in the previous incarnations of Flight Sim (and in P3D) the EFIS controls are local and specific to the gauge module displaying the results (eg the PFD and ND). Such local implementation is not usually subject to an external control offerings and the controls only react to mouse clicks. In the other Sims supported by versions of FSUIPC the solution has been either using "mouse macros" (programming a button to act like the mouse clicks needed), or L:Vars (Local Panel Variables). Unfortunately as yet such actions are not possible in MSFS -- they are subject to requests made to MS/Asobo. Pete

Arduinos are serial port devices. The serial port device support in FSUIPC is via the Lua plug-in library, so you'd need two things: 1. An Arduino program to send the required commands and data to the serial (COM) port, and receive data for display from it. 2. A Lua program to act on serial (COM) port data received (event.com), resulting in FS events/controls being sent or offsets being written, as appropriate, and also to monitor the values for display (event.offset) and send them to the COM port. This may sound daunting, and it is for something ambitious, but the programs involved would not be too large. More of a problem may be the poor current state f the SimConnect interface, especially for controlling all the aspects of autopilots. Pete

Good! Thanks for letting us know. Pete

I checked the data MakeRwys is using for KATL taxiway points and paths (as listed in the log, Runways.txt) and they closely match what the actual BGL contains -- as far as I've managed to check (not easy with several thousand points). It is important to note that the code in MakeRwys for handling the texiway data is completely unchanged from before and that works fine for all Flight Sims to date. The only difference for MSFS is the way it is now extracted, s the BGL format has changed a bit (mostly just new block type codes and additional fields, which I'm not using). So this is why I need to know if all airports are messed up or just KATL (or just one or two), because the former would mean some sort of error in my extraction whereas the latter would certainly mean an Asobo error in forming the data. (Actually of course that could apply to all airports too). I'm pretty sure the latest MakeRwys is by now in use by a number of Pilot2ATC and MSFS users, so it may be significant that so far only your report for KATL has been posted. This may take a while to get resolved. Thomas is looking at the possibility of making some specialised test tools. Pete

Of course. You don't need FSUIPC at all. It's a user choice. There are facilities in the SIM itself. But changing hardware and expecting previous settings to do the same as before is a bit of a stretch. No matter what way you choose. And why would that be? Are they totally inconsistent in the values they supply? Does calibration need adjusting for room temperature or humidity? I've recently changed to Hall Effect pots in my 737 cockpit. They work very well indeed. Recommended. Pete

Where are you getting that list from? The FSUIPC5 User Manual and Advanced users manual (the prime documentation for FSUIPC) are also ALWAYS installed as well as those extra ones. It looks like you either deleted them by mistake or somehow suffered a failed install. I suggest that you download again and reinstall FSUIPC. It seems very odd that you have every document installed with FSUIPC except those two main ones! How have you managed all these years before you changed the potentiometer? Pete

There's nothing "sadistic" in pointing out that it is all documented. I even tried to point you to where to find it! Without you telling me what version of FSUIPC you are using I cannot be that precise. but it would have been stated in the Installation document included in your FSUIPC download. Did you read that? For FSUIP3, FSUIPC4 and FSUIPC5 the documentation is, as i said, in the FSUIPC Documents folder in your Sim's Modules folder. For FSUIPC6 and FSUIPC7 it is in the FSUIPC6 or FSUIPC7 folder in your own Documents folder. How did you manage to get FSUIPC without using the Installer, which always also installs the manuals? Have oyu looked where i suggested? Pete

You need to do a proper calibration. For flaps you can calibrate for each flap position in turn. The documentation for FSUIPC is installed for you when you installed FSUIPC. Didn't you bother reading the Installation guide provided? You don't say which version of FSUIPC (nor sim) you are using, but if you have been using the same version for years surely you are using FSUIPC4 or at best FSUIPC5? Both are installed in your FSX/P3D Modules folder, and the documentation is in the (obscurely named?) FSUIPC Documents folder. Proper flaps detente (Dt) calibration is fully described in the User Manual. If you actually mean a more recent purchase -- FSUIPC6 or FSUIPC7, then you will find the FSUIPC documentation in your main Documents folder within the one called "FSUIPC6" or "FSUIPC7". The Installation document accompanying the install foile for FSUIPC does tell you these things! You evidently didn't look far, nor read what is provided in the files you obtain. Obviously the reason you need to re-calibrate is your change in potentiometer. You imply you managed to calibrate correctly before then, so why the excessive confusion now? Pete

Can you look at some other airports, please? I've done a quick check on the data being used for the KATL taxiways, and they look correctly extracted from the BGL. I'm therefore wondering whether it is a specific BGL data problem. I've got nothing which draws the resulting taxiways -- I might need to rectify that with a little graphics program. Pete

Mouse inputs are not directly assignable in FSUIPC. But you can do quite a lot of mouse action programming with a Lua plug-in. See the assorted event.mouseXXX functions in the Lua Library document, and also the Mouse library in the same document. Pete

It isn't possible for the Profiles still to be known to FSUIPC if you have definitely deleted the FSUIPC INI file! Everything it needs to do it is stored there. But make sure you delete the INI when FSUIPC is not running. The Profiles folder will be ignored with a default INI because the parameter will have reverted to UseProfiles=Yes, not Files. Also the Profile names are recorded in the [Profile.<name>] sections in the INI which will have been deleted along with the rest of the file contents. FSUIPC does not store this stuff anywhere else, only in the INI so if you delete it that's it, FSUIPC is completely back to default. Pete

Every part of the entry must be perfectly correct, not just the Key but also name and email, character for character. Making a mistake is the only possibly reason for the rejection of a correctly purchased registration. Pete

FSUIPC's IDs are 0-15 (same as internally, in the Registry). I think JoyID counts from 1 like FS. Is that only in FSUIPC? does P3D act the same? Try HidScanner (in "Additional Useful Programs" in Download Links subforum). The entries for your devices there might be useful. Also i think John will find the FSUIPC JoyScan file and the FSUIPC logs cottesponding to the INI's very useful. Pete

Sorry, but the registration for FSUIPC5 is not valid for V7. You need to purchase a V7 key. You will get a discount as an FSUIPC5 purchaser. Yes, that is correct. If you have a WideFS7 registration you can use it with FSUIPC7 too without purchasing WideFS7 again. Pete

Yes, but what John is saying is that one of your axes -- presumably axis Z on device E -- is continually "operating" (i.e. sending different values0. Use the ignore axis button to stop fSUIPC responding to this whilst you assign other axes. Pete