Simconnect SDK upgrade?

[paolo]

Hello,
I'm a FSX users and for my cockpit I have developed a driver to manage the communication from my hardware to FSX panel. To do this I use simconnect variables. My problem is that this is an incomplete SDK, at the moment is not possible to manage all the panel gauge variable, for example, very important for me, the EFIS panel. I need to know if I can hope in some SDK news with this variables or if I can not hope anymore.

Regards,
Paolo

 

[paolo]

No answer by MSFSX team? I' have patience but... at least yes or not.

Paolo

 

[Pete Dowson]

No answer by MSFSX team? I' have patience but... at least yes or not.

You been missing all the News, Paolo? The ACES Studio, including all of the FSX, ESP and TS2 teams, was closed last Friday. about 94 out of the 100 people lost their jobs. Only six folks remain to tidy up and archive the code, and they have 6 months.

No more FS or TS development for the foreseeable future!

Regards

Pete

 

[Simon853]

Yeah, last week MS released their latest FSX SDK, (that's Software Destruction Kit.)

Edit:
I've been thinking about your EFIS problem and there might be a way around it, but it's not going to be easy...
Since the G1000 in FS is all xml code, you could edit that and insert code to copy local gauge "G" variables into application-wide "L" variables. Then you could write a C gauge that uses execute_calculator_code() to get at them. If you put SimConnect client code in your C gauge, you can then use that to create a ClientData area to exchange them with an external SimConnect client application. See, I said it wouldn't be easy!

Si

 

[Pete Dowson]

Since the G1000 in FS is all xml code, you could edit that and insert code to copy local gauge "G" variables into application-wide "L" variables.

Isn't that the other way around? G = Global, L = Local?

Paolo is concerned with the 738 EFIS panel, the one with the ND mode and range and display selector buttons on it. I had a look at it and it too stores those values in L: variables -- which of course I cannot get access to in FSUIPC as they are local. I was thinking of hacking down into the FS panels code to see if I could locate them anyway, but it's a mess when it's XML implementation.

The problem with needing to change the XML is that Paolo cannot send his customers altered Microsoft files. It isn't legal. What he could do, I suppose, is provide a utility program which patched the user's own copy, on his own PC. That would be okay I think.

Wouldn't it be possible simply to change the L: variables to G: variables with the same names? I couldn't see where they were declared or generated either way. My problem is that I don't know XML at all.

Then you could write a C gauge that uses execute_calculator_code() to get at them.

Actually, the rest of Paolo's driver uses FSUIPC, so if this is required I would add the code to FSUIPC and map the variables to offsets.

Regards

Pete

 

[paolo]

No, I did not know this bad news about MS FS team. So I can not hope in some simconnect news. I can only hope that Pete can find a way, also that seem not easy.

Pete, thanks again for your effort.

Regards
Paolo

 

[Simon853]

Isn't that the other way around? G = Global, L = Local?

You may be right. I've only ever used L vars as all my stuff is usually contained within the same cab or .gau. I've used L vars to exchange switch and system state information between gauges and the 3D model so I assumed they were more global than just the gauge in question. I guess trial and error is the way to go..

Good point about the IPR with regards the MS code.

Si

 

[Pete Dowson]

You may be right. I've only ever used L vars as all my stuff is usually contained within the same cab or .gau. I've used L vars to exchange switch and system state information between gauges and the 3D model so I assumed they were more global than just the gauge in question. I guess trial and error is the way to go.

Well, I've checked the SDK docs, and the L: and G: types aren't what I thought.

G: is defined as "local to the gauge", so you are correct there.

L: is defined as "defined by the developer".

I have no idea what the scope of the latter is, but all the ones we need in the EFIS gauge are L: types, but so far I've not been able to get to them using "execute_calculator_code" calls. Maybe I'm doing it wrong.

The variables are:

L: Display Scale
L: MapItem Shown
L: EFIS Mode
L: EFIS VORADF1
L: EFIS VORADF2
L: MFD Centered

What is worrying is that there is also one called L:Init, used as a marker to determine whether the gauge has been initialised. I suspect that this must be local, or it could easily clash with many others also called "Init".

Maybe when addressing L: variables some more identification is needed?

All this XML and Gauge stuff is new to me and I must admit to being quite baffled. I'm just fumbling my way about at present.

Regards

Pete

 

[Pete Dowson]

Progress!

I can use execute_calculator_code to read the L: variables. In my previous tests I had the wrong type. I used "enum" and they looked like they should be (and SimConnect would have accepted that), but it seems they need type "number" instead.

I can read them all, and I'm now experimenting with writing them .. with partial success so far.

I'll email you, Paolo, when I have something positive for you to use.

Regards
Pete

 

[Simon853]

This is my code library for reading and writing XML variables. It works for L and A variables and can be added to to cope with G vars.

inline void SetLVar64(FLOAT64 val,char *str)
{
	sprintf_s(VarCommandString,VAR_STRLEN,"%f (>L:%s)",val,str);
	execute_calculator_code((PCSTRINGZ)VarCommandString,NULL,NULL,NULL);
}

inline void SetLVar32(SINT32 val,char *str)
{
	sprintf_s(VarCommandString,VAR_STRLEN,"%d (>L:%s)",val,str);
	execute_calculator_code((PCSTRINGZ)VarCommandString,NULL,NULL,NULL);
}

inline void SetAVar32(SINT32 val,char *str)
{
	int ret;
	sprintf_s(VarCommandString,VAR_STRLEN,"%d (>A:%s)",val,str);
	ret = execute_calculator_code((PCSTRINGZ)VarCommandString,NULL,NULL,NULL);
	ret=ret;
}

inline void SetAVar64(FLOAT64 val,char *str)
{
	sprintf_s(VarCommandString,VAR_STRLEN,"%f (>A:%s)",val,str);
	execute_calculator_code((PCSTRINGZ)VarCommandString,NULL,NULL,NULL);
}

inline void SetKVar64(FLOAT64 val,char *str)
{
	sprintf_s(VarCommandString,VAR_STRLEN,"%f (>K:%s)",val,str);
	execute_calculator_code((PCSTRINGZ)VarCommandString,NULL,NULL,NULL);
}

inline void SetKVar32(SINT32 val,char *str)
{
	sprintf_s(VarCommandString,VAR_STRLEN,"%d (>K:%s)",val,str);
	execute_calculator_code((PCSTRINGZ)VarCommandString,NULL,NULL,NULL);
}

inline void SetKEvent(char *str)
{
	sprintf_s(VarCommandString,VAR_STRLEN,"(>K:%s)",str);
	execute_calculator_code((PCSTRINGZ)VarCommandString,NULL,NULL,NULL);
}

inline SINT32 GetLVar32(char *str)
{
	SINT32 val;
	sprintf_s(VarCommandString,VAR_STRLEN,"(L:%s)",str);
	execute_calculator_code((PCSTRINGZ)VarCommandString,NULL,&val,NULL);
	return val;
}

inline FLOAT64 GetLVar64(char *str)
{
	FLOAT64 val;
	sprintf_s(VarCommandString,VAR_STRLEN,"(L:%s)",str);
	execute_calculator_code((PCSTRINGZ)VarCommandString,&val,NULL,NULL);
	return val;
}

inline SINT32 GetPVar32(char *str)
{
	SINT32 val;
	sprintf_s(VarCommandString,VAR_STRLEN,"(P:%s)",str);
	execute_calculator_code((PCSTRINGZ)VarCommandString,NULL,&val,NULL);
	return val;
}

inline FLOAT64 GetPVar64(char *str)
{
	FLOAT64 val;
	sprintf_s(VarCommandString,VAR_STRLEN,"(P:%s)",str);
	execute_calculator_code((PCSTRINGZ)VarCommandString,&val,NULL,NULL);
	return val;
}

inline SINT32 GetAVar32(char *str)
{
	SINT32 val;
	sprintf_s(VarCommandString,VAR_STRLEN,"(A:%s)",str);
	execute_calculator_code((PCSTRINGZ)VarCommandString,NULL,&val,NULL);
	return val;
}

inline FLOAT64 GetAVar64(char *str)
{
	FLOAT64 val;
	sprintf_s(VarCommandString,VAR_STRLEN,"(A:%s)",str);
	execute_calculator_code((PCSTRINGZ)VarCommandString,&val,NULL,NULL);
	return val;
}

inline PCSTRINGZ GetAVarString(char *str)
{
	PCSTRINGZ val;
	sprintf_s(VarCommandString,VAR_STRLEN,"(A:%s)",str);
	execute_calculator_code((PCSTRINGZ)VarCommandString,NULL,NULL,&val);

	return val;
}

Note that the string you pass is in the format "name,type", i.e.:

FLOAT64 val = GetAVar64("RELATIVE WIND VELOCITY BODY Z,knots");

or:

SetLVar64(99.9,"MY_LVAR,percent");

VAR_STRLEN is a #define set to my maximum string length, which I arbitrarily set to 64.
VarCommandString is a global string, to save memory and stack processing time, allocated as:

#define VAR_STRLEN 64
static char VarCommandString[VAR_STRLEN];


But I must admit that I've not tried all functions or units. (A lot I wrote and haven't needed to use.)

