Pete Dowson

The parameters for the C library functions sin() and cos() have to be in radians, yes. The result of the acos() will be in radians. Best do dMyLat * PI / 180.0 The magvar from FSUIPC offset 0x2A0 is 16-bit (short int), not 32-bit. And, yes, you have to convert it as it is in FS units. But do NOT use "(360/65536)" as that will give you 0! Use double dMagVarDegrees = (sMagVar * 360.0) / 65536.0 Always multiply before division if you want more accuracy, and always remember literal numbers are taken as integers by default unless you use ".0". Convert it to whatever you need. I convert it from radians to degres, then adjust it for Mag Var -- please look at my code again. I gave you the code I use. Sorry, I cannot really be more explicit. You will need to do your own debugging. Regards, Pete

I've never heard of a problem where WideServer doesn't produce at least the start of a log. But is sounds like one of two things. Either there are multiple copies of one of the DLLs in the troublesome installation (possibly renamed?), or the FSUIPC.KEY file isn't correct in that particular Modules folder. The FSUIPC.LOG file would tell me about the latter, but try copying your FS2004 KEY file over (again?). All the stuff both FSUIPC and WideFS deals with is in the Modules folder, so I suggest a good first step is to compare the "clean" modules folder with the suspect one. There must be some difference there causing the problem. When you find the differences, try eliminating them one by one till you've found the culprit, then get back to me. Don't delete anything, just move it into a temporary folder (I use a sub-folder in the Modules folder called "Saved" or "Others"). And don't rename anything, that makes it more confusing and it may still load if it looks like a DLL. Regards, Pete

There's some other threads here with the same question, and I think one of them even has a link to a website with a kit or example. Try scanning through the subject headings, maybe search on "module" in the title. My advice has always been: learn to write a proper C-language Gauge as per the older MS Panels SDKs, and you are over half way already. GAUs are just Modules loaded by Panels. Regards, Pete

TrafficLook makes assumptions to keep things easier. it assumes the Earth is flat as far as the TCAS data range is concerned, for instance. The formula I use is: =========================== //dHdg = result in degrees //dDst = computed distance "in radians (i.e. nms * PI / (180 * 60))" //dMyLat = User Latitude, degrees //dMyLon = User Longitude, degrees //pt = pointer to current AI TCAS_DATA struct //MagVar = mag variation at user aircraft as WORD from FSUIPC dHdg = (dMyLat == pt->lat) ? 90.0 : (180.0 * atan(fabs(dDst/(pt->lat-dMyLat))) / PI); if (dMyLat >= pt->lat) { if (dMyLon >= pt->lon) dHdg += 180.0; else dHdg = 180.0 - dHdg; } else if (dMyLon > pt->lon) dHdg = 360.0 - dHdg; // correct for magvar dHdg -= (MagVar * 360.0 / 65536.0); if (dHdg < 0.0) dHdg += 360.0; if (dHdg > 360.0) dHdg -= 360.0; ========================== I don't think this is very accurate, it only uses elementary trigonometry, but it seems good enough for my purposes. If you are using it for missile launching you'll need to be more accurate I expect! :D :D :D Regards, Pete

Ah, wellI did say I was prejudiced, didn't I? :) I take all your points on board, and will probably henceforth recommend all VB programmer's who ask me questions to upgrade to VB.NETbut tell me this, does it still change &H00008000 into &HFFFF8000 i.e. sign extend even though the zeroes are explicit? That alone makes me shiver! :? Regards, Pete

Latest Zip file for what? Sorry. I've also had some problems in the past with Logitech mouse drivers. I always use the default Windows ones these days. I don't know what they are doing. The problems I remember weren't in AdvDisplay though, they affected quite a few things when FS was running. Thanks! Regards, Pete

Mixture is not at all like an alternator switch or a light switch. It has a full range of values. If you mean a fuel switch for Jets, then a toggle switch will do the trick. Just program it to send "Full Lean" when turned off, and "Full Rich" when turned on. You can do that with one toggle switch in FSUIPC's buttons page. If you only have a momentary push button, then you can still do it but it means editing FSUIPC.INI. You can toggle a button flag (Button Flag Toggle) when it is pressed, and make the "Full Lean" or "Full Rich" action depend on the Flag state, so it does the two things alternately. Check the FSUIPC Advanced User's documentation. Regards, Pete

Yes, you can do that. But FSUIPC offers as an alternative a separate reverser axis facility. Just a single one (at present) which reverses all throttles. See the FSUIPC User Guide, Joystick section. Regards, Pete

Sorry, I don't understand. What's a "toggle mixture parameter?". There are 4 standard mixture controls in FS, other than the analogue axis ones. These are Mixture idle cut off (Ctrl+Shift+F1), Mixture Full Rich (Ctrl+Shift+F4), and the INC and DEC ones (Ctrl+Shift+F3 and F2, respectively). I've no idea what a "toggle" action would do, nor really why you'd want one. Please explain a bit more so I can understand. Regards, Pete

