Pete Dowson

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

I think some programs expect to be run with the "current folder" set to their load folder. They should really not make that assumption -- it is easy enough to find out where you were loaded from. This may have changed in Wideclient when I added the facilities to provide command-line parameters to the program being loaded. Possibly the way I had to do this also changed the new process's "current folder". I'll check this, as it wasn't intended to change anything which may have worked before. Regards, Pete

Ah, the dew point. At the aircraft? I could provide that in the same units as the OAT if you wish. Is that accurate enough? I'd just need to look for a suitable 16-bit word somewhere. Let me know. Regards, Pete

OAT at aircraft altitude is at 0E8C to 1/256th of a degree. You just need to move your aircraft to the altitude at which you wish to measure it. The values I read from FS internally are of course more accurate, but there's been no need for such in a complete and general weather reading/setting context, which is what the interface is for. Regards, Pete

FSUIPC just maps them into locations in FS which have been identified as containing these things. Quite honestly I don't know much about them myself. If you know more, please tell us. Yes, to make them nice and compact so I could allow more layers. They are converted to floating point values when submitted to FS. I'm not sure the term "begins from ..." is correct there. I think Fs uses these temperature points to define its temperature gradient. There shouldn't simply be a layer of one temperature then a layer of another, and so on. these are sample positions on the gradient to define it. Well, those are the numbers I submit to FS's Weather DLL. Why would I change them? But as I say, these are only sample positions to define the required temperature gradient. [Later] If you mean when READING the weather via the NWI, then obviously FSUIPC has to round the temperatures and altitudes to the nearest whole degree and metre, respectively. Regards Pete

Are you loading the EXACT same 737? The aircraft-specific option uses the full aircraft title to idendify the specific aircraft. Check the FSUIPC.INI file. You can edit this file and shorten the name to apply to any aircraft beginning with the shortened name -- you'd need to set the "ShortAircraftNameOk" parameter (search for it) to Yes as well. If you still can't figure it out, show me the assorted [buttons ...] sections in your FSUIPC.INI file. Regards, Pete

Yes, but not "strongest signal", but "greatest deflection". You can have up to 4 flight controls for each of the main axes -- the method is described in the Advanced Users document. Regards, Pete

Not really. (What is a "MIP"?) This is a question for PM support. Have you tried the PM newsgroup/webboard. Regards, Pete

It's all to do with Microaoft-wide rules on having multiple user settings -- each user will have his own FS configurations. Even the saved flights go to "My documents". I recommend Ken Salter's "FS9 Configurator" which will find everything for you. Check Avsim or FlightSim.com. No, but FSUIPC detects EPIC buttons directly in any case, so you can use FSUIPC button programming to do whatever you want, probably much more flexibly. Regards Pete

Can you try again, Zip up the FSUIPC.LOG and FSUIPC.KEY files from the FS Modules folder and send to me at petedowson@btconnect.com, please? No. I have two of them -- an FX53 and an 4000+, both running both FSUIPC and WideFS fine. I really have no idea what could be wrong on your FX55 (the Client won't be relevant at all). There are some mathematical calculations done to check the key, but nothing really complex. I would have thought that if your processor was faulty (say in the maths section) FS and many other programs would have problems. As a first step let me look at the files and try them here. I'll need to know the operating system too, please (XP SP2?). Regards, Pete

Why edit the CFG file directly? Just assign the buttons in the FS dialogues -- Options-Controls-Assignments. You can of course try doing it in the FS9.CFG file, but it is harder work. The FS9.CFG file is in your Documents & Settings folder, under your user name, Applications Data-Microsoft-FS9. Pete

Good. Not that I understand why it is that complicated to transfer a double as a double. I'm spoiled by C's transparency I suppose. Regards, Pete

Ah, C++/C#-speak! ;-) Sorry, terms like "overload" (even "ref".which I assumed meant "the address of" or "a pointer to") are lost on me. I'm strictly C and ASM. But if you mean there's no way of passing a pointer to a double (which seems odd), then I suppose you could pass a pointer to any 8-byte entity, like a "long long" ("_int64") or a DWORD array[2], etc etc, then cast it into a double. Can you cast in C#? You shouldn't really need "conversion" as such, as the value is actually in floating point format -- conversion sounds like (and usually means) actual alteration to the bit pattern, which would be wrong. I suspect you need to talk to someone who knows C# before this gets too confusing! Regards, Pete

No, no. That is far from true. I only know about the areas I've had to investigate in order to make my programs. I know nothing, for instance, about the graphics, the sound, aircraft design, panel design and scenery. I am not only new, I have tried looking and given up in disgust. They are completely alien to all I know and do in programming. I come from a hardware engineering programming background. Even C is really rather too high level, but at least I have a jolly good idea what it means at the hardware level. I prefer Assembly code. XML is the complete opposite. It is so far away from what I know as "programming" that I hated it the moment I saw it. I even got an idiot's guide to it and gave that up too! So, I am very sorry but I really haven't a cluse about your XML problem. Maybe some other reader will be able to help, but really you want an aircraft & panel designer's forum. Isn't there one somewhere? I don't know of one, but then the only ones I know of are Florian Praxmarer's programs like SA_WXR. These aren't free, but are reasonably cheap. Regards, Pete

Not only can it not work, but it could easily crash the program, since the FSUIPC read will read 8 bytes (you've told it to) but will store them in a 4 byte area. The excess 4 bytes will trample on something else. I don't know C# at all, but why not simply read an 8-byte double floating point value into an 8-byte double floating point variable. Isn't that logical? I cannot see why that would not be obvious? Regards, Pete

HmmmI've no idea what could have changed to affect that. Doesn't the cpFlight MCP connect direct to the PM MCP program? Or are you connecting the cpFlight MCP to a different PC from that running PM MCP? No, not at all. But every single time I make a new release of anything there are initially always lots of reports of all sorts of things being different to the way they were before, even things I haven't changed and even things I couldn't be responsible for -- for example someone actually said the latest FSUIPC changed the volume of sound in his headphones so he couldn't hear them any more! ;-) If you have any information which may relate to any problems specifically with FSUIPC or WideFS I'd be glad to investigate, but I really cannot even start with no information whatsoever, even how cpFlight has any connection to my programs. Sorry. Perhaps you can explain in more detail? Regards, Pete

No idea, sorry. Do you happen to have any information which may be slightly useful at all? Like: 1) Updated from what version of FSUIPC to what other version? 2) What is the "THR modification for Airbus by J. Oliviera"? Really I cannot guess these things, you do need to explain what it is you are talking about please. And anyway maybe you would be better off talking to J. Oliveira, as it is his modification? Pete

Any FSUIPC log showing the sequence? You should always use logging -- that is what it is for. If you check the Logging page in options you will see IPC read and write logging options. Try to do this with no other FSUIPC users also running so that the log only contains your efforts -- it makes things easier to interpret. Also test things with default aircraft. Some complex panels may be interfering with what you are trying to do. There's no difference between what FSUIPC does when called directly from inside FS to what it would do with an external call, though mostly internal users might as well use the normal interface FS provides, as documented in the Panels SDK. Regards, Pete