Pete Dowson

How did it get into the mess you showed before? Are these buttons or switches? If buttons, you don't want them doing actions when released as well as pressed, unless you intend holding them down. When you made those macros, did you follow the correct procedure and test them each time, using the TAB facility? Note that those pairs are the same as each other, but reversed: 1=ADF-L-ON=RX7590*X8bcc,31 ====> same as 4=VOR-L-OFF=RX7590*X8bcc,31 2=ADF-L-OFF=RX7590*X8bcc ====> same as 3=VOR-L-ON=RX7590*X8bcc I think you are missing the central switch position in any case. I'm afraid I cannot work out these macros for you. I do know that all of the 737 overhead buttons and switches are mouse programmable, and I think , from other reports from users, that most if not all of the others are too. Maybe you should re-check the way you created the macros. Multiple position switches will probably need more attention -- there are notes about editing the mouse action value if needed, in the documentation. And if the TAB test doesn't work, when you make the macro, then it is highly unlikely the macro will work. Anyway, I have the 747X installed on another Pc. I'm powering it up now to check. Regards Pete

Okay. You have 4 macro files listed. Reference numbers are 1, 2, 3 and 4. Now look at the Button assignments: You have assignments to Macro files referenced as 2, 6 and 11. There aren't any macro files 6 or 11 anyway, so where did those assignments come from? Have you been editing the file, or copying stuff over from a different installation? You certainly have no assignments to number 4, "747-forPete-EFIS", so how do you know they don't work? you do know you have to actually assign buttons to the macro functions you want them to operate, don't you? If you remember, i did ask you to explain what you meant by "he doesn't want to act", but you never replied. But if you mean that buttons you haven't assigned to EFIS functions don't work, then looking at the file it isn't surprising, is it? Why? What is the point? You should surely try to communicate your problems, or misunderstandings. not create something artificial for display? Regards Pete

You are not telling me much, are you? What is this file extract you showed part of? Where is it saved? Where are the assignments? What exactly does "he doesn't want to act" mean? I really cannot diagnose problems with no information, sorry. Best explain a bit more, please, and also show me the [JoyNames], [buttons] and [MacroFiles] sections of your FSUIPC4.INI file, which all play their part too. And what VERSION number of FSUIPC are you using? If not the latest, try that first (4.525 is available in the Updates announcement). Regards Pete

I don't deal with sales and registrations at all. It is all done by SimMarket. Open your account at SimMarket and put your problem to them in a Problem Ticket. If you've literally only just bought FSUIPC they may look kindly on this, but it might be a bit of a problem because their system is all automated. Regards Pete

How are they assigned, via FSUIPC axis assignment or only via FS? All calibrated in FSUIPC? Any log file I can look at? I don't understand this part. can you re-phrase that? What client, exactly? If it isn't registered, then it isn't doing anything with any joystick inputs. All those are part of the user facilities which registration brings. Sorry, I think you need to explain rather more. Like * how are these control surfaces connected? * where are they assigned? * where are they calibrated * do they work with default aircraft or only not work "on-line"? * what are you installing FSUIPC for anyway, if you aren't using its user facilities -- i.e. what programs are using it? * what is this "client" you speak of? * please run FS with 3.90 installed, close FS then find the FSUIPC.LOG file, from the FS modules folder, and show me it. As I say, FSUIPC really doesn't touch ANY buttons, control surfaces, nothing at all, when you are not registered. So it is probably connected with some accessory program you've not mentioned. Regards Pete

Okay. You might find the attached utilities useful. "joyview" uses the same "joy" API as FSUIPC3, whilst "DIview" uses DirectInput. Regards Pete joyview.zip DIView.zip

Ok. Good. Please note that if you are running FS in admin mode, I think you will also need to run any FSUIPC-client programs in Admin mode too, if they are on the same PC -- otherwise Windows stops them exchanging data. Yes, of course. This is what I do. Note that you'd be better off, in that case, selecting CTRL+SHIFT+... (0-9, etc) for the key combinations, in RC, to avoid possible conflicts with other programs. If you ever get IYP (Its Your Plane) you'll find its spoken RC commands translate to those key combinations too. Regards Pete

