News Developers Guide to Orbiter v0.1

BruceJohnJennerLawso

Dread Lord of the Idiots
Addon Developer
Joined
Apr 14, 2012
Messages
2,585
Reaction score
0
Points
36
Hello folks,

Ive been working the last couple weeks on creating a document that teaches someone completely new to Orbiter how to develop. Its currently in a very rough first draft format & I need feedback on it, as well as advice on where to continue. If you have any experience in developing for Orbiter please download & take a look. I can only make this guide as good as the feedback I get.

For anyone actually new to developing, feel free to take a look, but please understand this is not complete by any means yet

Download here View attachment 11327

:hailprobe:
 
Last edited:

PhantomCruiser

Wanderer
Moderator
Tutorial Publisher
Joined
Jan 23, 2009
Messages
5,603
Reaction score
168
Points
153
Location
Cleveland
Well, it reads OK so far. I would change the font, and use a conventional Left Justify rather than leave it center justified.
 

paddy2

Addon Developer
Addon Developer
Joined
Jul 21, 2012
Messages
384
Reaction score
1
Points
18
Location
Kent, UK
While it may seem I am ungreatful for the work you have put in, I am sorry to say that font makes it unreadable
 

RisingFury

OBSP developer
Addon Developer
Joined
Aug 15, 2008
Messages
6,427
Reaction score
492
Points
173
Location
Among bits and Bytes...
I skimmed through the file and have quite a few suggestions:
- Font makes it an absolute pain to read.
- Text is centered and often has the appearance of a "wall of text".
- Images are too zoomed in and low resolution. It's difficult to get a grasp of what the code does if you only see a small bit of it on screen.
- Rather annoying use of the and symbol (&) in places of the word itself.
- Quite a few sections in the document are useless. You mention texturing, 3D modelling, config editing,... but beyond the title and a few lines, there's nothing to be learned from the document.
- The content is... narrow:

You often write about addon creation methods and then don't explain them or just refer the reader to someone or somewhere else.

In the 3D modelling section you praised Anim8or over Blender for beginners. I know that's subject to personal preferences, but as a beginner in 3D modelling, I found Anim8or a pain in the rear end to use and Blender was like dancing a waltz. You yourself even admit that Blender is a better piece of software in every way, so why would you steer people towards a headache? Anyone who doesn't want to limit their ability to create 3D models will eventually switch to another piece of software like Blender and will therefore need to learn it again from scratch, therefore doubling the learning curve. As for the learning curve, I also disagree. Blender is well documented - quite unlike Anim8or. Searching the Anim8or documentation for any particular subject is a waste of time. On the other hand, Blender also has some very detailed and high quality YouTube tutorials. Anim8or also lacks some vital tools that are essential for 3D and 2D design. You need to get a good UV unwrap tool separately from Anim8or.


"3d meshing is a very large, complex field which could take years to fully explain. In lieu of that, I will just try to explain the absolute basics needed to get in, get out, and make a good mesh while you’re at it."

Basic, not good.



"The process of making textures is sometimes not given all of the credit it may deserve by the Orbiter community. This is really unfair, as the process itself is difficult, and the right texture or skin can make the difference between okay & amazing with an add-on."

Well, sure, but taking a repaint kit and slapping a Hello Kitty picture on it is not amazing work.


"when the save dialog box is open in paint.dot.net."

There are other editors, you know... When creating a guide for anything, you should make it so that it's independent of the software people wish to use.



In fact, the first half of the document feels more like a collection of links and programs than a tutorial.


Bottom of page 10:
"Blue text usually indicates anything interactive(ish), Green text is commented, made null & void by // at the beginning of the line, and red usually is used with respect to anything pointed outside of the program itself, like the name of the mesh file for your spacecraft."

Blue are C++ keywords! Nothing interactive about those!
Red usually means plain text. Anything between quotes (" " or ' ') shows in red.
Comments can also be marked with /* and */ for beginning and end of the comment.


"Below this is what I believe is called the class definition. It is a little bit important to note that the term “class” has a different meaning in programming than you might have first thought. The term “class” is often used to describe a specific type of vehicle, like the P-51 Mustang, A6M Zero, Supermarine Spitfire, etc., of which thousands of each type were built"

That is exactly what a C++ class is! You define a class, then you can spawn thousands of copies of the same type of object. To simplify: Class is a blueprint that contains properties and functionality. From the blueprint you can build objects.


