Pete Dowson

I hope someone might see this and jump in and help you, but I'm afraid multiplayer is one area (of many, I hasten to add :) ) I know absolutely nothing about. FSUIPC and WideFS don't come into it at all. I do know that multiplayer is not quite the same on FS2004 as it was on FS2002 -- the protocol has changed somewhat -- but I don't know if this explains your problem or not. Sorry. But maybe Jose will see the message. He pops in here now and then. Regards, Pete

I think it did have the 'new' label when it when it was new, nearly two months ago now, but I wouldn't swear to it. Sorry. Almost everything there has been "new" at least once in the last two months or so. Pete

I don't think Enrico gets around to updating the individual descriptions in each box. He did list FS2004 compatibility at the top. But the definitive guide to versions is my own, here in the Forum announcements. I write these myself and keep them up to date. Regards, Pete

Oh, right. Sorry. But that is really a graphics thing -- the added cloud layer graphic so that the mist is visible below when you ascend above it. This was MS's response to the many complaints it got about the ground being too clear below, suddenly, when you ascend out of the mist. It was actually a late addition, and in fact in many (even most in many parts of the world) situations it does make it better. I suppose they cannot win really, whatever they do someone isn't happy. All of the other visibility aspects in FS2004 are surely good -- certainly a big improvement on FS2002 which was dire in my opinion, and more like FS200o which was pretty good in this respect at least. However, that is not the point. The visibility facilities I provide in FSUIPC are better implemented, now, in FS2004, than they ever were in FS2000 or FS2002. You can certainly get rid of most of the ice rink effects be establishing maximum visibilities and some suitable graduation, to keep the mist clearing slowly to a suitable altitude. Yes, because it was so bad in FS2002 and so much better in FS2004. Sorry, but this has been one of my hobby-horses ever since FS2002 came out. It was nearly bad enough to make me go back to FS2000. Well, not exactly, though it may have been a possible easy side result. The main thing I would like to achieve (and this goes back to FS2002 release, not just FS2004) would be to allow the ATC text and responses to be handled by an external program, even via WideFS on a separate PC. To do this I thought I could hook into the routines which display the ATC window and re-direct the messages before it got drawn. Unfortunately I failed to do this in FS2002 and wasted as much time again looking for a way in FS2004. Another possible advantage of finding a way into it would have been to be able to make use of the same neat FS translucent window mechanism for others to use -- eg instructor programs, Squawkbox and Radar Contact type applications, and so on, rather than the current AdvDisplay window. There are so many potential benefits of cracking this area that I've not dismissed it altogether. It's just that I cannot afford to get buried into that and let everything else slide. I will look again when I get time (hah! :) ) Regards, Pete

No, not the near future. It's a horrendous task. To get anything else done with weather at all I think I would have to completely crack the WEATHER.DLL. It's a complete re-write from the FS2000/FS2002 version -- and much more complex. The FS2000 version took me about 9 months to do all the weather things I did in FSUIPC for that. I was lucky nothing much was changed in FS2002. With FS2004 I reckon its a good year's work, and I have other things to do as well. I just can't afford to drop everything else, ignore everything and do only that. To start with it might not get me far. Many of the last few months were completely wasted trying to get somewhere with it. And it isn't fun. Now that FS is almost all black-box closed-in style C++, rather than the nice open C and ASM structures of the past, it's simply horrendous. I expect FS2004 will be my last foray into this stuff. :( Sorry, Pete

I spent a week full time (my full time = 12 hours per day) trying to find out how to intercept the message to that window, so I could divert them completely, as in AdvDisplay, and failed to even get close. I really am not going to be able to devote so much time hacking again through that tortuous Microsoft code to find such things. I really think if it is that important to you you might like to try it yourself? :) It is no fun, and I would certainly not even consider embarking on such a horrendous investigation for something like that. I'm very sorry. You aren't using FSUIPC 3.05 or later then! The visibility smoothing, limits and graduation are FAR better the way I've done them in FS9 than they were in FS2002! To start with, they are universal, and this time really smooth. From what you say, it is obvious you haven't tried them yet. :cry: It's always been mentioned in the documentation. Regards, Pete

Strange. Most all of my flying is with mists. There must be some setting related to the video options, or possibly a function on the video card or its drivers? Maybe the "fogging" tables or something? I'm afraid that this is a bit beyond me. You might want to try posting in the FS2004 forum. Kety Pluta, there is an expert on video card settings and so forth. Regards, Pete

