Pete Dowson

Never heard of FSIP200x. But it doesn't matter. What I need to see (as always) are the Log files. There will be a WideServer.Log on the Server and a WideClient.Log on the client. I see from your WideClient.INI file you have specified these: ServerName=server ServerIPAddr=10.0.0.100 Protocol=TCP Why? Are you using Windows98, not XP? If you are using Windows XP all round you can let WideFS connect automatically. Also it is redundant to provide both the IP Address and the Server name -- the Name will be completely ignored. You are best only giving the name, in case the IP address changes. All these things are explained in the documentation provided. Additionally, I notice this in the INI: [user] Log=Debug Why are you specifying Debug logging (making a HUGE file) here, yet not even bothering to look at the Log when you have a problem? In the first instance, I don't want to see Debug logging as it is far too much data to wade through. Please change that back to "Log=Errors+", or simply delete it so that defaults. Finally, ALWAYS provide version numbers. If you are not using the currently supported version of WideFS (6.75) or later, for both Server and Client, please do so first, and test again. Oh, I need to see the FSUIPC.Log from the Server too, please. A complete one, after FS has closed. Regards Pete

"Registered" version? There's only one version! You register it by entering a key you purchase from SimMarket. It doesn't "become a different version". If things work fine without the Key (remove the FSUIPC4.KEY file from the Modules folder), but not with it, then there's one of two things wrong: 1. Either your system date is earlier than the Key purchase data, making it look illegal, 2. Or is is an illegal (pirated) key. If you believe it is neither of these things I need to see a complete FSUIPC4.LOG file (i.e. run FS and close it), as well as the KEY file. Don't show them here. ZIP them and send to petedowson@btconnect.com. If the same problems exist with or without the KEY file, first try version 4.203 from the FSX Downloads Announcement above. Regards Pete

Sounds like they are installed in the Program Files folder, which is protected in Vista? Or maybe they need to write to somewhere in FSX and that is installed in Program Files too? The FSUIPC4 Installer makes the Modules folder read/write by all comers, to avoid problem with FSUIPC writing its INI and LOG files. Best really to install all non-Vista aware programs outside Program Files. Regards Pete

No. It's just another control, like all the others. Sorry, I'm lost. I didn't mention mapping to keys. You did. And what are WideFS form keys? Regards Pete

I only just noticed, you are trying to program a BUTTON! Not a keystroke! So why on Earth are you going "to the FSUIPC Setting Key press tab"????? Pete

Sorry, I cannot understand any of that. Let's take it step by step. You "go to the FSUIPC Setting Key press tab", right? So you have displayed the part where it says "Press set, then the keys you want to program". But then you say "then I click the button I want to program". What? You must press the "Set" button first! If you do that, the words "PRESS KEY" come up with a white background in the edit box, and when you press "shift+C" it displays "shft+C". Are you following this? does this happen? When you say "nothing happens", doesn't "shft+C" appear in the edit box for the keypress? Can you help me at all by describing anything in more detail? sorry, but I have never heard of anything like this before! Did you report it? I don't remember! Sorry, but I don't understand any of that last part. Can you describe things slightly more, er, understandably? Regards Pete

Since both FSX and FSUIPC4 (not to mention SimConnect) are 32-bit programs, I am really at al loss to know how a 64-bit operating system can affect it so. However, I need (as always) to see the Install FSUIPC4.log and the FSUIPC4.log files, both from your FSX Modules folder. Your problem is probably nothing to do with whether it is 32 or 64 bits, but whatever it is the first steps are there. Regards Pete

No problem. I wouldn't have thought of that either! ;-) Pete

Could you first try using Logging and/or FSInterrogate (the tools provided to investigate such things), to check what you are reading to what is provided? BTW I've just re-checked, and both ground altitude and aircraft altitude read-outs are still fine. (There's actually no reason why they shouldn't be as it is all down to Simconnect these days! ;-)). Regards Pete

Good. Glad it helps, and thanks for the feedback. Incidentally, I had to make interim releases anyway, without waiting for confirmation, so those two links I gave you are now wrong. You and others needing this fix should get 4.023 or 3.766 from the Download Announcements at the top of the Forum. Regards Pete

:roll: Of course not. What would the key be used for if you are writing to FSUIPC directly? What would be the use of a key press or a button if it were never used? Who would see it and act on it anyway? Please look up offset 3110. I get the feeling there's a serious misunderstanding here of what the FSUIPC application interface is all about. Please tell me you understand a bit about it, else we'll have to go to absolute basics! ;-) Regards Pete

