Pete Dowson

Typo. My answer crossed with your clarification. Pete

Sorry, can you be more explicit, pleas. i don't understand what you meran by "hex notation" being a "little off"? [LATER] Oh I see. Typo. It says x1000 and x1FFE and it should say x10000 and x1FFFE. (The last one, x1FFFF is reserved for internal use). Fixed for next release, in a month or two. Pete

Did you run the Installer "as administrator", as instructed? What version of FSUIPC4 is it? If it isn't at least 4.853, please update and try again, re-registering in the Installer. I always need information. In the Modules folder there will be an Install log and an FSUIPC4.log, both normal text files. Make sure P3D is closed and paste them into a reply here. Pete

Not sure why you need macros just because their custom key events. Are you sure your 'tester' is using an up to date FSUIPC and that you also are referring to recent documentation? Custom events declared via SimConnect are NAMED, not numbered, and you tell FSUIPC about them by listing their names in an .evt file.-- see the section "Add-on Custom events" in the Advanced User's manual. If, instead, by "custom key events" you do not mean those named via SimConnect, but FS key events using WM_COMMAND numbers outside the normal range (much like PMDG have done with their 737NGX), then these have been assignable directly in the Assignments dialogues since version 4.85. Search on "custom control" in the User Guide. Regards Pete

