Pete Dowson

Only if the number of AI exceeds the limit you've set. The default settings in FSUIPC will have the limiter turned off. Not sure why you supplied a log if FSUIPC is not doing any traffic operations. And are you saying the deletions are logged? Where? i'm not looking through that long log! You'd need to give me a line number of time (numbrer on left of each line). If the traffic limiter is not enabled, then the only AI deletions will either be by P3D (leaving area or a conflict, or possibly stationary too long), or by an external program, presumably AIseparation if that's the only one you are runnng. Maybe AIseparation is holding them (probably in SLEW mode) too long and P3D deletes them because of that. Why not try AIflow. it is very good at dealing with AI, unlike AIseparation which never worked properly for me. Anyway this is not an FSUIPC matter. If you want AIseparation support you'd need to find the author, or move on to a more recent and active program. Pete

I've just loaded P3D4.5 on my test PC (my cockpit runs a completely different door system for ProSim's 738, where all doors, even emergency doors, have door controls). I have no add-on aircraft in this installation to test with, so I transferred the FSX B738 over to P3D. Using the default "shift E" key press to send the Toggle Aircraft Exit control, I get the same as you -- two "ATC MENU CLOSE" controls. Very strange -- I've no idea where these come from. There's even another after the Selection: 1284590 *** EVENT: Cntrl= 66389 (0x00010355), Param= 0 (0x00000000) TOGGLE_AIRCRAFT_EXIT 1284590 *** EVENT: Cntrl= 66514 (0x000103d2), Param= 0 (0x00000000) ATC_MENU_CLOSE 1284590 *** EVENT: Cntrl= 66514 (0x000103d2), Param= 0 (0x00000000) ATC_MENU_CLOSE 1284590 *** EVENT: Cntrl= 65539 (0x00010003), Param= 0 (0x00000000) SELECT_2 1284590 *** EVENT: Cntrl= 66514 (0x000103d2), Param= 0 (0x00000000) ATC_MENU_CLOSE With the "TimeToSelect" parameter set to 0 these intervening controls stop any subsequent '2', '3' or '4' keypress (by default Slect 2, 3 or 4) from doing anything, so only Exit 1 opens. BUT if I set the "TimeForSelect" parameter to 4, the selections do work. So FSUIPC is doing its job. This is why the TimeForSelect parameter is defaulted to 4. Please note that, whilst you can change the number of seconds for TimeForSelect in the FSUIPC 'Miscellaneous' menu in FSUIPC Options, you cannot change it to 0 or from 0 to another value in the menu. You have to change it in the INI file and restart P3D. This is because the operation of the facility requires a different Simconnect initialisation sequence. However, I think it is far easier to assign, in FSUIPC, a key press (or combination) to Toggle Aircraft Exit with a parameter selecting which one. Here I used Ctrl+Shift+2 for exit 2. That works fine (on the FSX 738 exit 2 operates both cargo doors). The log shows: 1615874 FS Control Sent: Ctrl=66389, Param=2 TOGGLE_AIRCRAFT_EXIT 1615874 .. This key is programmed in FSUIPC6 'Keys' options 1615874 *** EVENT: Cntrl= 66389 (0x00010355), Param= 2 (0x00000002) TOGGLE_AIRCRAFT_EXIT Note the parameter 2. It is that which selects door 2. And no spuriosly generated ATC_MENU_CLOSE controls! So, in conclusion, I think that you may have TimeForSelect=0 in your INI (though that isn't defaulted), so check that. Also, you say you have tested the assignment using a parameter as above. I'm sure that should work, so I think you must have made a mistake somewhere. Please try again, and then show me the Log and your INI file so I can check what you've done. Pete

If you have no assignments, there is no command assigned. Same with just the default INI file. Let me try to explain something. With TimeForSelect=0 there is no assistance in allowing the "SELECT" commands (for selecting door or engine or whatever) to be associated with the previous command needing it (like Toggle Aircraft Exit) even with intervening controls (like in your case those ATC Menu ones, coming from who knows where). With no key assignments in FSUIPC, the keys are not interfered with at all. With TimeForSelect=4 (say), FSUIPC remembers commands like Toggle Aircraft Exit, and holds it for up to 4 seconds to see if it is followed in that time by a SELECT command. Then it sends both on to the Sim in one request (in what is called a SimConnect macro). This facility was specifically added in order to deal with cases where the add-on aircraft (most notably the PMDG ones) were sending so many commands internally that the SELECT commands became detached from their "owner" and therefore did not operate. This appears to be what you are experiencing. So maybe you do really need TimeForSelect=4 or similar, though it would be nice to find out where those ATC commands are coming from. Note that these commands do not need assigning within FSUIPC for this facility to operate. It detects them being issued the same as it has to for the logging facilities. Pete

Your Log shows that you are using P3Dv4.0, which is not supported by FSUIPC6. As John has told you, you need to update your P3D4 installation. Update to version 4.5. You'll find it is well worth it as it is much improved. and best of all, it costs you nothing! Pete

Oh dear. I wish you had waited until I could see what the difference was. now we have no comparison to make! 😞 If they are both from your non-working setup, why bother posting both sets? When you did the re-installation, surely you copied over your working files from your working setup? I think you must have some firewall blocking the connection. The WideClient complains: Error on client pre-Connection Select() [Error=10060] Connection timed out whilst the Server (for P3Dv4) says: 16000 Broadcasting service every 1000 mSecs 17219 Incoming connection Accepted ok (skt=17064) TCP 17250 Restarting service due to zero reception! 17265 Incoming connection Accepted ok (skt=17256) TCP 99406 Closing down now ... But the P3Dv5 one, which you only allowed to run for a few seconds before closing, says just 16016 Broadcasting service every 1000 mSecs 40938 Closing down now ... Now maybe it would have said something else if allowed to run longer, But probably not. I would guess the P3Dv5 is completely blocked by firewall whilst something possibly lesser is happening on P3Dv4. It might be very difficult to find out exactly why there's a difference now that you've not got that original working installation for us to do a comparison against. I think that it may well be that you have both the Windows Win10 FireWall active and also another service from a different program, maybe anti-virus, and they are blocking the accesses for different reasons between the two programs, P3Dv4 and P3Dv5. If you can (temporarily as a test) try without whatever you have got enabled you would quickly know. Then it would be a matter of getting permissions granted. There are really no alternative explanations I can think of. Pete

Ah, so, you only worked out that it was related to FSUIPC recently? And is that why you didn't report it a year ago? Can you try without GSX and Accu-Feel please? Did you yet try the two alternatives I suggested? did you try changing the TimeForSelect parameter as I also suggested. Unless you do try what i ask I really can't see any way to help you! But since then you use a different add-on aircraft with Accu-Feel. sorry, but we either need to find out what is making the difference, or whether an alternative way of assigning works. You need to try one or the other or both, because this sort of thing is certainly no different now in P3Dv4 nor in P3Dv5 installs of FSUIPC. You have something else changed. Pete

You posted to the specialist support subForum for Paul Henty's .NET DLL. Is that what you are using? I've moved it here because the question seems more like a general support question. The offsets used and supported by FSUIPC6 for P3Dv5 are listed in the Offsets document in the documentation installed when you installed FSUIPC6. I don't know what you mean by "engine on and off" as I don't know functions or controls like that, but certainly the current aircraft name and air file details are available in the documented offsets. Pete

You must have the axes also assigned elsewhere, probably in FSX. Make sure you disable controllers in FSX -- do not simply unassign the axes. You may need to select each controller and disable each one. What is this "yet"? You only posted this 35 minutes ago! How much faster are you requiting support to operate? 😞 Pete

I've deleted the FSUIPC6.key file which was included in this message. Registration files should NEVER be published openly. if we need to see such detail you will be asked to provide them via a private channel (email of Private Message -- PM). You again supplied your Install log. John needs your run-time FSUIPC6.log file which is produced when P3D is run with FSUIPc installed. That file is in the same folder as FSUIPC6.DLL (and FSUIPC6.key). Pete

No, everything for WideFS is identical on both P3D4 and P3D5. Did you install FSUIPC6 for common use between both P3D4 and P3D5, or did you install separately? Ah, so you didn't use a common install? For instance, when I installed I selected both P3D4 and P3D5, specifying a special folder I'd previously created just called "FSUIPC6" (so i could find it easily). You sent your WideClient files again, but you've not sent anything from the Server -- the FSUIPC6.LOG and wideServer.Log are also relevant, detailing what happens in the Server. Is the WideClient.INI you've been sending the same one used on your client when you run P3d4? If not, why not? I can't really advice further till you show the server end. Also comparing all these files with what you get for P3D4 would be informative because, as I say, there's really been no change in WideFs itself. Pete

There's no difference whatever in WideFS between P3D4 and P3D5. In the WideClient INI you posted you have specified the IP address, bit not the Protocol to be used. If you specify one you must specify the other (as documented). Try adding "Protocol=TCP" after "ServerIPAdress=192.168.1.5" in the INI. Pete

That is perfectly right and proper. You asked for an event to be called is FSUIPC sees 'A' released. And it does. No. Once the shift keys are released there's no way of knowing. BTW your original problems would probably have been resolved much more easily by using different events for each case. the problem with asking for "Press, Repeat or Release" is simple that, as documented, events aren't queued. if your plug-in isn't ready to receive one when another occurs, you don't get the first. Exceptions were made just for buttons and keys so that you didn't get into a state where a button or key looked "stuck". A mistake was made in the code (by me of course) in simply incrementing the number of occurrences. At the time the plug-in code is ready to be re-entered with the event, things like the shift codes may be different. The Lua plug-in system isn't running in real time -- the threads operate in their own time (and space). This is very unlike the key assignments to controls, to which you compared it. That operation IS is real time, and all in the main sim thread. Today I compared the offering for event.key to what is documented for event.button. If you refer to that in the Lua Library document you will see there's a Note (*) reference, and the Note occurs at the end of the event library section. If you read that and think about it in terms of keys too, then maybe it will be clear. For us the fact that you were trying to collect events of key press repeats as well really complicated things. In the solution we arrived at you will only get repeats if the plug-in is fast enough to process things as they happen -- unlike release which will be saved so that the key doesn't look 'stuck'. It did take John and I quite a bit of head scratching to arrive at what we think is a good solution. I don't think we can improve upon it. BTW, personally I find it quite unnatural to release shift, control or alt first, when using them in conjunction with a main key. You need to press them first, to ensure they count when the main key is seen, and release them after. It's seems natural and correct in any case, don't you think? Pete

But there's no way possible for that to happen? I wouln't even know how to start looking. I do see that you haven't really calibrated any of the controls properly in the first place. Apart from "slopes" the calibration numbers are pretty much all defaulted.Please follow the numbered steps in the User Guide for proper calibration. And I've never ever seen anyone use slope values of -15 or +15. those are so extreme! Try first calibrating your controls properly in Windows. The fact that you find them so oversensitive really suggests to me that the calibration values actually Registered by Windows are bad. FSUIPC can only work with what it is given by Windows. It is not reading the USB devices directly (altohugh you can, via plug-ins, if desired -- but that needs some programming). Pete

Hi John, Yes, it looks like it. Maybe the Traffic Limiter is active? Or they've been removed by the Sim because of conflicts? Pete

Hi John. No problems with vJoy. Tested and used here (along with vJoyOffsets). Pete

But you said "For a year I have been experiencing a problem related to Fsuipc when opening the doors of the plane" so, you experienced an error 'related to fSUIPC', but did not know it was an error? that doesn't make sense. That's very strange. what add-ons are you running apart from FSUIPC? Logs are text files and ZIP up very compactly. If a ZIPped log is too large then you need to demonstrate in a shorter session. i'm not ploughing through an immense file. Sorry. You've tried the assignments I indicated? If they don't work I need to see (short) logs showing that please. Also check with a default aircraft. Pete

More sophisticated -- a lot more. I've tried them on a networked PC with P3D5. The author also wrote AI controller, which also routed them on SIDS and STARS, but took a lot of setting up. These are just run and forget. Pete

I never found AISeparation worked very well. I think you'd be better off with the new programs AIFlow and AIGround. See https://www.alpha-india.net/forums/index.php?topic=33055.msg331712#new or https://www.avsim.com/forums/topic/574110-heads-up-on-new-ai-separation-utilities-for-p3dv4/Pete Pete

Ah really? Wow! Time flies. I must admit I thought we'd have a lot more from Microsoft / ASOBO in the way of a Software Development Kit by now But, there you go. 😞 You must realise that the "product" is still in Alpha stage -- not even Beta. With most developments you never even see an Alpha. The revelations Microsoft are providing are perhaps mostly in the way of advanced publicity -- and are just distracting good people like you from looking at what you have now.. Well, please do go for the latter. Let me know when you find someone who can do that! Maybe Asobo? I can't think of anyone else at present, and even whatever they can do for you is subject to change -- I reckon a lot of change before the dust settles and the Beta phase is announced. This year? Hmm, maybe, maybe not. And do please note that the name is just "Microsoft Flight Simulator". It has never been called MS 2020 by Microsoft nor ASOBO. Pete

There was never a version with a higher number than 4.974. There is a small update to that in the Download Links subForum. What is this Lua plug-in?. Pete

You aren't helping us to help you. Please read my previous post, not far above, from three days ago! And there's really no way lack of having a slope applied actually necessitates re-calibration. Slopes are set after calibrating and are applied on top. Their absence, assuming you are interpreting things correctly which at present seems very unlikely, cannot possibly "block" all your test work! Pete

That's good, though actually I think John decided to update FSUIPC5 as well! 😉 Pete

I'm afraid there's no other set of curves provided. The maximum deflection still has to be reached at either extreme. If you want a steeper slope in one part you pay for it with a flatter slope elsewhere. I suppose, for FSUIPC6 (not FSUIPC5) John could possibly provide a difference set of "slopes" made up of linear segments, but quite honestly a point on the movement where it transitions for one slope to another isn't at all appealing. A smooth change like that actually provided is surely preferable. I really sounds like you'd prefer it linear all the way, thoughI must sat the -3 setting is not far off that. Well, you could certainly do what you want with a script. I suggest you look at some of the many examples provided, because the developers here really have a lot to do without producing specialist plug-ins. Certainly you'd get helpful answers if you tried to do things yourself and got into trouble with something, but it is better if you made the effort. After all, that was the idea of the Lua plug-in system, to allow users to do their own thing rather than overloading the basic program with too many special one-off facilities. I'm afraid I simply do not know if that option still applies to the current simulators, and I don't remember what it did in any case. (Trouble with old age, sorry). Try without it if you like and let us know if it makes a difference! Pete

We've locate the problem. It's our code, not P3Dv5. It was all to do with Version Checking. The Text events weren't supported till P3Dv4.2 (for creation) and 4.3 (for destruction0, and we had on tidy snippet of code using just the subversion, so P3Dv5 looked like 4.0!! Duh! This is one of the troubles with trying to support multiple versions when facilities being used change. I wish sometimes we could force all users to keep their sim software up to date! I expect John will include the fix in the next version of FSUIPC6. Pete

Hi James, We've locate the problem. It's our code, not P3Dv5. It was all to do with Version Checking. The Text events weren't supported till P3Dv4.2 (for creation) and 4.3 (for destruction0, and we had on tidy snippet of code using just the subversion, so P3Dv5 looked like 4.0!! Duh! This is one of the troubles with trying to support multiple versions when facilities being used change. I wish sometimes we could force all users to keep their sim software up to date! I expect John will include the fix in the next version of FSUIPC6. Pete