Pete Dowson

Aha! My fault entirely. I omitted to mention a parameter you need in the [user] section. Ooops! Can you try adding "ButtonScreen=Yes" to the [user] section, please? Let me know. I think, if that isn't there, it doesn't look for a [buttonScreen] section. (You can have a button screen with just a matrix of buttons and no labelling, which wouldn't need a [buttonScreen] section). There's a complete section on this missing in the WideFS documentation! I'm really terribly sorry about that! Seems you are the first person to try using it since I released it in 6.50 at the end of August! :-( Regards, Pete

On the contrary, the ILH_TCAS gauge is confirmed as registered, thus: The problem appears to be with Sem.GAU, which I'm afraid I've never heard of and which certainly does not have an access key granted: The odd thing here is that the this appears to be Module 2, which is the same module number as the ILH_TCAS gauge. Could the gauge called "Sem.GAU" actually be a copy of ILH_TCAS renamed? If so, then that would be the problem -- renaming the gauge causes the identification of its calls to go wrong (obviously, FSUIPC trusts Windows to tell it the names of the gauges in memory). Check your PANELS.CFG file, see if it loads both ILH_TCAS and SEM, or only one. If it is SEM only, change it (rename it) back to ILH_TCAS -- the GAU itself will probably be in the Gauges folder. BTW, please always give the version number of FSUIPC in such reports. If not the latest it is always wisest to check with that first, too. Regards, Pete

There is a limit on the window size below which the buttons cannot show. Have you tried dragging the screen borders to size, or even maximising the window? I've been using this feature continuously since I implemented it -- I use a Lilliput 7" touch-sensitive screen in my cockpit and the extra buttons it provides have come it very useful! I'm pretty sure the ButtonScreen example in the Manual works as it was one of my first test examples, but please post the copy from your own INI for me to re-check. Also, please tell me what version of Windows you are using. Maybe that makes a difference, though I doubt it. Regards, Pete

Look again at that pair of messages. The Module is called "PSS-B777.gau" but it is attempting to register itself as "PSS-777.gau". Do you see that the "B" is missing? PSS have not requested registration for a PSS-777 gauge at all, and in any case the name in the access request MUST match the name of the Gauge. You need to report this to them. Haven't they tested such small matters before Release Candidate stage? That is entirely dependent upon the code in PSS's gauge. Certainly there is nothing in FSUIPC which would do that. However, you also say that your FSUIPC is user registered? If so then it makes no difference whatsoever whether the gauge is registered for access of not. Your subscription for FSUIPC covers access for everything. Although FSUIPC will log the details, to aid in development and debugging, it will not prevent full access to a user-registered install. Seems you need to report this to PSS and get the 777 fixed before user release! ;-) Regards, Pete

Doesn't the GPS provide the same needle indication? If not have you checked to see if any of the GPS data locations (offsets 6000 ff) provide what you need? I'm afraid I know almost nothing at all about the GPS additions in FS. AhI'm pretty sure that the RealityXP GPS does its own calculations. There is no way FSUIPC can burrow into its code and extract such information. You would need to ask RealityXP if they have a programmer's toolkit for this. It is the same as the problem with sophisticated add-on panels such as those from PMDG and PSS -- most all of their systems are separate from FS. Regards Pete