"Anyways, your vessels class is defined here as MyVessel, specifically a VESSEL3 class."

No, MyVessel is not VESSEL3. It's an extension of VESSEL3. It has all of the functionality that VESSEL3 has and now you're free to add more.


"Squiggly brackets are used in C++ to package & stack things, especially when placing them in hierarchical order."

They mean scope. A variable declared in a certain scope will only appear in that scope or those "below" it, but not those "above" it. Example:

Code:
...
{
// Scope A

{
// Scope B

int MyInt;

{
// Scope C
}
}
}

Variable MyInt will exist in B and C, but will not exist in A. C is below B and B is below A.


Bottom of page 16:

"The quirky side-effect of this is that you will probably get a negative ISP value at low Venusian altitudes."

That seems a bit unlikely. I don't know what function orbiter uses to calculate Isp as a function of pressure but I highly doubt is linear and I highly doubt it ever reaches 0. Maybe you can find the function somewhere in the documentation (API_Guide.pdf or API_reference.pdf).


"For reasons I don’t fully understand, Orbiters left/right coordinate system will do odd things, so it will take a little bit of juggling to get thruster lights appearing in the right spot."

IIRC, Orbiter uses only left-handed coordinate system. I've never encountered right-handed coordinate system in Orbiter. For the vessel, x+ is right, y+ is up and z+ is forward.

The programming part of the document is a mess. You throw a bunch of information at the user, but at the end of the section, the user has no idea how to actually make anything.

After the programming section ends, you start the Spacecraft 3 section in equally poor detail. If you are gonna mention it in the document, put it at the top.


If you really want to write a programming guide for Orbiter, I suggest you take the API_Guide.pdf as a base and continue from there. That document helped me to begin programming for Orbiter, but after I got started, I found it quite lacking. You could expand it by actually creating a document that would take you through the creation of the vessel from start to finish. You could provide the user with a mesh, textures and images for the 2D panels and guide them through the creation of the entire vessel from scratch.

Also, it's obvious that your knowledge of C++ is somewhat lacking, so don't be afraid to ask OF for help.
 

garyw

O-F Administrator
Administrator
Moderator
Addon Developer
Tutorial Publisher
Joined
May 14, 2008
Messages
10,485
Reaction score
209
Points
138
Location
Kent
Website
blog.gdwnet.com
I took a very quick look and had to stop, that font is horrible. For headings it'll be fine but any test that you want people to read really should be in a serif based font to make it easier on the eyes.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,616
Reaction score
2,336
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
Also, for writing source code examples, I really recommend the font "Source Code Pro". I use it at work and at home, it is really better to read than the usual Courier font.

Don't try to be too fancy. A bit of fancy is nice, like using fancy text box borders for making comments and additional information in your text stand out, but for the main text, less is more.
 

Izack

Non sequitur
Addon Developer
Joined
Feb 4, 2010
Messages
6,665
Reaction score
13
Points
113
Location
The Wilderness, N.B.
Blue are C++ keywords! Nothing interactive about those!
Red usually means plain text. Anything between quotes (" " or ' ') shows in red.
Comments can also be marked with /* and */ for beginning and end of the comment.

Excellent critique. I'd just like to add that the colours are IDE-specific, and user settings-specific. For example, in my C++ environment, keywords are orange, strings are gold, and comments are pink.
 

BruceJohnJennerLawso

Dread Lord of the Idiots
Addon Developer
Joined
Apr 14, 2012
Messages
2,585
Reaction score
0
Points
36
I skimmed through the file and have quite a few suggestions:
- Font makes it an absolute pain to read.
- Text is centered and often has the appearance of a "wall of text".
- Images are too zoomed in and low resolution. It's difficult to get a grasp of what the code does if you only see a small bit of it on screen.
- Rather annoying use of the and symbol (&) in places of the word itself.
- Quite a few sections in the document are useless. You mention texturing, 3D modelling, config editing,... but beyond the title and a few lines, there's nothing to be learned from the document.
- The content is... narrow:

You often write about addon creation methods and then don't explain them or just refer the reader to someone or somewhere else.

