Pete Dowson

That sounds like it is always identifying the turns as "fast". the button numbers won't change any other way -- the same 4 numbers are fixed for each unit. Sounds like the TQ6 support is overloading the callback. Can you write to Doyle Nickless about this please? I can't really do much here yet -- Doyle has promised to send me a TQ6 but there's no sign of it yet, so I cannot really see what is happening. FSUIPC is rather dependent upon Doyle's DLL to feed it event information, and the TQ6 is probably sending my code too many messages (most of which I don't handle in any case, since I don't deal with the analogue axes at present). Regards, Pete

The controller board supports proportional brakes, but I think it depends which pedals you have whether they are actually fitted with them or not. I have one set with, one without. You'd need to check with PFC. Maybe those without can be upgraded. The PFC.DLL handles both with no configuration changes -- it simply receives 0 or 127 from those fitted with an on/off switch, but varying values for the proportional ones. Those you need to calibrate of course. Regards, Pete

I'm sorry, I am completely lost. Keys are keys. Why would you want to program a key from a key? All FSUIPC is doing is trapping the WM_KEYDOWN and WM_KEYUP messages and using them to issue an FS Control. Are you saying it should be able to take a WM_KEYDOWN and convert it to another KEY for some reason? And then discard the WM_KEYUP, so the Key stays pressed all the time? That will mess up things for sure. But surely the encoder can allow a key to be held -- doesn't it simulate a keyboard as far as the PC is concerned? It must be providing Key Down indications when a key is pressed and Key Up when released? I'm really confused about what you hope to occur here. FSUIPC sees keyboard actions -- keys being pressed, released, repeated, whatever. That's all. I provide the facility for actions to occur on the press (which the keyboard system in windows can repeat) and on the release. What else can I do? Can you explain more? Is this some problem with the encoder rather than the way FSUIPC is seeing things? Regards, Pete

Well, I'll have a look. Maybe I can do it simply by allowing the same input axis number to be assigned to several FS values. Otherwise it will be a "mapping" option, like the ones for throttle and so on. Well, as I said, I've only just released 3.202. I normally try to space releases out to around monthly, so at worst it might be 4 weeks. Your request is now in my list, but I've some other things I must do (not with FSUIPC) first. Maybe I can get to this within a week or so -- it depends how fast I can get through the other things. Anyway, when I do implement it I'll send a "Beta" (interim test version) to you for testing in any case, if you like. I don't need cowl flap levers myself, you see. :) Regards, Pete

