Pete Dowson

Sorry, I thought you said "the shoot button is settled in Fs command tab to activate brake as usually". Anyway, if it still doesn't work as expected when the button is ONLY programmed through FSUIPC, then I suspect it is set to pulse rather than hold. This may be either in the device itself, or maybe in the driver. Try just programming an action on the "Release" and see if that action is taken when you just press and hold. If so, then it sounds like it is a function set elsewhere, either in the device itself or its drivers. You should also be able to check this in the Control Panel Game Controllers section. See what that indicates. Maybe it is only that button affected. Try another one, perhaps, in case? I can't really think of anything else at present I'm afraid. Pete

I forgot to add this: If you REALLY want to brake as well as operate RW with the same button then you can program both functions in FSUIPC. But this would need editing in the FSUIPC.INI file. Details are in the Advanced User Guide. Pete

It's a really bad idea to have the same button activating FS actions as well as FSUIPC actions. I wouldn't be surprised if that is the cause of your problem. FS reads the buttons via DirectInput, FSUIPC uses the standard Windows API. It sounds like there's a conflict which makes the button look released to FSUIPC. Pete

All sounds relatively logical. The processor load from FS itself is obviosly partly to blame, but mostly its down ot the frame cycling by the looks of things. Pete

Something in the back of my mind nagged me about this "SafeLine" thing, so I looked through the older threads. There's a thread actually entitled "SafeLine Console". Isn't this relevant to your query? Looks like it. It seems that it was eventually confirmed there that this device is not dependent on FSUIPC, and that some folks do have problems with it, seemingly depending on the version of Windows they use. Check that thread. Pete

I've no idea. Does Safeline Jet Studio even use FSUIPC? What is it? Maybe someone else can jump in here who might know this program. I hope so. Pete

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