Reading variables from GSX

[FlyingCoder]

Hi ! I would like to ask, is it possible to read variables from GSX addon manager or panel? I am making my own software to simulator passenger boarding, catering etc, however, based on the manual from GSX, it requires me to read or retrieve variables. Here is the code from GSX manual. I am using C++ winform CLR to develop the software. Hope to get some help and clarification. Thank you 🙂

 

Here’s a C/C++ example code to read an L: variable safely:

// Panels will be filled at start by PANELS.DLL

EXTERN_C PANELS *Panels = NULL;
if (Panels)
{  
	int idVar = -1;  
	FLOAT64 value = 0;  // check if the variable exists  
	idVar = Panels->check_named_variable(“FSDT_GSX_CATERING_STATE”);  // read the value only if registration succeeded.  
	if (idVar != -1)    
		value = Panels->get_named_variable_value(idVar);
}

 

[Pete Dowson]

14 minutes ago, FlyingCoder said:

I would like to ask, is it possible to read variables from GSX addon manager or panel? I am making my own software to simulator passenger boarding, catering etc, however, based on the manual from GSX, it requires me to read or retrieve variables. Here is the code from GSX manual. I am using C++ winform CLR to develop the software. Hope to get some help and clarification. Thank you 🙂

Wouldn't it be better to ask this of the GSX authors, or at least on their forum?  Not sure how you think this relates to FSUIPC?

Pete

 

[FlyingCoder]

I did, this is what they got.

- Use FSUIPC and interface with it, to get the L: variables and send them back to your application.

[Pete Dowson]

2 hours ago, FlyingCoder said:

I did, this is what they got.

- Use FSUIPC and interface with it, to get the L: variables and send them back to your application.

Ah, if the values are available via Lvars, then you can either use a Lua plug-in to read them, or program an FSUIPC interface into your program and use the offset facilities to request the LVars.

The Lua facilities are documented in the Lua PDFs installed with the FSUIPC documentation, and the interface to FSUIPC is documented in the FSUIPC SDK. Or you could use Paul Henty's .NET DLL.  Check this thread:

Pete

 

[FlyingCoder]

Hi pete, thanks for the reply. REgarding LUA, is it difficult or is the process hard ? Im currently looking at the documents but i am not sure where to start. I am also wondering how do i link my software with the LUA script

[FlyingCoder]

Oh yes forget to mention, my software is soemthing related with passenger announcement, GSX data retrieval etc,

[John Dowson]

14 minutes ago, FlyingCoder said:

I am also wondering how do i link my software with the LUA script

If your software is written in C/C++ then you should look at the SDK, not lua, or Paul's DLL if using managed code / .net.
Lua is just for FSUIPC plugins, as explained in the link that Pete posted.

[FlyingCoder]

FSUIPC SDK or the P3D SDK ?

[Pete Dowson]

9 minutes ago, FlyingCoder said:

my software is soemthing related with passenger announcement, GSX data retrieval etc,

If it is a simple process of reacting to GSX events then possibly a Lua plug-in could do it all, more simply than having an external program interfacing to FSUIPC. Otherwise John is correct of course - better to use the FSUIPC SDK or the .Net client.

1 minute ago, FlyingCoder said:

FSUIPC SDK or the P3D SDK ?

To interface to FSUIPC use the FSUIPC SDK or Paul Henty's .NET DLL.

The P3D SDK will enable you to use SimConnect, build scenery, and make aircraft models, but unfortunately the Local variables used in aircraft panels and add-in DLLs such as that from GSX are only available to other in-process programs -- hence FSUIPC which already has L:Var access built in.

Pete

 

[John Dowson]

4 minutes ago, FlyingCoder said:

FSUIPC SDK or the P3D SDK ?

The FSUIPC SDK. There is no access to lvars from the P3D SDK. Otherwise, you can use the Panels.dll directly, as you do in the posted code fragment. This is what FSUIPC uses internally. You would need to run your program as a dll plugin to P3D to get access to the Panels.dll though.
 

[FlyingCoder]

20 minutes ago, John Dowson said:

The FSUIPC SDK. There is no access to lvars from the P3D SDK. Otherwise, you can use the Panels.dll directly, as you do in the posted code fragment. This is what FSUIPC uses internally. You would need to run your program as a dll plugin to P3D to get access to the Panels.dll though.
 

