Pete Dowson

I will check, but I need to know what PTT programming you have in your FSUIPC, please -- possibly let me see the [buttons] section of your FSUIPC.INI file? [LATER] Don't bother, I *think* I've spotted it. Silly error -- looks like the codes I send are inverted. That's the trouble with making facilities for programs I don't actually use myself! Please try the attached revised Beta 3.499. Let me know and if it is now okay I'll replace the one in the announcement up top. Incidentally, it is a real relief to get, at last, a problem report back on one of the Beta releases -- it is always worrying when you get absolutely nothing! It seems to imply no one is actually using them, they're so bad! ;-) Regards, Pete FSUIPC3499test.zip

Not at all, glad it is all ok. Pete

No, sorry. I don't even have any details of FS's video format. Is that what ".fsr"s are? Pete

Or show their contents in the message if they aren't very long. Since you aren't getting a connection they shouldn't be very long at all. But wait. Just clarify something for me please. Upon re-reading your original report I don't actually see any description of a problem. You simply showed a portion of a log without saying why. I perhaps wrongly assumed that nothing then happened The log you showed for WideClient was: Now, I assume those "****** ..." at the end yours -- because WideClient always logs when it is being terminated? For example, here is a complete log from a Wideclient which was just left waiting for nearly 10 minutes with no FS running on its Server: ********* WideClient Log [version 6.47] Class=FS98MAIN ********* Date (dmy): 29/07/05, Time 18:33:04.608: Client name is MYQOSMIO 290 Attempting to connect now 300 Trying TCP/IP host "newleft" port 8002 ... 300Okay, IP Address = 192.168.0.223 1232 Error on client pre-Connection Select() [Error=10061] Connection refused 1232 Ready to try connection again 1272 Attempting to connect now 6479 New Client Application: "pmsystems" (Id=792) 560396 ****** End of session performance summary ****** 560396 Total time connected = 0 seconds 560396 Reception maximum: 0 frames/sec, 0 bytes/sec 560396 Transmission maximum: 0 frames/sec, 0 bytes/sec 560396 Max receive buffer = 0, Max send depth = 0, Send frames lost = 0 560396 **************** Individual client application activity **************** 560396 Client 792 requests: 947 (Ave 947/sec), Data: 1619559 bytes (1619559/sec), Average 1710 bytes/Process 560396 ********* Log file closed (Buffers: MaxUsed 1, Alloc 947 Freed 947 Refused 0) ********* See? Your log is just a normal start when WideClient is run before FS is ready to fly. The missing bit is the log of the server name and IP address found for it, but I think that is only because you specify the IP address so WideClient doesn't need to ask windows for it. So, how long did you wait before terminating? What was FS showing? Was FS running on the FS PC before you ran WideClient? The error "Connection refused" is quite normal to see if WideClient is run before FS and WideServer is ready, as the service isn't available for the connection to be made. The service only starts when FS is ready to fly. Wideclient will keep retrying, as it actually says in the Log fragment. Please look at FS's title bar when FS is running (you'll need to go into Windowed mode for this, ALT + ENTER). Does it say it is waiting for clients? Regards Pete

Thank you, but can you please show me the INI files for both WideServer and WideClient and also the logs for both. I cannot debug your setup in a vacuum. Please provide as much information as you can. I am still not seeing enough to verify the correct setup! Note that it is not necessary to supply both ServerName and the IP Address. If the latter is provided the former is ignored, so the IP address had better be correct. In general it is much easier just to give the name. Check also that you have no firewall stopping the client getting to the server. That would most likely result in "connection refused" by Windows. Also check all the other hints in the documentation. Regards, Pete

