Pete Dowson

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

Phew! I had to dig out my EPICINFO document just to understand what you were talking about. I'm sorry, but I haven't used EPIC for several years. Hmmm. That doesn't necessarily follow I'm afraid. I seem to recall I never knew how to identify them exactly except by trial and error. I did once actually edit the Registry, giving each of the EPIC joysticks a different name, so I could tell. That worked for a while, but it is very messy and dangerous to do. I did ask Ralph Robinson (R&R) if he couldn't install them all with different names, but I don't think he ever got around to it. Well, this shows something changing, slightly, in the axes. Not enough to notice I suppose. Random jitter perhaps? According to my Microsoft jostick API refernces it means "joystick unplugged". Most likely thing is that you've got the wrong joystick number. Try using the JoyView program (from Thrustmaster) -- if you can find it still. If not, I may have it buried somewhere in my archives. It has always proven very useful when trying to sort EPIC axes and things out. You can monitor what's being changed in the PM MCP using FSUIPC's Monitor facilities. The offsets you need to monitor are listed in the PM offsets document (on the PM documentation site). They are all 16 bit words (U16 or S16) at offset 5406 onwards. Regards, Pete

The landing gear control in FS is only a switch (on/off in other words), you don't really get to control it's position, only tell it to go up or down. Whilst it is possible to program buttons to send axis controls with particular values, the reverse (to make axis inputs with particular values send button controls) isn't possible with FS nor with anything of mine, I'm afraid. Having said that, there is a "GEAR_SET" control in FS. At least it is listed (see my List of FS2004 Controls in the FSUIPC ZIP). Whether it actually does anything in FS2004 or not I don't know, but the big problem is getting it assigned. Even if you edit the FS9.CFG file and add the details for it there, it looks like FS2004 deletes any axis assignment other than the declared AXIS_.... ones. [LATER] I've tried setting different GEAR_SET values by programming buttons to send it (in FSUIPC) with different values. The only one which seems to do anything is a parameter of 0, which raises the gear. None of the non-zero values I tried did anything, not even 16383 which I would have expected to operate it. So I'm sorry, it looks like you'll need to use a toggle switch or button instead. Regards, Pete

This is confusing. Did you write to Project Magenta support with the same questions? This looks identical, so I'll repeat my replies for the benefit of other readers -- though you will actually find your answers in one or other of the threads already here. One quite recent one, in fact. No, it is caused by some bad gauge programming somewhere. Microsoft have been very specific about this. I consider it a weakness in the design of part of FS, but they say that if folks designed their gauges correctly it wouldn't happen. Therefore it won't be "fixed". The acceleration from units of 1 to units of 10, or whatever, is triggered by a second control following the first within so many milliseconds. I'm not sure of the actual interval off-hand, but it relates to normal keyboard repeat rates and so on, so is around 30-40 mSecs. Really, I think the acceleration should ONLY occur if the second control, arriving so close, is the SAME control as the earlier one. But for "efficiency" (if you like) MS don't bother to check. They just assume that if two controls arrive so close together they MUST be the same. After all, if they are being generated by user action, there's no way he could change so fast, right? The culprit gauges seem to be those which, for some reason best known to their authors, send controls to FS continuously at ridiculous rates, many every second. The first panel in which I met this was the 767PIC on FS2002, which is when I added the "acceleration fix" into FSUIPC. For some daft reason that panel was sending controls like AP off 20 or 30 times a second! No wonder some of these panels slow FS down so much! So much waste! Unfortunately it seems that, with the development now of XML gauges, my fix (which merely fiddles FS's acceleration timer if it sees a control which is different from the previous one) doesn't work with all gauges. The XML gauge "events" bypass the method I use to detect them. Ah, not FSUIPC 3.61 as in the email! :wink: Please note that the current version is 3.44. I really cannot support old versions, especially as old as that! Anyway, FSUIPC isn't relevant. Take it out and you'll get the same results. Why? Just stop writing gauges which continually send controls to FS. There should be no need. At least test values before sending controls to see if they would actually do anything useful. Things like setting the A/P off 20 times a second are daft if the A/P is off already. Et cetera. Regards, Pete

It doesn't mean to say it would have worked properly. It would have depended what was also being loaded before it. The whole business of logging and reporting on accreditation was tidied up to avoid some of the confusion the earlier laxity induced. The gauge may simply be a renaming of one of the other freeware TCAS gauges. If it is then renaming it back to its original name might help. Check the freeware key list above. You could try right-clicking on it in Explorer and checking Properties-Version. Regards, Pete

Are there URLs for further info? I don't recall those. Let me know so I can either delete them or update them. In order to transfer data between two processes, there are a limited number of choices. Don't forget that separate processes run in separate virtual machines, with their own virtual memories. They cannot see each other directly. The choices include the obvious one -- writing a file to disk for the other to read -- and also "pipes", which is a sort of serial link managed by Windows, and DDE (Direct Data Exchange) which was favourite in Windows 3.1 days but I think is rather inefficient (though with the right stuff installed does have the advantage of working over Networks, nowadays, I believe). The method used by FSUIPC is actually one also used by debugging API facilities to read and write process memory. It is memory-mapped files. All that happens is that the client program creates a memory-mapped file, with a unique name generated from its process ID and a few other things that FSUIPC can check. Since it cannot actually TELL FSUIPC this name (it cannot place the string in shared memory until the memory is shared --- classic chicken and egg dilemma), it registers the string with Windows as an Atom name. Atoms are guaranteed unique in the system. Windows provides an ID number for the Atom, which the Client can pass over to FSUIPC in a Message. This allows FSUIPC to obtain the memory-mapped filename, by asking Windows for the string corresponding to the atom number. Thus, it can "open" the memory mapped file, and read and process the data, placing the results back into the same area for the client to read when the Message call returns. There. Simple, eh? :wink: Most folks don't need to know all this, BTW. Just use the stuff provided. :) Regards Pete

I bet it didn't start FliteStar either, eh? To make shortcuts I just use the mouse, drag the EXE to the desktop bu press the ALT key before releasing. I think that works with all versions of Windows. Regards, Pete

They should be written to your FSUIPC.INI file. That's where everything is saved. What version of FSUIPC and what version of PFC.DLL? Check that you haven't protected FSUIPC.INI as read only. Check that it isn't corrupted -- show me the Buttons section if you like. If you haven't much invested in FSUIPC settings already you could simply try deleting the INI file so it makes a new one in any case, or at least test things by moving it out of the Modules folder for safe keeping. But, if you are not using FSUIPC 3.44, please make sure you update it first. Regards, Pete

It won't become apparent on its own. The offsets you would need to get the 737NG MCP values to the GF MCP display are not published by PMDG, though they have been hacked. Since I have an agreement with PMDG regarding its use of FSUIPC it would be unethical of me to help you further on that without PMDG's permission (which I've tried to obtain several times in vain). You will have to search for the information yourself I'm afraid. Sorry. But didn't I read, somewhere, that GoFlight themselves had at last come to some arrangement with PMDG and will be supporting it with their own drivers? Check the GoFlight website. Maybe I was dreaming? Regards, Pete