Pete Dowson

You mean 3.48? When you go to the FSUIPC buttons page, press the button, and select "Select for Key Press", the check mark should be against the "Key press not to be held" option, not the "Key press to repeat ...". Right? In the same page, press a button, and select for FS control. The check mark will/should NOT be against the "control to repeat while held" option. It will only be checked if the button was already programmed with some repeating action. Please check -- maybe you are re-programming buttons without pressing "Clear" first, so the previous options are retained? That's intended to be "user-friendly" ;-) I am very concerned here that you are observing totally different things to me, and things which are wrong. If you could please carry out these little checks and tell me what you finf. Thank you. Regards Pete

Yes, that would be a good idea for weather sources such as ActiveSky which I think does set sensible GLOB weather too. But it won't be so useful for FS default or FS downloads because the GLOB weather that provides doesn't seem to match much at all. You could read and set the the nearest WX station(s) and also copy either the nearest station or the *aircraft* weather to GLOB on the other PC. That would cover your options better, I think. Regards, Pete

That would be the most accurate and most successful way, I think. Yes. The "several" stations would need to be those surrounding your aircraft's position. You'd need a database for that -- you can use the lists provided by FS (see the Weather folder, with updates in your flight sim documents folder). Well, yes, but the GLOB weather you read will not necessarily relate to any of the weather around your aircraft (as it is only the default for unset stations), and it won't necessarily set the weather at your aircraft in the target PC because that might be dictated by locally set weather too. If you want to experiment with just one weather station before working out how to determine which ones to deal with, try just parking your aircraft at a known station/airport, and reading/writing that station. This may still give slightly different results in the other PC if it has other nearby stations with different weather, but if you are as close to the WX station coordinates as possible, there should be notceable similarities. :? Note that WX stations are not always exactly in the airport perimeter. The ICAO ids, Lat/Long/Alt are available. Look at the files in FS's weather folder. WXstationlist.BIN is just a complete list of 4-letter ICAO codes for weather stations. They are packed tight, 4 bytes to each. This file is the default -- if you ever use the FS Jeppesen weather downloads then an updated list will appear in the same folder as your FS9.CFG file. WXmapping.bin just gives all the station names as far as I can see. ICAO Pos.bin is the most useful. For every WX ICAO id it provides the Latitude, Longitude and Altitude. It is a binary file with 16 bytes per entry, thus: char chICAO[4] float fLatitude; float fLongitude; float fAltitude; This is in C. "float" is a 32-bit floating point number. Regards, Pete

Yes, but why is that instantaneous change occurring? Where are the different temperatures coming from? If not ActiveSky, where? No, it's unlikely to make any change as those offsets only control global weather, which, in FS2004, is just the default for any weather stations which don't already have their own weather. Regards, Pete

I'm not sure what you mean there. Well you might be able to accomplish something that way. I'm not too sure how the results would appear though. First you must make sure all weather is completely clear in the target FS -- use Clear Weather for that, and set the dynamics to 0. If the weather hasn't been cleared, when you set "GLOBal" weather it will only affect those weather stations which don't already have their own weather. It simply acts as the "default" weather for such stations. Unfortunately it still isn't that easy. After a while the stations which start with your global weather will have developed locally, and future global weather changes won't affect them -- they now have localised weather. So, if you want to keep them all set with global weather all the time, you have to clear all the weather before setting it. every time. This looks horrible and is very jerky/stuttery as well. The only proper way is to read weather at weather stations and set it to those weather stations in the target PC. You could read the aircraft's weather, as you are doing, and use that to set the surrounding weather stations. That might work too, but it isn't exactly the same -- interpolation produces the weather at the aircraft, and applying interpolated results to the weather stations may not then produce the same re-interpolated results back at the aircraft. Regards, Pete

Okay, I seemost unusual though. ;-) Yes, that's it. Have you re-checked it? Did you ask PM Support if not? I don't see anything which is aircraft-type specific for those particular bits. But the equivalent to Ctrl+Tab is probably one of the offset 04F4 controls (FSUIPC control 2999 "PM GC Controls"). There are incr engine page (20) and decr engine page (21). Maybe you can try those? Regards Pete