Have you told Wideclient what the name of the Server is? Where's the WideClient.ini file please? And the WideServer.Log file? Also, check the Beta releases available in the top announcement here. It includes a trial version of WideFS which finds the Server automatically. This is really to try to cope with users who don't (can't be bothered to?) read the documentation supplied, but it may help you too. Regards, Pete

If you have no "mapping" (from one throttle to the others) selected, it is only when throttle sync is selected that FSUIPC will attempt to copy the throttle 1 values to the others, when they are in range. I explained what I thought might be happening in the 767 code in my last message. You have not narrowed it down any further I'm afraid. If the 767 code is as I suggested it might be then I'm afraid you will not be able to use FSUIPC's throttle sync with that particular aircraft. This is why I suggested finding and fixing the root of the problem -- i.e. the inequality of the throttles. Regards Pete

Well, SimMarket could sort it for you (just file a problem ticket and explain), but now you've raised it here, just send the full details of both registrations (cut and paste from the original emails if possible), and send them to me at petedowson@btconnect.com. I'll send you a new FSUIPC registration to match the WideFS one. But unfortunately it will be tomorrow morning now, it is late here and I'm off to bed. Sorry. Regards, Pete

First make sure you update to FS9.1. The changes MS made fixed a large number of crash causes. Then it's a process of elimination. Something you are doing with FS9, or have added to FS9, is responsible -- assuming of course that there's nothing else in your PC which is responsible. You'll need to try it without one thing at a time. I really cannot hazard any guesses as to what the reason might be with the almost zero information you provide here. Of course, the first clue lies in the crash data that Windows should give you. A crash in G2D or G3D will likely be a scenery or video card/driver problem, in ATC or Traffic a traffic file problem, and so on. You should also always provide version numbers (FSUIPC, WideFS, FS, etc) when asking for any support for my programs. If you are not using the latest releases, try those first. Regards, Pete

No, I do not know that one. No. That gauge is called F16.gau. The names need to match. Maybe you can find F16.gau and substitute it, or, better, look for a TCAS gauge which has its keys built in for automatic access -- I think the Lee Hetherington ones do (ILH_TCAS or something like that?).

Version 3.45 is pretty old now and not supported. Please go to http://www.schiratti.com/dowson and get the current user release, 3.48. There's a list of supported versions near the top of this Forum. It doesn't say FSUIPC is not accredited. Read what it actually says -- "one or more programs you are using is not accredited". See the difference? And the only thing which will "refuse to run" is the TCAS in this panel. It isn't FSUIPC that is licensed, it is the PMDG aircraft which is licensed to use an unregistered copy of FSUIPC. As with the message you showed, you have it back to front. Yes, it is okay for PMDG aircraft, and some other payware aircraft who have licensed use of FSUIPC. It isn't okay for other unlicensed payware. For much freeware there are free access keys, either built in (in which case you wouldn't get the problem), or which you have to enter yourself (for old unsupported gauges such as those from Eric Marciano -- possibly your 757 is using one of those). This is why I provide a list of Freeware keys in this forum. Go look, above. To find the name of the gauge which needs a key look inside the FSUIPC LOG file (in the FS modules folder) after you get the error. If you never want any such error reports again consider paying for a user registration for FSUIPC. This bypasses all these accreditation checks and also gives you a large number of useful facilities. Check the FSUIPC user documentation in the ZIP when you download the 3.48 update. Regards, Pete

Have you checked all the information about the CH throttle quadrant? Look at http://www.ch-hangar.com. Bob Church has written some hints for setting the device up properly (CMNote02.zip or similar). This is FSUIPC's throttle sync? All this does is copy values from one axis to the others. Probably the 767 code is reading the axes directly too and so this is providing dual inputs which are different? I really can't think of anything else which might affect it so. And there really isn't any other way I know of to send FS the same axis values. One of the problems with these sort of intercepts in FS is that the last-loaded program performing the same intercept will be the first one to actually receive the information and deal with it. If the 767 is doing this in one of its Gauges, then it will have intercepted FS messages later than FSUIPC. Hence it processes the Axis messages before FSUIPC sees them. The sync works by FSUIPC checking the subservient axes (#2 in this case) are within range of the controlling one (#1) and if so, discarding the subservient one (not passing it through) whenever it arrives and sending a new one with #1's axis value. This may be being picked up by the 767 code and seen as a throttle variation, though I don't understand what throttle variations have to do with the A/P -- they may trigger an over-sensitive A/T cutout, that's all. If the Level D team cannot work out why this is happening (and as I say, it doesn't appear logical that throttle things interfere with A/P engagement -- A/T, yes, perhaps), then I think you should try to sort out the original prtoblem -- i.e. get the throttles stable and levelled. Maybe better calibration OR use of one of the other of the CH control manager and FSUIPC will do it. See if there's help that way on Bob Church's site. I think that really it would be better to sort out the real problem anyway. The sync option was originally provided for twin props and turboprops where throttle differences cam be more critical, causing a sort of gyrating flight pattern (wiggling throgh the air). Regards, Pete

Okay, so the full story that plus: L7.1=!C11 XBF4 U16 !=0 Ff10off ;Left Gear Moving L7.2=XBF4 U16 =16383 ;Left Gear Down I'm not clear on the choice of "Ff10off" for the flashing. There's a bit of a conflict likely there and I'm not sure how it might resolve. Ff10off says "flash fast for 10 seconds then turn it off". This 10 seconds STARTS when the conditions first become true. The behaviour is then independent of the actual gear motion, which is a strange thing to want. Why did you want this fixed 10 seconds? Why not have it flash whilst the gear is in motion, and leave it at that? Try using Ffast instead of Ff10off. You shouldn't need a time on it -- FS dictates the time for the gear to raise or lower. Regards, Pete

I'm not sure why they wouldn't -- their job is to make a simulator which works out of the box, not a kit of parts for the minority of "real cockpit" builders. They use the techniques which work best for what they need to do. There are very few programs which one can get into and almost tear apart as much as FS, so at least we should be thankful about that. Look at the horrible monolithic design of CFS3 if you want something really unusable from this point of view -- unlike CFS1 and 2 it wasn't based on FS designs, and I got a real fright that FS2004 was going the same way! It may be too late to suggest things for the next version, but write to tell_fs@microsoft.com in any case. Each voice counts. Regards, Pete

Not offhand. what is Condition 11 in your code? Pete

Well, it might be if it could be found. Back in FS2000 days the aircraft wizard Ian Donohoe found loads of stuff -- still mapped (the accelerations and velocities in all six axes, for example). I'm sure he'd know where to look if he was still doing this stuff. It may actually be easier to find in FS98 or FS2000 and then track through FS2002 and FS2004 in the hope that the changes each time are not wholesale. Starting at this end is almost impossible, because the data has become encapsulated in layers of C++ classes and hierarchies. It's all indirect pointers based on class pointers passed in registers, and gets almost impossible to follow. It's an enormously time consuming job, likely many hundreds of hours, and may be fruitless after all. I really can't undertake such things except in areas where I really have to (like the weather, which was a pig to sort out in FS2004). For slowing flap deployment down, assuming you are simulating an aircraft where you can't hear the flap motors from the cockpit in any case, (as in my 737NG), and you don't need to actually see what they are doing, I guess one way to simulate a slow down would be to pulse the changes with short bursts of interleaved reverse movements. i.e. going from 25 to 30, say, set 30, then 25 briefly, then 30 again, and so on, ending with 30. Adjust the times of each change to increase the time in the proportion you want. Sounds daft and looks daft, but in the cockpit you might only notice the longer time to deploy. Regards, Pete

As with many sub-systems and failures, I think the way to simulate such failures is by working out the affect they have and creating that, not the failure itself. For a real in-cockpit simulation, the external look of things (i.e. the aircraft body parts themselves) shouldn't really be the main consideration -- I rarely if ever get out and look -- the screen is outside the front cockpit windows and it seems 'wrong' to look at your own aircraft from there. So, what you need to consider is what is the effect of such a failure, and cause that to happen. Interfere with the aircraft performance in some way, and so on. Likewise, the actual indications of where gear or flaps are, when shown by, say, Project Magenta, could presumably be interfered with too. I've not got into really simulating failures much yet, just dabbling on the edge -- like the failure of reversers to deploy when there's a problem with hydraulics, or the possibility of a flame-out in heavy rain/snow unless the engine iginition is set to "continuous". Those things which Thomas and others have been adding to the pmSystems files for the 737NG. I really don't know exactly what is possible that way, but it certainly seems a lot more likely that you'd get some results by going down that sort of path. Regards, Pete

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