Pete Dowson

I don't have any add-on aircraft as such. The facility is P3D4's and is said to recognise every mouse sensitive rectangle. Maybe those have t be registered with P3D and somehow that aircraft has its own mouse detection code and proccesses mouse clicks itself. I doubt that though. Mouse action 10 is "mouse move", not "click". I seriously doubt if any of the buttons act on a move. Try to keep the mouse steady, then click, so the click is detected on its own. [LATER] I see that Reinhard has come through with a more tailor-made solution for that specific aircraft. Pete

There are threads on other forums (eg AVSIM) which explain all this better than I could (I am no teacher!).But here goes. 6-core with HT means Affinity Masks (AM) have 12 bits, one for each core, so: 1 1 1 1 1 1 1 1 1 1 1 1 That's P3D's default AM -- all cores enabled. And that's fine. FSUIPC cannot assign codes not already assigned to the process (P3D). The top bit (first 1 there) will be core 11 and the last bit core 0. Note that with HT enabled (which I don't), every other bit represents a pseuo-core, not a real one. I don't know how much the competition between the two 'cores' in a pair causes degraded performance, but possibly Intel have got that sorted. I don't take the chance -- and with HT off, the system doesn't get so hot and can be overclocked more with the same cooler. P3D4 will probably be using Core 0 at near 100% ( it seems locked at 100% here!). It will be using others as well, but you'll need to use Task Manager's Performance display to see which. The display can be set to stay "on top" so you can use it with P3D Full Screen. Let's assume it uses Codes 0, 6 and 8 most (all real cores). Removing those bits from the 12 shows us which are available for us to use for other things: Thus: 1 1 1 0 1 0 1 1 1 1 1 0 So just choose a selection of these bits, and prefereable a different selection, for each AM you need to assign. I'd tend to avoid the pseudo cores too, leaving just: 0 1 0 0 0 0 0 1 0 1 0 0 i.e 3 real cores to play with. But that might not be enough so by all means use the pseudo ones too if you like. To convert those bit lists to values to be used in a parameter, divide them into 4's: e.g. 1 1 1 0 1 0 1 1 1 1 1 0 Then convert each group of 4 into its hexadecimal value. 1110 = 14 decimal = E in hex, and 1011= 11 decimal, or B in hex. So an AM assignment for that value in FSUIPC would be xEBE. (See the thread entitled "About bits, numbers and hexadecimal" in the FAQ subforum). For AM's in other program's setting you would probably need the decimal, which isn't so easy. xEBE in decimal is ( 14 x 256) + (11 x 16) + 14, or 3774. Pete

If there are no normal "controls" or keyboard shortcuts for those, you can use the FSUIPC "Mouse Macro" facility. Please see the User Guide. Mouse Macros now work with ALL mouse sensitive switches and knobs on ALL aircraft -- thanks to facilities added in P3D4 which are now used in the current version of FSUIPC5. Pete

Just uninstall P3D4 as you would have to before installing an update from L-M in any case. When 4.3 comes out you'll want to do this in any case or you won't be taking advantage of all the fixes and improvements. It is by no means a static setup. And you should not have to reinstall many, if any, addons. Save copies of the DLL.XML and EXE.XML from the user AppData\Roaming folder and restore them afterwards. Most up to date P3D4 addons aren't even bothered and don't load that way in any case. P3D4 will simply prompt you on first starting after reload asking if you want to enable each of those add-ons. Orbx aren't the same --- for their sceneries just run FTX Central and that sorts it out. Nevertheless, I would strongly suggest that you re-download the Virtuali AddOn Manager (or the GSX Setup file as that includes AddOn Manager). I've experienced strange problems in the past and many of them came down to BGLMANX or COUATL being out of date. So much so that this is the first thing I tend to check on experiencing any odd problems. Pete