As I said "I've managed to reduce the stuttering, but i fear it may also be less effective." In tests here I'm getting fewer severe windshifts, but they are still there. On most flights there have been none to upset the autothrottle or anything. The worst ones with the default settings were at most around 110 degrees, whereas before they were often 180 degrees or close (the worst they could be). Most I've seen have been 40-50. If, in the Logging, you enable "Extras" (or set it to 1 if you have the Edit box showing), each significant occasion of Wind Shear will be logged, like so: 2124468 **** WINDSHEAR: prev ambient wind = 345/34, new wind = 257/34 The only way to make it acceptably effective, I think, (yet still not foolproof) is to reduce the delay to zero AND maybe including the Global weather. In other words, change these two parameters in the INI file (defaults shown): WeatherRewriteDelay=10 ProcessGlobalWeather=No I've not found a Delay of 1 to be noticeably better than 10, but do please try it and let me know. The best would be 0, but then you will certainly notice stutters. And it is probably best to ignore the Global weather part -- for proper graduated visibility it seems that is definitely needed, but the stutters are unbearable. Also, seeing as the other problem is the time taken to scan and update the nearest 9 stations (one of which may have therefore updated its weather 9 x update period ago, or maybe 18 seconds), if you can make it scan and update faster it should be more effective. The problem then is the performance hit. The default period is controlled by the parameter at the bottom left of the Winds page, which is this in the INI: WeatherReadFactor=2 You can change that to 1 for the fastest scan rate, halving the possible lapse before FSUIPC picks up new WX from a station. But take care not to slow down your FS frame rates. If you install Acceleration (or SP2 when it is released)* it will be twice as fast in any case ("2" will give 1 second instead of 2), so setting it to 1 gives a maximum scan, hopefully, of about 5 seconds per station. I suspect then that a delay value of less than 5 should be about an optimum for stutters versus wind shear effectiveness. As for trying to detect the weather at a station before it is set at the station, I'm afraid that's impossible. I was hoping that, by changing the weather at stations as far away as 40 nm the weather would be under control by the time you got there. The very nearest is actually processed twice in the scan (so really making each scan 10 stations). Experiment. Let me know. I can change the defaults if you find better values. Ideally I would like to just process the 3 WX stations which are contributing to the weather at the aircraft, but at present I can't identify them. If I could I could keep them all under watch every couple of seconds. And maybe use a delay of 0 (for one small stutter?) when one of the three changed. * You said "within FSX SP2". Did you mean SP1? SP2 isn't available yet. Or do you mean Acceleration? Regards Pete

Yes, of course. If is an FSUIPC-added control with a published control number. You can send any FS or FSUIPC control via offset 3110. If you want to Zap specific aircraft your own code selects from the FSUIPC TCAS tables, that facility, to do it with the aircraft ID, has been available for several years -- see the Programmers Guide. Pete

So, as it works fine with all the default planes, how do you work out the specific Level-D 767 problem is "something to do with FSUIPC"? You seem to have successfully proven otherwise! Or am I misunderstanding something? Regards Pete

Actually 60905 (means "5th September 2006") was the first release, last year, not SP1A. Regards Pete

It won't be FSUIPC giving you a CTD. Look elsewhere. Probably video driver. If you want any further help you'll need to be a lot more specific. Details, logs, etc. Pete

Aha, so there is a function for it! That's good, and I did really think there should be! Well done, Pete

