• 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.

Gauge vs. Module (like CabinComfort)

W

Waugh

Messages
135
Country
us-kentucky
Seems that CabinComfort could be defined as a Module that supports an XML gauge vs. a "gauge".

However, wouldn't it be bad to do all your gauges this way as then you would have to have FS load a module(s) which might not even be used by an aircraft being flown?

Patrick
 
Waugh said:
Seems that CabinComfort could be defined as a Module that supports an XML gauge vs. a "gauge".

However, wouldn't it be bad to do all your gauges this way as then you would have to have FS load a module(s) which might not even be used by an aircraft being flown?

Patrick
Click to expand...


You are right in certain aspects.
A custom "cabincomfort" type dll is always loaded at FS startup, however their included classes are registered only in panel's table at this stage. Instantiation occurs when a certain class(C: gauge) is called in any XML panel file of a given aircraft that uses the module.
Then if you are using a simple (C:Var) in different XML files, a new class (gauge) will be instantiated (created) and linked for each one of the XML files that make reference to the same(C:Var), returning a value of zero by default.
I believe this combination of XML and C++ dll is very powerful and is an open way for complex gauges -for example, you can program a complete FMC's CDU-; BUT you should plan it carefully as to avoid generating exta code at runtime.

Tom
 
Don't need to use a module to program a CDU, just 80,000 lines of code and 12 months to do it (been there done that).

So, don't see how a "module" is inheriently more powerful. Anyway, should be interesting to see what people's thoughts are on this.

Patrick
 
Waugh said:
Don't need to use a module to program a CDU, just 80,000 lines of code and 12 months to do it (been there done that).

So, don't see how a "module" is inheriently more powerful. Anyway, should be interesting to see what people's thoughts are on this.

Patrick
Click to expand...

Sounds too much to me, sorry. Maybe 10,000 lines and 4 months is a better approach using XML<->C++ combination ;) And of course a HUGE knowledge and skills on XML scripting is an excluding condition. Otherwise, it should be better to stay with C/C++ classic gauges's programming.

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