Pete Dowson

But i thought you were using that Lua file to maintain your GF-MCP digital displays? So it had an error? That would stop it running, of course. So is there another error listed in the Log? I meant, how were you making it run, where had you put the code. You've answered that now. You've discarded all of your GF-MCP work and are only now concerned with a single LED. Pete

Sorry, but nothing of mine can hasve anything to do with that, and I don't know anything about VATSIM or IVAO. Have you tried their support? Sounds like FSUIPC isn't installed correctly. That explains the last problem, but not your VATSIM or IVAO problems. Hmm. Did this "Booster" program stop any Windows services, by any chance? You must allow the cryptographic service to run. Please also see the Announcement in this Forum about help with code signature problems. Regards Pete

Where did you put the code you showed? Is it running? No. If the L:Landlight_switch is 0 when off and not 0 when on, you only need if and else. I don't think your code is running. Where did you put it? How are you starting it? Sorry, I don't know what you mean here. Pete

As documented, the button flags are toggled each time the associated button goes from "off" to "on". That's why they are useful as latches for momentary buttons. They wouldn't be needed for self-latching (toggle) switches, and would be useless for momentary buttons if they toggled when the buttons went from "on" to "off" as well, wouldn't they? You'd simply use the button state not the flag. Regards Pete

I've had to make some changes for other things so I had a look at this. I can fit in one line in the box beneath the version number, date and registration confirmation. It will be filled in with up to 127 characters (if they'll fit) from a user parameter in the INI [General] section called "AboutUserLine". This will be in 4.627 which I'll upload to the Updates announcement either tonight or more likely some time tomorrow (Tuesday). Regards Pete

Yes, of course that will be it -- it is taking over the autobraking. It is very good: it is able to simulate different braking effectiveness according to all sorts of factors, such as runway state, aircraft weight, alignment of aircraft, and so on, even brake wear and temperature from previous usage I think. Regards Pete

Yes. Here's the relevant part: Seems you have an external program managing your braking on landing. It is turning off the autobrakes (WRITEex 2F80, 1 bytes: 01), and then attempting to manipulate the toe brakes by writing to offsets 0C00 and 0C01 (right and left brakes respectively). The reason it probably doesn't work on some of your add-on aircraft is that they operate their own autobraking so are not affected by the FS autobrake being turned off. I've tried FS9 again today and it certainly doesn't itself turn autobrakes off. You need to examine what you have running! Regards Pete

Not sure why you'd need either just to set a flap position. It is a simple FS control. It is surely obvious? In line 12, as it says, you have tried to call a function called "marco" which is not defined - i.e. it is still "nil". (Everything in Lua is "nil" until it is defined -- it means "undefined"). No. There is no function called "marco" in the ipc library. Maybe you mean "macro"? You need to be more careful, and maybe use a magnifying glass to see such typing errors? ;-) Pete

No, you forgot to enable Event logging. It's one of the check boxes on the Left side of the Logging tab. We can see that the autobrakes are turned off but there's no evidence as to why. In case it is an add-on changing this via FSUIPC you could also enable IPC write logging, another check box on the left. But only do any of this on approach, and switch off after landing. Also I see you started a new log by pushing the New Log button. Please don't. Only do the things I list. By starting a new log the details of the aircraft being used are lost, amongst other things. Pete

Hmmm. I haven't used FS9 for a few years, but I seem to remember always having the problem that the autobrakes didn't switch off automatically at all, even when they should. As I said, if I forgot to turn them off manually after slowing down it was impossible to taxi! Are you sure you haven't got some add-on software doing this? Maybe a third party DLL in the modules folder? You might get some more feedback on this if you ask around over in the FS2004 Forum. [LATER] It occurs to me that if you want to investigate this a little more, use some FSUIPC facilities: On approach, before landing, go into FSUIPC options and: 1) enable Event logging, and 2) On the right-hand side of that Logging tab, enter offset 2F80 and type "U8", and check the "normal log" option below. This will log any FS commands, including any operating the autobrakes, and any changes to the offset controlling and reflecting the autobrake switch (0=RTO, 1=Off to 5 for 'Max'). Post the log here if you want help interpreting it. Regards Pete

I didn't think the red "Brakes" notice came up on autobrake operation in any case. I think the autobrakes should switch off automatically if you use manual (or pedal, rather) braking, but I don't think that worked -- in FS9 at least, I remember you had to turn them off manually or you couldn't taxi off the runway. Pete

Good! Well done! Pete

Do not even try installing such an old outdated and unsupported version! The earliest supported version is 4.60, and you MUST use the Installer. It is the Installer which enables FSUIPC to run, and it does the checks to make sure it can run. It is pointless trying to bypass it. Pete

