Pete Dowson

1. This section of the Support Forum is for FSUIPC7 and MSFS. You should have posted in the main Forum. 2. The "G" key is the default one in P3D. What does FSUIPC have to do with it? 3. I'm pretty sure you must assign these sorts of things in ProSim itself in any case, otherwise it probably overrides your actions. That sounds like exactly what is happening. I use ProSim737 too, and everythng is assigned in ProSim. It needs to have total control to work as a complete system. Pete

Log files are text files. They do ZIP up really small. Please do that in future. And the reason your log is bigger that it needs to be is that you have enabled additional logging options. There's no need at all to enable button and axis logging. those are only used for limited period when looking for problems with buttons or axes! It is NOT an error. It simply means that FSX crashed the last time and Windows thinks it might be due to FSUIPC! I already explained that. By answering NO every time FSUIPC is never getting started, let along crashing. You need to answer YES, as I also said, and then, if FSX crshes, show me the Log up to that point AND the Windows Event Viewer details for that crash. If you don't do these things there's no way I can help you! Of course it doesn't, as you told Windows not to allow it to be loaded! Unless you let the error occur you won't get any error details logged. You are just getting the warning and telling Windows to avoid loading FSUIPC. That helps no one. Well you've been saying you been deleting things all over the place. FSUIPC won't be deleting anything, and in any case you aren't even allowing it to run. Error 2 simply means "file not found". No, because FSUIPC doesn't care whether you run Linda or not. Where do you see that? The log you are posting is from 5 days ago. You've not tried to run FSUIPC since. The log you posted, dated the 17th, shows a perfect session with FSX and FSUIPC terminating normally. There is nothing wrong, except that you have lots of logging enabled which I don't need to see and I don't suppose you do either. Please do read what I'm saying. If you think you have a problem with FSUIPC, let it run, then show me the details. It is isn't allowed to run it tells us nothing at all. Pete

If no new log is being produced it just means Windows determined that the last time FSX crashed, it thought FSUIPC was the culprit. FSUIPC isn't actually crashing this time, otherwise a new log would be produced. Did you try saying "Yes" instead of "No"? What happens when FSX crashes for any reason, FSUIPC still has threads running which try to tidy up. It means that it is seen as the reason or the crash when it is not. In the case you display here, the culprit shown in the Event log is: which is the part of FSX handling AI Traffic. This suggests there may be a corrupt traffic file, or more likely a corrupt AI aircraft texture. If FSUIPC crashes, the log so far is important, and needs to be shown to the end -- the last thing it did would be a prime clue as to the cause, so truncating it as you have done tells us little. If the file is large (which it shouldn't be if you've not enabled extra logging options) then you can ZIP it up and attach it. So, your power outage is the original cause of the crash? But there was no FSUIPC log? I think you need to assume the crash was because of that power outage, not FSUIPC, and let Windows continue loading it. Pete

Sorry, but with no assignment FSUIPC cannot possibly be doing this is either V4 or V5. So anything you have happening with those buttons is being done elsewhere. presumably with that configurator tool. The only button assignment you can really use for Reverse is to Throttle1 Decr and Throttle2 Decr. Or keypress F2 for all engines. Otherwise you could try using a reverse zone on the throttle axes, though I don't think that works on PMDG Boeings. Why haven't you activated the event logging as Johnrequested, and supplied the resulting logs? No, sorry, I think it seems that it is you who has an issue. Perhaps you can describe a just a few of those million attempts? Maybe we can tell you where you are going wrong? And please do explain what you are attempting with these button assignments: 2=PA,11,Cx050078E7,x32 -{offset byte setbits, offset 78E7}- 3=PA,12,Cx050078E7,x64 -{offset byte setbits, offset 78E7}- 4=PA,13,Cx050078E7,x80 -{offset byte setbits, offset 78E7}- which, even if offset 78E7 was doing anything, don't appear to do much constructive as they just set, not change or clear, bits. Pete

Well, it works for me, every time. I develop all my plug-ins this way. Are you sure it isn't related to the MSFS window problems? I only use P3D5. I'm sure john can check it, bit you should show the relevant logs. Pete

