Pete Dowson

Sorry, but I don't know any way to implement the taxi wind facility in FS2004 at present. I did spend quite a lot od time on this, and was hopeful at one time, but failed miserably. i am hoping that Microsoft will one day realse some information which may help. Regards, Pete

I expect Jose, the author, will answer you better than I, but the reason is likely to be that the Multiplayer Protocol for FS is different in FS2004 than FS2002, and the Microsoft SDK for it isn't available yet to enable such programs to be made compatible. Regards, Pete

Hi Ulisses, I attach a corrected version of the FS2004 controls list. Sorry. The first version had the second table (supposedly in numerical order) in almost a random order by the looks of things! :oops: Regards, Pete FS2004controls.Zip

Yes, the registration belongs to you, for use on any of your PCs. I do not charge per installation, and in fact FSUIPC on one PC has no knowledge of any FSUIPC installed on another! Just enter exactly the same details on each -- the name, email and Key must be exactly the same for each installation. If it worked for you on one PC it must work on all the others, otherwise you are making a typing error in the entries somewhere. Regards, Pete

If it is freeware then I'd need details as laid out in the access registration document, now part of the FSUIPC SDK. I would normally expect the author to apply, though if he is no longer interested in his work I could try to deal with it separately. Take a look at the "sticky" thread about FreeWare keys above. Certainly if you register your FSUIPC then it won't be a problem. With the way some Gauges accessed FSUIPC in the past it may not be possible to grant it an access key even if it is freeware -- too many were written as if they are external applications, and that's not valid for internal parts of FS. You can tell by looking at the FSUIPC LOG file -- if it says a Gauge or DLL is trying to access FSUIPC, then it would be okay. If it says FS itself is, then it is not resolvable without software changes in the gauge, except by registering FSUIPC, that is. Regards, Pete

No, they don't interact. Though, for supporting purposes it would really be better to use the latest versions always. You don't need to do anything other than copy the two DLL's and the FSUIPC.KEY file from your FS2004 modules folder to your FS2002 modules folder. Regards, Pete

Sorry, no. I don't use Esound, I haven't for years, and I can't really support it. Are you using a standard FS-supplied sound or one of your own creation? If the latter, please try a standard FS sound first, in case it is merely due to some incompatible sound format. If you tell me which version of Esound you are using, and attach a ZIP of your Esound.cfg file, I can try it here and see if it is something obvious. Regards, Pete

The errors seem to be related to specific AI aircraft IDs -- Speed Bird 2466 Speed bird 8085 Speed Bird 1485 Speed bird 2738 etc. The common thing (apart from them all being British Airways) is that they are all 15 characters long, which is rather odd since FSUIPC 3 should be only allowing them to be 14 characters at maximum -- the other character has been stolen for use in providing the "status" indication. It looks like there's a bug in the way FSUIPC itself is providing the string data for the names. Sorry about this -- it is very odd it hasn't cropped up before, as it must have been like this for over two months now. I will check it and fix it in the next version (3.11), within a week or two. Thanks for the notification! Regards, Pete

Did you re-install it, or just copy everything across? I might try it here. Not that I want to use it, just to see why this is different. I am wondering now if this is a different cause of "spikes", not the ones fixed by FSUIPC, because, as I said, the actual part of the code which those options enable makes no differentiation at all between FS2002 and FS2004. I'll take a look some time this week (a bit tied up now). To save me some time, could your get the thing doing it, and save a Flight, please? ZIP it and its WX file (and FMC file if there is one), along with your FSUIPC.INI file and FSUIPC.LOG file -- all in one ZIP -- send it to petedowson@btconnect.com. I can't promise anything, because this may not be easily fixable, but I'll take a look. Regards, Pete

Have Wilco released a version of 767PIC which works with FS2004? I wouldn't have thought the FS2002 version would work properly in any case. The action within FSUIPC is identical for this option, whether you are using FS2002 or FS2004, so I don't know what is going on there, unless it is a revised version of 767PIC which is doing something different. I assume you are using a user-registered copy of FSUIPC and have enabled the facility in the Technical page of FSUIPC options? Can you tell me which version of FSUIPC you are using? If it isn't 3.10, try that first. Regards, Pete

Hi Stuart, The flaps stuff was pretty easy to do so I've already sent to a Beta to check out, by email. Let me know. Thanks. Pete

