Pete Dowson

Please confirm if you do get it working. Thanks, Pete

I'm note sure either, but I think the clue is using assert(require "socket.core") assert(require "mime.core") rather than the Lua plug-ins PDF way: require("socket") for Sockets support, and/or require("mime") for Mime support. I think requiring for example "socket.core" is pointing it to the core.dll in your socket folder, and the same for mime. Ah, that needs updating (along with probably many references elsewhere). It' the sSame in FSUIPC6. We didn't bind either core dll's into 64-bit FSUIPC because we couldn't find versions which were compatible with the version level of Lua we are using, and updating the complete included Lua code was a fearful amount of work we couldn't contemplate. If your solution works, I'd like to host the file package here and post your help in our User Contributions subforum. Of course I'd rather you did the latter job, if you wouldn't mind. If you could do that first, I'd upload the file package and change the link in your post accordingly. Would that be okay? Pretty please? Pete

Good question. Ive downloaded adrem's ZIP and had a look and it just seems to be core.dll's. I'm afraid I don't know how to use those. adrem, do you have an example of how to use these in a Lua plugin in FSUIPC5 otr 6? Thank you! All this internet protocol stuff is a mystery to me! Pete

Thank you! Pete

If that works with FSUIPC5 and 6 can we host that here? Where's it from? Pete

You could consider using WideClient which remainds a 32-bit program. If you aren't using it already on a Network then you can use it on the same PC as the sim by setting the ClassInstance parameter to a non-zero value. Of course this would require a WideFS registration. You could apply for dedicated space. Or possibly space shared with other applications with which it would never be used. Ah, I didn't see that before I wrote my main suggestion. Is your application freeware? If not then forcing the purchase of WideFS might be an alternative to coming to a commercial relationship with us. Pete

But your initial post showed that the Assignments tab HAD recognised Joystick 0, Axis Z. So you could assign to it. As I said, worry about the numbers afterwards. Obviously the numbers must have changed somehow or FSUIPC wouldn't have picked that axis to show. And now you say you assigned to the elevator then went back and assigned the ailerons, yet that isn't recoded. Did you perhaps press ESCapre or cancel instead ofg OK? The problem is that we cannot help solve any problems about what values are being received from an axis without actually seeing them logged, and that cannot happen until you assign them to something. With no backups at all? Wow! What a risk! Anyway, something has evidently gone badly wrong with that, because there is no change in any of this between your installation of FSUIPC5 for P3D4 and FSUIPC6 for P3D5. You would have been far better off installing P3D5 in parallel with P3D4, transferring things over, then, when happy with P3D5, cleaning up the remails of P3D4. This is what I am doing, and it is working out well. I repeat: FSUIPC5 and FSUIPC6 have not changed in any area to do with control recognition and assignment. Please actually do some assignments, then show the results. Remember that if you assign "direct to FSUIPC calibration" you do need to actully calibrate there. That will be the better test to see what is going on. Once calibrated, even with bad values, the logging will show at least some useful information. Really it would be better first to assign to the normal fS controls as then the calibration won't be necessary for the logging we need to see. Pete

There's been no change in the assignments system and the way they are saved for a several years - certainly before FSUIPC5 was released for P3D4. ! How old was the FSUIPC you used previous to FSUIPC6? The only way that is ever possible is if the actual USB connection fails. Assuming the hardware and wiring are okay, it might be to do with Windows power management. Make sure in Windows Device Manager that it is turned off on all USB entries where it appears in the Properties dialogue. The FSUIPC6 files you've provided clearly shows that your three devices are recognised, and assigned IDs (0, 1 and 2), but you have absolutely no assignments, so FSUIPC isn't at all involved in using any of them! Make some assignments first. There's no point in worrying about the numbers until you do. If you had assignments in a previous install of FSUIPC why not copy in your previous FSUIPC INI file and rename it as FSUIPC6.INI, as suggested in the Installation guide? Pete

Assuming that the change from FSUIPC5 to FSUIPC6 was not coincident with a Windows update or re-install, that implies that your FSUIPC5 settings were lost in the first place -- i.e a default or out of date INI file. Check that you copied the correct file from the correct folder. If you think you got it right, either compare them yourself or post both file here. Pete

As far as FSUIPC settings are concerned, they are identical. The generic all-engine throttle operates from Idle to Full thrust. if you assign to the standard FS control, Axis throttle set, then the range it needs is -16384 for idle through to +16383 for full thrust. The zero centre value has no special meaning. The "centre" value has no meaning for the generic throttle, the one on page 1, assigning to Axis throttle set. The separate engine throttle controls used by FSUIPC are normally the "ThrottleN set" controls, not the standard FS "Axis throttleN set" controls. The former ones have a range 0 fror idle to +16383 for full thrust. The negative values provide reverse thrust. For your purposes there is no meaning for "the centre value" and therefore no need to "remove" it! None of this is any different in FSX-SE that it was in FSX, nor, in fact, as it is in P3D. Pete

It's in the name in a folder installed with your PMDG aircraft. Inside it there's a document with filetype .h. That contains a list of assignable controls. It isn't a user friendly document I'm afraid (intended for programmers) -- the list of controls is at the end and you actually have to work out the control number to use in FSUIPC assignments (as "<custom control>".). If you just, initially, want to check that you can assign things successfully to the buttons on your controls, start with a default aircraft. Then you can assign to the normal FS controls ... easy! PMDG do their own thing for most of the controls and switches and are more difficult to figure out. There's some helpful posts by other users you could look at -- browse the FAQ subforum above. Another way, and favoured by many users, is to use Mouse Macros. See the chapter in the FSUIPC User Guide about that. Pete

