Pete Dowson

Why can't you use it? It is there, it works -- use FSInterrogate and see! All "not supported" means is that I cannot guarantee to provide it in the next version of FS. Mind you, since I cannot actually guarantee even an FSUIPC for the next version of FS, this doesn't mean so much. I suppose what I really mean is that it wouldn't be on my main priority list to find, but if I came across it I'd map it to the same place. Please please use FSInterrogate to check things out. You'll know what you can and can't get then. The utility is provided for such purposes. The next version of the SDK documentation? It is NOT a change to FSUIPC, only a change in where the offset is listed -- in the first table or the second! What DO you really think the second table is a list of, if not FSUIPC offsets? I'm evidently completely misunderstanding you here somehow. :-( Regards, Pete

I don't use "GetRawInputDeviceList" -- I don't even know what it is. I don't really understand your report. "When you start FS2004 an error-box appears" -- where, on top of FS2004? Is FS2004 still running, or is it FS2004 which has crashed? If not FS2004, what program is the error box emanating from? This may be the first step -- identifying what is crashing and on which PC. I note you attached a fragment of a WideClient log file. Is that intended to be relevant? I'm finding it hard to understand what you are seeing. If it is the PM MCDU which is crashing you need to talk to PM support. BTW, I just checked, and the USER32.DLL module, at least the one from WinXP, most certainly does include a "GetRawInputDeviceList" procedure. If yours doesn't, then presumably either it is corrupted, or you are using a version of Windows which doesn't support it. Regards, Pete

This question comes from the fact that some sentence types seem to come less than other (i.e. GSV sentences) I think some sentences, like the ones providing stellite details, can only hold a limited number of such. If you had, say, 15 satellites being received you'd need several successive copies of such a sentence to convey all their positions/times. But as far as FS data is concerned you only need the position, the altitude, the ground speed, and these only once per interval. You've lost me there I'm afraid. I don't know a "CEmonitor", and I don't know how the GPS receiver "asks" for sentences -- the NMEA 0183 protocol appears to be one-way. There shouldn't be a problem -- it's just something to watch. Thanks for the offer. I'm not sure what I'd be able to do with it though. ;-) But are you going to publish the actual program? Regards, Pete

There's some electrical stuff in the "usupported" variables, listed in the second table in the Programmer's Guide. Check those in the 28XX range. Some of those are getting to be quite important (2834 in particular), so I may see about promoting them to "supported" status (i.e. move them to the first table). What do you mean by "TOKVAR" here? Token variables are things you use in FSUIPC gauges and are documented in Microsoft's own Panels SDK. I think the correct token name will be one of: BATTERY_VOLTAGE, HOT_BATTERY_BUS_VOLTAGE, BATTERY_BUS_VOLTAGE, The FSUIPC offset 2834 provides the same as the first one I think. The other two are at 2860 and 2870. I don't know why you say you can't use these things. Can you explain that? Regards, Pete

Well, it isn't really my subject, but I'll tell you what I think. The navigational data is all part of the scenery -- "AFD" files for airports and, I think, general navaid data in other scenery files. I dont know about the waypoints and airways data, but I suspect it's still to do with BGLs. You might like to download the Microsoft FS scenery SDK from the Microsoft web site and check. If it is all in scenery then you would need to update the scenery. Certainly that's the way you get VOR/NDB and Airport facilities data. There is a freeware program called AFCAD which allows you to build new airport information files. Regards, Pete

Erone. Why would there be more than one of any type? Or do I misunderstand the question? Between all the sentences of one batch -- no time at all. Between each batch (i.e. each update) -- most devices seem to operate well with a 1 second update rate. Don't forget that if you are setting a standard NMEA speed of 4800 you can only get 480 bytes of data out per second in any case. If you try too many sentences per update you'll have problems in any case. Reduce the number or increase the interval. Regards, Pete

