Pete Dowson

Why do you think that's drastic? Just uninstall it using the Windows Programs & Features section of the Control Panel, then re-run the client's .msi file (not the whole setup). Takes but a few minutes. It's the same as for minor updates! (I assume you've fully updated your P3D? If not, do so! It is important!) The log you posted is a continuation log, so it is missing important information. Please do NOT press "new log"! Apart from that it shows that P3D is not recognising the 1, 2, 3 or 4 keypresses even though they are being passed on. There's definitely something wrong there. But as I am missing a lot of information I can't really say much more from it. Pete

Are you testing on the ground? Don't. The sim tends to regard being on the ground as "landed" and if you engage anyting near the "arm" position is will deploy fully. It sounds ike you selected REV after calibrating. Don't. Options like that need selecting before calibration. Press the "reset" buton for the calibration to remove it, then select SET, the REV, then calibrate. Pete

5.103j comes under the heading relating it to Prepar3D version 4, the new 64 bit version. FSUIPC5 is a new payware version on;y for that Sim. Any chance of seeing the Log and CSV files for the working install now, please,as requested? I'm pretty sure it was the change I put to to elimiate scanning of thay keyboard device. it's the first time i've seen a device reported with the UsegePage at highe as 65281 and this through my calculations off. At least that's what I think was happening, but i always like to check these things. Pete

As requested, could you provide the log and CSV files for that please. I need to see whay it works so I can understand it fully. It is still there! Look again. It is clear, in the Update Modules thread (where else?) in the section clearly headed "FSUIPC version 4.969d only, for those with 4.969 already installed" Please do look. And, as I advised, always look there first BEFORE posting support questions. Pete

No. ActiveSky doesn't spply any. It would be those loaded initially by the sim, beofre ActiveSky starts control. Have you an FSUIPC log related to this, so I can see if it chaned anything? To prove whether it is weather-related or not, you could try adding NoWeatherAtAll=Yes to the [General] section of the FSUIPC5.INI file. That stops it asking anything from P3D about weather. The other thing I've only just noticed is that you are loading the PMDG 737NG. If that isn't the very latest update for that add-on it could well be the problem. Can you look for an update? Pete

It was FSUIPC 4.969d and that update was released some time ago No point in installing 4.969d now! Please use the FSUIPC4969g versdion I just provided a link to!! Pete

Please see my previous message, crossing with your last. Pete

Still not with 4.969d though, as I suggested! Never mind. I've made a small improvement to the scanning to try to avoid this specific problem. It might be tidier to clear up the bad entries in the Register, but please try this version to see if it helps. Same files again please, whether it is successful or not. Hopefully it will save such messing. FSUIPC4969g.zip Pete

Further to my last result, I think the cuprit might be this device: 188 Usage=4, UsagePage=65281, =Game Controller 188 Product= HP Wireless Keyboard Kit 188 Manufacturer= Lite-On Technology Corp. 188 Vendor=04CA, Product=008D (Version 0.97) It identifies itself as a "Game Controller", so is part of FSUIPC's scan. But it's registry entries have the duplicate GUIDs attached. Is this a device you actually do have attached? Pete

The JoyScan file was very useful, thank you. But I think I need to see the same debug log AND the Joyscan file when each of the two devices are connected on their own. There's something odd in the Registry, but I cannot see why that wouldn't affect them singly as well. The Eclipse Yoke's GUID is duplicated one one other device and the Saitek's GUID is duplicated 4 times! The registry appears rather couupt in that regard. GUID's are supposed to always be unique. that's their whole point, their only purpose. I suspect the answer will be registry editing, but I'll come to that after looking at the individual results. Pete

The console is just a copy of the log file. No need ever to grab that as well! You've still not supplied the most important file (and probably the smallest!), FSUIPC4.JoyScan.csv. Could you download the latest update and try that please: 4.969d from the Download Links subforum. It is always best to look there before reporting a problem, in case it has been resolved. Pete

As documented clearly, the ONLY thing going on the client is wideclient.exe. There's no "install" as such, just copy one file into a folder of your choice! Well, the Client is not receiving broadcasts from the Server, so something is wrong there. Try following the directions to add parameters to the Wideclient.INI file. Pete