Si

PS. For anyone else stumbling across this in the future, these only work in C gauges, not SimConnect client applications.

 

[n4gix]

Progress!

I can use execute_calculator_code to read the L: variables. In my previous tests I had the wrong type. I used "enum" and they looked like they should be (and SimConnect would have accepted that), but it seems they need type "number" instead.

I can read them all, and I'm now experimenting with writing them .. with partial success so far.

Pete, this might save some time and hair:

http://forums.flightsim.com/fswiki/index.php/Code_Sample:_XML_Variables_in_C_Gauges

There are two methods that may be used to read/write to XML variables that're described in that Wiki page I wrote.

BTW, as far as XML is concerned, the "units" you use in the C call must match the "units" used in the XML gauge script...

...also, by definition all L:vars are stored as FLOAT64, which also means they cannot hold strings. The "units" tag performs the C equivalent of a cast to a specific data type; FLOAT64 or SINT32...

IOW, if the units are "bool" then use an SINT32 C variable, otherwise use a FLOAT64 C variable.

 

[Pete Dowson]

Thanks Si and Bill!

I've got it all working, both read and write, for the default 738 EFIS gauge. My main error was expecting FS to be as flexible about the units as SimConnect is. Once I made the units agree with those in the XML it was a doddle to read them.

Writing was a bit more pernickity. The interpretation of the string sent in the execute_calculator_code seems very fussy. Initially I put parentheses around the numeric value to be written, then I omitted them but didn't insert a space. Seems it needs a space between elements even if the next character is a ( character anyway -- I didn't see that in the XML source till I looked much more carefully!

