Pete Dowson

But from what you go on to say, there are other things you are not using when it is okay, not just my modulesSB for instance? Multiplayer? Okay, then that narrows it down a lot, doesn't it? It is either to do witth the internet connection itself, or multiplayer. Neither of these will have any bearing on any of my modules, except possibly WideFS, depending what protocol you are using. Phew! That does sound odd. And you had this when on-line with FS2002 as well? I think you need to check with other SB users. All that means is that WideServer was held up long enough for WideClient to time out and reconnect. This can happen during scenery loading for instance. It isn't a problem. But it still happens? With no internet connection at all? Sorry, but I certainly have not heard of anything like this before. It does sound suspiciously like something is interacting quite badly between your internet connection and FS. Possibly there's some conflict like the video drivers operating on the same IRQ as your Ethernet card or modem or whatever? If you are using the FS PC to connect to the Internet, try using the client instead, and running SB there. And so on, I'm sure that with two PCs you can try a variety of things to isolate the problem. My modules get the blame for almost everything, and it is very depressing. I think you will find your solution elsewhere though, in this case. It certainly won't be anything to do with FSUIPC's weather facilities as the FS2004 code and FS2002 code for the weather is entirely separate and different -- it had to be, FS2004's weather is totally different. Since the only other aspects used by SB in FSUIPC are for position read-outs, and pretty much all programs use those aspects, whether on-line or not, I really think FSUIPC is ruled out of the suspects. You should be looking at what is unique about flying on-line. (1) the internet connection, and (2) the multiplayer interface. Neither of these involve my modules. Oh, one more thing to think about. If this is happening on one PC only (i.e. you've not got it on another, or have no other suitable PC to try), it could be a hardware problem. I had some VERY weird stuff going on for weeks on one of my PCs. It turned out to be a bad memory stick. Oddly enough, it didn't often cause crashes, just weird things. And only when I loaded up the PC fairly heavily. I guess it was going bad in an areas rarely allocated, and then just affecting data, not program. Regards, Pete

HOLD THE FRONT PAGE! I may have found a way to "fiddle" the wind values, so that taxi wind and wind smoothing can be applied universally, from any weather source! Don't hold me to this as I have to prove the idea yet with some testing, but it looks like I might be able to intercept the wind read-out used for simulating flight and manipulate it before it is applied to the aircraft. This is an out-and-out fiddle, if it works. The 1 knot or smoothed wind won't show on the screen, or on (most?) wind indicators, or in ATIS or other weather reports. But it looks like it will be the actual active wind on the aircraft. It may possibly apply to all aircraft - AI ones included - so their selected runways may be affected too, but this was always a potential problem with taxi winds in FS2002 as well. Regards, Pete

Why do you make the subject "Pete Dawson"? It isn't very informative, and it isn't even my name! Please try to be a little more considerate of others trying to read threads which are of interest to them also. That's part of the benefit of a Forum over email. No, sorry. I have no idea what the payware Cheyenne is, nor what "shuts the plane completely down" means, but I assure you FSUIPC has nothing to do with views nor graphics of any kind. I suggest you ask the payware Cheyenne folks for assistance. Okay? Pete

Gray screen? By default you should have no screen at all except the title bar. You must have re-sized it. If you want to do that and have something other than gray there you can get WideClient to load your own bitmap. There's a parameter for that. What program are you trying to run on the client? It will be its window you want to see really. Normally you will want to hide or minimise the WideClient window. It's only useful for showing whether it is connected or not. Pete

Further on the tail hook, I see a "Toggle tailhook handle" control in the drop down list in FSUIPC's Keys and Button pages. Is that what you wanted? I'm not familiar with this stuff. FSUIPC's lists of FS controls aren't of its own making, it just extracts them directly from the table in CONTROLS.DLL, so what you get it what's there. Regards, Pete

AhNOW I think I understand what you are seeing. Try going to the Options-Settings-Display dialogue, select the Weather tab, and extend the "sight distance". You'll find that the further you allow the scenery to draw, the thinner that band becomes. If you set it at maximum you will get no such band or line at all, at least not at normal cruise altitudes. The only trouble with this is it may have an impact on frame rates. It would perhaps be nice to be able to gradually increase this value as you climb, and decrease it as you descend -- something for an FS2004 version of Lago's FSAssist, I suspect -- though I think it causes something of a reload/redraw action, so maybe it isn't desirable. Regards, Pete

Sorry, what is "tailhook_toggle"? Is this something FSUIPC should know about? Can you explain please? Pete

WideServer will automatically disconnect and reconnect at intervals if there is no activity, i.e. no client applications who have requested data. This is optional but defaulted. If you are experiencing disconnections for any other reason then please Zip up the Client and Server LOG files, plus the INI files, and send them to petedowson@btconnect.com with a covering message describing your systems and what you are doing. Regards, Pete

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