Pete Dowson

Hmm. No one has mentioned this as a "problem" before -- it was intended to be a feature, as in FS, not a problem! It would be easy enough for me to add an assignable control to toggle it on and off (only in the FSUIPC4 mouse look facility). I'm already adding two similar controls to toggle mouse look and mouse move on and off for another user. They'll be in the next version, which I'll be releasing as soon as LM release P3D v2.1. Another possibility, which may be better, is to ignore small changes in the wheel position until it has been moved more, er, forcibly. The code is more complicated for that, of course, but it may be better if the only problem is slight unwanted movements. Pete

What facility are you talking about? One in FSUIPC, or is this FS general or EZDOK or OpusFSX? If you mean FSUIPC's mouse move then it's actually an eyepoint movement, not a zoom. If you mean mouse look then it is a zoom -- so I suppose you mean mouse look? There is no facility to separate these actions at present, and it really surprises me that you find it difficult to press the middle button without moving the wheeel back and forth -- I have to make a positive effort to adjust the zoom should I want to. Are you wanting no zoom facility at all, or an on/off capability, and if the latter how do you propose to control that? Pete

Not sure what you mean. As you say, the handle is returned, so your Lua program has it. It is merely a pointer into an internal FSUIPC or WideClient structure. It has no use outside of the context in which it applies. What are you wanting it for? Pete

It sounds like TeamSpeak is running "as administrator". When two programs are running at different privilege levels they can't talk to each other. However, that doesn't explain why giving WideClient the focus made it work. That makes no sense -- unless it having focus temporarily "elevates" its privilege. Pete

It would have been better to put the INI file you really wanted to use in before running it for the first time. It is pointless making it generate a default one. BTW the curently supported version of FSUIPC4 is 4.928 and has been for nearly three weeks. You need to update. Ah, I see from the INI file: UpdatedByVersion=4928 that you mean 4.928, not 4.927a! The devices seen are assigned to letters A, B, C and D, but A is missing. Doesn't that matter? You do seem to have some button assignments for A. [JoyNames] AutoAssignLetters=Yes A=Saitek X52 Flight Control System << MISSING JOYSTICK >> It's hard to say what is going on Your log file shows you had Button & Key logging enabled, as well as Axis and Event logging. But there are no entries at all showing any buttons being pressed. and the only axis movement is for Prop2. Did you press any buttons at all? And only one lever moved? Your Prop2 assignment is to the X axis on device "D" (D=Saitek Pro Flight Yoke) whilst your ailerons axis is X on device "C" (C=Saitek Pro Flight Throttle Quadrant). These are surely the wrong way around? Perhaps the INI file you thought you saved and restored is from a different time? Check the lettering: [JoyNames] AutoAssignLetters=Yes A=Saitek X52 Flight Control System << MISSING JOYSTICK >> A.GUID={4526EAA0-89AE-11E3-8008-444553540000} B=Saitek Pro Flight Rudder Pedals B.GUID={4526EAA0-89AE-11E3-8009-444553540000} C=Saitek Pro Flight Throttle Quadrant C.GUID={4526EAA0-89AE-11E3-800A-444553540000} D=Saitek Pro Flight Yoke D.GUID={53D63970-89AE-11E3-800B-444553540000} Obviously one fix is to swap the C's and D's around -- but why would they have changed? It may be possible that GUIDs don't remain constant, but there's no way the names can be changed -- they are built into the device. The GUIDs might be too, I don't know, but anyway those are only used when there are several deivces with the same name -- else they are ignored. Is the Rudder assignment working okay? If so you know B is correct. if not maybe A and B are reversed too? I think the only explanation is that this INI you installed was not the one you had working before. Most folks just paste the contents into their message. You can do that quite tidily using the <> button above to encapsulate them. Pete

You do realise that none of those add-ons actually use FSUIPC? Evidently there's a bug in one or the other which is causing your FS to crash, but why come here with it? Why are you thinking keystrokes have anything to do with FS crashing? I'm not sure why you are providing these details. Do you know it is TrackIR causing the crash? Why are you suspecting a conflict rather than a bug? Pete