My GPSout module sends positional data out on a serial (COM) port. AutoRoute can be set to receive it on a serial (COM) port. If you have two such ports, or a USB-Serial port adapter or two, you can connect the null modem cable from one to the other port. This will certainly work if you get all the COM port identities sorted out correctly. I wouldn't guarantee very good performance on the part of either FS or Autoroute, though, unless you have a good fast PC! :) Regards, Pete

Since all axes are treated identically by the software, it just has to be a hardware issue. Probably a dry joint or a loose connector, something similar. You need to contact PFC for advice. They will probably give you instructions for dismantling and checking certain things inside. Otherwise, if it is a recent purchase, shipping it back for repair may be advisable. Regards, Pete

FS does not provide a reverser axis as such. There is a facility for this in FSUIPC, available to registered users. The FSUIPC facility, by default, uses the Mixture axis, not the Prop Pitch axis, but you can assign that if you like. it means editing the FSUIPC.INI file, as described in the FSUIPC Advanced User's Guide. Regards, Pete

Well I should probably just remove its connection with the FS prop sync. The facility itself shouldn't do any harm if folks don't use it, and I will tidy up the way it syncs things to use existing values rather than previous input values. I just think I shouldn't do anything with the FS prop sync at all for now. However, saying that, I have just received the first complaint (by private email for some reason) that what you experienced also occurred after upgrading to 1.72, without even using the Sync facility at allso I really don't understand how that happened. Maybe it's the power of suggestion, from this thread! :lol: Don't worry, you didn't. I've just got such a long list of things to do, some large, some not, that going backwards is rather frustrating. It was an easy facility to put in, which was why it ws done so quickly, but the aftermath has made it a big thing. Never mind. I'll sort it out. Regards, Pete

The calibration screen shows the same values as input to FS, so are you saying your aileron control doesn't work? There's no difference in treatment of any one axis over another in the PFC driver, with the exception of the Flaps axis with detentes. If you are getting problems on one axis only I think you should contact PFC as it sounds like the hardware may be playing up. I saw that announcement. I have no idea what they are on about. Trying to scare folks for some reason. The older (pre Version 3.xx) versions of FSUIPC do not run in FS2004 in any case. FS will say it cannot run that DLL , and give you the option to try in any case, and then you say no. Regards, Pete

Ideally, through the HID and normal assignments, as then you have Windows calibration, FS sensitivity settings and FSUIPC Joystick facilities at your disposal. If, for some odd reason, you cannot use the normal joystick interface then you can still send the values as the appropriate Axis controls, via FSUIPCs offset 3110. This bypasses Windows calibration and FS assignment and sensitivity, but will retain the FSUIPC options. The facility to write directy to the control values themselves affords no reassignment, no calibration, nothing. You have to do all that yourself. This is the way external and some sophisticated panels control those things for either Autopilot use of "fly-by-Wire". If you don't want to use any such sophisticated panel or external system (like Project Magenta) for example, then by all means write to the FSUIPC control locations (0BB2 etc). You bypass everything then. I don't know why, as they are all surely described in entirely different words? For even more different words: 0BB2 is the elevator control value, the final control sent to the actuator. 3110 is a facility for sending any of the Controls listed in my Controls List, and otherwise identical to assigning these in FS Assignments or FS CFG file. 3328 Is a READ-ONLY area showing the axis input value which would have gone to the control value if not disconnected by 310A. As described, it is this which allows Fly-by-Wire implementations -- the FBW module can diconnect the input value from the control value, read the former, manipulate is as it likes, and then forward it. Regards, Pete

But what does it do then? If I leave it in will I get complaints from others who say I've mucked up their cockpit now and stopped Prop Sync doing what it is really supposed to do? This is happening al the time now -- almost everything I put in is not liked by someone or other. Pete

The interface is a combination of EPICINFO (for displays) and normal FS assignments (for inputs), using POVs for radio frequencies and so forth. I only added the POV stuff to EPICINFO for FS2002 and later because when FS changed to DirectInput is messed the normal assignment of POVs up completely. In FS95, FS98 and FS2000 (yes, EPICINFO has been around for all of those), every single input to FS was by assignments in the FS CFG file, and EPICINFO was exactly as it's name ssuggests -- info to EPIC. Most of the specific stuff for the KR-1 was EPL derived from the EPL for the TR-1, and pretty much none of what I wrote originally is compatible with today's USB EPICs and new EPL syntax and facilities. It was all re-written for the new stuff by Ralph of R&R. I don't do any EPL programming now and would probably be quite bemused by what my own code has become! Regards, Pete

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