Pete Dowson

Only if you are loading it using one of the Run parameters in WideClient.ini. Are you? Even then, the problem is only because SA_WXR (exceptionally) expects the default disk folder to be the one it loaded from. That's easy to ensure by simply running WideClient from the same folder. It was fixed in any case in the interim release available above. Most Windows-based programs deterine their load location by using the appropriate Windows API call. The practice of assuming the current folder is the one you want derives from way back in DOS days. I don't know that one -- the original problem didn't seem to relate to config files at all, at least as far as its error report went. Sorry. You'll need to ask Florian. Regards, Pete

If you want to run FS + WidevieW on the same PC as WideClient with a touch-screen, this is possible provided you don't wish to actually run FSUIPC applications via that WideClient. You would need to change the Class name used by WideClient, otherwise it and FS cannot be run together. See the "ClassInstance" parameter, in the documentation. Regards, Pete

Thanks for letting me know. I'll try to remember this in case it happens to anyone else! Regards, Pete

If FS is running full screen it is next to impossible to get a window overlaid on it -- those who have achieved it from modules running within FS, like FSPassengers and FSNavigator, have done very well to have managed it. It gets very complex trying to work around the full screen use of Direct3D to get windows displayed without flicker. If FS in running in Windowed mode then any program can display a window on top, it is just a matter of manipulating the Z order and setting your window to the fore. Writing a module to work as part of FS is no easy task, and in VB it is even more difficult -- in fact until recently I would have said it was impossible, but I think someone has achieved it. Regards, Pete

Unless it's a 64-bit compiler (for a 64-bit processor), a normal "long" won't be long enough. I don't know VB -- someone may chip in and help out -- but if you read the description of what is in 0570 again you will see that it would be possible to read the 8 bytes into two "longs" in an array (or even use two separate reads into two separate longs). The first will contain the fractional metres and the second the whole number of metres. You'd need to treat the fraction as unsigned, though, and I know that is next-to-impossible in VB. In my opinion, from what I have learned here, VB is a very frustrating language I'm afraid. Pete

The wparam and lparam values are the parameters for the WM_KEYDOWN or WM_KEYUP messages. You need to refer to Microsoft Windows programming references, for whatever language you are using. For combinations like Ctrl+N you have to do the same as the keyboard would, i.e. Press Ctrl (KEYDOWN) Press N (KEYDOWN) Release N (KEYUP) Release Ctrl (KEYUP) i.e. 4 operations -- 4 separate writes t the 12 bytes at 3200. You may want to consider toggling a bit in the virtual joystick offsets instead (see 3340) and then simply programming the resulting button press in FSUIPC's Buttons page to send the Ctrl+N. It would be easier. Regards, Pete

That's not from me. It's probably an automated confirmation from SimMarket. I don't have anything to do with any of the selling and registrations -- too busy programming and supporting! Again, not from me. See "what to do if you lose your key" thread above. I think you just have to open your account. nothing to do with emails. Pete

Could you update to 3.50 (or even the 3.507 available in the top announcement here) please? I doubt that it will make much difference, but it is supportable in case I need to ask you for more information. Gauges don't actually have to be in the Gauges folder, though that is most usual. The way to find them is by looking at the PANEL.CFG file (in your aircraft's Panel folder). Any editor can be used to look at it. If the PANEL.CFG file is not loading a SEM.GAU, then there's some problem with renamed gauges there, somewhere. Not sure what you mean by "error spike"? But there's no "cpt_F16.gau" listed here that's ever had an access key. Regards, Pete

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