Pete Dowson

FSUIPC prior to version 3 will work on FS2002 and needs no registration. It works with the FS2002 VA tools such as Squawkbox. I'm sorry, but I am not an on-line flyer and cannot sort this out for you - you need to contact the on-line flyer's support fora. Regards, Pete

Okay. Let's assume it was something odd in the previous setup then. Regards, Pete

Good. That is the correct way. I don't have any records as I don't issue the keys. Regards, Pete

This seems to be in the wrong thread! You may want to post this in the cockpit building forum, or in some FSBus site. Certainly the hardware you are talking about is completely outside my experience. Sorry. Regards, Pete

I know for certain that the RealityXP stuff doesn't use FSUIPC. I don't know the other one, but I am very doubtful than any weather radar uses FSUIPC -- the information just isn't there, and I don't know how to get it. I know RealityXP cracked it. Sorry, what does that mean? I don't understand it. All FSUIPC is doing for weather is allowing external programs to read it and write it. There's no radar support at all. Take it out and see if either of your radars complains. I doubt they will. I think you may need to contact the support site for your gauges. Sorry. Regards, Pete

Check the PM website. In the Documentation section there's a document on FSUIPC Offsets used by PM. You can do anything that lists. If the RJ features you need are not dealt with in the FSUIPC interface, FSUIPC cannot handle them, you need to ask PM support. Regards, Pete

If you haven't resolved this yet, please send an FSUIPC.LOG showing the problem, to petedowson@btconnect.com. ZIP it please. Regards, Pete

More offsets for what? Can you be more explicit? FSUIPC currently offers almost everything available in FS. Those bits it doesn't aren't included because I can't find them ort don't understand them. Regards, Pete

I've really no idea whatsoever what is going on. Can you be a little more explicit about what the problem is? Then maybe I could hazard some guesses. When the FS A/P is enabled, the throttle inputs should have no effect. If the panels are configured to assume changes on the throttle inputs should disengage the A/T, then it sounds like you have some jitter on your throttle quadrant. Try calibrating with parking spaces at max and min throttle (and park them when using A/T), and also enable the digital filtering. Note that, with PFC.DLL, if there's no change detected on the throttle levers, no messages for throttle changes are sent to FS. Regards, Pete

Have you tried enabling wind smoothing? Regards, Pete

Sorry, I'm not sure I understand the question. Does the panel have its own systems, not using FS systems like autopilot and so on? If it does its own thing (like ,for instance, PMDG's 737NG) then it is unlikely, unless he has published some interface for you to program to. FSUIPC gives access to FS mechanisms and also Project Magenta. Regards, Pete

When you say "recently", is there something you have changed, or do you mean just after installing AS2004 and FSUIPC 3.317? Those are very worrying. I'd like to see what IPC calls are being made which causes these. Could you repeat the terst, please, but first enable IPC read and write logging in the FSUIPC Logging options page? The Log will be long, so ZIP it please and send it to me at petedowson@btconnect.com. I'll send you a newer version of FSUIPC to see if it still happens. If so, logs for both please. Regards, Pete

Unfortunately you cannot have wind smoothing and turbulence. The only method I found to smooth the winds effectively in FS2004 was to attack them at the simulation stage, i.e. just before they are implemented, and there's no way to distinguish turbulence from some of the violent wind changes which folks don't like. No, there never was such a facility -- only to suppress wind turbulence in upper winds, where they are less usual than in the surface winds (CAT excepting). Cloud turbulence is controlled by the bcloud bottoms and tops, but you might not actually be inside a cloud graphic to get it. Regards, Pete

Not sure you need to do that, though it does seem you didn't supply enough information? There's nothing in WideFS which is remotely connected to registration checking, and the re-installation of ActiveRadar on your Server couldn't possibly be seen by WideFS. All that the change in WideFS versions is probably doing is changing some timings very slightly -- a change to the next FSUIPC might do the same -- and so masking the error, whatever it is. The fact that it occurs on so few systems does indicate that the conditions needed for the error to manifest itself are critical. Maybe the re-installation so that 'clean' short files are being accessed does the same thing -- i.e. alter the timings slightly. Regards, Pete

Yes, but does, for instance, 6 go on-off before 5 goes on-off, or is there an overlap -- i.e. 6on, 5on, 6off and so on? It think if there's an overlap like that then it is easy to program. Otherwise it will need some careful thought. Yes, of course. Because the condition "(-j,b)" merely says "j,b not pressed", it is not an event, but a condition. So really all of the above amount to the same thing as: 82=P1,5,C65637,0 83=P1,4,C65637,0 84=P1,6,C65637,0 85=U1,5,C65636,0 86=U1,6,C65636,0 87=U1,4,C65636,0 which just gives you all 6 FS controls one after the other as you turn the rotary. I think that if the on's and off's are not overlapped, then you may be able to do it by latching (setting a flag) each time a button is pressed and clearing all the other flags. I'm convinced it can be done, but it is very fiddly. Check first if the on/offs are overlapping as that will be much easier. Regards, Pete

