Pete Dowson

Er7D4 certainly isn't "Ground Altitude", it is the altitude set in the autopilot. Please refer to the Programmer's Guide in the SDK. Furthermore: What is that about? You are reading a 32 bit value which, as it states in the document, is 65536 x the number of metres (entered into the A/P). Comparing it with 32767 doesn't do much (32768 = half a metre). And multiplying it by 3.2 .. etc doesn't give you feet unless you also divide by 65536. Regards, Pete

All the details for these things are in the Programmer's Guide in the FSUIPC SDK (http://www.schiratti.com/dowson) -- look through the table inside that document. Regards Pete

Thanks! I'm glad it is all working well for you! Regards, Pete

So far almost 100% of such cases have been down to finger trouble. All three parts (name, email and key) MUST be exactly as specified in the notification. Cut and Paste if you aren't sure how to do that. Try again. If you still get problems come back and I'll tell you what to do. There is a very remote possibility that the suppliers made a mistake. Regards, Pete

In FS the fuel cut-off lever for jets is actually the same as the mixture lever. Try assigning "Mixture Lean" for cut-off and "Mixture Rich" to enable fuel. If you have enough buttons you'll also find separate ones for each engine. Pete

Aha! There won't be a port called "1" -- that needs to be "COM1" or similar. You have the parameter set incorrectly in the [GPSout] section of WideServer.INI -- it needs to be Port= not a port 'number' -- the parameters are simply the same ones that a direct GPSout-to-COM would have. It is actually a little unlikely that your Notebook doesn't have some devices using COM port numbers up. On my Toshiba Qosmio (with no actual COM ports at all) there are a set of 10 COM ports listed called "Toshiba BT Port" which are, I think, virtual ports created for use by the built-in Modem. They are COM10 to COM19. And, yes, it is possible for a firewire port to have a driver with a virtual COM port too, though I don't think this is a regular thing. That freeware MixW port-pair driver I supply does need to be given free ports to operate with, and it doesn't seem to check. Best to find a pair otherwise not allocated -- you can find out by Settings - Control Panel - System - Device Manager, Ports(COM & LPT). However, the most likely problem in your case was simply that you put "Port=1" instead of "Port=COM1". I've always used port names not numbers -- and it has come in useful, because some folks have found ways of using USB ports by referring to a USB device name instead. If you could try again and let me know how you get on I'd be grateful. I also tried a Network Serial Port Kit (by Fabula Tech), and actually bought a license for it, and whilst it works well for some hardware (PFC serial connected) that I wanted to be able to test from a different PC, I found it wasn't reliable enough to stop FliteMap timing out the GPSout connection sometimes. When I checked what was going on it seemed to go through periods when it piled up the GPSout transmissions and release them all in one big bundle. I reported the problem to them and they are investigating. However, it was after that I decided to try to devise my own system, which I've been using here ever since. I was even going to write a virtual port driver, but found that freeware one instead. Oh, BTW, after assigning the pair of ports in the MixW program, I found you had to re-boot the system. Unusual these days, but it didn't work till I did. However, once installed it seems to work well and invisibly with no attention needed. Regards, Pete

This is rather a confused question. You are actually mixing up two completely different things. Flightplans FROM Flitemap are nothing to do with GPSout -- GPSout is an FS module which makes FS look like a GPS to Flitemap -- in other words it is OUT from FS and IN to Flitemap, not the other way round! Getting stuff out of FliteMap for use in FS and FS add-ons in what I wrote FStarRC for -- that produces .APL plans for Radar Contact, .sbp plans for Squawbox and Project Magenta, and .PLN plans for FS. Regards, Pete

That's interesting, because I am using it all the time here. Can you tell me more, please? After all, the purpose of Beta releases is to gain feedback. if it didn't work for you I'd like to understand why. Please tell me exactly what you did and what happened. Regards, Pete

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