Windows dialogues, like the Windows themselves, are supposed to be usable without a mouse. Not necessarily efficiently, of course, but nevertheless, usable. Before programming anything, just try operating the said dialogue using the keyboard only. You'll see what I mean. And you might find it quicker sometimes to use, i think, "shift + TAB" to tab backwards instead of forwards. Take care -- the TAB order in dialogues follows the order in the definition, not any order based on their screen position. And some fields might be reached more directly by their key letter (usually underscored). Regards Pete

Very strange. Sorry, I really don't know what's going on there. It does sound like, when not administrator, it cannot even read or find the file, or the registry. But the entries MUST have been written to the registry or it would never appear registered. Did you ever actually try registering the way documented, and as I asked three times before? You've never once said so! :-( Pete

Sorry, that's no use since most of the files aren't shown. Please first click on the Date heading so the files are sorted with latest ones at the top, otherwise there's no way to see what is happening, off the screen view you captured! I've researched this further. There was a (much) earlier version of FSUIPC which, in order to avoid the problem of the read-only restrictions in "Program Files" on Vista and Win7, automatically made the files in the same folder as the Flight Simulator Files (i.e the place where you found them). However, the current releases move them back again, to the modules folder -- or at least they should do! Please, tell me, have you been using FSUIPC before, i.e. an older version before 3.90? Maybe, during the registration run, the files aren't moved back for some reason. I'll cross check that here when I know the history of your FSUIPC usage. In that case it is 100% impossible, absolutely, for FSUIPC to log your name and address in its log file, for there is no where else it ever comes from. No where, really! This means that the files you are showing, for the Log, were produced when there WAS a KEY file, but it is somehow being lost or removed. Please delete those two FSUIPC files from the Flight Simulator Files folder. Run FS2004 "as administrator" -- in the way documented and as I have asked you to try, twice before already, and which it appears you never did (?), i.e. please, NOT in the way you said you did! The way as documented and as I have explained before in this thread. This seems to be getting ignored in every response you make. I've deliberately deleted my own Registration here and registered with your details, on my computer, and it works okay -- so it most certainly is nothing to do with the accented character in your name. Regards Pete

Not really, because FSUIPC isn't running when you are in a modal dialogue like that. If you are running in an external process you can of course send keystrokes to the FS Window and operate the menus that way. It isn't a "button strike" you need but the Enter key pressed when the OK button has the focus. Generally TAB moves focus from control to control within a dialogue. I operate FS menus from a Networked PC via WideFS. That operates a bit differently, the keystrokes being send from a different thread. Regards Pete

Not really, because FSUIPC isn't running when you are in a modal dialogue like that. If you are running in an external process you can of course send keystrokes to the FS Window and operate the menus that way. It isn't a "button strike" you need but the Enter key pressed when the OK button has the focus. Generally TAB moves focus from control to control within a dialogue. Regards Pete

No. FSUIPC3 uses the original Windows "joy" API to read both buttons and axes, just as FS used to until, I think FS2002, when it changed to DI (DirectInput). DirectInput suppports 8 axes, 4 POVs and 64 buttons on each joystick, with up to 128 possible joysticks (I think) The "joy" API supports 6 axes, 1 POV and 32 buttons on each of up to 16 joysticks. Evidently one of your axes in on one of the 2 not supported by the "joy" API. With FSUIPC4, which was almost a complete re-write (for the first time since FSUIPC 1.00 back in FS98 days) I changed the axis scanning to use DirectInput, so it also supports the same axes and POVs as FS. I didn't change the button scanning as it would have introduced too much incompatibility with FSUIPC3 when folks changed to FSX. Unfortunately there's really no easy way I can change FSUIPC3 at this stage. Being a program suject to ongoing changes and additions now for over ten years it is almost impossible to do anything major like that without almost rewriting it. Interim updates and other useful bits and pieces are always posted here, in the "Updates" announcement. This system has been going on now for several years. It isn't 3.918 now, it is 3.919. Regards Pete

Great! So you can simply assign keystrokes or buttons to those FS controls, "Anti_Ice_Toggle_Eng1" and "Anti_Ice_Toggle_Eng2". FSUIPC's drop-downs features ALL possible FS controls. Those are but 2 of many. Yes. And how do you suggest this be done? There's only one way I know: You can emulate a mouse click is by having a program which records the mouse positions (they must never move) and then, when asked, moves the mouse pointer and sends the button clicks. The program which does this is by Luciano Napolitano and is called "Key2Mouse". That will enable you to assign a keystroke for mouse actions. Then you assign a button to the keystroke. Regards Pete

