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

Draft Package Diagram

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
34,853
Country
unitedkingdom
Well sort of - apologies to the purists but this is my attempt at sorting out some of the elements of the program. All feedback and improvements gratefully received :)


PackageDiagram.jpg



Notes

Draw Primitives are elements of drawing or images which can be combined to create the graphical representation of an object. Each FS Object knows how to use these primitives to draw itself.

FS Objects Need a base class or interface from which they all inherit. Objects need to know how to draw themselves and also how to generate their source code (XML or otherwise) for compilation.

Plug In Manager If new object types can be created using the SDK then the Plug In Manager handles the inclusion of these into FS Objects.

GUI Needs to be independent of the rest of the program and uses the Model View Presenter to do this. I guess that the model is actually the DATA package so does not need to be shown in the GUI??
 
Last edited:
Messages
268
Country
netherlands
Some initial comments...

The package called "Data" is the "Domain Model" - and it is indeed the model you are unsure of in the GUI.

The GUI you list is the view (or actually a set of views) into the datamodel, being controlled by a presenter (or actually a number of presenters). Notice we will have one project for each presenter/view, with the posibility (but not desire unlike it makes sense for one or another reason) to add several views to the same presenter. The view will read and subscribe to events in the domain model, but never ever set any value.

The plugin manager is already delt with - it is included for free with Smart Client Factory. Basically everything will end up being plugins no matter if we like it to or not. :)
The SDK is known as Vistual Studio - simply make a component like ours, stuff it into the XML controling loading and you are set to go. You can even replace our modules this way. Hence only documentation would be needed, no actual code or package. I would not spend too much time on this though, let's first get our own stuff working as long as we do not block it from working in the future.

I am not sure what you mean with FSObjects? I simply see this as a part of the domain model, though reading and writing it might indeed be seperate modules (services), but I think we can refactor that as required.

Your "Persist Data IO" package is known as "Data Mappers", but they should not deal with user config (for that we use whatever it is .NET 2.0 is offering, I haven't looked much at that part yet).
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
34,853
Country
unitedkingdom
Hi Lars and thanks

Yes I think you are right that FS Objects are part of the Domain Model.

I have updated my diagram with your comments but will hold off producing another for a bit to see if there are any other comments.
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
32,859
Country
netherlands
Looks fine to me.
 
Messages
268
Country
netherlands
Another comment I just thought about: What do you plan to pull though SimConnect? Actual data like BGL files or similar data, or simply position of the aircraft etc. If it is the latter, SimConnect should communicate directly with the View or the Presenter as far as I can see.

I do not have the beta so I have not read the SDK to see what can be done with SimConnect.
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
34,853
Country
unitedkingdom
Another comment I just thought about: What do you plan to pull though SimConnect? Actual data like BGL files or similar data, or simply position of the aircraft etc. If it is the latter, SimConnect should communicate directly with the View or the Presenter as far as I can see.


It can't import data such as bgl files unless I am mistaken. But yes it would provide current location of aircraft information in one direction and in the other we might want to move the aircraft.

It should communicate with both actually - for one to show a position of the aircraft on the screen but also so that location information, heading, co-ordinates and altitude can be added directly to an object. How we do that I don't know - do we send that data to the Presenter/View via the Domain Model or direct?
 
Messages
268
Country
netherlands
FS is in our case a user interface and hence a view. It is therefore not allowed to write data to the domain model. It could in theory read it from there without violating the MVP pattern, but as this is a special case (we prefer only having one SimConnect connection I assume) we can simply send everything (read and write) though the presenter.

It can be the same presenter as the standard map view, or it could be a dedicated presenter. This is much easier to determine once we actually have a presenter it could be hooked into.
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
34,853
Country
unitedkingdom
OK - not sure I understand this fully yet, but that will be because I need to read more carefully into the Pattern :) In any case I will move the link to the Presenter in the Schematic
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
34,853
Country
unitedkingdom
Updated as a result of comments.


PackageDiagram2.jpg
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
32,859
Country
netherlands
I think we don't need very special things from SimConnect indeed. All we want to do is:

  1. Read the current aircraft position (and heading) and show it on screen or place an object at that location
  2. Write the position and heading of a certain object to FS, so that the aircraft will be positioned there

Lars, where does that Presenter come into the diagram? Does it need to be an addtional block between the GUI and the Data model? Just trying to get the picture :).
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
34,853
Country
unitedkingdom
I think we don't need very special things from SimConnect indeed. All we want to do is:

  1. Read the current aircraft position (and heading) and show it on screen or place an object at that location
  2. Write the position and heading of a certain object to FS, so that the aircraft will be positioned there

Agreed Arno
 
Messages
268
Country
netherlands
Lars, where does that Presenter come into the diagram? Does it need to be an addtional block between the GUI and the Data model? Just trying to get the picture :).

It will be in the same solution as the view, so it will be in the same package. Hence I do not think we need a separate package for it in the diagram. To be honest I am not good with package diagrams - the actual package distribution comes pretty natually as we progress, so I am not used to giving it any thought up front.
 
Messages
1,360
Country
scotland
Hi Gents

A tangential suggestion.

How about
dumping the GUI editing aspects,
and as per Mission Editor
use SimConnect to write directly into FS ?

ATB
Paul
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
34,853
Country
unitedkingdom
Well one immediatei ssue is that Simconnect can read/write certain FS variables like Lat/Lon which is useful for using the aircraft to position objects but it cannot handle scenery files. I am not sure how the mission editor works but as far as object placement is concerned I would bet that it uses the aircraft position to decide where to place mission objects and that is where simconnect comes in.

AS for the GUI the majority of scenery design tools (EZ-Scenery excluded) are external and use GUIs for object placement and overall visualization of the scene. EZ-Scenery is limited in that it can only really place objects and not the other range of scenery elements that exist.
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
32,859
Country
netherlands
I agree with Jon here. I think you need a GUI when you want to do things like placing aerial photos, drawing complex airport layouts, etc. I find it hard to imagine how you could do that kind of tasks efficiently from within FsX itself.

But for simple object placement the concept of EZ-Scenery is quite nice of course.
 
Messages
1,360
Country
scotland
Hi Folks

Jon -
Apologies if this is slightly off-topic.
Please feel free to split the posts
and relocate to an appropriate thread.

The Mission Object Placement Tool allows entering of coords
to place any library available object,
unrelated to the location of the user a/c.

These objects display immediately,
just as EZ-Scenery does.

However the MOPT can also draw and stretch/resize bounding boxes,
and might be able to draw waypoint lines,
(can't check ATM as mine's currently not working).

i.e.
There may be ways to draw directly into FSX itself.

Now if someone ?
could write a pass-through logging client,
rename the MS simconnect.dll to realsimconnect.dll
name their dll as simconnect.dll
then we might have a better idea of what's going on,
hence what's possible.

ATB
Paul
 
Last edited:
Messages
156
Country
france
Now if someone ?
could write a pass-through logging client,
rename the MS simconnect.dll to realsimconnect.dll
name their dll as simconnect.dll
then we might have a better idea of what's going on,
hence what's possible.

The *client* simconnect library (simconnect.dll) does nothing more than writing all arguments passed to its functions into packets, and sends them to the server.
There may be more functions available via simconnect than mentionned in the SDK documentation, but I doubt they will be so low-level as drawing lines or polygons in the FS world.

AFAIK, object_placement_tool does not use simconnect to communicate with FSX, but directly uses the fs core functions.
 
Messages
268
Country
netherlands
Even if we could write directly to FS it would not be my main priority for a GUI. I would consider it a nice addon, but nothing more.
 
Top