Pete Dowson

Personally, I don't think it is possible. With Flaps the detentes and their affect on the simulation are defined in the Aircraft.CFG file as you can easily check. I suspect FS uses those figures as they are and doesn't try interpolating between them. With gear, whilst the motion up and down is tracked, I don't know of any way of stopping it in between.

Controls are the things you assign to buttons and keys in FS. Every FS user surely need to know a bit about them, let alone someone designing hardware to interface with it. In FS go to the Options menu -- you will see an item called "Controls". Select that and you will find you can make Assignments, change Sensitivities, and so on. In my list of FS2004 controls I merely equate the name of each known FS2004 control with the numerical representaion FS assigns internally. The term "offsets" used in the FSUIPC interface is not at all related, and I really don't understand how such a confusion could arise. The only reason they are called "offsets" is that the interface provided derives from FS's own mapping of its assorted variables in an FS module called GLOBALS.DLL. This is way back in FS95 and FS98. The term "offset" was the difference between the position of a variable in that DLL and the start of the data itself -- the "offset" of one memory address from another. The FSUIPC interface derived from another program in FS95 and FSS98 days (FS5IPC and FS6IPC respectively, 5=FS95, 6=FS98). Then the offsets were changing in each FS release. I decided with FSUIPC (U=Universal) to keep to those known in FS98 so that all the interfacing programs wouldn't need changing for each new FS release. These days, though there still is a GLOBALS.DLL, it contains very little of the huge amount of data FSUIPC gives access to. The "offsets" no longer mean what they used to mean. You should merely think of them as Identifiers or Tokens for what they are documented as containing. FSUIPC is presenting a "virtual" memory map which doesn't really exist as such any more. Now please go look up offset 3110 in the Programmer's document in the FSUIPC SDK. I'm sure if you had done so in the first place you would not have been so 'confused'. Regards, Pete

In that case shouldn't you have shown what it is you've tried? Yes, the examples supplied and documented -- there's loads of examples. In fact there are more examples of multiple lines for Displays and LEDs that there are for single lines in the form you show above. Please take another look. Regards, Pete

I din't know of any. why would you need them? They are just numbers you write. FS does the rest. Groan! I told you the offset -- 3110. there's only that one. What's all this about conversions? :-( The CONTROL NUMBERS are CONTROL NUMBERS -- they are the numerical representation of the controls you can assign in FS (independently of FSUIPC). They are an FS invention and the control system they represent has been around since FS5 days at least. They are absolutely nothing whatsoever to do with "offsets". Just write a control number to offset 3110, as it says in the documentation. Please look it up. Pete

There's no such offsets that I know of. Buttons aren't "values", but are either local to the gauge (i.e. defined as specific hot spots), or have FS controls assigned to them as well, in which can you can program them on keyboard or joystick buttons. did you look through the list of FS controls I published with FSUIPC? There seems to be a heap of them, thus: GPS_ACTIVATE_BUTTON 66614 GPS_BUTTON1 66629 GPS_BUTTON2 66630 GPS_BUTTON3 66631 GPS_BUTTON4 66632 GPS_BUTTON5 66633 GPS_CLEAR_ALL_BUTTON 66620 GPS_CLEAR_BUTTON 66619 GPS_CLEAR_BUTTON_DOWN 66621 GPS_CLEAR_BUTTON_UP 66622 GPS_CURSOR_BUTTON 66624 GPS_DIRECTTO_BUTTON 66617 GPS_ENTER_BUTTON 66623 GPS_FLIGHTPLAN_BUTTON 66609 GPS_GROUP_KNOB_DEC 66626 GPS_GROUP_KNOB_INC 66625 GPS_MENU_BUTTON 66618 GPS_MSG_BUTTON 66606 GPS_MSG_BUTTON_DOWN 66607 GPS_MSG_BUTTON_UP 66608 GPS_NEAREST_BUTTON 66604 GPS_OBS_BUTTON 66605 GPS_PAGE_KNOB_DEC 66628 GPS_PAGE_KNOB_INC 66627 GPS_POWER_BUTTON 66602 GPS_PROCEDURE_BUTTON 66612 GPS_SETUP_BUTTON 66613 GPS_TERRAIN_BUTTON 66611 GPS_VNAV_BUTTON 66610 GPS_ZOOMIN_BUTTON 66615 GPS_ZOOMOUT_BUTTON 66616 I don't have any idea what they do or if they work, but you can certainly program them via FSUIPC's Keys or Buttons options to see. If you want to operate the FS GPS from a program you can send FS controls via offset 3110. Regards, Pete

What are these "GPS offsets" you want? There's an area which contains data from the FS GPS at 6000 onwards, but I assume that stuff isn't relevant to you? GPS's detect and show stuff like latitude/longitude/altitude/speed and direction. You have all those. What else is it you need? You will have to be more explicit. There won't be anything about satellite positions and signals in FS -- it does not simulate the GPS satellite system. You will have to "pretend" that you are getting data from satellites. Pete

You need to say what offset you are using to read things as they are not all unique and in any case it easier for me to look up by offset. The indicated airspeed is at 02BC as a 32-bit integer (i.e., yes, 4 bytes), and is stored with 7 bits of fraction -- hence the * 128. In other words, you do not MULTIPLY by 128 to get knots, you divide. If you want it to the nearest knot add 64 first. If you want to retain fractional values, copy the integer to a floating point value first then divide. Please please use the tools provided to show you these things -- FSInterrogate is excellent for showing the vlaues you get in real time and also the actual calculations used to convert them. This is why it is provided in the SDK. In general the documentation shows you the UNITS in which these things are stored , NOT the formula to convert them. You have it inverted. There are exceptions -- there was so much confusion about how FS stores its Latitudes and Longitudes that I had to re-describe them in terms of conversions. But I don't think many folks have misunderstood the simple stuff. Regards, Pete

The PFC hardware and my driver know nothing about what you are flying or whether you are having lessons, so there is nothing different at all that either can be doing. I'm afraid you need to look elsewhere, for instance, possibly your flying technique isn't quite up to Rod's standards yet? ;-) Either way I'm afraid you will need to give me more information about what your problems are. You don't describe them at all. But first I would ask you to update to versions of my software which are supported. Version 1.844 of the PFC driver is very much out of date and cannot be supported at all. The current supported release is 1.92 (since March) as listed in the List of current supported versions above. You could also try version 1.945 which was released for Beta testing yesterday (see the very first Announcement in this Forum). Please also make sure you are using the current or Beta version of FSUIPC (3.48 or later). Regards, Pete

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