Lvar on vb

[jul007]

Hello,

 

Is there an equivalent function in vb for ipc.readLvar(L:vars) ?

 

If yes could you post an example 

 

Regards

Jul

Edited March 14, 2014 by jul007

[Paul Henty]

Hi Jul,

 

There is no way of getting L:Vars in VB as far as I know. Certainly you cannot access them via the normal FSUIPC interface.

 

You can get and set L:Vars with a LUA plugin script. You could monitor the ones you want with an event and when they change write the value to a spare offset. Then your VB application can read them from there. But you'd need to have a Lua script running as well as your application.

 

If your program is only for your use, you can use the free offsets starting at 0x66C0. If it's for general release (including freeware) it's best to ask Pete to allocate some offsets officially for your application.

 

I'm no expert in Lua so there may be other ways to transfer these values to your VB program. You may want to ask about this up in the main forum if Pete doesn't see it here.

 

@Pete: If you do see this is there a better way?

 

Paul

 

[Pete Dowson]

There is no way of getting L:Vars in VB as far as I know. Certainly you cannot access them via the normal FSUIPC interface.

@Pete: If you do see this is there a better way?

 

No, only Lua currently provides a method of reading them. The problem with providing access through an offset-based interface is that L:Vars are only identifiable by name, and need requesting via the Gauge interface into FS.  Whilst writing a name as a string into an offset in order to get something done (like load or save a flight or a paln) is okay -- it's an action initiator and requires no reply -- having one which then has to await a response is not so nice. The question which would arise is how is another request, maybe from a different program, going to be handled? Who gets which reply and where? How can they tell?

 

If there was a desperate need I might try to work something out, but I implemented Lua as a more convenient way of adding facilities to FSUIPC without such horrendous complication on top of the already pretty unwieldy interface inherited from FS6IPC long long ago. So, I'd much rather Lua be used for such things. It is better to add facilities to Lua to implement new things than try to implement them in FSUIPC proper.

 

Regards

Pete

[jul007]

Understood,

 

Just two questions :

 

Is there a way to run Lua plugins on unregistered FSUIPC ?

(I'm searching  a way to create an interface between the majestic dash and fsfk for pilots on VA eg)

 

And How does PMDG in making its gauges compatible with fsfk eg ?

 

Regards,

Jul

[Pete Dowson]

Is there a way to run Lua plugins on unregistered FSUIPC ?

 

No. It is one of the main advantages of purchasing FSUIPC.

 

And How does PMDG in making its gauges compatible with fsfk eg ?

 

 

Sorry, I don't understand this question.

 

Pete

[jerry262]

I'm new to FSUIPC programming so please forgive me if this is a stupid question or if it has been asked a thousand times before but how does one pass several Lvars at a time to FSUIPC offsets as in the status of several warning lights.  If we can use 0x66C0 do we have all of the available hex numbers up to 0x6700. i.e 0x66C1, 0x66C2....0x66FF?

 

Thanks,

 

Jerry

[Paul Henty]

 If we can use 0x66C0 do we have all of the available hex numbers up to 0x6700. i.e 0x66C1, 0x66C2....0x66FF?

 

You have all of that area of memory to use (64 bytes). The offset addresses you use within this block will be determined by what kind of data you are writing there, specifically the length in bytes of each value.

 

If you wanted to write 64 values and each was 1 byte long then you would have all offsets (hex numbers) available.

 

However, let's say you're writing an integer value that is 2 bytes long (e.g. 'short' in most .net languages). The first value would be written to 0x66C0, but it would take up 2 bytes so 0x66C1 would be taken by the second byte. The next available offset would be 0x66C2. (If you wrote anything to 0x66C1 you'd overwrite part of the first value).

 

What you have to do is map out your own offsets within the block based on the length (in bytes) of each value you are writing.

 

Paul

[jerry262]

Thanks for your reply Paul,

So if I understand it.... Since all I really need is to turn on or off lights, I should be able to set each of the 64 bytes to either a 0 or 1 then capture the data with .net and operate the lights accordingly. theoretically I could break it down into bits right?

[Paul Henty]

Yes, the simplest way is to use each byte (each offset number in the block) to store a 1 or 0 value and read these from .net.

 

You could make it more memory efficient by using individual bits, so each byte will hold the state of 8 lights. This is a little more complicated as you'll need to deal with the lua to set and reset each bit individually i.e. ipc.clearbitsUB(offset, mask) and ipc.setbitsUB(offset, mask). If you use my DLL you can declare the offset using the BitArray type to make this easier on the .net side.

 

Paul

[jerry262]

Hi Again,

 

I finally have this all working pretty well with the exception of a very noticeable lag in the lights that rely on the Lua script.

The direct FSUIPC offset lights work without delay but any of the lights that use lvars and therefor require a brief trip through my Lua script delay by 

as much as 5 seconds before responding.

 

I am very new to Lua programming so I'm certain I'm doing something wrong.  Can anybody provide some insight?

 

The VB.net code monitors the state of the FSUIPC offsets and operates the lights accordingly.

I have 8 lights which are operate on standard FSUIPC offsets and thus not used in this script.  They operate without delay

 

Here is an example of the Lua script I am using.  

There are actually 35 entries but they are all basically the same

 

 

while 1 do

n1 = ipc.readLvar("L:B200CFuelCrossfeed")

n2 = ipc.readLvar("L:B200CRvsNotReady")

n3 = ipc.readLvar("L:B200CLBld")

n4 = ipc.readLvar("L:B200CRBld")

 

if n1==1 then

ipc.writeUB(0x66C0, 1)

else

ipc.writeUB(0x66C0, 0)

end

 

if n2==1 then

ipc.writeUB(0x66C1, 1)

else

ipc.writeUB(0x66C1, 0)

end

 

if n3==1 then

ipc.writeUB(0x66C2, 1)

else

ipc.writeUB(0x66C2, 0)

end

 

if n4==1 then

ipc.writeUB(0x66C3, 1)

else

ipc.writeUB(0x66C3, 0)

end

 

ipc.sleep(50)

 

end

 

 

Thanks 

[Paul Henty]

I'm no expert in Lua but you might want to try using the events system rather than a tight loop that updates the offsets every 50ms.

 

I've written the code below but I've no way of testing it.

 

First you define a function to be called when the value of the LVar changes. This function just takes in the Lvar name and its value. All you need yo do is write the new value into the required offset.

 

Then you register this function with the events system which will monitor the LVar value for you and call your function when it changes.

writeN1(varname, value) 
   ipc.writeUB(0x66C0, value) 
end
event.Lvar("B200CFuelCrossfeed", 100, "writeN1")

writeN2(varname, value) 
   ipc.writeUB(0x66C1, value) 
end
event.Lvar("B200CRvsNotReady", 100, "writeN2")

writeN3(varname, value) 
   ipc.writeUB(0x66C2, value) 
end
event.Lvar("B200CLBld", 100, "writeN3")

writeN4(varname, value) 
   ipc.writeUB(0x66C3, value) 
end
event.Lvar("B200CRBld", 100, "writeN4")

You may find this has better performance than the continuous loop.

 

Paul