Pete Dowson

You are not looking then. The current Advanced User's guide, headed "(for FSUIPC4 Version 4.95, May 2016)" and which would have been installed automatically for you in your FSUIPC Documents folder. has it on page 7. Here's the extract: These details are also in the FSUIPC4 History document, on about page 4, under "Version 4.941 (July 2015)", which is when they were added. As you see, it can't be made to operate more frequently, only less. The reason is that it is actually quite a lot of activity Windows is asked to do, totting up all the free (unallocated) space, which may be fragmented at that time. De-fragmenting it takes time too. I did not want to risk compromising performance. If you have a good reason for recomputing free space more often, I will consider a lower minimum. Pete

Where did you look? Just search on "memory" or "OOM" in the FSUIPC4 Advanced User's guide. It's the second parameter described under Other general user options. Called "OOMcheckInterval" I think. Pete

Ah, that definitely sounds like something in Win10 specifically then. Does FSX-SE see the keys, in its assignments dialogue? If so I certainly don't understand how FSUIPC doesn't see them, because all Windows messages to FS pass through its main "FS98MAIN" window processing function which FSUIPC hooks. Pete

I cannot help. Sorry. What you are asking for is simply not a function of FSUIPC! It never has been! I might be able to advise better if I actually used anything by PMDG, but I don't. And I see nothing rude about advising you to seek help in the correct place. I don't know where you are cvoming from by such inapproriate remarks! Pete

FSUIPC does not record panel states for any aircraft. Why do you think it might? It knowa nothing about them -- how could it? I would assume PMDG aircraft save their panel states when you save a flight. Maybe you need to visit the PMDG support forum? I think you are in the wrong place! Pete

Ah, so not buttons directly assignable in FSUIPC, then. Sounds like it doesn't send keys to fSX is a recognisable way, if FSUIPC doesn't see them at all. Does FSX-SE itself see it? Can you assign to it in FSX-SE? Well, I don't know what that could be. The changes Dovetail made to the code are very very unlilely to have altered anything in such areas, and besides, as I said, FSUIPC gets hold of the keypresses before FS has a chance to see them. Are you sure you only have exactly the same things running in your FSX-SE setup as you had (or is it "have"?) in your FSX setup? I think it must be something else you have running. Have you tried the logging as I suggested? Does that just show no inputs seen by FSUIPC too? Well, it would do, not when the keypresses aren't even seen in the Keys assignmetns tab. Pete

I don't know "Logitech Setpoint". Is that a joystick type device with buttons you can assign? Where are you assigning the keystrokes? Why not assign directly to the Lua commands? To see what the difference between your two tests really is, use the Button/Key logging in FSUIPC. You can temporarily put FS into Windowed mode (ALT+Enter) so you can use the Console Log option on the same FSUIPC tab and see the results in real time. Well if a keypress is assigned in FSUIPC, it will be capturing it before FS gets to see it in any case. Unlike buttons and Axes, FSUIPC can always override FS keypress settings. Quite honestly I'd be very surprised indeed f there was any difference in the way FSX-SE treats keypresses to FSX, unless it is that Steam interface interfering somehow. Pete

Okay. In that case you need Sim-Avionics support. I can't really help. If the offsets are being set correctly, as they will be if programmed correctly as you say, then the rest is up to Sim-Avionics. I'm afraid I can't support other folks' programs, and most especially ones I don't use myself. Pete

You posted this general FSUIPC question in Paul Henty's subforum which is for programming queries on his .NET DLL. Please always direct general support requests to this, the Support Forum. Slopes are to alter the response, and unless your throttles are exactly alike throughout their range will tend to make synchronisation worse, not better unless you make even more synchronisation steps. Try the documented "sync pos" options. There's a section about it called CALIBRATING MULTIPLE THROTTLE, PROP & MIXTURE AXES TO "LINE UP" which appears reasonably prominently in the FSUIPC4 User Guide chapter on Joystick Calibration. You would have found it quickly by searching on the word "synchronisation" (as I just did). It may be a good idea to refer to the documentation occasionally! ;-) Pete

All of your symptoms point to some sort of serious corruption -- maybe of the actual FS installation, or more likely memory. The only activity that FSUIPC indulges in with is not user instigated is requesting data continuously from SimConnect. One area of this data is the Weather. SimConnect gets the weather from the .WX files in your FS Files folder in your documents folders, and relates this to the weather station positions provided in the wxstationlist.bin file -- found in your AppData FS folder, where the FS CFG file is found. Both the WX files and the wxstationlist.bin files are in binary, and are completely unchecked by SimConnect -- a big mistake on FS's designers part. Any corruption in either of those can cause subsequent problems in FS. The only reason this might happen more with FSUIPC installed is that in order to service its client applications, FSUIPC requests weather data from SimConnect, and this is done on a regular basis. This is not new -- FSUIPC4 has always done this. Corruption in those files most often leads to a crash or hang soon after FS starts, when the weather is first being read, but sometimes it only happens in certain scenery areas, because of localised corruption in the file(s). And because the corruption wreaked will vary from system to system, really the results are unpredictable. I've never before seen any symptoms mentioned like the ones you are reporting, but at present I can see no other possibility excepting corruption in a variey of FS modules themselves. You can check whether the problems are due to weather file corruption by preventing FSUIPC reading the weather altogether. In the latest interim update, 4.955g, you can add the line NoWeatherAtAll=Yes to the [General] section of the INI file. This will remove all weather facilities completely from FSUIPC. You'll find 4.955g available in the Download Links subforum. If this helps, then you most certainly either have a file corruption in those data files, or the WEATHER and SIMCONNECT parts of the FS installation is corrupted. The former is easy to fix -- just delete all .WX files and the WXstationlist.bin file. The latter will be regenerated afresh by FS, and new WX files will be made when you save flights. I only know of one user who had such weather problems and needed to reinstall FS to fix it, so that's a final possibility. Pete

