Pete Dowson

All multiplayer 'clients' are external to FS. They provide details of aircraft, their positions and movements through a TCP/IP connection to FS (before FS2004 IPX could be used as an alternative). Sorry, I don't know what you are getting at really. As far as I know any multiplayer link can provide any number of aircraft and their movements. Of course performance may suffer. But this is how Squawkbox shows the positions and images of the other aircraft when flying on-line. Well, start with the FS Multiplayer SDK I suppose. Please don't ask me about this, though, I haven't got it and I've never used it. However, there are folks who visit here who have. I think the MP interface has changed with FS2004, and the SDK isn't available yet, so if you wanted to pursue this you'd need to work with FS2002 for now, and convert it for FS2004 when more is known. Regards, Pete

I can do it for global weather, but really I think that's a dead duck in FS2004, a waste of effort. Doing it for local weather would be a real problem, I'd have to think further about how I could do that --- it would be a big job, because I think I would effectively have to maintain a parallel weather structure, at least for the winds. I'll think about it further when there is more time to spare. For global weather there is the "maximum surface wind" facility which you can apply now. But of course this will affect the surface wind even when you are not on the ground. Maybe Marc will consider it for a future FSMeteo update. I think it would be easier for the weather control program, as it knows which WX stations are around the aircraft, which ones need such manipulating. That's my main problem at present, I just have not yet found a way to identify them from within FS. I did manage to find the "current three" in FS2000/FS2002 -- those versions used a series of triangles to determine the WX stations which influence the local weather. However, it is all different in FS2004. Anyway, I will leave it on my list for solving as and when. If I do come up with an idea I might pursue it there and then, but quite honestly every possible method I have thought of either plain wouldn't work, or would be very precarious. Pete

I think the deletion is really just a use of the function within FS to delete one of two AI aircraft which find themselves in contention on the taxi-ways. If neither of them move for so many minutes (the timeout is less in FS2004 than in FS2002) then one (or both?) is deleted. I still don't think there'll be a way of creating and manipulating AI traffic in the way that you want. I think you have to use the multiplayer input for that. But good luck. It would be nice to think you might be able to do such things. Regards, Pete

No. The joystick calibrations in FSUIPC are only for more accurate end dead zone and centre zone settings. Oh, and also extras like the ability to have a reverse zone for throttles, and do some mapping for multiple throttles. But not sensitivity. Before doing anything in the Joystick section of FSUIPC you really need to get your controls calibrated well. First in Windows (the "Game Controllers" applet in Control Panel, or possibly their own drivers if they come with any). Then adjust the sensitivity in FS. Once they are reasonably working in FS you can try using FSUIPC to define the dead zones and get better central stability, but I really wouldn't advise trying to do this until you have them working reasonably in FS in any case. Otherwise things will get too complicated, too many interactions and you won't know which adjustment to use to do what. One day I want to add new facilities to by-pass the FS assignments and provide full calibration and even response curves to FSUIPC, or possibly a separate utility. But that's a project for when I've got more time. Regards, Pete

Not sure why your Search isn't working, but: 1) Green / Red light for Nose, Left, Righ Gear (in total 6 different leds) Gear positions are at offsets 0BEC, 0BF0 and 0BF4. Try searching for the word "Gear". 2) Les Flaps Transit / Les Flaps Ext (2 leds) Leading edge flaps? Don't know anything about those. The only flap positions I know about are at 0BE0 and 0BE4. Try searching for the word "Flaps". Pete

You want to be able to delete aircraft programmatically? Really I am loathe to start ferreting into any more innards in FS2004 until I have got full compatibility with FS2002 for all application programs. Besides which, when the FS SDKs start coming out there may be more information there, or at least clues. to make things easier. But I must admit, providing a facility to delete AI aircraft seems a strange thing to me. What is the application for this? Why would you want to be able to? Because they are in your way or something? Regards, Pete

Tracking AI aircraft is the same as what FSUIPC does, isn't it? i.e providing AI data such a latitude, longitude and altitude. I know there is a way to delete AI aircraft, but I don't know how to do it. I don't know of any way to create them or change them or their routes except by compiling new data into the Traffic BGL and re-running FS. Thanks, Pete

To clarify: The value provided for Jets, with the old FS98 assumption on units (16384 = 860C), gives the same figures as FS2002, and the figures shown on external gauges, such as Project Magenta's EICAS for example, match those shown in the FS panels. So, it seemed correct. But then folks using external EGT gauges for Props told me that the values were far too high. Investigating I did, indeed, find that compared with FS2002 the Prop EGTs were much too high. Through experimentation I arrived at a very approximate conversion of y = 1450 + (x/3.6) where x would have been the value I place in 08BE (for example) but y is the value I now place (for props only). After doing this and comparing, side by side, FS2002 running a Cessna and FS2004 running the same, I get similar values for similar settings of throttle and prop and so forth. It is not accurate, but it's the best I could do for now and it works. Please understand. It is NOT FSUIPC's job to provide *correct* values if FS does not, but it is supposed to provide compatibility across FS2000-FS2002-FS2004. That is my first aim. Better or fixed values, should they arise, will have to find alternative offsets if they would make FSUIPC incompatible with existing gauges and so on. FSUIPC really is not a good vehicle for such testing. In all three versions I do a lot of manipulation to make things look like FS98. If you want real FS values you can use FSLook, which reads a subset of the Gauge SDK's Token Variables, or write a Gauge to investigate these things. FSUIPC is manipulating values to make them the same as FS98, whether they are good or bad. Except for newly discovered values of course, which can go to new offsets. Not at all. By empirical I mean I experimented and made a table of values read in FS2002 and those read for similar settings in FS2004. Then I derived the simplest formula which would take me from the latter to the former. Regards, Pete

Please write to me at petedowson@btconnect.com, as per the invitation in one of the announcements, and I'll send you the guide. It is a little out of date now -- I will be re-writing it for the SDK -- but it will do for now. Regards, Pete

WidevieW is not mine, so I assume you mean WideFS. Q. FSUIPC is non free. Is there trial keys ? A. No, there are no trial keys. But it is free in any case for its prime purpose, which is an interface to FS for applications. Please check the announcemetns at the top of the page. As for the other things, the user facilities, you can read the announcemetns to see what you get, or better still, download the FSUIPC ZIP from the Schiratti site and read the Documents therein. Q. Do I need a different key on every computers or can I use a single key ? Same question with WideFS ? A. No. the keys are tied to you, the user, not to PCs. Q. Does it work with FS2004 ? A. Yes. Please check the Announcements, and the notes on the Schiratti site. As you'll see, all my FS software is compatible with FS2000, FS2002 and FS2004. Regards, Pete

Yes. And for FS2000 as well. That's the idea. There will be new things for FS2004 eventually, and there will be some differences which I will try to document. In fact, if you do find any difference or anything not right, please let me know. I have not tested all the values for all the variables and need user feedback to complete that task. I don't even understand many of them! I'll try to do the first SDK update for FS2004 differences within the coming week or two, but at present it's been so hectic here I've not started. Regards, Pete

I think it is deliberate, not an accidental artifact The FS team in Microsoft like it. I must admit it seems okay to me, but being in the UK I wouldn't normally see so far anyway :wink: . Regards, Pete

There's an FSUIPC control to operate Roger Wilco directly! Just use the drop-down and look for it. It would be better than using any keypress. This is for use of RW on the same PC of course. For WideFS, assigning a button to press a key on the FS PC won't help at all. Instead you assign the button to operate a "Keysend". Just set a KeySend with parameter 1 when you press the button, parameter 2 when you release it. Then in the Client you simply say that KeySend1 is RWon, KeySend 2 is RWoff. All this is surely pretty clear in the documentation? It does appear in both FSUIPC and WideFS documents, with these examples. Can you tell me why you don't see it? You don't. You use the RWon and RWoff facilities. these make WideClient talk direct to RW. You don't need keystrokes. Regards, Pete

Sorry, but it isn't a "bug" as such. It was one of the many things that have moved in FS2004 and which I had not found until recently. There are many more. I could not test and find everything in the short time I had between receiving FS2004 and it going on general release. In fact there's no way I can test everything in any case -- a lot of it I don't even understand (I am a programmer not an aircraft engineer). I am dependent upon feedback from other developers, programmers and users. I doubt if I will have completely solved all the differences between FS2002 and FS2004 even by this time next year. All I can hope to do is deal with those that matter, and that's based on feedback. So thanks for your feedback, but please don't call them bugs. They are differences. If I do find real bugs I will admit to them, as always. :) Version 3.04 will be ready today. Regards, Pete

Unless you Register FSUIPC, it is not touching ANY of the joystick inputs. All the joystick calibration and smoothing facilities are part of "what you get if you Register". Also, there are facilities for removing spikes and so on which can affect some aircraft. Even if you do register, it isn't touching any axis unless you ask it to. If you had everything set up well with FS2002 and a previous version of FSUIPC then you can use the same FSUIPC.INI file and retain the claibrations and other options, but they will not operate on an unregistered copy. An unregistered FSUIPC is merely an interface to FS for applications, nothing more. Regards, Pete

Ahwe come full circle! If you just strip out the relevant parts of your log: 6343 Monitor IPC:0800 (U32) = 0x0 6343 Monitor IPC:07FC (U32) = 0x0 72734 WRITE0 0800, 4 bytes: 01 00 00 00 72750 Monitor IPC:0800 (U32) = 0x1 72859 WRITE0 07FC, 4 bytes: 01 00 00 00 72890 Monitor IPC:07FC (U32) = 0x1 76593 WRITE0 0800, 4 bytes: 00 00 00 00 76703 WRITE0 07FC, 4 bytes: 00 00 00 00 then we see, it is that interlock problem I mentioned right at the beginning. it is NOT that whatever you write is sets it to 1. It is the problem that setting GS requires LOC as well, and the IPC interface is not able to switch both together, as I said. Individually the switching certainly works. It is actually a matter of timing, take a look at this (FSUIPC 3.03 + FS2004): 450765 Monitor IPC:07FC (S32) = 0 450765 Monitor IPC:0800 (S32) = 0 452531 WRITEex 0800, 4 bytes: 01 00 00 00 452531 WRITEex 07FC, 4 bytes: 01 00 00 00 452593 Monitor IPC:07FC (S32) = 1 452593 Monitor IPC:0800 (S32) = 1 454359 WRITEex 0800, 4 bytes: 00 00 00 00 454359 WRITEex 07FC, 4 bytes: 00 00 00 00 454421 Monitor IPC:07FC (S32) = 0 454421 Monitor IPC:0800 (S32) = 0 Here each pair of reads/writes are done together, in one FSUIPC_Process. I think changing them both in one FS frame defeats the interlock well, but otherwise each interlocks the other. It is certainly a matter of timing, not a logic change. If the only way to be sure is to make sure the changes are done together, then I think that will be the only solution. I'll add a note to that effect to the programming guide. All the programs i have here do change them in one FSUIPC_Process call, so they work consistently. Hence the earlier confusion. Otherwise I may need to add some strange logic or memory of previous writes, and I'd rather not really. There might be other effects which I don't foresee. After some other testing, I find that, yes, it it EXACTLY the same in FS2002 with FSUIPC 2.975, setting 800, then 7FC, then clearing 800 and clearing 7FC. If these pairs are done quickly enough, it works, if not it doesn't. It is just the double interlock. The timing is slightly different in FSUIPC 3 compared to FSUIPC 2.9xx. Your program is just coincidentally with timings set to be between one and the other. Make the changes more slowly and it will fail in both, make them faster and it will work in both. My advice therefore is to change them both in the same FSUIPC_Process call. This ensures that they get processed in the same FS frame. I shall add a note to this effect in the SDK. Thanks, Pete

Yes, but I need you to apply to my email address, as mentioned in the Announcements. petedowson@btconnect.com. I have a system established there for doing it, you see. I can't really do it here without making a lot more work for myself. Thanks! Pete

I have no idea, but I cannot help find out if you persist in not cross-checking things, and not even providing log files to show what you mean. All the tests I can do here show it is working the same. There is no change in any of the code in FSUIPC for FS2002 in the areas concerned with A/P in any case, and the conversion to the FS2004 A/P is working fine in all respects according to all my tests, and is confirmed by using FSInterrogate.. I am quite prepared to help, and most certainly to correct anything that is wrong, but if you take this attitude and refuse to go into any more details, or to do any cross checking, I'm sorry, but it just isn't going to get any further, now, is it? What else do you expect? Please be reasonable. Regards, Pete

Has he? I didn't think that was the case. Where has he said this, please? You think I need something extra to do, to while away all these hours I'm twiddling my fingers from boredom? :lol: I wish! Sorry ... Pete

I am sorry, this simply is not true. Please try it using FSInterrogate and prove it to yourself. It is working fine, and has done for a long time. I don't know what you have wrong in your program, but please re-check it more thoroughly. These offsets are written to by programs driving PFC and Aerosoft MCP devices, and probably many others, and they work now in FS2002 and FS2004 just as they have for several years. Please re-check. Do some tests with FSInterrogate. If you think there's some sort of incorrect interlocking going on, then fine, let's investigate. But merely stating that YOUR program gets these results without any substantiation and no cross-checking on your part does not help I'm afraid. If you like, please use the IPC read/write logging facilities in FSUIPC, and show my the part of the log which proves your point, or show me the part of your program and I'll try to see the error in it. Meanwhile I cannot hold up the release of FSUIPC 3.04, which does correct some genuine errors and omissions, any longer. Regards, Pete

Is it Radar Contact you mean? I will assume it is ... Certainly Radar Contact has been accredited, and I know JD has incorporated the access key for FSUIPC 3. Maybe the "latest version" isn't the real latest, which is probably still in Beta. Sorry. You'd need to check in the RC support forum I think Anyway, if that is the case then, at least under FS2002, it won't need FSUIPC 3, your previous one would do. It is FS2004 which is the need for FSUIPC 3. Yes. All FSUIPC compatible programs should work (as far as their FSUIPC interface is concerned) when you have registered. Only accredited ones work if you haven't. The other pages contain the User facilities which is what you are really paying for when you register. You'll see them all then. You get all the User facilities if you register, including the "magic battery" option (as I like to call it! :) ). Regards, Pete

Not exactly FSUIPC's doing. The original FS98 weather interface only supported setting universal or global weather, as did the "Advanced Weather Interface" I provided to take advantage of the weather additions in FS2000. FSUIPC has never been able to directly set specific local weather stations before, even though there were most certainly local weather facilities in both FS2000 and FS2002. All that is added for FS2004 is an interface which allows external programs to set weather at specific weather stations (and read it too). This is in addition to the other two methods, and it is called the "New Weaher Interface" (NWI). (How's that for imaginitive naming? :lol: ) FSUIPC has never provided any smoothing of anything for local weather. That's not changed. FS itself does that. The weather at any point in FS (especially FS2004) is an interpolation of the weather from a number of nearby weather stations -- it is not just one, then the other! Your "abrubt wind changes" will certainly occur if you "go from one station to another" abrubtly, using the Go To Airport menu, for example. But it certainly shouldn't if you fly there, as FS is interpolating the weather all the way along the route. Why not load up FS2004, get it to download the weather for you, and try it? All the NWI provides is the opportunity for external programs to supply the same facilities. Why should Microsoft exclude 3rd party programs from being able to provide the same locally variable weather as they do through their arrangements with Jeppesen? If you don't like the new localised weather capabilities of FS2004, then you don't need to use them. The old methods still work. They are just not as good in my opinion. Let's move forward, not back, eh? Regards, Pete

Menu "PFC", Select the Avionics Buttons page. There you see the list of those buttons on the Avionics stack which can be re-programmed in PFC.DLL. There are 6 situated at the bottom of the stack and 6 in the GPS area. Make sure you have "List all FS ctrls" checked, then use one of the drop downs to find the GPS controls you can assign. When you register your FSUIPC you will be able to do likewise with almost ANY button or knob on the PFC devices. For that you go to FSUIPC's Buttons page. Pete

Hmmm. I don't knowI've never taken any steps specifically. Perhaps it's to do with BIOS settings? I do have one PC which never switches itself off, it only ever goes to a point where Windows says "it is now safe to switch your PC off". Does your rogue PC switch off properly when you tell XP to do so directly, via the Start menu? Because as far as I know it should do exactly the same when WideClient issues the instruction to Windows too. If it doesn't, then possibly there's some driver or other background task not terminating correctly? Pete

On the console? There are no switches or knobs really usable on the Cirrus II for a GPS. Don't you mean the Avionics stack? Anyway, please be a little patient! FS2004 only came out last week. I had it a couple of weeks before that, but even so it's a near miracle that as much works as it does. I have a lot of work to do still just to catch up and complete FS2002 compatibility items. When I've done all that, and hopefully it will be this side of Christmas, I shall start looking at some of the new things in FS2004. Meanwhile, you can of course program all the programmable buttons on the Cirrus and Avionics stack within the PFC options -- if you enble "all FS controls" to be listed you'll see the new GPS controls listed in the drop down (they start "GPS ..."). And of course you can program almost any button switch and knob on the Cirrus and the Avionics Stack through FSUIPC, assuming you have registered it. Again, you'll find all the GPS controls somewhere in the list of assignable FS controls -- look for "GPS ...". No, none at all. You should get excellent calibration for all the default FS2004 aircraft by simply copying over your previous PFC.INI. None of that is changed in the least. It works well here. Possibly some of the aircraft now behave slightly differerntly and you need to get used to them? Regards, Pete