• 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 Use Cases

scruffyduck

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
34,980
Country
unitedkingdom
The following is my first stab at use cases - bound to be wrong :) Based on the updated Design Schematic

Introduction
Use cases are sub divided roughly by package based on the schematic diagram. These may not be correct.

Map (GUI)
+Zoom
+Pan
+Center
+Load background image
+Change Z-Order

Decompilers
+Bulk Decompile
+Single File Decompile

FS Interface (SimConnect)
+Read current aircraft location
+Move aircraft

Domain Model
Current Scenery
+Create New
+Open
+Save
+Save As
+Add Object
+Remove Object
+Update Object
+Move Object
+Rotate Object
Library Object Catalog
+Import library
+Import 3rd party data (RWY12 etc)
+Change Object information
+Remove Object
FS Object Types
+Add Object Type
+Update Object Type
+Remove Object Type

Data Mappers
+Load Scenery from File
+Load Scenery from Server
(Overlaps with information in Domain Model – should all the IO operations be here?)

User Settings
+Read Setting
+Write Setting
+Update Setting

Compilers
+Compile scenery

Plugin Manager
+Add Plug-in
+Remove Plug-in
+Update Plug-in
Click to expand...
 
Last edited:
Personally I believe you are going into too much detail here, with the risk of drowning important decision in specifications like needing a "Save as".

Instead of the methods, I would try to focus on what the user will want to do (so the goal, not how it is achieved).

For example the user does not want to decompile bulk or single file. He wants to place his models in his scenery, and is in theory not really caring how we do it, as long as his model shows up where he expects. :)

I am not sure the user really wants to see object libraries either (please notice I am saying "I am not sure", not "I am certain he won't"). He might think more in the form "I want to place an object", and then not really caring if it comes from a 3rd party library, a standard FS scenery object, or his own MDL file. Actually this is one of the few really big doubts I have on how this should be done (based on my experience from my current tool that is doing a lot of what we are trying here). But I will not hijack this thread for that, but post it separately when I find the time (which might not be today).
 
Personally I believe you are going into too much detail here, with the risk of drowning important decision in specifications like needing a "Save as".

Instead of the methods, I would try to focus on what the user will want to do (so the goal, not how it is achieved).
Click to expand...

Fair Point, on the other hand a user would certainly want to be able to create a new scenery project, open an existing one etc.

For example the user does not want to decompile bulk or single file. He wants to place his models in his scenery, and is in theory not really caring how we do it, as long as his model shows up where he expects.
Click to expand...

Again fair point it is more of a method. I guess it could be part of loading a scenery project since we could be getting background data from FS BGL Files.

I am not sure the user really wants to see object libraries either (please notice I am saying "I am not sure", not "I am certain he won't"). He might think more in the form "I want to place an object", and then not really caring if it comes from a 3rd party library, a standard FS scenery object, or his own MDL file. Actually this is one of the few really big doubts I have on how this should be done (based on my experience from my current tool that is doing a lot of what we are trying here). But I will not hijack this thread for that, but post it separately when I find the time (which might not be today).
Click to expand...

The user will almost certainly want to be able to select objects from libraries. He will also want to add the information about the objects in those libraries into the program so that he can select them to place them. He might also want to categorize them to make it easier to find the building he wants out of the several hundred he has spread over a dozen libraries. I think that all the scenery design programs that I currently know about allow the user to import information about objects and libraries. If the scenery designer is designing for third party distribution then the he will need to know what libraries the objects he has used come from so that he can advise users on which ones they need to have installed so that the scenery works.
 
Jon,

I am not arguing against the functions being needed, but they are needed because they are required for the user to carry out his use cases - they are the means to do it, not the goal.

For example "He will also want to add the information about the objects in those libraries into the program so that he can select them to place them"

As I see it, the use case here is that he wants to add objects from a library to Flight Simulator. The information he adds to the objects is not a goal in itself - it is a necessary step in order to carry out his goal efficently.

Sorry for being a bit insistent on this, I am just trying to keep the documentation short, as if it get's too detailed we will diviate from it anyway. Hence I only created three use cases with regards to placing 3D objects.
 
That's fair enough Lars, I suspect, well know, that you have a lot more experience in these matters than me :) i guess I get drawn into implementation details far too quickly :o
 
Well I have beenn thinking about this and stepped back to what the goals of the system are and get four use cases now:

  • Configure Preferences
  • Manage Objects
  • Design Scenery
  • Deploy Scenery

The last two are what it is all about I think, the first two I think are there - one the user will want to configure the program to suit their needs and set things up for their environment and second I think that they will want to manage the objects they can use in design and deployment. That could fall into two categories - 3D objects on the one hand and everything else.

Does that seem better?
 
Last edited:
Can I add a request for custom autogen placement? For FS9 I use my own programs for helipads and vegetation but Annotator and AGenT for buildings and library objects.
 
Golf-HotelDelta said:
Can I add a request for custom autogen placement? For FS9 I use my own programs for helipads and vegetation but Annotator and AGenT for buildings and library objects.
Click to expand...

Sure I will add it to the list.
 
scruffyduck said:
Well I have beenn thinking about this and stepped back to what the goals of the system are and get four use cases now:

  • Configure Preferences
  • Manage Objects
  • Design Scenery
  • Deploy Scenery

The last two are what it is all about I think, the first two I think are there - one the user will want to configure the program to suit their needs and set things up for their environment and second I think that they will want to manage the objects they can use in design and deployment. That could fall into two categories - 3D objects on the one hand and everything else.

Does that seem better?
Click to expand...

Better, but I do not think preferences is a use case. Just ask yourself one simple question: Will a user use start the program to perform this task? Setting preferences is something the user will do in order to achive the task they want to perform (design scenery). They would never do it just for the sake of managing preferences. Managing objects can be a usecase for people who want to release library objects, but for scenery designers I would also call this a mean to reach the goal. I do not open my current program to manage my objects, I do it to design scenery. Hence the object management is one of the tasks performed when I place 3D objects.

Have you looked at the three usecases I gave for 3D model placement? Any thought of those? I was probsbly a bit sloppy and should have made transforming existing objects clearer, but I still think they hold water pretty well.

For scenery deployment/generation I actually have two use cases (and hence a feature requirements to support it):

1) Generate a scenery for internal testing
2) Generate a scenery for public release

Basically this comes from a feature we have in the tool I already created - in reality people would NOT be ready for release at the same time, and it annoyed everyone that they could not just work on when something was finalized for release. Add to that the fact that some people disapear from the scenery creation world for a few months now and then leavnig half done scenery in the project. Hence the tool should track that some things in it are not yet ready for release, so it should only be included in the internal builds. One could argue we should have more release types, for example:
* beta
* private (meaning only the specific developer, not the internal scenery of everyone in the group)
but personally I do not think this is necessary.
 
OK I agree Scenery Design and Deployment are the primary goals for the program, managing objects is a means to achieving scenery design.
 
Golf-HotelDelta said:
Can I add a request for custom autogen placement? For FS9 I use my own programs for helipads and vegetation but Annotator and AGenT for buildings and library objects.
Click to expand...

Yes of course, but adding autogen only makes sense once we have mesh scenery implemented as well. So it will not be in the first phase :).
 
You must log in or register to reply here.
Back
Top