Pete Dowson

Sorry. Actually I am almost the last person to ask, since I don't use MP. In fact I've never used it except for one experiment with it when it first appeared, back in, what, FS98 was it? Or FS2000? Can't even remember. There are others who pop in here who may know, though. Regards, Pete

Since version 3 of FSUIPC, programs need a key to access FSUIPC. This is freely provided to free programs like AFCAD, and in fact it is built into the latest version of AFCAD (for FS2004), but for the earlier version, which pre-dates FSUIPC 3, you have to enter the key manually. If you check the "sticky" thread near the top of this Forum, the one talking about Freeware Keys, you will find a 12-character key there for AFCAD. This is what you need. When you run FS, go into the FSUIPC options (via the Modules menu) and press the button near bottom right to register a program, then enter the program name (AFCAD) and the Key where shown. There's more explanation if you need it in the FSUIPC User Guide, which is provided in the FSUIPC Zip file in both PDF (Acrobat) and Word format. Regards, Pete

Okay. Two things about this. First, 512Kb was great for FS2002 but I think you'll find better performance with more memory -- and at present it is a pretty cheap upgrade, so well worthwhile. However, this depends on your Operating System, which you don't mention. You'd need Windows XP (or 2000). I think the "sweet spot" for FS alone is about 768Mb, but you are better off with 1Gb with other things (like WideServer, FSUIPC) running too. Second, I found WideFs ran best in FS2004 on my 2.4 Gb Pentium 4 with the frame rate limiter set at 25 or even 20. In fact I've now upgraded to a 3.2 Pentium and still have the limiter set to 20! This way I can have everything turned up max in FS and feed 4 WideClients smoothly at 20 fps too. FS stays at 19.9 fps most all the time (on my 2.4 GHz it dipped well below that now and then if I dared have all the settings to max). In other words, unless you have graphics and AI turned down I think 35 fps is still too high. But by all means experiment, see what you find. Your Server LOG shows no Netwrok problems, which makes me even more convinced it is just a performance bottleneck problem. Regards, Pete

