Pete Dowson

One thing which might be interesting to check. As you said, the 27 mSecs you are experiencing is remarkably close to being in step with your stated FS frame rate of 30 fps. Why not try to change the frame rate and see if this affects the measured elapsed time on your thread calls? Try both limiting the frame rate (in the frame rate limiter in FS) to, say, 15 or 20, and also see what happen if you get it much higher (reduce some of the display options). Just a thought. Of course the 27mSecs at 30 fps may be a simple fluke. But if it isn't then you've already got a way of matching the frame rate. Regards, Pete

Most things in FS are called via "chains", which are, in most current versions of FS, set up and controlled by CHAIN.DLL . However, there are many different chains called for different things and it is not easy to sort out. Additionally you would have to rewrite and research this for each version of FS. I really have no idea what FS's "loop iteration" would be, there's no single thing you could pin down. I think most people who do add-in Modules must have them operated by timer calls (SetTimer with a procedure) or by having a simple small thread which loops, and sleeps, sending a message at intervals to an invisible Window procedure in the DLL. I don't know what you are trying to do as a DLL but I normally try to discourage having more such continuous activity running inside FS itself, which is why I strive so hard to provide a good service for external programs. The advantages of EXE's are that you can do what you like, take full advantage of all Windows facilities for processes and threads, not have to worry about different versions of FS very much (FSUIPC takes care of that), and not really have to worry about the impact your code has on FS performance -- which is a major concern for internal DLLs. Additionally, an EXE interfacing to FSUIPC will also run on a separate PC via WideFS -- surely a really big advantage as then both your program and FS get to run better. The current versions of WideFS can easily manage to provide updated data at FS frame rates, which is surely all you need. Regards, Pete

More thoughts on this. I've only just noticed that you are calling FSUIPC from a separate thread, not the main FS thread. Correct? The Open2 method uses SendMessage. The MSDN data on this as it relates to threads says this: "Messages sent between threads are processed only when the receiving thread executes message retrieval code. The sending thread is blocked until the receiving thread processes the message." .. so your "SendMessage" is actually behaving more like a PostMessage, just adding another item to the complete Message queue for Flight Sim's main thread (in which FSUIPC runs). This rather defeats the object of the SendMessage. FS uses the message queue very extensively in any case. Within a single thread SendMessage calls the appropriate Window procedure directly, so it is then as efficient as a direct call. I seem to recall a time with Windows programming where you were'nt even supposed to use SendMessage between threads, only PostMessage. Looks like they've got around that by treating them the same when this arises. Really FSUIPC cannot do anything until it receives your Message. Once it does it processes it very fast indeed. I suggest you call FSUIPC in the normal FS main thread and see what results you get then. Pete

You've got something wrong there. It is almost always less than 1 millisecond, not measurable with the normal timers. That should be easily achievable, and is actually exceeded even by some external programs which have to do Process Switching as well. The data update will certainly not exceed the FS frame rate. All the parts of FSUIPC which obtain and populate the data which you are reading will be running at the FS frame rate at best (for some lesser items which involve procedural excursions into the nether parts of FS I reduce the frequency a little). However, the IPC calls, whether via the direct WM_IPCACCESS message you are using, or by the SendMessageTimeout from another process, are dealt with immediately and involve no delays within the FS process, unless something else is taking processor time away during this period. If fact, if you enable "Extras" logging, FSUIPC itself will Log any IPC call which takes longer that 20 mSecs. If you want it to log all the times for all the calls add a line "Debug=Please" to the [General] section of the INI, and set LogExtras to 8 (instead of Yes). But don't leave this sort of logging on, it will slow things down a little itself. I assure you it really isn't possible to take 10 mSecs off something that rarely gets to 1 mSec. If you are measuring more than 1 mSec consistently you have something going wrong. Maybe it's related to the data you are reading/writing? Many of the Write requests do provoke actions in FS, which will take more time -- for instance Saving a FLT can be provoked by simply writing through FSUIPC. That will take a few milliseconds no doubt. Pete

This is actually explained in the documentation. The Server is timing out and disconnecting those clients which don't send it messages and the clients are re-connecting when they time out and don't see messages from the Server. The server timeout is deliberately longer than the Clients, so these events overlap and produce what you see. Yes, these both simply mean the client is not getting responses from the Server. Please upgrade to Version 5.50. I cannot support old versions. Let me know how you get on when you are up to date. Pete

Sorry, it hasn't actually existed now for about 5 or maybe 6 years. For the "concept" of writing gauges, just get the Panels SDK. The one which shows how to write gauges in MSVC and has examples, not the recent XML stuff. You might need to search back for the FS98 or FS2000 one, I don't know. I've not really downloaded or looked at FS SDKs for several years. Pete

Not in any way I know, sorry. It's an area I know little to nothing about I'm afraid. Way back in FS4 and maybe FS5 the BGL commands had facilities to access parts of the GLOBALS.DLL, which is withing the area normally addressable by FSUIPC, but that direct access from BGLs disappeared long ago. Pete

