Pete Dowson

Ouch! It's the VendorID being zero. The code assumes that zero is an omitted value, so either a zero VID or zero PID would give this result UNLESS the names were used instead. But it looks like there's no Vendor (Manufacturer) name and no Product name! That is really bad -- they've broken all the rules for HID devices! 😞 You could see if it will work with "" (the null string) for the VID and PID parameters. That should get it passed the first checks. Otherwise I will see if I can fix this somehow in the next interim update of FSUIPC5. I hope you ARE using P3D4, as I'm not developing FSUIPC4 any more. Pete

What do you use on the actual switch, with the mouse? Pete

I'd like to know what of you've read about this you don't understand. Is the English not good enough? Sorry, but I do explain it in the documentation. That's what the documentation is for. I don't know what part you need expanding upon. If you need it translating, can you try Google? Pete

Sorry, this one is confusing. Are you saying MakeRwys is IGNORING the MakeRwys_scenery.cfg file? What is "LorbyScenery.cfg". That isn't to do with MakeRwys. Here it is getting even more confusing. What are yo actually doing? Why not follow the instructions. Put both MakeRwys.EXE and LorbySceneryExport.EXE in the P3D folder, then just run MakeRwys. All the rest of what you are doing seems unnecessary and confusing! It was all simplified thanks to LorbySceneryExport being provided! I really don't know what you want me to replicate. None of what you are doing is realted to what you are supposed to do. Sorry. Pete

Strange. So were the "A" macros made after a different sequnce of aircraft being loaded? That appears to be what I see here. If it always do the same thing, the macros stay valid. I'm still awaiting L-M's comment on this, but I think I will still disable the "Create Mouse Macro" buttons for now, but with an INI option to enable them, and put a warning in the release notice. Pete

I will see what I can do ... Pete

Check the option for no reverse zone on the Thottles calibration tab!. Pete

Oh, I see. My error. That was assuming the switch returned the values needed, they would be parameters to a single macro. So you'd get FUEL_SELECTOR_SET with parameters 0, 1, 2. I assume (if that's what is returned by the Cirrus), but now I see that those aren't the values you want. I also may be interpreting the documentation for the DLL incorrectly. Thst seems odd. Two tank selector switches, but one returning 0, 1, 3, and the other 0, 1, 2? I'm at a bit of a loss to know why your original macros don't work, or rather, why they repeat continuously. The log from the DLL doesn't show repeats from the device. I'll have a look in the code for the DLL to see if I can spot anything, but as I say it is very old code now, dating back to whenPFC started using HID interfaces (before that it was all COM serial port operated). The only work done recently on it was re-compiling for 64-bit, with suitable changes for that to happen. I've also got the difficulty of having no hardware to check it with. I'll get back to you if I have ideas or any sort of fix. Pete

Nearly. You need the length parameter with type "STR", thus: event.intercept(0x0130,"STR",256,"flightplan") But then. in if value ~= "xxx" ... you might be comparing all 256 chaaracters, not just the string till the end. I don't know how he is removing the plan from the GPS, but if it is by writing a null string, then it would be safer to test just the first character for zero, thus: if string.byte(value, 1) ~= 0 then ipc.writeSTR(offset,value) end But please do first use the Log at the end of the flight BEFORE EFB removes the plan to see what it actually writes. I'm not sure how SimConnect handles null strings. Maybe he writes a bad filename and that does the trick. If so get back to me and we'll work out the next step. Pete

Maybe not, but I do write as clearly as I'm able, so I don't see how i can really do any better. I'm a programmer, not a teacher. It would be far better if you asked specific questions, not asked for a complete tutorial. i'd like to know what you don't understand and why. That's the way things improve, eventually, after all. On your first point:about an earlier message, if you know it exists why not point me to it? Do you mean the one where Thomas contributed? Where is that? You see, by starting a new thread on the same subject to make it more difficult, not easier! Pete

I suspect the 0 position is in fact an "off", whereas the other two areboth "on". I don't though know. I haven't had a Cirrus for many years now. I don't know the position of the + either. In fact I'd forgotten all about the /position bit -- I thought at first glance that was partr of the name. But looking now at the document i see in fact that it wouldn't take a + or - parameter, as the /n facility is specifically intended to deal with rotary multi-position switches. So I'm puzzled as to how the ther positions are repeating. Have you tried using the PFCHid logging? The document list this log option which may show what is going on: LogDecode=Yes Ah, so it is using the SET control, not the specific positions! So why are you trying to change that via macros? And if you really want to, which not simply have the one line "TankSelector1"? Pete

Not sure what G:Vars are, but certainly the regular sim controls (the ones assigned to these macros) work fine. Tested here by assigning directly to switches (one switch each for the three positions). Pete

Ah, I see. With a switch (as opposed to a button), I think you need a + or - added to the switch name, to denote whether to do the action when it switches on or off. Without that it just looks like a button being held down. See the PFCHid document, page 5. Pete

MakeRunways Version 4.86 is released, including the Lorby exporter program. Pete