No. That is very strange. Obviously WideClient didn't suddenly change, so that's pretty weird. Having WideClient as the active window is never necessary for any action it performs EXCEPT the option for it to send keystrokes from the client keyboard to FS -- for that it obviously needs keyboard focus. But I assume your yoke button is programmed to use a KeySend number ot WideClient and in turn it has that number assigned to the key you set in TeanSpeak, and have "UseSendInput=Yes" set? If you don't have the latter set then this might be the problem, though I don't understand then why it would work with keyboard focus on WideClient. There is another way using "PostKeys=Yes" but you need stuff like the Class Name of the target program window, and only works if the target is processing Windows messages for key input, not relying on Hot Key settings or keyboard scanning. From the way that TeamSpeak PTT key assignment is described it sounds like it uses hot key or ascanning methods. What was the WideFS crash? The only crashes I've ever seen have been due to Networking problems and tend to be in low level Windows modules. Did WideClient log the crash details -- it does have crash logging built in for ones occurring in its own code. Pete

No. You are misunderstanding what WideClient does. It is an extender only for the FSUIPC application interface. WideClient runs on the non-FS PCs supporting FSUIPC applications on those PCs communicating to FSUIPC on the FS PC. It does not run on PCs which are also running FS. In your case you could use it to run some of your applications on another PC, away from FS. Those are probably PROATC, FDC, FSGRW, and maybe some GOFLIGHT gear -- but not yokes and pedals which need to be on the FS PC. Your REX, FTX GLOBAL and TRAFFIC apps are only textures and scenery files in any case and don't really use processing power whilst using FS, only when setting up different textures etc beforehand. The PMDG aircraft for FSX do not run without their panels -- they are there and operating even if you don't display them, and though they can be undocked they cannot be moved to other PCs. The only aircraft I'm aware of which is made to work like that is the iFly 737NG cockpit edition. I do know folks using the PMDG 737NG model from FS9 on FSX, with no panels at all, and using Project Magenta, SimAvionics or Prosim737 software for networking the instrumentation, but this cannot be done with the PMDG FSX versions. There is a program called WidevieW, by Luciano Napolitano, which links multiple PCs all running FS. You might find this will do closer to what you want, but even then I don't think you can distribute the panels of the PMDG 737NGX. Hope this helps. Pete

As your log clearly shows, it isn't anything in FSUIPC doing this. It would have been clearer if you had enabled Event logging, as that would have showed when the GEAR TOGGLE command was actually being sent. You must have an assignment to button 9 elsewhere, possibly in FS itself. Did you not disable controllers in FS, or at least de-assign everything? Be also aware that FS is liable to make assignments automatically when it thinks a device is newly connected or re-connected. I note that you use FS controls for some things, but the assigned FS keystrokes for others. Why not use FS controls for everything -- Gear Toggle instead of the G key, for example? Regards Pete

FSUIPC installer does not install any text documents in the Modules folder. You might still have an FSUIPC4.INI (configuration file) and an FSUIPC4.LOG from running FS before -- these files are generated when you run FS. They are text files, but there is no version number attached, so I don't know where you are reading this 4.20 in the file properties. It would only say so in the text itself. FSUIPC4.DLL is NOT a text file, it is the program actually called FSUIPC4 which runs when you run FS. I suggest you stop Windows explorer hiding the proper filenames from you. There are instructions for this in the FSUIPC4 user guide if you do not know how. Pete

The file installed is FSUIPC4.DLL. Thee is no file of any relevance to FSUIPC called just "FSIPC4" with no filetype. Where are you reading its version number? Pete

Answers in order: 1. Download the FSUIPC4.ZIP file, extract the Installation document and the Install EXE file, read the former and run the latter by right-clicking on it and selecting "run as ... administrator". (As explained in the instructions). 2. It will be automatic. 3. No other files are needed. The files installed are listed in the Installation document. WideFS is a separately purchased product. Pete

You could try it. All that does is delay the startup a little, to avoid clashes with other add-in programs. Pete

Sorry, I've no idea about any of that. I thought that only worked for messages displayed trough FSUIPC, not for FS's own messages. And it is done by a hack into fS code found by experimentation. Regards Pete

I've avoided Win8 entirely. Win7 is the best version of Windows ever and I'm sticking with it. Sorry, I've no other answer. You could try repairing or reinstalling Windows, or rolling back to some previous restore point. Pete