I have no details of any "authorised gauges" denied access. The only positive information you have provided is that your programs work, then don't work (EVEN on a reload of FS!!!) and then work again after a re-install. No matter what other problems your users may have with other things, this can ONLY mean you have data being created or changed which when reloaded in a subsequent session makes your program go wrong. That is the only inescapable conclusion from what you have told me. Corruption or problems which are in memory only cannot persist through reloads of FS (and especially not if the system is switched off in between), UNLESS the data is being saved. That's what you need to be looking at. Please apply a little logic here! ;-) If your users have problems with other gauges ("authorised"?) then let them report them to me or their authors with some details, and they'll get dealt with. But you are just confusing yourself with this -- look at the basic logic of your report first, and deal with that. Okay? Regards, Pete

Good question -- I assume it is meaningful to those who understand what N1 and N2 and so on really are. The descriptions are as provided to me by such an expert. Perhaps I should have asked for a definition, but I assumed anyone who was likely to want to use them would also understand what they meant. And it all happened at a time when I was extremely busy. Can you tell anything by looking at the values? Regards, Pete

I'm not sure what you mean by "safe". You certainly can't blow anything up reading any of it! :-) But I don't really know one value from another when it comes to turboprops -- best to use FSInterrogate and check for yourself what the values are. That is why it is provided in the SDK. History? Most of the lower numbered engines data sets date back to FS98 (before, but at slightly different offsets). They are maintained for compatibility for the many programs developed then and since. As other values come to light, I map them in case they are of any use. It is up to aircraft experts (such as yourself perhaps?) to determine whether they are truly the same or not, useful or not. Many have been found by others and I've been asked to add them. I really can't remember the history of some. The values listed in the second table in the programmer's guide may or may not be available in future versions of FS. If folks find stuff important there and can explain exactly what it is and how useful it is, I usually "promote" it to the first table so that I make an effort to find it in the next version, if possible. Regards, Pete

You don't mean capture a mouse click and when it occurs, make a button press I assume? That's the way your question starts out, but that wouldn't make any sense ;-) If what you want to do is create mouse clicks from a button press, then the only way I know is to use Key2Mouse by Luciano Napolitano (http://www.wideview.it/key2mouse.htm) to allow keypresses to do the job, then use FSUIPC to program your buttons to produce the keypresses. Regards, Pete

It cannot be related to anything in FSUIPC, especially not registration, if whatever happens is not cancelled when another FS session is started. It has simply got to be something in AS or your DLL, because reinstalling one or the other or both, and their ancillary files, fixes it. You need to find out what your program is writing which causes this. I cannot do that for you, I do not know your programs and have no sources for them, and really it is not my business. I am sorry, but this is really something you and Damien have to get to the bottom of. Regards, Pete

I seem to remember something like that being reported months or even years ago. I thought Damien solved it? Surely the way to proceed is to identify precisely what "permanent" change can possibly be made in a session which affects the next session -- something somewhere in the data AS or the DLL is actually writing to disk, or to the registry, but be preventing it operating correctly on the next session. After all, it it isn't being written to disk how can it affect the next session, and how does reinstalling AS "rectify" it? From what you say I don't think you will ever find anything that way. What is being "remembered" from session to session, and what can be wrong with it? That's all you need to know. Damien surely should know what is being written by his programs? Honestly, I know no other way of debugging such a problem. What does re-installing actually overwrite which has changed? Do a file comparison if you don't know what files the programs are writing to. It's easy with FSUIPC (or any of my FS programs) because the only files they change which they then read in a later session are the INI and KEY files -- deleting those reverts to an initial default. Comparing before and after shows the changes. Can't you do this with AS? Regards, Pete

No, after reading the rest of your message I realised that it was, indeed, the same as the "enable/disable" entry in the Options menu someplace, and also isn't it assigned by default to the 'K' key? No. I imagine it would mean disassembling more of Controls.DLL and tracing through. Almost nothing new is likely to be discovered using the offsets FSUIPC maps -- more and more of FS data disappears into private Class data with each release. Regards, Pete