The client doesn't have a registration. Only the server. You can have as many client PCs as you want. And what does the Server say? There are always two ends to a network connection. Show me the WideServer.LOG from the Modules folder in P3D, and the WideClient.LOG file from the folder on the Client in which you placed WideClient. The most usual problem is that you have the two PCs in a different Windows workgroup. if that is the case then one cannot receive broadcasts from the other, so if you are running WideClient with default settings it will not see the Server. You can either rename the workgroup in one PC to match the other, or simply provide the IP address and protocol in the Wideclient.INI file. All this is explained in the first few paragraphs of the "configure your network" section of the WideFS user guide (page 4). Oh dear, you ARE mixed up, aren't you! Why is that? WideFS consists of a SERVER which is part of FSUIPC. FSUIPC only runs inside the sim. The other part is the CLIENT, which runs on one or more clients. The SERVER serves the CLIENTs, by feeding it data and acting on stuff it sends back. That's the whole idea of networks, to exchange or share information between two or more machines. I really cannot believe you have read any of the WideFS User Guide. On page 3 there are sections clearly marked "On the Flight Simulator PC [FAX or later]" and "On each client PC". Please do make use of the documentation provided! That is what it is for. Pete

Very strange. That sounds like some sort of P3D corruption then. It might be worthwhile reinstalling the P3D client. And can you show me the log as I requested TWICE before, please? i.e. Please enable the Logging tab options for button/keys logging and also Event logging 9not axes), then try again with those. Keep the session brief, just those tests, then show me the log file which you will find in the P3D modules folder. Pete

I have moved your support question to the Support Forum. Please do not post such in reference subforum as they are likely to be missed. Do you mean that when you go to the FSUIPC axis assignments tab the Yoke is seen without you moving it? If so, all that is happening is that it is jittering -- i.e. constantly providing slightly changing values. It probably needs a clean or new potentiometers. To deal with this is FSUIPC just use the "ignore" button, as documented, for any axis you don't want to configure at that time. This is only a temprary state and is cleared next time yo visit the options, or just by using the "clear" button. Once ignored you can simply use the "rescan" button to receice another axis for assignment. Please show me the [JoyNames] section in the FSUIPC4.INI file. I must say, this part of your LOG looks rather odd: 187 Device acquired for use: 187 Joystick ID = 1 (Registry okay) 187 1=CH ECLIPSE YOKE 187 1.GUID={6F807CF0-680B-11E7-8001-444553540000} 203 Device acquired for use: 203 Joystick ID = 1 (Registry okay) 203 1= 203 1.GUID={6F807CF0-680B-11E7-8001-444553540000} Omitting the name, getting the same JoyStick ID and GUID twice, and not including the clearly identified other device, makes no sense. Next time could you post or attach the Log file as it is, without the extract and odd formatting, please? I can get a lot more information about what is going on by seeing the FSUIPC4.JoyScan.csv file, which is specifically produced for this sort of problem. A log with some extra logging may also be needed. To get this add these lines to the [General] section in the FSUIPC4.INI file: Debug=Please LogExtras=x200000 Pete

I've tested Shift+E, with 1,2,3 or 4 pressed afterwards, on an aircraft with 4 door controls (1=pax front+rear, 2=service front+rear, 3=cargo rear, 4=cargo front) and it works fine. Shift+P with a subsequent 1 or 2 also works fine. I am using the latest FSUIPC interim update, of course, 4.969d, (see the Download Links subforum for updates) but there's been no change. If you like you could also try 4.969f, as yet unreleased. Here's a link: FSUIPC4969f.zip But I don't think any version will make a difference. I'd need to see the log. Pete

