Pete Dowson

You seem to have completely misunderstood the purpose of the exercise. That log is NOT showing what your macro does, but what using the mouse does! Remember? We are trying to find out what the mouse does, which works, so we can do the same by macro! I asked you to add some logging and operate the APU switch by mouse so we could see what was happening when it works! Maybe you forgot all this in the days in-between? I know! But that isn't what the mouse actually does, as you can see. This is exactly why I suggested that you replaced what you had for the macros with three line ones using the same sequence as the mouse. This is why i said which you apparently ignored. :-( Pete

Okay. It all seems to work fine here. I don't have a PFC device with the LEDs, but I traced through to the place where it sends the commands to the PFC controller to turn them on and off, and it definitely does that when there's an active marker signal. There are other conditions that must be satisfied for any flashing to occur, but as these mostly apply to the whole avionics stack I assume these are satisfied when yo do your test. They are: FS Master Battery switch on FS Avionics switch on No electrical failure reported by FS. Anyway, to help investigate, I've added an offset in FSUIPC which monitors which PFC lights should be flashing. Look in the Updates and Goodies Announcement above and scroll down someways: you'll see the details. Download PFCFSX.DLL version 4.351 and copy that to the FSX Modules folder. In FSUIPC Logging, enable Monitoring of that offset (3BCE) as type U16, with a Hex display, then check the "normal log" and "fs display" options below. You should see on screen the value changing when the markers are activated. Assuming nothing else is set to flash you should see 0x0010 for Outer, 0x0020 for Middle, and 0x0040 for Inner. [LATER EDIT] I've had to remove this extra action, to 3BCE, because I found that offset already used. It seems it is irrelevant now as you have located your problem in anyt case. For further proof, if you enable the serial COM logging in the Test tab of the PFC options, the log should show the correct commands being sent to the hardware. The log will get very quick very fast, so if you think I ought to check it, only do this logging whilst you know you are receiving a marker beacon, and then only for a short time -- a few beeps. Zip the file and send to petedowson@btconnect.com. If you can get a test program from PFC, so much the better. It might be a lot easier. Note that I would doubt that all three bulbs or LEDS would fail together -- it is more likely to be a loose connection to that sub-board. Regards Pete

It is always in the same folder as FSUIPC -- i.e. the FS Modules folder. It is called "FSUIPC.LOG", but if you have Windows set to hide filetypes it will probably look to you as simply "FSUIPC", and be called a text file or somesuch. Pete

And did you see the log for more details? If you did I suspect you would have found that you are using a very very old unsupported version of FSUIPC, as that message hasn't existed for over three years. Maybe something you installed overwrote your later copy without asking? Regards Pete

No. Gate lists are made by scanning the scenery files. Programs which show the gates build up a database which you need to have updated when you add new scenery. I provide a free database maker called "MakeRunways", which creates a number of files -- airport lists, runways databases, gates, taxiways frequencies. The latest version is available in the Updates & Goodies announcement above, and I am putting another (faster and more foolproof) version, 4.40, up later today. Regards Pete

You missed this: If not the latest from the Updates & Goodies announcement above, could you try that, please? Just runway numbers would do, but I'll go there and check. I only have the default FSX scenery for Australia though. Regards Pete

Well, first of all you should be posting your question in the Support Forum for FSUIPC, as detailed in the FSUIPC document, on the FSUIPC options screen in FS, on the FSUIPC sales pages in SimMarket, and on the FSUIPC download site. In fact it is shown in so many places it is very hard to miss it! :o For full details of all things FSUIPC, please see the Announcements in that Forum, and of course the regular download site, http://www.schiratti.com/dowson where you will find the SDK quite easily. That contains all such details. Regards Pete

That's very strange. You are comparing it with the on-screen gyro compass, are you? Not the heading? Don't forget the gyro may be drifting. You can use the Logging facilities in FSUIPC (right-hand side, monitor on screen) to see the value FSUIPC is sending. The GFdisplay program is reading the values constantly, so it really cannot get out of step in any way I know. Maybe you should tell me rather more about your system. Are you using FSX or FS9, or something else? Are you using GFdisplay on the same PC as FS or on a WideFS client? What versions of FSUIPC, or WideFS? And I would need to see the complete GFdisplay file, please. Pete