Okay. That's good. Though FSUIPC installation cannot change such settings. Your post crossed with my message above. Now maybe you need to investigate your other woes in a similar vein? Pete

Nothing in the FSUIPC settings can ever have anything to do with windows belonging to other add-ons. In fact nothing in FSUIPc can possibly interfere with other add-ons which do not use FSUIPC in any case. Additionally, there is no way that FSUIPC alters anything in your Profile without you actually changing it. FSUIPC is reactive, it does what it is requested to do, it doesn't go about mucking up peoples settings and displasys on its own volition, just for fun! According to your FSUIPC4 settings you have no assignments to any keypresses at all in FSUIPC, so it isn't in any way even involved in your Shift+3,4,5 selections. But you do have a load of buttons assign to select different view controls: 23=P2,2,C66153,0 -{NEXT_SUB_VIEW}-24=P2,3,C66154,0 -{PREV_SUB_VIEW}-26=P0,4,C66029,0 -{ANTI_ICE_ON}-27=P0,2,C66153,0 -{NEXT_SUB_VIEW}-28=P0,3,C66154,0 -{PREV_SUB_VIEW}-31=P2,12,C65827,0 -{NEXT_VIEW}-32=P2,11,C65828,0 -{PREV_VIEW}- Maybe one of those buttons is repeating or getting stuck on and interfering? If you are not flying the "A2A Piper Cub" you also have this assignment: 5=P0,5,C65606,0 -{VIEW}- and this one: 2=P2,3,K65,9 -{Key press: shft+A}- I've no idea what Shift+A is for. I assume you only ever fly the A2A Piper Club, because the only axis assigned for other aircraft is: 0=0R,256,D,2,0,0,0 -{ DIRECT: Elevator }- For the A2A Piper Club you have a throttle conflict in any case, with two axes assigned! 5=2Y,256,F,65697,0,0,0 -{ TO SIM: THROTTLE_SET }-6=2Z,1,D,4,0,0,0 -{ DIRECT: Throttle }- I'm not sure what you are trying to achieve using FSUIPC, nor using one and only one Profile and virtually no other settings when the whole point of profiles is to allow different settings for different aircraft. However, honestly, there's no way FSUIPC can be responsible for all the things you are accusing it of. I know it is the favourite resort of blame for all FS woes, but it really does not deserve it. It is a very mature product with many thousands of successful users. I think you need to investigate elsewhere. Pete

You sent me a copy of your receipt, the details of which I used to Register an install of FSUIPC4 as if I were you, and it was fine. You are certainly making an error in your entries somewhere. The details you enter may already be recorded in the FSUIPC4.KEY file in the FSX Modules folder. Check that -- it is a plain text file. If you need to send me a copy by email, rename it to FSUIPC4.txt first or it won't get through. Pete

It's really pretty simple to adapt the example code. After all you are then only dealing with one offset, so the code simplies down enormously, to something like -- "Liar" example LUA plug-in for FSUIPC4/ESPIPC only, by Pete Dowson, January 2009 origversion = ipc.readUW(0x3308) -- Loop till flag 0 is set while ipc.testflag(0) == false do -- and write false value to 3308 ipc.writeStruct(0x0024, "3UW", 0x3308, 2, 8) -- Sleep for 50 mSecs so the update gets done roughly 20 times per second ipc.sleep(50) end -- Now undo the override (otherwise it'll take about 12 seconds to die, with frozen value provided!) ipc.writeStruct(0x0024, "3UW", 0x3308, 2, origversion) Okay? Pete

The Server never knows why a Client disconnects. The error is simply returned by Windows to tell it the client has gone. In that sense it is only an error if you didn't close it deliberately. Pete

They are both the exact same log, in fact, and show nothing useful. Looks like you closed the FS session after about 3 minutes. Well, SimConnect not connecting might be related. Pete

As it clearly says, it is one byte! The next byte (0BFD) is an anti-skid brake active flag. Please refer to the offsets list! It is a new value for FSX and P3D. It wasn't populated by FSUIPC before FSX. I thought you were working with FS9 now? THat location could contain anything in FS9, I wouldn't know. Pete