Do you press the keys together, or one after the other? Have you changed aircraft? Is it the same with all aircraft? Have you changed the P3D3 version? Which one are you using (what's the full version number 3.4.?.?). Check the parameter entered in "time to select" in the FSUIPC Miscellaneous tab. Please enable the Logging tab options for button/keys logging and also Event logging 9not axes), then try again with those. Keep the session brief, just those tests, then show me the log file which you will find in the P3D modules folder. Incidentally, what was your previous version of FSUIPC? Pete

A brief look at the Lua file involved shows "file" being set as follows: file = io.open("e:\Temp\Flusis\B777InitialFuelQty.txt", "r") So a value of "nil" just means the file.open attempt failed. You should really check for such an error in your script. The likely reason it failed is that within strings in Lua the \ character is an escape character, allowing all sorts of controls to be added, like \n for "newline2. To get a true \ you must use \\, so: file = io.open("e:\\Temp\\Flusis\\B777InitialFuelQty.txt", "r") Check, of course, that the file is actually there! Pete

The problem is almost certainly caused by a corrupt weather file. The reason it occurs with FSUIPC running is that it reads the weather regularly from SimConnect so it can properly populate the data areas it provides to client applications. The log confirms this, as the crash occurs immediately after the weather reading is enabled. It isn't FSUIPC itself crashing, but SimConnect or WEATHER.DLL, when it tries to decode the corrupted file. Unfortunately all the weather files are not only in binary but also unchecked --there is no check mechanism implemented for them. Try deleting the wxstationlist.bin file, which is in the same folder as your sim's CFG file (users AppData\Roaming etc). Also deleting or move to another place the .wx files from your sim's documents folder. Those files contain the weather loaded when a flight loads. Without them you'll just get default weather until you or a weather program changes it. Pete

Lua plug-ins run in their own thread. they cannot be "interfered" with. If operating another control on the aircraft affects the result of the Lua script then it is something else going on in the add-on aircraft. If the throttle data being sent by the Lua script is not being applied, or is being applied but then changed, then something else is doing thst -- something else is dealing with throttles. I'd normally suspect that other assignments to the throttles are responsible -- either in the Sim or in FSUIPC assignments. Really that's the only part of your post I can comment on. I've no idea about anything in that add-on aircraft. For that you need to post in a forum which deals with that add-on and see if others have a clue. But to help you investigate what is going on there are plenty of Logging options provided in FSUIPC. Have you thought of using any of those? Pete

The update is now actually 5.103j instead of 5.103g as stated. If nothing is deleting the files, then they are there. FSUIPC does go in a cycle, by default 10 saves, and replaces the oldest one each time it saves a new one. But you'd still get the last 10 (or however many you set). Of course, if you set a cycle of only one and P3D crashed when that was being replaced, then ... You can also try using the "alsosave" option, which saves just one file, always with the same name, and a different interval. Incidentally, I find it very strange you'd buy something as complex and feature rich as FSUIPC just for the autosave option, which is a minute part of it. I'm sure there are still simpler programs around which provide that facility maybe even freeware. Pete

FSUIPC does not delete them. In fact if P3D crashes, it cannot delete them. It does not actually write them in the first place -- P3D does. FSUIPC merely asks it to save the flight, just a couple of lines of code effectively. It is the same as yousaving flights -- do those all disappear too? Of course, P3D cannot delete them eith if it crashed. Nothing part of P3D can. If they are really being deleted you have some other third party program on your system being malicious. Ah. You are using a PMDG aircraft. PMDG also save many files, and most go into their own folders. do they disappear too? You are getting serious pauses on every autosave, caused by PMDG saves. With PMSG aircraft it is recommended NOT to use any type of Autosave because of these pauses. However, if you insist then you should at least use the current latest interim FSUIPC release -- 5.103g -- available in the Download Links subforum. That allows a much longer Simconnect timeout when it sees a flight being saved. This should stop spme pf the symptoms shown in your log, especially the looping at the end of the log showing repeated failed attempts to reconnect to SimConnect. (It isn't a crash, by the way). 5.104 should have been released today, but family matters came up and delayed this. Look out for that next Tuesday (I am away for the weekend, Fri to Mon inclusive). Pete

Application programs have not needed keys for many years. The FSUIPC.KEY file is only for your user registrations, for FSUIPC and WIDEFS.

To make sure it isn't to do with FSUIPC or WideFS, could you add an event.offset for something which is known to change redularly, and log that so you can see it still running? For example, the time of dat "second" value, one byte at 023A. If that is okay it is down to the PMDG aircraft I think. I'm just asking because I was excited to see this, yet I have no idea what to make of whether it is applicable or not. I would be certainly willing to investigate incorporating it if you think it is worthwhile. Yes, I looked at that. I even downloaded the source and tried compiling it (I need compiled modules fitting into the rst of my Lua interpreter). But there appear to be too many things missing which I couldn't find anywhere in the source provided. I assume it must be possible. i tried to work out what the missing bits should look like, but that's where I got lost in the very complex convoluted and uncommented code. Pete

In my case I had no PMDG 777 previously installed, but it could well apply to the PMDG 747, which was just "repaired" by the latest download. Pete