Pete Dowson

That's really weird. It seems likely to be something to do with the video drivers in that case. Can you go into Options-Settings-Display, Hardware tab. See if "render to texture" is checked. If not check it, if so uncheck it -- see if that makes any difference. The other thing to try is different video drivers. What video card is it, and what driver version (in case it is relevant ot others reading this)? Regards Pete

How strange. Sorry, I've no idea what the PMDG team have done which would cause such odd things. The only things I can suggest are: 1. Instead of docking it, try locking it into a suitable position. It won't come and go with panel parts then, but you can program an FSUIPC hot key to hide and display it. 2. Try hiding it completely ("hide Always) and run the little utility ShowText instead. Being a completely separate program it should not interact with anything in FS. Of course you may need to run FS is maximised windowed mode instead of full screen mode -- but the only penalty from that is the presence of the title bar, which is barely noticeable in high resolutions. [As an aside, maybe the problems won't occur in Windowed mode anyway??] 3. If you have another PC, use WideFS and apply the ShowText solution to that. I haven't got the PMDG 747 and it isn't something I'm interested in, but if PMDG are interested in resolving this they can contact me. I might need a copy of the aircraft "on loan" to look at it. By the way, PMDG seem to have a little (short) history with AdvDisplay. I seem to remember some folks having trouble with the AdvDisplay text flickering when the PMDG landing lights were switched on. Weird. No one ever got to the bottom of that -- I presume it still happens on some systems. Regards, Pete

Okay. You are not getting WideClient to run anything else, so that's not the problem. The only thing extra which WideClient will be doing when it connects to FS is to start scanning Buttons, in case you want to send button presses to FSUIPC for programming. It does this two ways. For normal Windows-connected joysticks it simply calls the standard Windows API "joyGetPosEx". That is supported in all versions of Windows and most certainly Win2000 as well. The only possible thing I can think of which might go wrong is if there's a joystick installed with a driver which is not Win2000 compatible -- though how you'd get it installed would be somewhat of a mystery. You could try checking for joysticks using the Control Panel "Game Controllers" facility (or whatever it is called on Win2000). The other thing it runs, if it can find it, is a module called "GFdev.DLL", which is the GoFlight device access library. Now I've checked that here and it, too, most definitely does not use "GetRawDeviceList" -- and in fact it works fine on Win2000 as well as WinXP. However, maybe another module by the same name is being picked up. Is this possible? Can you search your Windows folder for a GFDev.DLL (you will have to change folder options to unhide system files and show full names). I really cannot think of anything else that could be happening. If neither of the above yields any results for you I can try supplying a modified version of WideClient with a new parameter to set to make it bypass all the button-checking options. But could you also edit the WideClient.INI file and set "Log=DebugAll" in the [user] section, and let me see the log. (If it is too big, Zip it and send it to petedowson@btconnect.com). Regards, Pete

The log does not show any such plane being loaded nor any gauge being unauthorised. If you want me to help at all I would need to see a log which is relevant. There's absolutely no useful information in this one at all. There's also absolutely no reason an unauthorised gauge to prevent an already loaded and working DLL from working -- unless the code in that gauge itself is going berserk and corrupting ActiveRadar in memory (which would indeed make it a dangerous gauge in any case). But why would it pick on ActiveRadar and leave everything else okay? Sorry, but it is really up to the authors of the ActiveRadar module to determine exactly WHAT it is that doesn't work in their code, and sort that out. From what has been said so far it sounds as if it "almost works". If its access to FSUIPC were being lost surely it wouldn't work at all? The authors should be able to diagnose this easily enough with the correct logging. I cannot do so as it isn't my program and I don't even know what it is trying to do which doesn't work! Regards, Pete

Well, that USER32.DLL procedure isn't used by WideClient, nor is it called by anything WideClient calls (I've just used ProcExp to do a dependency check). It looks like something WideClient is running needs that procedure. Can you show me the WideClient.INI file from that PC please? What operating system are you running on the other PCs? I've checked the USER32.DLL in Win2000, and indeed it doesn't have a "GetRawInputDeviceList" procedure -- it looks like that is specific to WinXP (maybe also Win98/Me). Something is not compatible with Win2000 by the look of it. Let me see the WideClient.INI file first, please. Regards, Pete

Sorry, I don't understand. If whatever you are clicking operates one of the FS controls to do something (and most if not all, at least in the default panels, do), then you already know those controls and can use them -- they are listed in FSUIPC's dropdowns in the Keys and Buttons options pages, and also in the List of Controls documents I provide. If such button clicks do not simply give rise to an FS control -- and that is indeed the case with several default mouse places and very much true for most sophisticated add-on panels -- then the click action is processed by code within the gauge itself or passed on internally to some other part of the panel, or even a co-operating DLL (as for instance in PMDG aircraft). There is no way FSUIPC or anything else can get into that sort of operation. What do you expect it to be able to do, exactly? Incidentally, what do you mean by "limited to basic default commands". Is there something you need missing from the many hundreds of FS controls available? Regards, Pete

I think these must be all (default) libraries which come with Windows development kits. Certainly "uuid" is, and I think "LIBC" is a standard Microsoft C library. Possibly your compiler package doesn't support Windows without adding a lot yourself? I think you may find it more constructive to use the SOURCE I provide for the interface code and make your own library suitable for your compiler, or else just build the code directly into your program. There really isn't much of it. There's nothing hidden there -- everything is provided in the SDK. Regards, Pete

Thanks, Lefteris. Do you think he'd object to me putting something like that in the SDK? Regards, Pete

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