Pete Dowson

You shouldn't need to do that if you start at least one engine and its generator. The battery life option just "cheats" by making the battery last longer, up to forever. If the battery had failed you wouldn't see anything, on the radios or in any of the glass cockpit display screens. It sounds like you've just not enabled the mode you want. Doesn't the PSS A320 come with any documentation? They are usually pretty good with their manuals. Regards, Pete

Sorry, there is no way I can support such an old version of WideFS (three years I think). The current version is 6.50. I don't think you can run WideFS 5 on any FSUIPC 3.xxx version in any case. Also, if it is WideServer which says it can't run, it is the WideServer.LOG file which is relevant, not the client one. Regards, Pete

Not without it being written that way, no. What is wrong with it as a separate program? I often wish FSNav was a separate program, as then I'd run it on a separate PC. As it is I don't use it as my FS PC is totally occupied in providing the scenery view only. >> Thus, the question is: can any application be made to run as a module that would run in FS2004 in full screen mode without the user having to task switch? << No, not without the program sources and a deal of programming skills plus suitable language tools. Sorry. Regards, Pete

Always the latest. I'm using 1.21, not yet released. Where did you see 1.20 by the way? I presume it was attached to a reply to someone who asked for something? In the "Supported Releases" list above it does say 1.10, but all those numbers there are just minimums. I don't revert to older versions. Forever onwards! ;-) One of my problems is that I can develop faster than I can write documentation (or maybe it's an aversion! :-) ) Regards, Pete

Glad you found the answer. Perhaps the author will ask Mr. Schiratti to put a link up on his "Peter Dowson" page (there is a long list of FSUIPC-using programs on the right-hand side). It is possible, but I don't do such things unless they are offensive or duplicated. In any case it may help the next person who is looking ;-) Regards, Pete

Is there a Modules menu? It is usually FSUIPC which creates it. If FSUIPC isn't there, what is? There's really no way I know that FSUIPC, properly installed in the FS Modules folder, and properly still named "FSUIPC.DLL", will not appear in the Modules menu. Please double check. You have probably put it in the wrong place. Regards, Pete

Most of the variables listed in the second table of the Programmer's Guide can be made available if needed. It's just that the can't be mapped directly, so extra code is needed to obtain them at regular intervals and place them into mappable memory. They were all mappable in FS2000, which is how they ended up being listed. I only tend to add such extra code when requested with good reasons, because it all adds to the performance limiting path through my code. Obviously if you are using the Panels interface directly there is no advantage in asking FSUIPC for them -- I would probably have to do the same as you (though I tend to bypass the PANELS.DLL call indirection and ask the Sim engine directly). Regards, Pete

1. There's no "freeware" and "payware" FSUIPC, only the one FSUIPC. If it is user-registered you can access the extra facilities, if it isn't, you can't, that's all. 2. The installation is as described in the User documentation, which of course is part of the purpose of such documentation. And yes, it is just a matter of copying the DLL. Since this is so simple, and since it is thus made so clear that nothing else, hidden, is going on, I prefer such a method. Self-installers always leave me wondering what's gone where, and especially what horrid entries they've made into the Registry. Pete

Oh, right. Good. No, because I don't know. For most things you get best results by trying to match the FS frame rate, so setting FS's frame rate limiter to, say, 25, and writing every 40 mSecs should be okay. But having said that, some things in FS do seem to be updated at a faster rate. FSUIPC doesn't get to know about these because it, too, is triggered by the frame rate (with a standby 55 mSec timer for paused and minimised periods). Experiment some more. If you find FS is interfering too much between your writes then I can look at doing the same as I did for the vertical wind -- take the last value you wrote and repeatedly write it for you till you write another, or until a timeout expires (which could be 10-14 seconds, allowing your program to also run on WideFS from a client). Could you tell me the exact application of this? What is it you are doing with it? Regards, Pete

Setting the speed to zero isn't possible, it is dynamically caliulated using the velocities and accelerations you'll find in the higher offsets. You can write to those with some, temporary effect, but you have to keep writing. Well, that could be made to work using the already FSUIPC-implemented "flight freeze" facility, which holds the latitude and longitude but not the altitude. That was reqested for use in flight training schools -- the aircraft continues to fly and has speed, but it's position over the world doesn't change. All you'd then need to do is maintain altitude. The flight freeze facility was added in version 3.44, with a bug fix in 3.45. Check the FSUIPC History document -- it's the second item under 3.44. It is usable by programming buttons and keys as well as through FSUIPC offsets. Regards Pete

You can download it and use it with freeware applications that have an access key, and also with accredited payware programs. Without paying you don't get any of the user facilities, that's all. There are announcements at the top of this Forum explaining everything. Also, if you download the ZIP and read the user guide, everything is explained there too. Pete

It is enough to indicate that there is something wrong with your Keys, either the FSUIPC one or the WideFS one, or both. Can you tell me where you purchased them, please? There are some illegal key generators around and they can produce exactly the results you are getting. I can see an Ingmar Bail listed as purchasing an FSUIPC key back in April 2004, but I have no record of any WideFS purchase at all. However, my records aren't complete and are only from one reseller. Please ZIP up your FSUIPC.KEY file from the FS Modules folder (do not send it without Zipping please) and send it to me at petedowson@btconnect.com, and I will confirm this or otherwise investigate the problem. Regards, Pete

Yes, it is the spaces in the names which confused my programming. Thanks for confirming. No, no need. But I always find it more convenient for several things to keep away from such folder names. Just something to think about for the future. ;-) Regards, Pete

