Pete Dowson

Do you use separate axes for each engine for all three -- throttle, prop, and mixture? If so then I really have no idea how copying the engine 1 inputs to the other engine can cause anything whatsoever to stall. However, if you use, say, twin throttles, but a common prop pitch and/or mixture axis for both engines, then possibly my "Sync" is those FS controls into the others resulting in different scaling. There again, though, it should only be Engines 2-4 which would be affected. There's really no way I am touching Engine 1, that's just the source. I am indeed at a complete loss as to what is going on then. Are you sure it isn't some coincidence of something else happening? But, again, it makes no difference to Engine 1, so nothing I do will prevent that failing! In that case, since FS already has a Prop Sync control, I might as well take all this new code out and be done. :( Regards, Pete

Sorry, it is an area which I never studied. I took a quick glance at the NetPipes SDK when it first appeared, to see if had anything to make things easier for my implementations, found it didn't so put it aside. Regards, Pete

I don't really think that's a good idea. When using it as a speed brake you want to know that one press of the button will give a similar adjustment no matter where. You already have this in FS. Just ARM the spoilers. You also already have a spoler toggel for full up/down. Regards, Pete

No, the last question which I tried to answer was to do with the Prop Sync and Throttle/Proc/Mix Sync facility I included in PFC 172 also. It seems I didn't cater for all possibilities of configuration -- such as when an axis hasn't been previously used to set prop or mixture/conditioning. Good! thanks for letting me know! Regards, Pete

The only problem I know about (and I will address this) is that the facility copies the last INPUT values for Engine 1 to the other engines. This applies to throttle, prop and mixure/conditioner. It sounds like you made no input to the mixture/conditioner, so the internal value for that was zero. Do you think this could be the case? Mind you, I'm not sure why only Engine 1 died. They all should I think. I had assumed, of course, that inputs for all three components would apply every time. But I already had a message from Bob Scott who apparently adjusts the mix/condition on the FS panel with a mouse, so I never see the input, and so set zero. The answer is for me to READ the current prop and mixture settings from FS and apply those to the the other engines. Then even if there has been no axis input it should be okay. He also asks for the FS Prop Sync control to ONLY operate prop sync, not also throttle and mox. So I would ned to separate the two functions I've implemented. What do you think? Regards, Pete

You need the FSUIPC SDK. Get that from http://www.schiratti.com/dowson. All the details and tools are included there. Regards, Pete

Yes, of course. That's exactly what I understood. But that "rolling" is by repeat action -- with keyboards it is at the keyboard repeat rate. With buttons in FSUIPC you have to switch on the repeating, then it is dependent a bit on frame rate, but will generally be similar. The point is, however, that the individual press is an individual increment. For example, if it takes 32 presses to go the whole distance, and the repeat rate is 10 per second, then it will take 3.2 seconds to fully deploy or fully retract. Setting the increment to something useful was my question. Try an experiment. Assign a button to throttle inc/dec and see how many presses it takes to go from idle to full throttle. Now time how long it takes when you just hold it on (so that the button repeats). Is that how you want the spoiler control to work? Faster? Slower? Let me know the number of steps you think would (a) be fast enough, yet (b) still have enough resolution for your needs. Regards, Pete

Only trouble with paused mode would be if you wanted the time to match -- or can you update the time in paused mode without the Sim doing any stupid things like reloading scenery/textures? Now that's unexpected, and quite a bonus! Is this new in FS2004, because I thought the airspeed readout itself was one of the problems in FS2002? Thanks, Pete

