Pete Dowson

Well, it'll work with yours too . You don't actually have to buy your own full copy of FSUIPC if you don't want all the facilities. But it will be cheap in any case, probably with a special offer for a time. I think you should find it worth it. The price will be firmed and published in a couple of weeks. I'm nearly there, but I'm out for a few days next week. I hope to be able to publish everything within the first two weeks of July. Regards, Pete

This is only with the PIC767? If so then I think the most likely cause is the PIC 767 software clobbering the message queue -- it has a nasty habit of getting into some weird state where is is sending many Windows messages continuously, every second. This fills up message queues and causes other problems. I don't know *why* it does this, and it doesn't do it all the time. It's very inefficient in this way. All FSUIPC is doing with your pre-programmed buttons is sending the related keypress, as a message (or a sequence of messages -- keydowns and keyups, as needed). It does this as soon as it sees the button press. Alternatively, or, indeed, as well, given this statement: It is possible that the system is rather overloaded and the detection of the buttons being pressed is lagging, or even being missed. The button actually has to be held down during one of the scans for the change up-down or down-up to be noticed. The joystick drivers don't actually queue these things. I can only think of a couple of things you could try: 1. Limit the FS frame rate at something below your normally observed rate, so that FS itself spares more time for other things. For instance, on a 2GHz PC I would suggest something like 25fps or 20fps. Lower on lesser PCs, not much higher on faster ones. Experiment with that. It's in the FS Options-Settings-Display-Hardware dialogue. 2. Try making FSUIPC poll the buttons more frequently. This is done by a parameter "PollInterval" in the [buttons] section of FSUIPC.INI. the default is 55 mSecs which gives about 18 tests per second. Read the section "Button Programming" in the Advanced Users Guide. I'm not saying either of these will "fix" the problem, but they're the only things I can think of which stand a chance, short of getting the 767PIC software problems fixed. Regards, Pete

If this is addressed to me, please state your problem here. I do not have time to go chasing threads is other fora. Thank you. Pete Dowson

You need to refer to the Programmer's Guide. In the table in that document it explains this as "Autopilot altitude value, as metres*65536". In other words, that 32-bit integer holds the altitude in metres times 65536. Since 65536 is, in hexadecimal, 0x10000, this is effectively saying that the top 16 bits is the whole number of metres and the bottom 16 bits is the fractional part in 1/65536ths of a metre. If you want feet you simply convert metres to feet by multiplying by 3.28084. Please try the supplied utility FSINterrogate. You can read the values in that AND see the conversion in operation. Pete

