SDE Build 2591

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
The current download for SDE:

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

is now build 2591. This is a bug fix build which will hopefully deal with most of the problems associated with the new load and save in XML format. Apologies if you have just downloaded 2590 but please donwload again and make sure you use the latest build.

Thanks for your help and patience :)
 
Now we are getting somewhere

Need a field added to all new Approach legs.

The First add a Approach gives us the ability to select a MAG or TRUE Course and add a Heading. There after, any added approach leg is missing heading as a field even though there is a heading value in the yellow window pane.

I had to add the heading manually outside of SDE and then read it back into SDE as a XML to see my correct heading.

This missing heading field is important for certain type legs so the lines in the GPS will draw correctly.

I still am having problems saving as a XML as I add new areas to my airport. This build ghosted the save "as XML" or "SDE" for some reason.

The path for saving is also a little buggy. Path is looking for a sub folder in the work folder to save or extract a xml from. I had to add a new folder to the work folder manulally so SDE would find my XML.
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
Need a field added to all new Approach legs.

The First add a Approach gives us the ability to select a MAG or TRUE Course and add a Heading. There after, any added approach leg is missing heading as a field even though there is a heading value in the yellow window pane.

I had to add the heading manually outside of SDE and then read it back into SDE as a XML to see my correct heading.

This missing heading field is important for certain type legs so the lines in the GPS will draw correctly.
OK I have fixed that.

I still am having problems saving as a XML as I add new areas to my airport. This build ghosted the save "as XML" or "SDE" for some reason.
Yes that is a 'feature' it means that you can only save a piece of XML for something that could be compiled using BGLComp. If you want to be able to save approaches then you need to save the airport that contains the approaches. If you think we need to be able to save snippets then I can look at it.


The path for saving is also a little buggy. Path is looking for a sub folder in the work folder to save or extract a xml from. I had to add a new folder to the work folder manulally so SDE would find my XML.
I am not sure what you mean there Jim - all saves are placed in the work folder of the application. I would not think it possible for that to be somewhere else. However I can make it possible to save to a folder of your choice rather than force it. I guess that makes more sense. Currently the path to the work folder is hard coded into the test application.
 
Last edited:
Jon

Here is the path error when trying to save the xml to the default work folder. For some reason it is looking for an additional folder that I have no control over.

I had to exit SDE and make a new folder in the work folder with the proper name so I could save by default a sardy.xml that SDE chooses on its own.

By the way I wrote the approach code for KASE by using the SDE and posted my results on Reggie's original post over in the AFCAD type forum.
 
Last edited:
Jon

I think I see the problem with the path error.

I am working with KASE and that name has a forward slash which might be interpret as a folder causing the path error when trying to save the xml

Airport name in the Description list says

Aspen-Petkin Co/Sardi

SDE saves the xml as sardi.xml but is looking for a folder called KASE - Aspen-Petkin Co

0202/APX19180
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
OK Jim that would do it - anything with a slash in could be interpreted as a path.
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
By the way I wrote the approach code for KASE by using the SDE and posted my results on Reggie's original post over in the AFCAD type forum.
Yes I saw the post - iti s nice to know we are getting somewhere :)
 
Jon

I am seeing more and more Airports with the "/" in their name.

That is forcing me to make a sub folder in Work. Once the folder exsit the XML/SDE saves fine.

I think you were going to maybe change the coded folder so we can have a choice or maybe a code that makes the sub-folder when it sees the "/". Maybe in the next build.

We also need to revisit the Apron lighting. I will come up with a picture of what is happening at night when SDE decompiles the lighting. It causes all kinds of light strings around the airport. I have a sample of what does work when I change the code that the lights need.

It appears the Aprons also have a problem but I need to do more work to confirm.

I think BGLAnaylze was doing the same thing once and Winfried change the codes in his decompilers.

I have a list but want to give you time to work out other bugs that some may have with the models.
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
OK Jim

Thanks - I will look at the issue of the '\' in airport names - the only way to handle it will be to change that character in the filename when it is saved to something else.

I have nver been happy with aprons and apron lights so I would appreciate any feedback on what is happening. As for other stuff please go ahead, at the moment I am clear of my 'obvious bug' list in the current build.


EDIT

OK I think I have fixed the airport name problem
 
Last edited:

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
Apron Edge Lights seem to be fixed now. I had not understood how they are stored in the bgl correctly :eek:
 
I assume that SDE is built using .net Framework 2.0

Are utilities designed specific to these versions?

I now have .net Framework 3.0 so can I remove 1.1 and 2.0?

Will SDE and other utilities continue to work ok or must the version of framework stay with the version used for the design of the utility?
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
Jim

You are correct SDE is on NET2.0. Do NOT remove any versions of the dotNET framework, they are not backward compatible and applications have to run against the framework they were compiled for. Also NET3.0 is a bit of a misnomer in that it is a set of additional functionality on top of NET2.0. For example Windows Presentation Foundation (WPF) is part of NET3.0.

I have dotNET 1.0, 1.1, 2.0 and 3.0 !!
 
Lars is using net 3.0 for is new beta FSX compliant editvoicepac program.

I was hoping that .net Framework was backward compatible but you cleared that up for me.

I now have all the versions installed same as you and will have to leave them as they are.

I need to find out what was needed and why I had to have Versions 1.0 and 1.1 which I might not need any more (based on previous FS9 utilities not in use on my system).
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
Jim

Unless you are short of space I would advise leaving everything where it is.

I expect to use WPF (from NET3.0) for future interfaces to SDE.
 
No problem with space (a very very high end Alienware Area 51 computer)

I will leave everything as is (all versions installed)
 
Top