In the 3D modelling section you praised Anim8or over Blender for beginners. I know that's subject to personal preferences, but as a beginner in 3D modelling, I found Anim8or a pain in the rear end to use and Blender was like dancing a waltz. You yourself even admit that Blender is a better piece of software in every way, so why would you steer people towards a headache? Anyone who doesn't want to limit their ability to create 3D models will eventually switch to another piece of software like Blender and will therefore need to learn it again from scratch, therefore doubling the learning curve. As for the learning curve, I also disagree. Blender is well documented - quite unlike Anim8or. Searching the Anim8or documentation for any particular subject is a waste of time. On the other hand, Blender also has some very detailed and high quality YouTube tutorials. Anim8or also lacks some vital tools that are essential for 3D and 2D design. You need to get a good UV unwrap tool separately from Anim8or.


"3d meshing is a very large, complex field which could take years to fully explain. In lieu of that, I will just try to explain the absolute basics needed to get in, get out, and make a good mesh while you’re at it."

Basic, not good.



"The process of making textures is sometimes not given all of the credit it may deserve by the Orbiter community. This is really unfair, as the process itself is difficult, and the right texture or skin can make the difference between okay & amazing with an add-on."

Well, sure, but taking a repaint kit and slapping a Hello Kitty picture on it is not amazing work.


"when the save dialog box is open in paint.dot.net."

There are other editors, you know... When creating a guide for anything, you should make it so that it's independent of the software people wish to use.



In fact, the first half of the document feels more like a collection of links and programs than a tutorial.


Bottom of page 10:
"Blue text usually indicates anything interactive(ish), Green text is commented, made null & void by // at the beginning of the line, and red usually is used with respect to anything pointed outside of the program itself, like the name of the mesh file for your spacecraft."

Blue are C++ keywords! Nothing interactive about those!
Red usually means plain text. Anything between quotes (" " or ' ') shows in red.
Comments can also be marked with /* and */ for beginning and end of the comment.


"Below this is what I believe is called the class definition. It is a little bit important to note that the term “class” has a different meaning in programming than you might have first thought. The term “class” is often used to describe a specific type of vehicle, like the P-51 Mustang, A6M Zero, Supermarine Spitfire, etc., of which thousands of each type were built"

That is exactly what a C++ class is! You define a class, then you can spawn thousands of copies of the same type of object. To simplify: Class is a blueprint that contains properties and functionality. From the blueprint you can build objects.


"Anyways, your vessels class is defined here as MyVessel, specifically a VESSEL3 class."

No, MyVessel is not VESSEL3. It's an extension of VESSEL3. It has all of the functionality that VESSEL3 has and now you're free to add more.


"Squiggly brackets are used in C++ to package & stack things, especially when placing them in hierarchical order."

They mean scope. A variable declared in a certain scope will only appear in that scope or those "below" it, but not those "above" it. Example:

Code:
...
{
// Scope A

{
// Scope B

int MyInt;

{
// Scope C
}
}
}

Variable MyInt will exist in B and C, but will not exist in A. C is below B and B is below A.


Bottom of page 16:

"The quirky side-effect of this is that you will probably get a negative ISP value at low Venusian altitudes."

That seems a bit unlikely. I don't know what function orbiter uses to calculate Isp as a function of pressure but I highly doubt is linear and I highly doubt it ever reaches 0. Maybe you can find the function somewhere in the documentation (API_Guide.pdf or API_reference.pdf).


"For reasons I don’t fully understand, Orbiters left/right coordinate system will do odd things, so it will take a little bit of juggling to get thruster lights appearing in the right spot."

IIRC, Orbiter uses only left-handed coordinate system. I've never encountered right-handed coordinate system in Orbiter. For the vessel, x+ is right, y+ is up and z+ is forward.

The programming part of the document is a mess. You throw a bunch of information at the user, but at the end of the section, the user has no idea how to actually make anything.

After the programming section ends, you start the Spacecraft 3 section in equally poor detail. If you are gonna mention it in the document, put it at the top.


If you really want to write a programming guide for Orbiter, I suggest you take the API_Guide.pdf as a base and continue from there. That document helped me to begin programming for Orbiter, but after I got started, I found it quite lacking. You could expand it by actually creating a document that would take you through the creation of the vessel from start to finish. You could provide the user with a mesh, textures and images for the 2D panels and guide them through the creation of the entire vessel from scratch.

Also, it's obvious that your knowledge of C++ is somewhat lacking, so don't be afraid to ask OF for help.

Well, I would be hypocritical if I wasnt willing to accept tough feedback too ;). Thankyou

As to the font, yes I suspected that would be a problem as well, but I didnt bother to change it earlier since I wasn't sure. How does arial sound as a replacement?