You are misreading the documentation somewhat: 1. You missed out the offset type for 0 and 1 (e.g. U8 or U16) 2. You don't actually need the "=1" to test for non-zero: you'd be better leaving it off 3. For the offset 0D0C entries you should really have X0D0C (but it might work omitting the first 0, I don't know off-hand). 4. The conditions like "=32" says "if the value is equal to 32. This would only ever be true if the panel lights were on and all the rest off. I assume this isn't what you wanted? You want "if the value has the 32 bit set". So you need to use the Mask facility to test the individual bits. The bit worth 32 is the 2^5 bit (32=2x2x2x2x2), so the mask is M0020. Similarly 4 is M0004, 8 is M0008, 1 is M0001, 2 is M0002 and 16 is M0010. 5. In cases like "U16=32" you probably need a space before the =, because the condition "=32" is not associated with the type "U16", but with the offset. It may work without the space, but I'm not sure. Regards Pete

No. Pretty much the whole team, as was, were real world fliers too. And dedicated to making it realistic. they also had professional fliers, including even a stunt flier for the Extra, to check things out for them in case they were mistaken. Apart from the rather exaggerated weather vaning (due I think mainly to a lack of correct ground friction simulation) I find FS pretty realistic, from my experience. So I think we agree to differ on this. There's really no need to keep on with the lessons. There isn't such a feature for FSX, and I fly FSX exclusively. Maybe that's where the difference lies? Regards Pete

Seems unlikely. What version of the PFC or PFCFSX DLL are you using? PFC can supply test programs I think. But if you hang on a day or two I'll have a look to see if I can log the O M I actions specifically via the driver. I'm afraid I no longer have the serial port avionics with the O M I lights to test here, and I am a bit tied up today. Maybe I've messed them up in some update to my software. Do you have both FS9 and FSX? If so can you check on the other Sim please? Oh, can you give me a couple of Lat/Lons, or at least runways, where there definitely are Marker beacons in FSX? I don't think there are so many compared to FS9. I assume this reflects a real world decline in their use? Regards Pete

Good. Well done. Other folks with the Garmins have contacted Garmin about this and been told it cannot be done with the USB connection -- the Garmin will not accept the Aviation input that way. Apparently you have to purchase an expensive serial connector from them. There has been recent threads on this. Do a search on "296". Regards Pete

Oh, yes. i see how you might interpret it that way. I'll have to change that. Thanks. So do I. I'll re-visit it for sure sometime. It was easy on XP -- I found out how by monitoring registry activity when you change it in athe Control Panel. Just one Registry entry. On Vista and Win7 there were many convoluted Registry changes when you just select a different sound device, many using those long weird GUIDs, and I just couldn't track anything remotely reproducible. I guess it has to be done by calling some routines someplace instead, but there's nothing in any of the MS reference or developer areas which helps. Regards, Pete

I've never seen that. It must be an FS control. Let me look at the list. Oh yes, "ADD_FUEL_QUANTITY". I've never noticed that. I'm surprised it works. ;-) Well I'm not going to hack into Microsoft's code to alter the way one of its controls works, I'm afraid. Maybe it takes a parameter value -- it sort of implies it by the name. Have you tried putting, say, 10 in as a parameter and seeing what it does? If that works you could simply have it repeating whilst a button or, better, toggle switch was on. Otherwise, to do what you want, you'd have you think about using a Lua plug-in. Doing a bit of programming to loop around incrementing the fuel levels. Regards Pete

Sorry, but as it says in the documentation, the facility only works with Windows XP. I cannot fathom out any way to change the sound devices by program on Vista or Windows 7. Luckily, all my Client PCs are lowly beasts and I'm leaving them all on XP. Regards Pete

I'm sorry, but Esound probably doesn't work. It dates back to FS95/FS98 days and hasn't been maintained or supported for many years. I don't know anyway at all of separating some FS sounds from others in any case, they are all just wave files. Even with Esound , if it worked, you wouldn't have been able to do what you want. It only ever separated Adventure sound (from APL files used by the old FS Adventure Interpreter). Regards Pete

For heading you want a cyclic update with a limit of 360. the example was not for heading. I pointed you there so you could understand the FORMAT (i.e. increment/limit)! That's all. I never thought you'd just think to copy values from an example! A button repeat rate of 1 will be very slow -- that's 1 per second! Why do you want it so slow? The delay is how long you hold the button down bfore it starts repeating. with a repeat rate of 1 per second it won't matter, but if you have something more sensible then having the repeats start immediately will stop you being able to make an increase or decrease of just 1. you seem not to have read the description of the ButtonRepeat parameter. What is the limit on the heading? 360 isn't it? Or are you using some unit other than degrees? ;-) What increment do you want? 1 or 5 or 10 or what? You must choose the values you want. That's the point. Regards Pete

That would be a SimConnect problem, then, assuming the installation succeeded. The Installer produces a Log file, in the FSX Modules folder, and there will be an FSUIPC4 log file if it ever got started. Show me both. So, something changed in your FSX installation between the two attempts? You should really have checked the logs first. Note that the re-installing FSUIPC4 does absolutely no harm. It merely carries out the same checks again -- implying that something happened to your FSX installation in between those two attempts. Ugh. That is drastic, and the cause of most SimConnect problems, as the FSX uninstaller cannot cope with the Windows side-by-side (WinSxS) library system used by SimConnect. Before doing that you should have checked the logs, and probably deleted the SimConnect folders before doing the installs (the FSX Help Announcement above assists with this). There's no such thing as "FSUIPC.EXE", and FSUIPC4 only runs inside FSX which also itself needs msvcr80.dll. It is the main Visual C/C++ run-time library for the version of the compiler used by Microsoft when building FSX. So, please try to be a little more accurate. At the end of the installation, the installer terminates. There is then nothing running, so nothing could be missing any DLL. What did you then do to get the message? Regards Pete

Yes. With WideFS any GoFlight unit on any WideClient PC will send its button and switch events to FSUIPC for assigning there. It doesn't work for axes, as on the throttle quadrant, and of course it isn't connecting them to the GoFlight software. You need the GFDev.dll installed on the client PC. Easiest way to do that is put it in the same folder as WideClient. You'll find GFDev.dll in the "Updates and Goodies" Announcement above. If you want to have any of the displays and LEDs working on the client you need the GFDisplay program operating there, properly programmed, just as you would for FSUIPC-handled GoFlight units on the server PC. Regards Pete

If FSX beeps, the lights should flash. There's no difference between FS9 and FSX in this regard. They each flash at different intervals. Regards Pete

Yes to all that. But it most certainly needs some rudder too, to offset the weathervaning. Never tried a taildragger. I've been in Sea Planes a couple of times, though not piloting. Of course it is different -- he "friction" on water is not like land. But I'm sure that the pilot used rudder quite a bit to keep straight (mainly due to the buffeting of the waves ricocheting off nearby land). He always took off and landed directly into wind, so crosswinds didn't come into it. If the rudder is aligned with the offset wind, it would be less drag surely, especially at low speeds (during taxi) when the prop effect is less too. It is presenting minimal surface to the air. Naturally as you speed up for takeoff you gradually straighten the rudder as it becomes more effective with more potential drag if you don't. So you are saying the tyres always slip sideways, no matter what the surface? Strange. I've NEVER experienced that, only weathervaning. Regards Pete

Good. Only the lower wind layer is called "surface winds". You can manually add many layers. When you use ASA or FS downloaded weather you get a surface layer and a number of upper layers (though the latter are optional with FS downloads). Yes, that's weathervaning. I cannot agree. It IS exaggerated in FS, but it is certainly a noticeable effect in real light aircraft too, as I can attest to from my flight training days in Cessnas and Pipers -- before my sight problems were discovered. You need to use rudder to counter the weather vaning, as you do in FS, but just not so much. Well, I never experienced that -- maybe you had aircraft with large side surfaces to be exposed to the wind in comparison with perhaps a smaller tailplane that usual. Besides, I would expect the tyres on the wheels to resist sideways motions much more than a twisting action due to weathervaning. Maybe your experiences were on wet slippery grass? I realise that FS doesn't simulate various ground conditions and frictional changes much, if at all. We evidently know different things, and have different experiences. To my knowledge and experience the tail surface is the largest off-centre surface facing the wind and has more effect than the more or less equal effect all down the side of the body. That's not being versed in FS so much as experimenting to get the best effects in the weather. I leave that to the specialists -- I've been using ActiveSky throughout all of its incarnations, with ASA on FSX at present, along with FEX and REX high resolution multilayered clouds. Wonderfully realistic. Most of these things aren't needed with a decent weather program. They were fiddles for personal taste in the early days. Most of that cannot be done in FSX in any case. If you don't know what you want, I'd leave settings to the defaults. By all means turns things on and try them -- but remember than most of those only work with external weather programs in any case, and the recent versions of Active Sky do most for you in any case. Those adjustments are simply to do with performance. If you have enough of that, whack them all up full. With what program is that? If you mean clouds, there's nothing which smooths clouds, but if you have them popping up you probably haven't got the settings in FS up full -- they'll be the "pretend" 2D clouds done for performance. Regards Pete

Not that I noticed, but I'm afraid it wasn't one of the stands I took so much notice of. I was too entranced by all of the super realistic (and mostly super-priced :-( ) cockpit stuff around. VRInsight might be cheaper and utilitarian, but it doesn't look enough like the real thing for my tastes. ;-) Regards Pete

So, not a proper simulation of an FMS, which cannot show such things. It would be wrong to be "blown to the left", but that isn't it -- you weathervane into the wind, so you end up driving the aircraft to the left. I've never ever had any version of FS which has wind effects operating in the wrong direction, so I am pretty sure you must be misinterpreting what is happening. But according to you you are not getting any weather vaning? You say you are getting "blown off" in the wrong direction. I've never actually been "blown" anywhere in FS whilst on the ground, so that is very odfd indeed. (It sounds rather like you are in a balloon? Maybe FS's balloon simulation isn't correct ;-) ). Hmm. You contradict yourself here -- "the winds are still present" and "wind to zero" ...? Yes. If AS6 isn't running it cannot download nor inject weather into FS. When you get these winds, do you go into FS's weather menu and see what mode it is in? That's all to do with how the initial flight, or the flight you are saving, was saved. There's an option to "use system time" which can override some parts of the saved flights. I think you are in the wrong place here with your problems. I really don't think I can help I'm afraid. You'd probably be better off over in the FS2004 Forum. I'm sure there are folks there with all sorts of experiences like this who can help, and sympathise. Regards Pete

These are with separate little Lua programs, one for each function? If so, I think you need to do it the other way I suggested: accumulating changes and sending them to the L:var in measured doses, limiting it to a speed it can cope with. It does really sound like something is getting corrupted by re-entry. Probably either faster code handling the L:vars, or they have coded it to be re-entrant . It can be done. Yes, indeed, I agree that is where the problem lies. Of course you are trying to use it in a way they hadn't designed for. Regards Pete