No. More likely you are trying to do this in a 16-bit word, where, of course, as soon as you multiply by 360 you overflow its capacity. The value 65535 for instance (the largest possible value in a 16-bit unsigned word as 0E92 is) represents 359.99degrees. Ty multiplying 65535 by 360 then dividing by 65536. Use a calculator. What do you get? Now wonder why you aren't getting the same result. Anyway, why not use the tools provided to show you what is going on? FSInterrogate, FSUIPC logging, and the FSUIPC Monitor. Please help yourself by using what is provided! You are most certainly making a mistake then. Use the tools as I just said.

Have you tested on a default aircraft? The control works fine on all of those. If it doesn't on this add-on aircraft it is because they've done their own thing. I'm sorry, but I cannot get every aircraft and hack into them all. FSUIPC supports all default controls. If you need to program others then you may have up to 4 choices: 1. Use any keyboard short-cuts the aircraft maker has provided 2. See if FSUIPC mouse macros work -- this depends on the gauges using C/C++ gauge SDK methods 3. See if you can do it via L:Vars, using a Lua plug-in. This often suits XML gauges. 4. Finally, resort to something like Key2Mouse (by Luciano Napolitano) to convert keypresses to mouse moves and clicks. Regards, Pete

No, it is similar, surely. For example, for the Altitude display you read an L:Var, and if it has changed you set a display. Doing the same with the lights is almost identical. Just a different L:Var and different gfd commands to light or extinguish the LED -- I even told you which commands they were, remember? Look, here's your code for the Altitude: prevalt = -1 ... alt = ipc.readLvar("L:AB_AP_ALT_Select") if (alt ~= prevalt) then stringalt = string.format("%05d", alt) gfd.setDisplay(GFMCP,0,4,stringalt) prevalt = alt end So, for Landing Lights: prevlandlt = -1 ... landlt = ipc.readLvar("L:Landlight_switch") if (landlt ~= prevlandlt) then if landlt == 0 then gfd.ClearLight(GFMCP,0,) -- change to the correct light number! else gfd.SetLight(GFMCP,0,) -- change to the correct light number! end prevalt = alt end Just find out (by experiment, maybe) what light number it is and put that where I've shown . You can insert any number of these in your ipcReady.lua. Regards Pete

That message is from the Installer, NOT from running FSUIPC4. You don't run FSUIPC4, FSX does. I really need to know the version number of the FSUIPC4 you are trying to install. If it isn't at least 4.60 please go get that and try again. If it still fails, and assuming you've not stopped the Windows cryptographic service, and that you've already checked that SimFlight is not listed in the untrusted publishers list in Internet Explorer, then please see the Announcement in this Forum which gives a number of suggestions. It's the one entitled "Help with FSUIPC4 code signature problem". Pete

Sorry, but I don't understand what you want to do. None of that makes any sense to me I'm afraid. Can you try explaining what it is you want to do a different way? Pete

It's more important what the log doesn't show, and it doesn't show the EVENT resulting from your assigned button pressing. Try it on a default aircraft and you'll see what I mean. It looks like that aircraft is trapping that event for its own purposes. Regards Pete

You do it just like the Lua for the digital displays -- in fact add them in there. You need to read the L:var and when it changes use the GFD library function "gfd.SetLight" to turn a light on, and "gfd.ClearLight" to turn it off. You'll need to work out the ID's for the lights. I don't remember if they are numbered from 0 from the left or right, but probably left. Yes, fine. Regards Pete

I'm a bit reluctant as there's precious little room. I had to abbreviate the pointer to the website a while back, already. Can you explain which you need different INI files? The facilities in FSUIPC should be flexible enough to avoid that. Regards Pete

Yes, new post with explanation. If you can assure me it is fully tested I'll make it a stickie. Make sure the title is relevant, please. you'll need to mention the AirbusX as well as the GF-MCP in the title -- and Lua, not "lau". ;-) Pete

You can always examine the log file at your leisure. You don't need to rely only on the screen copy. Regards Pete

How do those values (659 and 653) relate to what is going on? Any idea what the word "Drag" in these names has to do with it? doesn't seem an obvious name for what you want! You need to observe what happens to the variables whne changing the value on screen. That wouldn't change a value by 100 but set it to 100 instead. If you want to increment a value you'd have to READ it first, add the 100, then WRITE it back! I'm not surprised. Why not start a proper separate Lua file. Seems daft to insert a line into something designed to do something else. Regards Pete

Well, it is more to do with how fast you need to see it change. Set it to a normal update frequency by default. Probably 100 (for 10 updates per second), or at minimum 50 (for 20). Pete