Pete Dowson

For 0D70 writes, you'd need to use the Monitor option, with 0D70 as the offset and ASCIIZ as the type. For the button action just button logging should do. That makes no sense to me. Definitely do the Monitor logging, and try to stop when you get a failure so we know which log entry it is -- unless to can make your program stop automatically then? Pete

You are using the original bug-ridden and unsupported version of FSX. Try updating to at least SP! or the SP2 versions. Or even the FSX-SE versions available on Steam -- they are much better. Pete

It seems to be a bug in P3D5, and has been reported to L-M. Last I saw was that they are investigating. Pete

In FSUIPC the code to process the 0D70 method is the same common code used for buttons. I suspect it might be a timing issue. To determine if that's the case so the cause can be pinned down, could you use FSUIPC logging. Compare the times via your two methods. It has been found by others that changing L:Vars is not something you can do rapidly. I think the code in the Panels part of P3D is non-re-entrant and there's no queuing of requests. After all, the L:var mechanism was implemented as an internal thing for panel gauge modules. Try making sure there's a normal key/mouse pressing delay between each request. A good portion of a second I would think. Pete

Send me an email about that and I 'll take a look in less busy times. Pete Dowson@btconnect.com Pete

I think you might need either too buttons/switches, or a Lua plugin to program that. The initial on is fine. To move it again to Start (i assume) another press is needed, separately. But to keep it there is possibly more difficult. What happens the second time you use the App switch? Can you press it again without signalling Off? If not then you either need two switches or a plugin. Best type of switch is a centre off spring loaded one which sends a different signal for up and down. The type you'd also use for trims. Pete

I think you are referring to "Mouse Macros". Looking at your QW787.mcro file: [Macros] 1=APU 1.1=RX40000005,1 1.2=RX40000005,1 1.3=RX40000005,1 1.4=RX40000005,1 2=APUoff 2.1=RX40000005,3 2.2=RX40000005,3 3=Apu2=RX40000005,1 4=ApuDouble=RX40000005,1 5=RFuel=RX4000010e,3 6=Lfuel=RX4000010c,3 7=Rstart=RX40000015,3 8=LStart=RX40000014,3 9=RstartOFF=RX40000015,1 10=LstartOFF=RX40000014,1 You seem to have managed to create several macros, a lot seemingly aimed at the APU switch. Do the others you made work okay? The QW787:APU macro operates (presses) the APU switch 4 times, which is odd. Is that intentional? The QW787:Apu2 macro operates (presses) the APU switch once, which seem better. Does that not work? The QW787:ApuDouble macro operates (presses) the APU switch once too. So you have three macros all operating the same switch, two of them identical and one doing it 4 times. What is the purpose of having these like this? You have them operating using a single click on the RIGHT mouse button. Is that what you have to do on screen with the mouse? When you created the Macro on screen, didn't you TEST it, as it prompts on screen, by pressing the TAB key on the keyboard? The QW787:APUoff macro operates (presses) the APU switch twice, which is odd. Is that intentional? The encoding says to LEFT click on the mouse twice to do this. You have only assigned a button (or switch?) to QW787:APU and QW787:APUoff: 23=P0,19,CM1:1,0 -{Macro QW787: APU: APU: APU: APU}- 24=U0,19,CM1:2,0 -{Macro QW787: APUoff: APUoff}- This seems to mean that when operating the switch with the mouse you have to right click the mouse 4 times to turn the APU on. Is that correct? And to turn it off, you do a left click twice? I assume the switch you use is a latching toggle switch? Pete

Not until it is released with a usable SDK, and even then there are no promises. Being aimed also at XBox users it is a completely different beast from previous Flight Sims supported by FSUIPC. Don't forget it is still in Alpha and barely usable for many folks (including me). Alpha phases normally occur completely in-house and therefore before anyone outside the development team even knows about it, let alone sees it. Microsoft seem to be playing a canny advsertising campaign a long time before having a viable release. You'll need to be patient and wait for proper release before you get add-ons. Pete