Is that what that does? Strange name for it! :-). How do you specify which joystick? Or is that any and all joystick axes and button connections? HmmmI really have no idea how to tell if the FS option for enabling/disabling joysticks is on or off. Sorry. If you ever find out, let me know and I'll add a flag somewhere for it. Correct. FSUIPC's facilities for axes are all concerned with the FS axis controls. It has no idea how these arise, whether from program or real joystick is immaterial. Regards, Pete

There's no errors there, but there's also no log of anything connecting. ActiveRadar.DLL will normally show up and be logged. The VERY odd thing is the gap between FS starting and FSUIPC actually logging anything: 2928282 System time = 20:36:27, FS2004 time = 19:18:18 (00:18Z) The number on the left is the time since FS started, in milliseconds. That's over 48 minutes! What was happening in all that time? It looks like it's been edited or is part of a contniuation log, so there's no information about anything registering. There's too much logging enabled too, confusing matters. What are the symptoms of the problem anyway? If you think it's registration, just enable Read and Write IPC logging, nothing else. And show a complete log, but a short one - i.e. load FS, see the problem, close FS. Regards, Pete

No, none at all. Gauge registration is so simple internally. The long name problem was for manually entering them into FSUIPC's dialogues -- someone had an email address of about 68 characters and there wasn't enough room in the Edit box (FSUIPC copes with up to 127). The fix for that was to enable auto-scroll in the edit box, that's all. And there's only been one such instance in the two years of registrations. I have no information, no logs, no nothing, so I cannot really help. The only possibly reason for such inconsistency will be something awry with the way you are registering. You must use the FSUIPC_Open2() call to establish the initial link. You should call FSUIPC from the main thread -- certainly for registration. Are you using the latest version of the ModuleUser.lib? It will be the one dated September 2004 I think. Switch on IPC read/write logging and show me the log. Send logs to me at petedowson@btconnect.com. BTW if it fails with no registration message, it isn't failing the registration -- it is more likely to be users with illegal FSUIPC keys. I can tell the difference from a log. They can tell by deleting their FSUIPC.KEY file and trying again. Not for a gauge or DLL. Pete

The variables (just Joystick Number, j or joy#, and Button number, b or btn#) are the same throughout. A button is ALWAYS identified by these two numbers, separated by a comma, and this is actually explained in words too. Why is this i any way a "bump". You interpreted "j,b" to mean "button number, button number", somehow introducing another button for some reason and ignoring the consistent system introduced and used throughout. This is where I don't understand how you managed it and which you have not been able to explain. :-( Ah, then I think you must have missed that step? I have no idea why you still need conditionals. Why does one button (0,22) have to be "pressed" (i.e. on) to make the other (0,23) work? It is looking as if you have the (cheaper?) two phase encoders after all? None at all, sorry. I really don't know how your encoders are operating. I'e never met any which need any form of conditionals to operate -- all the ones I have are simple and can be programmed in the dialogues with no problems at all. If you can get the phase timing diagrams for your encoders and show me, then perhaps we can work it out. They should be available from the manufacturer. Regards Pete

Good. Thanks for letting me know! Regards, Pete

That's why it's best to cut-and-paste. Don't forget to make a safe copy of the details (e.g. the FSUIPC.KEY file out of the FS Modules folder) somewhere AWAY from the PC. Hard disks do crash. Never trust information to be really safe in a PC. Regards, Pete

See "READ THIS IF YOU LOSE YOUR FSUIPC or WIDEFS keys" near the top of the forum. Pete

Thanks .. maybe I didn't eliminate that duplicate after all. There were several in the CONTROLs.DLL list. Maybe I missed one. Pete

Sorry, can you be more specific on the location? I am looking through it all and I cannot see where your "clear" bit ends and the "geek" bit starts. you say "on the very next page" but I cannot see any clear page demarcation for anything. Can you identify the actual heading, words, or something to help? The "easy" section (i.e. no conditions) defines the format with: = ,,C, and similar. Is this not "Geek"? The start of the section on conditions is a little more abbreviated: n=CP(+j2,b2)j,b, .... n=CU(+j2,b2)j,b, ... n=CP(–j2,b2)j,b, ... n=CU(–j2,b2)j,b, ... but surely the "j" and "b" references here strongly (unambiguously?) suggest the same as the and or your "easy" bit? There is even an explanation just a little later: (+j2,b2) means that button b2 on joystick j2 must be pressed ("on") for the current button action (for j,b) to be obeyed. (–j2,b2) means that button b2 on joystick j2 must be released ("off") for the current button action (for j,b) to be obeyed. The j,b,part is the usual button parameter, for the action of the “current” button which is button b on joystick j. In other words, the meaning of each symbol used is defined, just as it was in the earlier part. Please tell me why one is "clear English" and the other is "Geek". Agreed, the business of using conditionals is going to be more complex than simple definitions of "button X means do Y", but surely you must expect that? This stuff has been like this for years and I've really not had such adverse comments as your in all that time. Folks who don't understand conditionals apparently don't need to use them (as in fact it turns out you don't). I am left bewildered and confused here. Please help. Regards, Pete