Well, there are controls to SET the cowl flaps (separately for 1, 2, 3, and 4) -- they are named COWLFLAPn_SET (n = 1 to 4), so it could be programmed -- Unfortunately FS doesn't regard these inputs as Axis inputs so won't assign them to axes (FS98 didn't have these sorts of delineations, and it is annoying that they introduced them). I suspect FS will override them if you try to assign them directly in the FS9.CFG file too, but it may be worth a try. For FSUIPC to support these you'd have to select another, otherwise unused, axis control and edit the FSUIPC.INI file to tell me its number (names and numbers are listed in my FS controls list, available on http://www.schiratti.com/dowson). Then I'd have to intercept those inputs and re-route them to the Cowl Flaps SET value. I can add this to my list if you like. It isn't complex. In fact I could have added it to 3.202, but you just missed that -- I try to keep FSUIPC releases down to once per month now, unless something drastic happens. Are you needing it for a single engined aircraft, or would you need to be able to map the one axis to all 4 engine cowls? That wouldn't be quite so easy of course. Regards, Pete

I think I've reach a reasonably satisfactory method. The menu entry detection is by WM_MENUSELECT. That covers both browsing and the subsequent selection. I am now not clearing this on WM_ACTIVATE, but only when I get the next normal frame-rate chained call from FS -- I use these in any case to synchronize critical FS changes to the frame rate. Those class stop when FS is in a dialogue. That seems to cover everything related to menus and their resulting dialogues. I still had the problem with modal dialogues which can occur directly, not via the Menu system. One normal example is the Save Flight dialogue when brought up by pressing ";" (or whichever key is assigned). I've dealt with that by detecting the WM_ENTERIDLE message, which seems to only occur with dialogues. Again, this is cleared when my frame rate routine is called by FS. I'm setting different bits in the byte at offset 0x3365 for these two things -- the 1 bit for entry via MENUSELECT, the 2 bit for entry via ENTERIDLE. You'll get both with menus. The 2 bit may flicker off and on during the exit phase from a dialogue because the ENTERIDLE message occurs quite a lot and piles up. In the end you have to look at three places - the Pause flag at 0264, the "ready to fly" flag at 3364 (only applicable to FS2004, mind), and this new byte at 3365 (which should be okay in all versions of FS). I hope this covers your needs. Have a play with it when you get FSUIPC version 3.202 -- I should get this out later today or possible tomorrow at the latest. Regards, Pete

I don't think there is a "second timer" in FS2004. Either way neither would halt. The "timer" discussed earlier related to the time of day clock -- the seconds counter stops when FS is paused or frozen. As I mentioned, though, it takes a second at least to determine if it has stopped, and it could be a lot more if the user is running at a slow sim rate. Well I do have a couple of other ideas which I'll try today, but then I really have to get on with other things. So if you do have anything let me know straight away. Thanks, Regards, Pete

Ah, a typo -- thanks, I'll fix that. The default update rate is 1 second so you could try faster, though most GPS's only seen to read the values that infrequently even if you send them more often. Another factor is the serial speed. The default NMEA standard of 4800 bps is rather slow considering the data is in plain text formats and so longer than would be necessary for pure binary data. With a message length of, say, 80 characters, it takes a sixth of a second just for the transmission. Even small lags like that can be noticeable. Great! From what I've seen there aren't many GPS units designed to allow NMEA input, only output. If they did allow NMEA input then it should have worked. You say you changed the GPS protocol, but are you certain it was to something accepting NMEA? All the Garmin units I've seen support NMEA out but only RTCM (or similar) in -- the latter isn't a GPS type output but an external antenna encoding for more accurate positioning. The contents are more like raw information from which the GPS can compute things. I can't get into that. I've got all the documents. The "Garmin protocol" is for transfer of waypoint and routing information, and digital maps for those units which support them. I've not found any real-time position infomation capabilities that way. Regards, Pete

FSUIPC also offers a hot key option specifically to operate the AdvDisplay window visibility. Pete

There's a PM parameter (and a key press I think) to enable that, but I don't think it is really very suitable for Radar Contact's current multi-line menus. It originally only allowed for one line (long, for sure), I think Enrico extended it for two lines, but even so it doesn't really suit RC. I use Showtext to superimpose an unbordered black window over one of the Standby instruments which otherwise I have on the EICAS1 screen. You can size it and configure it to fit in other places I suspect, and still retain the RC menu structure in the display. Regards, Pete

Yes, the seconds counter halts, but when is is running it changes according to the sim rate. You might have to wait more than a second to see the counter change. Of course, it would be possible, it just makes things a little more complicated and may not be suitable for time-critical things (i.e. if seconds matter). I've found that if I flag the stoppage on a WM_MENUSELECT then clear the flag on the next WM_ACTIVATE message it works across dialogue actions. It isn't foolproof -- if you open a dialogue then go activate another program and then return to FS, the WM_ACTIVATE message arrives even with the modal dialogue still open. This is about as good as I've got it so far, though. Regards, Pete

Further on this, I've run aground I'm afraid. First off, whilst I can detect when the user merely has the mouse over the menu, this can't be what you want to know as FS is still most definitely running then. Only when a menu is selected (by ALT or mouse click) does FS actually stop. Until a menu item is actually chosen, I can indicate quite easily the fact that FS is paused because of menu browsing. However, if he selects an item which opens a dialogue, I can trap no further messages until he closes the dialogue. The WM_EXITMENULOOP message tells me he's stopped browsing, but nothing tells me he's in a dialogue. Effectively none of my FS message-based code can run whilst FS is in a modal dialogue. I seem to remember facing this problem before and not being able to solve it -- I needed to know when the aircraft dialogue was being accessed so that I could prevent changes to aircraft-dependent things when this may be dangerous and crash FS. I ended up doing it a different way, based on memory validity checks and so on. So I'm not sure I can really help you after all. If you have any good ideas about this please let me know and I'll try them. Regards, Pete

For the menu stuff, after experimenting a bit with Spyxx, I think the following might work okay: Set "in menu" flag on: 1. Seeing a WM_MENUSELECT message, or 2. Seeing a WM_NCHITTEST message which returns "HTMENU". The latter is a little problematic, though, as I'd need to get the message processed to see the result. If there's any other subclassed or main window which wants to process this I could mess them up. But I can't see any other easy way to detect "hovering". Maybe I process it AND pass it on. This would be a little inefficient because the Windows processing (that determines the Window and returns the HTxxxx value) would be executed twice each time the NCHITTEST occurred. But this is only when the User moves the cursor over non-client bits of the display, so I don't suppose it will be at all noticeable. The "in menu" flag would need clearing on: 1. WM_EXITMENULOOP, or 2. WM_NCHITTEST return is not HTMENU, or 3. The flag was last set by the HITTEST and a WM_NCMOUSEMOVE is seen. I may include this stuff in 3.202 and let you play with it. If anything else is needed it would have to go in a later update. Regards, Pete

I don't know. I'd need to do some experiments. I'd probably need to trap a number of Windows messages. I think I can detect when a menu is being selected, but I'm not so sure I can easily or reliably detect when it is being "hovered" on. What about other occasions when FS is effectively frozen, like grabbing its title bar and holding it (with the mouse)? And does the "pause on task switch" option show as "paused" when the user is accessing another program? If you have some good ideas about exactly how I should do this, I don't mind adding a flag for it at all. I am planning a minor release this weekend -- to fix a problem with Button programming on PFC devices -- so if you are quick I can slip it in now! Regards, Pete

Well done! That's what I like to see -- users answering their own questions perfectly! More, more! :D :D :D Regards, Pete

Unless it is a corrupted or illegal copy of FSUIPC, it sounds like he has another program or add-on installed which is not compatible with the version of FSUIPC he is using. You don't even say which version it is, but FSUIPC itself does not cause FS to crash -- in fact it traps crashes and logs them in its Log, then carries on, so if anything does go wrong you get a loss of function not an FS crash. What does cause crashes are programs doing wrong things using the FSUIPC interface, or doing different things when their version checking says things aren't how they like them. To determine what is going on is therefore a matter of elimination. There are two ways of doing that. The easiest it do uninstall everything, install FS, check that, then FSUIPC, check again, then other things one at a time. The other way is to uninstall things one at a time instead, but that is more precarious as it isn't always obvious what belongs to what and whether things are truly uninstalled or not. There are no other reports to hand of any crashes from simply installing FSUIPC, and haven't been any for a very long time, so I'm afraid this really is the only course of action I can currently suggest. Regards, Pete

That'll be the magnetic variation, which is different in different places. The heading you are reading is relative to True North, the one shown in aircraft instrumentation is related to Magnetic North. You can get the Mag Var from FSUIPC at offset 02A0. Note that this is only a 16-bit (2 byte) value, so read it into a "short" variable, and scale is as described before adjusting the heading for Magnetic. The variation is signed. Regards, Pete

I don't do actual code for folks. That's programming and you should really be a programmer before you start, especially if you are considering using C or C++. But it is easy enough to describe. Do an FSUIPC_Read from 0x580 (4 bytes long) into a variable declared as an "unsigned int", then call FSUIPC_Process to make it happen. Printf the value times 360.0 and divided by (65536.0 * 65536.0) as a floating point number (a double, using the %f formatter). Ah. Then what don't you understand about the Hello example? What do you mean about a "pvoid setup" -- sorry, that doesn't really mean anything. You don't set up any "pvoids". You make a pointer to your Heading value, declared as an "unsigned int" by taking its name and prepending & (eg &heading). Please refer to your C reference books for C syntax. You do need that first. If there's something you don't understand which I should be explaining in the SDK, the please be more explicit. Then I know how to improve it. But actually writing the code for you would be a mistake I think. I ought to be finding out why you cannot do it and advising on that. If it is just that you've never used C or C++ before then I would really advise programming something simpler than an FS application first. Let me know. Regards, Pete

Yes. I don't know how you'd handle a toggle switch via a keyboard encoder -- you certainly shouldn't keep a key pressed all the time I don't think. With a normal keyboard this can stop other keys from working correctly, as they are matrixed. I don't know if that is a problem with keyboard encoders, but another problem could be that, if it looks like a keyboard to the BIOS it is likely to generate repeats, which you don't want for light switches! Regards, Pete

Yes. That would be the best way -- on in one position, off in the other. For the Strobes, Landing and Panel lights there are even separate ON and OFF controls you can use -- assign one to press and the other to release, according to how you've wired the switch. In the cases of Beacon, Cabin, Logo, Nav, Recognition and Taxi lights there's only a "toggle" control, however, so you'd need to get your light switches synchronised for those and use the "toggle" control for both "press" and "release". Synchronise them using keyboard/mouse initially and they should then stay synchronised -- at least till you reload a flight or aircraft, anyway. Well, the FS key programming can be set not to hold the key in any case -- FS doesn't want keys held down except for repetitive things like changing bug positions and so on. But don't use the key press programming part for this, when there are perfectly good FS controls you can assign! You should even be able to find them in FS's own assignments, but if using FSUIPC for this, use the right-hand part of the Buttons programming page and assign the appropriate FS controls. The ON/OFF ones are named "Strobes ...", "Landing ..." and "Panel .." but I think all the others start with "Toggle ...". Check the FS2004 controls list (from http://www.schiratti.com/dowson). Having a button fixed "on" isn't like a Key on the keyboard -- each button/switch is a separate detectable input. They can be left on or off. Regards, Pete

Certainly not the default GPS, which is a Gauge and only runs with the rest of the FS code. I don't know the "new Garmin 530", but if it is an external program, uses the FSUIPC interface, and doesn't need direct access to other bits of FS, then it should work via WideFS. Maybe it needs installing and setting up in or near FS in order to generate its data files, which could then be copied across. Some investigation with the documents and support might pay dividends. Regards, Pete

That's okay then. Just make them aircraft-specific, as I suggested. In fact all you'd need to do it edit the FSUIPC.INI file and change the [buttons] section to be the [buttons.] section. The aircraft name is the one sepcified in the Aircraft.CFG file, readable in FSUIPC's Joysticks page 6 of 7, under "flap details". Oh, okay. Regards, Pete

No, sorry. I really have no knowledge about it at all, other than that former APL programmers seem to say it is far too restrictive in comparison, and most I know have moved to external VB programs instead. Regards, Pete

In the next version I'm replacing all three entries, 0D50, 0D58 and 0D64 with just the one, so: 0D50 24 The Tower Latitude (8 bytes), Longitude (8 bytes) and Altitude (8 bytes) in the same format as 0560–0577 above. Ok Ok like I've already done with tne viewpoint location at 05B0. Then I've only got one explanation to keep expanding! :D Sorry if it was confusing for you. The original source for all this merely said "FS units" by the way, you had to forage in quite complex ways to work out what they were. At least I think my documentation is a bit better. Regards, Pete

Yes, of course, since the lower part are merely the lower 32-bits of the complete 64-bit signed integer. You can't have two sign bits in one number. Ah, copy and paste error, not typo exactly. Thanks. I'll fix it. Ah, the fuller explanation is in the 0560 part. Sorry. It seems i'll have to reproduce the whole text in every place the same notation is used. :( In 0560 the differentiation between "int" and "unsigned int" is emphasised by emboldening in the original: "To do, copy the high part (the 32-bit int at 0564) to one double and the low part (the 32-bit unsigned int at 0560) to another (say dLo). Remember that the low part is only part of a bigger number, so doesn’t have a sign of its own." Probably, though it would need tidying to work as a program of any sort. Since the whole thing is in units where 90 degrees is represented by 10001750, it is easier to understand if you consider the joining of the two parts as merely making one number (65536*65536 is just my easier-to-remember way of referring to the 32-bit capacity of the lower value -- can you call what 2^32 is in decimal offhand? :) ), and then the scaling is multiplying by 90 and dividing by 10001750. This system of representing things in FS dates back many many years by the way. FSUIPC just gives you what FS gives it. Yes, but largely unnecessary. Unless you are at the very far reaches of some sprawling airports which are close to some small field, just using your Lat Lon on a database of airports will do -- just find the nearest. There won't often be ambiguity. I think airport databases are easy enough to come by -- some of the AI traffic utilities make them I think, for instance. Regards, Pete