The default HSI is driven by NAV1, so it is the NAV1 needle value you want. The horizontal needle is the glideslope, the vertical one is the localiser. There are values for NAV1 and NAV2. There are no others. What different indication from those are you after? What do you think it is showing that is different? FSUIPC does not use the Panels interface, which is where the internal simulation values (exposed in FSUIPC's offsets) are 'converted' to your 'Token Variables'. Regards Pete

Okay. If you do manage to narrow it down, please let me know what it was. And next time you have an FSUIPC.INI file which appears to cause FS to hang on loading, please save a copy and send it -- I am very curious about that. I really cannot see any way this should be possible and it needs investigation. Regards, Pete

First, please always state the version of FSUIPC. If it is not the latest supported version (3.50 or later at present), please upgrade first and retry. FSUIPC's menu can be used and on display for a long time without adverse affect on FS. I don't see how any simply internal operations such as re-coding keypresses will make any difference. These merely adjust internal tables. It doesn't even invoke any file access until you exit, when it re-writes that part of the INI file. What happens if you simply enter the options and leave it there for the same length of time without doing anything? as far as anything external to FS knows, this is exactly the same thing. If that also causes problems then it may be down to some application or panel trying to use FSUIPC which is screwing things up by being held up for so long. FSUIPC can hardly respond to requests from these properly whilst its options are being changed. Hmmm. There is no permanent change made by FSUIPC which could do that. Even if the FSUIPC.INI file was corrupted it shouldn't be able to do that. I need to see the INI file you think is responsible for this. But please re-test with the latest FSUIPC, 3.507, available in the top announcement in this Forum. If you were not using 3.50 beforehand in any case, then I'm afraid none of your report is relevant in any case as I can only support the releases listed. You are getting a crash in FS9 too? You don't mention that. In which module? Normally you should get a Windows crash report, and you can opt to have Windows send the details to Microsoft. If you still get problems with the latest version of FSUIPC, try to narrow it down to specific applications. Possibly the panel you are using? Try a default aircraft, see if that's the same. External programs? Try without each in turn. Other add-in modules? Some use FSUIPC too. Maybe some are impatient and don't like being held up? Regards, Pete

I think the only way you'll get a value for IAS changes over time is to read it and record it at known intervals. Read the millisecond counter at the same time so you can keep it correct with respect to varying intervals (due to Windows message processing, process switching and varied FS graphics, sound and disk loading). The best timer to read is probably the millisecond one provided by FSUIPC itself, at offset 3374, as this will almost precisely reflect the actual time it met your request. Regards, Pete

No idea, but it doesn't sound right. It seems to me that you can't keep both the IAS constant AND the acceleration zero if the wind velocity is changing. Also, though I don't know whether it is modelled in FS, I would have thought that a vertical or lateral movement would have some (small) effect on the pressure in the pitot tube even though it is aligned with the longitudinal axis. The FS simulation engine is dynamically recalculating all these things all of the time. Results like the IAS would likely be a derived value, not one resulting from any trend or prediction, so why would there be a specific IAS "acceleration" for you to read? Incidentally, the TAS is more what you would want in any case, as some changes in the IAS will also be due to pressure and temperature changes, which will certainly be occurring during climbs and descents as well as more slowly in level flight. Why not just use FSUIPC's Monitoring (on the Logging page) to display it dynamically on the FS screen (adv display option checked). You can see what it is doing then. [LATER] If all you want is some trend indication in order to adjust thrust, or display the trend on the airspeed tape, then I don't think you are going to get anything better than the body-axis acceleration. Maybe you would need to "smooth" that a little too, to remove spikes due to wind gusts or turbulence, but it is worth looking at in any case. Regards, Pete

Did you search thoroughly? What about 3070, the longitudinal acceleration relative to the body axes? Pete

I don't know whether any of the GPS controls tabulated in CONTROLS.DLL (and hence listed in FSUIPC's drop-downs) are actually hooked up in FS2004. Have you tried any of the others? No one has ever confirmed that they work. It is entirely possible that the FS team fully intended to link them up but that this didn't make the final release. If they are not so linked then the GPS buttons on the gauge are only mouse-activated. The controls list contains old controls which used to work but have now loost their function (because of re-written code which isn't linked), and controls which were added ready to make work but which never actually did. I'm afraid that, though back in FS98/2000 days I did test and document each one, I simply never have had time to do so since, and with a growing list (it never diminishes) it gets harder. That implies that the table in CONTROLS.DLL doesn't have the correct flags to activate it, or a pointer to a PANELS routine to process it. I did decode a couple of the flags years ago (ones classifying controls as Axes or Buttons) but there were some which I never faathomed. No, I never found anything for the GPS except the area of readable data (mapped at FSUIPC offsets 6xxx), and even much of that seems in doubt. I doubt that you are missing anything. Sorry. My only suggestion would be to use something like Luciano Napolitano's "Key2Mouse" to map keypresses (programmable on buttons) to mouse events. [LATER] I've just looked at the default GPS on the 737. Where is this "power button" anyway? If it isn't implemented on the device, the control, even if valid, won't operate anything. I tried some of the controls for buttons the GPS does actually have, and they do seem to be linked up okay. Therefore I think the problem you have got is that you want to implement a function which isn't actually programmed in FS at all. Regards, Pete

