Pete Dowson

Add all what values? It makes no sense to add different deflection values, surely? Why would you add elevator deflection to airleron deflection to rudder deflection, etc? Please tell me what you are trying to do with these values, as it seems I cannot understand your problem at all at present! Pete

Google translates this to: For a new PC the same registration process is needed, with the same key. Make sure your FSUIPC3 installer is up to date (3.999) and follow the Installation instructions. You register in the Installer, not in FSUIPC! Google translates this to: Pour un nouveau PC le processus d'enregistrement même est nécessaire, avec la même clé. Assurez-vous que votre installateur FSUIPC3 est à jour (3.999) et suivez les instructions d'installation. Vous vous inscrivez dans le programme d'installation, pas dans FSUIPC! Regards Pete

If you mean the values in offsets 03B0, 03B8, 2E98 - 2EC0, then no conversion is needed -- as stated in the offsets list, they are already in double form! Simply read them into a double variable and you are done. No conversion. Pete

If you mean "mouse move" this is only using the mouse to send the standard FS controls EYEPOINT FORWARD, EYEPOINT BACK, EYEPOINT LEFT and EYEPOINT RIGHT, controls you could assign to any buttons or keys or a hat even. No way can one SimConnect client change how another SimConnect client operates, unless that other client provides an interface to allow this to happen. that's something you'd need to take up with the TrackIR folks. Same applies. And in any case I thought Ezdock provided many such facilities? I'm a very happy user of Ezdock, for dynamic movements and 5 fixed views around the cockpit. Works for me because my view of the outside world is through the cockpit windows. Regards Pete

Yes of course -- that is why there are separate controls for each prop as well as the generic one assigned to Ctrl+F2!! You seem to have not actually read my last reply which not only contained the answers but also explained how you could find these things out for yourself. I'm not going to repeat it again, I'm just rather puzzled and frustrated that you've not bothered to read it! :-( Pete

I seem to have recently answered this question before. Pete

FSUIPC is a module of FS, it fits into FS in many ways with hooks and fingers all through it. there's no way it will ever work with anything not based on FS -- it works with FS98, FS2000, CFS1, CFS2 (not CFS3 which was not based on FS), FS2002, FS2004, FSX, ESP and Prepar3D. But not X-Plane, Fly!, Flight, FlightGear or Rise of Flight or any other non-FS-based sim. Sorry. Pete

No of course not. The notes are just the differences. If I listed all of the facilities FSUIPC provided in every update it would be thousands of lines long!!! I'm not ever going to do that! The main difference of course is that the 4.827 link is to an Installer and 4.831 just to an updated DLL. Always run the Installer first. Individual DLL updates are just copied in. You posted twice. I've removed the superfluous posting. Pete

In that case there is honestly no way that entry could have "magicked" itself back into that section of the INI file. Where would FSUIPC have obtained that data from? That makes no sense, honest. Maybe you are editing a different FSUIPC.INI file to the one really being used? When you run Windows Explorer to find the file, do so using "Run as administrator" to make sure you are not simply looking at and editing a file in a Windows-aliassed copy of the folder. That can happen with FS9, which is a Vista/Win7-unaware program if you have it installed in "Program Files", because Windows protects those folders and presents aliassed copies for all non-vista/Win7 applications. Regards Pete

Are you doing this editing with FS running? If so, either don't, or select some other aircraft entirely first, so there's no existing association kept in memory, then, after editing the INI file, go to the jotstick calibration tab and click the 2Reload" button to force FSUIPC to re-scan the INI file. Generally it is better to do such editing without FS running, to avoid any conflict with the settings already loaded into memory. Since the INI file is the ONLY place where such information is stored, this must have occurred because the data was still in FS memory at the time. See advice above. Pete

For that to happen you must either have assigned the JU52 to the DC-3 profile, or the list for the DC-3 profile includes an abbreviated or partial name which matches somewhere in the full name of the JU52. For the latter to happen you must have edited the list because by default full names are used (FSUIPC cannot "guess" at a suitable short name to, for example, cover all repaints). Easy enough. Each Prifle has a sections entitled [Profile.<profile name>] in which is listed all the aircraft names which are assigned to that profile. Just find the DC-3 profile list and delete the name you don't want to be there. Regards Pete

Either your registry is incorrect and is not pointing to the correct place for FSX, or you are not running the FSUIPC4 installer with sufficient access rights. Where's the start of the Install log? It doesn't help me to help you if you only supply part of the Log file! And is this correct? This can only happen if you have not given the Installer sufficient provileges to write to the FSX folders. You MUST run the Installer from an administrator's account AND with the right-click "run as ... administrator" option. And what user account did you use to do this? If Windows will not let you change your own files you cannot ever install anything. All the installer needs is elevated administrator privileges. This is all a result of allowing FSX install to go to the "Program Files" folders which are protected by Windows against any changes without such provileges being allowed. Regards Pete

