Discussion Velcro + Universal Cargo Deck vs. Mulstistage.dll + spacecraft.dll

[Arthur Dent]

Hi Everyone,

I'm currently developing my own multistage launcher and some spacecraft.dll payload for it.
Then, I read in the screenshot thread, that Velcro rockets might be the better solution for that.

So I want to start a discussion about the use of Velcro rockets and Kulch's Universal Cargo Deck and find out why it might be a better way of having a multistage launcher than using a multistage.dll launcher.

What are the advantages, what are the shortcomings?

 

[Izack]

I answered to your other post here:
http://www.orbiter-forum.com/showthread.php?p=245779#post245779

I wouldn't recommend UCD for a launcher as it has no capability for launch autopilot.

 

[Arthur Dent]

Thanks!
So does that mean, if I have a Spacecraft.dll bases payload, like an Orion/Apollo type capsule, which engines shouldn't fire at lift-off, I can attach a Velcro based launcher to it, and I can still use the VC view of the spacecraft.dll capsule?

Because that is the biggest downside I found in the multistage.dll and spacecraft.dll configuration. If one would make an Apollo/Saturn launcher with that, It requires a lot of thinking and fiddling to have the cockpit view from launch to splashdown (If you do it the standard way, you would only have the VC after the Apollo CM separates from the SM)

 

[Izack]

Thanks!
So does that mean, if I have a Spacecraft.dll bases payload, like an Orion/Apollo type capsule, which engines shouldn't fire at lift-off, I can attach a Velcro based launcher to it, and I can still use the VC view of the spacecraft.dll capsule?

No, unfortunately. Velcro only creates the final payload once it has been jettisoned from the top stage.

AMSO has the only launcher I've seen to have a virtual cockpit available during launch, and it was all custom-coded without either multistage or velcro. (And you can't use it either, because the meshes get scrambled when they aren't used in AMSO's included scenarios.)

I haven't tried setting a spacecraft3 vessel as a velcro payload before, but I don't see why it wouldn't work so long as the payload name is the same as the config file name and spacecraft3 ini for that vessel.

 

[Urwumpe]

I think the lack of a autopilot is not that a problem if you really intend to write a DLL for your launcher. The effort isn't that high to make a simple one, if you did a few launchers in your orbiter life, you already have a pile of autopilot codes around.

And a sophisticated autopilot is also not really outside the range of even an intermediate developer. The NASA publication that describes the algorithm of an earlier version of the Space Shuttle autopilot is less than 70 pages long, in terms of technical documentation, that is damn short, and still well enough explained that you can adapt it to your needs.

I think multistage is some sort of a pact with the devil. It is right, it makes developing an add-on extremely simple and fast, but this also has a price: the quality of the add-ons is generally extremely poor, compared to even a cheap DLL. If people would put as much effort into a simple DLL as into tweaking around the shortcomings of multistage, by more and more sophisticated stage structures and spacecraft3 payload stacks, the add-ons would be awesome. The only valid excuse for never making a DLL is lack of interest to learn coding. But better, it is not.

You can't even animate a Multistage vessel. If you want animations and cool effects, like ullage and retro thrusters or explosive separations, there is no alternative to a DLL. Add new features like light sources or Lua script to this now with 2010.

Also, the Multistage autopilot is pretty crude, and most people waste a lot of energy into creating a profile for it that works.

 

[Nistenf]

I was wanting to make a little launcher with a CEV or something like that, I guess I'll have to learn some C++ coding

 

[Urwumpe]

I was wanting to make a little launcher with a CEV or something like that, I guess I'll have to learn some C++ coding

Believe me, the hardest part of it all is starting to code. Sadly, I have to warn you that it will be always hard staring at the blank project in the beginning and give yourself the push to start coding. :lol:

 

[Nistenf]

Oh yes, I know how that feels. Any tips on where to start? Maybe a good ebook or link? I'll look on the SDK section of this forum now.

Edit: Sorry, no more thread derailing

 

[Arthur Dent]

Well, I thought, taking a look in the Orbiter SDK and see how the default Atlantis was made, would make things easier. It might be easy if you're planing to make a satellite with no atmospheric model and one or two thrusters. But making a proper multistage launcher with boosters and all the stuff attached to it seems to be impossible for a person how can barely code "Hello World" in C++.
Even using multiple spacecraft.dll vessels as a multistage launcher seems to be less confusing to make than "proper" dll launcher.

Every time I think of coding C++ for orbiter, I look in the SDK examples and get so frustrated that I abandon the idea again. This happens to me about once a year. On the plus side: Every time this happens I pay +1 respect to the experienced Orbiter developers.

 

[Izack]

Every time I think of coding C++ for orbiter, I look in the SDK examples and get so frustrated that I abandon the idea again. This happens to me about once a year. On the plus side: Every time this happens I pay +1 respect to the experienced Orbiter developers.

I know exactly how you feel, except with me it's twice a month, and I still don't get it.

I'm planning on taking a C++ course in university as an elective...maybe that will help...someday.

 

[Urwumpe]

Oh yes, I know how that feels. Any tips on where to start? Maybe a good ebook or link? I'll look on the SDK section of this forum now.

Edit: Sorry, no more thread derailing

Start with one of the samples of the OrbiterSDK. No editing, just learning to open the project and compile it, then study the structure. Then after you have understood roughly how orbiter communicates with the add-on (Especially pay attention to InitModule, ExitModule, ovcInit, ovcExit and everything starting with "clbk"), you create your own project. There is a set of "templates" around in "OrbiterSDK\resources", which you can use with a VisualStudio to create a project in which the basic settings are already set.

The best way to program a multistage launcher is combining two important knowledges from two different fields:
- The theory about multistage rockets, especially what a logical stage is (a phase during flight of constant structural mass)
- The concept of state machines and at least one way to implement it.

The most popular way in Orbiter is to use an integer object variable that contains the current state number of logical stage of the flight. That should be your preferred way until you have grown more experienced with C++ and OOP.

Once you have understood things, you can look at this:

A much more flexible and easier to read way is to use a [ame="http://en.wikipedia.org/wiki/Strategy_pattern"]Strategy design pattern[/ame]. It is a bit more code for a simple rocket, so I don't really recommend it for small projects, but if you have a pretty complex rocket, you can use this pattern very well, making every stage a "concrete strategy" and using the "abstract strategy" as interface...

Yes, that is no longer the direct route, this is really about planning your rocket. The add-ons by estar use this route, it is really an example of how things really become great, since you can reuse most code of an add-on then for the next one.

That is where you should aim to go... messing with the best.

 

[Nistenf]

Great post, thanks! I'll start messing around

 

[N_Molson]

I'm planning on taking a C++ course in university as an elective...

That's a great idea ! :thumbup: