Pete Dowson

There's a (non-Beta) version 4.20 which was released to FS Beta testers a month ago and which will work with the Release version of FS2004 as soon as FSUIPC is ready for it. In fact all of my FS modules are ready except FSUIPC, upon which most (not all) depend, with the exception of: ESOUND which I'm not really supporting, but I will look at updating, and ADVDISPLAY which works for displaying messages sent to it via FSUIPC, in it's own window, but at present neither intercepts ATIS or other messages in FS2004, nor injects user messages into any FS display. The reason for the latter is that the FS coding of all that window stuff has changed considerably and I've not found the right routines yet. I will sort that out, but it may not be in time for the Release. When I have a good enough Beta FSUIPC for FS2004 Gold I will post a notice here and supply a complete bundle of all modules to those bona fide developers who need them. Regards, Pete

Ouch, Nasty. Sounds like a COM port or seral driver problem. Make sure the COM port is not sharing an IRQ with anything else. Try another COM port. Try deleting it in the device manager and re-installing it. If it comes to the worst you may have to try re-installing Windows. Regards, Pete

No problem, glad you got it sorted. Pete

I don't think throttles can cause nose bobbing. How could they, unless your torgue and P-factor settings are very high (see Aircraft Realism menu) and there's some jittering from the throttle. I find the FS settings a bit overdone anyway -- set both those somewhere near the centre of their range. See if the throttles are jittering (the PFC.DLL calibration screen should show you). If so you either have a poor power supply or there's something else wrong. For either you would need to contact PFC. Regards, Pete

Total fuel quantity is calculated from the values already provided. This is the way FS actually does it when you ask for that value. It isn't a good idea to ask FSUIPC to provide this as, when running WideFS, in order to keep gauges updated it would have to force the calculation on every frame, no matter whether anyone wanted it or not. It is really best for such things to be off-loaded to the individual applications when needed. The munition things aren't mapped simply because I've never seen any working guns or bombs in FS. Although FSUIPC does run in CFS1 and CFS2, in rather limited fashion, these weren't supported deliberately. When CFS3 turned up completely closed there was never any point going back. Are you using FS? Are you implementing something with Guns and Bombs? If you want access to things which do exist in FS2002 or FS2004 I can add them, but not at present please. Ask later in the year. I've still far too much to do for FS2004. Regards, Pete

I will confirm details within the next two weeks, but it looks certain to be via SimMarket, which provides numerous ways to pay -- PayPal being just one of them. It can even be by cash, cheque, or bank transfer for those who don't have Internet access, or who don't trust it. SimMarket is run by the same folks who host this Forum for me. Regards, Pete

Well, I'll have a look at it, and if it isn't too much work (I don't think it will be) I will update it. But it won't be the first priority, or even the second. Just keep a look out, please. Regards, Pete

If all you want to use it for is to run add-on applications, then it is free. PLEASE go and read the announcement again and maybe follow through some of the existing threads. I shouldn't need to repeat myself here. Please research your subject a little before posting! Pete

Yes. Pete

Yes, that is an interesting option for checking or setting the route followed, but I thought the requester was thinking of using the GPS "live" as an additional flight instrument. Regards, Pete

I looked at it. Yes, that's all it does write-wise at present, but I expect the author can add more. Basically it is doing something anyone with the Microsoft Panels SDK can do, by writing a Gauge. In fact there have been gauges which do something similar in the past. Converting a Gauge to a full Module is not hard, but you have to take precautions not to invoke the Panels interface when it isn't ready, like before a Panel is loaded or whilst an aircraft is being loaded/reloaded. It is easy to crash FS otherwise. Using the Atom name itself to pass the information back, rather than shared memory via mapped files, is a clever idea, though it does mean it is a bit limited in performance terms -- if you want a whole sheaf of data (for a full cockpit, say) it would mean many messages per frame, and hence many process swaps -- it could therefore be quite inefficient for that I think. Maybe he will develop this a little too. It will be interesting to watch it develop. All the variables it supports are panel tokens. I don't know why he's only supporting the position writing at present, you can write a *lot* more than that via the Gauges interface. This subset of the information and facilities FSUIPC offers will no doubt be useful to some. But I expect that if the author goes as far as FSUIPC does and spends the time needed to do this (many months full time) he'd probably wish he hadn't started (like I have several times ), or find it necessary to make some income from it to compensate for not having time to spend earning a living elsewhere! But perhaps not. We'll see ... Thanks for pointing the module out to me, in any case, I am always interested in these things. I'm sure one day I'll be able to withdraw, but maybe even then I shall have to hand over the code ownership too. Regards, Pete

Looks like it should work. Have you tried programming the Server side through FSUIPC "Keys" programming instead? Worth a try. Remove the SendKeys from WideServer.ini (NOT WideClient) and program the keys in the FSUIPC Keys option page instead. You'll find entries in the drop-down Controls lists allowing you to select KEYSEND for WideFS and give the KeySend number as a parameter -- both press and release can be programmed on the same page. To eliminate problems on the WideFS bit, you could try (just as a test), making a copy of Roger Wilco on the FS PC and seeing if the "Roger Wilco Transmit" On/Off controls in FSUIPC's Keys page work with it. If not, then it may be that the version of RW you are using doesn't support the control messages I know about. In that case perhaps you could Zip up the RW folder, or at least the EXE, and send it to me so I can work it out here. petedowson@btconnect.com. Regards, Pete

Hi Chris, Thanks for your explanations on my behalf. Yes, I will be doing a fuller explanation of everything, up top and in front, but I want that to include pricing, availability, and registration procedures as well. Actually a lot of the attacking messages are sort-of interesting in that they allow me to see where folks might be misunderstanding me in any case, and perhaps will help me make things even clearer when I do. Meanwhile, really, this week and maybe next too I'll have my head buried deep into FS2004 -- I've not got the Release version yet but am expecting it tomorrow (?). Only then will I know how much more work I have to do for the initial release of FSUIPC Version 3, which I do really want to release at the same time as FS2004 if I can. Thanks again & best regards, Pete

No way! I've not even got a version which will run with FS2004 Release version. I am hoping for my advanced copy of FS2004 to arrive soon, and then I will get to work on it. The changes needed in FSUIPC just from Beta 2 to Beta 3 of FS2004 took around 120 hours real hard work. I don't know if the differences between Beta 3 and the Release version will be more or less. The relationship between FSUIPC and FS is very intricate. It isn't using regular gauge/panel interfaces, they do not provide enough control nor data. I am pretty sure I wil be able to release an FS2004 compatible version of FSUIPC around the same time as FS2004 is released, but it may not be complete at that time. It should support the majority of applications, however. There will be a fairly frequent update rate for a few months whilst I find other stuff, no doubt. Regards, Pete

Yes, but I expect they might slave the antennae signals, or at least use a more convenient (to them) signal protocol than NMEA 0183. It's worth checking into I suppose, but I have strong doubts. Okay. Let me know what you find out. Well, between two PCs it has to be a "null modem" cable, though in truth all it needs is three wires -- ground (1-1) then Tx-Rx and Rx-Tx (2-3, 3-2). For a GPS it would be the appropriate cable to link that GPS, bidirectionally, to a PC -- they all tend to come with their own specific plug arrangements so no standard cable would do. Regards, Pete

Yes, but I expect they might slave the antennae signals, or at least use a more convenient (to them) signal protocol than NMEA 0183. It's worth checking into I suppose, but I have strong doubts. Okay. Let me know what you find out. Well, between two PCs it has to be a "null modem" cable, though in truth all it needs is three wires -- ground (1-1) then Tx-Rx and Rx-Tx (2-3, 3-2). For a GPS it would be the appropriate cable to link that GPS, bidirectionally, to a PC -- they all tend to come with their own specific plug arrangements so no standard cable would do. Regards, Pete

That part is right. When running FS with GPSout the output on the COM port looks, to any GPS-compatible software (or device) like the output from a real GPS. In other words, it turns FS into a "GPS simulator" as far as that external program or device is concerned. That is its purpose, so that all those GPS-compatible mapping programs can be used with FS. No, because I have never found a GPS which could receive the output from another GPS and act as if this was the signal coming from the satellites. Basically what you are asking for is your GPS to stop being a GPS, to throw its satellite receiver signals away, and instead connect to another GPS (in this case FS+GPSout) to get its positional data from. Now *maybe* there are GPS's that can do this (why they would put such a facility in I do not know), but I don't know of one. Many GPSs do have facilities to receive signals from external aerial or positional update systems, to more accurately determine their position. I think these use additional ground-based transmissions (beacons) and, together with the GPS's own satellite reception, can, in some parts of the world (probably only parts of the USA) determine positions to something like one centimeter accuracy or better. I think these are used in surveying. The protocol these use is RTCM SC-104 or similar, which deals with differential GPS beacons. Even my little Garmin Etrex can receive these, but I don't think they are of any use to me here. Well if you find that your GPS 176 can be set to ignore its receivers and accept data in standard NMEA 0183 sentences on a serial connection, then configure it so and try it out with GPSout. I'm not saying that isn't possible, it's just that I've never come across a GPS device which will do this. Maybe it will have it as "simulation mode" or something like that, intended for training/classroom use. Please let me know in case others ask. If you succeed I can tell others which GPS unit they'd need! Ah, then you can't try it after all. Shame. Perhaps you can get the handbook off the internet and see if it says it is possible? Regards, Pete

Glad you fixed it, but ... ... "FSpauser"? There wasn't a DLL by that name in your FS modules folder, or at least it wasn't running. Or is this an external application? Are you saying it overwrote part of the WideServer DLL file itself? Pete

No, all recent versions of Wideclient use a pair of Registered messages which RW responds to. It doesn't use KeyStrokes at all when you use the keywords RWon and RWoff. There are two different pairs of Registered Message names I found in the copies of RW I looked at (Mark 1 and Mark 1c). I try both sets. The allocation of the PTT key in RW is actually irrelevant. Regards, Pete

That's great! So I can stop work on FSUIPC and go do something else? At last! This saves me a *lot* of painful work! Pete

Well, you shouldn't actually need to shut down and restart FliteMap - that sounds very odd - but framing errors are normally due to incorrect (mismatching) baud rate or parity. Try the Test mode in FliteMap, see what this shows. If things are sometimes okay, sometimes not, I can only think that either your cable is rather suspect, or there's problem with one of the COM ports -- perhaps a conflicting IRQ. With my copy of FliteMap I have the baud rate set to 19200, and the device selected happens to be "Garmin GPS 95 NMEA 0183" (but I think many of the others will do). In the GPSout.ini file the sentences selected are RMC, GGA and GSA. Regards, Pete

Not till an FSUIPC for FS2004 is released, and then I'll probably release an updated PFC as well. PFC.DLL depends intricately upon FSUIPC. Regards, Pete

Sorry, no. There's no way FSUIPC can stop FS loading up panels, if that's what it should be doing. Sounds like something else is wrong in your FS configuration. By default FSUIPC just sits there, doing almost nothing at all. Pete

If you mean the keycode values used by FSUIPC and WideFS, then they are listed in the Advanced User's Guide, a document you'll find inside the FSUIPC ZIP. If you mean something for PM specifically, not using FSUIPC or WideFS, then I'm not sure. You'ld need to check with PM support. Regards, Pete

Ahthat's what I like to hear! Pete