AOSP or Advanced Orbiter Scenario Parser

[SolarLiner]

Here we go. Along with my Shuttle PB Mk2 project, I started this one with an idea: how simply can Orbiter scenarios can be handled ? The answer was definitely AOSP.

So, what is AOSP ?
It is a bunch of classes that allow developers using whatever .NET language to create, modify and save Orbiter Scenarios. It's a challenging project for me, and I sure will learn a lot about coding on this one too.
AOSP will provide the developer a nice set of classes, which are much easier to play (I mean, code) with, and will provide better results than a hard-coded parser from scratch.
Everything will have its own class: A class for the environment, one for the current camera, one for the ships, one for ... you get the point.

I'll love to AOSP !
First, stop. AOSP is only a verb for me. :lol:
Wait a little. AOSP is at its "starting" state, and little was done. If you like to help me, contribute to the project.

I'll love to help you !
Nicest thing I've ever heard !! Link to the Sourceforge repo at the end of the entry. I accept you in the dev team !

What about me, who don't code and still enjoy Orbiter and its 3rd party tools ?
The Sourceforge link will have downloads of the latest versions of AOSP. If asked, it is here to download the binaries.

Why Shuttle PB Mk2 and AOSP at the same time ?
Because I love to have some projects in progress at once. Because I love coding. Because I love Orbiter. And trust me I'm an engineer, both developments will not take longer because of each other. I'll just pass more time behind a Visual Studio window, that's for sure

Link to the repository: http://sourceforge.net/projects/orbaosp/

 

[Face]

I've already started a similar development as part of the OMP server (which is in C#). In essence it is a general serializer/deserializer for various Orbiter file formats, starting with configuration files. The basic ingredient I'm using there is called GOLDParser, a general parser framework. My work simply consisted of creating grammars for Orbiter's file formats, and then let a .NET parser engine convert it into objects.

Take a look here: http://bitbucket.org/face/orl-onlin....Multiplayer.Server/Map.cs?at=ORRL2010#cl-431

 

[SolarLiner]

Your approach is interesting, and while I've heard of parsers, I try to not use them for obscure reasons (the main one is because I started with no parser and I don't want to include one for now). But if things gets too complicated by my way of parsing, it is sure the way I'll be going.

Now AOSP will only look for a scenario, the only thing needed later is the parent body mass for Elements <-> StateVectors calculations.

Finally, I think you will not release the parsing work you've done as a standalone .NET library.

So good luck with OMP, and I'll still give a look into the parsers if that can still save me time (as I got my "own" parser done and ready and tested)

 

[Face]

From my experience, coding parsers dedicated to one special format is always a dead end. You'll end up with obscure bugs that you can't really debug, and you'll have a hard time to maintain the code if the format moves on. A result of this will be a small (and eventually non at all) user base.

Using a special grammar in a general framework is much more reusable, too, as I could easily put my work in a standalone .NET library. I can even extend it easily by writing another grammar and putting it into the same parser engine. I wouldn't have to worry about lexing, tokenizing and comment-checking the input file, just about what the content is.

Now don't get me wrong, I can understand that writing a dedicated parser for a format makes sense in terms of development time if you develop an application using it. But you are developing a library, so I'd try to make it as modular as possible, and not to reinvent the wheel.

But of course your mileage may vary. Good luck to you, too!