I'm not sure it is possible. How would you think it could be done? Have a little program perhaps which sits waiting for the window to appear, then move it? Wouldn't that be very irritating -- it would appear in its default position then move every time. How does it identify the window? If the title always the same in all language versions of FS? It can't tell by the window calss as they are all "FS98CHILD" I think. Yes, and that works. Sorry, what are you implying? That facility just intercepts attempts to move the windows (any children of FS) and doen't pass them on to be implemented. It doesn't work when Windows is set to show Windows whilst dragging, as by the time it sees the message it is too late. Regards, Pete

Well currently the key press associations are to FS controls, on the whole -- there are a few additions for special FSUIPC or WideFS functions, and of course the ones for Project Magenta. What you really want is an "AutoBrake Set" axis type control, which possibly should have been thought of by Microsoft. I'll put it on my list of things. It shouldn't be too hard, but I need to be careful. In the end I could be implementing a whole cockpit inside FSUIPC, which isn't its function -- it's supposed to be an interface to allow others to do such things! :) Look out for another release in a couple of weeks or more. I'm trying to ease off on release frequency, so it may be longer still -- I need to get on and do the SDK. Regards, Pete

Check the list of supported versions on this forum (see the "Annoucements" near the top?), and the module list on the Schiratti site. AutoSave for FS2004 was released along with others as long ago as 8th July. Pete

Not sure what you mean there. For me, the single biggest drawback in FS2002 was the poor visibility implementation. It was a giant step backwards from the excellent effects in FS2000 and I hated it. I'm glad it is all fixed in FS2004. Hmmm. Now I know that I don't know what you mean. To me, FS2004's misting and fogging is far better, more like what we had in FS2000. Regards, Pete

It has to be worked out individually for each. And they must access FSUIPC using the internal module method, not the external application method which is inefficient and liable to cause errors in any case. Pete

Good. But what was the problem? Is it something that should be improved, or is it specifically a thing with the one aircraft? Pete

Sorry, I don't understand how this helps me at present. According to another report here, using GPSout, which also uses a serial port, doesn't actually cause the HT problem. Of course, it's use it trivial -- only output, no input (so probably less use for interrupts), and quite infrequent by comparsion. Also I don't think it uses concurrent serial operations, but its own separate thread instead. If you want to try tests on variations I might think of for PFC.DLL, please write to me on my email address as I suggested. Regards, Pete

This is covered in the global weather problem I describe in the IMPORTANT announcement at the top of the forum. I don't think it isn't anything at all to do with the option to extend the upper wind level. As described, it happens because the "global" weather gradually becomes localised. Then any changes made to global aren't seen locally. Yes, there are lots of things that do that in those dialogues, and not just from values set by FSUIPC. This was the same, in fact, in FS2002 and FS2000. If you go into the weather dialogues and press "OK" you are effectively resetting the complete weather system back to user-defined global. that's al that is happening there. It doesn't solve the problem I describe in my IMPORTANT announcement. I don't know of any solution except to move to local weather stting programs. Regards, Pete

RC most certainly has been accredited, and uses a Key to access FSUIPC. It sounds like you do not have the latest version which is so equipped. Please check with the RC folks on this. You don't need to pay for FSUIPC just to run the latest RC, but if you want to for other reasons just check the links in the FSUIPC documentation, or in the "how To" and other announcements at the top of this forum, or in the Schiratti page where you probably got FSUIPC. They are really quite prevalent! :) Regards, Pete

Bob, There's one thing I found which may contribute to this HT problem, or may not. If you've installed Wilco's 767PIC, version 1.3 or later, the PFC.DLL opens a memory filemap to communicate with it's DLL for the 767PIC controls in PFC. Although these are only active when you are actually using the 767, the filemap is an interface with the 767PIC DLL in your Modules folder. If this is applicable in your case, could you just try running FS without the DLL (I think it is called APS.DLL now, though there may be a B767W.DLL too). This is just a straw I'm clutching at, but as it is an easy one to try and eliminate it is certainly worth a look. There is some problem associated with HT and filemapping, according to some reference posted in the other thread. Thanks. Pete