Hmmm. Not sure how/why there would be fluctuations then, I thought ActiveSky took steps to ensure harmony between neighbouring weather stations, and did itself smoothing for weather changes on-the-fly. Is this not now the case? Or is this a new bug in FS itself which you've identified? Well, as I said, I've no way of directly affecting either temperature or pressure without quite nasty repercussions thoughout the whole modelling. I did try, believe me, but everything in that area of FS's atmospheric simulation seems to be linked to everything else. Assuming the fluctuations are not being caused by some sort of calculation bug in FS, like the 180 degree wind shifts are, then the only way I know is by ensuring that the input figures, those set for all the surrounding weather stations, are not too disparate and don't change too quickly. That's really in the hands of the weather program. Of course, in Concorde cruise, you are pretty high. Have you checked (eg in WeatherSet2) to see if the program is actually providing temperature data for a layer at that altitude? Regards, Pete

Is that with FS2000 or FS2002? There really isn't any pressure smoothing in FSUIPC for FS2004. I can't get at the ambient pressure to fiddle it without other unwanted ramifications. It's the same problem as with pressure -- if I attempt to fiddle the temperature at the aircraft all sorts of other things go haywire. I've only managed to successfully control the immediate wind effects (not really the wind itself) and the visibility (a graphics effect). If you use one of the better weather control programs such as FSMeteo or ActiveSky, I think you'll find they do a pretty good job of smoothing these things. This is by controlling the inputs rather than, as in FSUIPC's case, trying to manipulate effects. FSUIPC itself doesn't originate the values in any case. Regards, Pete

Please turn caps lock off -- it comes across as shouting! The latest version of AISmooth needs the latest version of FSUIPC simply because it uses the addional information provided. That's all. There have been no other changes which can affect it. No you don't. There are no changes in FSUIPC that will stop AISmooth 0.92 working with the current version any better or worse than it did with the previous version. Programs are rarely dependent upon specific FSUIPC versions. Just use FSUIPC 3.48. If you have a problem with AISmooth 1.00 you should certainly report it to the author. Just going back to a Beta version does not help anyone. Regards, Pete

