C++ Question Vessel development starting point

[Depth08]

Hello all,

Can anybody point me into the right direction here? I'm trying to get started writing my own .dll vessel. I want to avoid using vinka's spacecraft because I want to go for CoG compensation later on in the project.

I can program C++, but I failed to find a clear documentation of the orbiter API. There seems to be no clear reference guide of things I can use. Don't know what structure to keep in my vessel code, and the examples just don't show me how far I can take it with a custom .dll.

Any tips & tricks are also welcome!

 

[N_Molson]

Hello,

Some addon developers provide the source files in the download package. Velcro Rockets is an example amongst others. Seeing how others do the stuff and make comparisons is a good way to learn IMHO.

 

[fred18]

My starting point was the converter from sc3 to c++ made by artlav. It creates the basic structure of the vessel class. Starting from there the orbiter sdk documents is your friend to find the built in apis. At the same time you can check the examples given in the sdk and provided by various users. And take your time searching here in the forum because there are many answers here!
Talking about how far you can go: no limits,you can literally do whatever you want, it's just a matter on how much in deep you want to go!

For trips and tricks it depends on the result you want to obtain!

Cheers and good luck!

 

[jedidia]

I can program C++

You're halfway there, then, don't worry.

but I failed to find a clear documentation of the orbiter API. There seems to be no clear reference guide of things I can use.

Oh boy, you are so wrong, luckily.

Look in orbitersdk/doc. You'll find the complete reference as a chm or a pdf, depending on what you prefer, and you'll find the API Guide.pdf which will teach you the basics of programming a vessl or other module (but especailly vessels).

Also, the shuttlepb.cpp in the samples folder is always a good place to start trying out new functionalities. The Deltaglider source is also there, but it can be a bit overwhelming at first, and the structure is a bit messy... that much code should really be split into multiple files.

 

[Lisias]

Any tips & tricks are also welcome!

Some of the best uses of the API is not directly documented, you will need to read some fellow orbiter's source code to see the light.

My best advice is to download all add-ons with source you can grasp with your hands. Be kind while reading such source code, a lot of add-ons developers are not professional developers, and some that are, do it on scarce sparing time.

There are a lot of old add-ons with source on OHM (as Kev33 ones). I realize some are pretty old, and the current API is more resourceful. But I learnt some tricks there, perhaps it would serve you too. And if you find the time to bring them to a newer Orbiter, no one will be sad. It can be a nice exercise too.:thumbup:

Also don't hesitate to ask for help on the Development Threads. Be patient, however. Some questions can take some time to be answered... :rofl:

 

[Depth08]

Thank you all for answering my questions! I found the API in the orbitersdk folder. Completely forgot to check the root folder first :facepalm:

It seems as though it's not as hard as I first thought it would be. It turns out I learned a tad bit more about programming ever since going back to school.

Quick question I couldn't seem to find the answer to, can I use visual studio 2015? How would I go about setting that up?

 

[Urwumpe]

Quick question I couldn't seem to find the answer to, can I use visual studio 2015? How would I go about setting that up?

I have not yet succeeded compiling add-ons which use OrbiterSound or UCGO with VS 2015, because some library incompatibilities, I still need to do some research there. VS2013 works fine though.

Otherwise, remember: More important than any compiler, code pattern or mesh is the concept. If you have a good concept for an add-on ready, all those technical challenges can't stop you. Also, a good concept prevents the worst end boss, that can happen to you in add-on development, the dev ops challenge: As your add-ons become bigger and more complex, the more code you will write and the more you will have to learn all those little tricks and trades of software development, that make your life easier. It won't be a problem for a small add-on with just 1,000 lines of code, but if you pass through the 10,000 lines sound barrier, having a clear structure and development process will be mandatory. With a good concept, all this is easier to follow from the start, in comparison to an add-on that evolves over time into some alien monstrosity below the surface.

 

[Face]

Can anybody point me into the right direction here?

Did you already succeed in compiling the SDK examples? If not, try that and start tinkering with them.

Alternatively you can setup a build server, a version control host, write a formal procedure for your SCRUM process, apply roles to all members, hold specification meetings with yourself, do brain storming sessions until you've reviewed your add-on concept at least twice, then scratch it because it is 2100 and your add-on is incompatible with Orbiter 2080. :rofl:

 

[Urwumpe]

