C++ Question Best way to learn C++ just for add-on developing

[Pipcard]

For someone who has never coded anything at all? Read tons of books on programming theory? Sounds pretty daunting. And yet people claim that it's so easy...

I really think, many people would be great programmers, if they would just not be so deeply scared of it.

And when I say "just for add-on development", I mean "just for add-on development". Also, how will I be able to do more than just create vessels that use modified ShuttlePB code?

 

[Enjo]

For someone who has never coded anything at all? Read tons of books on programming theory? Sounds pretty daunting. And yet people claim that it's so easy...

Sounds daunting, because you may think that education == school.
Don't read about programming theory, but programming practice. Try reading "Thinking in C++", and this category in parallel:
[ame="http://en.wikipedia.org/wiki/Categoryrogramming_principles"]Categoryrogramming principles - Wikipedia, the free encyclopedia[/ame]

And when I say "just for add-on development", I mean "just for add-on development". Also, how will I be able to do more than just create vessels that use modified ShuttlePB code?

If you want to learn only this way, then you'll create buggy code. Once you learn it well, only your imagination stops you.

 

[Loru]

And when I say "just for add-on development", I mean "just for add-on development".

I think learning c++ even solely for orbiter makes sense. Let me give you my example. I don't know c++ much. I can make PB clone with altered mesh and proper particle emitters/exhust textures to match it and basic aerodynamics.

Not much you'd say however after few months that knowledge paid off already. I'll be using my AV-88 Vtol (not released yet) as example.

