Pete Dowson

Yes. You will have to do this by editing in the FSUIPC.INI file. You can do it by using the facilities for setting and clearing flags and having conditional actions. Check out the Advanced User's documentation. You could also do it by using FSUIPC offsets - incrementing one and making other actions on the same key dependent upon the value. But for that you need some publically available offsets. I will be releasing a batch of those soon, mainly aimed at making it easier to use my GFdisplay (Go Flight display control program), but they could be used for anything, providing that it's for private use (so avoiding clashes between different products). Look at flags first though. Regards, Pete

Good. Have fun! Pete

It looks like your aircraft has about three gauges which are attempting to access FSUIPC using the external application methods, which have not been "legal" since the special internal access facilities were provided in the SDK in the FS2000 era. The method of identifying the caller so that it can be accredited goes wrong when the wrong entry calls are made. Furthermore, even if your copy of FSUIPC were to be user-registered (which would certainly overcome the illegal access problem), it is still possible for the separate callers to clash with each other, on occasion, because the external entry method depends upon process IDs and they will all be the same for internal gauges and DLLs. Is the aircraft you are using an old one? You say it happens each time you "click on an aircraft", which is ambiguous. Do you mean any aircraft or just this specific one (Blackhawk)? If it is occurring every time, then maybe it is an add-in DLL which is doing it? If you'd like me to investigate further please do this: 1. Before loading FS, edit the FSUIPC.INI file, adding the lines Debug=Please LogExtras=2048 LogReads=Yes LogWrites=Yes to the [General] section. 2. Run FS, but please, for this, do not run any extra external programs like AS2004 -- the Log will get too big. 3. After the error, close FS. Then ZIP up the Log file and send it to me at petedowson@btconnect.com. 4. Edit the FSUIPC.INI file again and remove those lines you added above. Please also tell me what operating system you are using on your PC. Regards, Pete

If you moved to a new PC or reinstalled Windows, just copying the KEY file won't work. You need to re-enter the details exactly as before. If it isn't working then you've probably got something wrong. Open the original KEY file with an editor (e.g. NotePad) and check -- cut and paste if you are not sure of any of the characters. Once you've done it for FSUIPC or WideFS, for the other you would just need to enter the key, although by then your KEY file should work. Regards, Pete

