Jump to content
The simFlight Network Forums

WideFS Button Screen II


gfd

Recommended Posts

Greetings

I am working my way through programming the WideFS virtual buttons. I am quite impressed with the result.

 

Currently, WideClient is on my non-FSX networked machine. The lua script I am writing is on the FSX machine.

 

I noticed in the ipc library, that there is a function called ipc.setbtncol. That could be quite useful in allowing me to show non-toggle buttons as on or off. I attempted to add that function to a code block I was writing to change the state of a control in Airbus X. The form of the function was ipc.setbtncol(buttonNumber, r, g, b). I'm sure the function parameter data (button number and the colour numbers) were correct.

 

However, when I activated the control using the virtual button in WideClient, on the networked machine; I got an error message in the log window on the FSX machine. It suggested the function was referring to a nil value. As stated above, the LUA script to manipulate the controls is on the FSX machine. The virtual button screen is on the networked machine.

 

Forgive the long drawn out explanation. Can anybody help me to understand if what I am trying to do is possible? If so, what am I doing wrong?

 

Thanks

Graham

Link to comment
Share on other sites

The official FSUIPC lua documentation states very clearly that the ipc.setbtncol() function is for wideclient only. So this function doesn't exist in the FSUIPC lua library (=nil value), only the wideclient lua library.

 

If your current lua script must be run on the FSX machine then you'll need another script on the wideclient machine that responds to changes in the state of the aircraft systems and colours the buttons accordingly. You could use events for this, monitoring changes in offsets (event.offset()) or changes in LVars (event.Lvar()) depending on how you get the data from your aircraft.

 

Paul

Link to comment
Share on other sites

Well thanks for the reply Paul. When I saw Wideclient only, I assumed that was advisory. OK, at the risk of getting in over my head, would it go something like this:

-ensure copy of ipc library in Wideclient folder on networked machine

-write script which would change colour of button in question also in Wideclient folder

-setup function in client script to take 2 arguments (button number and colour numbers)

-call script on client machine, in script on FSX machine

If this is the right idea, how do I go about calling a script on a differnt machine? If I'm out in left field somewhere, can you give me a rough sketch or point me somewhere I can get the required information?

Thanks again for looking into this,

Graham

Link to comment
Share on other sites

No that's not quite what I suggested.

 

Firstly, can you not just run your current script on the wideclient machine? That would be the easiest way.

 

If your current script must be run on the FSX machine for some reason then I'm suggesting that you make an additional, independent script on the wideclient machine that just sets the button colours. This script has nothing to do with your current script on the FSX machine, and there is no need for communication between the scripts. The wideclient script simply monitors the relevant offset or lvar using the event library (specifically event.offset() and/or event.Lvar()). When these values change you set the button colour accordingly.

 

For example if you have a button for putting the gear up/down you could monitor offset 0x0BEC (nose landing gear position). When this value changes you can colour the button red when the gear is up, green when it's down and orange when it's in transit. Note that this has nothing to do with your existing script or responding to the button presses. It's simply monitoring the gear position in the simulator and sets the appropriate colour

 

If you're not familiar with the Lua events library, it's explained in the "FSUIPC Lua Library.pdf" in it's own chapter. Search for "The Event Library".

 

I'm not an expert in using Lua with FSUIPC but I from what I know this is a viable solution. Anyway, it's a suggestion for you if you want to try something before Pete gets back and gives you a definitive answer.

 

Paul

Link to comment
Share on other sites

Thanks Paul

I thought about it a bit after my first reply. You are of course right. I was looking for a complicated solution to what should be a simple problem.

 

It seems I either autorun a lua file when WideClient opens (event option) or use sendkey in FSUIPC and have WideClient run a script when it receives the appropriate key code. Thank you very much for setting me straight. I'll fool around with these options and hopefully come up with a solution.

 

Thanks again,

Graham

Link to comment
Share on other sites

I decided on using the KeySend option. It works very well. I am having trouble running scripts in WideClient. I don't want to comment further until I have exhausted my efforts to find a solution. If necessary, at that time, I'll create a new post regarding the scripts in WideClient.

Link to comment
Share on other sites

Well thanks for the reply Paul. When I saw Wideclient only, I assumed that was advisory.

 

 

The reason it's WideClient only is that it is for the ButtonScreen, which is a WideClient facility. If there is no WideClient there is no ButtonScreen!

 

-ensure copy of ipc library in Wideclient folder on networked machine

-write script which would change colour of button in question also in Wideclient folder