You know well that Woo is coding the thing however with my very limited knowledge I was able to develop aerodynamics for it, make airbreathing engines and hover fans (so AV doesn't work in space), and do some minor things. That gave time Woo to implement more advanced features (tuning aerodynamics is time consuming).

Browsing through Orbiter API allowed me to sugest some interesting functions for my creations. Even if I cannot implement them now I can point those out to whoever is coding add-on so he/she saves time. (for example dynamic UVW update for my and RisingFury's MagneticShield add-on).

Also, how will I be able to do more than just create vessels that use modified ShuttlePB code?

By analyzing other source files. Atlantis can give you basics of staging. Deltaglider can teach you animations, VC, and 2d panels.

Yes - code looks scary at first glance but when you open it in editor and syntax will be highlighted to different colors things starting to make sense.

Don't be afraid of asking questions. There is good chance you'll get your answer but that may take some time (developers here are not 24h c++ helpdesk employes)

 

[asbjos]

My method is not recommended by the professionals, I guess, but here is how I got into programming for Orbiter:

Was interested in learning how to code, because it sounded cool to create things for Orbiter and computers in general. A friend of mine tipped me about the web page www.code.org. This page again lead me into www.codecademy.com. At Codecademy, I took "courses" in JavaScript. JavaScript is not too far away from C++, so after creating some easy scripts (prime number checker, degrees to radian converter, vector cross product calculator, etc.), I jumped into the C++ world by creating a vessel DLL. I followed this tutorial: www.orbithangar.com/searchid.php?ID=2210, and when I wanted to do something I didn't know how to do, I simply searched in the API_Reference.pdf, searched on Google, looked what others had done in their source code in the Orbitersdk\samples\ folder or, if neither worked, asked for help here in the Orbiter-Forum.

So I would not consider myself a coder, but a-guy-who-knows-what-to-do-to-get-what-he-wants simply by experience.

 

[Urwumpe]

For someone who has never coded anything at all? Read tons of books on programming theory? Sounds pretty daunting. And yet people claim that it's so easy...

Start programming with the simple examples - must not even be C++. There are programming environments like Scratch, which aim at children, but which already teach you many basics about algorithms and describing a problem and its solution in a programming language.

More important than theory is playing with the language. Start with a Hello world. Learn to make it ask for your name and greet you personally. Add new ideas to the simple start.

The books assist you, when things get really advanced and are a good help, if you are a better learner with books.

Just don't be afraid. Neither to program, nor to ask questions. We all learned programming one day. I learned the basics when I was 6 (in BASIC), and started developing my programs beyond the examples with 12 (in BASIC). I did not do all this alone, and I needed books because the internet was not helpful in the 1980s. But today it is. It was not impressive (some simple games in BASIC), but it was fun to have such successes like a moving sprite.

I learned the basics of C++ in 3 months between an internship and starting my apprenticeship there. When I was apprentice, I had a senior programmer acting as some sort of Guru to me. He was smoking like a volcano, consuming coffee in impressive speeds, was never having any patience and was always busy with coding at high speed... but still he taught me a lot about C++, that the books didn't tell me.

So, what can you learn from that: Programming does not depend on the language that you do, but starts on a much more abstract level of understanding, what actions you need to do to solve a problems and how you can explain them a computer so that he decides just like you would decide. Thats not C++. There is maybe some bit of logic involved. Mostly it is splitting one big problem (how to define the RCS of a complex spacecraft) into smaller problems that you already have solved once (how to define a single thruster)

What you will soon find out then: There is not just one solution for every problem, but actually, many solutions. And if you are lucky, one solution that can be realized and many that are ineffective.

And then you will by experience also get a number of standard solutions for a problem that appears often. Some of these standards appear in books already, that are worth a reading later.

But first learn solving problems with computers and then gradually shift to always do that in C++. The sooner you also learn to describe your solution in C++, the faster you will learn C++ and the solutions, that you have available in C++ without needing to invent them again.

And then get some books. Not many. You maybe never need more than 3 books in your life for C++. Reading the Orbiter API reference together with the sample code should help you to learn what exists.

 

[RisingFury]

Sounds daunting, because you may think that education == school.

 

[BruceJohnJennerLawso]

For someone who has never coded anything at all? Read tons of books on programming theory? Sounds pretty daunting. And yet people claim that it's so easy...



And when I say "just for add-on development", I mean "just for add-on development". Also, how will I be able to do more than just create vessels that use modified ShuttlePB code?

*Sigh*

I honestly cant believe I'm doing this. A year or so ago, I was thinking the same way, but ultimately, if you really want to know how to develop good Orbiter modules, youll need to read through something like this:

http://www.cplusplus.com/doc/

(as I recall, Orb directed me to this link originally when I was asking very similar questions :lol:. I wish I could find the link to the PDF though, cant find it at the moment)

I understand your frustration over not being able to cut straight to the Orbiter side of things, but if you want to go beyond recycled PB code, you'll need to know the syntax and how the language works. You can hack your way up to a semi-decent level, roughly where the Shuttle-D is now, without learning C++ properly, but it just wont work to try and create much beyond that. Its like trying to get dressed with a blindfold on: lots of crashing into things, and never really understanding how to avoid obstacles or problems.

At the same time, I suspect a lot of things in that tutorial could be discarded, or better yet, replaced by explanations of things that are more crucial to Orbiter like Handles. Maybe someday Developers Guide for Orbiter can do that.

Hate to be the bringer of bad news, but the Cult of the Probe succeeded in brainwashing me to their point of view

PS, am I the only one that thinks this thread might be a good sticky? This question is bound to come up a lot.

 

[Urwumpe]

At the same time, I suspect a lot of things in that tutorial could be discarded, or better yet, replaced by explanations of things that are more crucial to Orbiter like Handles. Maybe someday Developers Guide for Orbiter can do that.

Well, I am a big fan of letting people ask questions, because for formulating a question, you already have to think about your problems and likely will have half of the question already answered yourself and only leave the really good essence of the problem as a very good and smart question. (Yes, I am a big Sokrates fan sometimes)

I just find it hard to write a good developers guide for orbiter, because Orbiter is very flexible and I can't imagine writing a document that will please all the same.

Maybe, a mixture of spaceflight theory and suggestions how to turn it into code would be a good idea, because many developers for add-ons collide more often on mathematics and physics, than on C++.

For handles for example, you just need to know that they are just a number identifying the thruster or propellant resource in Orbiter. Of course, there is some about it, if you like hacking Orbiter, but for those who like to write add-ons that will still work two versions in the future, it is better to stick to the concept, that a handle only identifies the object, but is not the object.

 

[Hlynkacg]

If your objective is simply to make a vessel I will once again stoop to shameless self-pimpage.

See my sig...

---------- Post added at 11:25 ---------- Previous post was at 10:53 ----------

*Sigh*
I understand your frustration over not being able to cut straight to the Orbiter side of things, but if you want to go beyond recycled PB code, you'll need to know the syntax and how the language works. You can hack your way up to a semi-decent level, roughly where the Shuttle-D is now, without learning C++ properly, but it just wont work to try and create much beyond that. Its like trying to get dressed with a blindfold on: lots of crashing into things, and never really understanding how to avoid obstacles or problems.

At the same time, I suspect a lot of things in that tutorial could be discarded, or better yet, replaced by explanations of things that are more crucial to Orbiter like Handles. Maybe someday Developers Guide for Orbiter can do that.

Hate to be the bringer of bad news, but the Cult of the Probe succeeded in brainwashing me to their point of view

PS, am I the only one that thinks this thread might be a good sticky? This question is bound to come up a lot.

And before you, I.

Hail Probe!

 

[BruceJohnJennerLawso]

Well, I am a big fan of letting people ask questions, because for formulating a question, you already have to think about your problems and likely will have half of the question already answered yourself and only leave the really good essence of the problem as a very good and smart question. (Yes, I am a big Sokrates fan sometimes)

Ughh, Greek Philosophers

Very little of the thinking in the ancient world makes any sense to me save Rome, but that's another discussion...

I just find it hard to write a good developers guide for orbiter, because Orbiter is very flexible and I can't imagine writing a document that will please all the same.

Maybe, a mixture of spaceflight theory and suggestions how to turn it into code would be a good idea, because many developers for add-ons collide more often on mathematics and physics, than on C++.

Maybe, but I figured something is better than nothing at all. In any case, Developers Guide to Orbiter wont be happening anytime soon; writing consumes so much time for me!!!

But I will keep your suggestion about the maths & sciences in mind. I am a science student after all, so I should be able to help somewhat with that department.

For handles for example, you just need to know that they are just a number identifying the thruster or propellant resource in Orbiter. Of course, there is some about it, if you like hacking Orbiter, but for those who like to write add-ons that will still work two versions in the future, it is better to stick to the concept, that a handle only identifies the object, but is not the object.

Yes and no. I want to completely tear apart the concept of handles until I understand it as well as I can, as opposed to "Yeah, its a handle, sort of a pointer, sorta not, hey look there's a bunny over there!"

But that's just me :shrug:

If your objective is simply to make a vessel I will once again stoop to shameless self-pimpage.

See my sig...

Definitely a good :thumbup:

You really should give creating your own programs a try though Hlynkacg. The main reason why I and many others say this, is that once you learn enough C++ to develop good Orbiter modules, you can pretty much almost instantly start developing your own programs. The idea of learning C++ only for Orbiter is almost silly, because if you really learn C++ inside and out, creating new programs & non-Orbiter classes is trivial.

 

[Urwumpe]

Yes and no. I want to completely tear apart the concept of handles until I understand it as well as I can, as opposed to "Yeah, its a handle, sort of a pointer, sorta not, hey look there's a bunny over there!"

A handle is no pointer. Never forget that. Your ID number in your passport is pretty much a handle to you in the context of your government. Or your income tax number your handle to the tax office bureaucracy.

Neither does point to you nor does it represent you. It just allows to identify one aspect of you through an interface and hide the actual implementation from you (your tax returns are calculated by a old guy on an abacus, who constantly sleeps during the afternoon)

 

[kamaz]

A handle is a resource identifier. That's all there is to it. A handle may be a pointer (and in Orbiter, it usually is) but it does not have to be.

---------- Post added at 05:23 PM ---------- Previous post was at 05:16 PM ----------

JavaScript

Good advice.

Also, get a copy of Accelerated C++. A lot of books on C++ take a wrong approach by attempting to teach C first and then moving to C++. As a result you end up with a lot of bad habits.

 

[BruceJohnJennerLawso]

A handle is a resource identifier. That's all there is to it. A handle may be a pointer (and in Orbiter, it usually is) but it does not have to be.

Okay, so elaborate. Is a handle defined in a C++ program a sort of template class like std::vector that takes the type that it must store at creation, and why wrap data types in a handle (presumably related to the OS interacting with the handle somehow?)

 

[Urwumpe]

Okay, so elaborate. Is a handle defined in a C++ program a sort of template class like std::vector that takes the type that it must store at creation, and why wrap data types in a handle (presumably related to the OS interacting with the handle somehow?)

For the functional interface of Orbiters API, which has some merits in terms of allowing Orbiter bindings in different programming languages with different class models.

 

[RisingFury]

You can't learn to make good Orbiter plugins and vessels without having decent understanding of C++.

A handle in every context in Orbiter I've seen was usually a void pointer.

Something along the lines of

typedef void * HandleName;

So yes, in Orbiter, handles are disguised pointers. The reason it's helpful not to think of them as pointers is because a pointer points to a block of memory (which this does too), but even if you know what's there, you really can't use it. You have to let Orbiter manipulate it. So if you don't think of it as a pointer, think of it as a registration number.

Let's say you couple a thruster with a fuel tank. You basically tell Orbiter this:

"Couple thruster number 83845493 with fuel tank number 6328474."

That's why it's called a "handle", not a "pointer".


Still, take time to understand pointers. They tend to be difficult to grasp at first, but once you know them, you'll love them. They help make C and C++ stand out against other languages.

 

[kamaz]

Okay, so elaborate. Is a handle defined in a C++ program a sort of template class like std::vector that takes the type that it must store at creation,

In Orbiter, handle is usually a pointer casted to void * .

Consider the following example. We are writing a program which manages foos. A property of foos is that they can be bar'ed. A natural way of implementing API would be like that:

class Foo {
int Bar(void) { ... };
};

If the client wants to create a foo and then bar it, it does:

Foo *f = new Foo();
f->Bar();

However, the API programmer may find this overly constraining, because as the definition of Foo has been exposed to the user, it cannot be changed, as the user code would have to be recompiled whenever the definition of Foo is changed. So he decides to hide the definition of Foo object from the user, and does this:

typedef void * HFOO;

HFOO CreateFoo(void) {
return (HFOO) new Foo();
}

int BarFoo(HFOO hf) {
Foo *fptr = (Foo *)hf;
return fptr->Bar();
}

The client then does:

HFOO f = CreateFoo();
BarFoo(f);

Now, if the API author decides that for some reason, he needs to abandon foo for baz. Baz does the same thing that foo does, except that the class prototype is incompatible with foo. In the first variant, this cannot be done easily. However, if he has used handles, simply rewrites CreateFoo and BarFoo:

class Baz {
int Qux(void) { ... };
};

HFOO CreateFoo(void) {
return (HFOO) new Baz();
}

int BarFoo(HFOO hf) {
Baz *bptr = (Baz *)hf;
return bptr->Qux();
}

Voila! The client still happily calls CreateFoo() and BarFoo() thinking he actually bars foos. In reality, it quxes bazes instead.

This way, if you have written an add-on for the previous version of Orbiter (which uses foos) it will still work, despite the fact that the new version quxes bazes instead of baring foos.

 

[N_Molson]

One does not simply learn C++...

 

[kamaz]

For the functional interface of Orbiters API, which has some merits in terms of allowing Orbiter bindings in different programming languages with different class models.

If we want to get really technical, this is all due to the fact that objects, as opposed to functions, cannot be easily exposed via the DLL interface. (Thanks to lazyness of the creator of C++, ineptness of ISO C++ commitee and Microsoft's inability to remain compatible with itself.)

So instead of exporting class Foo as you'do in Java/C#, you pretend that the object pointer is a handle, and expose functions which take a handle, cast it back to object pointer, call object methods and return results.

In other words, you are wrapping C++ inside a C-compatible interface.

 

[Donamy]

I have a .dll converted by the SC3converter. I can open the Goose.cpp and Goose.h files in the compiler. I can make sense of a some things, but others seem very strange. How would I make it so, when I press the retro thust keypad "-", it activates the reverse thruster animation, and closes it when released ?

 

[BruceJohnJennerLawso]

I have a .dll converted by the SC3converter. I can open the Goose.cpp and Goose.h files in the compiler. I can make sense of a some things, but others seem very strange. How would I make it so, when I press the retro thust keypad "-", it activates the reverse thruster animation, and closes it when released ?

Depends on how complex the retro animation is. Does it involve multiple sequences, or is it just a pair of doors swinging aside or somesuch?