Please read the Announcements at the top of this Forum, especially the ones about going Payware. Also, in the FSUIPC SDK (available on http://www.schiratti.com/dowson) there's an Access Registration document explaining more. If you are not interfacing any program to it, and not selling it as part of a product, then what there is left of it is 'free' -- user's cannot access most of the facilities unless it is registered in any case, and only Freeware programs with free access keys, and commercial programs with purchased access keys, can interface to it. For any other commercial arrangement you need to read the documents and contact me on petedowson@btconnect.com. Regards, Pete

No. CFS3 is a closed program. There is no way to add more modules. CFS1 and CFS2 were based on the FS design, so some parts of FSUIPC (and my other modules) did work on those, but CFS3 took a completely different dead-end direction and is as closed up as most 'games'. Regards, Pete

It is possibly a performance problem. It looks like the Server is not responding fast enough so messages from clients are piling up. How many clients do you have? What is the processor where FS + WideServer is running? What is your FS frame rate limiter set to? What is the Network - 10 or 100 Mbps, and is it via a hub or switch? A look at the WideServer.log may help too. Anyways, try, as an experiment, severely reducing your FS frame rate limit. If this helps, then the problem is that WideServer is not getting enough FS PC time to meet all the demans from the clients whilst also trying to send stuff out at FS's frame rates. You may find a "sweet spot" that suits your set up. There are some parameters to limit the Server actions so it doesn't send so much out, but in general it is better to achieve a balance without using those. Regards, Pete

Well, for recording I can see there are controls "DEMO_RECORD_1_SEC", "DEMO_RECORD_5_SEC", and "DEMO_STOP", but I don't see anything off-hand to start a playback, so I think maybe it isn't possible. As described in the WideFS documentation, keypresses on a Client, if received by WideClient (i.e. it must have keyboard focus), can be relayed to FS by setting "SendKeyPresses=Yes", but you cannot access Menus this way as that needs the ALT key. If you are writing a program with an FSUIPC interface, then key presses can be sent via offset 3200, and controls via 3110 (see the FSUIPC SDK). But, again, accessing the menu this way can be problematic because as soon as the Menu opens, FSUIPC is no longer running and so cannot send more keys. Regards, Pete

All the details are in the FSUIPC SDK, in the documentation about access registration. Also please see the "Sticky" message about Freeware Keys, above, which gives the email address for your application. Thanks, Pete

I don't think there is one. At least I've never found it. The gauge seems to be mouse driven only. Just badly written. Maybe there's a third party one around (probably in a third party panel) that obeys the controlled selection and hasn't got it purely internally coded as that one seems to. The one in the Cessna's main panel obeys the "TOGGLE DME" control, like the radio stack, but I don't see the "DME", "DME1 TOGGLE" or "DME2 TOGGLE" controls doing anything in either. Regards, Pete

With crosswinds too, please. Well, I might detect FS2004 and read the FS GPS "track" value if possible, as I'm concerned that variable winds and turbukence will make a right mess of it! Tomorrow. Regards, Pete

With crosswinds too, please. Well, I might detect FS2004 and read the FS GPS "track" value if possible, as I'm concerned that variable winds and turbukence will make a right mess of it! Tomorrow. Regards, Pete

It cannot see commands given on the keyboard. they are not actioned by FS sending a message with the control numbers I recognise. They operate through some keyboard table some place. Whilst I could intercept keypresses I do not have access to the table so I don't know which should do what. besides, I've never has a need to do it. In the case of Gauges it is different. I do see "trigger_key_events", so if the gauge uses one of the FS controls I know, I will deal with it (if asked to, of course). I expect all that is happening is that the regularly-polled input from the axis is overriding the key press. Or maybe it is more serious, but I couldn't say from experiments I'm afraid. What "non-proportional" brake commands are you using from a gauge? If you used the AXIS_LEFT_BRAKE_SET and AXIS_RIGHT_BRAKE_SET controls (the ones used by FS2002 and FS2004 for brake axes), then I should think these would be okay. You could experiment with those by assignment with different parameter values in FSUIPC's Key or Buttons pages. No, not at all. It changes the braking pressure directly, inside SIM1.SIM or SIM1.DLL, where it actually has effect. It is not sending any controls to anything. It is direct maniplation. It was the only way on FS2000 -- there were no controls whatsoever providing any proportional effect, though internally the simulation did have the implementation of braking pressure, as you could see by its gradual reduction on release, or increased effect when "pumped". Since when using FSUIPC for proportional braking the axes aren't really connected to FS, I assume it won't occur, but I've not tried it. Not sure why. Isn't it for the same reason? Q1. Yes as far as your (1) is concerned, and I don't see that (3) is different. Q2. Well, not really, you would expect folks to either use axes or use keypad. If I were writing a simulator I'd choose axes over keypad, if I knew it was operable. I'm not sure how you'd deal with conflicts between them. This is one way I suppose. Q3. I can't deal with FS keyboard controls, and I've no idea what you are doing inside your Gauge. But if you wanted you could make your gauge control brakes via FSUIPC offsets instead of FS controls. Then it shouldn't interfere with any other FS functions. Well, I did apologise, and as I explained, I use it without thinking as I have done for 40 years or more. It is like any habit, difficult to break. I suppose if I said "+ve" you'd recognise the "+" as meaning positive, no? The problem is that the ASCII negative (-) is too short and used as a hyphen. I really cannot promise never to use it again just in case my recipient isn't so good at English, but I do apologise. I don't see what else I can do. And your English seemed so good! :) Maybe if your English was bad I'd have spelled everything out and used easier words in any case. Sorry again. :? Pete

Okay. If it is permanent fixed to magnetic, I'll change to that. Odd. I'll try to simulate something here. It's a bit awkward not having a device, I may have to write a little program to display things. I'm using the "ambient wind" value, which will change as you fly, especially if you have variable winds or turbulence set. But otherwise it shouldn't, as the same steady wind will be making me do the same calculations over and over. Strange. I'll see what I can find. Well, it's a lot more programming -- currently it's pretty much a single line of code to format the data I already have (for NMEA sentences) into the Aviation format. In FS2004 I can get the actual Track value your FS GPS displays. I didn't really want to make GPSout FS-version dependent, but I certainly could use the value to find out what's going on. Okay. Since I'm rather tied up today, I may send you a version which just provides Magnetic instead of True, and let you try that and report. If I have to mess with Track I'll look at that tomorrow. Okay? Pete

No. Use FS assignments to configure your separate throttles for each engine, then use FSUIPC's Joysticks section to calibrate the throttles with a centre (or more usually off-centre) position for Idle. Allow enough "dead space" for idle (and preferably notch it on your quadrant). Reverse will operate when you pul back further. In general allow about 20% of the movement for the reverse section -- the reverse thrust component varies frpm aircraft to aircraft, but is generally up to 25% of the full thrust amount. Regards, Pete

I am trying to compute Track, I'm not providing Heading. To do this I'm using the ambient wind values. I already do this for (for instance) FliteMap, and it seems to get the right values. Are you saying this isn't working in this format? It's the same Track figure as sent to FliteMap and others. The "HDG on screen" on the aircraft instruments is Magnetic, so you were facing Magnetic North, right, not True North (as you would be, for instance, in slew mode after pressing Space)? The MagVar in Seattle is, what, 20 East? Right? So 360 MAG = 20 TRUE. So the value of 20 shown on your GPS is correct if it is supposed to be showing TRUE rather than MAG. On my Garmin this is a user option -- many folks use TRUE (I do) because it helps with Maps -- usually Grid lines or somesuch are aligned with true north, NOT magnetic. Before I do any changes here you need to check things like that. You can't just assume them. But please also check it again with winds. It should give correct track too, maybe not accurately (the only real accurate way is to compute from successive coordinates, whch is what a GPS does). Sorry, you'll need to be MUCH more explicit there. When you say "offset slightly" what do you mean? What is "slightly". I am sending the position FS uses to 1/100th of a minute accuracy. That's all the protocol allows. I've no idea what you mean about confusion. It gets sent explicit Latitudes and Longitudes. there's nothing in those which will be modified by track, groundspeed or magnetic variation. Pete

No, no. That wasn't the problem. It wasn't anything to do with the attachment. The message went into my "OutBox" and stayed there, never moving to "Sent". When checking this I found TWO other messages, to the same person, still in the OutBox, one dating from a week ago! The second message was an answer to almost a repeat of the first, presumably because the author never got the reply. Those two mesages are STILL there, but the one to you has gone. I don't know what is going on. I've put some queries out to the Simflight operators, but I think they are all at Miguel and Andrea's wedding today! :D Ahthere's lucky, eh? :) The main thing I need you to check is the Track degrees. I've assume degrees TRUE, but they may need to be MAGNETIC. The doc doesn't say. Please try it in a region of large MagVar (eg. Seattle E 20 degrees MagVar) and let me know. Regards, Pete

