Preparing Airport for the future

[gsnde]

Dear all,

Please help me a question I am asking me for quite a time. I have build an airport I am quite happy with. To get where I wanted to go I had to learn quite a set of tools. From a technical point of view my airport consists of:

- an exclusion made with ExcBuilder
- the airport made with AFCAD
- a lake for a floating plane base made with SBuilder
- the airport buildings placed with EZ-Scenery
- most airport objects (hardened shelters, radar domes, fuel, fire) placed with FSSC
- few other airport objects placed with Rwy12

As you can see I used quite some tools. I asked myself where I can consolidate. I am sure that I can get rid of the ExcBuildler exclusion and add that part to the SBuilder lake. Further I have understood that I might use ObPlacerXML to place objects from both EZ-Scenery and Rwy12. Are these assumptions correct ?

Now to my most important question. The airport is a military one. Most objects I use are api macros which I place with FSSC. The macros are not done by me - I managed to learn the programs mentioned above, but I am not the "and here I design that object myself " type of guy.

Many of the api macros are real jewels and there is absolutely nothing comparable available in the XML world of Rwy12 or EZ-Scenery.

What I fear is that I might loose them with the next version of the flight simulator. Is that true ? Is there a way that I can migrate these macros into the XML world ? Is Library Creator a tool I can use to combine the macros in an object library and make them therefore kind of compatible ?

Thank you for your feedback and best regards,
Martin

 

[arno]

Hi Martin,

As you can see I used quite some tools. I asked myself where I can consolidate. I am sure that I can get rid of the ExcBuildler exclusion and add that part to the SBuilder lake. Further I have understood that I might use ObPlacerXML to place objects from both EZ-Scenery and Rwy12. Are these assumptions correct ?

Your choice of tools is rather good already, as you have not used that many of the pre-Fs2004 tools. So if you are happy with what you use, there is no real reason to use less tools.

For the excludes that would be possible, SBuilder can make VTP and XML style excludes, so you should be able to make any exclude you want with it.

In theory ObPlacer XML could indeed place any library object, but the way of reading the library information is different in all the tools. So at the moment it is not really easy to place Rwy12 objects with it for example (I want to improve that in future versions).
You could for example also use EZ-Scenery to place all your objects, as it scans your available libraries automatically. So that also includes the Rwy12 libraries. I think in the end it is more a choice of the user interface that works best for you.

What I fear is that I might loose them with the next version of the flight simulator. Is that true ? Is there a way that I can migrate these macros into the XML world ?

At the moment it is not possible to migrate them easily, but we also don't know yet which scenery commands will work in the future and which will not. In theory it would be possible to convert them, I have been thinking about that idea a lot already. So if the next version of FS drops some commands, it is very likely that I will try to make a tool to convert this old work.

 

[gsnde]

Thank you very much, Arno.

