Pete Dowson

AS requested above, please try setting these parameters in the [General] section of the FSUIPC4.INI file: Debug=Please LogExtras=5 TimeForLuaClosing=0 (If the last is already there, change it from =1 or =2 to =0). I'd like to see the log -- from a good run if all good. From a run which crashes on exit if one does. Also please state version of Windows and whether you use LINDA. Oh, you could also try assigning a key press combination to "LuaKillAll" and using it before closing P3D. Thanks, Pete

As I said, there's no difference in WideFS. Without seeing the relevant logs, as IO mentioned, I can't really start guessing. Sorry. Pete

There's no private information in a crash log. SimConnect will already have approved of that version, that's why. There's an entry in the [Trusted] section of the FSX.CFG file -- take a look. The problem is almost certainly the Trust check timing error in SimConnect. It has been happening since the very first release of FSX, and The FSX team did try to fix it. By SP2/Accel they did manage to reduce it's likelihood, but never actually solved the issue -- parts were in Windows itself, outside their control. How many times did you try reloading with the later version? And you've not even said what Windows version you are using. Please do read the thread in the FAQ subforum. There's more information there and lots of suggestions. Pete

As you can clearly see from the log, FSUIPC is doing exactly the same, correct, thing, with either button: PgUp: 112165 Button changed: bRef=0, Joy=2, Btn=4, Pressed 112165 [Buttons] 36=R2,4,K33,8 112165 Repeating flag set: bRef=0, Joy=2, Btn=4 (RepeatDelayCtr=1) 112165 SendKeyToFS(00000021=[PgUp], KEYDOWN) ctr=0 112181 Sending WM_KEYDOWN, Key=33 (Scan code 73), Ctr=1 That is the keypress being sent. And here it is detected by FSUIPC: 112196 KEYDOWN: VK=33, Waiting=0, Repeat=N, Shifts=0 112196 .. Key not programmed -- passed on to FS PgDn: 388115 Button changed: bRef=0, Joy=2, Btn=5, Pressed 388115 [Buttons] 37=R2,5,K34,8 388115 Repeating flag set: bRef=0, Joy=2, Btn=5 (RepeatDelayCtr=1) 388115 SendKeyToFS(00000022=[PgDn], KEYDOWN) ctr=0 388115 Sending WM_KEYDOWN, Key=34 (Scan code 81), Ctr=1 388146 KEYDOWN: VK=34, Waiting=0, Repeat=N, Shifts=0 388146 .. Key not programmed -- passed on to FS The actions of FSUIPC are indistinguishable apart from which ke it is which gets sent. As I said, FSUIPC doesn't care at all what keypress it is, it makes no distinction whatsoever. So you have something else intercepting and using the PgUp keypress when it arrives this way. You need to look for that. Regards Pete

Not the same at all. Two major differences to the above report: 1. You are using FSX 2. His problem was with 4.959 as well. I need more information to help, please. Windows crash details, which Windows, the actual wording of the "warning", and whether it is consistent, even on further load attempts -- because really it sounds like the normal SimConnect problem with updated modules and its checks -- see the FAQ subforum thread "FSX fails to run after FSUIPC4 first installed". Pete

There's another long thread here dealing with the problems with the P3D 3.4 HotFix 2 release. Please see that. I'm working full time, with some volunteer testers, to try to work out why -- and I have asked L-M to be involved too. The differences between 4.948 and 4.959 are minimal as far as P3D is concerned. The main differences are additional facilities like the Traffic Limiter option. The changes where P3D are concerned are just to adjust hooks so that frictions tables and so on are still usable. These sorts of changes have been needed for every P3D version and every increment, even Beta versions. And there is no change whatsoever in anything to do with WideFS -- that's all completely separate code, only bound into FSUIPC for more efficiency and easier installation. Unfortunately I cannot reproduce the problems with P3D here on my Win7 based PC. In fact, so far no one who has the problem has reported Win7 -- all those we know are using Win10. Also most are also using LINDA or other add-ons involving Lua plug-ins with displays. So this is the area we are concentrating on. Without knowing more about your setup -- operating system, add-ons, and exact symptoms, I can't really help you much further, at least with FSUIPC+P3D. I strongly suggest you check that other thread for similarities and see the discussions there. On the WideFS side of things I would need to see your WideServer.LOG from the P3D modules folder, and the WideClient.LOG from the same folder as the WideClient you are using. Pete

Those two aircraft are very heavy on FS resources, and if you have enabled the facility for FSUIPC to expose their cockpit values via offsets, FSUIPC is also involved. But the data involved is only sent when it changes -- which for some values could be much more frequently than one second, and for others a lot less frequently. Some of the "normal" FS data FSUIPC provides is supplied at a maximum rate of once per second, But again, most stuff doesn't have a minimum time limit like that. Have you looked at the FSUIPC log, to see if there's anything there suggesting a problem, or some activity every second? Most of the time, when not servicing requests from applications and plug-ins, FSUIPC is doing nothnig but awaiting data arrival from SimConnect. AI Traffic tables in FSUIPC are maintained every 1 second, normally, as is the Weather data. But those should be the same irrespective of whether you are using those aircraft or not. However, you could try one of these FSUIPC4.INI settings to stop the weather reading: WeatherReadFactor=0 or NoWeatherAtAll=Yes and of course you can turn traffic off completely, to see if that does it. But I really can't think of anything involving both those aircraft AND FSUIPC except that data reading already mentioned -- unless of course you have some other add-on which uses FSUIPC more when those aircraft are running -- perhaps a Lua plug-in? If you have other addons you might need to go through a process of elimination. Pete