Tuomas, please email me at petedowson@btconnect.com. I have a test version of GPSout for you to try, with "Series 400 Aviation" format support, as best as I understand it at present. I tried to send it via the private mail service here, to no avail I'm afraid -- I'm getting some messages stuck in my "OutBox" and not getting sent. I've no idea why. I've asked Admin here but not got a reply yet. Regards, Pete

Check with Enrico Schiratti at Project Magenta. He is in charge of Keys for PM. I think he provides time-limited Keys for demos, but I am not sure, you'll need to ask. Regards, Pete

Thanks for solving it without me! :D I will consider adding a check for this into the next version of FSUIPC. Regards, Pete

Goodthanks for letting me know! Regards, Pete

There is really nothing in any of the FS control mechanisms which will do this sort of thing. They are completely ignorant of altitude. Are you sure what you are seeing is not simple over-control due to poor responsiveness? If so then it is the performance of FS near ground which is the problem. Any slowness in responses to inputs can look like over-sensitivity because to tend to over-control when you see that your alterations appear to have no effect. If this is the problem, then I think your only recourse is a faster PC or reduction in some of FS's settings. Climbing away from the performance problems of ground and airport details. Regards, Pete

All the FS controls in CONTROLS.DLL are listed in both numeric and name order in my controls documents, on http://www.schiratti.com/dowson. There's one there for FS2004. That's the same list accessible for Key or Button assignment in FSUIPC's Key and Button assignment pages. "-ve" = negative. Sorry, I thought it was a standard abbreviation. I've been using it since I was a tot! Regards, Pete

Okay. Thanks for letting me know. Good luck! Regards, Pete

I think those values should be -16383 to +16383, but 16000 is close enough I suspect :D There are two sets of Throttle axis controls, one running 0 to 16383, and ones running -16383 to +16383. Both have idle at "0" but the ones with -ve ranges provide reverse thrust too -- these are made use of in the separate throttle assignments in FSUIPC. No problem! Glad you got it sorted. Regards, Pete

Apart from "type", what other measures? There was in FS2002, but you said you were using FS2004. It runs here without FSUIPC, but by all means install it as a test. Let me know. There's a serial port monitor, I'm sure, on http://www.systeminternals.com. Try that and let me know. Regards, Pete