• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

P3D v3 Modules DLL questions

R

Ravamar

Messages
100
Country
italy
I'm performing some research on C:VARS using a heavily modified version of the Cabin Comfort sample. What I'm trying to understand is if it would be a good idea to implement something similar to an INS "brain" using a module DLL. The GPS "subsystem" has been implemented in a very similar way, right?

Is there any way to specify runtime parameters? Or do I have to use a configuration file (something like a .properties or .INI) instead?

Also is there any "standard" tool to locate and patch the dll.xml file, to be used during DLL install process?

P.S.: Never define a C:VAR name having a leading number because it will NOT work, I wasted a lot of hours before realizing this :(

Thank you very much in advance!
Marco
 
Hi Marco,

Have you checked XMLTools? It might be useful for what you are looking for.

Classes included can be called either from XML/C++ gauges.

Tom
 
Hi Tom!

I'm trying to implement the INS INU (the black box normally installed in the avionics bay) as a module DLL, and so far I've been quite successful.
In which areas would XMLTools help me?
Please note I'm not talking about the existing CIVA INS, it's a new project, and I'm just trying to understand if it would be a good idea to use module DLL.

Thank you,
Marco
 
Ravamar said:
Please note I'm not talking about the existing CIVA INS
Click to expand...

Noted, I supposed that, sorry.

I guess then your doubts are regarding the use of a C++ gauge or a .dll module loaded through DLL.XML right?

If so, then I will stay on the gauge side; much easier and a simple solution too.
Besides you don't need to worry about module install issues from end users.

Tom
 
I am inclined to agree with Tom.
The only reason you would produce a module would be if you planned to produce two or more xml gauges to act as a front end for it (or you planned that others would produce such gauges.)

Doug
 
Hi Tom and Doug,
taguilo said:
I supposed that, sorry
Click to expand...
No problem at all, no need to be sorry!
taguilo said:
I guess then your doubts are regarding the use of a C++ gauge or a .dll module loaded through DLL.XML right?
Click to expand...
A dll module loaded through DLL.XML, correct
taguilo said:
If so, then I will stay on the gauge side; much easier and a simple solution too.
Click to expand...
I agree but since for me a DLL module world is new, it represents something very interesting, independently from how complex it might be. Also, as I wrote, at the moment I'm just doing some experiments, nothing has been decided yet. And, BTW, it's not that complex.
ddawson said:
The only reason you would produce a module would be if you planned to produce two or more xml gauges to act as a front end for it (or you planned that others would produce such gauges.)
Click to expand...
Yes, Doug, what you described is exactly one of the reasons I'm looking at it. What I originally thought is that if CIVA (the INU part) had been developed as a DLL module, it would have been much simpler to support my or somebody else front end gauges. Believe me (but I'm sure you both well know), it's not easy to embed a "calculation engine" within a gauge and have other gauges access it.
Moving the brain part to a separate module, which is not tied to a gauge, would, as far as I currently can see it, make sense.

Marco
 
From a bugfixing and compatibility perspective, XML is much more preferable since everybody can edit it and checking a fix is just an aircraft reload away.
And keep in mind that all dlls will also have to be compiled in both 32 and 64 bit format nowadays if you want to maximise your target audience.


ddawson said:
The only reason you would produce a module would be if you planned to produce two or more xml gauges to act as a front end for it (or you planned that others would produce such gauges.)
Click to expand...

I'd say the only reason to use a module is a requirement for simulator interactions at framerate (such as for a custom flight model or FBW system). For anything else that's not framerate-critical, there's XMLTools.
 
Marco,
Ravamar said:
Believe me (but I'm sure you both well know), it's not easy to embed a "calculation engine" within a gauge and have other gauges access it.
Click to expand...

That is indeed simple. XML gauges/visual models use LVars, and C++ gauges can manage those pretty well, so communication between a C++ gauge and one to many XML gauges is very possible.

EXCEPT, of course, that LVars do not support strings and/or array-style manipulation.

XMLVars class in XMLTools allows, via C :vars , to manage string data and array-style loops. If that is what you are looking for then yes, the only way is to develop a custom module or perhaps check XMLVars class and see if it could give you a solution to your needs.

Tom
 
You must log in or register to reply here.
Back
Top