They all need SimConnect, though maybe AS2012 was the last to also support FS9, in which case you can probably force it to use FSUIPC / WideFS instead. But AS16 is so superior, such a vast improvement, that it would be a mistake to go backwards. Why would you want to run the weather program on a separate PC to FS in any case? It really doesn't take much away from FS's performance -- barely measurable. If weather updates are causing hesitations or stutters on your FS then they will do no matter how they originate. The data has to be fed into FS one way or another, and it's the resulting computations and graphics work, anyway, which take the computing power in FS. Just keep things simpler, like the maximum number of cloud layers and the distance away from the aircraft things are drawn. Pete

Sorry, I'm confused. What did you assign the button to, exactly? What did you expect to happen? Is ECZA's use of PageUp intended, or is this the problem? I'm afraid that I'm not really seeing any explanation about what you think is wrong. FSUIPC cannot and does not distinguish between key presses being assigned. It just sends them when requested. If this is resulting in something unintended then something else is picking up that keypress. OR, perhaps, the button press is actually doing more than you intended. To find out more, please use FSUIPC's logging -- enable Button & Key logging and press your button. The log will then show what is occurring. Pete

This report seems to be another repeat of the majority of those posted by folks get the reload problem. I already have you recorded as one of the Win10 users with the same problem. I am in contact with L-M and hoping for some feedback there, but I also have two volunteer testers who have been tirelessly testing all sorts of things to isolate the causes. Perhaps you might become one of them? It is a non-flying task which I think is why most here have not volunteered. It's a matter of running with your normal add-ons, then closing, then starting again ... for any number of times, until you are happy that the problem is gone ... OR not! On the diagnostic side with your current result, did P3D suffer a crash on exit from the last run before you got the crash on load? Please check the Windows Event viewer and let me know. Then try setting these parameters in the [General] section of the FSUIPC4.INI file: Debug=Please LogExtras=5 TimeForLuaClosing=0 (If the last is already there, change it from =1 or =2 to =0). I'd like to see the log -- from a good run if all good. From a run which crashes on exit if one does. Thanks, Pete

Sorry, this is completely nonsense to me. What does it mean? Is the an actual control or keypress you need to assign? How do you get this "feeling"? Didn't you use FSUIPC's button logging to check? Did you actually assign that button in FSUIPC? I do not understand much of that log. What is it from? It is not from any of my software -- certainly not FSUIPC. Are you sure you are asking this on the right Forum? Seems to me you need to be on the VRS Superbug forum, if there is one (?). Pete

Well, at some time, on that system, you unplugged the devices and reconnected them, OR you updated Windows. Best to use the Joystick lettering option to be sure in the future. Pete

Sorry, but 4.959 IS the version updated for HF2. That's why I released it at the same time! They are fobbing you off. Check the FSUIPC4.LOG in the Modules folder. It should have everything checked okay, like this: 1545 ------------------------------------------------------------------- 1545 ------ Setting the hooks and direct calls into the simulator ------ 1545 --- CONTROLS timer memory location obtained ok 1545 --- SIM1 Frictions access gained 1545 --- FS Controls Table located ok 1545 --- Installed Mouse Macro hooks ok. 1545 --- Wind smoothing fix is installed 1545 --- SimConnect intercept for texts and menus installed ok 1545 --- All links okay (except older global weather setting method) 1545 ------------------------------------------------------------------- Pete

The controller ID nubers can change, and usually do, when you change systems, or unpug things and plug them in differently, or even change your version of Windows. Probably part of the duplication is from your old configuration. Yes -- a change in the joystick IDs. FSUIPC has a facility which uses Letters instead of the IDs and can then automatically track them -- there's a chapter about it in the User Guide. always enable that unless you only have one controller or never unplug them, change PCs or operating systems. Pete

