Pete Dowson

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

No. If WideClient sees the shutdown it closes any applications in its close list -- it works best only for those it loaded itself too. I don't know how you are starting the apps because you don't show your INI file. If WideClient is not closing, then it is not seeing the close down signal in WideServer. This is simply a value written to a location in FSUIPC offsets. Possibly you are closing down FS before this has had a chance? Best to close down FS using the WideServer shutdown facility and a WideServer hot Key (I use Ctrl+Shift+E). It works here every time, for all apps and WideClient. Regards, Pete

Okay, Check version 3.06 when it's up on the Schiratti site (some time Saturday I guess). You can do this now, just set the lower graduation altitude to zero and it uses the top of the visibility layer instead. Regards, Pete

FSUIPC's "New Weather Interface" can provide you with the weather at any WX station given the ICAO id, or the interpolated weather at any point given the Latitude and Longitude. This is for FS2004 only. Regards, Pete

I don't know what your "src" is, but you need to now treat 05DC as a 4 byte value, and write 0x00010001 to set slew, 0x00000000 to unset it. It MIGHT work with your code if you actually set 05DC before 05DE, bt I think not -- safest to do it as a single value. Pete

No, I can't do that, but I can send you a key to use in the mean time, with an expiry date. Please write to me at petedowson@btconnect.com, giving the exact name and email address you supplied to SimMarket, and I'll send you an interim key. Will an expiry mid-September be enough, do you think? Regards, Pete

If I could locate where the localised weather structures are I could do a lot of things, but I spent many many hours and never found them. I only ever found the global one. I think it gets very complicated anyway -- the WX station weather is the source, wherever they are, but then, as you fly, I think it is making a matrix of nearby stations and manipulating these. Trying to track them down through private pointers and so on is a real nightmare, and I failed miserably. Maybe I'll take up the hunt again one day, but I hate such long periods being totally unproductive. It is so frustrating. What might be easier is to download the FS9 weather (the all-at-once option, not the 15 minute updates), save a Flight, which also saves the WX completely, then have a program which processes the WX file, raising or lowering all the visibility layer tops. Then you'd have to re-load the flight and hence the manipulated weatherUgh! Regards, Pete

Sorry, isn't it described in the SDK yet? If not, my mistake. I'm referring to my own copy, of course, which I keep updated. Here's the entry as it should be appearing: 05DE 2 bytes Slew control: write non-zero value here at same time as changing 05DC above, and the Slew mode change includes the swapping of the assigned joystick axes. [ignored in FS2004 – the axes are swapped in any case] Regards, Pete

Enrico says: "I just refreshed the Glass Cockpit to 402... We now have three new entries... StartElecOff=On/Off - switches the displays off on startup sets 0x510 bit 0 to 1 on startup - displays are reactivated when bit 0 is reset or any keyboard key is pressed StartElecSingle=On/Off - switches the displays off on startup sets 0x510 bits 2 to 8 on startup (not bit 0!) StartElecAvionics=On/Off - checks the position of the avionics to decide whether the displays are on or off" Okay now? :D Pete

In FS2002 it was discovered that writing to the Slew control offset (05DC) to enable slew mode did NOT switch to the slew mode joystick axes. The only way to do that was for FSUIPC to intercept the writing of Non-Zero to 05DC and instead send FS a SLEW ON command. It was decided that, since the FS offset had always omitted to switch the axes, rather than make this standard I would enable it by using the extension in 05DE. This is, I think, what you are referring to as "enabled" but you seem to have it the wrong way around -- before that change the normal joystick axes were always left enabled, you couldn't make FS swap over to the slew axes via the IPX interface. Unfortunately, in FS2004, which I assume is now what you are asking about (though you don't say), there is no place which FS is recognising as a "slew on/off" switch -- there is in effect no 05DC nor 05DE facility actually provided in FS2004. To support any Slew control and indicator at all, FSUIPC has to intercept writes to 05DC and operate the FS Slew control as a result. Similarly it reads the slew state and provides the value back as an indicator. But now that it has no choice, now that the only way to enable Slew mode is via the FS control, there's no use for 05DE. The joystick axes are always switched to the SLEW ones when in slew mode. I see no way around that. There should be no problem for you if you are using normal axes, assigned in FS. If you are using separate controls like PFC or, presumably, Elite, it might be a problem as they don't send any axis values to the Slew controls. Regards, Pete