What Aircraft are you using? FS by default does not have an "AP disconnect", only an AP Master switch, which toggles on or off. Ah, Project Magenta. Hmmm. Which manual? What's difficult? I can't help unless I understand what your problem is! My list of PM offsets (which is certainly "difficult", as I've always found too!) says the 99 value is 747 AP Disconnect. There's also bit 10 of offset x5414 but that says it's for 747 and 777. The most likely one as far as I can see is offset x050A, bit 1. For that you'd presumably assign to "Offset byte setbits" with offset x050A and parameter 2, but it may well be "Offset byte togglebits" -- sometimes PM wants the bit to change for the action, sometimes just set. I don't really know without trying it. PM does have its own Support site, where you can post questions I believe, or you could try the help of other users over in the unofficial PM forum in the http://www.mycockpit.org/forums. Regards Pete

How do you make it work with the mouse itself? do you left click for one direction and right-click for the other, or what? If it's been programmed by some difference in the mouse action, then there will probably be some flag setting you can adjust for the parameter (in the MCRO file) which will make the direction reverse. The flags are described in the FSUIPC documentation. You'd have to try various values. I have no way of predicting these things. If the way they've programmed the switch is by separate screen areas with the mouse position being important, then EITHER you can do it with two separate mouse macros, one for each area, or, more likely, it is just one area with the distinction made in the code itself, by reading the mouse position at the time. In the latter case there's really no way to do it with mouse macros because the real mouse isn't involved and could be anywhere. No, just delete the lines you don't need in the one MCRO file (I assume you've put them all in the one file, and not generated loads of files?). Regards Pete

I see. That's good to know. Thanks! Pete

I quote above just some relevant lines from the INI file. First, FSUIPC does see both devices and records them in [JoyNames] as it should. How was that not occurring before? Second, those calibration lines show you are setting "no reverse zone", which is fine, but the calibtation values are all the same (-16384) so no throttle changes will have any effect. Third, the [Axes] section shows silly values like 5565 and 7542 for the "delta". you shouldn't mess with the Delta unless you are technically proficient and know what you are trying to do with it. The Delta is the smallest change which will be acted upon. It is normaly 256, but can be reduced for well-behaved axes, but large values like that means your throttles will be virtually ineffective. Best to delete the INI file and start again, to avoid hassle with these bad settings. I thought you said you'd disabled controllers in FSX and were using FSUIPC assignments? Do NOT mix them. Either use FSX or use FSUIPC for axis and button assignments otherwise you are very likely to get conflicts. I think you'll find quite the opposite. Look at the tutorials knocking around. Most users of FSUIPC disable controllers completely in FS and advocate this quite strongly. If you don't, then it is best to do all your assignments in FS, not in FSUIPC. You can still calibrate axes in FSUIPC -- assignment and calibration are two separate things. If you leave FSX controllers enabled, and just delete the individual assignments be aware that FS can automatically reassign the axes and buttons without asking you. This happens if it ever ses the joysticks as "new" connections, which may occur simply because of a USB glitch or power variation. This is why it is safer to disable them completely. BTW, in general, using FSUIPC only for assignments, it is usually perfectly okay to have multiple assignments for the same action, such as throttle. FSUIPC only processes changes in the input, so providing the axes aren't jittering, or you have them parked in a "dead zone", or their jitter is less than the "Delta" value I mention above, they don't interfere. Dead zones, especially at the idle (or centred) position, are always a good idea for this reason, and also so that you can always be sure of getting a true idle even allowing for variation in axis output (temperature, humidity, voltage, and aging all vary the read-outs to some extent). When assignments are made to exactly the same functions from two different controllers, and providing these assignments are "direct to FSUIPC calibration", FSUIPC arbitrates between the incoming values, favouring the one with the most deviation from "normal" (idle for throttle, centred for control axes). This makes such assignment useful when building a dual control setup, pilot + copilot. Regards Pete

4.80 is now VERY old and I cannot possibily support it! What do you mean by "only version identity" you could find? It is displayed in the main Tab in the FSUIPC options, on screen in FS, it is shown in the Properties of the DLL if you right-click on it and select Properties-Version (same as nearly all programs and modules), it is displayed in the Log file it produces every time it is run, it is placed into the [General] section of the INI file -- and the main release number is shown at the the top the User Guide, and in the Installation documentation, and, in separate updates, in the changes document. All these ways you give you a proper version number! If no devices at all are listed, and you have some recognised by FSX, then either FSUIPC is not running or it is an extremely old version of FSUIPC dating well before the 4.800 you say you think it might be! It sounds like something you've installed has wrongly placed its own version. I suggest you download the current installer version, 4.853, and run it, then run FSX, then close it down, then find and paste here the FSUIPC4 Installer log file, the FSUIPC4.log file, and the FSUIPC4.INI file. Then I should be able to see what on Earth you have going on, or at least make a start! Regards Pete

Version numbers are more useful. Latest version with installer is 4.853, latest version DLL available is 4.858 It sounds very suspiciously like hardware, maybe just the particular USB connection. Have you tried a different socket? FSUIPC4 uses exactly the same method of finding and reading axes as FSX, so I don't understand the distinction there. Maybe FSUIPC is actually seeing the device itself - check the FSUIPC4.INI file, in the [JoyNames] section FSUIPC lists all joystick-type devices it finds. It is probably finding the device, just like FSX, but neither sees any action (or perhaps inconsistent action) on the axis itself. That could be a broken wires, a bad USB socket, or a failed device itself. Regards Pete

Okay. Use 0x9500 - 0x953F. I've marked it down as reserved for you and FSSymphony. Regards Pete

No problem. When you say "for the time being" do you imply that you may expand in future? If so wouldn't it be best to determine your long-term need so it can be allocated contiguously? Say 64 bytes? Let me know a realistic size and I'll respond with the allocation I can provide. Regards Pete

All the autosave function does is call the FSX save facility in exactly the same way as you can using the ';' key. The advantage only is that it is automatic and assigns a name to save you having to enter one. But it is not responsible for what is saved and what is not. I expect the PMDG aircraft, with its complex systems, needs to save its own data. I expect that the request to save the data came at a time in the 747 when things were not easily saveable. I think the complete set of arcraft systems would have to be temporarily frozen whilst the data was written out. I don't know if PMDG do this, but I suspect not from what you and others say. You'd need to ask PMDG to implement their saves correctly, so that all systems are saved correctly. But I suspect this is very complicated for them to do, and they will just reply that their aircraft is not compatible with Autosave so not to use it.with them at all. No, not if the normal saves work okay. Have you tried those? Regards Pete

What is the version number of the FSUIPC you are using? How are you assigning and calibrating? There are several different methods for assignment and the subsequent calibration will vary. Did you not try simply letting FS do the assignments and using FSUIPC for calibration? Please also specify the aircraft. If it is an add-on aircraft then don't -- use one of the default aircraft first, to get things sorted. If the CH manager still running? I'm not sure how that gets along with FSUIPC. Most folks use only one or the other I think. Your best bet for advice on CH devices is Bob "Stickworks" Church. Try http://www.ch-hangar.com. Regards Pete

Well, I'd rather not, and, as you say, they work still, so why would I do this anyway? Pete P.S. It is possible to write a Lua plug-in to make most offsets, including this one I think, tell lies to applications. The example "Liar.lua" in the Lua plugins installed in your FSUIPC Documnts folder shows this method.

I moved your post into the Support Forum, where support is carried out. You mistakenly posted it in the FAQ subforum, which is where standard answers are kept. So, why didn't you follow that instruction and update to a later version? FSUIPC4 was changed for P3D 1.4 within a week of it being released!!! The current main version is 4.853 and there's a version 4.858 also available after that is installed. Pete

No, it found it okay, look: You seem to have called yourself "User". Try installing FSX SP2 update. You should get FSX up to date (as far as it went!). Pete

It isn't FSUIPC, it's your USB settings. It would happen without FSUIPC even being there. You need to turn off Windows power management on the USB hubs in the PC. Check them in Wndows' device manager -- Windows checks the power management options by default. You need to uncheck them all. I think for some reason Saitek axes in particular seem most vulnerable to this. I can only think their controllers take more 'juice' than most, and/or don't do something in the USB protocol to keep the things awake. Pete

I've never ever heard of any problem where an empty log is produced, not in the 14 years of FSUIPC. At present I just don't see how it is possible. SimConnect loads DLLs, and how long that takes varies. Perhaps you can find your DLL.XML file (in the same folder as your FSX.CFG file) and paste it here so we can see what else SimConnect is doing. The EXE.XML file too if one exists. You could also get a SimConnect log file so we can see what SimConnect is doing and how far things got. There are instructions for producing one of those in the FAQ subforum. Pease update the FSUIPC4.DLL itself, in the FS Modules folder, with the latest, 4.858. You'll find it in the Download Links subforum. Another bit of information would then be useful too. Go to the Windows event logs (just enter event log in the Windows Start search field, then select Windows Logs -- Application, find and highlight the Error entry for FSX, double click it and select "copy", then paste into a message here. Pete

What are you posting about? All you've done is quote the original poster's message! Pete

The only problem like that is really a SimCommect bug. FSUIPC doesn't even get to run. you get an FSUIPC4.LOG file and it is empty? I've never ever encountered any such problem as that. The first tihng FSUIPC does after creating a log file is to write its name and version number. nothing else in between. If that's failing such a simple taks I'm afraid you have a real Windows problem. I really do find this hard to believe. Are you sure the FSUIPC4.LOG file you are looking at is called exactly FSUIPC4.LOG with the date and time of the start of your session and with exactly 0 bytes in size? No. Pete

You still are, then, as registration never expires. You made no backup? The user guide does advise you to back up your KEY file. You will need to open up your account on SimMarket and retrieve your data. It is always there, for all your SimMarket products. No. the registration is irrevocably tied to the original name and email you purchased it with. But it will still work. The email address is not used for anything else. Regards Pete

All the FS commands are assignable in FSUIPC, and more. Just look through the list. If you want to identify which command you are using with your FS keypress, just enable Event logging in FSUIPC and examine the FSUIPC log file (in the Modules folder) afterwards. There's also a list of FS controls provided -- see the FSUIPC documents subfolder inside the FS Modules folder. Regards Pete

Ah,do i detect a missing "not" in there somewhere! ;-) If you mean that these products do what you ask, but more also, then, yes, that is true. If that makes them too expensive for you I can understand your lack of interest in them. but I, for one, use IYP quite happily with little to no copilot activity, nothing mostly but the use of voice commands at busy times to do things in a cockpit where there'd normally be two pilots (like dial in a new altitude or QNH value or Transponder code or radio fequency) -- but also quite often for checklists -- the latter is a useful addition i feel, as you are trying to fly the plane and reading proper checklists yourself is really often out of the question. Having these read out, with you only confirming each item is an excellent compromise. Only in that sense do I have a "copilot". You need to assign keystrokes to more specific actions. The subset presented to you for assigning in FS is limited -- FSUIPC simply allows access to all of the possible FS commands, including those wth parameters, and also to assign keystrokes to macros or plug-in programmable actions. However, I'd be surprised if this VAC program can translate a command like "set heading n" into a keystroke AND a number which could be used as a parameter. You'd be able to program, say, "set heading to 300" into a control action to set the heading with the parameter fixed at 300, but not to make it general by converting the '300' part into a number to be used in the parameter position. This is where the power for FS use comes in when using IYP or MCE. Yes, but only the specific values you program. How would you do that? If you only ever flew the same small set of headings, used the same small set of frequencies, flew only certain pre-programmed altitudes, and so on, you could work it that way. The only other way with a generic voice-to-ketystroke program would be to only ever use INC and DEC commands, and simply keep repeating them whilst watching the dials. Ugh! Regards Pete

I see. Well, it would be okay that way. I suppose it's a matter of taste. I tend towards the idea that the plug-in programmed part defines the actions on the aircraft just effectively providing more functions for assignment, separating the business of sorting out how the aircraft works separately from which buttons or switches you are going to use for what. Then changing assignments is easy -- once the file defining the aircraft actions is made and done it wouldn't need any changes for different device assignments. So, one way is easier in one way and messier in another, and vice versa. Pete