I doubt it, but I don't really know. There are nearly a thousand controls in FS these days and I just haven't had time to try them all and see what they do. I think many are "left over" from previous releases and may or may not still work. And I know that some were added for future use, but that future doesn't seem to have arrived yet. FSUIPC doesn't "invent" the FS controls -- they are from a list in FS's CONTROLS.DLL. The words are obtained from there too. FSUIPC does ADD quite a few of its own -- those are listed in the Advanced User's guide. I can only suggest you assign some and see what they do, if anything. No, I don't think so -- it's an error in the list in CONTROLS.DLL. what version of FSUIPC are you using? I thought I'd eliminated that -- try the latest Beta in the first thread above. Let me know. Regards, Pete

I think it refers to a specific type of encoder (aparently called a "two-phase" type) which, instead of having two separate button outputs, one for each direction, has two outputs which pulse in different phases depending on the direction the knob is turned. I assume these are some sort of cheaper alternatives to all those I have seen. I have never actually had one such in my hands nor is that section authored by myself, but by a contributor who has experience with such devices and worked out how to program them. Please check whether you have "two-phase rotary encoders" or the more common (as far as I can tell) simple twin output digital ones. If the former then you'll need advice from someone else, not only for programming them but also probably for wiring them up. Er. Yes. How did you arrive at that? What would those two button numbers mean on their own, with no joystick number? Why two buttons, what happens to them? The line 1=CP(+1,1)1,2, ... is the same as 1=P1,2, ... but with the condition (+1,1) applying to it and the "C" warning me that the condition is coming. The active button declaration is the same -- how do you read my documentation in another sense, please? I will have to revise that somehow but I need to know how you arrived at such and what you thought it might mena. No, not at all. I expect you to understand complex things if you want to do complex things. Flying an airliner properly is a complex thing too, and folks have to understand a lot. If your rotaries are complex and need complex programming you will need to understand more about how they operate first and then delve into the complexities of programming them. Or else go purchase the simpler ones which have three wires and can be programmed as two buttons, one clockwise and the other anti-clockwise. Having done that, discard the Advanced User's guide for FSUIPC and just program them in the Dialogue on screen. My philosophy in all these things has been simple ways to do simple things, but allow more complication to do complex things. If I don't work that way I'd not get very far -- I'd still be trying to write the user interfaces for obscure stuff from long back. Regards, Pete

GoFlight modules don't use FSUIPC nor vice versa (excepting when you've programmed a GF button in FSUIPC -- but it still doesn't use a GF FS module, only the GFdev.DLL which is elsewhere). If FSUIPC is not set to process the axis, then it doesn't touch it at all. It is not touching it when it says "Set" in the top left button in its section of the options. It has got to be calibration, sensitivity or dead zone. For the latter two go to FS's Options-Controls-Sensitivities. Ensure max sensitivity, and eith no or little null zone. For calibration I have no idea -- Windows I expect, but check GF documentation. Always calibrate the two end positions with the lever OFF the end stops a bit, to ensure it will always reach the extreme values. Regards, Pete