As documented in the FSUIPC SDK, you can set LLAPBH (Latitude, Longitude, Altitude, Pitch, Bank, Heading). In FS2002 and before the PBH could only be set in Pause, Slew, or zero-simulation rate modes. In FS2004 all six aspects can be set even in flight mode. Whether this can result in a smoother and more "realistic" flight than the video method, I really have no idea. I don't know anyone who has done any comparisons. One this I know can't be done through FSUIPC, and that is controlling the airspeed directly. Maybe that's a deciding factor. There is a third way, of course, and that is using the multiplayer interface to feed in the flight of another aircraft, and have the user's FS set in MP "observer" mode rather than in his own aircraft. If it is the visual path you want, then the facilities available in FSUIPC will do all that. Whether you use Slew mode or not would need to be a choice based on what you find, but as documented in the FSUIPC SDK you can switch that on and off through the interface. I would not keep changing the time in FS, however. This could cause nasty pauses whilst things redraw. Best to set the start time (both Local and UTC or Zulu) then let FS update its time naturally with you keeping pace with the inputs. For smoothness you'll want to interpolate values between your GPS readouts which are probably rather infrequent. Aim at at least 10 frames per second, ideally around 20. (18 corresponds to Windows "tick" time of 55 mSecs, so would be useful). Interpolation of Lat/Lon/Alt would be easier if you have the Ground Speed and Track values as well, but you would not be using either of those directly in FS. Regards, Pete

Okay, I'll fix it and send you another Beta. Pete

Flaps have detentes, special positions where they stop, which is why INC/DEC type parameters suit them. Spoilers are continuous, so FS doesn't provide an INC/DEC for them. It would be easy enough for me to add a couple of "pseudo" FS commands to FSUIPC's Keys and Buttons pages. It isn't on my list at present because no one's ever asked for this, but I'll add it now. The only thing I'm not clear on is the increment value. How many steps would you think appropriate between Spoilers fully raised, and spoilers down, off? I can make it configurable in the INI but it is always best if there's a good default. Perhaps 32 steps, or maybe only 16? What do you think. Regards, Pete

Is this with FS2000, 2002 or 2004? Possibly the Menu ID's have changed. I'll check when I know what version of FS you've checked it with. Certainly it isn't anything changed in FSUIPC, so I assume it never operated on the World menu in FS2004? It should be easy enough to fix. Regards, Pete

There was the facility for moving fuel fore to aft or vice versa in the Concorde, to maintain the CofG in the correct range. I suppose that still works in FS2004, but certainly I know of no way to move fuel between left/right/centre tanks. I doubt if that feature exists on many if any real aircraft, does it? Regards, Pete

Not much more is "findable" in the old sense. FS2002 uses GLOBALS.DLL but a little and FS2004 even less. To provide offsets for such control someone would have to hack the sound subsystem. It isn't easy anymore, what with C++ and the convoluted code the Class system produces. Regards, Pete

Oh, right. Not sure why, but then I don't know VB, lrt along VB.NET. Er .. it isn't in my copy, it's declared as 4. Maybe it was in an old version of the SDK? I don't have one so I can't check I'm afraid. Well, from the sorts of questions I get on VB problems I think most are due to the language, not the user. I think it is ambiguous and imprecise, and the more I know about it the more I think it's a bad choice for beginners (or for anyone, for that matter). But maybe I'm just a little prejudiced! :D Regards, Pete

Not sure they ever worked really. Maybe with some aircraft models where there are separate fuel selector switches and cross-feed valves, if such is possible to implement in FS. You will find, however, that on the default 737, for example, the FUEL_SELECTOR_LEFT control selects crossfeed left-to-right, and so on. The X-Feed switch graphic is ambiguous, and I find it misleading, as it shows the destination of the fuel, not the source, so LEFT to RIGHT shows as "Right" on the switch. Regards, Pete

No, I've not catered for that. The 3 engined arrangement in FSUIPC is 1->12 and 2->3, as documented. I don't see any point in 1->13, 2->2 as the main use of two throttles is for asymmetric thrust -- either to aid in ground steering or to deal with engine troubles. Being able to control the centre engine separately seems to confer no benefits at all as far as I can see. Regards, Pete

Yes, it seems like the pumps are only boosters -- for low wing GA aircraft and for aerobatics. The fuel pressure should increase with them on. Regards, Pete