As to the blender/anim8or debate, I still feel that it might be better to stick to it for a first try. If you're willing to help me in creating a tutorial on how to do the basics in blender, I can include that, but I also felt that Anim8or has a slight advantage because of the tutorials I listed by Ar81 are so good, and so on topic for modelling in Orbiter. I hear you, but Im not fully convinced yet

Yes, I know the repaints can be an annoyance to some, but there are many interesting things that can be done just with textures. Even a good exhaust texture can really add an extra element to making an add-on really outstanding.

The document is definitely imbalanced towards the programming tutorial, but that was an easier area to write than others. Please remember, this is only meant as a starting point for someone who is really, really new to developing. As such, some of these links are very useful to have listed somewhere.

About Paint.net, I would be more than happy to include references to other programs, but what would you suggest? Ive found Paint.net nothing but excellent for Orbiter, so it seemed natural to include.

Thank you for the points on C++. By move the SC3 part to the top, do you mean before the programming tutorial?

And, finally, I do agree with using the API guide as a building block, but I also think a slightly different approach is needed. It is an excellent document, but its contents would be better ordered in terms of difficulty. I personally feel that it would be best to work through things according to their relative difficulty level. If we can work a new developer through the first steps, without worrying about animations, VC, 2d panel, etc. then they can get a feel for how the process works. The biggest issue for developers at first appears to be that they add too much, too soon, rather than developing new features build by build, one at a time.

Other than that though, is it of any use? Is the document worth continuing work on, or should I just scrap it?
 

Ripley

Tutorial translator
Donator
Joined
Sep 12, 2010
Messages
3,133
Reaction score
407
Points
123
Location
Rome
Website
www.tuttovola.org
BruceJohnJennerLawso, excuse me but I have to ask: did you REALLY need to quote the entire post by RisingFury?
 

RisingFury

OBSP developer
Addon Developer
Joined
Aug 15, 2008
Messages
6,427
Reaction score
492
Points
173
Location
Among bits and Bytes...
Is to the font, yes I suspected that would be a problem as well, but I didnt bother to change it earlier since I wasn't sure. How does arial sound as a replacement?

I forgot to say that in the previous post, but I suggest that you try to mimic the documentation style released with Orbiter. People are accustomed to it.


As to the blender/anim8or debate, I still feel that it might be better to stick to it for a first try. If you're willing to help me in creating a tutorial on how to do the basics in blender, I can include that, but I also felt that Anim8or has a slight advantage because of the tutorials I listed by Ar81 are so good, and so on topic for modelling in Orbiter. I hear you, but Im not fully convinced yet

I'm not good enough to be able to instruct others, but there are excellent videos on YouTube that describe Blender in great detail and ease. I used them to learn Blender. Here's the link to the video series I used:

http://www.youtube.com/playlist?list=PL006307E237BB7FF6

If you want to learn enough to use Blender with orbiter, you need to watch episodes 1, 2, 3, optionally 4, 5, optionally 6, optionally 7 and 12. With that, you should get enough to make decent models and UV unwrap them yourself. That's about 80 minutes of video and it introduces you to more advanced modelling techniques than slapping together primes.


As far as ar81's tutorials... it doesn't matter how good they are. Ultimately the user is limited by the software they're using. I remember I made my first 300 poly mesh in Anim8or and it was a pain from the start. Just moving the camera is a pain. Trust me, steering people towards Blender from the start is a much better idea.


The document is definitely imbalanced towards the programming tutorial, but that was an easier area to write than others. Please remember, this is only meant as a starting point for someone who is really, really new to developing. As such, some of these links are very useful to have listed somewhere.

As a starting point, it's way to broad. I think it's unreasonable to expect a person to just pick up everything at once. I think separate files would be a much better idea, so the user that is trying to learn programming only doesn't have to go through the clutter of everything else. That way, each particular section can be explained in detail.


About Paint.net, I would be more than happy to include references to other programs, but what would you suggest? Ive found Paint.net nothing but excellent for Orbiter, so it seemed natural to include.

If you insist in mentioning programs, I think you should also mention GIMP and Photoshop as free and proprietary high level paint programs, but ultimately I think you need to explain your subject so that it can be understood and applied to any program. By default, Photoshop has no way of exporting as DDS, but you can get a plugin for it. Saving as DDS is easy enough, but picking the options is not. You need to explain what DTX and DTX3 are, for example, not how to actually select the DDS option and hit the save button...



