Pete Dowson

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

Can you be a little more specific? What aircraft panel is this with? Does it do the same with default aircraft? If not then doesn't it also do the same with FS's own default assignments? It's hard to tell from the little information you provide, but it sounds rather like the control acceleration which occurs on some complex aircraft panels because of the way they wastefully send controls to FS many times per second. If this is the case, then try checking the "fix control accelerations" option on FSUIPC's Technical page. Regards Pete

You don't mention it, but I assume you are using my GPSout DLL? If so, which NMEA sentences have you enabled? The RMC and RMA sentences don't carry the altitude. I think you need the GGA sentence, or the proprietary Garmin PGRMZ sentence. The non-NMEA protocol AV400 also carries it. The origin of NMEA protocols lies with marine applications, where I suppose altitude had a low priority! :wink: Maybe the documentation for PocketFMS says what it accepts? Regards, Pete

It is "supposed to work" with any Moving Map program which accepts NMEA 0183 standard messages from a normal RS232 serial comms port, running on any type of PC or device which has such a facility, using a cable which connects the correct output lines from the FS PC to the correct input lines on the target computer or device. I have no idea whether the Garmin program and your connection meets any of those criteria, but from my experience with two Garmin units (an Etrex and an iQue 3600) I don't think Garmin supports such a facility in any case except on their aviation-equipped units, and then it seems the protocol it requres is AV400 (which I added specifically because of this), not NMEA at all. Regards, Pete

It's just based on the units used in FS. In this case, I think it's the number of metres from the equator (10001750 metres is about 6215 statute miles). So dividing by that and multiplying by 90 gives you degrees. The reference used by those editing FSInterrogate's FSI files is the Programmer's Guide document. Regards, Pete

The FSUIPC interface for adding airraft to the TCAS tables is only a means of adding data to those tables, for other programs to read (for TCAS displays and the like). It doesn't create any aircraft in the simulation. That's done through the Multiplayer interface. This is how Squawkbox and the other on-line programs work -- those EXTERNAL programs do exactly what you say. So, with that understanding, except for pitch and bank, yes. Those two particular items are in the TCAS_DATA2 part of the information structure, and that part is not available for externally injected MP data. As you will notice, most of the data there was relevant to AI aircraft only in any case -- I only used spare fields there for pitch and roll for use by the AIsmooth program. No, they are not "AI aircraft". They are "Multiplayer aircraft". But given that, if you injected the aircraft through the FS multiplayer interface, yes, that's what it is for. Note that FSUIPC has absolutely nothing to do with multiplayer -- that is entirely a Microsoft documented interface. The FSUIPC interface to which you refer is merely to allow aircraft injected via the MP interface to also be seen on 3rd party TCAS displays. This should all be clear from the description of the facilities in the Programmer's guide documentation in the SDK! Regards, Pete

Good flying then! Regards, Pete

Where did you get those parameter values from? I've never heard of them and they most certainly will not be recognised! Please refer to the section in the WideFS documentation entitled "PTT (push to talk) for Roger Wilco, AVC and TeamSpeak", and use the parameters as shown. There's also a separate document inside the WideFS package called "How to setup Push To Talk". That one has pictures in it and the correct parameters. I am afraid that computer programs do not work just by making up your own values for things. They have to be fed things they are programmed to understand. Regards, Pete

If you mean you want to use FSUIPC to enable reverse thrust, then the instructions are included in the FSUIPC documentation. It does get slightly more complicated for the CH quadrant if you are using their Manager. You then have two ways of doing it, as far as I understand. I don't have any CH gear, but Bob "Sticky" Church has written about how to sort this out, either way. Check for this on http://www.stickworks.com. Regards, Pete