I have two, one with 256Mb RAM and an older one with 128. I would be too. Sorry. I've had some odd graphics glitches but the latest drivers (1.5.107 I think?) seem pretty well perfect with FS2004 so far. I use them at 2400 x 600, but with no FS panel (virtual or 2D) at all, just the forward view at 0.50x Zoom. I did try 3840 x 1024, but really for the outside view that resolution isn't needed and the lower gives me more frames per secwhich I then use up by having virtually all sliders at max. Have you thought it might be nothing to do with the video card and drivers, but the sound system instead? Try it with no sound, and with the sound acceleration turned down one or two notches (use DxDiag for that). It wouldn't surprise me if it were the sound drivers. Both my Parhelia's are on Pentium based PCs, though it shouldn't really make any difference, unless the Matrox drivers have some incompatibility with AMD stuff. Were both your systems AMD? Same chipset? Really? Mind you, if it is your sound system you can't really blame them for being puzzled too. Just to see if it's some problems with AGP you could try turning AGP off (in DxDiag too) -- there was a time when AMD-based mobos had AGP problems. I think you have to make sure you have the latest "minidrivers" or some such. Whether that applies to your mobo's chipset or not I wouldn't know, but it's worth checking. Sorry, I've really no other ideas. Regards, Pete

Sorry, so many things to do, not enough hours. And it's a separate utility with more dependence on releases of FliteStar and FliteMap than FS. If I had to update it specifically for FS2004 I would have changed the documentation and everything. But no such change was needed so I didn't. Regards, Pete

Yes. It could be done, as I said. I don't want to do it. I'm really not able to look for more things to do, I have enough to last years as it is. i would dearly love to find time to actually fly FS now and then too. :( If it is so desirable I'm sure someone will want to do it, just not I. Sorry. Of course, they don't need to use WideFS in any case. The interface to FSUIPC is published. I'm sure anyone could program an external program, or even another DLL, with a protocol of their own choosing. I know, for instance, that the 777 cockpit designed and nearly finished (?)some time back by Chris Brett has its own TCP/IP links between its components. Regards, Pete

Ah, right. Yes, I didn't notice that. Looks like the 32-bit result was being written to an 8-bit location and so spilling over into another value. Since it would normally be zero that would clear part of that value. You were lucky (or unlucky) that it didn't overwrite something more important and crash the program! :wink: I still think that you should either read all 4 bytes of Flaps or set your Flaps = 0 before reading, in case there's rubbish in the high part. Don't forget, when you start reading more stuff, it is much more efficient to do a list of "FSUIPC_Reads" and then one "FSUIPC_Process" for the lot. Only the "Process" call actually goes into FSUIPC. I still don't understand why there's that "FSUIPC_Get", though. Regards, Pete

What does "FSUIPC_Get" do? Surely after the Process call the Integer "Flaps" already contains the value, which should certainly be 16383 for full flaps. I don't know what "ToString" does either, but it's why you need a "Get" which is really puzzling me. I'm afraid you'll need to talk to someone who know something about VB or VB.NET (if they are different?). Incidentally, it is odd seeing "3036" for the flaps offset of 0BDC. Doesn't VB.NET have the hex facility either (&H0BDC I think?). Also, note that 0BDC is defined as 4 bytes (i.e. a full 32-bit integer) even though the value never exceeds the 2-byte capacity. However, you've defined "Flaps" as "Integer" which I assume is 32 bits (4 bytes). I don't know if VB clears the values to zero for you -- C/C++ certainly doesn't for dynamic (stack-based) variables -- so to be safe you should either read 4 bytes or set Flaps = 0 first. Regards, Pete

No, not from me. But it would be easy enough for anyone to write an external program to do that using the FSUIPC interface. It would be pretty jerky unless the program interpolated quite a bit between readings -- I think most GPS outputs are not frquent enough for reasonable fps without some crafty programming. This question, or similar, has arisen several times and I'm sure someone somewhere must either have done such a thing already, or be working on it now. Try doing a Google search. Regards, Pete

No to FSUIPC, it is an FS module. I don't think Microsoft provide a Linux version of FS do they? If you mean WideClient, then I suppose it would be possible, but it isn't going to be me doing it I'm afraid. Several years ago someone did start on something like that and I provided some details, but I never heard anything after. I'm afraid there's no written specifications of the protocol WideFS uses, but it can be deciphered using TCP/IP tools, and that's what they did. I just answered questions now and then. Regards, Pete