CloseReady refers to programs started by RunReady, whilst Close refers to those started by Run. You can have up to 9 of each, so it needs to know which ones you are on about. See? Surely the documentation isn't that obscure? There's no difference in the way they are closed, only in the way they are run in the first place. There are also up to 9 "RunKey" programs, so of the 27 possible programs running, WideClient has to differentiate! Oh dear. If you want to close them via KeySend, please read the section Running and stopping programs via KeySend requests. Well, yes but I am still very insistent that the PM controls for this, published by PM and always working as far as I know until you discovered they are not, should be made to work. PLEASE REPORT THIS to PM Support, rather than simply finding poorer alternatives. If you don't report errors they never get fixed. It is really VERY important! But this is a surprise tooYou are actually starting the programs with keypresses as well? Why so complicated? Isn't the normal starting when FS is ready (RunReady) good enough? And if you have managed to understand that, really more complex, part, how is it you don't understand the simple association of "CloseXXXN" with their "RunXXXN" counterparts? (XXX being Ready or Key or nothing). There are just 27 programs started and closed. 9 of then by "Run1-Run9" and "Close1-Close9", 9 by "RunRead1-RunReady9" and "CloseReady1-CloseReady9" and 9 by "RunKey1-RunKey9" and "CloseKey1-CloseKey9". Just be consistent in how you refer to them in the KeySend lines as well. Would you understand it more if they were numbered 1-27 instead, with different actions according to numbers? I thought using English words in the parameter names might help. Sometimes I truly regret adding so many facilities. Too much choice and folks don't know what to do. :-( Regards, Pete

No, sorry. Maybe you have found a problem in the new AISmooth. You should contact the author. I really know nothing about it. The only reason it needs the very latest FSUIPC is for the bank and pitch values it can now read for the aircraft, so it can make the AI turns more realistic-looking. FSUIPC is not actively involved in what it does, it is only acting as the channel to FS for it to work. I've been running it here with no problems, but I don't really know what you mean about distance or ETA values -- I just let it do its thing in the background. Are there values to read? Regards, Pete

It used to default to "Repeat", but that was an error. It should be fixed in 3.48, or even before. Are you saying that with the latest version by default you still get repeating action? That's rather worrying! No, I think the method they use to get the keys won't work with the same options as TeamSpeak. In fact the reason for the original work I did (hacking actually) to derive the RWon/off method was because of problems with key inputs. Regards Pete

You certainly don't want "R" (repeating whilst held). That may well mess things up here. Change that to "P". It should then work -- it should send both KeySend codes. (What version of FSUIPC is it please?) Just as a test, as well as using Press (P) instead of Repeat ®, try the other order: 1=P0,0,C1006,3 2=U0,0,C1006,4 3=P0,0,C1006,1 4=U0,0,C1006,2 just to see if it works then for TeamSpeak but not for RW/AVC/SB3. Regards, Pete

How can a PDA detect COM ports on a PC? Surely you need to run a program in the PC to detect COM ports in a PC? It is the PDA's duty to detect its own COM ports, if that's what it has -- I see no way possible for a PDA to find anything inside a PC. I'm obviously not understanding much of what you say. If it is any consolation, I have an Ipaq connected via USB which "syncs" okay, but I see no way to address its serial port, if it has one. I think you have to stop the ActiveSync program altogether -- when installed it runs at start up and presumably takes over the appropriate port exclusively. No doubt someone here will know more about this stuff than I. Regards, Pete

I hope someone here can help as I've no idea what any of those things are I'm afraid. Do you have a support email address for any of those things -- asking the author directly might be of more help to you? Do you know if any of what you list actually uses FSUIPC for anything? Maybe you missed re-installing some essential part after re-installing FS? Regards, Pete

Why not just make your PTT button send both KeySends -- the wrong ones shouldn't harm the other program, surely? You'd need to edit your FSUIPC INI file's [buttons] section for this. Any button can have any number of actions, all of which are carried out. It's just that this cannot be done in the FSUIPC option dialogue. Check the Advanced User's guide for more details. Regards, Pete

From a program all you need to do is send the appropriate FS control via FSUIPC offset 3110. Don't use keystrokes. If you really want to send keystrokes to FS use FSUIPC offset 3200, but it is rarely needed -- controls are more reliable and more efficient. Simulating proper keystrokes in Windows needs more details than merely sending WM_KEYDOWN messages. You have to include other information in the messages and you have to have a following KEYUP or risk stuck keys. It really isn't worth the hassle and it is not needed. Try the facilities provided. If you really must use keystrokes, then program them fully and use the "ButtonKeys" facility to operate one of the free virtual buttons in FSUIPC, then program that button, in the FSUIPC buttons option, to action your control. This is designed for those using Hagstrom keyboard encoders, not someone writing an interface program, so it is a rather roundabout method in any case. Regards, Pete

Actually, all those are now allocated. Sorry, I'll be updating the Programmer's document to show this. The areas available for allocation are now x6D20 (3424 bytes) and x8300 (11520 bytes -- but I would want to keep most of those for use with new facilities in future FS versions). If you only need to use bytes for your own private purpose, not for something which will be released to others, there won't be any problems using the free area at 66C0 (64 bytes). You only need specific allocations where clashes with other released programs might otherwise occur. Regards, Pete

Yes, I believe those have synoptics. I'm a 737 flyer myself. Well I'm not surprised. WideClient knows neither of those keywords. Please check the WideFS documentation where it is all expalined with examples. You have to direct the keypress to the correct program. You can do that using class names, but it is far easier and more reliable to get WideClient to load your program so it knows the process and can be precise. Please review the documentation on this. It is all there. I still think you be far better off using the proper controls for this. If the bits documented by Enrico aren't working for you, report this to support@projectmagenta.com so it will be looked at. Or at least ask advice from others via the PM newsgroup/forum. That is by far the more appropiate place. I cannot support PM myself. There's nothing called "SendKey", and anyway, why use any keyboard method when WideFS provides ShutDown facilities built in? Please please look at the documentation for this. Just have Wideclient load your programs and allow the shut downs. I really cannot reproduce the documentation here. Your questions really do indicate you've not looked very far. I can answer specific questions, but not those much better covered in writing already. Sorry. Regards, Pete

I expect there are none in the code. Many gauge programmers seem to think that having mousable hotspots on screen is all that is needed. The provision of keyboard or control support isn't automatic, it has to be included in the programming. I don't understand why they would do their own thing. It isn't as if FS is too short of light switch controls. These are supported in FS: 0 Navigation 1 Beacon 2 Landing 3 Taxi 4 Strobes 5 Instruments 6 Recognition 7 Wing 8 Logo 9 Cabin With only some extension (eg for separate inboard and outboard landing lights, and adding taxi turnoff and wheel well lights) the FS allocations should have been usable. I don't know why they decided to bypass them. Regards, Pete

This is my original post @ Flight1 and I was told that you might be able to help Mr Dowson Sorry. I've not idea why they would send you to me. If there are no keystrokes and no added FS controls to control the lights in that cockpit, then I have no solution. I am not going to hack into their software to find their switches -- it is up to them to publish methods for folks to use their software. I very much doubt that Flight1 intended for me to hack their software! I assume you can switch the lights by mouse click? If so then you can use Luciano Napolitano's Key2mouse program -- but of course it means having the light switches on screen to be clicked. Regards, Pete

Check the "Throttle Sync" hot key, on the FSUIPC hot keys page. It is documented in the User guide in the Hot Keys section under the bold sub-title "Throttle Sync". Pete

I don't think that's possible, they are all table driven and use the same piece of simple code. There's a whole bunch which affect PM offset 5424, documented as follows (source PM FSUIPC offsets in the Project Magenta documentation web page): 5424 Glass Cockpit Selectors (Read/Write) Bit 0 Show Controls on engine page 1 Show Standby Gauge on engine page 2 Engine Page Decrement 3 Engine Page Increment 4 Synoptic Page Decrement 5 Synoptic Page Increment 6 PLAN mode selected waypoint Decrement 7 PLAN mode selected waypoint Increment ... Those FSUIPC controls simple set bits 4 and 5 in this word, exactly as (still) documented in PM specs. If they are not working for you, then either there are no alternative synoptics (yet) provided for your aircraft type (e.g. the 737, which has none in reality in any case but I think Enrico is working on some fictional ones), OR the build of the PM PFD.EXE/DLL you are using has a bug. Either way, your proper course of action is to ask PM support or go via the PM Newsgroups. For any of the built-in PM functions in FSUIPC, you can easily check yourself whether FSUIPC is up to scratch by using the Monitor facilities (on the Logging options tab, right-hand side) to see the changes in the documented offset -- the PM offsets documentation is freely available to all on the PM site. If you use PM's CDU you can also check offsets there. It isn't a good method using key presses -- best to get the direct control working. However, if you want to try it the tab code is 9. Thanks for pointing out its omission in the WideFS documentation -- I'll add it. It is deliberately missing in the FSUIPC Advanced guide as in FSUIPC it is used as a shift and cannot be specified as the main key. Regards, Pete

There's no such thing as a "config editor site" for FSUIPC! To find FSUIPC options, run FS, press ALT M F. This displays the FSUIPC options. Choose the Technical page in the options. Please go and find, inside the FSUIPC.ZIP package, the user documentation -- it is available as a Word DOC file or an Acrobat PDF, so there really is no excuse not to read it. In there there is an explanation of every single option, and even pictures of the different pages. You should not be editing the INI file direct except for some advanced facilities not available in the programmed on-screen displays. And for those there is the Advanced User's document also provided. I spend a lot of time making the documentation, it is sad not many people even look at it. :cry: There's no way of changing how a gauge is programmed by editing a CFG file. Regards, Pete

Well, SimMarket could have helped you with this too, but now that your here: Zip up your FSUIPC.KEY file (it is in the FS Modules folder) and send it to me with a copy of the notification email you got for WideFS recently. Send to petedowson@btconnect.com. I can make you a new FSUIPC key to match the WideFS one. Then you will have to delete the FSUIPC.KEY file and re-register both. Regards, Pete