Pete Dowson

Good. but it is a bit worrying for me. The codesigning check in Windows uses "wide character" format -- 2 bytes per character instead of 1. But all the folder / filename routines use multi-byte characters -- that is single characters for standard English/ASCII characters but 2 or more for other character sets like Cyrillic. Before I call the codesign checker I have to use a library routine "mbstowcs" to convert multi-byte to wide character format. It seems this is going wrong. I've looked at my code and that looks fine, so I'm wondering now if there's a bug in the C++ library, at least for Cyrillic multi-byte. I'll do some checking into this, as it may occur again with other users. Glad you are okay now, though. [LATER] I can't find any reports of any problems with the library routines I'm using. I am wondering if it has to do with "locale" settings. The multibyte encoding, or "Unicode", has different "code pages" for different character sets, and the "locale" set on the PC selects the code page to be used when Unicode is selected. Is it possible that you have a different User locale set, not the one normally used for Cyrillic? (Sorry, I can't, at present, explain any moreI am floundering a little in an area I know nothing about). Regards Pete

Only the first few lines were needed: The outgoing connection is being blocked completely. The most likely reason is a firewall, on the Server PC by the look of it. You said you tried disabling them, but evidently this did not happen. Windows Error 10038 merely says "An operation was attempted on something that is not a socket.", which effectively implies that the socket which was automatically opened for the incoming connection from the client has been closed by something as soon as an attempt to write to it is made. Incidentally, I've never had to disable any firewalls anywhere to make WideFS work fine. I've used both Windows and Norton firewalls with no problems. You may get a prompt asking if you want to allow the connection, but no more. I don't know what security software you are using, but it is still preventing the connection -- or something you have installed certainly is. Regards Pete

I've tested this and, in fact, the space bar by default actually uses the same toggle control ("MOUSE LOOK TOGGLE", but it sends it when pressed and also when released (also continuously whilst held), so cancels itself. I think this is too complex for me to easily implement in the easy way I dealt with the simple space bar held action -- detecting the control is asynchronous compared to keyboard interception in any case, and things may get out of step. so I'll quit on this whilst I'm ahead. Regards Pete

Not so rapid. The retries are at 20 second intervals. This is the standard timeout for receiving data. The Client end is only half the story. Please show the equivalent period WideServer.Log too. The summary at the end shows that, in fact, the Client never received any data blocks from the Server. I have no idea what the instruments were showing, but it most certainly was nothing to do with what was happening on the Server. I can't comment any further without seeing what the Server made of this. Pete

With Vista I'd avoid "Program Files" if I were you. Vista protects it against programs writing data, so makes life difficult for non-Vista aware add-ons which then forces you to always run everything with the "RunAs Administrator" special privilege. Best to keep it simple -- C:\FSX. Regards Pete

Ah, I see. So to avoid any problems all folks should do is make up their minds whether to use CHM first, before assigning in FSUIPC. Then no problems would arise. Alternatively, simply delete the FSUIPC INI file and start again if you change to/from CHM? I don't think CH themselves would be interested is "fixing" anything here, as they wouldn't regard it as a problem, surely? This reminds me of the days of Game Ports. If you were using a Game Port joystick, then unplugged it but did not unassign it, there would be long delays whilst the Game Port driver timed out every single attempt to poll the device that isn't there! USB is supposed to deal with all of these things tidily, but evidently the CH Manager hooking is wrecking that a bit. Regards Pete

The answer is in the log. ACER2 is not receiving the broadcasts from ACER3. Either they are on different Workgroups or something else is stopping the broadcasts (firewall, for example). As described in the WideFS documentation (which is included in the WideFS.zip), you don't need to rely on broadcasting. If you cannot get it to work (sort out firewalls, make all PCs in same workgroup), then simply tell the Wideclient the ServerName (ACER3) and the Protocol (eg TCP). Add these parameters to the [Config] section f the INI file. Regards Pete

Well, yes, possibly. Where did you find it? I am wondering if the version of the signature checking routines I am calling upon doesn't like the Cyrillic characters in the filepath: "C:\Игры\Flight Simulator X\Modules\FSUIPC4.DLL" Obviously all of the other routines I am using are quite happy with the Cyrillic, otherwise the files would not be created in the first place. I'll look to see if there are other Windows APIs which I can use for the code-signing checks, but this does suggest that an alternative may be to install FS into another folder, wityh no Cyrillic characters. I always use something simple like C:\FSX. Regards Pete

Suddenly, after weeks of everyone saying it all works well, reports are streaming out of the woodwork about how bad it is after all? :cry: :cry: :cry: And didn't suppressing the variance fix it for you as it did for Andy? Also, your results seem to be the exact opposite of Tom's. Please, give me files I can reproduce this mess with! Some days it is better to stay in bed. :-( Pete

Suddenly, after weeks of everyone saying it all works well, reports are streaming out of the woodwork about how bad it is after all? :cry: :cry: :cry: Your results seem to be the exact opposite of Toms. So the whole implementation seems doomed. Some days it is better to stay in bed. :-( Please, give me files I can reproduce this mess with! Pete

It's already done and dusted, in 4.264 released earlier today. What does that do? And is it assignable to a control? If so then it would be the control I'd need to watch for in case it is re-assigned or used as a hotkey by something else, even FSUIPC. Pete

Confirmed, that solved the problem. Yes, as I thought. Sorry, I don't understand. You had assignments to a joystick which doesn't exist? That should simply return an error to FSUIPC so it will desist. Can you verify that Joyview shows nothing for such a joystick? But I am now even more mystified. If it only a problem when you have assignments to a non-existent joystick, why would CH want to fix it, and why would you need to disuse it? Regards Pete

I'm sorry, then, I cannot help further. We've exhausted all the possibilities. Please report this to Microsoft tech support and see if they can solve it. I think your Windows installation must be corrupted in some way. Tell them the error number which the signature checking is reporting -- 80092003. Regards Pete

Okay. It is actually 4.264. Download a complete new Istaller from this link: http://fsuipc.simflight.com/beta/Instal4_4264.zip then put the contents, the installer, into a work folder and run it. If you still get the problem, please show me the complete Install log, which should be in your FSX Modules folder. Regards Pete

For FSX only FSUIPC4 will work, and that has to be installed. To save more messing about, I'll build version 4.262 with my latest Installer and get back to you later today ... Pete

Ah, so shouldn't I auto-disable the mousewheel trim whilst the space bar is held down? That would be easy enough to do. Couple of lines of code ... Regards Pete

The fact that he can use the mousewheel for anything other than trim indicates that option is disabled. I didn't even know the mousewheel operated the zoom. My my, that's interesting. I'll have to try it sometime. Regards Pete

What version of FS are you using? Versions 3.8 and 4.6 are not interchangeable, they are for different FS versions. 3.8 will NOT work in FSX, so of course you will not see it? And you don't "run" FSUIPC -- FS runs FSUIPC. In FS2004 and before, with FSUIPC3, it only has to be in the Modules folder, and it runs. You cannot stop it from doing so! Pete

Sorry, but that's an absolute nonsense! You are misinterpreting everything completely. The difference which matters in 4.262 is only in the Buttons Options screen. There's absolutely no difference between 4.26 and 4.262 for button scanning in normal use -- there's been no change to that at all! The "big hit" applies to ALL versions of FSUIPC, including FSUIPC3, because the delay in in the CH control manager!!!! None of you even bothered to notice until I pointed out that it must, logically, be there, because of the appalling inefficiency of CHM. The only "fix" to this is to either disuse CHM or make FSUIPC's button polling less frequent, as I've already explained (and no even documented in the Release Notes). Pete

Which METARs did you check? You would need to know which three weather stations contribute to the interpolated weather at the aircraft, and in general that is not easy to determine. You would need to run something like WeatherSet to see the current interpolated weather being supplied from SimConnect, or engage FSUIPC's weather logging and check the reports in the Log. Yes. Target directions within the range specified are chosen at random, and then these are approached at an interval controlled by parameters until a new random target is computed at a random time later. Under test conditions it looks quite good. Ah, that does sound wrong. FSUIPC most certainly does go to enormous lengths to try to prevent any instantaneous jumps. It sounds like all my efforts have been in vain after all. :-( :cry: :cry: :cry: I've really no more tricks up my sleeve, no other avenues I can even begin to investigate. Odd that every report until yours, over many weeks, said how well the smoothing worked, so this comes as a really bitter blow. Do you think you can reproduce it to order? If so, could you supply a saved FLT+WX file set so I can see it here? Well, approach is one of the worst times for it to happen, so that's a poor excuse. As for on the ground, it is generally best to have wind smoothing disabled on the ground so that new weather conditions can be instigated without enforced delays. I'd love to be able to fix it, but I would first need to reproduce it. There must be some way FSX is bypassing the avenues for wind setting which I am already trapping. As I implied, I really don't have much hope of going further than I have, so it may be simply an exercise in verifying that it is happening then documenting it as a warning. The wind smoothing has been received so well by so many that I don't feel I can withdraw it now. :-( Pete

AdvDisplay is not supported, and has not been used for over two years. Please use the special FS window facilities now built into FSUIPC, as documented near the beginning of its User Guide. Pete

Okay. I've released 4.263 in the FSX Announcement above, now. Regards Pete

Yes, please see FSX Help announcement and repair SimConnect, as I already said. NEVER EVER display your private Key! I've removed it. I may have to block it now! :-( Pete

Looks like the version of Vista you ave doesn't include the GlobalSign Root -- have you tried running the Globalsign root fix as provided with FSUIPC3 and mentioned in one of the pictures you posted? Seems that Microsoft have omitted some essential parts when building some non-English versions of Vista. This is the second such. I am changing the FSUIPC4 installer to automatically run the fix, but it is already supplierd and documented for FSUIPC3. Regards Pete

This is extreme, but it doesn't surprise me if CH Manage is taking at least 5 mSecs every time it is being polled for button presses. The main FSUIPC parameter to experiment with is "PollInterval" which can be added to your main [buttons] section (create one if there isn't one there already). THe default is PollInterval=25, meaning FSUIPC polls for buttons every 25 mSecs (i.e. 40 times a second). If this is halving your frame rate it seems to mean that CH Manager is taking about 12 mSecs to deal with each polling call. No wonder the dialogue hung -- that was polling at 5 mSec intervals! Assuming it is a 12 mSec delay on each call, you really want to either not use it, or set the FSUIPC PollInterval to something similar to FS's own (about 6 per sec U think, or PollInterval=166). For more information on this check the PollInterval parameter in the Button programming section of the FSUIPC Advanced User's Guide. Regards Pete