Scenery Design Engine Build 2555 Available

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
#1
Finally :)

It can be downloaded from my website or directly from this link:

http://www.scruffyduck.co.uk/files/sde_current_build.zip

There are a lot of 'under the hood' changes in this build. The main ones now allow for scenery elements to be added and removed from the scenery tree. The program should only allow you to add those elements which are valid for the current object (e.g you can add a runway to an airport but not an ILS. You can add an approach to a runway but you cannot add an Extrusion Bridge to an airport). It should follow the 'rules' laid down in the FSX SDK. Also the different elements of taxiways should now work, aprons should be sorted out and apron edge lights work. There is basic operating instructions in the included release notes.

As alway feedback is much appreciated (goos and bad please :) ) If I hear nothing then I wonder
(a) has anyone downloaded it?
(b) is it so bad that it is deleted at once?
(c) am I getting paranoid that nobody like me in my old age :D
 
Last edited:
#2
Actually, I find SDE most interesting.
Why don't you share the source of TestApp.exe? I'd love to play around with it. : )

I see SDE as a solution to the problem of multile versions of default scenery files. Using SDE, it looks like it should be quite easy to write an application that modifies default files.
 
#3
I thought you were going on vacation?

Over the past 3 years I have written a lot of XML code for all the airports I have uploaded to AVSIM.

I have a new hand written XML (100,000 lines) KATL finished and about to upload so I will run the utility on it.

People may wonder why so many lines of code.

When FS9 was released I adopted their method as per the SDK of how a airport facility type AP9/APX bgl is written. Other then a new FSX compliant airport ground poly (proper GUID), several road exclusion GUID's and a cvx bgl to stop all the road traffic from crossing the new 10/28 runway, everything else is in a single bgl.

This technique may go against the grain with some scenery designers but I work with default FSX airport scenery and not the more exotic 3rd party type scenery design tools. I am not a scenery design person but spend my time rewritting XML default airports so anything that has been added since the release of FS shows up in my design.

The airport data cutoff date as per some of the ACES group was over a year ago so some airports in the FSX database are not 2006 current.

Atlanta (KATL) opened their 5th parallel runway this past year and that requires adding it and all the support scenery GUID's including a new Control Tower, Fire Stations/trucks, taxiway signs, aprons, taxiways, ground tracks, lighting, rectangle excludes, model mdl's, more fuel trucks (8) and the list is endless all into a single bgl.

The new ILS freq for rwy 28 is also ILS freq for another airport 22 miles away that was changed when rwy 28 opened. That required combining 2 airports into one bgl so I could change the other ILS freq so no conflict occured in the approach data. All important is knowing what deleteAll statements to use for both airports in one single bgl. This allows FSX to use certain portions of the exsisting APX and block out other parts of the airport facility that is updated in a new bgl.

All new approach XML for runway 10/28 and every single XML exsisting line of approach data had to be rewritten because KATL just introduced (Jeppesen plates) all new STAR (RNAV) Arrivals which are FLCON, PECHY, CANUP, HONIE and ERLIN (FLCON and PECHY replaces MACEY). This also requires writting all new Transistions off the STAR's so the User Airplane Pilot can select a RNAV (gps overlay) from the Arrival (if optional for the FP) to the IAF of the proper active runway.

Three years ago I introduced my Crosswind Runway Technique that most AFCAD designers adopted so all runways are open simultaneously (non-parallel based on < 7.9 degree base heading) at airports (based on winds). With the release of my FSX compliant KATL I have developed another first which uses all 5 parallel runways for arrivals (instead of just the outer 2) which is partly based on landing weight (empty) for both the User and the AI Airplane Traffic. The Aircraft.cfg weight tells ATC which default ILS vector/runway will be used for the assignment unless the USER ask for a different Transistion and Runway.

AI Traffic behavior can also fly a STAR arrival (proper XML code) rather then the default ILS vectors to final. I did not add this feature because many Pilots rely solely on the 30 degree default offset heading value that ATC vectors for final and mixing AI Traffic onto the STAR arrival could be confusing to some. My plan is to add a AI Traffic arrival STAR to FSX KMIA (9/27) that also opens all runways for departure and arrival.

Some of this is not new to FS because FS2002 allowed for multiple runway useage (using different techniques). When FS9 (and now FSX) was released these type runway behavior patterns are no longer honored unless trickery is written and applied to the airport facility XML database.

There is a large community out there that thrives on having realistic AI Aircraft as part of the FS program. If that was not so there would have been little need for a program/utility such as Lee Swordy's user friendly AFCAD.

Your tool design is very much appreciated and I will give a good work out.
 
Last edited:

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
#4
Hi Guys and thanks for the feedback.

Jim - I leave next weekend for Florida but I will not be completely out of touch :) Also my Annual snowbirding is a good time to get my head around a program so SDE will get the attention this year. I can certainly appreciate the work which goes into 100,000 lines of XML :cool: I hope SDE will provide some support for that kind of thing by helping take some grunt out while not interfering with the creative stuff.