Well I don't know Flight Tracker (though I have it here someplace), but I use FSMeteo every day and I know it loads okay with "RunReady". Sorry, what "other copies" of what "ini" files do you need? That looks fine, except there are apparently no exchanges with the Server. Was FS running? Where's the WideServer log? That might show something, don't you think? Pete

You could try using my ESOUND module, but please be aware that I am not supporting it these days. Otherwise you would need to write a gauge. For that you'd need the FS PANELS SDK. There may well be some other packages which can make sounds based on events. Flight Deck Companion (FDC) and Enrico Schiratti's PMSounds come to mind, though they may both be over the top for what you want. There may be others. Sorry, it isn't really something I've been interested in -- I try to replicate a real cockpit in my setup. This section (as an example) determines which [WindowNN] section is activated by each such key combination, and gives the names you see in the Views dialogue for the panel. [Window Titles] Window00=Main Panel Window01=Radio Stack Window02=GPS Window03=Annunciator Window04=Compass Window05=Mini Panel Window00 is selected by Shift+1 and so on. Pete

My first "module" was a Gauge -- EPICINFO.GAU to be precise. It had no mouse input, no graphics, nothing to do with panels. It simply used the PANELs system to get itself loaded. There is no SDK for add-in Modules. Those that are written are done by hacking into the FS code to see how to do it. But GAUges are more than halfway there. Take a look inside them and compare them to the DLLs. Pete

Actually the range at 088C et cetera can be -16383 to +16384. All -ve values are reverse thrust. The -4096 I show in the document was just the 'normal limit' for jet reverse as I saw it when I wrote it. In fact the maximum reverse thrust is set in the AIR file and can be more or less than that. If you have an AIR file with the max reverse set to -16383 then you can go just as fast backwards as forwards! You can read the maximum reverse thrust in 333A. FSUIPC now calibrates reverse to that limit, and this actually changes according to the aircraft you load. That given, I think you should be able to simply copy the value you read in 3330 into 088C, with any manipulation you want in between. Why don't you just look at these locations using FSInterrogate? I think you'd then get a feel for what is going on. It'll all become clear . Regards, Pete

Yes. In fact you don't even need to do the direct input bit yourself unless you really want to. (Actually I wouldn't use DX in any case, the ordinary joyGetPosEX calls seem perfectly adequate to me!). If you check the Programmers Guide for FSUIPC you will see that at offsets 3328-3337 you can read the axis input values -- those read by FS itself, and at 310A you'll find switches to allow these to be disconnected from FS. Hence you can read the values yourself, manipulate them how you like, then write the results to the Throttle control areas at 088C, 0924 et cetera. This is the method you'd use for "fly-by-wire", for example, on an Airbus, where the throttle position only represents a desired "mode" not a specific throttle setting. Take care to keep replenishing the switches at 310A as, for safety reasons, FSUIPC will cancel the disconnection every so often otherwise. Regards, Pete

No. Unless you can get pots which are really very precisely matched I don't think you can ever get them perfectly lined up. (Actually, I don't really think the real throttle levers in the aircraft are necessarily precisely aligned to get the exact same performance from the engines -- at least they don't look that way when I've been in the jump seat, especially with Auto-Throttle engaged, which it invariably is after take-off). You can use the FSUIPC throttle sync facility to get them all doing the same thing -- that 'cheats' by copying the throttle 1 values to all the others, overriding the separate inputs. That's okay when you don't want differential thrust and all engines are working okay. To get values the same for each physical position of the throttles, each one would need many calibration points, with a table to convert the input value to the desired output. This is actually a facility provided on EPIC cards -- each input axis is processed through a 256 byte table (the raw inputs are in the range 0-255, so this suits). I could consider something like that for a future version of FSUIPC -- I have been considering adding full axis assignment and calibration facilities in any case (by-passing the FS CFG stuff), and would certainly add this then. But I cannot consider any such addition yet -- not till well after "conquering" FS2004! Regards, Pete

Okay, good. Don't forget the whiskey compass, being magenetic/mechanical, doesn't read accurately except when flying straight and level. If you want your compass to behave like that then that's fine, but don't rely on it in turns, climbs, descents, or at least make the appropriate allowances if you do. If you want it instead to behave like the gyroscopic heading indicator then you should use the heading instead, but adjust it for gyro drift (offset 0C3E) for more realism. Regards, Pete

Okaygood luck. I'm sure you will sort it out now! Pete

The current version of FSInterrogate unfortunately does not provide any facilities for this - the LAT LON and ALT are in 32-bit "float" format, and FSInterrogate only supports floating point in its 8-byte, 64-bit "double" or "float64" format. Pelle was developing a new version which would inlcude this format and, at last, strings, but I think he's been far too busy with work to finish it. Pete