Ahapologies. I really don't know without studying it further, whether it can or cannot be done, but I will put it on my list of things to look at soon -- maybe later this week or early next week. No promises, though. Regards, Pete

I don't know what a "cueing algorithm" is, but what values is the EPIC card getting which you can't get direct from CFS2? I don't understand where the EPIC comes in. Check the FSUIPC SDK (available at http://www.schiratti.com/dowson) and see if the data you need is listed. I'm afraid I cannot guarantee much for CFS2 -- FSUIPC is really aimed at FS and it is only by coincidence that some things are okay in CFS1 and (more so) in CFS2. Regards, Pete

I assume you mean 3.08 and 3.04, respectively? Can you first try 3.10, now available, just in case? I am not aware of anything I do which will affect trim or autopilot, but so I can compare your results, perhaps you can enable IPC write logging (in the Logging page of FSUIPC options), and Zip up a Log from FSUIPC 3.04 when it is okay, and one of FSUIPC 3.10 if it is not. I'll try to work out why it should be any different. Please also include your FSUIPC.INI file -- Zip them all up and send to petedowson@btconnect.com. Thanks. Pete

I don't know of one, though I do recall someone providing a reference to some basic examples before. Have you done a search here? It is probably still in the Forum somewhere. Basically, I normally advise to start by writing a Gauge, for which there are MS SDKs. Gauges are DLLs with the same sort of module linkage, but loaded by PANELS.DLL instead of by the FS EXE at initilialisation. Once you have a working gauge written in C you are over half way there. (Don't use XML, that won't help). Regards, Pete

Yes, of course. As detailed in the announcements here, I do offer free registration of FSUIPC for those who donated enough early on. But I don't have the mechanism here. Can you please send the details to my email address petedowson@btconnect.com? Thanks. Regards, Pete

Ouch :wink: Sorry, I haven't the patience to work through that, I'm afraid -- at least, not unless I realy have to! :) If you are talking Buttons, then you should note that, as mentioned in the Release Notes for FSUIPC 3.10 in the Announcements above, there's been a bug in recent versions of FSUIPC that stopped the repeat option working. Try again with version 3.10, which is now available. It should work with any button programming system -- at least there's nothing I've put in to stop it doing so. Regards, Pete

[quote name="John EGPF Does leaving the maximums settings unchecked give my unlimited visibilty at lower levels' date=' regardless of what the MS weather thinks it should be?[/quote] No. You get whatever the MS weather says. But if the METAR is "CAVOK" then you'll get the maximum FS visibility, which really in not very realistic for the UK, and is going to be greater than your 60 miles upper visibility for graduation. If you don't want the odd upside down effect, then the maximum values need to be less than or equal to the maximum upper level visibility, do you see? Imposing maxima of 60, 50, 40 or whatever at surface level won't destroy the realism from the METAR reports, as they don't give such high visibility values in any case. I find the default maxima quite suitable for UK flying, or possibly a little lower than those -- maybe 30 miles in clear skies, down to 10 when it's overcast and raining. Regards, Pete

One way to see what is going on, which may help, is to enable FSUIPC's IPC read and write logging. Then first use WeatherSet2 (supplied with FSUIPC) to read the weather at a specific ICAOand then do the same with your program. Now just compare the logs for the two actions, this should show you what is wrong. If you need any help interpreting the logs show the extracts and I'll see what I can do. Regards, Pete

I don't think there's necessarily a "problem", as such. The difference in wind direction, from the example you gave, does look likely to be the Mag Var (magnetic variation -- the difference between TRUE north and MAGNETIC North, which varies from place to place). I suspect that the panel makers are showing the wrong one, but it is correct in its own way, just incorrect on the cockpit if the ND is set for Magnetic indications -- which it would normally be. Certainly, you should report this to the panel makers. Such errors were quire prevalent throughout the life of FS2000 and FS2002 too -- I think some were deliberate so that the value shown was the same as the Shift+Z value, but they were errors nonetheless. Regards, Pete

Key press repeating is surely dealt with by the keyboard itself repeating? This is why I provided no repeat options for keys, only for buttons. I'm really not sure why you'd need anything extra, nor how I would program it and avoid the standard keyboard repeats interfering. Can you explain? Regards, Pete

You can't have the throttle+reverser AND speed brakes (spoilers) all on one axis. You can have a throttle axis with part of it calibrated for reverse, but the spoiler axis is always separate. Instructions for setting up a throttle with a reverse section in FSUIPC's Joysticks section are given in the FSUIPC documentation. Basically you go to the main throttle (on the same page as aileron, elevator and rudder), and check the option to map it to the four separate throttles. It is those controls in FS which have a reverse range, you see. Then you go to the 4 throttle page and calibrate the 1st throttle with a reverse range and a dead zone at "centre" which is then your Idle position. Regards, Pete

Okay. I'll find some unused space and map these -- FS2002 and FS2004 only. If I need to access them procedurally (which is normal when I can't locate their storage allocations efficiently or reliably) they won't be updated on every frame, but I presume pretty much any fraction of a second delay won't matter roo much? I'll email you a Beta to check when I do it. Won't be today though, but probably some time this week. Regards, Pete

