Jump to content
The simFlight Network Forums

Recommended Posts

Posted

What I'm trying to do

I'm writing a lua script that will determine what physical GoFlight switches are switched on and then set the aircraft switches accordingly.

What I have

n = gfd.Buttons() -- Gets the State of the switches on the T8
ipc.display(n) -- Displays the returned value

What I need

I need to break down the returned value so I can determine the state of individual switches. I believe it's done with either masks or a math function/formula, I don't know or remember which.

Can someone point me in the right direction?

Thanks,

Joe

Posted

n = gfd.Buttons() -- Gets the State of the switches on the T8
ipc.display(n) -- Displays the returned value

Is that your complete code? Because you need to use gfd.GetValues beforehand, as the documentation says. All "gfd.Buttons" does is decode the buttons value from all the data obtained by the last gfd.GetValues.

If you want individual buttons you'd be better off using gfd.TestButton in any case. Just have a loop testing each possible button from 0 to 31.

I need to break down the returned value so I can determine the state of individual switches. I believe it's done with either masks or a math function/formula, I don't know or remember which.

As the documentation says, each of the 32 bits in the returned value represents a button setting. You'd need to test each bit separately using the logic.And function with a mask, starting with 0x00000001 for button 0, doubling each time till you get to 0x80000000 for button 31.

Can someone point me in the right direction?

For a short tutorial on numbers, bits and masks see the FAQ thread entitled About bits, numbers and hexadecimal ...

Regards

Pete

Posted

Thanks Pete, Yes I did include the gfd.GetValues command. I just missed that line when pasting into the forum.

Here's what I came up with last night. It may not be pretty but it works.

gfd.GetValues(GFT8,1) -- Get values of GFT8 Unit 1
n = gfd.Buttons()
--ipc.display(n)
if n >= 128 then -- Switch 8 is ON
  ipc.writeSB("0bc8",1)
  n = n - 128
else
  ipc.writeSB("0bc8",0)
end
if n >= 64 then -- Switch 7 is ON
  ipc.writeSB("2438",1)
  n = n - 64
else
  ipc.writeSB("2438",0)
end
if n >= 32 then -- Switch 6 is ON
  ipc.writeSB("0bcc",1)
  n = n - 32
else
  ipc.writeSB("0bcc",0)
end
if n >= 16 then -- Switch 5 is ON
  ipc.writeSB("3104",1)
  n = n - 16
else
  ipc.writeSB("3104",0)
end
if n >= 8 then -- Switch 4 is ON
  ipc.writeSB("132c",1)
  n = n - 8
else
  ipc.writeSB("132c",0)
end
if n >= 4 then -- Switch 3 is ON
  ipc.writeSB("3103",1)
  n = n -  4
else
  ipc.writeSB("3103",0)
end
if n >= 2 then -- Switch 2 is ON
  ipc.writeSB("3101",1)
  n = n - 2
else
  ipc.writeSB("3101",0)
end
if n >= 1 then -- Switch 1 is ON
  ipc.writeSB("3102",1)
else
  ipc.writeSB("3102",0)
end

Posted

Thanks Pete, Yes I did include the gfd.GetValues command. I just missed that line when pasting into the forum.

Here's what I came up with last night. It may not be pretty but it works.

Still, it would be a darn sight shorter to just test each button separately using the gfd.TestButton function as I suggested.

gfd.GetValues(GFT8,1) -- Get values of GFT8 Unit 1
if gfd.TestButton(7) then -- Switch 8 is ON
  ipc.writeSB("0bc8",1)
else
  ipc.writeSB("0bc8",0)
end

-- et cetera for TestButton(6) down to (0).

The TestButton function is surely made for doing exactly what you are doing?

Regards

Pete

Posted

Still, it would be a darn sight shorter to just test each button separately using the gfd.TestButton function as I suggested.

gfd.GetValues(GFT8,1) -- Get values of GFT8 Unit 1
if gfd.TestButton(7) then -- Switch 8 is ON
  ipc.writeSB("0bc8",1)
else
  ipc.writeSB("0bc8",0)
end

-- et cetera for TestButton(6) down to (0).

The TestButton function is surely made for doing exactly what you are doing?

Regards

Pete

I hadn't investigated the TestButton when I last wrote. I was just going to get into that until I saw you provided that example. You beat me to it... Thanks for your time and efforts. I'll get on it.

You're awesome Mr. Dowson.

Posted

I'm receiving a Lua Error...

********* LUA: "GF-ModDisp" Log [from FSUIPC version 3.997c] *********

1423578 System time = 01/08/2011 16:07:48, FS2004 time = 15:45:19 (22:45Z)

1423578 LUA: beginning "D:\FS2004-FS9\MODULES\GF-ModDisp.lua"

1423578 *** LUA Error: D:\FS2004-FS9\MODULES\GF-ModDisp.lua:24: <name> or '...' expected near '1'