The FS time data isn't character based, but binary values -- i.e. numbers. If you want strings to display you'll have to convert numbers to string character representations, eg. by using sprintf or similar. Numerical values have fixed defined lengths in any case -- a bytes is 1 bytes, a word is 2 bytes, etc. Different numbers have different sizes or representations. Any strings actually provided in the offset list are either of a defined length or already have a zero terminator in any case! There's a FAQ subforum thread telling you about numbers and bits for those new to programming. Pete

Ctrl+F2 is merely a keypress assigned in FS to an FS control. I think this is "Prop pitch decr" -- if you don't know the control names you can always enable Event Logging in FSUIPC's logging tab, use the keypress, and view the result in the Log file (or for FSX even in real time on screen if you enable the Console Log and run FSX in Windowed mode). There are also separate prop pitch controls for each engine, so you can assign to those. They are in the drop-down assignments list -- prop pitch1 decr, etc. Really it is always better (more efficient) to assign directly to the relevant FS controls in any case, rather than to a keystroke which is in turn assigned to a control. Regards Pete

No. But please ask your questions in the Support Forum. This is not the right place nor thread. I'll give a fuller answer in the Support Forum. Meanwhile, look up "ShortAircraftNameOk" in the manuals. Pete

All FSUIPC_Read and FSUIPC_Write do is add your request to the queue of requests waiting to be processed. Please look at the examples provided and read the text files and other documents provided. The only communication with FSUIPC occurs when you execute the FSUIPC_Process call. You should be accumulating all your requests for a sinlge Process each cycle, for efficiency, because each Process call involves a process switch. The read and write costs themselves are negligible, they just handle data in your own program. Regards Pete

Best ask PFC. It's nothing to do with any of my software. If it's the serial port throttle control system then I doubt it, but they may have solutions. After all I think they also support X-Plane which I don't. Pete

Ah ... Vista64 had even more problems with drivers than Win7! Many avoided it just for that reason! There are solutions for most Win7 driver problems now, but I doubt if many of the developers are backtracking to Vista64. Pete

Is there one that does that? All those single selector ones I've encountered work the other way, shifting to the left so the first digit entered is the first one in the transponder code. Otherwise you'd need to enter the code backwards which could introduce errors. You can certainly do it with a small Lua plug-in. you could probably do it with a sequence of keystrokes, switching from one decoding to the next by clever use of flags, but I think the Lua plug-in approach would be easier. In your FSUIPC Documents folder, in the FS Modules folder, you'll find the Lua plug-ins documentation and examples. Have a look at that lot first. Regards Pete

Thanks Ian. I'll copy this to the other similar thread, just in case. Pete

Seems that device or its driver is not fully Win7 compatible! Thanks for the feedback. This might also help others! Regards Pete

Yes, but i don't understand why it is happenng intermittently. If there was a bad driver you'd think it would be more consistent. Does it still crash if you remove the FSUIPC4.KEY file, temporarily, so that FSUIPC effectively runs unregistered? It shouldn't then be looking at any devices at all. There's another recent thread here concerning CTDs in DINPUT which has just been resolved with this conclusion: Interestingly, although it seemed to by FSUIPC related, in this case FSUIPC was not registered and was not accessing the devices. Just the presence of FSUIPC changed timings etc and exacerbated a problem which was there in any case -- probably a driver which was incompatible with Win7. [LATER] Ian P. just posted this, which may be useful: Regards Pete

No, I am sure that's not correct. The G3D.DLL patch is completely and utterly silent. The only way you'd know whether it ever occurred is to look into the FSUIPC4 log -- each group of occurrences is logged and a total of all occurrences is given at the end of the log, after FSX is closed. The only error sound FSUIPC makes is when the memory available to FSX is reduced below 300 Mb, because soon after that you would start getting problems ad evenutally an OOM error is likely. In the latest version (4.831) this check is reduced to 250 Mb and made optional via the "OOMcheck" parameter in the INI file. Sorry, I've never heard of any automatic "minimizing" of FSX, only minimizing by user action. I really have no idea what you have going on there, but none of that is anything whatsoever to do with FSUIPC at all. Why would you want to pause, minimize and maximize FS? What is it you think you are achieving by this? I've usually found such actions rather precarious. Best just run in full screen mode and leave it alone. Regards Pete

Okay. I am now of the opinon that the attribution to FSUIPC is actually wrong, that it is mere coincidence, possibly due to differences in memory arrangements and timing of events when it is loaded. I see that your FSUIPC installation is not actually registered, so FSUIPC is not in fact scanning buttons or joysticks at all, and is making no calls at all to DirectInput. I'm not sure how you'd go about finding the true cause, but if DirectInput seems to be the most prevalent crash area I would certainly check all your USB connections and devices. Regards Pete

Well, the logging additions made no difference in any case. Obviously it isn't related to FSUIPC's DirectInput scanning as it didn't get that far. However, FSUIPC got a helluva lot further than the last log you showed. Simconnect did connect okay, and everything was going well except that FSUIPC never saw you exit from the selection menu and commence normal flight mode. You must have changed something to make that occur, because there is nothing in the world FSUIPC could do to change that. It's an option in your FSX.CFG file. It is beginning to sound very much like you have some sort of hardware problem, probably bad memory. And what did the Windows log show this time? Pete