Thanks again, I now have offsets for the 738 EFIS. I might add some FSUIPC controls for it too.

Pete

 

[Simon853]

Ah, well it's refreshing to know I'm helping you for a change instead of the normal other way around. Pleased to be of service!!

All this EFIS talk is actually quite intruiging... At work at the moment I'm putting together a cockpit training simulator for an experimental aircraft using X-Plane. We need an EFIS for it and the X-Plane EFIS add-on only supports 2 engines. I had suggested I looked at whether I could network ESP to X-Plane and drive the EFIS from it via an interfacing program but discounted it as I didn't think I'd be able to override all the MS variables that it uses. But as it's all XML I may well be able to extend its functionality and do something.

Si

 

[n4gix]

Writing was a bit more pernickity. The interpretation of the string sent in the execute_calculator_code seems very fussy. Initially I put parentheses around the numeric value to be written, then I omitted them but didn't insert a space. Seems it needs a space between elements even if the next character is a ( character anyway -- I didn't see that in the XML source till I looked much more carefully!

Cool! Spaces (or lack thereof) are in fact an integral part of the XML schema...

For example, "if { " is invalid; "if{ " is valid. The absent space between "if" and the curly brace is obvious. The space following the curly brace is required, albeit invisible!

Also, the inconsistencies within the XML schema were obviously crafted to drive anyone completely insane...

