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

Community Idea

W

Waugh

Messages
135
Country
us-kentucky
What do you guys think about working together to develop a set of classes that provide the facilities to do common tasks that are required to interface to FS.

For example, we'd have a class NavCom (as I already do) that would provide the API to get and set NAVCOM frequencies in FS.

Once written, we could then all benefit by not having to reinvent the wheel, and could focus on higher level development for add-ons. As new versions come out, then we could each take a section, and update it to make it take advantage of any new features or compatible with changes.

Each class could provide a number of public methods to provide data in a variet of formats, so if you are using Gdi+, for example, you could get the data in a wstring, while if you want it in string or char* you could use methods that returned/set data in those formats instead.

Finally, we'd all benefit too by having the code open to peer review. We could even publish/maintain it on sourceforge.com if we wanted.

Thoughts?
 
Are you talking about a library to handle the interface with FS via Simmconnect or FSUIPC or a library to handle scenery file information? If it is the latter then I am currently developing such a library in C# for net 2. It is mentioned in this thread:

http://www.fsdeveloper.com/forum/showthread.php?t=3453

I am considering making it available for developers once it is finished. Though it is designed for scenery those elements such as altitude and so on are classes in their own right and have properties and methods related to connecting to FS.

Also in the Tools Programming forum there is a plan to develop a suite of design tools for scenery design called SDSX.
 
As I mentioned above, a group of classes used for .gau development that allow one to easily Get()/Set() FS variables, like my existing NavCom Class where I can call methods to get and set frequencies.

So, this is for in-game gauges.
 
OK thanks for clarifying that Patrick.
 
You must log in or register to reply here.
Back
Top