Thank you for the points on C++. By move the SC3 part to the top, do you mean before the programming tutorial?

If you insist of having everything in a single document, then yes, bring the SC3 part before the programming part. The programming part is far from complete and it'll need to expand.


And, finally, I do agree with using the API guide as a building block, but I also think a slightly different approach is needed. It is an excellent document, but its contents would be better ordered in terms of difficulty. I personally feel that it would be best to work through things according to their relative difficulty level. If we can work a new developer through the first steps, without worrying about animations, VC, 2d panel, etc. then they can get a feel for how the process works. The biggest issue for developers at first appears to be that they add too much, too soon, rather than developing new features build by build, one at a time.

Just to make sure we're on the same page... there are two documents that Orbiter comes with. One is API_Reference.pdf that lists every function, every class, every struct,... available to the programmer with an explanation, but doesn't do it in any particular order that is useful to a newbie.

The other document is API_Guide.pdf (Orbiter\Orbitersdk\doc\API_Guide.pdf). That one does take you step-by-step through the creation of a vessel, but many of its sections aren't exactly detailed, some lack examples, bits of the document are becoming obsolete and some are downright missing. The API_Guide is a great starting point for the programmer and as I said, it helped me greatly when i first started.

Ultimately the experienced programmed switches to the API_Reference.pdf, but it is too much for a newbie.


Other than that though, is it of any use? Is the document worth continuing work on, or should I just scrap it?

You should definitely continue working on it. I understand that this was just the first version so as time goes on you should definitely be able to improve this. Just keep in mind that this might be a long project...
 

Loru

Retired Staff Member
Retired Staff
Addon Developer
Donator
Joined
Sep 30, 2008
Messages
3,731
Reaction score
6
Points
36
Location
Warsaw
...
Well, sure, but taking a repaint kit and slapping a Hello Kitty picture on it is not amazing work.

How dare you ?????? [ame="http://www.orbithangar.com/searchid.php?ID=5130"]http://www.orbithangar.com/searchid.php?ID=5130[/ame]
 

ADSWNJ

Scientist
Addon Developer
Joined
Aug 5, 2011
Messages
1,667
Reaction score
3
Points
38
Firstly BruceJohnJennerLawso, kudos to you for starting this project. It's easy for people to critique a piece of work, but much harder to create something from a blank sheet of paper. For a v0.1, and potentially starting a community-written bible of development on Orbiter, I think that this is cool.

I think you can structure this guide into various chapters by type of development you want to do. For each chapter, you can describe the big picture of what you are doing (e.g. meshing), then a brief explanation of the tool choices and links to download / learn the basic tool, then then bring it back to the context of Orbiter.

I have not done any mesh work or textures, so I am interested to look at that from the viewpoint of a total n00b. If by the v1.0 version, I can do some basic artifacts in this area, then the guide will definitely be hitting the mark. (One side-comment on the Microsoft barb ... getting their butts handed to them, etc ... I vote for just dropping that. There's enough religion in IT, that such comments are counterproductive, especially when you don't then equally praise them for providing the whole Visual Studio Express for free, etc.)

On the C++ side ... where I can comment with a bit more experience ... I think you need to figure out who you are addressing. For example, I would suggest that you ask people to be at least aware of C++ to get value out of a C++ for Orbiter chapter, and if they wish to learn C++ from scratch, then point them to other sites (e.g. http://www.cplusplus.com/doc/tutorial/ ). What I was looking for when I first started coding MFD's on Orbiter was an overview of what was calling what, and how the persistence worked. (E.g. when you change view or resize an ExtMFD your main class instance gets blown away, so you need to understand how to manually persist your critical code to cater for that issue.) Also - quickly getting set up with the right external dependencies in Visual Studio, and point the output to the right place, and setting up the debugger to call Orbiter.exe, etc was all obvious in hindsight, but each took me a while to find. So there's basic things on VS configuration for Orbiter, then more involved things on the mechanics of the call stack, then the deeper issues of coordinate systems, matrix manipulations and graphic output into the simulation, and the deepest knowledge of the physics involved (forces, heating flux, thrust equations, orbital elements, etc) that can be examined for years before achieving mastery!

Finally - I think a common approach to source code management, versioning, LGPL license basics, etc, would be cool, so the next generation of addons all start with the best of advice. (I'm still figuring this stuff out too!)

Great start ... keep going!
 
Top