Yes, that will work (though you should add a zero character to the end -- if you don't any previous longer message will leave part of itself appended to yours when displayed). But: it is not very efficient. Each time you add another character you are creating another "write block" with a 16-byte header. That makes the data being transferred nearly 17 times larger than it should be. Worse, when it gets to FSUIPC, each of those writes is processed separately, taking valuable FS processor cycles. Better to formulate the string correctly in your own area first. If VB doesn't come with a way of converting its strings for normal Windows API ASCIIZ format already (which would surprise me), then declare a work area as an array of 128 bytes and do the loop for the string length preparing that array. Add the zero at the end, then do the single FSUIPC_Write from the array with a length+1. Regards Pete

Further to this, I have now added code to FSUIPC4 to check that the full pathname for the SimConnect.dll I connect to contains "WinSxS" (to show it is from the Windows side-by-side folder. However, in trying to test it, I placed each of the versions of Microsoft.FlightSimulator.Simconnect.dll I can find (Original, SP1 and the new Accelerator version), one test at a time, into the Modules folder alongside FSUIPC4, and also even tried them with the name stripped to just Simconnect.dll, and in no case did Windows supply anything other than the correct WinSxS version. So I don't understand what happened in your case. Are you sure there was no other file in there, like the .manifest file or any SimConnect.xml or cfg file? [LATER] EUREKA! I managed to make it do as you did -- on Vista! It doesn't go wrong on WinXP. It is evidently a new Vista bug/deficiency! Anyway, now I can test my "check" for this. Unfortunately I cannot make FSUIPC4 actually work with this hapening, all I can do is log the incorrect SimConnect details and say it should be removed. Thanks, Regards Pete

No idea. I'm amazed that they can be set to operate digitally at all. But doesn't the other posting, above, by GeorgeTyrell help? I'd send them back and get them fixed if I were you. I'm sorry, but I don't have any Saitek gear and cannot substitute for their support. Judging by the recent threads on their new gear it looks like everyone's having problems with them, and that they were released rather before they were ready. I'm sure Saitek had an excellent reputation before this, and it is rather sad to see all this happen. But there's not an awful lot I can do about it. Sorry. Regards Pete

Ooh, ouch! Maybe I should put in a check against that. However, I do find it rather strange that Windows would look there for a Side-by-Side manifested DLL. I shall have to ask my contacts in Microsoft about it. The only difference I can think of is that 4.16 was not aware of the Acc/SP2 update whilst later interim versions were. Can you tell me what the version of the SimConnect.DLL was that you put in the Modules folder? Regards Pete

Hmmm. I don't think FSCopilot is interfering with anything -- didn't we try a test with that not even loading? Two tests in fact! Maybe an FSX reinstall would do it, but I'm not so confident. SimConnect is a side-by-side library and even if you do a complete uninstall first (which you should), parts of SimConnect are not removed. That FSX Help announcement does tell you how to fix this for the base version, but I think there are problems doing that in VGista -- you need extra privileges. It might be worth doing those little edits in the DLL.XML file, just to see what happens. Here's the beginning of a SimConnect log I just got with FSUIPC4 and FSCopilot listed in the DLL.XML file, but no FSCopilot installed in Modules: 0.00000 SimConnect version 10.0.61259.0 0.04623 Server: Scope=local, Protocol=Pipe, Name=\\.\pipe\Microsoft Flight Simulator\SimConnect, MaxClients=64 0.13076 Server: Scope=local, Protocol=IPv4, Address=127.0.0.1, Port=2276, MaxClients=64 0.13313 File not found: Path="Modules\FSCopilot.dll" 0.55982 DLL Loaded: Path="SDK\Environment Kit\Traffic Toolbox SDK\traffictoolbox.dll" Version="10.0.61637.0" 1.54959 Panels data export found and set to 20B319D8 4.44048 DLL Loaded: Path="Modules\FSUIPC4.dll" Version="4.2.0.1" > 15.82679 [ 0, 1]Open: Version=0x00000004 Name="FSUIPC4" This is actually from an installation with Acceleration already installed, so the version numbers and so on aren't like yours. But that message "File not found" has always been reported by Simconnect when it is told to load a module and it cannot find it. That's the crunch. In your log it didn't say it couldn't find FSUIPC4 even. Why not? Will it say that about FSCopilot if you move it or spell it wrong? Regards Pete

Sorry, but in my haste to reply before I went out, I pressed "Edit" and edited your message instead of "quote" to reply to it with quotes. However, I did read it, and here is my reply. I'm sorry it isn't good news! :-( First I have to assume that by "no fsuipc" you did mean that you looked in the Modules folder and made sure there were no new FSUIPC4 files produced (like the Log and INI files)? [if not tell me soon, please]. If so, then I'm absolutely and completely out of ideas. The Install log is perfect, but even if it was screwed up the rest is not explainable. In both of those XML files FSUIPC4 is clearly in the DLL.XML, in the place occupied previously by FSCopilot, and with everything absolutely the same excepting only the name of the DLL. It is inconceivable to me that SimConnect can read that file, find and load FSCopilot okay, yet not only completely ignore the FSUIPC4 entry but not even report that it is wrong in some way! It simply makes no sense whatsoever. Even if the FSUIPC4.DLL file wasn't there it would report that in its Log. If it was there but it didn't like it, it would report that too. There is no case I know where it would simply do something like this, say "I don't think I'll take any notice of these parameters, so there!". To test this, as an example, just edit the DLL.XML and change the spelling of "FSCopilot" to say "FSPilot". Run FSX, check the SimConnect log (you are still logging SimConnect? If not, do so for this). It should report that it cannot find " FSPilot". If it still actually loads FSCopilot then obviously we have been looking at the wrong DLL.XML file all along! If it does, correctly, report that it cannot find "FSPilot", try a test with a misspelling of the FSUIPC4 entry. Change "FSUIPC4.dll" to "FSUIPC.dll". See what the log says. Apart from such apparently daft tricks I just cannot think of any way of proceeding. You have a unique condition which, on all the evidence so far, is simply impossible. There must be something we're missing, but I honestly cannot see it. It isn't as if I can add more diagnostics in order to find out -- I can't add anything useful to a program that is simply being blatantly ignored. Sorry. Regards Pete

Sounds like you have more than one axis assigned to the same throttle(s). Check all your assignments. Possibly you are trying to assign them via FSUIPC Axis Assignments but haven't unassigned them or disabled the joystick in FS? Or possibly you not only have separate engine throttles but also one generic throttle assigned controlling all engines. Regards Pete

But it most certainly shouldn't work that way. The display is activated when you write to 32FA. Nothing happens when you write to 3380. Maybe you are repeating it? First, the call "FSUIPC_Write(&H3380&, 128, VarPtr(test), dwResult)" is wrong because the string is not 128 bytes long. You must give the actual length, including the terminating zero byte. Second, though I don't know VB, the usual sort of reason for this problem was that VB didn't use ASCIIZ strings, but either Wide or Unicode strings, so that string wouldn't be correct. Additionally, an ASCIIZ string should be zero terminated, whereas aren't VB strings preceded by a length byte? If that is some odd control character, that would wreck the string as well. Please use the Logging facilities in FSUIPC to see exactly what is being written. That is why I provided logging, to help folks debug their code, yet no one seems to bother to take advantage of this! :-( Regards Pete