Two errors to start with. A byte contains 8 bits, not 10. "UB" means "Unsigned Byte". You need UW (Unsigned Word). ipc.setbits(0X66C0,1) isn't valid. there's no "ipc.setbits". You forgot to put the size in (UB or UW). Please ALWAYS check the FSUIPC log file when developing a plug in. it would show this error. I assume you mean 1, 2, 4, 8 ...? I don't see any other than your test for setting the 1 bit, bit 0. Pete

Not sure why that should be -- I have ASN set to automatically load the plan if load into FS. Best report the problem on the AS forum. Oh, and thanks for the thanks! Regards Pete

I don't know about FSRealWXlite, but certainly neither Squawkbox4 nor ASN use FSUIPC for Weather setting. The only reason you needed to update FSUIPC for ASN is that previous versions of FSUIPC had an incompatibility with how ASN performs its own wind smoothing and other effects, which caused certain other programs to be unable to do their own smoothing. It didn't cause crashes or prevent any weather setting activity. Sorry, I can't really help with problems with other folks programs. Pete

FSUIPC is started when you run FS. It becomes part of FS. There's never any need to "start it up". The Add-Ons menu entry is there for you to set or change options, it is nothing to do with starting or stopping anything. Many add-ons put entries into the Add-Ons menu entry.The User Guide is your friend. It has pictures of the assorted option pages you get from the Menu. I'm really not sure where else you could possibly think of looking. Regards Pete

It's a bad file somewhere. If you have a backup of FSX first replace the WEATHER.DLL from the backup. Otherwise it will most likely be some texture file associated with the airports near or at which you get the crashes. Pete

Sorry, no, I don't know any way to do that programmatically, only by editing the CFG file. Pete

What you've managed to prove is that something is corrupting the Weather data, either that being read or whatever is stored in memory. What is the weather setting in your FS weather menu? If it is initially downloading weather from the MS site, then it may be that. Select a clear weather theme and close FS down so that when you relaod that will be its action. Or I suppose it might be a corruption in the Themes. The only other alternatives from what you've told me are ( a ) some bad texture file, either in scenery or AI traiffic, is corrupting memory, or ( b ) Weather.DLL or SimConnect is corrupted ( c ) You have some bad memory chip. if it only occurs at certain places then (a) seems the most likely. If you have no application needing to read or write weather through FSUIPC then it does no harm to leave "WeatherReadFactor" at 0. It's workaround, though, not a solution. Pete

For the log to end up so large you must surely have some logging options set? Just turn them off. You don't need anything selected for a Log to be produced. Or was is some loop with a SimConnect failure to connect? Didn't you get to glance at any of that 250Mb? If FSUIPC is producing a Log it must be running, and for it to be running so must FSX, so I'm not sure what you mean by "unable to start FSX". You mean it hangs during starting? With what displayed? You can load programs, eg SIOC, using the Programs option in the FSUIPC4.INI file, and set it to only start when FS is "ready to fly" ("READY"). Pete

Well, the crashes are still in WEATHER.DLL, so I really don't see how they are related to scenery areas. However, I believe it must be due to in-memory data corruption in the weather data -- and there's a way to prove that which I'll explain in a moment. This could well be caused by a bad texture file which is only being called up at certain locations -- either a scenery texture or an aircraft texture. There's been a case identified recently, causing STACKHASH crashes in FSX, which only occurred at certain locations and was eventually nailed down to a faulty AI traffic aircraft.texture for an airline flying out of the near airport. I suspect other types of crashes are equally likely in such cases as different memory arrangements affect different data structures. FSX will make a new one if it needs to -- there's a backup in its WEATHER folder in any case. To test with FSUIPC installed but not reading or writing any weather at all, change this line in the FSUIPC4.INI file before loading FSX: WeatherReadFactor=2 change this to WeatherReadFactor=0 Pete

The CFG file is of no consequence to FSUIPC, as I keep saying. If FSUIPC is not loading (and we've not established that yet!) then it will be the DLL.XML file which is corrupt. C:\Users\rfields6\AppData\Roaming\Microsoft\FSX\DLL.XML If you think FSUIPC is not being loaded then show me that file. I'm not interested in any CFG file. Pete