I see you have no Rudder calibration. Oddly, too, you have some main controls not even assigned in FSUIPC even though you do have others. Are you by any chance using FS for assignment as well as FSUIPC. That will definitely cause problems. You should choose one or the other. The steering tiller in FSUIPC uses the rudder control and there is a cross-relationship with that assignment and calibration. I can't reproduce your problem here with FSX (I abandoned FS9 completely some years ago), but I think calibrating the rudder would help. You also need "auto-rudder" disabled in FS. Your axis assignments in FSUIPC are: [Axes] 0=0Z,256,D,3,0,0,0 RUDDER 1=0U,256,D,41,0,0,0 REVERSER1 2=0V,256,D,36,0,0,0 STEERING TILLER 3=2X,256,D,42,0,0,0 REVERSER2 4=2Y,256,D,22,0,0,0 SPOILERS 5=2Z,256,D,10,0,0,0 THROTTLE2 6=2R,256,D,9,0,0,0 THROTTLE1 7=2U,256,D,41,0,0,0 Another REVERSER1 (?) 8=2V,256,D,36,0,0,0 Another STEERING TILLER (?) Three comments about all that. First, I assume the duplication of two of the controls is deliberate, though having two REVERSER1s and only one REVERSER2 seems odd. Secondly you have no assignments for the main Yoke (elevator and ailerons) controls, which strongly suggests assignments to these in FS -- mixing assignment places is a really bad idea. (Or do you fly by keyboard?) Thirdly, when you assign "Direct to FSUIPC Calibration", you ARE supposed to calibrate. There's a good chance they will sometimes be unusable otherwise. Your calibrations are only for these axes: Spoilers=-11854,-7003,-512,16160Reverser1=-14624,5622/16Reverser2=-13056,7324/16SteeringTiller=-16127,512,1824,16288 The throttles and rudder are assigned "direct to calibration", but not calibrated! Pete

There have been threads in either the FSX or the P3D forum on AVSIM with help and explanations. Pete

FSUIPC merely shows what it sees coming from DirectInput. Maybe there's some jitter on one or the other and the input that gives is overriding the one you want to set? Try clearing the selection (there's a button top left somewhere) and see which axis pops up. If you can't then also use FSUIPC's calibration (because the aircraft doesn't like the way the controls then arrive, as with PMDG aircraft), then you'd need to try to properly calibrate in Windows. Pete

The calibration will be saved in your FSUIPC.INI file. It sounds like you have a corrupted one. Post it into a message here and I'll take a look. Pete

The latest full version, 4.959, handles P3D 3.4 .8, which is the latest version of P3D. It does say this clearly in the Changes notice included -- see item 26. Version 4.959 was released on the same day as 3.4.18, so the timing was perfect! Pete

Clicking on the Lua file does nothing!!! It's a script, which has to be loaded by FSUIPC and run inside the simulator. Clicking on files is NOT a way of doing everything in a computer! I'm afraid I cannot explain things any better than shown in the documentation. I have already suggested ways for you to make it run. If you cannot even put the Lua file into the Modules folder, and cannot assign a button or key in FSUIPC, then I don't think you can really use FSUIPC at all. How do you use the simulator? Surely you must have mastered some things to do with FS? If you think you can manage to find the FSUIPC options in the sim's Add-Ons menu, and then find the Buttons and Switches tab, try it. Try pressing a button, then try assigning to the control "Lua" followed by the name of that lua file in the drop down list. Then, press the OK button, and press the button you assigned. That will then run the Lua file. If you cannot do any of that then, I'm sorry, I really give up. Maybe someone else can help. Pete

Not that display, it's a sim function being used. There are solutions using Lua plug-ins to make other windows. Here's one example, which also shows frame rate and traffic count. It won't be transparent, only translucent: -- Update the display at 500 msec intervals (see event at end) function mytimer(time) fr = ipc.readUW(0x0274) if fr ~= 0 then fr = 32768/fr end fr = math.floor((fr * 10) + 0.5)/10 mem = ipc.readUD(0x024C) memmb = math.floor((mem/1024) + 0.5) traff = ipc.readUD(0x025C) ipc.display("Frame Rate " .. fr .. " fps\nVAS free " .. memmb .. " Mb\nTraffic " .. traff) end -- Adjust timing to taste: 500 = 1/2 second event.timer(500, "mytimer") You can undock it and move it to another screen, or run it on a client PC under WideFS. I have another version which also displays the maximum free memory block size, but that needs an interim FSUIPC update which isn't released yet. There are other solutions around, written by users. Take a look on the AVSIM forums for FSX or P3D. Pete

I asked gypsyczar to do this test. He's come back with a negative I'm afraid. As with everything about this problem, it is just too variable. What applies to one doesn't necessarily apply to another. Shame. I'm getting L-M involved with all the details I can supply. I doubt if much will change in P3D 3.4 though, but we can but hope for a solution. Maybe they'll be able to tell me what I'm doing wrong, if anything. So far it certainly looks related to other problems folks have reported to L-M, not concerning FSUIPC at all. Pete

Some ReadOnly offsets are actually protected from writing by FSUIPC -- but none of these are related to add-on dedicated locations. If there are any so marked for PM it just means that writing to them doesn't change anything in PM. Pete

NONE of the PM offsets are used if PM isn't running, except where individuals, like me (and soon you!), have re-used them for their own private purpose. Surely I've already said that? I don't know what you don't understand by "Yes you can" in answer to your question. The rest of my reply was by way of friendly explanation, not a cause for debate! ;-) Pete

It's FSUIPC4, not PCUIPC4, and I'm sorry, but as stated earlier, I don't know anything about Elite and have never written any software for their hardware. Pete