The only reports ever of such a problem have either been: 1) An early-ish version of FSNavigator, released for FS2004, did some sort of odd check for FSUIPC and hung doing it. To see if this is the culprit, try putting FSUIPC back in and taking the FSNav DLL out instead. If that fixes it, see about getting an FSNav update. 2) On any operating system other than WinXP folks seem to have a variety of different problem with the way 3.20/3.30 scans joysticks buttons. I've not seen any reports of this for WinXP, but either way please try adding this to the FSUIPC.INI file before running FS: [buttons] PollInterval=50 (or just add the last line into your [buttons] section if one is already there). Please let me know either way. In the next version I am defaulting this parameter to 50 for Win98/Me/2K and 25 for XP. Regards, Pete

I've no idea, since you don't explain how the direction of turning the rotary affects these buttons 4, 5, 6. You'd need to program them so that when 25 and 26 are on you set Mags OFF, and so on. You more or less defined it there already. After this message I am off-line for a week -- back 25th September. Regards, Pete

Really? I think you will have to investigate a little more. The inverter is just a generator, a particular way of generating electricity. There are generator switches. You will need to think about the possible alternative names used in different aircraft. Alternator is another term for the same function. It is highly unlikely that there is anything in the standard FS cockpits not covered in one way or another. Add-on aircraft are different, the programmers can add what they want and not supply any programming information to the outside world. After this message I am off-line for a week -- back 25th September. Regards, Pete

Sorry, I don't know Delphi, but there is a Delphi section and example in the FSUIPC SDK. Isn't that specific enough for you? If you want folks to help you may have to be a little more specific. Regards, Pete

"Need more offsets"? Do you really mean you need more information? just download the FSUIPC SDK from http://www.schiratti.com/dowson and check the Programmer's Guide. Regards, Pete

Yes, it is a void function (returns nothing), but I think it has two 32-bit parameters passed to it, the uses of which vary according to the chain number. Okay, I'll be interested. As I said, a lot of the work is designing for minimal impact. Regards, Pete

You cannot, it is not possible with WideFS or with one installation of FS. Did you miss the part right near the beginning, in bold proint and a bold box? The part that starts out like this: See the bit about not for cockpit views, and only for external applications? Isn't this clear enough? It is emphasised pretty boldly. Regards, Pete

Ah, yesdoesn't help! glad you got it sorted! Regards, Pete

Please, to start with, don't try to use FSUIPC to calibrate axes until they are working reasonably well in FS2004 as is. All FSUIPC is doing is taking the results of the FS assignments and calibrations and scalings and allowing you to define the end points and centre zones more precisely. It is dealing not with the Joystick but with values inside FS, the final values just before they are passed to the simulation engine. This means that if they are in a mess and not working properly before you start using FSUIPC, all you can do is make things worse. You need to start by ensuring good calibration in Windows itself, in Game Controllers. Also you might want to add the line "stick_sensitivity_mode=0" to the [Controls] section of your FS9.CFG. Maybe you did this for FS2002 and forgot? It makes the axis inputs linear instead of time-based. THEN load up FS. Do this without the FSUIPC calibrations -- delete the Joysticks section in the FSUIPC.INI file if you've not used it for any of the others -- otherwise go to the appropriate pages in FSUIPC options after FS is loaded and press the relevant "Reset" buttons. In FS, assign the axes to whatever functions you want to use them for, and ensure the sensitivity is high and the null zone low (otherwise you are immediately losing a lot of the input detail). Also make sure there are no other assignments to the same functions. If you have multiple joystick connections, go through the list of axes for each joystick and delete any conflicting assignments. Now try them in FS. If they more or less do what you want, by all means refine them in FSUIPC. If not, there's some problem which is really outside my field of knowledge. You want to find the forum in which Bob "Sticky" Church visits -- he's a real joystick expert! Regards, Pete

What is "filled in by FS" is the pointer in your ImportTable to each imported Module's "Linkage" structure. And, yes, the poniters are exactly similar to the Init/Deinit pair in all of the Linkage structures -- but it isn't those which are filled in by FS. It is almost universally, though of course it doesn't have to be programmed that way. Any, I've just looked them up and the calls for Chain and Unchain are at offsets off the base EXE's Linkage of 0x438 and 0x43C respectively. This is in FS2004 only. That should make it easy for you to spot them. I am pretty sure the closest you'll get to a frame rate call is chain 0x13, though in FS2004 that seems to go twice as fast when the flight mode display is showing (Shift+Z). Very odd. I had to take special steps to deal with that. All of which are, if anything, easier to do without impacting FS performance from an external program, whether on the same PC as FS or on a separate PC interfacing through WideFS. Running inside FS means taking a great deal more care about how you organise the program and perform the tasks you are doing. Instead of having Windows timeslice for you, you are now responsible. It is MUCH more difficult not to impact FS performance from a DLL or Gauge than from an external program, where Windows is helping considerably. Much of the 5+ near full-time years put into FSUIPC and WideServer has been spent on making sure they have minimal impact. If you run FS on an Intel P4 with "hyperthreading", FS only appears to run in one of the two virtual processors. You can add a few ancillary programs running in the other without any noticeable impact. Of course, it is still best to offload all your joystick, serial and parallel processing activity to another PC if possible. Regards, Pete