No. The only buttons you have assigned are these: [Buttons] ButtonRepeat=20,10 PollInterval=25 2=PA,11,Cx050078E7,x32 -{offset byte setbits, offset 78E7}- 3=PA,12,Cx050078E7,x64 -{offset byte setbits, offset 78E7}- 4=PA,13,Cx050078E7,x80 -{offset byte setbits, offset 78E7}- 5=RA,3,C65615,0 -{ELEV_TRIM_UP}- 6=RA,2,C65607,0 -{ELEV_TRIM_DN}- 7=PA,5,C65758,0 -{FLAPS_INCR}- 8=PA,4,C65759,0 -{FLAPS_DECR}- I don't know what offset 78E7 is being used for in your system, but apart from those three offset changes (which don't appear to make any sense), the Trim and the Flaps, there are no others assigned in either INI file, so probably you only assigned in that Honeycomb tool. You need always to be very wary of using more than one program for assignments. It is is easy to gey duplicate and therefore conflicting assignments, and it is also easy to confuse which is doing what. Just as with P3D v FSUIPC assignments where we strongly recommend only using one for assignments. Pete

Yes, as described (though admittedly not very clearly) in the section Macro Control References in the FSUIPC Advanced User's guide (about page 37). CMm:n,p C = Control (instead of eg K for Keypress) M = Macro m = file number in the [Macros] list of FSUIPC INI n = entry number in the file p = parameter Pete

None of those add-ons are relevant.I think you are just not running it ' as administrator' as in the instructions. Otherwise there's probably a corruption in your Scenery.cfg file. You'll need to show your Scenery.cfg and the generated Runways.txt file if you want more help. Pete

You might be able to use the GPSout data provided by FSUIPC. it can send it to any serial port -- for USB connected ports you would need to figure out the correct port name, but for simple Serial COM ports it's only the COM number (COM1 etc) needed, and your selection of NMEA messages (or other supported ones) needed for the data you need. Pete

It isn't a normal encoder then. I use encoders, connected via Leo Bodnar USB boards, and they all click on the change -- press/release alternately. But if there is a press and a release for every click, your are actually getting twice the click speed, so it should really have been no problem -- seems it's the 60-70 mSecs the switch takes to release which is the limitation. As you say, a switch design weakness. If you don't mind a slight irregularity in trying to set things, maybe do the action twice on the press and once on the release in order to get a more regular interval. Pete

Yes, they are okay, thank you. Interestingly they both show the same results, with the menu etc being detected and resolved, so the problem must be within the Lua interpreter code itself. I'll look into that tomorrow. I'll need to set up a specific test here. Pete

I've tested event.textmenu here on 6.1.1 with the capturing of SimConnect message windows and it works fine. Unfortunately I don't appear to have anything using the SimConnect menu facility on my test PC, but I can set something up tomorrow. Meanwhile could you please do two comparable logs, one for 6.0.13 or whichever it is you have success with, and one with 6.1.1, but first edit your FSUIPC6.INI file as follows: In the [General] section add Debug=Please TestOptions=x8000 Run your test exactly the same one each and show me the logs please. I'll look at this later tomorrow -- retiring for the evening now. Oh, please also say exactly what menus you are checking with. Thanks, Pete

That's not true for a rotary encoder. Each click is a change -- i.e a press or a release, alternately. So you need to assign the same thing to both press and release. Pete

I don't see any likely either. Are you saying that for non-PMDG aircraft that program is detecting these okay? Don't the same work for PMDG aircraft? I'm pretty sure their Boeings use the underlying simulator code for the NAV radio simulation and signals received from them, so that should equally cover LOC and GS signals which are indicated in regular FSUIPC offsets. If not then I can only suggest you ask over in the PMDG Forums. Pete

The .key file is a .key file. It contains only text and can be edited in Notepad, but it is just not recognised by Windows as a TXT file. Similarly INI and CFG files are text files but are categorised as configuration files. Note that when you register ALL THREE PARTS (Name, Email and Key) must be exact. You must be making a mistake. Pete

I've never had to do that. I thought you had to nominate the program by EXE name? Just as a test, can you try with the firewalls disabled at both ends? Pete

John will need to see the FSUIPC7.LOG created up to the point of the crash, and also probably the FSUIPC7.INI file so he can see your settings. A description of what you and MSFS were doing at the time would be useful too, please. Pete

That's very good of you. Yes please. Both of us Dowsons have a lot on our plates right now, and this one is supposed to be "retired" 😉 Pete (the elder Dowson).

