Problem with reading Lvar

[Delphi]

Hi Paul,
I got stuck on a problem to read a certain Lvar from GSX. The issue is ony one Lvar, all other GSX Lvar working fine.

                GSX_NUMPASSENGERS_BOARDING_Total = FSUIPCConnection.ReadLVar("L:FSDT_GSX_NUMPASSENGERS_BOARDING_TOTAL")
                GSX_NUMPASSENGERS_BOARDING = FSUIPCConnection.ReadLVar("L:FSDT_GSX_NUMPASSENGERS_BOARDING")

                GSX_NUMPASSENGERS_DEBOARDING_Total = FSUIPCConnection.ReadLVar("L:FSDT_GSX_NUMPASSENGERS_DEBOARDING_TOTAL")
                GSX_NUMPASSENGERS_DEBOARDING = FSUIPCConnection.ReadLVar("L:FSDT_GSX_NUMPASSENGERS_DEBOARDING")

My internal variables a defined as Double.

GSX_NUMPASSENGERS_DEBOARDING_Total does not has the correct value. It seems to be a copy of GSX_NUMPASSENGERS_BOARDING. I checked the issue already with virtuali from FSDT. He can not find any problem with GSX_NUMPASSENGERS_DEBOARDING_Total.

http://www.fsdreamteam.com/forum/index.php/topic,22950.0.html

I use many other GSX Lvars, too. All other are working.

Kind regards,

Ruediger

[Pete Dowson]

I can't check your Client code for you (I am not familiar with Paul's work), but have you tried checking those L:Vars with either the FSUIPC list LVar control, or viewing changes live using the Log LVars lua plug-in provided in the Lua Examples ZIP in the FSUIPC Documents subfolder?

That might at least show if it's the code or something else.

Also, you need to make sure you are using the current FSUIPC5 release, 5.153, because before that the limit on L:Var name lengths was 32. Yours are longer than that. The limit was increased to 64 in 5.153, released last month. I know this was specifically for macros, but it may affect the offset being used in the programming interface.

Pete

 

[John Dowson]

As we did not communicate the increase in lvar length from 32 to 64 characters, maybe the .net client dll needs updating for this?
Just a thought. Maybe Paul could check this?

Cheers,

John

 

[Delphi]

I repeated the tests with 5.153. Same result as before. Perhaps Paul can check his code. 

Tomorrow I will do the checks as you have proposed, Pete.

Many thanks to you guys for jumping into that thread so fast. I appreciate very much.

Ruediger

[Paul Henty]

Sorry for the delay - I've been on holiday.

The DLL uses 40 characters for the LVAR name (offset 0D70 says 40 bytes in the FSUIPC4 Offsets list).

If this offset is now 64 then I can modify the length of my internal offset and it should be okay.

If Pete or John can confirm this is correct I'll make the changes and release a new version to NuGet.

Paul

[John Dowson]

Hi Paul,

no, the size of that offset is still 40 chars and can't be extended to 64. I think I'll have to add another offset for this. Let me take a look and I'll get back to you.

John

[Delphi]

Hi, Paul, hi Pete,

many thanks for the affort you spent on that issue.

Ruediger

[John Dowson]

Hi Paul,

lets keep offset 0D70 for this (for external use). Internally I'll map to a different area so that I can increase the size. I'll look into this over the weekend (hopefully!) and post an updated dll in this topic when ready for testing.

Cheers,

John

[John Dowson]

Hi Paul,

please try the attached dll below which contains FSUIPC v5.153b. This will be officially released as v5.154 at some point. I have re-mapped offset 0D70 internally to a 128 byte array, which should hopefully be sufficient for all future needs.

Note that this is currently only implemented for reads/writes from the SDK, and also the lua ipc.writeSTR and ipc.macro commands. Theoretically you can write to this offset (range) with other lua statements (e.g. ipc.writeUB). I'm not sure whether I should handle these or not at the moment - maybe a clarification in the documentation would suffice. I'll discuss with Pete when he's back from holiday next week.

I've tested via the SDK and via lua, but not with lvar lengths > 40 as I don't think I have any aircraft with such long lvar names (although I guess I could create one....).

Let me know if you have any issues.

Regards,

John

FSUIPC5.dll

[Paul Henty]

Thanks John,

Can you please confirm a few things before I implement the changes to my DLL:

1. 0x0D70 is now 128 bytes long, meaning LVARS up to 128 characters can be requested.

2. It is not safe to write 128 bytes here in FSUIPC4 and 3 so I'll need to check the FSUIPC version in my DLL.

3. Normally these strings are Zero terminated. Is a 0 required at the end if the string is the exact length of the offset. e.g. Can I send 40 characters to a 40-long string offset, or is it only 39 because the end 0 is required.

Paul

[John Dowson]

1 hour ago, Paul Henty said:

1. 0x0D70 is now 128 bytes long, meaning LVARS up to 128 characters can be requested.

Yes, but the length would be 127 characters for read and 126 characters for write (both including the terminating zero), as you need to precede the lvar name with ':' or '::'

1 hour ago, Paul Henty said:

2. It is not safe to write 128 bytes here in FSUIPC4 and 3 so I'll need to check the FSUIPC version in my DLL.

Yes, that is correct.

1 hour ago, Paul Henty said:

3. Normally these strings are Zero terminated. Is a 0 required at the end if the string is the exact length of the offset. e.g. Can I send 40 characters to a 40-long string offset, or is it only 39 because the end 0 is required.

Nothing has changed here, the zero termination is still required.

John

[Paul Henty]

All understood. 

Thanks.

Paul

[Paul Henty]

Ruediger and others...

I've just published 3.1.12 BETA of my DLL. Please use NuGet to update (make sure you tick 'Include prereleases').

Remember you'll also need FSUIPC v5.153b which John kindly posted above.

No code changes are required in your project. The Read/Write LVAR methods should now just work with larger LVAR names.

I can't test this as I don't have P3D so please let me know how it goes.

Thanks,

Paul

[Delphi]

Paul,

done...

Works perfect now. Many thanks....

Thanks too Paul and Pete.

Excellent example of cooperation 🙂

Ruediger

[John Dowson]

Its John, not Pete! Pete has retired, I am now supporting FSUIPC5.

John

[Delphi]

Sorry, I missed that.

Ruediger