You haven't yet really described what is wrong from a user perspective -- i.e. what are the symptoms you actually experience as a result of the COM queing? I think that if things aren't actually going wrong, but something is a bit stuttery, then it must be a performance problem. Things are clashing somewhere, and as far as I can see from all this data, it is probably in the Windows subsystems for comms and networking, both maybe running in the one processor core. The Wideclient log shows a very high demand rate imposed by "Server": 279000 ****** End of session performance summary ****** 279000 Total time connected = 261 seconds 279000 Reception maximum: 31 frames/sec, 5868 bytes/sec 279000 Reception average whilst connected: 27 frames/sec, 2971 bytes/sec 279000 Transmission maximum: 59 frames/sec, 3853 bytes/sec 279000 Transmission average whilst connected: 16 frames/sec, 1144 bytes/sec 279000 Max receive buffer = 1004, Max send depth = 30, Send frames lost = 0 279000 **************** Individual client application activity **************** 279000 Client 9008 requests: 7049 (Ave 27/sec), Data: 4385539 bytes (16802/sec), Average 622 bytes/Process What is it sending so frequently? The Send Depth should never build up so much. Normally it would be 1 or 2. It implied WideClient is not getting enough time -- "Server" is monopolising things. Can that be tamed somewhat? I have 8 WideClient connections in my cockpit system, and FSUIPC/WideServer can cope well with a heavy demand whilst also running about 9 Lua plug-ins. There are some COM port involvements too. However: I see you are using TCP. Why? Is the order of packets important? Is it important not to miss any? Are you likely to get bad reliability on your Network? The only things I use TCP for are my CDUs (to ensure requests/settings are in order and never lost). For everything else UDP is fine. You don't normally want all the red-tape stuff, the checking and enveloping that TCP does, especially for things which are changing all the time in any case -- i.e. if one of the 29 packets per second is lost, it doesn't matter because abother one follows in 1/29th of a second. I think with UDP the load on WideServer will be a lot less and more processing core time will be available for the COMs stuff (both the Network and the COMs are being handled by Windows functions, not directly in any FSUIPC code). Also make sure your Lua plug-in is using an affinity mask to take it off the cores most in use by the Sim (LuaAffinityMask parameter in FSUIPC INI's [General] section). WideServer and the COMs functions in FUIPC are also using separate threads for reads and writes, and you can separate those using the ThreadAffinityMask parameter. Check core loading using Windows Task Manager. See which cores are most used. Do NOT use an affinity mask in P3D, judst check which cores are most heavily used and avoid them for other things. Pete

What names? Try moving them out or renaming them. The other add-ons do not use FSUIPC except possibly ProATC. Do you have the copilot enabled in ProATC? try without ProATC to see if that makes a difference. To be honest, now, I'm convinced you are in the wrong Forum, that it isn't an FSUIPC probem. Pete

In that case it really isn't FSUIPC which is doing this, as without any settings it is not actiely doing anything at all except receiving data inn case any application needs it. Of course, it may still be acting on behalf of requests from applications using its facilities, or even by Lua plug-ins. Are you using anything like that? Unlikely. The current version of FSUIPC4 dates from February, but it has not changed substantially for quite some time. It is now on a "care and maintenance" footing, with development being concentrated in the more popular and expanding 64-bit arena (P3D4 and FSUIPC5). After all, P3D4 is still being developed ... Pete

That's not my understanding. Maybe it applies to those SimMarket products where the keys are generated by the supplier. I don't actually deal with the keys at all. In my experience, and I do purchase quite a lot from SimMarket, I never get emailed the registration details. I have to go to my account and retrieve them. Pete

No, not at all. The SimMarket Order Number is what is needed, along with the Name and Email Address used for your account when ordering. You didn't register your account and purchase in your LogIn name, surely? My Login name is Pete Dowson, which is also my real name. I always wonder why folks would hide behing false names for Forums. Well according to the complete database, neither of those email addresses have ever been used for any purchases whatsoever from SimMarket! Are you perhaps making a mistake? Or could you have yet another email address? I can only search by email address or order number. Pete

No, but many very small changes aren't needed. I'm talking about a check that the value has changed enough to be worth bothering with. FSUIPC does this, for instance, with all assigned axes -- the "DELTA" value, which can be changed, determines the smallest change that will be handled. The values you are looking at for throyttle can be anthing from 0 to 16383 (or negative for reverse), but I'm sure you don't need 16,384 different positions for the feedback. Typically this is reduced by a factor of 256 even before it is noticed, and that's still 64 positions. However, the 3330 and 3332 values are "post calibration", so IF you are assigning in FSUIPC, the DELTA should have already been applied. Yet you say: By which I assume you meant that you remove the other events for a test. Is that so? If not that remains rather a puzzle. You mean not on what is happening regarding your device, but just on a monitoring reslut? And what does the Monitor show? Is the reception piling up, or the tranmission spasmodic? I don't understand the Sim-A log -- it has lots of lines like Flt Data Loop = 50 ms Data Send Rate = 16 A/P Rate = 10 but nothing about Reception? If that rate is related to reception, then a value ranging to to 16 seems reasonable since it cannot achieve more than 20 for all values put together, because of the 50 mS delays. What frame rate is WideClient getting, and what is the average on the Sim? I'm beginning to think i don't understand your problem at all. What are you thinking is wrong. what actually goes wrong from a user perspective? Pete

Sounds like you have some bad assignments or clashes between your Sim and FSUIPC. Do NOT assign both in the Sim and in FSUIPC. Use one or the other. Also be aware that PMDG is very choosey about HOW things are assigned, and will usually not respond to FSUIPC calibrated values. Try just removing or renaming your FSUIPC4.INI file before starting FSX. If that makes it better you have bad FSUIPC settings. Pete

Why the 50 mS delays? What if one of the other events occurs? It could cause them to pile up. And shouldn't yu be checking that the vaue being sent has changed sufficiently to bother with? You could probably save a lot of queued COM port traffic be filtering the data. According to the log, good connection was established in 2 seconds of starting WideClient. Not sure how much better you'd expect ? I think there are timings you can adjust if you really want, but they were optimised long ago. WideServer won't be able to secure 100% of the Sim processing time. Than you closed down 870 mSecs later!!! For COM port problems i'd check using a COM port monitor program. Oddly you didn't supply the WideServer.log, which would seem more significant? Pete

This is obviously a bug in P3D. Can you please report it to them. Well, that's really not proof. You need to remove ALL add-ons then add them one at a time. It could be anything which uses SimConnect. I run GSX, UTLive, ASP4, ASCA, Rex SkyForce, and several others which appear in AddOns, and almost all the scenery i ever use is add-on scenery, and there's no such problems here. It really does sound like a P3D problem. After all, FSUIPC has no involvement whatsoever with scenery. I literally does not know what scenery you use nor does it case. You might need to uninstall P3D completely and install it from scratch. Pete

Is this in the assignments tab, or are you reading this in the calibration tab? The overall max should be about 16380. it sounds like you have the device registered as a digital one -- i.e. either on or off, or at least only giving alf of the proper range. ALL Windows recognsed joystick axes should have a default range of -16380 to +16380 or thereabouts. Windows calibration achieves this. Have you calibrated in "Game controllers". If you are running some driver software for the device then this may be preventing good calibration both in Windows and in FSUIPC. Did you check the other thread near here about the same device (I think): Some Issues of The Axis Assignment There is also another potential solution outlined near the end of the thread entitled Levers not to calibrate Pete

Buttons and switches just need assigning to whatever you want them to do. what else? In your original message you said: "started to do set up for buttons and switches , that went well." so what happened since then? Have you tried looking at the User Guide? It does explain things and includes pictures. It really isn't difficult. Pete

Are the quadrant levers assigned to anything? Unless you assign them, whether in FSX or FSUIPC, then there's nothing to calibrate. The calibration operates on the controls inside FS, it doesn't operate on the levers themselves. Assignment is the process of associating the levers or dials to the function you wish them to fulful. You can assign throttle quadrant levers to anything, not just the obvious. In fact they all look the same internally, just a variable input. Pete

I've moved your post from the Download Links subforum, which is a repository for links to programs, NOT a Support Site, to the FSUIPC Support Forum so it can be answered. Please take care to post to the correct place if you want attention! What have you done with it since then, 12 days ago? And why €49.99. Even with 20% VAT it is only €35.99. And why is that? If you purchased it surely you had an account! Have you forgotten your name or password? Normally to change a password you need the current one. I don't think your real name is "captzog". Why use a false name here? I need to see proper identification. Name, email used for order, and order number. Pete

Yes, adjusting the existing line as you need. All that is standard Lua as documented in the Lua website and books. Pete

That isn't an FSUIPC log, but one produced to allow GoFlight support (or those who made the software you are using) to help. Possibly it is checking for a different version of FSUIPC, or is trying to connect before FSUIPC's interface is established. Pete

The value is fixed at 30 for the original, uncorrected version of FSX. I think the Advanced User guide probably specified that, but it was defaulted to 0 and the option to change it added for all the later versions. I'm surprised that anyone is still left running the original 2005/6 version of FSX when there were so many problems fixed in each of the issued updates, SP1 and SP2. I'll be sure to add a note for such users to the documentation. The value was fixed for the original release because 30 seconds was found ideal for avoiding assorted initialisation problems which, when fixed, made 0 possible. It was allowed to be varied then to provide another way to avoid problems with other add-ons. This section in the FSUIPC4 History pdf is relevant (page 26): 7. The order of initialisation actions in FSUIPC4 has been changed substantially in an attempt to try to avert the possibility of causing a loading problem with SimConnect, whether or not this is caused by Trust checking timing bugs. Furthermore, in order to allow changes to the timing to be tried, to avoid clashes with other competing SimConnect clients being loaded at the same time, a new parameter is added to the FSUIPC4.INI [General] section: InitDelay=0 This can be set to a value from 0 to 120 to delay the actual linking to SimConnect by that number of seconds. Whether this actually helps is unknown at this time. That was for version 4.80, in February 2012, over 6 years since FSX's release. This is also relevant, from page 21: 17. In order to try to avoid problems with some Direct Input or Sound devices causing conflicts during FSX initialisation, if you delay the SimConnect initialisation using the InitDelay option in the FSUIPC4.INI file you can delay FSUIPC's DInput and DSound scanning by the same time by adding InitDelayDevicesToo=Yes to the [General] section. That was for FSUIPC Version 4.84, released in July 2012, nearly 7 years after the first release of FSX. Pete P.S. Advanced User Guide is changed now, but this will only find its way into user Documents folders when another full update is made, and there's no call for that at present. So please just assume there's a subnote in the Guide saying "Fixed at 30 for FSX RTM version". Thank you.

All those which can be read using the ipc library facilities to read offsets, yes. It does cover all the things FSUIPC can read for oyu! Pete

Just edit the Lua file. It is a simple text file. you'll see quite easily where it opens file file. Just specify the whole path as well as the filename you wish! The only thing you need to know is that for each \ charater you need two 9i.e. \\) because in Lua as in many programming languages, \ is an "escape" character, used to prefix control codes. Do not be so afraid of Lua. it is a simple scripting system. Just look at the file, in an editor like Notepad. You will see how easy it all is! Documentation is in your FSUIPC documents folder. Pete

The Log shows: 5594 LUA.0: beginning "D:\Lockheed Martin\Prepar3D v4\Modules\ipcInit.lua" 5704 *** LUA Error: D:\Lockheed Martin\Prepar3D v4\Modules\gitlua.lua:5: module 'socket' not found: no field package.preload['socket']socket no file 'D:\Lockheed Martin\Prepar3D v4\modules\socket.lua' no file 'D:\Lockheed Martin\Prepar3D v4\modules\socket\init.lua' no file 'D:\Lockheed Martin\Prepar3D v4\modules\lua\socket.lua' no file 'D:\Lockheed Martin\Prepar3D v4\modules\lua\socket\init.lua' no file 'D:\Lockheed Martin\Prepar3D v4\modules\lua\socket.dll' no file 'D:\Lockheed Martin\Prepar3D v4\modules\lua\loadall.dll' which appears to indicate that you are trying to use a plug-in called "gitlua.lua" which I have never heard of, but it seems to be trying to use a lua socket package which you haven't installed. Note that you'd need the 64-bit package as it seems that it needs to run "socket.dll" and "loadall.dll" which need to be 64-bit in order to run inside P3D4. I have no idea how this is related to your "Goflight Interface Tool", which I also don't know at all. What does it have to do with gout GoFlight MCP? Isn't that supported by the standard GoFlight driver for P3D4? Why on Earth does it need something on the Internet or over a TCP/IP interface? That's what sockets are all about -- web access and PC Networking. I think you need proper help from GoFlight. Pete

Will they work in the Simulator? Have you tried. If it is not recognised as a standard Joystick type device in Windows and therefore the flight simulator, then FSUIPC won't recognise it either. Why are you wanting to use FSUIPC in any case? Pete

There are lots of Lua examples provided in your FSUIPC Documents folder, and other examples in the User Contributions forum here. Pete