Pete Dowson

SimMarket can sort it for you, or else you can send me all the details (both receipts, both sets of full registration details, and tell me which one you wish to use. Then I'll replace the other. Send to petedowson@btconnect.com. It may not get done till tomorrow night now. I'm away most of the day tomorrow (Thursday). Regards Pete

There's no "glitch", nor do you need very much intelligence! If you take the Heading as an UNSIGNED value direct from the offset, take the Magnetic Variation, direct from the offset, and scale it to match the units of the heading (i.e. shift left 16 bits to make it a proper unsigned 32-bit value) then subtract it from the heading, you end up with another unsigned 32 bit number which when converted gives you the magnetic heading. That way you never need to add or subtract 360. But either way, it surely isn't as matter of all that much intelligence to realise that -1 is the same as 359 when dealing with a 360 degree circle? Regards Pete

Correrct, though I normally calibrate the tiller to have a more forceful effect than the rudder (i.e. use a curve which increases effect quickly near centre). It seems to work quite well in my cockpit. Obviously if you are supplying the values directly you can do something similar. It still won't make a 747 turn on a sixpence, though! ;-) Regards Pete

Yes, and rudder next to it. They are read-outs for indicator gauges. Mainly the rudder one is used to allow checking of the rudder (deflection viewed on the EICAS or lower MFD) even though the real rudder control in FS is being 'stolen' by the tiller axis for steering on the ground. The steering tiller is not truly a nose wheel control but another rudder. The input is gradually blended with the rudder as ground speed is increased. This depends upon both rudder and tiller axes being calibrated in FSUIPC, as it is the calibration routines which do the blending. No. it's only a read-out. There'd be no point in any case. What would it do? Since all FSUIPC can do with a tiller input is send it on to FS's rudder, why not simply write direct to the rudder input at 0BBA? If your program also has control of the rudder axis you could do the same sort of gradual cross-blending yourself, as FSUIPC would do if both axes were calibrated in FSUIPC. FSUIPC has a "crossover" ground speed (defaulting to 60) at which rudder has 100% authority. At 0 knots the tiller has 100%. At 30 knots it is 50:50. the computation is easy enough. You should also check that the aircraft is on the ground, of course, else you ignore the tiller. Regards Pete

You use a 'Double'. Thanks Paul. not totally different from C/C++ then! ;-) Pete

Oh, I don't mind. don't worry. I try to explain everything when I see lack of understanding, so you should progress okay, hopefully. Sorry if I'm explaining things which you know in the process. But what's confusing still? Regards Pete

A heading of -1 is the same as a heading of 359. Look at the face of the compass dial if you don't understand why! Just normalise any result you ever get to lie in the range 0 to 359.9999... by adding 360 if it is less than 0, or subtracting 360 if it is greater than 360. Note that the same applies to time. If you added an hour to 23:30 hours you don't get 24:30 but 00:30. and An hour before 00:30 is not -00:30. This is merely application of everyday common sense! ;-) You need a programming reference for the language you are using. In C a 64-bit floating point number is a "double". I don't know what it is in yours, but you should be able to find out in the same way as you found out how to use the language in the first place. Regards Pete

It's subject to gyro drift (unless you switch that off). Pete

Oh dear. Please use the FACTORED column in FSInterrogator, so you can see the converted value, not the raw FS units! In any case you are mixing up signed and unsigned values. The heading is NEVER negative, it runs from 0 to 359.9999... and is therefore always positive. You are probably reading the correct data but treating it incorrectly. Going East the heading will be positive even if you are treating it incorrectly. Pete

0BE0 is merely a copy of the SimConnect variable "TRAILING EDGE FLAPS LEFT PERCENT", scaled to scaled to the FS98-compatible 0 to 16384 range. So, its potential resolution is 1 in 16384 for full flaps. That's 14 bit. Of course you won't be able to read it fast enough to get every possible value, and nor will FSUIPC receive every possible value because of the asynchronous data passing mechanism used by SimConnect. However, you should be able to read it often enough to give smooth enough values, and if you are driving servos the motion needs of the mechanism itself will surely interpolate the parts between. If you want to observe the values it is providing simply go to FSUIPC's Logging page, put 0BE0 in the first Offset slot on the right-hand sde, select type "U16", then check the "FS Window" option below. You will get a real-time readout on FSX's screen. There's no difference in offset 0BE0 in any version of FSUIPC4. I don't think FSX's SimConnect changed it in either of the SP1 or SP2 updates, and it is merely a read-out from the Sim's own value (from the Sim1.DLL engine). I only mentioned you were out of date because I do not support old versions. Regards Pete

4.30 is out of date. The current version is 4.40. When you ask about resolution you need to state which quantity you are talking about else I cannot possibly answer. Regards Pete

