SDE Build 2598

#21
Jon

Many web site forums are talking about SDE and how it can be a replacement for AFCAD.

Many Many AFCAD's where not designed correctly even though they appeared to work in FS9.

SDE is working with a more compliant code then AFCAD so as more people try to open their exsiting AFCAD's with SDE it will produce errors.

This is not a SDE issue as much as it is a corrupt AFCAD issue even though FS9 accepted the AFCAD.

You will end up in the near future chasing many ghost because of the AFCAD and not SDE.
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
#22
Hi Jim

Thanks for that. I agree that the problems coming from AFCAD will be an issue - what I want to do here is try and make SDE resilient enough to handle these problems gracefully and let the user know. At the moment they tend to cause a fatal error but that is OK as it is the best way to find them. At the moment I can get over them the programming problem is how to handle them gracefully and let the user know what has happened (i.e. do not crash but do not ignore it either) It is quite difficult as the errors can turn up in many places but, in technical terms I am looking at generating an event when an error happens which can be put onto the decompiler output and read by the user.

At least if more people are starting to work with it then the problems should surface faster :)

I guess this is a downside of AFCAD having it's own compiler ;)
 
#23
The biggest downside to AFCAD is that it did not follow in the decompile or compile process any minimum spec that bglcomp uses. Lee had nothing to work with (SDK's) but also thought that the AFCAD designers would know not to compile a AFCAD that did not conform to BGLcomp.

The last AFCAD that we just checked also has all the Apron link Lines set to 0.0M width. AFCAD would allow a 0.0M taxiway/link line and a 1x1 foot runway. BGLComp throws this out with errors. Minimum size runway with BGLComp is 3x3M.

This goes back to what you said while ago that we don't know how FS treats these values or if it uses a default size regardless of what AFCAD did to the Airport. Many AFCAD's (airport) do not work correctly that are uploaded to web sites.

That is not always the fault of AFCAD because FS continues to have Airport record entrys in the XML that do nothing. You can close one end of a runway with AFCAD, SDE, hand written XML but, ATC does not honor it.

You can change pushback to left or right but it is not honored. Taxi weight values mean nothing. The list is endless and why FS still continues to have these entry's in the records is beyound me unless they where thinking long term.

The SDK tells us what can be added to each Airport field but fails to tell us it does nothing based on what the default is in the dll's.

If SDE is built on the BGLComp and schema error checking process then any errors that it finds based on what it is decompiling would go through but give a log to say this bgl does not conform to the standards set by MS and could cause problems if used in FSX/FS9.
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
#24
That is not always the fault of AFCAD because FS continues to have Airport record entrys in the XML that do nothing. You can close one end of a runway with AFCAD, SDE, hand written XML but, ATC does not honor it.

You can change pushback to left or right but it is not honored. Taxi weight values mean nothing. The list is endless and why FS still continues to have these entry's in the records is beyound me unless they where thinking long term.

The SDK tells us what can be added to each Airport field but fails to tell us it does nothing based on what the default is in the dll's.
Well I think if we can collect this type of information then SDE could either not display that property (which would certainly cause new users to ask us why) or better provide some messages on the fact that such-and-such is ignored by FS.

If SDE is built on the BGLComp and schema error checking process then any errors that it finds based on what it is decompiling would go through but give a log to say this bgl does not conform to the standards set by MS and could cause problems if used in FSX/FS9.
Let me rephrase that in case I do not understand. Should SDE report this type of oddity in the decompiler output that is shown after the decompile?

Creating new stuff in SDE should conform to the schema and FSX Compiler.
 
#25
Should SDE report this type of oddity in the decompiler output that is shown after the decompile?
Yes, that is a good way to say it.

You should still decompile even if there are errors but then after the decompile show what could be wrong in the code.
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
#26
OK then we are on the same page - I now need to figure out the best way to do that and report back
 
#27
Was I clear enough on how AFCAD adds a ILS but leaves the orignal which appears to be 2 ILS for a runway?

There are reasons why this is done by Users which in turn normally breaks the Approach code of FS9 and now possibly FSX.

If a runway changed Numbers or Reversed the numbers (EHAM) designers think they can use AFCAD to fix the airport Runways. They rename the runways then AFCAD has a menu that will add a new ILS to that runway.

In the AFCAD compiler Lee hardcoded deleteAllApproaches="FALSE" so no type of approach code could be copied into or if put in by hand nest in AFCAD.

He also made AFCAD availble to read all the default Navaids in a area (as we found out) but not delete any Navaids. Designers would insert a new ILS if they renumbered a runway so it appears that 2 ILS exsist. That is one example and there are others. Of course doing this breaks the approach code that is tied to the runway in FS9.

Another example is if the designer moves the orignal ILS of a default Runway by draging with the mouse which is allowed in AFCAD.

I have more examples if you need SDE to understand all of them.
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
#28
Hi Jim

Yes that makes sense. I think that I will need to deal with some of these things in the Engine and some in the Application(s) that use it. For example an AFCAD replacement using the engine might need to stop users from deleting approaches. Having said that if they move runways about then they will mess up the Approaches anyway if I understand you correctly. Seems to me that AFCAD is used by a lot of people to do things that they probably should not use it for. I know I have been guilty of that in the past.
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
#30
Hi Ron

I have it thanks and replied - I can't replicate it in today's build but it is a very BIG file and the error you have is coming from the Tree. Perhaps when I release the next build over the weekend you can try it again on your machine.
 
Top