It's a long long time ado, and maybe I'm mis-remembering, but surely FS2002 has most of its own DLL parts in its Modules folder. If FS2002 actually runs, then it must be there! If you can't find the Modules folder, how did you clear it and copy FSUIPC to it? Where on Earth are you getting version 2.975 from? There's no such version available or supported by me. All previous versions were superseded by FSUIPC3 long ago (2003). I cannot support anyone trying to use any earlier one! I'm astonished you found it anywhere. There must be a lot of illegal copies of my stuff kicking aron! Pete

Okay. I only needed to check because we've had many cases where folks sometimes use a middle initial, sometimes a full middle name, sometimes not, and folks have been known to change their emails several times since purchasing the Registration. The name and email you provide does match the order number, so those are okay. So either your computer has a date set which is before the purchase date, or you are keying the 12-character key in wrongly. Have you tried copy and paste instead of keying it in, or is this a printed not digital copy? It is easy to mix up 0 and O, 1 and I, and Z and 2, for example. Perhaps you need to send it to me by EMAIL (petedowson@btconnect.com) so I can check in here on my PC? (Don't publish it here on the Forum). I don't know about logging into your account. You'd need to raise that with SimMarket. But the key for FSUIPC never changes -- there would be a different one for FSUIPC4 as opposed to FSUIPC3, but otherwise the system has never changed. Pete

There's no difference between a "registered version" and an "unregistered version", except for the registration which unlocks facilities. With your saved copy of FSUIPC dd you not have the FSUIPC4.KEY file? If you have it you don't need to re-register. Maybe, when entering the details again you used a new email, or spelled your name a little differently? All three parts must be the same as originally. How did you remember the 12 character registration f you forgot the rest, or are you guessing that too? Again that sounds like you are using different details. I might be able to look things up, but I need your name and email address too please. I certainly won't have access to your account or your password. You'll have to remember some details. All I can do is check you are using the correct name and email. Pete

Good. Hope it stays that way! Pete

Well you see this bit? (THIRD_PARTY_EVENT_ID_MIN + 37) That means "add 37 to the value called "THIRD_PARTY_EVENT_ID_MIN" which I think you might find defined earlier on in the same file -- look at the top of the list. Pete

You'd have to read the fuel quantities per tank and prevent them being increased. i.e keep a note of the last value and if an increase is seen, write back the last value you read. If you do this often enough the user won't even see the blip. You can make an aircraft use less or more fuel using the same technique. This is how fuel leak problems are simulated by some instructor programs which provide fault simulation. Pete

My free utility MakeRunways generates data files including Gate lists and locations for all airports -- in the G5.csv file. You would need to search this for the Latitude / Longitude or the aircraft -- anything within radius area of the gate (given in the file) would identify the gate the aircraft is standing at. Pete

Something is not right asbout the logs, or at least they don't illustrate what you say. Look: Date (dmy): 26/07/16, Time 09:33:01.035: Server name is FLIGHTSIM ... 1881653 Restarting service due to zero reception! 2407876 Incoming connection Accepted ok (skt=5228) TCP 2407985 Connected to computer "DESKTOP-VU4P01J" running WideClient version 6.999 (skt=5228) TCP 2861293 Error 10053: client socket disconnected at Client: removing (skt=5228) TCP The Server starts at 09:33 whilst the Client not till 10:14, about 40 minutes later -- so if this Client log is the one related to the above Server log, the connection shown at 2407985 (i.e. after 40 minutes) is the FIRST one. You only ran the Client for less than 8 minutes, closing it after 457.688 seconds (i.e. at about 10:22). The "Error 10053" you see then is simply because WideClient was closed. It is not a network error as such. However, though you certainly didn't run it for the 30 minutes you stated, this part of the Client log is also relevant: 457688 Reception maximum: 30 frames/sec, 1782 bytes/sec 457688 Reception average whilst connected: 29 frames/sec, 1608 bytes/sec 457688 Transmission maximum: 1 frames/sec, 100 bytes/sec 457688 Transmission average whilst connected: 0 frames/sec, 20 bytes/sec So the Client is receiving data from the Server okay, at a decent frame rate too, but very little being sent back to it. Perhaps PF3 doesn't need to send anything? The 1 frame/sec upload is probably just the regular message WideClient sends to the Server to keep it aware it is still there. So, summarising, I'm not really seeing a problem indicated in the logs at all. Sorry. Anyway, just in case you are truly experiencing a problem and simply sent the wrong logs, here's some notes. These are in addition to or probably duplicate those in the WideFS manuals, which I hope you referred to first: First off, you ARE using a wired connection, not wireless, aren't you? Wireless is certainly problematic with the type of traffic WideFs generates normally. Unfortunately, the Windows network interface doesn't tell applications about retries and errors if it recovers, but if it's got a bad connection somehow (eg. bad Network port on either PC), then many retries could certainly reduce traffic almost to a standstill. Not sure why that would get worse over time, though, unless it is building up a big backlog. If you have alternative Ethernet sockets at either end, try different ones. You could try setting the protocol in the WideClient INI to UDP, as that has no error correction. If things are going bad then this might give corrupted data which could crash PF3 or even FS, but it would be worth a test to see what the counts were then like. Finally, if PF3 really is working ok for those 30 minutes then you could use this desperate measure (from the WideFS Technical manual): Pete