Pete Dowson

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

Cheers Okay. Thanks very much! If that doesn't help, maybe you'd like to try a few variations in PFC.DLL for me -- assuming I can think of any which don't involve a complete re-write? If so, please wite to my email address and I'll get back to you when I've thought of something. Thanks again, Pete

Okay, I've been all the way through the code to see if I can spot anything that looks at all likely to be a candidate for "messing up" HT operations -- not that I'd really know, of course. It's all a bit above my head I'm afraid. The only significant thing different about anything PFC.DLL does from, say, FSUIPC or WideServer, or most of my other modules, is that it uses the Serial port. It not only uses it, but, for efficiency, it uses it in full duplex mode with both reads and writes programmed for concurrency -- following all the guidelines and examples in Microsoft sources for such things. Additional to this it does also create two small threads -- one to check on the status of the serial port read buffers, and extract data as it arrives, and the other to replenish the write buffers in the serial port driver whenever they become nearly empty and there's still data to be sent. Now, whether any of these actions is specifically inimical to HyperThreading, I just don't know. And, worse, I have no way of finding out. Looking at this from the hardware up, the first possible area of suspicion is the BIOS serial port support. I doubt that this could do any harm, but given Microsoft's rather pronounced wish to move away from these legacy devices, it is possible that there's less compatibility here that one would wish. To determine whether this could at all be the culprit, I propose that a test be carried out. If anyone using PFC equipment and an HT CPU could try using a USB-serial port adapter for the connection, instead of a genuine serial port, this should succeed in bypassing the BIOS and use USB parts of Windows XP instead. I should be able to do this myself in a week or so's time, once I get the P4 3.2GHz processor I've ordered installed and working. But if anyone does it before, please let me know the results. If this doesn't help, all I can do really is try the PFC driver with different thread priorities, or no threads, and maybe even try using blocking serial I/O, though I don't think that will be acceptable. Oh, there are some Windows API calls to set a thread's processor affinity as well, so I could try deliberately associating the Serial threads with one or the other virtual processors. Anyway, I'm afraid most of this experimentation will have to wait until I have the equipment. Please bear with me until then. I'll be in touch. Regards, Pete

So how are you invoking the ShutDown? I don't understand. If you have WideClient running in all the clients, then of course. You use the "RunReady" facilities. If you mean can I start WideClient remotely from WideServer with no program running in the client PCs to see the request, no. How could I do that? Why not use RunReady and put WideClient in your Windows "StartUp" folder so it starts when you boot. Make sure, in that case, that your FS PC is up and ready or it is likely that WideClient will fail to find the Server. Pete

But all the results folks are posting seem to show that, PFC.DLL aside, FS's performance with or without HT is identical, so what does it matter? Please clarify! Depends whether that succeeds in by-passing whatever it is in Windows that is causing the problem. Maybe it isn't even in windows. Perhaps legacy hardware support in the Motherboard's BIOS isn't suited to HT operation, in which casm yes, bypassing that part by using USB might help. Let me know, please. Also let me know what the difference in performance of FS is with and without HT, both without PFC.DLL. So far no one has shown any. As was mentioned somewhere else here, really the HT thing is surely best used when you have other processes sharing the FS PC. Then assigning FS to one and all the others to the other seems to be a realy good idea. Regards, Pete

You won't catch me doing that. The PFC stuff is too good. Anyway, I though this NT problem could be solved by assigning processors or something? Isn't that what you all have been fussing around doing? Is it me confused or what? :? I've been making notes about all this so I know what to do next week -- my P4 3.2GHz processor, mobo and memory is on order. I expect to be off-line for a couple of days next week whilst I'm rebuilding! :) Pete

I've now looked at that article, and it doesn't really apply. Almost all my modules do use the QueryPerformance calls, but only to get accurate time differences between the calls they get from FS. I might change that soon anyway, if I can find FS's own millisecond timer. The article is really talking about things which might go wrong with a program if it assumes that the values it gets back fit into 32 bits instead of the 64 allowed. This doesn't apply to my code, and even if it did, it wouldn't slow down FS, it would just make the DLLs go wrong, as the article implies. Really, I think the only thing different about PFC.DLL is its use of the COM port, so I think there's something about the COM port drivers which are coming into play (or not) with HT operation. Regards, Pete

No. Sorry, I have no idea at all. I don't have the program. Well, it might be here someplace, but I've never used it and I don't know what version it is. Maybe a FlightMax user can help? Or you could try it and see? Regards, Pete

Sounds like some inefficiency in the Serial Port driver setup then. It's just a DLL. It does use the COM port of course, and that is used in what should be "concurrent" mode -- i.e. PFC is not hanging around waiting for data to be received or sent. So maybe it is to do with the way the Serial port driver is handling this. Testing here I see no difference in frame rates whatsoever, with or without PFC.DLL, but then I've only got a humble 2.4GHz P4 which I don't think hat "HT"? I don't know. I'll have a look. It is probably the only thing using a COM port, so the most likely problem is your serial port driver. Not sure what you can do about that. As I say, there's no difference here at all. There are lots of problems in FS's weather dialogues, few of which are at all related to FSUIPC. I wouldn't really worry about that specific one. Like what? You need to be more specific than that, please! There is nothing "odd" about 100,000 feet. Internally ALL altitudes are kept in metres in any case. That one is actually 30480 metres. I would expect the possibility of problems if it were 32768 metres (exceeding 16-bit capacity), but even that would be strange as FS usese floating point almost universally now. Regards, Pete