Pete Dowson

No. All of the separate language packages in the SDK are aimed at external program writers. The only internal stuff is that in the ZIP for it, and it revolves around C, because that was the only support provided by Microsoft. The methods of module writing are derived from Gauge writing, for which MS provided an SDK. Until recently this was C (or C++ just about, with much care I would think) only, though you can also do XML gauges now. I don't really know how you'd go about making the structures work correctly for a module in another language, but then I don't really know any others than C and ASM. Either way, you will need to change the innards of whatever "wrapper" you are using, or write your own, to not only use the Open2() call but also, of course, supply the memory it needs for the data exchanges. Regards, Pete

AhI've not changed that part yet. I only added the facility to start and stop programs via KeySend. Ooops! [This is what comes of adding facilities for folks ad hoc!] I'll add this and send you a revised version. It may be tomorrow (Monday) now though. Regards, Pete

Unfortunately no attachment. I don't seem to be able to make attachments either at present, and I'm trying to find out why! If this is merely a message box containing a message, the words will do fine. But probably more important is the FSUIPC LOG. Possibly the program (or is it a gauge or DLL?) is not registering correctly with FSUIPC? In that case then possibly there's something wrong with your user Key? If you'd like to try again, then close down FS, Zip up the FSUIPC.LOG and FSUIPC.KEY files and send them to me at petedowson@btconnect.com, I can check things out. But the Log is always the first thing to check. Regards, Pete

I've tested the gauge on WinXP SP2 with no problems, but maybe I've disabled some of that Internet stuff. I'll check. I would have expected any pop-up stopper to only run when I use Internet Explorer though. There is certainly no reason why any such program should be running all the time in any case. it should start when you open up your browser (e.g. IE) and terminate when you close it. ANY process doing things in the background like that is something you most certainly do not want when flying with FS. It will reduce performance, and, worse, introduce stutters and jerks. Regards, Pete

I had a look and it was quite easy to do. Try this WideClient 6.453, which will work with WideServer 6.45 already released. The new Run/Close facilities, summarised, are: In each case N = 1 to 9 RunN= runs program when WideClient starts and when KeySend says to RunReadyN= runs program when FS is ready to fly and when KeySend says to RunKeyN= runs program only when KeySend says to CloseN=... closes program 'RunN' when WideClient closes CloseReadyN=... closes program 'RunReadyN' when WideClient closes or as controlled by Shut Down options and wideServer hot keys. CloseKeyN=... same as CloseReady, but for RunKeyN program. Then there are these new parameters for KeySend. As usual, the KeySend number M can be anything from 1 to 255: KeySendM=RunN to run the RunN program if not running now KeySendM=RunReadyN to run the RunReadyN program if not running now KeySendM=RunKeyN to run the RunKeyN program if not running now KeySendM=CloseN to close the RunN program if it is running KeySendM=CloseReadyN to close the RunReadyN program if it is running KeySendM=CloseKeyN to close the RunKeyN program if it is running I think this covers all the angles. Let me know how you get on! OUCH! OUCH! I am not allowed to add this small attachments! I'll be back soon ... Regards, Pete

I see. How odd. Have you mentioned this difficulty to the FreeFD author, or is it not in development any more? Obviously it would be preferable for it to have a keypress to tell it to load or reload a plan. I have added your request to my list and will see if there's a tidy way to implement it in the next WideClient update -- I am actually working on some small improvements there at present. But if, in the mean time, you do arrive at a better solution please do let me know. Regards, Pete

It doesn't? Writing 0 to 05DC should most certainly switch slew off in all versions of FS since FS98. See offset 05DE, as documented. That's the difference. Hmmm! It may indeed be the difference described in offset 05DE. In FS2004 there's no way to prevent the axes being swapped (there are separate axis controls in FS for slew mode). You may need to do something about those too. Check offset 310B. Regards, Pete