Hi john, thanks for the reply. Based on the code i posted, i kept getting error like Expected a member name, syntax error ( i feel i was 1 or 2 steps close but the error is just making me wonder. Cause of that, i tried looking for alternatives. I am using C++ CLR Win forms btw to do my software. Maybe like you said, as a DLL.

My program is like ACARS that tracks pilot flight. With an addition to passenger announcement, meals etc similar like fspassenger. However, i am intending to let my program to run a standalone and also being able to get data from sim(which already works). Now im trying to learn to implement much more stuff like GSX boarding, deboarding etc so i can integrate them to make one full complete system. Thats what i have in mind.

As to what i have explain, correct me if im wrong, STANDALONE PROGRAM -> COMMUNICATES WITH DLL TO READ VARIABLE OF GSX -> PASS BACK TO MY PROGRAM. is this the flow if i am right ?

 

[John Dowson]

3 minutes ago, FlyingCoder said:

As to what i have explain, correct me if im wrong, STANDALONE PROGRAM -> COMMUNICATES WITH DLL TO READ VARIABLE OF GSX -> PASS BACK TO MY PROGRAM. is this the flow if i am right ?

No. A standalone program cannot talk to the Panels.dll, which is running inside of P3D. You can only do this if your program is also a dll, running as a plugin to P3D. If your program is standalone, you should use the FSUIPC SDK and request the lvar via the provided offsets.

[FlyingCoder]

Ah i understand now. SInce its a standalone program,  i will try use FSUIPC SDK. Talking about the SDK, which part of the SDK says about LVars ?

[John Dowson]

1 minute ago, FlyingCoder said:

which part of the SDK says about LVars ?

The SDK only provides functions to read/write to the offset area. You can get/set lvars using offset 0x0D70. Check the FSUIPC Offset Status document for details.

[FlyingCoder]

I read it. It says write the complete identity string. So it look like this correct me if im wrong.

 

FSUIPC_Read(0x0D70, 40, "MyVariableNameHere", &result);

 

[John Dowson]

1 minute ago, FlyingCoder said:

I read it

Then please read again:
 

Quote

L:Var read, write and create requests First write the offset address to which the resulting value (an 8-byte double or FLT64) will be written (for a Read) or the value to be written can be found (for a Write and Create). This MUST be one of the user offsets, i.e. in the range 0x66C0 to 0x66F8 (or up to 0x66FF depending on the next setting). This offset value only occupies the low 16-bits (LOWORD) of the 32-bit value. The high part specifies the value format. Assuming the offset is ‘nnnn’, the options are:     0x0nnnn for 64-bit double (as before)     0x1nnnn for 32-bit float (FLT)     0x2nnnn for 32-bit signed integer (SD)         0x3nnnn for 32-bit unsigned integer (UD)     0x4nnnn for 16-bit signed integer (SW)     0x5nnnn for 16-bit unsigned integer (UW)     0x6nnnn for 8-bit signed integer (SB)     0x7nnnn for 8-bit unsigned integer (UB)  With reads into a fixed point value (the last 6 above), the floating point value provided from the Gauge system is rounded to the nearest integer (up for positive numbers, down for negative). Then write to 0D70 the name of the LVar, preceded by just one : (colon) character for a read, :: (two colons) for a write, and (three colons) for a create (and initialise). It should also be terminated by a zero byte. The reason for the use of user offsets is to avoid corruption when more than one application is running which reads L:Vars in this way. It is a matter for the programs, probably with user cooperation, to avoid clashes. Both 0D6C and 0D70 can be written together or at least in one Process call, and the result of a read can be read immediately, even in the same Process call. For a write the value to be written can be placed in the stated offset in the same Process call too, provided it is before the writes to 0D6C and 0D70. If the Lvar does not currently exist the result of a read will be 0.0. There’s no way to detect if a write/create succeeded other than to read the L:var afterwards. If the offset provided is invalid the request is just ignored and the offset value unchanged

 

[FlyingCoder]

Oh kay this is confusing but i will try this.

[John Dowson]

26 minutes ago, FlyingCoder said:

Oh kay this is confusing but i will try this.

Shouldn't be too confusing....basically, you need to:
   - FSUIPC_Write to offset 0D6C , with the value being the offset to receive the value and the value type (as explained in the manual and posted above)
   - FSUIPC_Write to offset 0D70 with the name of the lvar you want to read, preceded by a ':'
   - FSUIPC_Read to the offset you specified in the first write to offset 0D6C

They can all be grouped into the same FSUIPC_Process call.

Edited September 30, 2020 by John Dowson
correction to offset

[FlyingCoder]

Hi john, this is what i came out with. I believe its wrong because im getting weird weird numbers but im trying to understand the flow. Result should be 1 to 6 respectively but getting none of the one i wanted.. Do correct me on where i should put such variable like test and the L:FSDT_GSX_CATERING_STATE.

 

FLOAT64 test;
FSUIPC_Write(0x0D6C, 4, &test, &result);
FSUIPC_Write(0x0D70, 40, "L:FSDT_GSX_CATERING_STATE", &result);
FSUIPC_Read(0x0D6C, 4, &test, &result);
FSUIPC_Process(&result);
cout << test;

 

[John Dowson]

1. you need to write the value of the offset to 0D6C (together with the value type, as explained previously). You are writing an uninitialised value.
2. Your write of the lvar name is incorrect. As stated, it should be the the lvar name preceeded by a colon (':') for read
3. You are reading the result from 0D6C. This is incorrect. The result needs to be read from the offset  that you wrote to the LOWORD of offset 0D6C in step 1.

Please re-read the provided documentation.

[FlyingCoder]

Ah this is confusing. How do i write the value of the offset to 0D6C ? Im doing it wrongly

[John Dowson]

4 minutes ago, FlyingCoder said:

How do i write the value of the offset to 0D6C ? Im doing it wrongly

Yes, you are 'doing it wrongly', as you are writing an uninitialised variable so the contents are undefined /garbage.
You need to set the value (and type of 4 bytes, not a float64 which is 8 bytes!) of your test variable to contain an "unused" user offset vale (e.g. 66C0), together with the type. So, assuming your lvar is an 8-bit unsigned integer, you would need:
     int test = 0x766C0

and use that.

 

[FlyingCoder]

Alright. I have used the one you mentioned. Kinda get the idea that 0x7nnnn = nnnn is 66C0. This is the pdated code.
Regarding about the LVars,
 

DWORD result;
unsigned int test = 0x766C0;
FSUIPC_Write(0x0D6C, 4, &test,&result);
FSUIPC_Write(0x0D70, 40, ":FSDT_GSX_CATERING_STATE", &result);
FSUIPC_Read(0x766C0, 4, &test, &result);
FSUIPC_Process(&result);
cout << test;

 

[John Dowson]

43 minutes ago, FlyingCoder said:

FSUIPC_Read(0x766C0, 4, &test, &result);

But you requested 1 Byte at offset 66C0, so should be:

BOOL = val;
FSUIPC_Read(0x66C0, 1, &val, &result);

Be aware that I've not used this myself, just going by what the documentation says!

[FlyingCoder]

Okay, how about my FSUIPC? Are they correct?