Paavo - I have in mind to release the Design Engine as a dll library for others to use. It is all basically in one dll. jmFlightSimLib. I plan to spend some time documenting the main interfaces while I am in Florida. There are over 140 assorted classes, enumerations and helper files but actually only one class that really needs to be accessed to use the library. So maybe a release at the end of January for developers :)
 
#5
Hi Jon,

I haven't tried this last version yet (holidays, you know) but you are doing a huge effort to facilitate other addons tasks.

Actually, I started to decode some files but now I'm following your path...

Best Regards,
Javier.
 
#6
Why don't you share the source of TestApp.exe? I'd love to play around with it. : )
QUOTE]

It's easy to play with Jon's dlls. Just reference them and use the object browser to have a look at their methods and attributes names. Actually, you don't need too much documentation to do most of the things as the names are self-explained.

Everything starts with:

Code:
ScruffyDuck.Flightsim.Scenery.SceneryFile.SceneryFile bglFile = new ScruffyDuck.Flightsim.Scenery.SceneryFile.SceneryFile(bglName);
sceneryFile.Decompile();
The rest is also quite easy to get. For example, ICAOs in the file:

Code:
while (i < sceneryFile.Airports.Count)
{
...
_ICAO = bglFile.Airports[i].ICAO;
...
}
and so on.

By the way, Jon, may you make public the lat and lon in decimal format? That will save a convert from string for different uses than xml writting.

Regards,
Javier.
 
#7
Scruffyduck,

Enjoy your program. It's terrific. Will there be a GUI part to it?

In working with it I opened up a few BGL files and after about the fourth one I got an out of memory error. Do you need any of the info presented?

Can you add a find feature. Some BGLs have 100 airports. Also is there a way to give the LibraryObjects a "real" name with a lookup?
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
#8
Enjoy your program. It's terrific.
Thank you :)

Will there be a GUI part to it?
I will probably build one. Also I plan to make the library available as a DLL for other developers to build applications on. I am sure that someone will be able to build a much better GUI than I can ;)

In working with it I opened up a few BGL files and after about the fourth one I got an out of memory error. Do you need any of the info presented?
Yes please - I have not had that problem but it is quite possible there is a memory leak in the program at the moment as the 'garbage collection' has not been optimized.


Can you add a find feature. Some BGLs have 100 airports.
I will add it to the list :)


Also is there a way to give the LibraryObjects a "real" name with a lookup
Yes - you would have to see my program called LOM, that creates a database of objects. Certainly for FSX objects it is possible to extract the real name. I plan to add access to a database of objects as part of further development
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
#9
Hi Javier

You will find that the latest version is getting rid of many of the arraylists. I am using the tree as the primary way to access the data. I will also add 'on the fly' methods to extract ArrayLists of each object type.

As for getting decimal co-ords out that should be possible now. Each coordinate is based either on the FSLatitude or FSLongitude class. Each of these classes has public methods .DDM and .Decimal. .Decimal will get you the decimal value. .DDM the string version. Because these classes do the math internally you can use them interchangeably e.g. store it as DDM and then get it back as decimal and vice versa. There is a bug in the DDM code which seems to set N52 00.000 as N51 60.000 :eek: I have not had time to check out why.

The next build has the ability for the user to set their units of preference for Altitude, co-ordinates, Distance and dimensions.

I am documenting the code as I go along but it is not very good at the moment . Also I have changed some of the namespaces around. I plan to get a documented version of the library done while I am in Florida for the next several weeks. I will then make that available using nDoc.
 
#10
Hi Jon,
You will find that the latest version is getting rid of many of the arraylists. I am using the tree as the primary way to access the data.
I see... I understand the reason behind that because your GUI but, in my opinion, it makes more difficult to use your library for any other application.

I will also add 'on the fly' methods to extract ArrayLists of each object type.
I think I'll keep your old dll version until that. It had very convenient access to almost everything.

As for getting decimal co-ords out that should be possible now. Each coordinate is based either on the FSLatitude or FSLongitude class. Each of these classes has public methods .DDM and .Decimal. .Decimal will get you the decimal value. .DDM the string version.
As I see in the object browser FSLatitude/Longitude/Altitude... have public methods but the actual objects (Runway, Helipad,...) only have public the string. FSLatitude latitude, FSLongitude longitude, etc are private in every case.

There is a bug in the DDM code which seems to set N52 00.000 as N51 60.000 :eek: I have not had time to check out why.
I haven't seen that but maybe some Floor/Ceiling issues. I use a quite simple code for that conversion:

Code:
...
int g = (int)Math.Abs(lat);
float m = (lat - g) * 60;
s.Append(g.ToString("00") + " " + m.ToString("00.00000", NumberFormatInfo.InvariantInfo));
...
The next build has the ability for the user to set their units of preference for Altitude, co-ordinates, Distance and dimensions.

