Pete Dowson

One of the images you attached showed that you assigned the ProSim servo control to offset 0BCC. But 0BCC is just a boolean flag, values 0 or 1, indicating whether the speedbrake is armed or not. How do you expect your servo to move to positions 0 and 1? Even if it did move you would hardly see it. 0BCC and 0BD0 are set by the sim according to the axis position. I don't know anything about ProSim's assignable servo output, but surely it should go to a separate user offset, like those in the 66C0 range. Maybe offset 0BCC will work, if ProSim drives the default speedbake. Certainly 0BCC is being set correctly here -- I don't have anything assigned to it in ProSim. I suspect assigning the Server output to 0BCC as well may cause conflicts with the Sim also setting it. You said: But you are using 0BCC, which is 0 for not-armed, 1 for armed. Surely you need the lever position, which is in 0BD0, or, better, a user offset, as I said. I don't understand why Mobiflight needs the 'on ground' offset. When the speedbrake is armed the detection of ground is automatic in the speedbrake operation. That's the whole point or arming it. Pete

Sorry, I don't understand this part. Isn't your spoiler lever a normal joystick axis which you can assign directly, and calibrate, in ProSim? I use my hand. It isn't motorized. I don't know MobiFlight. But why are you not assigning in ProSim? Version 3 or ProSim really does need all control axes assigned and calibrated directly in its config. Pete

I tested this today with ProsimB737, version 3.16B24 (almost the latest). My spoiler is assigned as an axis in ProSim, with the calibration, including the ARM position, done in ProSim. I logged the offsets 0BCC and 0BD0 and they were being updated correctly whilst I manipulated the spoiler lever. So, you certainly should be able to use those offsets to drive your spoiler motor. Pete

Yes, looks good now. Congratulations! Pete

Thank you! Perhaps they are using data from different dates. The magnetic runway headings can change due to changes in the Earth's magnetic field. Of course, the True heading should be the same. Pete

It looks like there's some sort of corruption which is causing the LorbySceneryExport program to fail to read the P3D4 add-ons.cfg files it needs to in order to find all the AddOn sceneries installed via XML files in your P3D add-ons folder (in your Documents). There should be one in you ProgramData\Lockheed Martin\Prepar3D v4 folder and another in your users\<user name>\AppData\Roaming\Lockheed Martin\Prepar3D v4 folder. The resulting MakeRwys_Scenery.cfg file is either empty, or in error: Using "LorbySceneryExport.exe MakeRwys_Scenery.cfg" LorbySceneryExport executed: Checking for "MakeRwys_Scenery.cfg" Reading Prepar3D v4 scenery: The CFG file being used is: "D:\Lockheed Martin\Prepar3D v4\MakeRwys_Scenery.cfg" 0 scenery layers to be processed When you run without Admin rights, LorbySceneryExport cannot run. This is the error: ... ERROR: failed to run Lorby program, error=740! Reading Prepar3D v4 scenery: The CFG file being used is: "C:\ProgramData\Lockheed Martin\Prepar3D v4\SCENERY.CFG" 486 scenery layers to be processed So MakeRwys has to revert to only using the Scenery.CFG file. This means that any and all add-on sceneries which install via the Add-On.xml method are omitted from the scan. Please run with Admin rights again, and show me the resulting MakeRwys_Scenery.cfg which you''ll find in the P3D folder. You should also run Lorby's AddonOrganizer program and check that it shows all you sceneries okay. The addons method is not used by FSX, and your P3Dv5 installation must be okay, Pete

Your post is very interesting. Are you wishing to allow others to make use of your work? If so, would you like to re-post this data to the "User Contributions" subforum, above? I can do this for you if you prefer, with just a small edit needed to divorce it from this thread. Pete

Just that one file? The others were okay? I'd need to se the Runways.txt file to understand why. Because access is needed to folders in your system which are normally protected. In particular, the Lorby scanning utility used for P3D must run with Admin rights. If it works without that, fine, but in that case it must run with admin rights -- they don't reduce capabilities! Quite the reverse. If you want further help you need to specify version numbers -- MakeRwys version AND sim version (FS98, FS2000, FS2002, FS2004, FSX, FSX-SE, P3D1,2,3,4,5 or MSFS). Pete