I found my test and tried it ands it does still work fine in FS2004. In case it helps, I attach the little test program (UIPCHelloByMenu). When it is run, it starts but adding UIPCHello to the Modules menu, then just waits for you to select it. then it removes the menu entry and does its normal UIPCHello message box. It only waits 60 seconds then does it in any case. If will say it doesn't know the FS version -- that's because it was made long ago, before FS2004 was allocated #7 in FSUIPC. You can work out what's it's doing by using the FSUIPC IPC logging, but there's an extract from the UIPCHelloByMenu code in the Zip too. Hope this helps! Pete UIPChellobymenu.zip

Well, it should do, as there's no difference in that (nor in fact in the way FSUIPC and ADvDisplay, and PFC.DLL, add their own menu entries). I must admit to not having explicitly re-tested it, however -- I've had too much else to do I'm afraid. I do have a test program here someplace, so if I can find it I'll see if I can check it. Are you using code which worked on FS2002 but now not on FS2004, or is this new for FS2004? Pete

There should be no problem at all. I have assorted mixtures of these on different machines (none with them all on). They don't conflict. you can only run one of them at a time though . As far as FS98 goes, I've not managed to fully test FSUIPC 3 on FS98 but it should be okay. None of the FSUIPC versions really do much on FS98 in any case. With a registered copy of FSUIPC 3, to save re-entering the details for each version of FS, just copy the FSUIPC.KEY file across to each of the FS Modules folders. This only works on one PC, though. If you move to another PC you need to enter the details afresh. Regards, Pete

Not a lot of progress yet --- I've still got a lot of variables to check. If there's something you want to know beforehand, please ask. I can send you bits of what's available so far. For most things the current version is good enough still. Sorry for the delay, but there's been so much unexpected work arising which has been more important, and it takes me half my time just keeping up with support and email. Regards, Pete

Disappointing, but at least it eliminates one part of the puzzle. As I said earlier, I'll try to think up other changes to try. If you would like to help test, please write to my email as I said. Not without a HUGE amount of work, and in any case I don't like main flight controls on clients. I tried that once with EPIC stuff and the latency is just too annoying. It is achievable with airliners, but not nice. With anything faster or more responsive it is noticeably annoying. I think there are other easier and more useful things to try first. Obviously it would help if anyone knew enough about HT to advise me on possibile reasons for this happening, as otherwise it is going to be trial and error. It will be quicker for me when I've got an HT PC up and running, which I may have by the end of the week. Regards, Pete

As a hotkey defined in WideServer.ini. See the "ShutdowsHotKey" parameter. It is in the doc. Well, that should work, provided the data it writes to invoke the shutdown is definitely written before it terminates locally. Uh? Doesn't that just go get the WideClient.exe's from the client PCs and run them in the FS PC? I didn't know you could make the CreateProcess function create a process in another PC! It certainly doesn't work here -- if I run a program from another PC is is brought over the link and runs in this PC, just very inefficiently as it gets its parts, data and so on from the other PC. Anyway, that is nothing to do with RunReady, so I don't know why you mention them in the same sentence? Pete

You do not need any access keys for any application whatsoever if you have paid for a full user copy of FSUIPC. Just ignore that. If you are using Squawkbox with FS2004, then I think the problem is simply that Squawkbox is not yet ready for FS2004 -- the multiplayer protocol is different -- I think there's another package that is needed to complete that part of the interface. I am not an SB user, but I'm sure someone else will jump in here to help on this. Regards, Pete

If you don't receive a response in that time it is because the process you are sending it to (WideClient or FS itself) is tied up (eg reading or writing a large file) and not processing its message queue. Either that or its message queue is so long that it is taking ages to get through it, but that is less likely. Part of the delay could also be process switching, which may be also slowed by other processes and by memory shortages. Sending another message before the first has responded merely complicates matters. The other will be dealt with first, in any case, as it will be in the queue first. FS will be processing the messages one at a time as it sees them, as will FSUIPC when it gets them handed down from FS's message loop. The original code recommended by Adam in FS95/98 days had a single attempt with a timeout of 5 seconds or more. I didn't like that as it appeared to make the application more "hung", so I changed it to multiple attempts with a shorter timeout. The reason I extended it considerably was to allow good results with WideClient when "wait for new data" is set. If you don't use that then you could reduce the number of attempts. It would be high to anyone, but if FS was stuck not processing any messages for that long you'd probably be swearing about the hung state of FS, not worried about your application! Pete