1423578 LUA: ended "D:\FS2004-FS9\MODULES\GF-ModDisp.lua"

1423578 System time = 01/08/2011 16:07:48, FS2004 time = 15:45:19 (22:45Z)

********* LUA execution terminated: Log Closed *********

I'm guessing that 24 is the line number? This is line 24 of the Llua file.

function CHKPWRSWT(GFT8, 1) -- CHECK POWER SWITCHES

I can't see the problem. I've attached the whole file as a txt.

GF-ModDisp.txt

Posted

I suppose it's a good thing I'm a tinkerer.

According to the Lua Library Reference the function syntax is...

function-name(model, unit)

The function in question works without parameters.

function NAME()

Posted

I'm receiving a Lua Error...

I'm guessing that 24 is the line number? This is line 24 of the Llua file.

function CHKPWRSWT(GFT8, 1) -- CHECK POWER SWITCHES

I can't see the problem. I've attached the whole file as a txt.

The error in line 24 is that your are definining a function, CHKPWRSWT, with constants (the numbers GFT8 and 1) instead of parameter names to be replaced by the real values when it is called. The values of the parameters to a function are provided by the CALLER., you cannot pre-define them as fixed amounts in the definition. The normal purpose of a function is to operate on values it is called with.

Your subsequent message said:

According to the Lua Library Reference the function syntax is...

function-name(model, unit)

Yes, the model and unit parameter names represent values which will be supplied to the function by whatever calls it -- in this case

event.gfd(GFT8, 1,"CHKPWRSWT") -- Check All Power Switches

which will obviously supply it with GFT8 and 1 as values "model" and "unit" respectively.

The function in question works without parameters.

function NAME()

It will do because you are only calling it with that one event, and you are explicitly using GFT8 and 1 internally to the function, ignoring any possibly supplied parameters. If you wanted to use the same function for multiple GoFlight units you'd need to replace all the explicit references in it by the parameter values, "model" and "unit". Then you could call it for any GFD event.

It is better really to keep functions generalised so you can reuse them, but if it's a one-off throwaway it doesn't matter so much. However, bear it in mind for the future as you may want to expand your Lua usage one day! ;-)

Regards

Pete

Posted

So I thought I would create a blank while... do block

RTF = ipc.readUB("3364") -- If "Ready to fly"
MENUPAUSE = ipc.readUB("3365") -- Pause in Menu
while MENUPAUSE &gt; 0 do
  while RTF &gt; 0 do
  end
end

I could be wrong but I would think this would loop until both offsets are zero and then run the rest of my code.

They both either don't loop at all because the condition is not true, or they loop forever because nothing inside the loops changes anything you are testing.

When there's no code in a loop, nothing happens. You'd have to reread the offset on every loop execution to see if it had changed. Once you copied a value into a variable, like RTF and MENUPAUSE, it stays in that variable until you put some other value into it. If it changed on its own, spontaneously, it would be no good if you needed to do computations on it, would it? Think about it as if you were reading the airspeed, say, or the aircraft position? How would you ever be able to use it more than once if it changed without you re-reading it?

Also, having a loop within a loop just to test two conditions is very wasteful. You should test them both together. So you could do something like:

while (ipc.readUB("3364") ~= 0) or (ipc.readUB("3365") ~= 0) do
end

As in English, "or" means one or the other. The other condition joiner is "and" meand both one and the other.

Notice I've changed the tests to ~= 0 (not equal zero) rather than greater than zero, because it is more logical when that is what you really mean. I know it males no difference here, but one day it will.

However, because this is going round the loop reading those offsets as fast as possible (at least 1000 times per second), you will be clobbering performance and virtually killing FSUIPC with such a loop. So, in any such loops, always include a "sleep":

while (ipc.readUB("3364") ~= 0) or (ipc.readUB("3365") ~= 0) do
    ipc.sleep(500)
end

That sleep will make it check every half second = (500 milliseconds), which should be fast enough?

The other thing you should notice is that the two bytes you are testing ate next to each other -- 3364 and 3365, so you would be better reading them as one 2-byte (16-bit) Word, ending up with:

 while ipc.readUW("3364") ~= 0 do
	ipc.sleep(500)
end

So then I thought I would add an ipc.ask command. According to the log, it's asking the question, but when I get in the aircraft, there's no question displayed.

I can't help with this because there's no information provided. Sorry.

Pete

Posted

I'm terribly sorry... When I got it to work how I wanted, I went back to my post and tried to remove it.

So I'm very sorry to say, I once again, wasted your time.

I did however take your suggestion about the looping...

ipc.display("Loaded, Please wait")
ipc.sleep(4000) -- Wait until next two offsets are initialised
while (ipc.readUB("3364") ~= 0) or (ipc.readUB("3365") ~= 0) do
  ipc.sleep(333)
end
ipc.sleep(2000) -- waits until aircraft is initialized within the sim
gfd.BlankAll()

Now I need to figure out why my light switches keep turning on and off. It never ends.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.