Not without hacking into FS code. None of the weather data is exported at all. Regards, Pete

Ah, this is just a carry-over from earlier FS versions which didn't allow negative altitudes in weather data. I think it should only affect read-outs, not weather being set through FSUIPC. For read-outs just treat it as a signed short instead. Is it affecting the new dew point calculations? If so I'll check that and fix it before a full release. There are no float types fitting in 16 bits. Just a desgn decision at the time, mostly from historical usage. There's no way any of this will be changed now -- too late, too many dependencies. Sorry. Regards, Pete

This is now done and available in the interim test version 3.507, see top announcement above. Could you try it and let me know if it works as you'd expect, please? Regards, Pete

I have added a per-message white-text setting option in interim version 3.507 of FSUIPC, available in the top announcement above. Note that this isn't compatible with AdvDisplay at present. Regards, Pete

Interim version 3.507, available at the top of this forum, fixes the slope-saving bug. Regards, Pete

Okay. I think I found and fixed the problem in interim version 3.507 -- see top announcement above. Please try it and let me know. Sorry about the mess before. Regards, Pete

Did you put that parameter into the correct section in the INI file -- i.e. in the [user] section, as documented? Was the Wideclient window the active window on the Client PC when you pressed the key? If it does not have the keyboard focus it cannot receive the keys in the first place. Did you assign '.' to the parking brake in FS, then? By default that key merely operates the brakes momentarily. Regards, Prete

Not sure I understand all of the question, but certainly FSUIPC supports a separate reverser axis if that's what you want. Take a look inside the FSUIPC.ZIP package and browse the User documentation provided. Regards, Pete

The problem is almost undoubtedly the network. Something is failing, but whether it is one of your network cards, the cabling, or the drivers I couldn't say. You would ned to try replacing/checking each in turn. Another possibility is that the video card is sharing IRQs with the Network card -- maybe moving the latter to a different slot may help. The tell tale entries in the Log are: Whilst there are not many of these, the fact that they occur at all is worrying. They are also occurring on different sockets, so the prime suspect is most likely to be associated with the Server PC. The following errors, on the Client, are, however, evidence of something going wrong with an application on that client. These are nothing to do with the Network, though I suppose it is just possible that bad data caused by Network problems may cause the applications to go wrong too. I notice you are using an out-of-date and unsupported version of WideFS still. If you do need further help it would be best if you updated your software first. Possibly FSUIPC too if it is earlier than 3.50. Regards, Pete

Registration is not a function of the DLL, only the local KEY file on your PC, which is generated when you register. There is no registration effect of merely updating the DLL, and in any case you should always keep up to date. Older versions are not supported. Pete

If things work with FSUIPC without your user registration it is a pretty sure indication of an invalid (i.e. illegally generated) user key. Deleting the KEY file containing the pirated key is the correct and only solution. Pete

Check the units! FS's display shows degrees, minutes, and then either seconds or fractional minutes (depending on an FS9.CFG option). You and FSInterrogate are showing just degrees and fractional degrees. 50 degrees and 45 minutes would be 50.75 in degrees only. 50.72 degrees would be 50 degrees 43.2 minutes. Hmmwell, it is really your fault ;-), but only in the sense that you are assuming that you and FS are displaying the values in the same way. You need to know that though there are 100 hundredths of a degree in a degree, there are only 60 minutes in a degree. Similarly there are 60 seconds in a minute. You just need to do a bit more arithmetic. ;-) Regards, Pete

You don't open FSUIPC's file. You don't deal with DLLs at all. The FSUIPC DLL is installed in and runs as part of Flight Sim. You need to get the FSUIPC SDK and check the examples there for the language you are using. When we say "Open FSUIPC" we mean "open the link to FSUIPC" -- this uses a call to a procedure/function called FSUIPC_Open. Regards, Pete