Jeppesen's? Do you mean FS's own downloaded weather? FSUIPC cannot interfere with the actual local weather so directly like that, only the wind and visibility at the aircraft location. You say you are getting the airport wind forecast/ATIS stated as 0/0 even when you have a local wind, so it really cannot be anything of mine. That is weird. Have you tried going into the weather menu of FS and explicitly setting the local weather at the airport to have some wind? Just as a test I mean? Do the weather stations actually appear correctly on the FS weather setting map? Is the rest of the weather at the airport "standard" (no winds, no clouds, pressure 1013 (29.92"), temp 15C)? If so, is this applied at all airports or only the specific one you are noticing it with? The FS defaults may be kicking in for some reason -- possibly the METAR station list in FS is corrupted. These files are used by FS: In FS's "weather folder": wxmapping.bin icao_pos.bin wxstationlist.bin which are, I think, the originals, plus, in the same folder as the FS9.cfg (i.e. Documents and Settings\\Application Data\Microsoft\FS9): wxstationlist.bin I think this one gets updated at times and may have got corrupted. Make a safe copy of it and either delete it (FS will probably make a new one), or copy over the one from the weather folder (assuming that one isn't corrupted). If the airports you've checked don't match the weather station list then local weather details from any source -- FSMeteo, AS2004 or MS's own downloads -- won't be getting assigned, and defaults may prevail. I really cannot think of anything else which could even come close to producing the sympptoms you describe. Regards, Pete

No, there's no such facility at present. No one has ever asked for anything like that. Why would you need it? All programs I know are happy to start up when FS is ready to deal with them, and that can be accomplished with the "RunReady" parameters in WideClient.ini. If you want some programs to start later than others you declare them in order (RunReady1, 2, 3 etc), and use the DelayReady parameters to put any number of seconds between them. I can certainly think about a way to do what you want, but I do like to understand the reasons first, as there are always so many other justified things to do. Regards, Pete

Ah, yes -- if it is using software emulation, not hardware acceleration, it will take a huge amount of processor time and not allow much for the other things, like Network operations! Good, glad it is resolved! Regards, Pete

It sounds like you have the "Auto Taxiwind" facility enabled. This reduces the wind to 1 knot when you are on the ground, to prevent the overdone "weather-vaning" that many aircraft a subject to. Just turn it off (in the Winds options of FSUIPC) if you don't like it. You don't say whether you are using FS2004 or an earlier version, but the other possibilities are that you have a low value set either for "Max Surface Wind" (FS2002 and before) or "Max wind speed up to 1000 feet" (FS2004). However in both of these cases the wind will be restricted well before your wheels touch the ground. No, it is certainly neither of those. I use 9.1 and AS2004 and there are most certainly ground winds. How are you measuring this, by the way? If it is from a properly programmed cockpit PFD wind indication, such as Project Magenta or PMDG 737, then the PFD wind indicator is not operable when on the ground and should be showing ---/--. Regards, Pete

But related to the networking operations, none the less. Did you check the IRQ assignments? Win98SE is very poor as sharing them. When you say "server hung" what is hanging? The whole system, or only FS? What exactly do you see? If the PC is hung it is almost certainly some driver level clash. Not really. I am still very very suspicious of mixing Win98SE and WinXP on the same Network, most especially when the Win98SE one is the Server. I had a load of problems which were unsolved till I changed the Server. It seems to work okay the other way round (i.e. one or more clients being Win98SE). Have you considered upgrading that PC to WinXP? Well, it creates a log file as soon as it is started. If that file isn't entering the file system on hard disk it certainly does sound like the whole PC is crashing, as otherwise the caching in memory would be flushed when the process closes/dies. I think you can tell Windows not to cache writes. It slows things up a bit but does ensure data isn't lost on crashes. BTW I don't know whether you've noticed, but the current supported versions are FSUIPC 3.45 and WideFS 6.45. Regards, Pete

Sorry, but you misunderstand something fundamental here. The data returned by FSUIPC has no types associated with it. How it is treated is entirely up to your code. If the 16-bit value is supposed to be signed it is up to YOU to read it into a signed variable. As far as the FSUIPC interface is concerned, its all just data, rows of bits if you like. There's no meaning at all associated with any of it until YOUR program determines what to do with it. Dim Success As Boolean Dim Data As Long Dim dwResult As Long Success = FSUIPC_Read(&H0E8C, 2, VarPtr(Data), dwResult) Well, I don't know VB at all, but your problem is staring at you -- you are reading 2 bytes (i.e. 16 bits) into a 4 byte (32-bit) variable. The top 16 bits of the 32 bit value should contain the propagated sign bit, but won't do so unless you make it. You can't and don't. You either need to declare the correct data type (a 16-bit signed value, not a 32-bit one), or work out a logical mthod of extending the sign bit into the top 16 bits, like "if value >= 32768 logically "OR" the value hex FFFF0000 into it". But I would hope that VB supported a 16-bit value, as the code will be better. Haven't you got any VB reference books? They surely must talk about number representations someplace, for learning VB programmers? Regards, Pete

Gauges have an interface to PANELS.DLL to draw themselves, values, needles and so on, of course. If you use those for your display then there should be no problems. But if it is going to be a visible gauge, why do you want a menu entry? You can process mouseclicks for your selections. Another alternative to consider merely for getting information onto FS's screen is the Kneeboard. I notice some folks are even getting live web pages up on the kneeboard. But please don't ask me how all that's done -- it must be via some links in CFG files, or probably just files in the right format in the right folders. Regards, Pete

I would have been very surprised if it was operating system related in any case. There are two possibilities as far as I can see: 1. Other installed programs or services in Windows which are running and possible interfering with programs like FS. There are some -- WindowBlinds for instance -- which actually hook into the window structures and menus of other programs and change them in subtle ways. WindowBlinds was responsible for many difficulties with getting any add-on program using FS's menu correctly. Another example is the driver for the Kensington Mouse, which seems to have a disastrous effect on some add-ins, particularly FSUIPC. I'm not saying it is either of these, but just illustrating the sorts of things which, though apparently outside FS, do have a strong influence. 2. Other installed gauges or DLLs in your FS installation may be affecting how that F16 gauge operates. Even, possibly, how its constituent parts are configured in the PANEL.CFG file may change what it is doing. I did try various things but couldn't get it to go wrong at all here, but there's no way I could be 100% sure. So, how to proceed? Well, on that last point, perhaps you could both show the section of the relevant Panel.CFG file which utilises the F16 gauge. I can try exactly the same entries here. Mine were actually derived from Eric's F16 panel itself, so they are probably the same, but you never know for sure. Also, I had no F16 to use the panel with, so I sort-of "adapted" it. Do either of you have a complete aircraft? If so, maybe you should Zip is up and send it to me at petedowson@btconnect.com, so I can see if I can make it fail that way. Apart from these points, look for other add-in DLLs, other than FSUIPC.DLL. Temporarily remove them. Now there are two of you, perhaps comparing notes on the add-ins you have will identify common things which may be clues. (Come to think of it, the same comparing notes idea should be applied to other things installed on your respective Windows systems). All I need to be able to do is reproduce it here to work out what is going on. Whether I can fix it or not is another matter -- but, evidently, because it works fine here and for others, there is a way to configure things to make them work, and maybe once I can see what is happening I can determine how to configure it so it doesn't. Mind you, with all this hassle and difficulty you may end up wishing you'd paid for FSUIPC User Registration after all, then none of the F16 registration checking would be applied in any case! :wink: Regards, Pete

In FSUIPC's Logging page, turn on IPC read and write logging, close FS. Reload FS, making sure you have no other FSUIPC using DLLs installed, and with default aircraft only -- otherwise the Log may become full of other program's reads and writes and make it bigger and more difficult to see what you are doing. Run FS to the point where you'd expect your Menu entry to be there. Close FS. Show me the Log. From the actual details of what FSUIPC sees being read and written from the appropriate offsets, it is easy enough to see what may be wrong with what you are doing. BTW these things are much easier to do from an external EXE program, and in that case you can use almost any language. Gauges and Modules inside FS are much more difficult, and often there's no good reason to write them this way. With an external program you have an additional advantage, that it can be run on a separate PC using WideFS. Even with a gauge or module, you will find it very difficult indeed to display a Window on top of FS when the latter is in full screen mode, unless you are using DirectX for your display. An if you really do mean "MessageBox" then you should realise that that type of Window is modal -- i.e. it stops the rest of the program whilst displayed. Regards, Pete

Sorry, I've not found a way to directly change the pressure. If I could find it I'd implement pressure smoothing like the visibility and wind smoothing. Regards, Pete

And what version number is that, please? Everyone says they have the "latest version" but often this just means the latest one they downloaded. Sometimes folks have said that and the version has been many months out of date! If you have any problems with such things, please run FS, get the problem, close FS and show me the FSUIPC.LOG. If you have registered FSUIPC then are you sure you used a legitimate Key? Some similar problems are caused by the use of bad keys. If you want me to check, Zip up the LOG and the FSUIPC.KEY files (both from the FS Modules folder) and send them to me at petedowson@btconnect.com. Pete

Actually, you need not bother with the KEY file now either -- Katy from PM Support has sent me the details, and this has enabled me to locate the problem. Many apologies. I am sending a fixed interim version of FSUIPC to you now. But please replace it with the next official issue when available (probably late February). I think you would be better off with the current WideFS (6.45) rather than the 6.44 version you are using. Check http://www.schiratti.com/dowson. Regards, Pete

I wrote to PM support after posting my last reply here, and they supplied me with the Logs which you supplied them but forgot to supply me. It looks almost certain that either or both of the FSUIPC and WideFS keys you are using are not correct. They test out as counterfeit, which is worrying. Please Zip up your FSUIPC.KEY file and send it to me by email (see previous message), but you need not bother about the Log files now. BTW the Logs do show that you are a little out of date. Current FSUIPC is 3.45 and WideFS is 6.45. Regards, Pete

Hmmm. Think about this: as the value is contained in only 16 bits (2 bytes) it is impossible for it to contain a positive value of anything greater than 31767, which after dividing by 256 would give you 124 degrees C, no where near your 250. So I assume that the temperature is below zero, maybe only slightly, and you are wrongly treating the number as unsigned! Please look in the FSUIPC SDK and find the program called FSInterrogate. ALWAYS check your results against those shown by FSInterrogate. If you get something different you have an error in your program. You can also use FSUIPC Logging. Go to the FSUIPC options, find the Logging tab and select IPC read logging. This will show the values actualy being supplied to your program. Regards Pete

I've no idea, sorry. I've not made any such keys, so anything could be happening. I don't know anything about the demos at all. This is really 100% a matter for the PM support folks. I assume you are not using a registered FSUIPC? If you want me to take a look then I'd need to see the FSUIPC Log file. Oh, I just noticed you say you are running on TWO PCs. With WideFS? If you have WideFS and it is connecting okay, then you must have paid for it. If you are running all of the PM programs on the client PC then none of them need any keys in any case. Anyway, the same file should have helped PM Support work out what's wrong too. Didn't they ask? Have you tried the PM support website? Please also check that you are using current supported versions of FSUIPC and WideFS -- there's a list near the top of this forum. [LATER] It just occurred to me that these time-limited keys you are talking about might have been for FSUIPC and WideFS, not for the PM applications themselves. Is this so? I'm afraid your message is ambiguous in this regard. Anyway, if it is so, and you want me to investigate (rather than PM Support?), then try it all again, then close down FS, and Zip up the FSUIPC.LOG and FSUIPC.KEY files you will find in the FS Modules folder. Send the Zip to me at petedowson@btconnect.com. Regards, Pete

FS only appears to do this if the key is not assigned to anything. By default it seems to be assigned to the Kneeboard. If I delete that assignment in FS I get the effect you are describing, but if I then assign a function to it in FSUIPC's Keys page, that works correctly and FS doesn't appear to go into that mode. Have you tried that? I'm not sure exactly what you are trying to do with it. Keys assigned in FS or FSUIPC do not get passed on to Windows' default message handling routines, and I think it is those, not FS itself, which enter this menu selection type of limbo (not the FS-implemented Pause, of course). If you simply want F10 to do nothing, try assigning it to an FS control which does nothing. I think there are plenty non-working controls in FS, listed in FSUIPC's drop-downs, but you'd need to try one and see. Regards, Pete

Yes, via parameters in the PFC.INI file. Just look in the PFC.DLL User Guide, in the section on the INI file near the end. You'll see two parameters which you can change to achieve whatever you like. Regards, Pete

Yes, assuming Program 2948 is your program (that will be identified earlier in the Log file), then FSUIPC is most certainly supplying your program the correct data. So, I'm afraid there is something wrong in your code. But you need someone who knows Delphi to help. Maybe it is all to do with differences between passing things by value instead of address or vice versa, but I really don't know. Sorry. Regards, Pete