The Install log is not really relevant, butwe do need to see your FSUIPC6.INI file and the FSUIPC6.LOG, please. Pete

That's okay. It became obvious when you showed that brief snippen from the MakeRunways log. Pete

Add-on airports replace default airports. In order to do this the airport facilities data (in the BGL "LEMD_AFX-OPO2-N.bgl" as shown) contains special Deletion codes telling P3D to throw away data it was previously given (by an earlier loaded BGL file). Then fresh data can be used. Otherwise P3D would get two sets, probably conflicting. All MakeRunways is doing in its Log (that Runways.txt file) is listing the fact that the deletion codes are seen and executed -- they must come before the additions, so they are listed first. MakeRunwayts has to do two passes over the files in order to get the right order -- all deletes from files in the folder, then all addtions. So all the airport data is then added in the second pass, the one where you seem to have listed (above) only the heading details. All of the runway, taxipaths, gates and COM frequencies will be listed after those headngs, before moving on to the next airport. So, how did the first r4.csv get generated? It must have been from MakeRunways. So you ran the program twice and got different results without changing anything else? You aren't making sense, so please explain. If you see 4 runways in r4.csv they MUST be listed in MakeRunways,txt, so why do you show in yorpost here only the heading of the last LEMD entry? The answers to your questions are in the part you don't bother to show! LEMD only has 4 runways, each with 2 "start points", so 8 Start points. However, it looks like you have elected to only install the BGL which assumes winds from the North (I think that's what the -N means in the BGL name. It might mean landing or taking off from the North). Probably, in order to get the correct traffic flow, the scenery file -N removes the start points from the ends of the runways not being used. This sort of thing is done by some add-ons to overcome the problems in the Sim (which are supposed to be fixed in P3D4.5) whereby a runway cam't be closed for landing ot takeoff at one end without also doing so on the other end. The documentation for your add-on airport should explain this to you and inform you of which file to install for North, South or both ends active. Pete

You still don't provide enough information. And axis settings in FSUIPC are never lost! You are making a mistake. I suggest you show us your settings file (FSUIPC5 or FSUIPC6 INI amd any log showing the problem. Pete

I don't know. FSUIPC merely tries to use the normal TerminateProcess call to kill the process it created for the program. If that returns an error it will be logged. Did you look in the log? If there's no error logged then FSUIPC has effectively been told that the TerminateProcess succeeded. Possibly those two programs don't react well to forced closure, possibly leaving threads running? Possibly the program actually running is a process created by the one which FSUIPC has started. If it has such an initialisation program then I'm afraid FSUIPC has no way of tracking that. Pete

Many gauges are written like this, using L:Vars simply to keep track and control the graphic relating to a setting, but not the setting itself. Does the normal Master Battery control not operate on this aircraft? If it doesn't, and there is no other L:Var which does the job then why not use a Mouse Macro? Pete

I've never tried that. Did it work in P3Dv4? All FSUIPC does when you assign the P3D controls is send them on to the sim via SimConnect. What then happens is up to it. If there's the same control assignable in P3D itself, see if that works. I'll try it here when I can get at my P3D5 sim (we have chaps working on restoring our tiled floor in the hallway, and i can't get to my cockpit room at present). I can check it on P3Dv4 though, on this Win7 PC -- later. BTW, stupid question, but you are in a virtual cockpit view window already, I assume? Pete

You need to make the changes without P3D running,, otherwise they won't be read and at the end they'll get overwritten. Pete

Assigned in FSUIPC? If so, have you disabled controllers is P3D4? If not you probably have both doing the same thing. Alternatively, if it is a button you are sing, check that you only assigned to the button press, not to both press and release. Pete

No, but use the Logging facilities in FSUIPC to see what is being sent. Just before you try engaging reverse, enable both Axis logging and Event logging in FSUIPC's logging tab. Reproduce the problem, and look in the log to see what was sent. If you set the sim to run in Windowed mode and enable the log console facility, you can see what is sent in real time. Pete

No keypresses logged at all? Are you sure you checked thevright Logging option? Ah, I think probably the combination cancels the Num Lock temporarily. Actually I can check that now, whilst typing this ... Yes! I put the cursor at the start of this line, made sure Num Lock was on, then pressed hift + Num1 -- and all that happened is that the cursor moved back to the end of the line. The Ctrl in addition doesn't turn it back into a 1 either. So, sorry, it seems that key combination isn't usable, or at least not settable in the dialog. You could try editing the assignment line in FSUIPC's INI file. The format and keycodes are detailed in the FSUIPC Advanced User's guide, Or, perhaps easier, why not change the GSX assignment instead? I don't use its default assignments. I think I changed them all because they clashed with something else I was using. Pete

FSUIPC can only go by the Windows message it gets telling it the Key code for the key being pressed. I think the NUM LOCk should change that, but i don't know. Try enable the Ket Press logging in FSYUPC's logging tab and see what it shows. Pete

Thanks Thomas, It was my error. I now see that the FSUIPC.com site points to "FSUIPC4.zip", whereas the 4.975 version I prepared was named "Install_FSUIPC4.zip". Fixed now, so downloads from either place will be okay. Pete

Arrggghhh! It was my error. I now see that the FSUIPC.com site points to "FSUIPC4.zip", whereas the 4.975 version I prepared was named "Install_FSUIPC4.zip". Fixed now, so downloads from either place will be okay. Pete