Alternatively you can setup a build server, a version control host, write a formal procedure for your SCRUM process, apply roles to all members, hold specification meetings with yourself, do brain storming sessions until you've reviewed your add-on concept at least twice, then scratch it because it is 2100 and your add-on is incompatible with Orbiter 2080. :rofl:

Also you must then also perform a multi-week PDR and CDR. For extra realism, don't wash the pot of the coffee machine until the CDR is done.

 

[Hlynkacg]

Someday I'll finish my LM and with it the tutorial but as far as a starting point is concerned check my signature below.

 

[Blake]

Quick question I couldn't seem to find the answer to, can I use visual studio 2015? How would I go about setting that up?

You can use 2015, I'm currently using the Community version.

Tip: Pull up one of the SDK sample projects into VS 2015, that will convert the property pages for you. Then reference those in your 2015 projects.

 

[jedidia]

Alternatively you can setup a build server, a version control host, write a formal procedure for your SCRUM process, apply roles to all members, hold specification meetings with yourself, do brain storming sessions until you've reviewed your add-on concept at least twice, then scratch it because it is 2100 and your add-on is incompatible with Orbiter 2080.

That kind of reminds me of a friend of mine, who lately complained that they had a project "in development" for almost two years now, and the "project leaders" were still discussing the best way to represent the structure (i.e. they didn't even start with the structural design itself, much less with any code). :lol:

 

[4throck]

Someday I'll finish my LM and with it the tutorial but as far as a starting point is concerned check my signature below.

That's what made my Orion possible.
I'd recommend going through Hlynkacg's tutorial, since the code seems to make sense.
At least to me with limited C++ knowledge it got me off on the right direction.

Still, don't discard sc3 or vessel as a way to structure your project.
That will get you working scenarios from the start, and ensure you have the meshes, configs, names, etc all right, before going into code.

 

[fred18]

I remembered that it was written somewhere and I found it, in orbiter wiki!

The Rules

1. ALWAYS test each change, no matter how small
2. For historical or real vessels, get good reference material
3. NEVER proceed to the next change if the last one doesn't work yet
4. Start with something you know works
5. ALWAYS ALWAYS test each change, no matter how small
6. There is NO rule 6
7. NEVER NEVER proceed to the next change if the last one doesn't work yet
8. Only make one change at a time
9. ALWAYS ALWAYS ALWAYS test each change, no matter how small
10. NEVER NEVER NEVER proceed to the next change if the last one doesn't work yet

 

[jangofett287]

Use a version control system. It is the solution to the "Yesterday it was working, today it is not working. What did I change?" problem.

 

[Lisias]

Still, don't discard sc3 or vessel as a way to structure your project.

That will get you working scenarios from the start, and ensure you have the meshes, configs, names, etc all right, before going into code.

I want to add/complement the above advice: do prototypes. Do not mind writing throw away code just to test things earlier. Starting your vessel as a .CFG only, and later "rewrite" it as a C++ module recently proved to worth the effort. Basically, when I think "what if", I frequently write some throw-away code to answer the question - a few of them became "good to stay" code.

I like to use "stock" vessels to test my stations (or carriers) features (as docking), and "stock" stations to test my vessels. This helps me to keep things interoperabile - and frequently pinpoints mistakes in the project earlier when fixing them is cheap/easy.

In a personal advice (your mileage can vary on this): don't mind making mistakes, au contraire, do them the most you can. Some of the best tricks I learnt born from a bunch of mistakes (some really dumb ) that, somehow, lead me to one nice idea.

Save a copy of your project when something works (using a code management system can make it easier, as advised earlier), and then you will always have a good copy to go back when something goes down the tubes. This allows you to try new things without being afraid to screw up something badly - now and then I do something dumb that crashes Orbiter relentlessly, and reverting to the last working copy saves my sorry frequently.


p.s.: As a "stock" vessel or station, please understand add-ons that come standard with Orbiter, or are só disseminated that it would make no sense using Orbiter without. Using them as benchmark rises your add-on compatibility.

 

[Urwumpe]

do prototypes. Do not mind writing throw away code ...

It is generally recommended, to not use prototypes in the final product. Even if they finally work, what you are interested in is not the code, but the solution. also a working prototype still contains non-functional code and lots of instrumentation.

The heroic software developer way: write a unit test suite, that lets the prototype pass. and then use the same test for the final version. Develop final version until all tests are green.