Nor can I, because as I said, FSUIPC.DLL only ever accesses and writes its files to the folder in which it is installed. And for FS to load it it has to be installed in the FS modules folder. I cannot examine your disks from here, but i'm sure it could be resolved very quickly by examination of your modules folder. No, it shouldn't be -- the checking in FSUIPC is the same as the system used to make your key in the first place. And if is appeared incorrect it would have been rejected when you entered it. The only thing i know which can produce the symptom you report, that of it accepting the details and key, but then still appearing unregistered on reload, is when the Registry cannot be accessed, and as far as I know that can only happen due to lack of "elevated administrator" privileges when registering. Did you try as I said, using the right click run-as, not the property change as you originally did? You haven't said yet. I'm sure there's only one correct way. Not really. There's nothing going to be different. The first thing to do is find the files in the right place -- i.e. in the Modules folder. Grab a screen shot of your Modules folder in Explorer and show me if you are still convinced the files aren't there. None that would make any difference. All that is entered there is a record of the date you registered. This is a check on the validity of the key -- pirated keys often have wrong dates. If the registry contained this data you'd not have the problem. And if it did it wouldn't stop you re-registering correctly as I've advised. Regards Pete

Okay. The problem you have appears to be fixed in version 3.918, already available from the Updates announcement above. I think there was a little fix for FS2002 which also fixed FS2000, a few increments ago. However, I have found another problem in FS2000 which may cause it to crash when you enter the FSUIPC options. I'm fixing that now -- please download 3.919 later today. Regards Pete

Ah, excellent. Well done! It won't be hidden, at least it isn't set to be hidden by FSUIPC. Maybe you have Windows set to hide known filetypes from you, simply identifying them with the main name, like "FSUIPC". If so, the FSUIPC.INI and FSUIPC.LOG files would also have their types hidden. Windows might assume a KEY file to be a registry file. The FSUIPC.KEY file is the only place your name and email address is stored, and that is where FSUIPC reads it from. It is most certainly on your PC, and in the same folder as FSUIPC, else it could not possibly show in the Log file! They cannot possibly be the actual current FSUIPC files then, unless you moved them there. FSUIPC only ever reads and writes its files in the same folder as itself. Why on Earth are you dependent upon FSUIPC to use a Saitek device? They don't rely on FSUIPC -- they certainly don't pay any license for it. I am sure they must have their own drivers for it, or else Windows handles them automatically as standard HIDs. Regards Pete

No, please don't do that. Go back and uncheck that option. It is not what is requested and is not required. When you are asked to run FS as administrator, you do it ONLY for that one time, and it is an elevated administrator position you obtain. Find the FS9.EXE or the FS9 icon on screen, right click it, do NOT select "Properties", but instead select "Run as ..." then "Administrator", or just "Run as administrator" (this varies slightly depending on version). You most certainly do have an FSUIPC.KEY file in the modules folder, as the log shows: These parts of the log are obtained by actually reading the KEY file! No other possibility exists for those lines. The details are stored no where else. I suspect you have allowed FS to install itself in its default place, in "Program Files". This is really a big mistake with FS9 and before, because it isn't a Vista / Win7 aware program. These new versions of Windows protect all "Program Files" folders from being written to, even by the programs installed there -- true Vista programs store data in "ProgramData" or "Appdata" folders, pseudonyms for Document and settings folders. So, to allow older programs to run, Vista and Win7 both actually make new folders, hidden from non-elevated administrators, and keep the programs there. What you see in Explorer is only an alias, not the real folders. To find the real folder, you need to run Explorer itself "as administrator" (as above for FS9). Then you see the real folders, not the aliassed ones. You could also try turning off UAC (User Access Control) as this is responsible for much of this confusion. Note that many many FS9 add-ons will also face difficulties with FS9 is aliassed folders, as they won't be able to find what they need to even write to where they want. In the long term you might be far better off uninstalling FS9 and re-installing it into a good folder like C:\FS9. Then you won't get any of these further administrator hassles later. Regards Pete

