Pete Dowson

Eremphatically no! Did I say that somewhere? If so it is a typo and I will correct it. Always please use the latest if possible -- updates here are a little experimental, so sometimes it might be necessary to revert to the "official" versions from the Schiratti site, but hopefully only after telling me about the problem so I can fix it. I don't want to ever "revert" to older versions. Always onwards! ;-) [LATER] Ah, I see the confusion. Where it says "It can be used with WideServer 6.72 in FS9 or earlier" that is supposed to be read as "It can be used with WideServer 6.72 in (FS9 or earlier) ...." as it then goes on to explain about "FSX or later". All it really means is that 6.72 is the earliest you should be using, not that you should go backwards. I'll re-word it. Pete

Well, knock me down with a feather! I would never have thought thathow weird. It was creating symptoms exactly like SimConnect being screwed up. Thanks for letting us know. I shall certainly have to remember that. I wonder how it got corrupted in the first place? Presumably one of those crashes you had after installing Acceleration? Regards Pete

If all the switches are readable, yes, of course. If you want to get into conditional programming you need to study the Advanced User's documentation. There IS a thread here, quite recent (a week or three) about this with one user's solution at least. Use the Search and review all the threads with "Saitek" in them. Pete

Not in FS there isn't. It doesn't simulate the transponder so well, at least in its simulation engine. Some add-on aircraft have fully implemented transponder switches, but you'd have to check what controls they provide, other than mouse, if any. Regards Pete

Okay, you wrote to me by Email. I've moved your report back here to keep the thread complete. You sent the DIR.TXT, that's fine. Nothing wrong there. The other directory listings weren't needed and were empty in any case. And the log of course was the same as the one you posted here. Right. That is weird. It isn't something in FS, then, so it must be something else in your Windows system. I'm sorry, but apart from a complete reinstall of Windows I really can't think of anything to suggest now. That's the copy protection routine FS runs when you start it, to stop folks hacking it so you can't load or run it without the CD. Of course that protection didn't last long, they never do. Regards Pete

So, they MUST be assigned someplace, unless you have a joystick driver which is converting them into FS commands directly (unlikely). Have you assigned them in FSUIPC? I assume not or you'd surely say so? In the FSX control assignments dropdown, did you scroll through all the attached joysticks. Each has its own list of assignments, and its own enable/disable button. not like FS9. That seems to indicate even more that you are looking at the wrong list for that joystick. FSUIPC4 doesn't do anything about wonky assignments in FS. You have to sort that out yourself, or simply stop FSX reading anything and do it all in FSUIPC. Regards Pete

Sorry, what is that? No, I just fixed the options muck-ups (not reloading the smoothwhenairborne option when off, and the Miscellaneous options deleting the wind smoothing). Well sudden little wind changes would certainly affect the measured airspeed, of course, as the pressure in the pitot probes is varying. There'd be surely something wrong if it didn't! Regards Pete

BCD is merely the use a a few bits in binary for each digit, so all you have to do is separate the bits. For example, the frequency 123.45 is represented in BCD as hexadecimal 0x2345, probably $2345 in Basic. Right? Of those 4 digits, the lowest, the 5, is in the lowest 4 bits. the next is in the next 4 bits and so on. It is almost ALREADY in character format, you just need to split the bits up. There's no clever computation ever needed! All you need are SHIFTS, logical AND, and OR. I don't know VB so I'll show it in ordinary 'English': Take $2345 First store the character '1', as this is assumed first. Result so far = "1". Take the $2345, SHIFT it right by 12 bits. Result is 2. OR the character '0' with it. This gives character '2'. Store it in the reslut which is now "12". Take the $2345 again, SHIFT it right by 8 bits, then AND it with 15 ($000F). Result is 3. OR the character '0' with it. This gives character '3'. Store it in the reslut which is now "123". Add the decimal '.' here to give "123." Take the $2345 again, SHIFT it right by 4 bits, then AND it with 15 ($000F). Result is 4. OR the character '0' with it. This gives character '4'. Store it in the reslut which is now "123.4" Take the $2345 again, AND it with 15 ($000F). Result is 5. OR the character '0' with it. This gives character '5'. Store it in the reslut which is now "123.45" Okay? Another way is to simply print it in hexadecimal, if your VB library "print" functions support this. You'll immediately get the string "2345" which you can massage into "123.45" quite easily. Pete

Ah, I see. Yes, WideServer tends to be tied to the FS frame rate, because that's when the data it is sending gets updated. There's not a lot of point in going faster. The prime reason for limiting the FS frame rate is to keep it regular, not going up and down like a yo-yo. It would have to be quite a poorly performing system these days to need limiting just so WideServer could keep up, though you might need to limit it if any of your client can't keep up -- not too likely unless, like me on my test system, you run three copies of Project Magenta's PFD glass cockpit programs on one poor machine wth a Parhelia card driving three monitors! ;-) Regards Pete

