Pete Dowson

They cannot really have anything at all to do with autopilot. Furthermore the PMDG autopilot is programmed in its own way, completely separately from the FS one, yet you say it "also occurs with other aircraft" -- other aircraft using the FS autopilot itself? It you have one problem not even really autopilot related how could it possibly affect separately programmed A/Ps with little if anything in common? If you are running anything at all which uses FSUIPC then you are not really ever getting FSUIPC in what you say is a "default" state. Aha! It sounds like you have some bad programming of buttons and a rogue button repeating itself. Or maybe you have dual assignments. Again that word "default" -- you are using seven or more FSUIPC interfacing programs. There's no such thing as "default". If you mean the user options, the "default" settings are those which are thought sensible, not "no options at all". I really don't know how you are managing to associate passive filtering actions such as visibility limits with active controls like parking brake and A/P disengagement. Have you proven such an association? If so then something is very badly corrupted somewhere and i would advise completely re-installing FS and the add-ons. But to me it sounds very much like you have bad button assignments and this is confusing things. Try deleting assignments in FS first, and the [buttons] sections in FSUIPC.INI. Regards Pete

I'm sorry, but I know absolutely nothing at all about Multiplayer, nor is any of my software at all involved in it. you will need to ask SB3 support. Regards, Pete

Good news indeed! Thank you for posting details. Pete

I know about FSUIPC of course, but I don't have any Level D aircraft. Maybe you should ask whatever question it is you have? Regards, Pete

Sorry, I don't know TCASIIv7, but in any case there's no way WideFS or FSUIPC can relay sounds played on one PC to a sound card on another. In fact I don't know any software at all that can do that. You will have to get a mixer and take the sound output from both PCs, mix them together to feed to your headset. If your "multiplayer sessions" are on-line flying with Squawkbox or similar you'd really be better off running that on the client PC so you have the ATC interaction in the headset, and put the TCAS on the FS PC so all the normal cockpit sounds come from the cockpit speakers not the headset. Regards, Pete

Sorry, but I thought I just explained how to do this? i.e.: There is really nothing else at all to explain! Pete

How are you programming them, via key presses or controls? Do you have "repeat" enabled -- if so disable it -- you could get several controls or keypresses whilst you press the button. The nominal repeat rate is 20 per second. Please always state the version number of FSUIPC. If you are not using the latest (3.48) please update. You are programming these in FSUIPC too? Check the settings you have. I don't know why you want to program these things in FSUIPC, as they are all normally assigned in FS. And that's a thought too -- did you disable all the assignments of the same buttons in FS? If not then you will have both FS and FSUIPC obeying the buttons. That could easily explain skipping flap values -- and sending the Gear up/down control twice would negate that too. It does tell you in the FSUIPC documentation to disable FS buttons programmed in FSUIPC. Regards, Pete

Yes, it is a problem with some rather badly designed panels which seem to constantly bombard FS with repetitive commands to no discernible useful purpose. It was to correct this sort of problem (which not only affects engine selection, door selection and pushback operations, but also makes some MCP values constantly accelerate) that I enhanced the "control acceleration fix" option (on the Technical page in FSUIPC options) to deal with it in recent versions of FSUIPC. Have you tried that? Because that FS control does not accept a parameter. It is exactly the same control as assigned to the "E" key you've been pressing! If you aren't happy with the two key pressing method you could program your own control using the FSUIPC added control "Offset Byte Set", with offset x888 and parameter values 1, 2, 4, 8 for Engines 1, 2, 3, or 4 respectively. Add these together for combinations (e.g. 15 for all 4 engines). The offset x888 is where the E + 1 2 3 4 FS control operates. Regards, Pete

I don't understand what "kicking" is in this context, but if this "computer 4" (what a better name that would be than the real ones you have! ) was not even running WideClient when it was interfering, then it sounds like it has a wildly misbehaving network interface or card. Pete

In the FS Modules folder. It's the only place where anything to do with FSUIPC goes/is found. But if you've re-installed Windows you'll have to re-enter the details in the FSUIPC registration screen. Just cut and paste from the KEY file, which you can read with an editor like Notepad. Regards, Pete

You do really need to keep a copy of details for things you pay for! Please refer to the sticky thread near the top of this forum entitled READ THIS IF YOU LOSE YOUR FSUIPC or WIDEFS keys. Pete

The values aren't "capped" by my code, that is the function of the specific controls assigned to those axes. By default the assignment for that particular quadrant uses the controls which have no "reverse" (i.e negative) zone on them. They are so assigned exactly because that quadrant has no detent and no reverse area. Please compare the NAMES of the controls as shown at the top of each calibration column. They are different. The documentation shows a list of the controls you can assign -- including two full sets for Throttle, Prop and Mixture/conditioner, one without and one with 'reverse'. These use different FS controls to operate. That is why I suggested that, if you want that facility you requested on the Baron, you do one of two things: (a) use the turbo quadrant selection in the program, with or without the actual quadrant, or (b) use the facilities provided to make your own User Configuration with the controls which include the reverse facility assigned where appropriate! I don't understand why you take this attitude! You ignore both of my suggestions and want to use the keyboard instead? Why on Earth do you do this? The provisions in PFC.DLL provide the utmost flexibility to do EXACTLY what you want. If you simply haven't the patience to even read my replies properly, then go look at the PFC program and see what you can do, then I really don't understand why you asked me in the first place! :cry: :cry: :cry: Pete