I done more tests and the same problem applies to default aircraft as well! This is a disastrous result for the Mouse Macro facility in FSUIPC5, so it will be disabled. I'll be tring to get L-M to do something about it, because otherwise there's little point in the facilities they provided! The next release of FSUIPC5 (5.141) will have the "start" button disabled. I am retaining all the code in the hope it will be fixed by L-M. [LATER] On further testing I seem to see that the macro values (rectangle numbers) do remain the same, but only if the aircraft concerned is the first one loaded each time. Either that, or the same sequence of aircraft loads before hand (not sure about this latter point though). Either way, I do have L-M involved now. Even if they fix it, it won't be immediate. it would be in the next main update I think (4.4 or whatever), so probably months away. Pete

I have done some tests. The controls you are using work fine. Also the FUEL SELECTOR SET control works with parameters 0=OFF, 2=LEFT, 3=RIGHT. I cannot make the mouse operate the switch properly no matter what I do -- and that's true just after loading P3D, with no attempts to use those controls. Occasionally, after clicking many times in various places it will select "RIGHT", but then won't move at all -- with the mouse. No trouble with the controls though. So, it looks like your mouse problems are to do with the Carenado implementation, or a P3D bug. For your macros sending those controls, I can't advise. We need a log showing their use with your switch. Enable both Button and Event logging. We may need PFCHid logging as well, but that's another matter which I'd advise on afterwards. Pete

I've just looked at the EFB2 forum. According to the EFB2 author's reply about this, it is removing the plan from the GPS only. It is not deleting the actual .PLN file. So the interception method I suggested above should work fine. Pete

Did you use the installer for AddOnOrganizer? If not, or if you moved it, the Registry entry will be incorrect. HKEY_LOCAL_MACHINE\SOFTWARE\AddonOrganizer_P3D_V4 Install_Dir. Also, iin a day or two there will be a new MakeRunways available, supplied with a special version of AddOnOrganizer which sits with MakeRunways and geared to only do what is needed to make that file. Pete

I MOVED YOUR SUPPORT QUESTION FROM THE REFERENCE SUBFORUM INTO THE SUPPORT FORUM SO IT CAN RECEIVE ATTENTION. The problem there is that the DLL is a 32-bit module and cannot be used in a 64-bit process. You needed to look in the User Contributions subforum. There is a solution using another package entirely which a user found. The thread is entitled: "Work around for UDP sockets in fsuipc5". Pete

Can you log "Events" in FSUIPC then check what is being sent? Do those standard sim controls actually work on that aircraft? It sounds like they don't, or not properly and there's no way sending a standard command should then prevent a switch being moved by mouse. How do you recover from that - reload the aircraft or restart P3D? I see the Carenado A36 is one of the included P3D4 aircraft, so I can test these commands on it here, myself. but I will be assigning keyboard or Goflight buttons. And it may not be today. There's also a "FUEL SELECTOR SET" control, which would need a parameter (probably 0,1,2,3). BTW FSUIPC 5.122 is out of date. The current one is 5.14. You should really update when asking for support, just in case things have changed. Pete

I assume you are talkng about EFB2? How is it "deleting it" via FSUIPC? Do you mean deleting the actual file? Or simply removing it from use in the Sim? If the latter, then I can only think it is telling the Sim to load a plan and not giving its name. I don't know if that removes the plan from the sim. You could try logging in FSUIPC to see exactly what it does (Log IPC writes), but you will probably get a very large log. The offset to get the Sim to load a plan is: 0x0130 The current flight Plan path & file name (in UNC format if WideFS is in use). This is a 256 byte area, but the actio is triggered by the one byte at 0x0130. Writes to offsets can be intercepted by Lua plug-ins then either dealt with or sent on. This is by the library function event.intercept. You would need to check what istring s being sent to 0x0130, and just forward it on (i.e. do the write yourself via ipc.writeSTR) if it is a proper plan name which you want loading. If it's the file being deleted then that must be happening directly, not via FSUIPC. Pete

Thanks. This is the evidence I need to get L-M to look at it. Is this with the Airosogy Airbus Pro? Can you be very specific please -- L-M always ask how they can reproduce the issue. Pete

What is puzzling you? Please ask specific problems as I'm not going to reproduce the manual sections here! And the manual was produced to explain things. You mention Thomas' answers (?), but where are they? Are you starting a new thread rather than sticking to an earlier, more relevant, one? Pete

Yes, via WideFS. I have both of those, and have the menus an messages on a small monitor in my cockpit. Unfortunately you cannot remove the Menus from the P3D screen, but you can remove the others via an option in the P3D4 User Interface. Details are provided in the Lua Library documentation in the FSUIPC Documents subfolder, and in a little package supplied with the latest WideFS. WideFS is payware and needs registering through the FSUIPC Installer. Pete

That's not a message from FSUIPC, but from iVAP from what you say. It sounds like a conflict betwen the LH DLL and whatever iVAP is loading. Maybe a different order of DLL loading would help -- that is usually dictated by the order of entries in the DLL.XML file. I'm afraid I know nothing about iVAP. I do have LH Budapest but not currently installed in my P3D4 (you don't mention versions at all). But FSUIPC itself has no dependencies on scenery, so it's definitely a matter relatting to IVap. It sounds like FSUIPC is loading okay. The error is in the iVAP module not running correctly, not detecting the running FSUIPC. Didn't you check the Forum for previous postings on this. I've just done so and immediately found this one: That thread ended with a solution. it may not be the same problem you have, but it must surely be closely related! Pete