No, not really, as the changes since 3.75 have been enormous. If you are happy enough with 3.75 and don't need any more support from me, then I suggest you stick to it until you bring your flight simming up to date. i was actually surprised you are actually using Windows XP, which is far more recent than FS2000, showing that you aren't totally averse to getting relatively up to date! ;-) If you really do need a later version of FSUIPC the only way may be for me to somehow find a second-hand copy of FS2000, or maybe send you a test version with some debug code included so you can do the testing there. It is a shame this problem wasn't discovered a few weeks ago -- it was only last month that i had a good clearout and got rid of everything before FS2004! I originally kept all that stuff for nostalgic reasons, but I decided I needed to actually move about my office a bit more! ;-) [LATER] I just found my FS2000 disks! I hadn't actually discarded them -- only all of the add-ons (I had just about every add-on scenery you could get for FS2000!). So, I'll look at your problem later today. Regards Pete

I don't think it will ever update them as a result of you changing payloads unless you visit the relevant menu and okay out of it. It should be possible to find out what procedures get called to do the propagation, but it is in an area I don't know and I never got very far. This is because with FSX came SimConnect which is (or rather was) an officially supported Microsoft interface, and FSUIPC4 uses that, not a hacked access. Regards Pete

With the default 737-800? I think the logic in FSX is broken. Er, offsets 0892 and 092A aren't bit oriented. They are values. For jets the starter value is 1. The value 4 is for props. Example 2: You press either L or R Engine Start and that engine shows START on the EICAS and begins the spool process and eventually fires off and settles. Surely, for a jet, it shouldn't "fire off" till you enable the fuel by moving the start lever to the idle position -- performed in FS by full mixture (16384 to offset 0890, etc). Then when the compbustion flag is seen 0894 etc) you should return the start switch to 0 or 2. Hmmm, very strange. I had something daft like this happening for a little while with pmSystems -- not the same. I got one engine started okay, then when the next was started the first cut out. I never proved for sure what was causing it, but i think it was something to do with the N1 or N2 values being too low, as I could never reproduce it with a slightly higher throttle setting. And then the symptom disappeared in any case. To see what is happening between FSUIPC and FSX, enable some monitoring and logging. Enable logging of Events (one of the items on the left hand side of the logging Tab). And on the right-hand side set monitoring on 0890, 0892, 0928, and 092A, all as U16. This assumes you have start levers. If you have mixture full enabled all the time then maybe instead monitor 0892, 0894, 092A and 092C so that we catch the "combusting" state too. Below the list enable "normal log" (or whatever the top left selection is called, for logging). Then we'll get the SimConnect changes logged too. Just do this logging during a start sequence. Try and get one of each of your variations so we can see what is happening. But before any of this, can you check and list what add-on programs you might be using which could interfere, and also, of course, as always, state FSUIPC version number, FSX mod state andwhich aircraft you are talking about? Regards Pete

No, it won't be if FS is crashing -- obviously when FS crashes, FSUIPC gets stopped and can log no more. So, the questions now are: does it get further when FSUIPC is not in the Modules folder, and is this otherwise a pure FS2000 installation, or have you added anything else, other than FSUIPC? I might have to see if I can borrow a copy of FS2000 to check it here, buyt lets see if I can sort it without first. Regards Pete

Not supported, for a long time. Please always update to a supported version (3.90 or later) before posting. Yes, I know, and it is documented that way as no one ever found a way to propagate the change through the system. You didn't read this in the offsets documentation? Pete

Does my TrafficLook utility show the traffic? Are those freeware/payware TCAS systems using FSUIPC to obtain their data? If TrafficLook shows the on-line traffic, then FSHost or something (AIBridge?) must be injecting them into FSUIPC. If this is the case, and PMDG TCAS displays use FSUIPC for this, then I can only think that the PMDG gauge is making some discrinmination based on the ID of the injected aircraft. If TrafficLook does not show the aircraft, then you have nothing telling FSUIPC about the on-line aircraft, so the information is not available to any add-on reading the data from FSUIPC. As far as I remember, for FS2004 the data either needed Jose Oliveiras "AIBridge", or the automatic injection from Squawkbox 3. I don't know anything about FSHost and that method. FSNav does not use FSUIPC. Regards Pete

That's the correct thing to do. You cannot have the two programs registered to different people on the same installation, and your unique identity is by both your name and address/email (names alone are seldom unique). The need to have them the same is documented in the FSUIPC user guide. Regards Pete