Hold it there. 1. If your aircraft accesses FSUIPC, then, yes, you need FSUIPC installed. Not many add-on aircraft access FSUIPC, but it is feasible. 2. If you access FSUIPC then, effective from FSUIPC version 3, you need an access key (unless the user has bought a full license for his FSUIPC). This is true for any version of Flight Sim, not specifically FS2004. You will see in my announcement that I invite all developers to apply for full details of the registration scheme so they can be prepared. 3. If your plane is freeware -- i.e. you are not making money from it -- then the Acess key you need is provided free. No one pays anyone anything. Surely this is clear for everything I've said? Why are you not reading any of it? It makes no sense to me either, especially as, right from the very start, I've made it clear that this wouldn't be the case. Please go back and read what I actually said. Maybe so. And I'll will go get a different job. But whilst I am full time on this I need some income. Okay? :-( Pete

Oh, didn't I answer that one? Sorry. Taking the last point first, no one ever has to pay for FSUIPC more than once. If he buys the full license for FSUIPC then not only does he have access to all of its facilities, but it will work with all add-ons, whether accredited or not. He doesn't need to pay anything at all if he has no need for the extra facilities and all his add-ons are "accredited". As for vendors "passing on additional costs", I don't think this is a defensible position. To start with there are no software products I know whose price is based on costs. It is impossible to work out such pricing. Software prices are based on estimates of market worth -- i.e. "how much are folks likely to pay?", "what is the optimum price for this to give maximum returns?". Often a lower price will secure better returns, but it's all a guessing game in the end, with experience and knowledge of the market place as guidance. Adding in the relatively miniscule amounts vendors or developers will be paying me will make not the blindest bit of difference to this, I assure you. Regards, Pete

Is there no "Modules" entry in the FS menu? I mean here the main menu at the top of the screen when you are actually in FS flight modes, not when you are waiting at the flight selection dialogue. If there is no "modules" menu, then you have put FSUIPC.DLL into the wrong place. There's no need to "access" it if all you installed it for was to run add-ons. But if you want to look at its options dialogues then you select FSUIPC in the Modules menu, as documented in the User Guide. Regards, Pete

I have to allow vendors to package FSUIPC, as there will be many folks who (a) don't know what it is and don't care, and (b) have no access to the Internet or don't want to bother anyway. I keep asking vendors to make sure their installation programs do NOT overwrite a later version if one is found already installed. Most do incorporate this check, and I write to those who don't and complain. But this is the most I can really do. Note that there is no conflict regarding the *access* rights to fSUIPC these differing installs might have. Their access is through a key, which is operated at the time of the access. There is nothing different about the module itself. And if the user has purchased FSUIPC for the additional facilities, these are parts of his installation. He will want to preserve the Key file, or at least the information he entered when registering, but this should not be affected by vendor installs. Hope this makes it clear. Regards, Pete

But you don't need to shell out for FSUIPC. It supports freeware for free and payware is supported by arrangement with the folks who make or sell it. Haven't you read what I've written? Pete

Hmm. That is very strange looking isn't it? I've never seen that before. Well, my problem there is that I know nothing about graphics and would have no idea how to get into the drawing parts of FS or your video drivers to do anything with it. Also I really can't see how it could be a function of FSUIPC to get into such things even if I did know how to do it. This does certainly look like something to do with the video card/drivers, or maybe DirectX, but how it could be fixed I wouldn't know. Terribly sorry. Maybe there's some advice on the help or support forum for your video card? Maybe their drivers are yet quite DX9 or 9a compatible? What is DX 9a anyway? Is it worth upgrading to? I'm always very reluctant to update DirectX as new versions are often troublesome, and it is very hard to go back. Regards, Pete

It isn't FSUIPC which "works only in slew mode". All FSUIPC can do is forward your requests onto FS. How does DirectPlay come into it? Do you mean Multiplayer? This is all an unknown area to me. With AI aircraft you can open windows to view them as they fly. Possibly the same can be done with multiplayer aircraft, I don't know. That I have no idea about I'm afraid. ActiveCamera does some fancy tricks with views in FS, so maybe that can be adapted. You'd need to write to the author. Regards, Pete

Pitch and bank are controlled by elevator and aileron. You can just take over those controls. You can even ask FSUIPC to disconnect the user's controls so that they don't interfere. The control inputs are at offsets 0BB2 AND 0BB6. The facilities to disconnect the real controls are at 310A,. Please refer to the Programmers Guide in the SDK. Pete

You need the FSUIPC SDK. Go get it from http://www.schiratti.com/dowson. Pete

Thanks for your support, but I should point out that catering for all possibilities regarding payments will not really be feasible. If the amount donated is more than a certain amount (which will be significantly less than even the initial "special offer, bargain, get it whilst it's cheap" price) then the registration will be by application to me, and I'll supply a free key, but if it is less than the normal route (probably SimMarket) to obtain a key has to be used and that will be at a fixed (but as I say, bargain) price. Pete

For GSPout to work in FS2002 you also need FSUIPC installed. FSUIPC corrects some aspects of FS2002 which GPSout needs. However, since WideFS also needs FSUIPC I assume you have it installed already. If so, then GPSout will already be sending messages on your COM port, whichever you told it to in GPSout.ini. It could well be your map programs which need configuring to suit the GPS options and COM baud rate (line speed) you've set in GPSout.ini. Most real GPS's are set to use 4800 bps by default (this is the NMEA-stipulated default), so start there, and try the various sentences. Check the documentation for the map programs, see how to configure the GPS input correctly. Regards, Pete

Yes :-) Yes, WideFS is used to link FS to FS applications across a Network. That is what it does. Whatever FS applications you have, if they interface to FSUIPC on the FS PC, they will also work across the Network under WideFS. No confusion so far ... No, there you go completely wrong. GPSout is absolutely nothing to do with WideFS. There;s no sense of "Server" and "Client" here. GPSout is simply a little module which sends out NMEA 0183-compatible messages through your chosen COM port (NOT a Network), which can be read through a COM port input on any other computer (even palmtop or MAC or anything). The PC+FS+GPSout combination emulates a real genuine GPS, sending out the same messages on the COM port as a real GPS does. There are many map and atlas programs which will accept input from a GPS, on a COM port, and plot the moving vehicle you are in. Your PC+FS+GPSout system isn't really moving, but the messages say it is, so that's what the mapping programs accept. You are only way off base by mentioning WideFS, which is nothing to do with it. WideFS extends the FSUIPC interface for programs written especially for FS and interfacing to it via FSUIPC. There are mapping programs which do this, NAV3 by Ted Wright, for instance. But Delorme do not write any Flight Sim programs, and Microsoft have not so far written any mapping programs for FS either. The program you mention probably have interfaces in them to allow outputs form GPS devices to connect in them, so they can be used for navigation in a moving vehicle -- car or aircraft, etc. My GPSout module just takes advantage of that and uses the same connection. (I say "probably" because I do not know those programs. I know Autoroute and Jeppesen Flitemap have GPS input facilities, but I don't know all programs). You need to understand how the program you are using for the map wants its input connection, then configure GPSout to suit, just as you would configure your GPS. Pete

I have checked into the PayPal system (http://www.paypal.com) and it seems they offer several ways to pay as well as credit cards. Regards, Pete

You are mixing up two completely different and separate things. WideFS operates FS applications across a Network -- i.e applications written SPECIFICALLY to interface to FS. GPSout is simply making the whole FS PC simulate a GPS unit with serial (COM port) output, so that any old programs which can accept genuine GPS output, from a real GPS, can be fooled into accepting similar output from FS. There is no relationship whatsoever between the simple serial port link used by GPSout (and real GPS's), and a Network. You can use any available COM port on one PC and any available COM port on the other, provided that neither are being used for anything else. Neither end has any idea what the other end is plugged into. Windows "direct connection" will use the COM ports for a Network connection. GPSout cannot use a Network connection. It is simulating a humble GPS, with a simple serial output. It just shovels data out at the Baud rate (speed) you set in its INI file. At the other end you have a COM port receiving data and the map program or wharever configured to read the correct data at the same speed. TCP/IP is a Network protocol and is nothing to do with the serial link used by GPSout. If this is all you installed WideFS for, remove it and discard it. It is totally irrelevant. and only serving to confuse you. I really don't know how you could have gathered from any of my documentation that there was any relationship at all between these two totally different applications. :-( Regards, Pete

I think this is documented, but in case not, here goes: WideClient maintains a memory map of all of the locations ever requested since it started running. When the values are requested by the client applications, it gets data from there and gives it to the client in a direct response. If there are data items which have not been requested before, it also sends appropriate requests to WideServer, whilst supplying the default value in its memory to the applications (this would be zero). There is an option in the INI ("WaitForNewData") which actually stops this return until WideServer has sent the newly requested data -- this is actually enabled by default with a 500 mSec timeout. See the DOC. Except for Write requests from clients, the Network traffic is totally controlled by WideServer, which maintains details of all data items requested by each client, separately, and monitors these for changes. This latter is done at FS frame rates. Only changes are sent out. If a connection dies or closed, the list for that client is cleared (by both ends) and the process starts over. No. It doesn't really matter, but if you are operating something graphical to run at FS speeds then you probably should try to match average frame rates, for smoothness of your displays. WideServer works better if you limit FS's frame rates to a bit less than its average performance in any case (as documented), so you would, say, set the FS limiter to 35 or 30 or 25 fps (according to processor) and poll WideClient at that sort of frequency. Of course, if your program does a lot of processing or heavy graphics, or is sharing the client PC with other such applications, you might not be able to or want to achieve such a frequency. Really, since WideClient is supplying these from memory, directly, there's no benefit from splitting them like this. WideServer will be sending all the changes anyway. You'll just be skipping some. 100mSecs is only 10 fps, which would be too slow for smooth graphics. Project Magenta achieves FS frame rates quite easily, even with up to half a dozen client PCs running it. See the Jet Cockpit at PFC (http://www.flypfc.com). You don't have any control over the Network operations, excepting how you write things. Certainly you should optimise writes. Don't keep writing the same values to the same places, only write what you need to write, and don't write that frequently that things bog down. But when you are reading you are not affecting anything on the Network. Provided you don't actually ask for any data you don't need (for once you have it will be monitored for changes and all changes sent), then it doesn't matter. Of course, if your program is also supposed to run well on the FS PC you have to consider the affect you may have on FS's performance. But there's a lot of other factors there apart from calling the IPC interface. Regards, Pete

You really do need to go back and read my announcement and most of the other times I have to repeat the same thing. FSUIPC will still be available to all and will work with all accredited add-ons. The end user doesn't have to pay for FSUIPC in order to make add-ons work, provided those add-ons have an access key. In many cases the add-on will install FSUIPC and it will just work, no different form what happens now. You just won't have so many options to deal with in FSUIPC so installed, that's all. How many more times do I have to say the same thing? :-( Regards, Pete

Okay, so should I remove the user facilities from both so that they become just FS interfaces for applications and nothing more? Most of the facilities have been added through USER demand or request, certainly not from developer requets. Developers want control over things in FS, or information from FS. That is not really wahat users ask for, that is invisible to them. Nowadays, in FSUIPC, much more code is devoted to user facilities than to the interface, and judging by requests outstanding this is set to grow further. No, he needs none at all. You evidently have not read much of what I've written, or not understood it. If this is my fault for poor explanation I apologise. But please look back. Each accredited add-on application is either freeware or is payware and has an agreement with me of some sort. That's its license. The user (pilot) only has to pay if he want the facilities I offer to users, he only has to purchase accedited add-ons if he want accredited add-ons to work. There is no way FSUIPC controls any functionality in application programs. It either offers an interface to them into FS or it doesn't. You seem to be completely misunderstanding the function of FSUIPC. Regards, Pete

I'm always talking to Microsoft. One of my wish lists for them a year ago was that they took this stuff over so I could get some rest! Don't forget they are a very small team in a gigantic company. They really have no influence on policies, but they can sure turn out some good productwait till you see FS2004! Pete

Need the actual CDs first, unfortunately. Then my wife, who's birthday it is very soon, is dragging me off the Cornwall for a few days, to visit the "Eden Project" down there. It'll be a break, for which I'm thankful, but it looks like coming slap bang just as the CDs might arrive! Ah well ... Best regards, Pete

I'm not sure if there is any way that the agencies which I will have to appoint to deal with this can accept other mehods. Did you check whether PayPal has methods other than credit cards? Certainly I could accept cash (in note form) to the equivalent value, as I can probably get it exchanged at normal bureaux de change. For such small amounts I think this is probably the best way, even if a little risky. Non-sterling cheques for small amounts just are not worth it, they cost far too much to process and will be wasted completely. I think the same might go for international money orders. In Europe it is a great pity that the "Eurocheque" system died, as it was by far the easiest for postal purchases. Maybe Britain will one day enter the Euro domain and it will be easier again. I'm ready to take advice here, and do what I can, but I don't think I should publish anything like that generally, at least until it is VERY clear how to do what. There's no panic yet, do not fret please. Regards, Pete