Oh, right. Yes, I've found the part of the Aircraft Container SDK which allows the definition of (any?) numbers of flap sets. And I've tried it with the 777 in both FS2002 and FS2004. You are right. Odd then that there's no gauge tokens defined for anything but "Left Flaps" and "Right Flaps". I wonder how the panels manage to show these things correctly? I've just found these variables in FS2002's SIM1.DLL TRAILING EDGE FLAPS0 LEFT PERCENT TRAILING EDGE FLAPS0 RIGHT PERCENT TRAILING EDGE FLAPS1 LEFT PERCENT TRAILING EDGE FLAPS1 RIGHT PERCENT LEADING EDGE FLAPS0 LEFT PERCENT LEADING EDGE FLAPS0 RIGHT PERCENT LEADING EDGE FLAPS1 LEFT PERCENT LEADING EDGE FLAPS1 RIGHT PERCENT TRAILING EDGE FLAPS0 LEFT ANGLE TRAILING EDGE FLAPS0 RIGHT ANGLE TRAILING EDGE FLAPS1 LEFT ANGLE TRAILING EDGE FLAPS1 RIGHT ANGLE LEADING EDGE FLAPS0 LEFT ANGLE LEADING EDGE FLAPS0 RIGHT ANGLE LEADING EDGE FLAPS1 LEFT ANGLE LEADING EDGE FLAPS1 RIGHT ANGLE and there are similar ones in FS2004. I can try to map these into FSUIPC's address space and see what they provide. I assume the 0 and 1 sets are inboard and outboard? If not, what? Alternatively, I could try to interfere with the value going to offsets 0BE0 and 0BE4 -- "correct" them according to these other values. Though I'm really not sure how I should combine them all. Currently the offsets 0BE0 and 0BE4 are actually two of the very few still in GLOBALS.DLL and still updated directly by FS, no FSUIPC involvement. This is applicable to FS2002 as well, so how come the first request comes two years late? Very strange. No! Check your arithmetic :) 2910 + E0 (=decimal 224) gets you to 29F0. I don't do silly things like that, honestly. :D Regards, Pete

Sounds like it could be one of two things. 1) The ND implementation is wrong, in that it is showing the direction in degrees TRUE, not MAGNETIC. Assuming you are using FS2004 the Shift+Z display shows the wind in degrees magnetic -- this is different from FS2002 and before where it was shown TRUE. If the difference in direction is the same as the local Mag Var, then that's your answer, and warrants a bug report to the panel makers. The difference in wind speed will be just a rounding thing. One is rounding off the other up. OR 2) The gauge code is actually getting the wrong wind data. I think this is unlikely, but it is possible and would certainly be indicated if the difference in direction was not pretty close to the Mag Var all the time. I should add that neither of these phenomena are related to anything FSUIPC can do. Those panels will be dealing direct with the relevant internals of FS, normally via PANELS.DLL. BTW, it may be that the lack of mag var correction in the ND's is because, in FS2002 and before, the same programmers wanted to make the ND show the same as the Shift+Z display. This would have been wrong, because if the ND is showing MAG directions (track or heading), the wind arrow should, of course, also be Mag -- but maybe when it didn't show the same as Shift+Z folks complained and the programmers gave in! As an aside, I see that FSNav is still showing the wind direction in degrees TRUE as well. Regards, Pete