I've written to him to ask anyway, as it also affects the programming in my PFC driver, for the avionics master switch. I'll relay anything I learn. I expect it is just an oversight. Regards, Pete

Sounds like their switches have bouncing problems. Maybe they have debouncing code in their drivers. All FSUIPC is doing is reading the state at regular intervals and acting on changes. You can make it do this faster -- check for the PollInterval parameter (Advanced Users Guide), but this could conceivably make it worse rather than better. FSUIPC reads joystick buttons via the standard Windows API (joyGetPosEx), not via DirectInput. So another possibility is that the Goflight driver is doing things a different way and the two accesses are conflicting somewhere. Maybe the driver doesn't actually provide the real-time status of the button, but uses queues, counts or flags or something. Sorry, but I think you'll have to get GoFlight to advise you on this one. Regards, Pete

That's nice. He doesn't tell me these things. :cry: Well that seems bad. What does Enrico say? I hope he told Enrico this. All I can do is relay this to him in case he is not aware of it. Regards, Pete

Right. Well, I see no real advantage in that. It just limits things more, doesn't it? If your vis layer finishes at X feet and the graduated starts at Y feet, then you have one of X >= Y, in which case graduated vis starts before or at the top of the visibility layer, or X < Y, in which case you have a vis layer value from 0 to X, then the maximum allowed by the FSUIPC maxima settings from X to Y, then graduation from Y upwards. I can see your point if you are not using the FSUIPC maximum settings, and maybe not using smoothing. Well, yes, but you should get it smoothed in any case, unless you don't use the FSUIPC smoothing. Admittedly, that isn't done by altitude. I'll have a look, anyway, and see what I can do. It it is easy I will slip it into FSUIPC version 3.06 which I hope to release later today or maybe tomorrow. Regards, Pete

There are no passwords used in FSUIPC. To upgrade from one version of FSUIPC to another you simply copy the FSUIPC.DLL file into your Modules folder. That's it. There are no prompts for passwords, nothing like that at all. If you have already registered FSUIPC then updating the DLL from one version 3.xx to another will not affect that registration. The details will have been stored in the FSUIPC.KEY file so you do not have to re-enter them. This will be so for ALL versions 3.xx -- i.e. for at least 2 years. On the other hand if you DO want to re-register for some reason, you can delete the FSUIPC.KEY file. If you do re-register you must be VERY careful to ensure that al the details are EXACTLY as given in your original email notifying you of the registration key. Your name, email and key must all be precisely as notified. Computers are stupid, they believe what you tell them. Regards, Pete

You don't say which version of FSMeteo you are using, but if it is version 5.xx then this may be a symptom of FS's localisation of globally set weather -- please see my discussion in the "IMPORTANT" announcement about this. If you are using FSMeteo version 6, There's really no change in FSUIPC 3.05 which would affect FSMeteo's behaviour. I know that FSMeteo is still being furiously developed by Marc. In general, either do not start FSMeteo before FS is fully ready to fly, or at least manually clear the weather in FS first -- you can use the button in FSUIPC's first page, or assign at Hot Key for that. Manually refreshing FSMeteo would do the same, I think. Regards, Pete

The graduation starts from the lower altitude you set for it, but 1000 feet above the WX station's ground level at minimum. i.e. it always tries to ensure there is a measurable layer with the current set visibility. Then it increases with altitude to the upper altitude you specify, whereby it should reach the upper visibility you specify. Below the lower altitude the visibility is constrained by the maximum value applicable to the cloud cover -- if you have that option enabled -- or, when below the top of FS's visibility layer, by FS's set visibility if that is lower. On top of all this, if you have smoothing enabled in FSUIPC, the final value is constrained to change only at the rate you impose. Hope that's clear. Pete

Either raise the top of the visibility layer so that the haze layer covers the mountains too, or lower it so that it disappears (you can still get lower visibilities using FSUIPC's maxima). If you use FS's own weather downloads you can't really change that easily, but you can get FSUIPC to set the level automatically if you are using an external weather program. Because, as I explained, in FS2002 when you climbed out of fog or mist and everything went clear, the ground below also went clear, completely sharp, and most definitely unnatural. In most circumstances the new effect, which as I said is done by FS applying a thin cloud graphic at the top of the vis layer, is better. I agree it can look odd in some circumstances, but the only answer then is to adjust the level. It isn't a bug, that's why. It's the same sort of thing as the ever-present blue horizon in FS2002 -- an artefact of the way a facility is implemented. Regards, Pete