Project M-II + Negi-5 launch vehicles

[Pipcard]

Should I release this as Velcro first or should I wait and ask a person with programming skills to make a guidance autopilot and user interface for payload/rocket configuration (so that users don't have to edit .scn files, and because I lack the time to learn C++)?

I'm also planning on making a manned space capsule that launches on the M-II.

 

[Loru]

I think dll is better option.

You can reasonably guide rocket with single equation (pitch vs altitude for example) and integrated payload manager (Kulch's one or new Zatnikitelman's one) will surelly improve usage. You can either implement 2d panel for controls or use MFD aproach.

 

[Pipcard]

The thing is, I have no idea how programming works, and Izack once told me via PM that

If you don't want to bother with DLLs because you don't want to learn to code, great. Most of us who do that stuff are software engineers or technologists, or at least have interest in those fields outside of Orbiter. Wanting to make a functional rocket is a poor motivation to spend years learning to assemble C++ programs.

So I'm politely asking anyone with programming skills if they are available for doing such a task.

 

[Urwumpe]

So I'm politely asking anyone with programming skills if they are available for doing such a task.

Programming C++ is not the biggest challenge there, the language is much like chess (few rules, many options) and you really only need to know orbiters API and some mathematic functions to start well.

The big problem you would get is programming in general, and that you can also get with letting somebody else do the coding for you. You need to explain somebody else what you want and do that in his language. Nothing else is programming, the computer is just often a tiny bit more stupid than the programmer.

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

 

[Zatnikitelman]

If you sit down and work at it, I bet you could get a basic .dll vessel programmed in a weekend. Years down the road, you would probably look at your old code and might have the urge to defenestrate your computer, but if it works, it doesn't matter! Orbiter makes things fairly simple for programming a vessel. You can get fairly complex if you want, but you don't have to.

 

[Pipcard]

You know what, I've decided to release this initially as a Velcro rocket, because
-Editing scenario files isn't really that complicated (compared to coding)
-Velcro's autopilot is pretty decent; stable up to x10 time acceleration (the second stage burns for a long time)
-Neptune, Jarvis, Quasar rockets are still popular despite not being .dll-based yet (and using multistage2, which involves manual guidance files instead of a built-in autopilot, unlike Velcro)

 

[Pipcard]

I'll just release the mesh, textures, and stats of the rocket if someone wants to make a .dll with them.

Although making a .dll right now will make it harder to add future expansions such as a launch escape tower/fairing for a manned spacecraft (which I haven't made yet).

adding more to dll code would create possible bugs, instabilities ETC.

 

[Pipcard]

 

[Urwumpe]

Although making a .dll right now will make it harder to add future expansions such as a launch escape tower/fairing for a manned spacecraft (which I haven't made yet).

Why that? :blink:

 

[Pipcard]

Why that? :blink:

What do you mean?

 

[Urwumpe]

What do you mean?

That making a DLL first makes it harder to add capsule and escape systems. Actually, once you have found into the programming, making a capsule and escape systems is WAY more straight forward in a DLL, than you can ever have it with SC3/GV

 

[Loru]

Also you can code LV that way, it could recieve order from capsule (you'll make later) to release capsule (or whatever payload it is carrying) for example.

 

[Urwumpe]

Also you can code LV that way, it could recieve order from capsule (you'll make later) to release capsule (or whatever payload it is carrying) for example.

Yes, that is what I currently implement in the GLV, by the common electrical simulation. Also it will get a pretty sophisticated "structural behavior strategy" for handling a Mode I-II abort in a reusable (in terms of programming) way.

Short explanation: Mode I-II means, equipment section is separated from the reentry section and keeps sticking to the launch vehicle, while instantly all four retro solid rocket motors fire below the capsule and accelerate the remaining Gemini spacecraft away at about 2G (Which is why there was a honeycomb blast shield between retro section and equipment section)

That is the advantage of DLLs - your rules with all consequences. Gemini is dominated by relay logic, so it was only natural to go for an electrical interface path to handle the big slow events (and literally see on the amperemeter, how the spacecraft is busy with "thinking"). For any other, you could make your own interface, or join with somebody else to create a standard interface that multiple rockets can share and which spacecraft can support to have a standard launcher interface.

I could for example also make a simple adapter section, that converts the Gemini DC signals into digital commands for a standard launcher interface. Or convert standard launcher interface data into the DC signals for the GLV. My add-on, my rules. :lol:

 

[Pipcard]

I was thinking of initially making a partially functional escape tower (one that only separates from the rocket at a certain point during launch, like the Jarvis rocket/Antares spacecraft) with Velcro.

I know that making a fully functional escape system (like in Thorton's Soyuz) is more straightforward in a custom .dll, if you know how. But I was worried that, if someone makes a .dll right now, it would have to be modified later to add the escape system, which might "create possible bugs, instabilities ETC."

 

[Loru]

Piece of advice - If you find person willing to code it, make list of features with proper description of each feature.

Throwing out meshes with multistage config is not enough information for coder.

Plan into the future and think of add-ons that will be used with your rocket (for example LaunchMFD has problems with TVC control and that's one of reasons why Themis-A and HCLV are using internal AP).

You can make you rocket to support custom fairings and adapters so it'd be more versatile.

Adjustable height over ground could be handy to allow launches from different pads.

Make a list of commands your rocket can recieve (for example using clbkGeneric function) from it's payload.

Make a list of commands rocket can execute by player input (manual separation, fairing jettison etc)

Making exhaust textures particle streams in spacecraft3 (not multistage) also can help coder to do it faster as they're very similar (they have same data so coder just has to put it in particle stream function).

Be in contact with your coder and "bulid" your rocket with him.

You don't have to know c++ but you have to be aware what's possible within orbiter.

 

[Pipcard]

Negi-5 launch vehicle:

Payload capacity is about 2 tonnes to LEO; the upper stage is inspired by the H-I's cryogenic second stage.



---------- Post added 12-23-13 at 12:25 AM ---------- Previous post was 12-22-13 at 09:41 PM ----------

On second thought, it might be an all-solid launcher just like Mu-V/Epsilon. Just like Uchinoura Space Center, the small satellite launchpad at Negishima was originally designed for launchers with solid propellant (not cryogenic), and I don't know how I can justify the spending of hypothetical money on hypothetical modifications on the pad. Although, the upper stage had existed before in Hatsunese canon (as the second stage of an H-I equivalent)

Perhaps I could have gone with that. The M-II and Negi-5 launch pads were close to each other. Just now, I found this paper describing an upgrade for the Epsilon rocket, with a modified H-I second stage, 2 tonnes to LEO. Exactly the same thing as I was describing.