Ah yes, sorryI now see that it is much more complicated than I thought. I needed to re-code some of it to use run-time linking -- currently it needs that entry as a bound-in link, which is what is causing the error. Sorry. forget that parameter altogether. It is gone. This version 5.531 sees if it can use the routines (they are in NT's Kernel32.dll) and if it can, it does, if it can't, it doesn't. Pete WideClient5531.zip

I'm not saying you are in error READING the value, only in interpreting it. It is no use showing me examples of VB.anything, I'm afraid. If your code is in error I hope someone who uses this language can jump in and help you. But I am not he, sorry. You are therefore not understanding what "BCD" means. 120.60 is represented in BCD by 0x2060 which is decimal 8288. so when you read 8288 this is correct for a frequency of 120.60. What can be more obvious than this? You already just proved it to yourself!! Please use FSInterrogate where you can see the values read in all sorts of formats, all at once! Then maybe you will understand? If you get 8288 in decimal as you say, this IS the BCD (Binary-Coded-Decimal) version of 2060 as in hex it is 0x2060, as you already so clearly pointed out! Why are you asking HOW to "get the BCD" when you've "got it"????? Pete

Okay, that sounds fine. These are in the [user] section of the appropriate WideClient.ini file, as documented? No, that seems to be correct. At least it works fine with all the versions of RW I've tested it with. I cannot guarantee it will always work with every version, as the author seems to change the Registered message names used for PTT sometimes. No, not at all. There's your error. You have the parameters in the wrong section. Pete

If it is only WideClient (NOT FS and the Server part) you want to run on NT4, then just possibly the attached version of WideClient (5.53) will do the job. I've provided an option to bypass the use of ToolHelp (it was only being used to log the names of Client programs). Just edit the INI file, adding "IdentifyClients=No" to the [user] section. I cannot say for sure whether it will then work -- maybe other things will conspire to stop it. Let me know. Pete WideClient553.zip

Yes. It is called "Flaps Set". No, it appears there is not. Pete

Thanks. I'll forward your message to the author. I had assumed he'd tested it, so this is a bit odd. I know nothing about VB or .Net so I don't just want to change it myself. Pete

My Latin is a bit rusty, but if you mean has anyone tried all the possible FS controls listed in CONTROLS.DLL (which is where FSUIPC gets them) and reported on the results, then the answer is no. Do you want to volunteer for this? It is rather odd to find that these are mapped so oddly inside FS. But I think you'll find that the plain "COM RADIO ..." (i.e. not the Standby) controls do actually operate the Standby. It is not surprising that MS did not bring all these controls through to the user interface for assignment in their own dialogues! You definitely have some errors in your code then. 120.07 would be encoded as 0x2007 which is 8199 in decimal. You cannot get 6567 from any BCD encoding as this is 0x19A7 and the digit "A" has no place in BCD. Just think of BCD as having 4 bits per digit. i.e. 0x2007 is, bit by bit: 0 0 1 0 0 0 0 0 0 0 0 0 0 1 1 1 If you AND the value with 15 (1 1 1 1 in binary) you'll get the last digit as a number (7) in this case. Add the character '0' to this and you get the character '7' for display. Repeated shift down by 4 bits and do the same again and you get the correct characters for the other three. Insert the decimal point and add the leading '1' and you are there. This BCD method of encoding frequencies in FS has been the same now for many many years and there are plenty of applications using it with no problems. Stop thinking numerically, think of it as merely packing characters into smaller spaces, and just unpack it as I suggest. No, there's no shortcuts if you want to increment and decrement BCD. And remember that many of the frequencies are invalid. The last digit can only be 0, 2, 5, or 7. These represent 0.000, 0.025 0.050 and 0.075 so if you want to do it numerically you would have to convert something like 0x2007 to decimal 20070 then increment by 25 and convert back again, ignoring the last digit (0 or 5). To convert 0x2007 to decimal 20070 you'd take the value of the top 4 bits (2) and multiply by 10000 then the next 4 and multiply by 1000 and add, and so on. Vice versa converting back -- you use division, on the remainders each time. Pete

No, sorry. You need Win2000 or Win98, or later. Pete

Well certainly all those things are programmable. I really would have no idea about graphics overlays, but I presume that could be done by some sort of scenery design. Sorry, it isn't my subject. You might want to get hold of one of the official scenery design SDKs, or perhaps a scenery design package, and see if it is possible. You are probably right. I don't think there's anything which records sequences of keystrokes or buttons for FS. I supposed you could design a panel with such an arrangement. Apart from the "W" option you have 9 possible panels selectable by Shift+1 to 9. So the PANEL.CFG file could define different gauges, in different places, for each such selection. That's easy to do -- PANEL.CFG files are only text files. You can edit them yourself. But be aware that each gauge needs a bitmap to sit on (but it can be a blank bitmap). Again, there are some panel design programs that could help you. Pete