I was told that with FSDS2 (which I don't have) you could load the API macros (given that the sca file are available as well) and save / export them as library objects. I don't know if I would be able to still buy the old version of the program, neither do I know if it could be done with the current version as well.
In case it would require only a "load old source" and "save in another format" maybe somebody would be willing to do the conversion for me.

The thing I don't understand is if that would make them completely "up-to-date". One benefit should be that you would gain an advantage in frames-per-second if placing such objects with xml.

What do you think?
Martin

 

[arno]

Hi Martin,

I was told that with FSDS2 (which I don't have) you could load the API macros (given that the sca file are available as well) and save / export them as library objects. I don't know if I would be able to still buy the old version of the program, neither do I know if it could be done with the current version as well.

I don't think that feature will allow what you are looking for, but as I don't use FSDS myself anymore I am not sure. I expect that the libraries FSDS2 can create will still be Fs2002 style libraries and not new Fs2004 XML style libraries (actually I am sure it can not make the new format). So that would not solve your problem, as the objects in the library would still use the same old scenery commands that they did when you had them as API macros.

It would only be useful if you could import the API object into FSDS and then re-export it with the new FSDS3 that supports the Fs2004 format. But I have never heard of a feature to read back a API file to a FSDS-source file.

 

[Sarge]

I expect that the libraries FSDS2 can create will still be Fs2002 style libraries and not new Fs2004 XML style libraries (actually I am sure it can not make the new format).

(I've been following your work for quite some time, Arno -- thanks to my design mentor, Jeff Stanyer.) Having used FSDS2 and, now, FSDS3, I can attest that if FS X drops SCASM support, FSDS2 API/SCA objects won't work in it. FSDS2 can only export scenery objects as API, SCA or BGL. (BGL is NOT the way to go unless a designer wants dozens of BGL's in the AddOn Scenery/Scenery directory for a single airfield, with the concurrent massive grab of system resources to display them.) Having both API and SCA formats will allow a designer to create a LibObj file, but it has to be compiled by SCASM as bglcomp will not recognize the format and, therefore, will not compile it to BGL. Likewise, they have to be called from the LibObj file with a SCASM-based XML, again which bglcomp does not recognize for compiling to BGL.

FSDS3, on the other hand, does not export as API/SCA, only MDL or BGL. Exporting as MDL uses the makeMDL (and, subsequently, bglcomp conventions for creating LibObj files and XML call-outs); so, unless FS X significantly changes the SDK's, anything created for FS2004 with FSDS3 should work in FS X. It is possible to import an FSDS2 raw design (the .fsc file) into FSDS3 and then export it as a scenery MDL. (And now for the BUT) BUT some design habits in FSDS2 will have to be corrected. It was possible in FSDS2 to be somewhat sloppy and not "Snap Together" all parts of an object. 'Taint so in FSDS3 (from personal experience so far). If the parts are not snapped, makeMDL will not process the data to an MDL. SCASM was somewhat forgiving, makeMDL is not. Some rework of the FSDS2 objects may be necessary before they will export as MDL.

(Didn't mean to intrude on your area of expertise; but Jeff has taught me a lot, and reading your responses to posts in these forums has taught me even more.) If this lowly grasshopper has offended the mighty Guru of XML and scenery design (in general), may my tents be infested with the fleas of 1,000 diseased camels.

 

[arno]

Hi,

When the designer still has his source files, loading the old files in FSDS3 and exporting them again is of course the easiest way. But sometimes you loose the files or you want to use objects that the author does not support anymore. I think in these cases some sort of converter might be useful.

As FS in general has a backwards compatibility with the previous version, it is very likely that any scenery created according to the Fs2004 standards will still work in FsX. So I would not worry there, but the older API objects do not use this standard yet.

It is btw not a question if FsX will support SCASM or not. It is about the scenery commands used, not the compiler. With SCASM you can also create scenery files according to the Fs2004 standard, so these should still work in FsX as well. But SCASM is not (yet) able to create scenery MDL files, so for 3D objects SCASM is no option at the moment. So we need to know which scenery commands will be supported in the future and then we can find a compiler that can create them.

 

[Sarge]

It is btw not a question if FsX will support SCASM or not. It is about the scenery commands used, not the compiler. With SCASM you can also create scenery files according to the Fs2004 standard, so these should still work in FsX as well. But SCASM is not (yet) able to create scenery MDL files, so for 3D objects SCASM is no option at the moment. So we need to know which scenery commands will be supported in the future and then we can find a compiler that can create them.

Correct in all aspects (as usual, of course) ; and if it's possible to produce something that will convert APIs to MDLs, a whole lot of designers will be greatly relieved.

As I said, I started with FSDS2, creating API/SCA objects then creating a LibObj file and compiling to BGL with SCASM, then creating call-outs for them and compiling to BGL with SCASM. With the upgrade to FSDS3, however, I recreated all of the old API/SCA objects as scenery MDLs (and used the KillShadow_shadow.x file during generation to remove a REAL framerate killer). If I had stayed with GMAX and gotten it down pat, I could have been producing my objects as MDLs all along .... from my point of view, MDLs are a MUCH better way to go. The design is cleaner (so makeMDL will process it), for one thing, and it's a one step process to generate. Combine that with your Library Creator XML and it's off to the races!

Looking forward to your next project with GREAT interest!

 

[Burkhard]

The scenery and airport MDL format is rather hard to read and to understand.

But MAKEMDL ( from FS8 SDK and the one from FS9 SDK ) both can read the .X format, that is a readable ASCI file, so if a API-MDL conversion tool is needed, API-X is enough and sounds a little easier.
Big advantage, than it would be possible to add several LODs this way, which is the main key to performance.

 

[arno]

The scenery and airport MDL format is rather hard to read and to understand.

But MAKEMDL ( from FS8 SDK and the one from FS9 SDK ) both can read the .X format, that is a readable ASCI file, so if a API-MDL conversion tool is needed, API-X is enough and sounds a little easier.
Big advantage, than it would be possible to add several LODs this way, which is the main key to performance.

Good point, but the downside of using the X-file format is that you will have to deal with the bugs in MakeMDL again. Writing the MDL file yourself means you can solve these problems.

But I guess we first have to wait what the future brings, before starting to make new conversion tools.

 

[TFE123]

Ok i've heard the term SBuilder thrown around here can anyone tell me what it does... im guessing its a Scenery Builder

 

[scruffyduck]

Probably best to check out the SBuilder Forum over at www.ptsim.com

There are two versions now - one for FS9 (version 2) and one for FSX (Version 3).

SBuilder can handle a number of scenery design activities including exclusions, landlass object placement and so on but not AFCAD type activities.

There are also some tutorials on using SBuilder 2 on my site and some on using SBuilderX on the forum mentioned above