I am documenting the code as I go along but it is not very good at the moment . Also I have changed some of the namespaces around. I plan to get a documented version of the library done while I am in Florida for the next several weeks. I will then make that available using nDoc.
Keep up this good work!

Best Regards,
Javier.
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
#11
I see... I understand the reason behind that because your GUI but, in my opinion, it makes more difficult to use your library for any other application. I think I'll keep your old dll version until that. It had very convenient access to almost everything.
I'll put the arraylist methods into the new build. I agree that is easier for applications wanting read only access to the data. Using them to add or remove information is not so easy. Would you want the ability to write to them?


As I see in the object browser FSLatitude/Longitude/Altitude... have public methods but the actual objects (Runway, Helipad,...) only have public the string. FSLatitude latitude, FSLongitude longitude, etc are private in every case
OK you are right :) The current build here has functions to externally set the format used to display coordinates. It uses a new property of those classes called Value. It is a string in the cases of Latitude and Longitude but you can get the decimal value out as a string and that is then easy enough to parse into a double or whatever.

I haven't seen that but maybe some Floor/Ceiling issues. I use a quite simple code for that conversion
I think mine is much the same - I need to go check it :)
 
Last edited:

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
#12
Javier,

If you want to get lists out of a sceneryfile now you could get them from the tree

something like

Code:
ArrayList data = new ArrayList();
foreach ( TreeNode node in sceneryFile.Tree.Nodes){
   SceneryBase current = (SceneryBase) node.Tag;
   if(current.Type == SceneryObjectType.Airport){
      data.Add(current);
   }
}
That presupposes you know a bit about the ScruffyDuck.FlightSim Namespace :)
It contains:

  • .Common which has general supporting routines in it
  • .Enumerations which contains - well the enumerations
  • .Interface which contains code to communicate with FSX (via FSUIPC at the moment)
  • .Scenery which contains scenery object classes
  • .Types which contains the type classes for things like Latitude and so on

The .Scenery Namespace is subdivided:
  • .SceneryElement which contains bit players like Glide slopes and Approach Legs
  • .SceneryFile which contains the classes for the top level scenery file
  • .SceneryObject which contains the main objects and also .AirportRecord which contains the airport sub objects like runways and so on


SceneryObjectType is an enumeration with every type of object in it.

SceneryBase is the base class for all objects and contains a Type field so you only need to cast the Tag in the tree to SceneryBase to be able to get the object type you want.

I am adding this type of code into each level of Scenery Object so that you can get out ArrayLists on the fly - I think they need to be readonly because you would have a big job to put everything back into the tree if you wanted to change something - that is why I went to a tree for the internal domain model.

Anyway gives you a bit more about how the Engine is constructed. :)
 
Last edited:
#13
Hi Jon,
If you want to get lists out of a sceneryfile now you could get them from the tree
I have been thinking in something like that but it will force a lot of changes in my code here and there.

Anyway, don't mind, I can still live with 0.3 version and I'll wait for a more stable dll. It's my fault to start using a beta! ;)

I am adding this type of code into each level of Scenery Object so that you can get out ArrayLists on the fly - I think they need to be readonly because you would have a big job to put everything back into the tree if you wanted to change something - that is why I went to a tree for the internal domain model.
I think your approach has a lot of sense, specially if you plan to have a GUI for scenery desing. To use your dll by other apps, the "get" for arraylists is fine too.

What I would suggest is more public methods for "investigators". A public rawdata would be nice :)

Best Regards,
Javier.
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
#14
There is some access to rawdata, at least in the later versions - it is called HexString and should be available for any object based on SceneryBase.


I think that providing read only access to the data for those applications which do not need to modify it is the right way to go. Also I am adding some classes to do faster scans of the whole FS setup - to get basic airport details for example.
 
#16
I finally found a couple of seconds to look at it, and it appears to be pretty useful stuff. The only details I noticed are:

1) Carefull about casing on the property names (yes, I know - it's just something that really annoys me when it is wrong for one or another reason) :)

2) Didn't see any events raised when the properties are changed. I recommend not delaying this one too long, it is not that much fun going though adding them all at once. :)

3) What is the meaning of the DrawObject? Som vector data for later processing into Web, WinForm, WPF, whatever? Personally I am not too happy about any GUI information in a domain model, but I guess it might work if it is kept generic enough.
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
#17
1) Carefull about casing on the property names (yes, I know - it's just something that really annoys me when it is wrong for one or another reason) :)
:) I will go back though and check everything as I document it but if you tell me the annoying ones I will fix them

2) Didn't see any events raised when the properties are changed. I recommend not delaying this one too long, it is not that much fun going though adding them all at once. :)
No you are right - I need to go back and look at that.

3) What is the meaning of the DrawObject? Som vector data for later processing into Web, WinForm, WPF, whatever? Personally I am not too happy about any GUI information in a domain model, but I guess it might work if it is kept generic enough.
Agreed - I am leaving that in there at the moment in case there might be some information worth passing to a GUI, but to be honest I think that is best left to that layer.
 
Top