That can only be because the Direct Input driver for your joystick classifies them differently from the old Windows "joy" API part of the same driver. FSUIPC3 uses the old methods (as FS98 and before used to), whereas FSUIPC4 uses Direct Input (but only for Axes, not for buttons). Hopefully this never affects the basic axes, X and Y. The joystick / gamepad devices I have here all seem to give the same axis mappings, but I can see that this could be different depending on the supplier's programming. Regards Pete

See the FSX downloads announcement now. 4.222. Pete

Not without the FSUIPC4 log file, from the modules folder, please. You only showed me the Installer log. Pete

Okay. Here they are: http://fsuipc.simflight.com/beta/FSUIPC4222.zip http://fsuipc.simflight.com/beta/FSUIPC3782.zip Regards Pete

Of course I am very interested in a discussion about this Well, for now I've gone with my first inclination -- if and only if one of those 4 axes are intercepted via 341A, I put the value which would have gone to FS after calibration into the relevant 34xx offset, and don't forward it at all. This means I still go through the calibration, slope and notch calculation just as if it hadn't been intercepted. The only side effect of this, changing things from what they were before, is that the 34xx offsets are NOT updated if the axes aren't intercepted. To do that I'd either have to do quite a big re-write, or I'd have to compute the values twice, and I don't want that overhead. I don't think this matters, though? I shall note in the documents that the 34xx intercepted values are only valid when the intercept is enabled. These changes will be in version 3.782 and 4.222. I'll upload them and supply links later today. Regards Pete

Hmm. That's odd. I'm pretty sure I had that working okay. I'll re-check it. [LATER] Ah .. it IS saved, but not restored to off on reloading. It's because I changed the default to "Yes" and forgot to change the initialisation check to react to "No" instead of "Yes"! Yes, that was reported this morning in another thread very close to this one. It is a silly omission from when I moved the options around. Easy to fix, meanwhile if you go to the Miscellaneous tab, re-check the Winds one before OKaying. Regards Pete

Sorry, let me get this clear. Your flight bsimulator will not load ANY flights at all? Or is it selective? Surely it must be loading a flight to start with, else what is it starting out doing? If you create a new flight, does it reload that okay? If you save a flight using ";" does it save one which reloads okay? That is all AutoSave is doing, using the ";" facility. You need to try to narrow it down by trial and error. What flights does it like, what flights doesn't it like? If it likes none, what is it doing when you first start it up? Pete