...as the syntax rules are completely different within a <String> evaluation!

 

[n4gix]

This is my code library for reading and writing XML variables.

Very nice, Si! Might I ask permission to archive those in my Wiki pages (with full attribution of course)?

 

[Pete Dowson]

For anyone else stumbling across this in the future, these only work in C gauges, not SimConnect client applications.

Odd. The technique works fine in FSUIPC4, which is most emphatically a SimConnect client application.

Perhaps you meant to say that they only work inside the FSX process, i.e. from a gauge or DLL?

Regards

Pete

 

[Simon853]

Very nice, Si! Might I ask permission to archive those in my Wiki pages (with full attribution of course)?

Sure, no problem.

Perhaps you meant to say that they only work inside the FSX process, i.e. from a gauge or DLL?

Yes, that's a better description.

Si

 

[Geoff_D]

Peter

I hope you were not planning to "retire" soon !!!

With Microsoft's FREEZE on further FSX developement, there would seem to be a lot of possibilities to add some new functionality to FSUIPC, even if it means a little of the old "non simconnect methodology".

It's not as if a new version of FS is just around the corner, to require "re-investigating" of non-simconnect methods.

If at some time in the future, work resumes on a new MSFS, then hopefully any exposure you have added in FSUIPC, would be incorporated into Simconnect in the next FS version.

Geoff

 

[Pete Dowson]

I hope you were not planning to "retire" soon !!!

No. I did that years ago and it didn't work! ;-)

With Microsoft's FREEZE on further FSX developement, there would seem to be a lot of possibilities to add some new functionality to FSUIPC, even if it means a little of the old "non simconnect methodology".

Hacking into the code, you mean. I was worried about that. With the current deficiencies in FSX and ESP I was negotiating with my contacts in MS for them to be sorted in ESP2 and FSXI. Now those products are no more, I suppose folks will be pressing for other ways.

Quite honestly I don't enjoy it these days like I used to. FS9 was a nightmare and I succeeded, but it made me ill with the hours I spent and the beers I had to consume to stay awake (yes, beer works for me, not coffee like most programmers).

Code produced by modern compilers -- optimised in weird ways for pipelines and so forth, and convoluted through classes and heirarchy, with everything locked away through virtual interfaces and the like (yes, I mix up all that terminology, sorry) -- is really really tiresome to wade through and make sense of.

I might consider it as a last resort for something mighty important, but otherwise I'd looks for less efficient but lazier answers, like the use of "execute_calculator_code" above in order to get at the EFIS switches.

If at some time in the future, work resumes on a new MSFS, then hopefully any exposure you have added in FSUIPC, would be incorporated into Simconnect in the next FS version.

Any new version of FS won't look anything like any past version, from the inside especially. And I really can't see anyone copying SimConnect. I certainly wouldn't do it that way. Of course I wouldn't have done FSUIPC the way I did if the design hadn't just been extended on the original IPC interface Adam Szofran made. Continuity forced continuation.

In the probably more than 5 years to when there might be another "FS" (as opposed to a grown up X-Plane, for example) I shall certainly be "retired" more properly, I hope, and doing more flying and maybe even re-programming my model railway at long last -- it's near time I retired that Commodore Amiga! ;-)

Regards

Pete

 

[paolo]

Hello Pete, good news about the EFI737. Do you think that will be possible to manage the EFIS functions only for B737 or also the EFIS functions for the A320 of FSX defualt?

Regards,
Paolo
CPflight