From the logs you have 5 computers, the one called COMPUTER running FS, one called FS which you have shoed WideClient logs for but isn't ruynning anything correctly because you've not given it the ServerName, and the three PCs with odd names as listed above. It is the WideClient logs of those three you should be looking at. Also, the wideClient log shows nothing freezing at all, everything is running fine according to that. You have said this before, and as I told you, you MUST NOT have the same IP address! They must all be different!! Where do you get this "as required" from? Pete

I have no idea because I need to see the relevant logs. You have showed two logs from the same WideServer, and two logs from the same WideClient -- and the WideClient log you showed is from a PC which is not connecting in any case because you have still not given it the ServerName!! Look at the Server log: You appear to have three PCs connecting: AL-6B013BA69872 AL-6B0 AL-6B This is a most weird choice of computer names, which is suspicious in itself, but worse your Wideclient log (for which you showed two) is for a completely different PC: See? This is from a PC named "FS", and its WideClient cannot possibly connect because, as it clearly says, you have still not told it the ServerName! Looking again at the WideServer log: This part shows several interesting things. First, you were up and running for over 7 minutes (522.703 - 85.828 secs) and WideServer recorded no problems at all. If there are problems reported they must be in the WideClient logs which you have not supplied. The second thing to notice is that the PC called "AL-6B" performed well and provided 17 frames per second, whilst the other two contributed a lot less. This may not indicate any error -- it is possible that AL-6B is running the MCP or the CDU or both, therefore writing a lot back to the Server, whilst the other two are merely displaying things -- the PFD.EXE program probably. This is just guesswork of course, because you have not supplied the WideClient Logs for the three PCs which are running WideClient, only for one (called FS) which is not participating at all. If you would try to provide relevant information I can tell you whether you have a Network problem or not. With the information you have supplied I see nothing wrong. In fact WideFS's performance seems rather good, look: 47 frames per second between the 3 PCs, as an overall average, it quite respectable and should easily assure you of smooth running. Regards, Pete

Please find the WideFS.ZIP file, the one you got WideFS from. Look inside that and you will see a WideFS.doc file (there is also a WideFS.pdf which is the same). This is called "documentation". Please take a look. it does tell you ALL these things, and in particular it tells you how to edit the INI files (not "Log" files which are logs of things that happen!) to make things work. You set the ServerName parameter in the WideClient.INI file, in the [Config] section. Then it knows where FS is. Quite honestly if you not bothered to look things up I am not going to continue to spell it all out here. I spend a lot of time writing documentation and it shouldn't have to be repeated here, at least not the basics like this. If your problem is that you don't understand English at all then maybe we can get someone who does speak your language to help here. But quite honestly I don't understand how you can get complex systems such as Project Magenta up and running if you cannot even set one simple parameter in one INI file for WideFS. I have no idea what you are talking about here. This seems to be nothing to do with WideFS. As I said before, if your Client PC does not know where your FS PC is then WideFS isn't going to even START to work. There's certainly no "freezing" going to happen because it won't start in the first place. There's really no way you can have a successful Network with all the IP addresses the same. They have to be all different or they won't talk to each other. One is older than the other, giving the results of the previous session so you can reload and carry on whilst still solving the previous errors if any. Just as for the ServerName business this is explained in the documentation. I do wish you'd take a little time out and try to read some of it. I don't mind answering questions which are not answered in the documentation or which are for some reason obscure there, but everything you've asked indicates you have not even looked at anything like documentation at all. The basic setup of WideFS is so simple, involving very little work on your part. If you really want to do so little then please wait for the next version which will even find the Server for you. Pete

Don't you back things up? You should at least keep copies of things you pay for! Anyway, I don't generate or issue or have records of keys, and I don't send the emails. I do development and support, not sales. Please see the thread near the top of the Forum about what to do if you lose your key. Pete

Isn't that merely a position on the prop pitch levers? I'm sure that works here. Perhaps you aren't calibrating properly? Yes, this is used by PFC.DLL. It most definitely sounds like you are not calibrating your Baron style quadrant correctly. There's a notch part way down, then the red area should all give negative PROPx_SET values, down to where it is marked "feather". Ah. Here you are misunderstanding the whole thing. Sorry. The values arrriving from the throttle axes are NOT the ones sent to FS, they are the "raw" pot readings, that's all. They are for CALIBRATING in PFC.DLL. CALIBRATING is the process of making the raw input values transform correctly into whatever is needed in FS for different purposes. You CALIBRATE in PFC.DLL. You MUST use the calibration facilities in the PFC dialogues. Everything you need to do is there. Please refer to the documentation supplied and follow the directions. If you select the Baron-style twin quadrant and calibrate there you will find everything works. Why? That quadrant seems pretty useful for the Baron. However, if you want to use the same sort of assignments for the prop pitch as on the Baron, but different ones for the other axes, just use one of the many free User Config sections and assign them yourself! You can make any mix of axes there. Calibrate them all, and mark it assigned to the current aircraft (when the Baron is loaded of course). You will find two types of Throttle, Prop and Mixture/conditioner controls you can assign -- one set has "reverse" or negative zones and the other hasn't. Please do look at the documentation some time! Regards Pete