Hmm. I'm not seen them with either FSX downloaded weather or with ASX. You have updated ASX to the very latest version, haven't you? It seems pretty good. I wonder if your problems are related to the on-line operations. There's a lot going on with AI traffic creation, to emulate multiplayer, with those programs. Anyway, I'll experiment here with pressure control, to see if I can change that without messing other things up. Not easy -- aircraft systems like those in the PMDG range are very sophisticated and use values like air density and temperature correlated with pressure in the flight and A/P computations, so I have to find a way of manipulating one aspect and hoping FSX will adjust the others accordingly. :-( Now you are going to tell me you get temperature jumps as well, aren't you? ;-) Regards Pete

Generally the displayed frame rate in WideClient (that IS what you are reading, I assume?) more or less closely matches the displayed frame rate in FS. It will only tend to dip if you are asking for massive amounts of data - like using FSInterrogate for a whole raft of stuff. Anyway, you provide no information for me to tell you any more.You don't even say what version of FS it is. FS9 or FSX? What aplications are you using on the clients? What is the effect if you only have one client not "several"? Please show WideClient and WideServer log files -- complete ones, from after they close down. This is important because all of the performance and error recovery information is tallied at the end of the log, when closing. Pete

I've just had a thought though. At present my "simulated" turbulence etc operates whenever there a such effects present in the local weather as told to me by SimConnect. The suppression of these items doesn't directly affect my simulation of them, they operate by trying to change the weather in all of the surrounding weather stations (FSX doesn't provide a "change weather here" facility, only at WX stations). Changing the weather all around can take many seconds, and then there's a delay in any case as the FSX weather system gradually phases in the changes (as of course it is supposed to do with wind). I think, perhaps, I will change my code to suppress MY simulation of the effects when MY options are set so, no matter what FSX decides to do. ;-) Regards Pete

What? I don't see how that is possible -- the bits are individually tested in every place they are affected. [LATER] Aha! Yes. Sorry, found it. A silly typo in one new line of code. I'll fix that. Ah, yes, that is certainly true. In actual fact in all 4 cases the source data is the raw input. So, for instance. That is where they are being intercepted, before going through calibration. Hmm. That is a bit more of a problem. All 4 will have to be re-thought, otherwise it becomes the job of the program which is intercepting them to do their own "calibration". Well, you can work it out of course as FSUIPC has to do. But this is just another result of the input date being raw, not calibrated. I'll have to think about whether to and how to re-design the whole facility here. The similar one for the control axes was designed deliberately to by-pass my calibration, as it is used for "fly-by-wire" where the controlling program wants direct control over the end values, not a "simple" interference. I assume your use is different. You aren't after direct control, where you are deciding exactly what brake, flap or spoiler values to use, but simply want to reduce or change the actual values which would have been applied? Maybe before I change anything at all we ought to have a longer discussion? My first inclination is to put the "raw" value through my calibration routine before providing it in the 34xx offsets. Would that be best? Regards Pete

Okay, so it isn't the weather. This is strange. I've not had anything like this before at all. I don't know how to proceed now. wrong with your FS or Windows system, but what? If I was there, with your PC, I'd use debuggers and all sorts of tools to determine what was going wrong, but I can't see how to do this from here. Just as a last gamble, could you please send me a directory listing of your FS modules folder. I attach a little batch file which will produce one of these. Just unzip the ListDir.bat file to your Modules folder, then execute it (double click it). It will make a small text file called Dir.txt. Zip it and send it to petedowson@btconnect.com. Well, if you are starting with a complete reinstall, test with FS9.0 first before doing the update to 9.1 in case the latter is corrupt. Regards Pete ListDir.zip

I have implemented both Flaps and spoiler axes disconnection facilities in an interim version of FSUIPC (and FSUIPC4), but I have not had time to test them properly. If you would like to download the updates and try them, letting me know, I'd be grateful. Thanks. These are the links: http://fsuipc.simflight.com/beta/FSUIPC4221.zip http://fsuipc.simflight.com/beta/FSUIPC3781.zip The implementation details are: Hope this is clear enough. Regards Pete

Aha! Yes, I see that too. It isn't the Wind settings specifically, but the "Allow changes .." option. This must have been what you were seeing before. It also affects the Visibility and Clouds pages with the same option. It is a result of my moving the "Allow changes ..." option off the Miscellaneous page with copies instead on the Winds, Clouds and Visibility pages, where it has some significance. Seems I omitted to remove code from the Miscellaneous page processing. Sorry. Thanks for this clearer report. I will have this fixed in the next incremental release, or at least in the next main user release which I am aiming for the end of the month. Meanwhile, please visit the Winds, Clouds or Visibility pages after the Miscellaneous page to re-check that option. Regards Pete

Please ignore this in 4.218 because all that was changed in 4.219 which I uploaded this afternoon. That seems fair. I can't SPEED UP FSX smoothing, I only try to slow it down when it is faster! That's the whole point. If it is being changed by FSX I don't even know what its ultimate target is, in any case, only what it is trying to set at the moment. If that is within the range you chose then it is okay! ;-) No smoothing I've ever implemented speeds things up, ever. Not possible, not desirable. Regards Pete

It isn't actually my page at all, but Enrico Schiratti's, as it points out. There is a link there to this Support Forum, and the Support Forum is nicely equipped with an Announcement facility, where I make Announcements and keep folks up to date with what is going on. ;-) I don't release major updates as often as interim ones here, even if Enrico would actually update his page so often, which he doesn't. I was made extraordinary clear with the "official" 4.2 release that the wind smoothing, new in that release, was "experimental" -- it actually says as much on the screen you so kindly posted here (as if i'd not seen it before! ;-) ). There's also quite a lot written in the documentation as well explaining a lot of the problems with doing much with FSX weather. There is no "B" key in a real aircraft, and 18000 is only the "standard" level in North America. Here in the UK the TA varies from about 3000 to 6000. It actually varies considerably all over the world. And unlike in North America the rest of us have two different altitudes to consider -- TA and TL. The TA is generally published in the charts, but the lowest Flight Level you can fly, known as the TL, varies with the QNH and is computed by ATC to ensure adequate vertical separation betwen those on QNH and those on STD (i.e. flight levels). The "B" key "cheat" in FS doesn't obtain the QNH for you, it actually sets it on the altimeter. What you are doing is wrong (and of course not possible in the real world). When descending below flight levels you should set the altimeter to the QNH value you get from ATC or an ATIS weather report. That wouldn't change so often. You shouldn't have to be worried about what the ACTUAL sea level pressure is immediately below you -- other aircraft will be using the ATC/ATIS QNH values as well. Also, the fact that the actual QNH is changing slowly means that FSX is actually smoothing the pressure -- otherwise it would keep jumping. If it kept jumping you would see your altimeter jumping too. Do you? That means, really, that there must have been a sudden jump somewhere -- from another area's QNH to the one at that airport. That isn't smoothing, it is the opposite of smoothing! I'm 65 this year and really would like to fly more in my nice 737 cockpit on which I've spent quite a bit over the years. FSX's SimConnect was supposed to take over from me, and let me have more time .... now it looks like FSXI before I get time off! :-( Regards Pete