Ah. I wish you'd said it was registered in the first place. With a correctly user-registered FSUIPC the Gauge registration is not relevant (it is bypassed -- though as an aid to developers FSUIPC still logs it as good or bad), so Mr Capt's reply was not actually at all relevant, unfortunately. Just as an experiment, try removing the FSUIPC.KEY file from the FS Modules folder and see if it then works. If so, then it sounds like there is something wrong with your user key (or FSUIPC's checks on it). In that case, please Zip up the FSUIPC.KEY file and send it to me at petedowson@btconnect.com and I'll work out what is happening. If, however, it still does not work, then I'm afraid we are dependent upon Mr. Capt finding out what is going on, as the log shows that the interface is working perfectly correctly between the gauge and FSUIPC. You could, also, enable IPC read and write logging (in the FSUIPC Logging page), which will show us the sort of interchange that is happening. But take care, the Log file could get very large. Hmmm. There's no interface for such things in FSUIPC in any case, so that is something else. Maybe it will take ZIPs? Regards, Pete

How did you "unregister" it? When you update FSUIPC all you need to do is copy the new DLL over the old one. Don't delete your FSUIPC.KEY file, or you will have to enter the details again. No. Unless you've done something wrong, like published your key details openly for others to use, or told your credit card company to stop payment. In either case your Key will be blocked. I am emailing you about this. Regards, Pete

Version 3.44 is current. I only support the latest version, so please do upgrade when you can. The entries which are blank are simply those which no one has confirmed to me as being correct and working. I am not an expert in all these things, so it isn't any use just me checking them. I think they are correct, but someone who knows what he is looking at would need to confirm this before I mark them as "ok". If you know how to derive the same values from others, then you can check them that way. On the other hand, maybe some or all of these are saved in the FLT file, so if you Pause, save a flight, then compare the saved values with those read here by, say FSInterrogate, then you could verify them that way. I think this is how I checked some of the others, but the FLT file naming for this stuff is not always clear. Let me know when/if you do verify them and I will mark them accordingly. Thanks, Regards, Pete

I assume you are using a free install of FSUIPC? i.e. you've not registered it? Can you show me the Log file please? I need whatever information is included in the file, as Mr. Capt pointed out already. Also please tell me if you are using Windows 98 or Windows XP, or what other? Then, AFTER getting the Log for me, please, you can also try manually registering the gauge, before loading the aircraft. Do this by going to the FSUIPC options (Modules menu, FSUIPC), selecting the "Register an application program" button, then entering the details Mr. Capt gave you. i.e. Program: ACS.Zulu-MD11.gau Key: EHTM OBYE XWXI You will only need to do this once, as it is remembered in your Key file. If this works, and you are using Windows 98 or Windows Me, then it may be the same problem reported to me yesterday with another program entirely. I am working on this now. But I need to see the log, and know the version of Windows you are using, to be sure. Thanks Regards, Pete

I assume they must know about it? Best to notify them anyway, just in case. Regards, Pete

Test the spoilers in the air, not on the ground. See the thread "Spoiler axis problem!" below (http://forums.simflight.com/viewtopic.php?t=33430). Rob Barendregt gave a very full explanation in one of the messages in that thread. Regards, Pete

Hmmm. I don't know how that's supposed to work, then. Seems as if they've got something wrong with the programming. They need to implement a delay between the messages. Neither FS nor FSUIPC queue them. If a new message arrives it will replace the preceding one. There is a facility to specify a number of seconds for a message to be delayed before it is cleared down automatically, but another message arriving supercedes that. This has been how it worked since FS95 days (when it was "adventures" which did the displaying, hence the name of AdvDisplay). Regards, Pete

Did you make the Advdisplay window big enough for all the lines? Also, that ATIS transmission seems a lot bigger than the 128 bytes AdvDisplay can cope with, or FSUIPC come to that. Isn't there any support for Ivap. No one who can tell you how to use their system? Is it supposed to be usable with AdvDisplay? Regards, Pete

If you've assigned it to the spoiler in FS, it will show up as the Spoiler in FSUIPC, not as a Throttle. Does it move the spoiler lever in FS at all? If it does not move either in FSUIPC or the lever in FS, then the most likely thing is that you have the FS sensitivity for that axis set at minimum. Set it to maximum, and while you are at it, set the null zone to minimum. It isn't a throttle axis if it is assigned to the spoiler in FS. Make sure you are looking at the right thing. FSUIPC can only see what is being sent to those subsystems by FS. If FS isn't controlling the spoiler with that axis, FSUIPC won't see it as a spoiler either. If it won't calibrate in Windows "Game controllers", and won't move the spoiler axis in FS, then it is very likely to be a fault. But check the other things first. Regards, Pete

The film star? No, Ralph Robinson! :wink: Regards, Pete

I'll have to go search the Microsoft documentation again. Hang on, I'll give you the whole list: JOYERR_PARMS 165 bad parameters JOYERR_NOCANDO 166 request not completed JOYERR_UNPLUGGED 167 joystick is unplugged That's all that appears to be listed. Looking up their meanings further only gives: 165 = The specified joystick identifier is invalid. 166 no other mention? Presumably a timeout someplace. 167 = The specified joystick is not connected to the system. Regards, Pete

FSUIPC is not actually processing axes as such, it is intercepting and processing the FS controls with the stated function. It is not a joystick driver and does not read the axes at all. In order to use an axis, you need to assign it in FS -- Options-Controls-Assignments. You will actually find the spoiler listed there, for assignment. When it is assigned in FS as a spoiler, FSUIPC will see it as a spoiler. If you assign it to something else, it will be something else. Regards, Pete

:? :( :? :cry: If you really want to have to register application programs, simply delete your FSUIPC.KEY file and don't register FSUIPC. By registering FSUIPC (you paid for it after all?) you get full access to everything without ever having to register an application program again. Why would you want to? Please read a little bit of the user documentation. What did you think you'd paid for? All the facilities and complete compatibility with any application! Pete

Any FSUIPC before 3.40 wouldn't have functioned in FS9.1 in any case. It wouldn't even let FS load until you took it out or updated. Yes, of course. It's a Microsoft module, same as their WEATHER.DLL or PANELS.DLL or any part of FS. It is simply an optional part of FS. Only things that interface externally to FS via FSUIPC can be run on WideFS. WideFS is simply an extension of the FSUIPC interface to networked PCs. Microsoft do not write anything which uses FSUIPC. Regards, Pete

Oh, right. I know the feeling! :wink: Glad you are sorted. You also get jitter filtering and slope selection in the current version, though slopes are only for the flight controls. Pete

TrafficLook runs fine either directly on the FS PC or via WideFS. I cannot imagine why yours won't work. Have you checked the FSUIPC log? Is this the current version of TrafficLook (1.54 I think) -- check by right-clicking it and selecting Properties-Version. There is certainly no difference in it or the FSUIPC AI facilities between FS9.0 and FS9.1, so if all you've done is upgraded FS from 9.0 to 9.1 then I'm afraid I've really no idea what is going on. Or did you also upgrade FSUIPC at the same time? If so, what was the previous version you were using? As a last resort you could try enabling FSUIPC IPC read logging (see the Logging page), then running it. The log will tell me what it is reading there. Please close FS afterwards, so the log is closed. ZIP up the FSUIPC log file and your FSUIPC.KEY file (both from the FS Modules folder) and send to petedowson@btconnect.com. I need the KEY file to check as well, because the only possibility I can think of at present is that there's something wrong with your user key for FSUIPC or WideFS, assuming you are user-registered. Regards Pete

Where are you looking? It's exactly the same in 3.44. On the first joystick page (1 of 8), bottom right, click map to 4 throttles. then go and calibrate on the 4 throttles page. Please also refer to the User documentation supplied. That's what it is for. The "map to 4 throttles" checkbox is even shown in the picture of the Joysticks page of the options, and not far below that there's a whole paragraph on it. Pete

No, I've had no other reports at all of any such problem, and I use TrafficLook regularly. It uses the same data from FSUIPC as the various TCAS and other AI mapping programs around, so if it didn't get the data then they wouldn't work either. Are you sure you have actually got AI traffic? Check the FS menu entries, make sure it is enabled. And make sure you've not lost the Traffic BGL. The default is "traffic030528.bgl" and lives in Scenery\World\Scenery. If you have add-on AI like MyTraffic, Ultimate Traffic or ProjectAI then this may be renamed or removed in favour of theirs, which could be there instead, but more often in the Addon Scenery folder. Finally, there are some AI scanning controls in the FSUIPC.INI. Try deleting that (or moving it out of the Modules folder, if it has any valuable settings of yours like Button, Key programming or joystick calibration), so that FSUIPC runs with default values. If that fixes it you have some odd parameter settings in the INI. Regards, Pete

Ahthat would have carried Adam Szofran's original stuff. Pelle Liljendal is the author of FSInterrogate, the very useful utility I include in the SDK. He was working on a new one with new facilities, including arrays and string support, but I think real work got the better of him for time. His website used to work fine -- he hosted loads of interesting FS programs. Shame it has gone. I certainly haven't heard from him for a while, though my emailed updates don't seem to get returned. I'll remove both links. thanks. Not sure where you get the "conversion" bit. there's no conversion in the stuff I wrote. You get what there is. And really the sequence is "a whole mix of all the reads and writes you want to do in one cycle provided they fit in the buffer space" then a single process, then go do your own thing before coming back for another cycle. If you think in terms of one process call for every single read and every single write you will have extremely inefficient programs. Yes. Though I don't know what you mean by "two bytes base". It's a 16-bit integer. Why not use FSInterrogate, which not only shows all this stuff in all sorts of ways, but even shows the conversions as well? That's what it is provided for! If you divide a 16 bit integer by 65536 you'll get zero, so multiplying it by 360 is no good. Try it the other way around. 4A FF is not hexadecimal "4AFF" because you are reading a byte display. Intel processors, unlike Motorola, use lo-hi representation, so the number id FF4A. You'd see all this with ease if you use the tools provided. FF4A hex = -182 decimal (-182 x 360) / 65536 = -1 as near as dammit. So I think your memory made an error somewhere if it was -3 (3W). 3W would be (65536 x -3) / 360 = -546 decimal = FDDE hex (or DE FD in two successive bytes). Please, please, PLEASE use FSInterrogate. You will find it an invaluable learning tool. Regards, Pete

Yes, it is the control value. The position read-outs, which you don't write to, are at 0BD4 and 0BD8. Regards, Pete

There aren't fixed positons in FS for the speed brake (called the spoiler in FS). They are mostly just different values for the spoiler setting, at offset 0BD0. "DN" is 0, "ARM" is 4800, but with 0BCC set NZ too, the Flight Detente for a 737, which is about 60-70% (sorry I don't know the exact proportion) would be 60-70% of 16383, and UP is 16383. Pete