Sorry, I'm confused. When you said: did you mean your "previous version" also being an FSUIPC6? Are you saying you just updated, for example from 6.1.0 to 6.1.1? If so, then I misunderstood. I thought you meant from FSUIPC5 to FSUIPC6. According to your list of .mcro files, you've actually of got 4. Of these: [MacroFiles] 1=6 DHC 2=737 3=400 Q 4=9 CRJ 5=7 crj 6=DHC 6 you are missing 7 crj and DHC 6. You don't have any assignments to 7 crj, but you do have just one to DHC 6 (Button 3 on Joy #1. However, I understand that isn't the problem. You appear to be saying that none of the macro files are providing entries in the Buttons, Keys or Axes assignments drop downs. Is that correct? And they were listed with your previous version of FSUIPC? Belatedly, I now see that the INI file you posted is from FSUIPC 6.008. Why haven.t you provided the INI file from your current 6.110 version? I need to see the current one, please. Pete

So your macro files are these: [MacroFiles] 1=6 DHC 2=737 3=400 Q 4=9 CRJ 5=7 crj 6=DHC 6 Did you copy your FSUIPC INI file over from your previous version? Could that list possibly have been carried over from the last installation? That would be expected and reasonable. But did you also move those 6 .mcro files over as well? They need to be in the same folder. You have assignments to macros in several different profile assignments. If not all, which ones are you saying aren't now recognised? Pete

You need to show us your FSUIPC6.INI file as otherwise we have no information with which to assist! Pete P.S. I moved your question to the correct place, the Support Forum. You posted in a programming sub-forum.

The log simply shows the Client requesting data from the Server (or at least, that IP address you provided), and getting nothing. The server is receiving a connection but no data with it. So, there's a firewall type block at one end or the other. That won't work. The ProtocolPreferred parameter is for those clients which connect by receiving a broadcast from the Server. That's the default method -- leaving both Protocol and Server details out of the WideClient.INI, so the client links to whatever Server is running. The only requirement for the Broadcast method to work is that both PCs ar in the same WorkGroup (as well as no Firewall blockage). The firewall blockage (from Windows Defender possibly) can be in Client or Server. It isn't possible to tell from the logs. Pete

ProSim has a SimConnect mode which, when selected, means it is not using FSUIPC to control MSFS. I think that mode is recommended over the older FSUIPC mode, which is still supported. However, I have read some folks find FSUIPC mode still better than its own direct SimConnect mode. Presumably still some work to do on their SimConnect code. When SimConnect is selected in ProSim I don't think FSUIPC is used at all. You are supposed to do all your assignments and calibrations in ProSim in either case. I use ProSim, but only with P3D5. No way is MSFS yet ready for use in a full blown 737NG cockpit. Pete

I don't really know, but I would have thought that MSFS sensitivity settings for specific hardware controls should (would) not be operative if MSFS was told not to use those controls? However, I don't know MSFS very well and have never played with its sensitivities. My controls (I only fly the Just Flight Piper Arrow) are direct through FSUIPC only -- I don't have a choice as my control devices aren't ones recognised by MSFS, being part of a Piper Arrow cockpit ("GA28R") built many years ago by Aerosoft Australia (no relation to the German one). Since I'm not sure and I know John is very busy at present with development work, why not check for yourself whether the MSFS sensitivities do anything? With FSUIPC the main way has always been, and remains, to flatten the response slope in the centre. This results in steeper extremes since it is normally still important to be able to span the complete movement of the control surfaces. You can "fiddle" the range actually used by FSUIPC by changing the calibration values in the settings (the INI file). For example, changing this: Aileron=-16384,-512,512,16383 to this: Aileron=-32768,-512,512,32767 goes to the extreme of pretending that the aileron axis has fully twice the range it really has, so reducing the amount you can control to half what is possible. This would mean that it needs twice the movement to do the same as before. But it does also mean your maximum movement is limited to half what it was. This is why it is generally better to use the slopes., though I suppose a combination of the two techniques could be used wisely, just not so extremely. It might also be a good idea, before you start, to check whether Windows' own calibration, in its game controllers, does anything for you. That should really have been done to start with, if not automatically by installation. Pete

They are set to individual taste, and often differently for different aircraft -- especially aircraft of different types or persuasions. For example fighters and stunt jeys need sensitive fast response controls whereas large heavy multi-engined turboprops want a slower more lumbering feel. So adjust accordingly and go by results. They most certainly shouldn't as you shouldn't have them enabled in MSFS if assigning in FSUIPC. However, FSUIPC doesn't support Force Feedback, so I'm not sure how you are managing that aspect. Pete