Okay. How have you done this? conditions for button press actions are possible, and documented in the Advanced User's guide. there is no equivalent for keypresses. As you don't tell me how you are accomplishing what you are doing I can't really add to it at present. You could also look at the Macro facilities, which allow any sorts of sequences of actions to be combined, whether instigated by button or keypress, and the Lua plug-in facilities, which allow you any amount of flexibility in what you do, as well as having actions depending on FS events. Check the Contents lists of the main two User documents regarding Macros. For Lua there are separate documents available describing this as well as examples to try or examine. You do need the latest FSUIPC release of course. Regards Pete

Assuming you do mean the "SET" button below the flap detente setting, i.e. the centre one, that's crazy. :-( I cannot see how it CANNOT copy the IN value to one of those two places (alternately) each time you press that Centre "SET" button. That is all that it does, it has no other finction except that! I think i would have to stand behind you whilst you are doing this to see what you are doing wrong. This facility is really quite simple and very reliable, and has been in use now in both versions of FSUIPC for some time (30+ months, as I mentioned), with never any trouble. That's not strange. It is caused by fluttering or jittering values on the axes you are seeing most. The FSUIPC routine merely shows the first axis which it detects changing. Wobbling values like that can be due to poor power supply (at the device, usually, so power from a USB port or hub), dirty pots, varying temperatures, moisture and so on. You can sometimes reduce or eliminate it by parking the axis at one extreme or the other, where the pot is less worn and the Windows driver makes a stable reading. In order to help deal with axes which never go quiet the Axis assignment dialogue is equipped with an "Ignore" button, which you can use to (temporarily) ignore the axis shown. If your Flaps axis is "spiking" (that is, not just fluctuating or jittering slightly, but actually occasionally sending extreme values, like your 16383) then that would more likely indicate a bad connection or dry joint and would be serious. Concievably this could be responsible for your flap setting problems, but I wouldn't expect it to be as consistent as you describe. You could test this by making a safe copy of your working FSUIPC.INI file, then removing the assignment of the flaps on the one you are using and then seeing if you can get the flap detentes set correctly using one of the other axes you are otherwise using and which don't appear to be jittering. Oh, one other thing to double-check (I didn't think of it before as it seemed too obvious -- but you never know), do go through all the assignments and make sure NO OTHER AXIS is assigned to Flaps, whether via FSUIPC or FSX. Regards Pete

FS itself doesn't simulate these things. Where an aircraft panel has them, their condition is determined by the logic local to the gauge maintaining the display itself. This is also why there are no FS controls for "pressing" those buttons and you have to resort to mouse emulation. If you are using a sophisticated add-on aircraft, like the Level D 767, then there's probably a way of accessing the status via the information in their SDK, or through interface programs written for this. The PMDG aircraft did have an SDK but it has only ever been made available, at a price, to hardware deveopers and I think it is withdrawn in any case at present. The more generalised add-on aircraft systems programs like Project Magenta and FlightDeck Software, and another I see recently, Sim-Avionics, do have interfaces via FSUIPC which you can use. If you are serious about building an airliner cockpit then you should really be looking at something like that for full flexibility in linking in and operating your indicators and switches. Otherwise you would have to resort to simulating the Master Caution condition yourself by checking all the conditions which can cause it to be lit. You could do this in a program interfacing to FSUIPC (or SimConnect, for FSX), or, in FSUIPC, you could consider writing a Lua plug-in to do the same thing. Regards Pete

Are you by any chance comparing a MAGNETIC heading with the TRUE heading provided in offset 0580? Is the magnetic variation wherever you are about 16 degrees? You need to be aware of these things. Please try using the tools available to check your own code. For instance, FSInterrogate will show you the TRUE heading and the Magnetic Variation (from offset 02A0). Alternatively, if you put your aircraft into slew mode and press the Space bar (or possibly Shift+Space or Ctrl+Space in FSX?), it will turn your aircraft to TRUE north and you can read the magnetic variation locally from the heading indicator. Regards Pete

Sounds like a video driver problem. Try running FS in Windowed mode instead of full screen. That usually gets around such quirks. Otherwise you'll need to find better video drivers. Regards Pete

Sorry, what documentation regarding what calculation? For a value which runs from 0 to 16384, the 100% value is represented by 16384, so a value of n is ((n x 100) / 16384). Simple arithmetic. Put another way, since "percent" just means "out of 100" or "proportion of 100" so converting a "proportion of 16384" to such means dividing by 16384/100. Pete

That's all very well, but it is the actual numbers which are important. That's all I need to see. FSUIPC will refuse to allow you to set impossible numbers -- i.e. numbers which make no sense in achieving what is needed. That is totally the opposite of what will work! Flaps Up is the MINIMUM value for flaps. "Minimum" means the least value, and must be lower than all the other values. Similarly Flaps down is the Maximum value for flaps (it has a higher flap number, a higher angle, remember?). With ANY axis, whether you set and calibrate in FS or in FSUIPC, you must ALWAYS first ensure that you have it going the right way! You CAN leave your Flaps going the wrong way if you wish, but then you have to remember to push away from you for more flaps, instead of towards you as in the real airplane. Note that the spoilers/speed brake axis is also reversed. If you look at a throttle quadrant, the one for your default 737, you will see that when everything is "off" or at "minimum", the left and rightmost levers are both as far away from you (top most) as they can get, whilst throttles are nearest or at bottom. This alone should suggest that those outer two are reversed relative to the others, right? Yes, of course. Clear everything (press Reset then Set is best) then select Rev, THEN do everything you did before. Regards Pete

This can only happen if the values are decreasing. Each successive detente must have a pair of values higher than the preceding pair. Most axes need reversing before using as flaps, unless you want the lever working in the reverse direction to those in the aircraft. Are you sure you did this? You cannot set notch #2 with lower values than notch #1. It would do that if the values were impossible, but certainly not otherwise. Show me what you tried to set. It does sound to me exactly as if you are trying to assign everything in reverse order, of values, which cannot be done. flap values must increase from up to down. I've just tried exactly what you said you did here, but with the Rev option selection first, to get the orientation correct, and it works fine. If you still cannot operate it, please show me the values -- the ones you tried to set manually sshould tell me where the misunderstanding lies. BTW if you want to make editing changes in the INI file, for any of the Buttons, Keys, Axes or JoystickCalibration sections, you can do so without closing FS, and then just tell FSUIPC to reload that section -- there are Reload buttons for each. Regards Pete

Does FS actually simulate that? I didn't know that. I assumed the "Toggle Alternate Static" control just operated the Engine ones, according to the currently selected engines. Hmmm. Looking now i see there is, in SimConnect, a separate value I can read: "ALTERNATE STATIC SOURCE OPEN". It must be the one controlled by that toggle control. So I could add this to FSUIPC4 as a new read/write offset. However, I cannot do it in FS9 and before, as there's no obvious sign of it in the data I've already "hacked out" of those older versions, and I'm not going to start again on that sort of thing now! ;-) Regards Pete