The software for the PFC hasn't changed, so what has changed on your system? If this is happening with no changes in software, then it must be a hardware problem. You appear to have some odd assignments in FSUIPC for different aircraft Profiles: for example these oddities: B747: Steering, Throttles1+2, 3+4: no reverse, no spoiler, no flaps A320 FBW: only Prop1 Cessna jet & F-358: nothing CRJ 1000: Spoiler, Throttle (=all throttles), Throttle2 (?!) And for the Hawk T1 you've assigned Throttle1 and Radiator cooling flaps (only), and have calibrated the Spoiler (not assigned). This is all a bit of a mess, with no consistency. AND you've not actually calibrated any of the axes you've assigned in FSUIPC. You so seem to have calibrated in the PFC driver itself, but with a mix of assignments, some in FSUIPC and presumably the rest left to the PFC driver, it is not easily possible for use to point to exactly what you might have wrong (assuming it isn't a hardware problem, which seems more likely. Fluctuations are commonly caused by multiple assignments to the same control, causing conflicts. For example, one such conflict is where you have the generic throttle assigned to one lever (so controlling all throttles) and throttle 2 assigned to another (the CRJ1000 assignments). The reverser is just a throttle sending -ve thrust numbers to the same throttle, so the main throttle should be at idle when using the reverser and vice versa. With a professional style quadrant this is assured by the design of the levers (the one attached to the other). With separate levers it is your job to use them correctly. First off, concentrate on getting things working properly on one aircraft. There's no way we can diagnose problems with such a complete mix, each aircraft having its own odd set of assignments and calibrations, mixed between FSUIPC and PFCcom. Try to keep everything in FSUIPC because that has the Profile facility whereas PFCcom only has a few paricular types. The latter is a lot simpler if you only fly one or two different aircraft types, but you have many different ones and profiles would be better because of that, but you need ot be more consistent in where you are assigning and especially calibrating. So, select an aircraft, sort out your assignments and calibrations in FSUIPC, and test. If you still have problems then it might be possible for us to help you via logging or other methods. Pete

Just a correction. Those are not overhead indicator/buttons, but part of the MIP or Glareshield. Maybe you are looking in the wrong section? They are definitely listed. Look in the Glareshield section for Caution and Fire, and the Forward Panel section for the AT, AP and FMC inidicators. Pete

I don't think very many of the gauges and switches in PMDG aircraft are susceptible to mouse macros. In FSX-SE (FSUIPC4) that facility relies on the coding of the gauges being strictly to FS2004 C++ programming, using the tools originally provided by MS. The facility is a 'hack' into the code. Most gauges just aren't coded to suit. In P3D4 and P3D5 the mouse macro facilities depend on new facilities implemented for us by L-M, and are thereby more consistently applicable. Pretty much ALL of the switches and dials in the PMDG 737 implementation can be controlled using the <custom control>s John mentions. I think you'll need to explain exactly what switches etc you are trying to program for which you think there's no provided control already. What have you actually tried? Pete

Can you explain a few things please: what is PF3? What is meant by "fax or p3 data"? What 'runway maker' are you talking about? Actual names and version numbers please! Pete

STOP PRESS! I suddenly remembered: there are lines in the Log (Runways.txt) showing a computed threshold/start. This is actually computed with trig the way I said, thus: // Compute better thresholds and get other stuff rwy1.r.fLat = (float) ((double) rwy1.fLat - (((double) rwy1.r.uLen * cos((double) fHeading * PI / 180.0)) / 729132.0)); rwy1.r.fLong = (float) ((double) rwy1.fLong - (((double) rwy1.r.uLen * sin((double) fHeading * PI / 180.0)) / (729132.0 * cos((double) rwy1.fLat * PI / 180.0)))); fprintf(fpAFDS, " Computed start %s: Lat %.6f Long %.6f\n", chWork2, (double) rwy1.r.fLat, (double) rwy1.r.fLong); So the positions given ARE the centres of the end lines of the runway! I seem to remember I did this because so many runway "start" records were actually set at the hold point off the runway. This is especially the case for many add-on airports. Sorry about my first answer. Most of this code is so old I don't remember it well (and old age isn't helping). Pete

The threshold lat/lon is just what is provided in the BGLs, usually from a "Start" record (the data used by the sim when you opt to start on a runway). No computation involving any threshold offset is performed. Makerunways' job is simply to extract and file the data. How it is used and what it all means is up to the user. Possibly, if you actually want the coordinates of the very ends of the runway you would need to compute this from the runway length, the centre coordinates and the direction of the runway -- i.e. a bit of trig. Pete

Good. I'll make it the current version, then. Thanks for the quick feedback. Pete

I had a look at the code and I think I've fixed the problem. It looks like it's been there since the very first version which was released in 1999, so it's over 22 years old! Surprising no one has reported before! I assume the binary format is very rarely used. BTW your version 5.128 is out of date, 5.129 is current. However, it would have made no difference. Please try the attached and let me know. If okay I'll make it a proper release -- it is version 5.13 now. Pete MakeRwys.exe

Yes, it is a very wise thing to backup your INI file. You shouldn't have a problem -- it is just a text file after all, in the FSUIPC installation folder. What's wrong with looking it up in the FSUIPC Advanced User's manual, provided as part of the FSUIPC installed documentation? The section on button programming provides a complete list of the Key codes used. No, 'Press' and 'Repeat', as described fully in the document. If you want to find things out, supplied documentation is a good place to start! Pete

No, sorry. I'll have a look, but it will be next week now. First, though, please tell me the version number and what simulator you are using it with. And are they default or add-on airports? Pete

The words "equivalent to" is surely obvious? The setbits functions are simple and fast ways of setting bits in an offset without having to read that offset, "ORing the bits" (a simple logic operation), and writing it back. Not only does it do it in one call, it also prevents the offset value changing for some other reason after you read it and before it is written back (after all, the Lua thread may be only one of more threads also changing things -- like the values being continually received from SimConnect. Your second sequence, reading the offset, setting bits in the offset, then writing what you read back would end up with no change to the offset. Pete

Thanks for verifying! I'll make it a proper release this afternoon. No need to re-download it though. Pete

Yes. The Gate identification is more complex that I'd remembered. The clue was that the KSNA gates with Jetways were not actually "1" etc, but "G1" etc. In other words the names weren't matching because another component is involved. I think it's all fixed now. Please try this version (same version number, so please destroy the previous one). Pete MakeRwys.exe

Hi Bruce, I had a quick look this morning. You are correct, and your diagnosis was spot on! I checked the Jetway data definition in that FSDeveloper wiki document with the definition I was using, and mine was missing the "gate name" field. Evidently that was discovered after I used similar documentation to add the /Jetways facility to MakeRwys. So, it wasn't checking the gate names! I attach version 5.129 of MakeRwys.exe which appears to be correct. If you confirm I'll make it the current release. Thank you for your excellent report. Odd that the folks who asked me to add the Jetway facility, so long ago, didn't find the problem. Pete [EDITED: attached file removed. See later in thread]

No, they are separate entities in the encoding. And internally names and numbers are linked by a serial reference, not directly related to either. I don't see how anything can be mixed up or confused, but perhaps you can see for yourself. The BGL format is here: https://www.fsdeveloper.com/wiki/index.php/BGL_File_Format I'll certainly check for you though. Are the airports you mention (AYPY and KSNA) default ones -- is that what you mean by "no overrides"? Even ZIPPed? Anyway, it doesn't matter if they are defaults. I might not be able to look at this for a day or two. Pete

This is very strange as nothing has been changed for many years -- just the conversion to 64 bit in the case of PFChid64.dll. The current PFChid was last built in July 2017. How many years are you going back for it to have 'worked'? Pete

I moved your question from the Announcements subforum, where you posted it. What made you think that was a place to post support questions? From the BGL files which supply the Sim with the scenery of course. You can see it doing this when you run it. It doesn't read it automatically. You need to run MSFS at least once after installing scenery, so the new stuff gets registered, THEN you run MakeRwys to update the data files it makes with the new information. Pete