Pete Dowson

Oh. That's for support for users of the "Client DLL for .NET" by Paul Henty. i.e .NET programmers. Please do read the names of the places you post in!. With the default aircraft you are using that is not surprising. With a proper cockpit build why are you using the default aircraft, which are really relatively basic compared to the real aircraft? Which instruments are you trying ot program which, for default aircraft, don't have normal FS controls which you could assign? There are certainly very few, and none i can recall which would be adjustable by encoders. I did ask what you were trying to do. maybe you don't know the FS names of the things you want to control? That happens. Pete

Where have you been posting them? I've certainly seen none from you before here, in the Support Forum! Really? How old was that? FSUIPC has supported macros since around 2002, well before FSX was released, for sure. I see you are using FSX-SE, and most certainly ALL versions of FSUIPC which work with FSX-SE have supported macros, of all types (Lua, L:Vars, normal controls and mouse). Ah, you just mean "mouse macros". Those only work on gauges written in C/C++ using the original Gauge SDK provided by Microsoft. That used to cover most add-on aircraft in FS2002 and FS2004 days, but it really has never included much on the default aircraft -- because Microsoft didn't use its own SDK! Nowadays most add-on aircraft have gauges using XML techniques rather than the SDK. Those aren't susceptible to the hacking needed for mouse macros either. However, they do often use Local Variables (L:Vars) which can be used instead, in different macros. If you get no "green window" when in mouse macro making mode and clicking on the panel somewhere, it means there's no support for such things at that place. For most default aircraft there are built-in FS controls to handle them. What is is you want to do? Pete

So the function is NEVER called -- there's nothing to call it! Have you not looked at any of the many examples using events instead of loops? How did you think the function was called? The proper script for you would be: function depart(offset,value) if value==2 then --check status of strobe at PMDG 737 sound.play("c:\\mysound\\paxsign.wav") --if status on white play sound end end event.offset(0x6500, "UB", "depart") The "event" call keeps the plug-in running awaiting a change to that offset, when it then calls the function. That's what events are for -- please do have a look at the documentation and examples provided. Pete

I assume that is just an extract? Where's the rest of the program? I can't help with and incomplete extract! And why not simplify it to: function depart(offset,value) if value==2 then --check status of strobe at PMDG 737 sound.play("c:\\mysound\\paxsign.wav") --if status on white play sound end end since both the offset and its value are supplied in the function call. That's the whole point of having parameters in it! Pete

Well, there's still nothing I can do about it. Without knowing WHY it suddenly thinks my program, compiled with the same compiler, libraries, and so on, as FSUIPC5 itself, and with the same tools as P3D4 itself, is "not compatible" with your computer, I cannot do anything. And it IS compatible with all my 8 computers! If it isn't a difference in your Windows installation, it must be something else specific to your PC. I Would add some extra logging, if the program actually started but it sounds lke it is just looking at it!? Pete