Well if the client log hasn't changed since the last one you posted, the broadcasts from the server still aren't reaching the client. For an otherwise working network the only cause of that I'm aware of is that they are in different workgroups. You have an INTERNAL firewall on a router? Phew. Never heard of one of those. Why use the Server IP address? Use the ServerName -- it is much easier and more flexible, in case your server IP address changes (or is masked by your very clever sounding router). If that doesn't work then I'm sorry but you will need some expert help from someone who knows about Networks. There's absolutely nothing special or clever about how WideFS uses the network, it is a direct copy of Microsoft examples. You do actually need to have a working network first. Evidently at present neither port 9002 (for Broadcasts) nor 8002 (for data exchanges) can connect between the two PCs. I assume you have other networking needs sorted? Regards Pete

Yes. My own systems run FSX on Vista SP1 and all my clients are on XP SP2. Make sure the workgroup name is the same on both -- I always name mine "PETES" in any case, but if you leave them to default I think Vista chooses a different name tp XP. It doesn't affect networking except in a few places, such as Broadcasts, and WideFS uses Broadcasts from the Server to save you having to configure the Clients. Regards Pete

Every firewall? How many did you have? Well, almost. The current official release of Wideclient is 6.78, and has been for a couple of weeks or so. There's also a later one in the Announcements above. But no matter, the differences won't affect this. The logs show that the Broadcasts from the Server are not reaching the Client. This is usually because you have the two computers in different WorkGroups. Make sure you name the workgroup the same in both machines. After all, you want them to work together, no? Working together should mean they are both in the same group. See? Alternatively, but not the best solution, you can do as the documentation suggests (you didn't think of looking there at all, perhaps?), and that is: add parameters to the WideClient INI to tell it the name of the Server and the Protocol you want to use. This obviates the need for the computers to be on the same workgroup -- but it isn't the best way to do it. Regards Pete

Which offset is it in the FSX offsets list, then? That control seems to appear in the FS2004 list as well as the FSX list, so why do you think it is new? I simply searched for the word "alternate" in both the FS2004 offsets list ("FSUIPC for Programmers", and also in the FSX offsets list ("FSUIPC4 offsets status") and found Engine 4's alternate air at 35C0, Engine 3's at 3680, engine 2's at 3740 and engine 1's at 3800. What method of searching are you using that failed so well? FSInterrogate only lists what the documentation lists, at best. The FSI file is, sadly, often out of date. What were you expecting it to do extra? Even when there is no working offset, if there's a control you can always send that, using offset 3110. That's what it is for! Regards Pete