-setup function in client script to take 2 arguments (button number and colour numbers)

-call script on client machine, in script on FSX machine

 

Why not just use a user offset, such as 66C0, and the assignable offset controls to set values there which can be easily read by your client-run Lua program?

 

It seems I either autorun a lua file when WideClient opens (event option) or use sendkey in FSUIPC and have WideClient run a script when it receives the appropriate key code. 

 

WideClient automatically runs any Lua script it finds in its folder. Use events to determnine when those scripts should actually do somethnig.

 

Pete

Link to comment
Share on other sites

Thanks for the reply.

 

Before going on, I would like to say that I have completed the button screen (btnPress, btncolchange notwithstanding...I'll get that right) and am so very impressed with the difference it makes in using FS. Once I got an idea of what to use in the libraries, and how to construct the script, I was able to complete the screen and 'wire' it into FSUIPC to control FSX. I plagiarized the LINDA code a bit to get the local variables. Of course none of that would have been necessary if LINDA supported your button screen. That is another story...another place. The time I have taken to do this little project has deepened my understanding of FSUIPC and FS. Before this, I wouldn't have known an offset if you had hit me over that head with it.

 

You saved me hundreds of dollars in hardware costs; not to mention the fact that I am running out of USB ports for the hardware. It's fairly rudimentary and some of the LUA programming would be seen as positively grotesque by a more experienced user; but it does much of what I want. Thanks for the functionality!

 

I am only a couple weeks into using LUA. I taught myself how to use C# (very rudimentary...as a hobbyist) and so understand the concept of events. I haven't programmed anything in many years. I don't want to spoonfed, I would prefer to gain the understanding myself. Your replies have given me the places to look for methods to accomplish what I am after.

 

Would I be correct in assuming that to use an event in LUA, I would structure the script as follows:

 

function DoSomething()

 

   <do something>

 

end

 

event(<watchSomething>, "DoSomething")

 

 

I notice in the event library that there is event.Lvar("lvarname", interval, "function_name"). It does not seem to be confined to FSUIPC. If an event on the wideclient machine were to watch for an lvar, would it be listening to the activity on the FSX machine?

 

Do have one final question. I had some trouble getting wideclient to run lua scripts. I kept getting error 193. At the time, I was using notepad to create the scripts and .lua was associated with notepad. Perhaps that was the reason for the error number. I got rid of that association. I installed LuaForWindows. It has the SciT editor and a command interpreter along with a number of libraries; etc. LUA files are now associated with the 'Standalone Command Interpreter'. I don't seem to be getting the error message any longer. However, scripts still don't seem to run. For example, I wrote a script to change the colour of a button.

 

-I set up a KeySend on the FSX machine.

-I associated the KeySend with RunKey on the wideclient machine

-I set up the RunKey to run a LUA script

-the LUA script changed the colour of one of the non-toggle buttons

 

if  not ipc.btnstate(40,0) then    --if button 40 is pressed

ipc.setbtncol(40,153,247,171)     --set button 40 colour to light green
end

 

-that is a non-toggle button on the button screen

-nothing happened

 

Where can I find the answer for this. I must have done something wrong

 

Thanks again for looking in on this,

 

Graham

Link to comment
Share on other sites

Would I be correct in assuming that to use an event in LUA, I would structure the script as follows:

 

function DoSomething()

 

   <do something>

 

end

 

event(<watchSomething>, "DoSomething")

 

 

Yes, that's the general idea.

 

I notice in the event library that there is event.Lvar("lvarname", interval, "function_name"). It does not seem to be confined to FSUIPC. If an event on the wideclient machine were to watch for an lvar, would it be listening to the activity on the FSX machine?

 

 

Ooops! Well spotted -- the red [Not WideClient] notice should be there. Sorry, it isn't possible to use LVars on a client Pc. They are intricately bound into the gauges which use them.

 

Do have one final question. I had some trouble getting wideclient to run lua scripts. I kept getting error 193.
 
193? Reported where?  By Windows? Windows error 193 is "bad EXE -- not a valid EXE program". I don't know how that can be connected to Lua. 
 
LUA files are now associated with the 'Standalone Command Interpreter'.
 
LUA files are simple text files. Just use Notepad or any text editor!
 
I don't seem to be getting the error message any longer. However, scripts still don't seem to run.
 
Any file or filetype .lua placed in the same folder as WideClient will be run as soon as WideClient connects to FS. This has never failed. Check the logging -- Lua files run there are logged.
For example, I wrote a script to change the colour of a button.

 

-I set up a KeySend on the FSX machine.

-I associated the KeySend with RunKey on the wideclient machine

-I set up the RunKey to run a LUA script

-the LUA script changed the colour of one of the non-toggle buttons

 

I assume this Lua was NOT placed in the same folder as WideClient, then?

 

if  not ipc.btnstate(40,0) then    --if button 1 is pressed

ipc.setbtncol(40,153,247,171)     --set button 1 colour to light green

end-that is a non-toggle button on the button screen

 

Where do you find "ipc.btnstate"? What does it mean? And how is (40,0) button 1?

 

You can't just invent your own library functions. You can only use what is there. That line would give you an error, logged in the log for that Lua plug-in -- didn't you look?

 

And note that ipc.setbtncol can't be used on button spaces declared as Toggle.

 

Pete

 

Link to comment
Share on other sites

Thanks for the reply. The dialogue was something to the effect "WideClient cannot run file blah blah error=193".

 

Please forgive me for making a hash of the second bit. I edited it but you beat me to it. Looking at the edit, it wasn't quite right either. Sensory overload. It should read:

 

if not ipc.setbtnstate(40, 0)    --if button 40 is pressed

ipc.setbtncol(40,153,247,171)   --set button 40 colour to light green

end

 

The code wouldn't work anyway, as you pointed out. I missed that. I want to use the functionality for regular buttons. So would something like this work:

 

if ipc.btnPress(40) then

ipc.setbtncol(40, n, n, n)   --changes the colour to reflect it's now the selected position (example landing lights retracted)

ipc.setbtncol(41, n, n, n)    --changes one 'switch postition to a different colour to reflect it's no longer the selected position (example landing lights off)

ipc.setbtncol(42, n, n, n)     --changes the final 'switch position' to the same colour as 42 to reflect it's no longer selected (example landing lights on)

end

 

This would require an event. event.timer()? to watch for button pushes. And I imagine I would either have to make about 12 if statements, or loop through the applicable button numbers in order to determine where to change colours.

 

This would model a light switch. I am mostly interested in checking the state of the switch, primarily where there are more than two switches acting on one control. Landing lights, wipers, etc. I am not trying to invent a better toggle switch. It doesn't get any better than what you have done. I just want to look at the button screen and see the state of not only the push buttons, but also the 'switches'.

 

Thanks once again for taking time out to help me with this. Have a good one,

 

Graham

Link to comment
Share on other sites

Thanks for the reply. The dialogue was something to the effect "WideClient cannot run file blah blah error=193".

 

The "blah blah blah" bit is the important bit.  That error can only occur if you asked Wideclient to run some program or other, as in a "Run" command.

 

Ah, hold on -- didn't you say you were trying to run a Lua program using "RunKey"? That won't work. Lua programs are not recognised as such by Windows. Only a Lua interpreter can run a Lua program.

 

 

Please forgive me for making a hash of the second bit. I edited it but you beat me to it. Looking at the edit, it wasn't quite right either. Sensory overload. It should read:

 

if not ipc.setbtnstate(40, 0)    --if button 40 is pressed

ipc.setbtncol(40,153,247,171)   --set button 40 colour to light green

end

 

The code wouldn't work anyway, as you pointed out. I missed that. I want to use the functionality for regular buttons. So would something like this work:if ipc.btnPress(40) then

 

Yes. "setbtnstate" is for Toggle buttons, whilst "setbtncol" is for non-Toggle buttons.  They are two ways of doing effectively the same thing for the different types.

 

This would require an event. event.timer()? to watch for button pushes. And I imagine I would either have to make about 12 if statements, or loop through the applicable button numbers in order to determine where to change colours.

 

What buttons are you thinking of testing here? I'm completely confused about what you are trying to do. If you want a button to change colour when it is toggled, use the toggle facility. If you want the colour to reflect a state of something in FS it is the offsets in FSUIPC you need to be testing, and you can have events for those.

 

This would model a light switch. I am mostly interested in checking the state of the switch, primarily where there are more than two switches acting on one control. Landing lights, wipers, etc. I am not trying to invent a better toggle switch. It doesn't get any better than what you have done. I just want to look at the button screen and see the state of not only the push buttons, but also the 'switches'.

 

 

 

So you need to test the switch states by having events on the appropriate offsets which reflect the switches in FS. I really don't know why you are concerned with testing buttons, which you can't do anyway on the client except for the relevant offsets which reflect the buttons states in FS.

 

Pete

Link to comment
Share on other sites

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.