As far as I know (and I don't use PMDG aircraft) the commands offered are actually representations of the way the mouse is used on the switches and knobs. For those which using the mouse turn the knob one way or the other, the mouse left and right click is used. The commands have the relevant Windows MOUSE code as parameter. For this reason, the document in which you find the numbers of the commands also lists the relevant mouse codes. Please do take a look. Also please note that this is really more a matter for the PMDG support forums. I cannot really undertake to support other software than my own. Pete

I've never seen such a message! How strange. I've no idea how it is deciding that! Well, it must be a new bug they've introduced. I only have one Win10 PC (staying resolutely on the better system, Win 7, for my 8 satellites), but that was subjected to Windows Updates a couple of days ago. Without knowing how they could decide such a thing I've no way of changing anything to suit MS's whims like this. Both the Installer and the DLL are compiled with Visual Studio 2015, the same version used and recommended by L-M to match their P3D4. Please report it to MS as a bug. I'm sure they need to fix this in yet another of thir automatic updates. Pete

No. GS is always available. It comes in very useful for monitoring taxi speeds. Why not try debugging in the way I suggested? Pete

You mean you hadn't allowed the updated FSUIPC to be loaded before? no wonder the INI still showed the older version -- the new one would have never run! FSUIPC4 creates or updates the INI when it is loaded, NOT when it is installed. It also created a LOG file which is always useful inm resolving such things. Pete

That isn't the complete script I assume? What is the event? Or are there more than one? The way I debug these things is to use the ipc.log function to log what is happening. you could alternatively use the Debug/Trace log option, but if this function is called frequently that could be very long and mostly no use. I see you test "and (aljflag == 0) " which is a waste as aljflag is always zero there, it is zeroed when the function is called. You might as well delete it and all references to it. You also refer to a "djz" value which is not set or changed in this fragment. You've cut out far too much for it to make sense. Try using ipc.log to show the value reecived frow offset 02B4 and the computed gs. Pete

Don't forget I am getting that with P3D4.1, and I cannot see any possible reason for it. It is bazaar. But life is too short. I will abandon my own calculations and awat L-M's addition of FR as a proper variable like everything else. Pete

That's out of date. The current supported version is 4.974. Please update. It will be fine IF you use Joy Letters. FSUIPC then assigns by letter instead of the Windows-assigned numbers (0, 1, 2 in your case). There's a chapter on this in the User Guide. Easiest thing to do is simply find this in the INI: [JoyNames] AutoAssignLetters=No and change the "No" to "Yes" before you next run FSX and most certainly before you disconnect and reconnect things. That will use letters A, B and C. If you want more meaningful letters, like R, Y and Q you'd need to do it manually instead, as described in the manual. Pete

I cannot debug FSXWX, sorry. You must send such crash data to its author. If P3D is crashing then there should be a P3D crash log in the Event viewer. it is that I need to see, Okay. So not a corrupt weather file then. Does FSXWX use FSUIPC for weather? I don't know it at all. But everything you've now said points to FSXWX as the culprit, not FSUIPC. Pete

Yes, seems it is okay for most. But I do see the 1/3rd value with 4.1. If it were okay with 4.2 but not 4.1 I'd just check "why" with L-M and merely disable the PDK use before 4.2. But it seems it is more complicated than that. Anyway, in the next interim update for FSUIPC5 I have SimConnect frame events used, but only to get the Frame Rate, and the PDK used for all the other actions FSUIPC needs to do per frame. I have asked L-M for either a PDK facility to get the Frame Rate, or, more consistently with other data, make it a regular Sim Var. Pete

The log indicates that it is definitely a corrupted weather file. Those cause SimConnect to crash when FSUIPC starts requesting weather information. You can test this for yourself by adding NoWeatherAtAll=Yes to the [General] section of the FSUIPC5.INI file. You've obtained the Windows crash data but not shown the details! You do realise these might be useful, in particular naming the particular module (DLL) which crashed? Please don't keep these things to yourself. What about all the other .wx files? Which wxstationlist.bin file did you delete? It needs to be the one in the same folder as your current Prepar3D.cfg file (users -> your name -> AppData -> Roaming -> LM -> P3D4). Even more pointing towards the weather data, because FSUIPC is doing very little else for you -- just receiving data from SimConnect so it can support the application interface. Pete

I can get your result, the PDK computed frame rate 1/3rd of the correct one, but only with P3D4.1. Not at all with 4.2. Can you double check the P3D version, that it is 4.2.21, please? It is a puzzle nonetheless, but easier for me to deal with efficiently if I know it's a problem only with 4.1. Pete

I'm afraid I don't know that. Perhaps you need to post your settings (the FSUIPC INI file in the sim's Modules folder), the I can see what you are doing. Does the Quadrant have buttons pressed when you pull back, and if so are you using those, or the axis? Please do make sure you are using an up-to-date supported version of FSUIPC. Pete

It's the subject of a complete Chapter in the FSUIPC User Guide, the one entitled Keeping track of multiple control devices ("Joy Letters") It's a way for FSUIPC to keep trak of the Windows-assigned joystick numbers so the assignments don't change when Windos changes the assigned numbers for any of a number of reasons. It is pretty important when you have multiple controllers installed and assigned in FSUIPC. Well, if they are working with your FSUIPC assignments and calibrations in default aircraft, that is really all FSUIPC can do for you. It knows nothing special about aircraft which do their own thing like the PMDG ones. most folks say thay have success provided they don't assign "Direct to FSUIPC Calibration" but to the FS Axis controls instead, and, for most axes, don't calibrate. i think this is because PMDG read the values directly from the main inputs, not from the values injected into the Sim. I assume you are only talking about axis assignments, not buttons as well? You seem to imply that. I don't actually have any or use PMDG aircraft, so you might be better off checking on thePMDG forums for help. All I can really say is that if FSUIPC is doing its job for the default aircraft,, thaen it is performaing correctly. [LATER] One other thing. It occurred to me that you may have been using Profiles before for the PMDG aircraft? It might be that you are using aircraft names which have been changed in the newer versions of those aircraft. Since you've not provided any FSUIPC INI file for checking you settings, I can't really comment in detail. Pete

I'm pleased it was relatively easy. Pete

that seems to conflict with this: Which is true? Is the FSUIPC5 installation on the same PC as the FSUIPC4 one? Are you using Joy Letters? Check the INI file -- maybe the devices have been interchanged? Also, when you say something is "not functioning" you need to differentiate between "not detected in the assignments tab" and "not acting on the aircraft as i would expect (or not at all). Pete

As Thomas says, you would need simply to buy the 33 licences. Possibly SimMarket would consider a "bulk deal". You'd have to contact them about that. Unfortunately I don't think there's an email address you can use. Normally the way to talk to someone is to open an account and post a problem report or ticket on it. Pete

Ouch! I hope you ran the Sim between those two actions! The change to the INI file will re-do all your assignments to use the letters. THEN you can change joystick connections When you use Joystick Letters then letters are used for ALL joysticks. Otherwise your #1 for your "original controller" could be re-assigned by Windows to another device! The whole point of using the letters is so that FSUIPC can keep track of the devices should the nmumbers change, as they will if you move them or sometimes boot without them -- or if you make substantail changes to Windows, like a significant update. All you needed to do was set that Auto parameter to Yes and run the Sim! FSUIPC would automatically assign the letters and re-do all your assignments to match, a one-off exercise done automatically on yor behalf. That has now happened but, because you changed the connections in between, the devices are probably not the correct way round! So you need to edit the [JoyNames] section in the INI and change the letters there to match the correct devices. Pete

Several points there: 1. No way does TrackIR and FSUIPC have anything to do with each other. They are completely independent. 2. FSUIPC cannot possibly "kill" any hardware. Apart from an initial scan (reading data) to see what devices there are, and possible repeated scans if you enter the Assignments tabs, it does touch any hardware at all until you assign any in the FSUIPC Options. 3. FSUIPC most certinly cannot stop anything working in Windows. It simply has no preivileges to do so. It is not a driver or running at any low levels at all. Even the scanning it does initially only reads files (the Registry only) and the IDs supplied by each registered joystick device. 4. After P3D has closed FSUIPC is not even there, and it most certainly makes no changes to anything outside of its own foder, where it writes the FSUIPC5.LOG, FSUIPC5.Joyscan.csv and FSUIPC5.INI files. So, I'm sorry, but you need to look elsewhere to resolve your problems. Pete

I'm not sure how you do that, but I know it is a regular needed thing to do. I don't have any firewalls between the 8 PCs involved in my Cockpit setup. I have too many needs for inter-PC connections. Googling on the subject finds this answer straight-away. (You should try internet searching, it helps me quite a lot): Add Firewall Program Exception Choose Control Panel from the Windows Start menu. ... Beneath Manage security settings for, select Windows Firewall. ... Determine the status of the Windows Firewall. ... Open the Exceptions tab and click the Add Program button. The program you'd need to allow access for is presumably P3D, though logically it would seem to be WideClient.exe -- except that if you already use that connecting to FSX-SE it should be there already, if needed. BTW Whenever you do want to report a problem with WideFS, you need to remember that there are two ends to the connection. I would need to see not only the WideClient.LOG but also the WideServer.LOG, which you'd find in the Modules folder next to the FSUIPC one. Pete

The file only changes when you add or update airports. So why not process it once yourself and do what you wish with the data? Pete P.S. I can't really believe it takes as long as 10 seconds to load in any case. And once it is loaded once it will be cached for quite a while. I have over 600 scenery layers and the data tends to be more extensive, but even Makerunways only takes about 20 seconds when generating all the files, and there's a lot of those! If you are processing whilst you load, don't! Load it then process in memory.