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

SDE Build 2598

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.
 
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 ;)
 
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.
 
jvile said:
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.
Click to expand...

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.
Click to expand...

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.
 
Should SDE report this type of oddity in the decompiler output that is shown after the decompile?
Click to expand...

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.
 
OK then we are on the same page - I now need to figure out the best way to do that and report back
 
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.
 
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.
 
Jon,

I sent you a e-mail wrt Out of memory error - No big deal - just wanted to report it
 
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.
 
You must log in or register to reply here.
Back
Top