I really doubt whether that is possible without actually patching code someplace. Even if it were possible, to find the correct place to patch in a new value so that it gets used consistently would involve another nightmare of tracing through hideous C++ compiles code at machine level, trying to recognise things as they crop up. Even if I understood this area it would be very difficult, and would be many many hours of tortuous hacking. The best you could possibly get easily would be if FS responded at all to you writing to offset 28C0 (FSUIPC does allow this). If you can induce any effects whatsoever writing there (and you'd probably need to do it as frequently as possible), then I could try to provide a way for FSUIPC to sustain the writing at closer quarters (i.e. faster and in time with FS's recalculations) to try to override FS's own computed values. I have done this for some other areas, notably the vertical wind component (used to simulate lift for gliders, for example), and it can work, but getting the timing right is important to stop fluctuations. Regards, Pete

Try http://www.flightsimmer.com/. I think they get some capable technical folks there. If they don't know I expect they could tell you where else. Regards, Pete

That's more or less what I do in PFC.DLL for the PFC jet cockpit, which has a tiller axis input too. I actually go further, gradually changing the sensitivities of the two inputs -- what FS sees is a combination of the two, all tiller at 0 kts, all rudder at about 60, half and half at 30. You can do something very much like it now, using the multiple control input facilites. You won't get the automatic changeover between the two inputs which I implemented for PFC -- but you can do that yourself of course, just take your hand off the one and use the other. You would calibrate the tiller input (in Windows' Game Controllers and/or FS Assignments) to give maximum effectiveness over a smaller range, and the rudder using its normal full range, thus emulating the greater turning power of the nosewheel. Just check the section in the Advanced User's guide on Multiple Joysticks. You can actually have up to four different inputs for all three flight controls, as well as the proportional brakes and main (single) throttle. FSUIPC takes the one with the highest deflection, so you just park or leave the unused ones alone (making sure they have an adequate null zone so they don't interfere if they jitter). These facilities have been available in FSUIPC for a few years now I think. Regards, Pete

Well, I never! I didn't even know FS did that. I certainly have never come across anything that I would recognise as a trigger value for this. If you know where this is or how it is set I can certainly add a setting for it. Perhaps you could ask around in an aircraft designers forum someplace? Regards, Pete

Quite honestly, all that certainly points to something going wrong with TeamSpeak. FSUIPC can in no way interfere with TeamSpeak seeing the keyboard directly, and the fact that it doesn't see the same key when pssed through FSUIPC isn't really relevant, as it is evidently just the same problem. Furthermore, the fact that reinstalling Teamspeak "fixes" it temporarily also seems to show that it is something in Teamspeak's own settings which is getting changed or corrupted somehow. Neither FS nor, especially, FSUIPC, know anything about TeamSpeak. It is entirely separate and has no connection or overlap with anything FSUIPC does. Me too, since, as I say, there cannot really be any connection. Possibly a very small difference in timing, or real memory usage, due to the few differences between 3.48 and 3.50, but this is clutching at straws. Nevertheless, if you load TeamSpeak before FS, try it loading after, or vice versa, just so they get different real memory allocations. Please don't bother. Now that I understand the use of the keyboard directly also fails, it explains very clearly why FSUIPC's button programming does too -- after all, all it is doing is seeing your button and sending the NumPad 0 keypress which is being ignored in TeamSpeak just as it is when you press it directly. One thing though. Can you try another keypress instead, one NOT on the NumPad? Maybe it is related to the Num Lock setting on the keyboard? Regards Pete

Ah, something easy then! Good! ;-) Regards, Pete

Just so I can understand that, can you tell me the full pathnames to both SA_WXR and WideClient, please? I think it must be related to path depth and spaces in pathnames. The latter, in particular, create big problems when trying to allow for parameters to be placed after the program name, and it is that which I was trying to rsolve in 6.500. I think it is right now, but I'd like to be sure. Thanks, Pete

Actually, for completeness, it is the FSUIPC Log which is needed. Start everything up, get the problem, close FS down, then let me see the FSUIPC Log file. Also the WideClient and WideServer log files are much more useful after FS and WideClient has been closed, as they both place performance summaries at the end of the Logs showing how many blocks have been exchanged and how much data. This looks more like some sort of data dependency in SB3 -- it isn't seing something it wants to see. The connection looks fine. Regards, Pete

I don't think so, because I run SA_WXR from its own folder using a WideClient run from its own folder. The same Wideclient actually starts up several different programs all in different folders. However, having said that it may be related to spaces in folder names and the number of levels down in the folder structure the program is stored. I have revised this area of WideClient and tested it here in a variety of complicated circumstances, and attach WideClient 6.503. By all means try it. Regards, Pete WideClient6503.zip

You mean actually using the keyboard? Unless you've programmed that in FS or in FSUIPC for something, neither will be stopping TeamSpeak getting it. In any case I would assume TeamSpeak must capture it beofre anything else gets it, i.e. as a Hot Key? No, sorry, none at all. Anyway, I'll need more explanation about exactly what you mean by "getting a problem with [both] the keyboard assigned teamspeak button". The button actions in 3.50 are really the same as they've always been. I don't understand why you get a difference. You can check that the button assignment itself works quite easily by assigning it in FS to some function you can recognise. This is how I test it. The actual method used to send the button hasn't changed, so your experience is really weird. There's also some extra logging (see Logging page) which you can enable to check button actions. Can you switch it on and let me see the results in the FSUIPC Log please? Keep the test short. Pete

Well, they are as accurate as stored in FS's weather data arrays. There's no other values that I know of. They use 32-bit floats. If my results are inaccurate this will be because of different interpolation methods -- I'm assuming linear, but I don't know if that is correct. Have you checked whether the temperature gradients are linear between the specific layer levels? The other area where it will be wrong is below the lowest temperature layer. I've nothing to interpolate it with there. Anyway, try it and let me know. In the attached interim version 3.504 you can read my interpolated value in the 16-bit word following the OAT. i.e. offset 0E8E. Regards, Pete FSUIPC3504.zip

Yes, the dew point at the aircraft, exactly like the OAT in 0E8C; 1/256th of a degree would be very good. I've done some checking and I can't actually find the exact dew point at the aircraft altitude, except by extrapolation given its altitude and the temperature layers below and above. I could do it assuming a linear gradient between the two (or a fixed temperature above the uppermost layer). Would that do the job for you? Otherwise I can't see any way of getting it I'm afraid. Also, I have to limit the frequency at which I read the weather at the aircraft as it does affect performance. Currently it is set to get it once a second. Given these restrictions, will it still be of use? Regards, Pete