Okay. Fixed in 4.91 now released. A well as the threshold offsets with the P3D5 formatter airport records version 4.90 also omitted runway approach lights and VASI information. Pete

I've looked into this, and I can confirm that it is a bug in MakeRwys 4.90 with the revised P3Dv5 airport records. I'm not sure yet how to fix it, but I will do and release 4.91 in due course. Pete

Yes, that is correct. John now uses two digits for the last part, so 6008 reads as 6, 0, 08. Pete

I should be ble to get my P3D5 system running later today. I'll check the record for the default PAGA and see what ADE makes of it. If ADE gives a non-zero offset I shall have to ask Jon where that field has moved to. Since the XML file has the entry for it but as zero there;s certainly a zero where it should be. Because of that I still think it more likely that the reworked airport records have had that field zeroes for some reson, possibly mistakenly? In the latter case it would need reporting to L-M of course. Pete

No, zero. They can't be missing as they are part of the structure. I assume you are only looking at default airports? Best person to ask is Jon Masterson, the author of Aiport Design Editor, who gave me the changes in the P3D5 airport BGLs -- just extra fields at the ends to handle sloping runways, taxiways and so on. Try the ScruffyDuck support forum, see what he says. Better still, update to the latest ADE for P3D5 (it is freeware), and load up one of those aiports and see what it says. Pete

Yes. You can assign the any axis to up to 4 functions. Pete

That's generally not a good idea. The [LuaFiles] section is maintained by FSUIPC and it would have added the Lua name when it saw it. It just wouldn't have deleted the old one. The problem is that the name "ThrottleManagerPMDG777" exceeds the maximum length for a plug-in name. This is what it says on page 1 of the Lua Plug-ins document: Note that the filename part (preceding the .lua filetype) can contain spaces and other characters acceptable to Windows, but there is a limit of16 characters on that name Pete

Oh, just another firewall problem. You needed to allow WideClient and the P3D EXE through the firewall. Pete.

😉 Thanks for the explanation. Pete

The Lua will start when you start the Sim. It isn't specific to any Profile. If you want it to be then you have to change the section name from [Auto] to [Auto.Aerosoft A320] However, it will be running in any case -- unless it has an error in it or it didn't work properly in the first place. It currently has nothing to do with whether you are using a Profile or not. You should check in the Log to see if an error is registered for your Lua plug-in. I can't really help further. I've not seen your plug-n and know nothing at all about it. Pete

But I didn't really help! :-) What was the solution? Pete

Seems it has trouble with Brosadcasts on your Network. Try doing as advised in the Documentation -- adding the ServerIPAddr and Protocol parameters into the INI. I have an 8 PC Network for my cockpit and they all link just after the Sim is "ready to fly". I've always used explicit linking. Pete

I think you are now in the wrong Forum. Shouldn't you be in an XPlane forum by now? And why are you shouting? Pete

You posted in a subforum, clearly marked in red "Not for support requests". I have moved it here, to the Support Forum, so it can be answered! FSUIPC3. Which is now unsupported and free. Please refer to FSUIPC.com. Pete

Thanks to a suggestion from Thomas, I believe this may now be fixed in FSUIPC 4.975a which you can now download. The original problem was definitely due to a failures some time in the install of FSX-SE, and in particular in the error which prevented you running the correct installer .msi file for SimConnect. Please confirm all is well after you install 4.975a. Pete

Okay. then please show me your INI file, because the [Auto] section with the same entry should most certainly do the same thing as that button! Ah, So, that sounds like you changed the [Auto] section and assumed it would somehow work without you restarting the sim? The [Auto] section is actioned when the system loads. If you use profiles you can have separate profile-dependent Auto sections, by [Auto.<profile name>], and those would be actioned on a change of aircraft which then caused a different profile to be loaded. Also you can reload button, key and axis settings using facilities in their own Option Tabs, but otherwise the settings are only loaded when you start the sim. Pete

Not from us. There is a program called XPUIPC (I think) which emulates some of the things FSUIPC does. You'll need to Google for it, or ask folks on XPlane forums. Pete