Freezing? If, as they found out, you never told WideClient how to contact the Flight Sim PC (the Server), it would never have started at all, so how could it freeze? that doesn't make sense. The WideFS ZIP package comes with documentation. Please take a look at that some time. There's both a "DOC" and "PDF" version so it will be easy enough to open and rwad, or even print. The "info" I presume you need, so you can give it to WideClient, is the name of your Server. This is the name you gave it, the name it is seen as by other PCs on your Network. If you've no idea what you called it you can find out easily by looking for the file "WideServer.log" in your FS Modules folder (it will be there once you have run FS once with WideServer installed). Look in that file for the line near the top showing as, for example: Date (dmy): 21/07/05, Time 14:00:29.578: Server name is NEWLEFT Here the Server Name is actually "NEWLEFT", because that's what I called it. Yours will be different. If this is all still too difficult for you (though I assure you it is all a lot easier than flying an aircraft properly -- you just need to read some short documentation first, not many manuals) then please wait for a few weeks when I shall be releasing version 6.50 of WideFS, which has clients which find the Server for themselves. I have worked out how to do this recently from a new book -- but it can only be done if everything is running on Windows 2000 or Windows XP. Regards, Pete

It can't be done with FSUIPC, or anything of mine. You need WidevieW by Luciano Napolitano, http://www.wideview.it Pete

Sorry, neither VB.NET nor C# are any use to me. I would not know what to do with them. Don't you have a debugger with the compilers so you can find your errors? How do you manage else? It sounds like you are corrupting your own data areas. Trace it through, work out where it is going wrong. I provide as much in the way of tools as you should need to verify the FSUIPC part of this. If FSUIPC logs the values correctly or displays them on screen (using the monitor) correctly, and if FSInterrogate shows them correctly, then they are certainly correct --- and will give you something to compare with. I am very sorry, but I simply cannot undertake to develop and debug other folks programs as well as my own, and most certainly not in languages with which I am not familiar. Regards, Pete

The language DLLs are simply resources. You can read the strings using the Windows LoadString API with the appropriate module handle and string ID. You can use something like ResHacker (a freeware program) to obtain the string IDs you need. Check what you are reading against a well-known working program such as FSInterrogate, or simply use the real-time monitoring provided in FSUIPC (Logging options, right-hand side). You evidently have a bug which you will need to fix. I assume VB.NET and C# come with Debuggers just like the MSVC and C++ compilers? Regards, Pete

If you mean programmatically, you can find the FS process by finding the top level window with Class Name "FS98MAIN". So far, since FS98, all versions of FS use this as their main top level Class. The only way I can think of for identifying the labugage is to look at the DLLs in the main FS folder. Older versions used different names, like "English.fll", but now the different languages are obtained by different Language.dll's as you have said. Regards, Pete

You mean via WideFS, or are you talking about two completely separate installations of some Microsoft Flight simulator (FS98, 2000, 2002 or 2004)? Aha! 262145 is hex 00040001. It is too large a value for the 16 bit values you are reading -- the maximum 16 bit value is 65535. It sounds like you are reading 2 bytes into a 4 byte variable which you have not previously initialised to zero. The higher 16 bits will be unpredictable. This is an elementary programming error which you should easily find by the part of the programming process known as debugging. In any case, please use the tools provided to check things. FSUIPC has extensive logging and real-time Monitoring facilities (see the Logging page in the Options), and there's a program called FSInterrogate supplied in the SDK. These things are there to help you. ALWAYS but always check things against something separate, such as these, first. That's why I provide them. If you are not initialising values which you are only partially loading into you must expect them to vary considerably, as they will pick up any rubbish left in memory on that PC. That could happen on any PC, it just depends on what happened before. As I said, please use the tools you have to find out what you have done wrong. Even think of using the debugger which presumably comes with your compiler. If you really still need my help, I need more information, like logging results, actual version numbers, and even simple things like whether you are talking about a WideFS configuration, a version of FS or CFS, and actual version numbers of my own modules. Regards, Pete

That is not an FSUIPC function, except insofar as you Register WideFS via FSUIPC. FSUIPC is used by WideFS but it certainly does not have anything to do with any Network connections. What does the WideServer LOG say? It is the Server's Windows Sockets which is refusing the connection after all. Perhaps you haven't even remembered to install WideServer into FS2004? Regards, Pete

Yes, but we should discuss it when it exists I think! Hopefully you will get enough to cover your initial outlay for suvh things as a compiler and of course FSUIPC registration! ;-) Regards, Pete