Project Multistage2015 - Development Thread

[K_Jameson]

That's in my mind... actually I'm a bit worried about it: on the Jarvis it was really difficult to implement it,

I'm against it: even after countless attempts, this effect was never entirely credible on screen during the Jarvis DLL development. I would focus on more concrete things.

---------- Post added at 03:06 PM ---------- Previous post was at 03:04 PM ----------

About the Jarvis DLL: I want to remember that this version is still a beta. I once had a list of various issues, annotated during a heavy beta testing session, long time ago. I never submitted this to Fred18 - that has a very busy life and is not always available for developing - and now that list is lost.

Now i'm in hiatus from developing, but I hope to resume soon my works. I have still some exciting stuff to finish and send out - Starlab, the interplanetary probes - and i'm impatient to restart my contributions. Because Jarvis (the multistage one) is somewhat a "son" for me - was my first FOI addon and the one in which i have personally spent more time and efforts with countless versions uploaded over time - i would be glad to update it with the brand new version of this interface...

 

[fred18]

Today's update:
- rocket builds up smoothly,ini file is parsed completely and correctly, thrust, weights, isp etc are computed and updated (also on staging/spawning events) correctly
- staging, fairing and payload deployments are working fine. Default vinka's values are guessed (tested also with a vinka and a ms2015 rockets side by side)
- delays in separations and ignitions work fine
- complete rocket process goes fine: autostaging, autoignition etc

Still to do for obtaining the vinka module:
- particle stream parsing and implementation. This should be easy. Difficult part is that it looks like vinka modue applies a default particle stream to boosters if not defined by user, therefore i will have to guess the proper default values
- atmospheric model: this is gonna be hard to guess, since vinka itself defines his atmospheric values as "arbitrary"... with the symple cylinder sections and implementation suggested by vinka i'm still low on drag
- default guidance system as it is now. Fun part starts here, i'm confident this won't take long

- after that is coded and working i'll publish it here for a bit of testing, while i'll start to implement the new features.

Cheers

Fred

 

[Face]

I totally forgot to ask a very important question: will you release it as open source?

 

[jacquesmomo]

Hi fred18 !!!
A very good idea !!!

Face for "generic_vessel" and you for a new "multistage"...

Thanks to both of you, I'm waiting even if it take a long time...
(and apologise for my bad english, as i'm french)....

 

[boogabooga]

I'm against it: even after countless attempts, this effect was never entirely credible on screen during the Jarvis DLL development. I would focus on more concrete things.

I disagree. I think it is really cool.

Perhaps you should change the particle color a bit to more red-orange when the expansion starts. But it is a neat idea, and gives a lot of life to the launch.

 

[fred18]

I totally forgot to ask a very important question: will you release it as open source?

I will. It will be a bit embarassing: since i'm not a professional programmer the code sometime will look silly to the expert people, but I think that could be useful to everyone to have the code available for this. If i had the vinka one, now my life would be a lot easier.

@booga: relevant to the particles I'll leave it at the end and optional as mentioned, so first i'll finish the rest and then with the option everyone will be free to choose whether to have them or not.

 

[Marg]

It would be cool if multistage for Orbiter BETA2015 would be available soon as well.

 

[Face]

It will be a bit embarassing: since i'm not a professional programmer the code sometime will look silly to the expert people...

This is totally irrelevant. If it does the job, no matter how bad the code looks in the end, the important thing is that the community will not lose it like it did with Vinka's.

 

[fred18]

It would be cool if multistage for Orbiter BETA2015 would be available soon as well.

The plan is to develop the orbiter beta version as soon as finished with the 2010P1 one. I need to work first with what i am confident and then, once everything is done and finished, to adapt it to the new orbiter. My plan is to finish the 2010P1 one within a couple of weeks, so before end of august having also the one for the new orbiter ready.

Let s see!

 

[Dantassii]

I disagree. I think it is really cool.

Perhaps you should change the particle color a bit to more red-orange when the expansion starts. But it is a neat idea, and gives a lot of life to the launch.

The red-orange effect you are talking about is only true for RP1-O2 engines. H2-O2 engines are nearly colorless, except for a blueish mach diamond at low altitudes. And I have no idea what the other 'historical' rocket flames look like at altitude. I suspect most are not red-orange.

Suggestion: May want to put some hooks in the code so that folks can hang a color on their flames as they expand. Make the default red-orange if you like, but make sure the users manual clearly states that the default is only appropriate for RP1-O2 engines.

Dantassii
HUMONGOUS IMS shipbuilder

 

[boogabooga]

Good point. I was talking about Jarvis specifically, but I agree about the other fuels.

 

[Lisias]

I will. It will be a bit embarassing: since i'm not a professional programmer the code sometime will look silly to the expert people, but I think that could be useful to everyone to have the code available for this. If i had the vinka one, now my life would be a lot easier.

People that are experts on coding, rarely are experts on the problem. The inverse is also true.

But the nice thing about Open Source is that you can have both in your project without doubling your costs.

The only really tricky issue is interfacing - it's a huge pain to publish an interface and, when a lot of people are already using it, you discover you messed up and need to change it. A lot of people will probably get angry with you ( been there, done that =P ). But this is a problem you don't have for now - the interfaces you will realize are already defined.

Just don't be afraid of rewrite everything two or three times and you will probably ending up with a good codetree.

 

[Face]

The only really tricky issue is interfacing - it's a huge pain to publish an interface and, when a lot of people are already using it, you discover you messed up and need to change it. A lot of people will probably get angry with you ( been there, done that =P ). But this is a problem you don't have for now - the interfaces you will realized are already defined.

Please don't frighten the good man. The important interface is already defined: Vinka's multistage format. If people get angry about changed additions, they can always go and use the old version. Or implement their own thing.

The real problem in this regards is versioning of the runtime. I've already written about that in the genericvessel thread, proposed a solution, and implemented it, too. I consider it solved.

Keep on going, fred18, you have the right idea. :thumbup:

 

[Lisias]

Please don't frighten the good man.

Not my intention! But I got pretty fried when I broke an interface once.

The important interface is already defined: Vinka's multistage format. If people get angry about changed additions, they can always go and use the old version. Or implement their own thing

I wasn't talking about interface evolution (in the sense of "next version"), I was meaning breaking it. Little things as changing the order of the values on an enumeration - ideally, everybody use the symbolic value, but there're some useful tricks using increments and static_casts and if you change the order of the enum, these tricks can stop working (and this is *really* hard to debug).

Of course, failing to synchronize the header with the DLL while deploying didn't improved my situation.

The real problem in this regards is versioning of the runtime. I've already wrote about that in the genericvessel thread, proposed a solution, and implemented it, too. I consider it solved.

This threadl? I will give it a peek

Keep on going, fred18, you have the right idea. :thumbup:

Just to clarify... English is not my mother language. Did I anyhow (involuntarily) stated that fred18 was in some kind of error?

 

[Face]

I wasn't talking about interface evolution (in the sense of "next version"), I was meaning breaking it.

You can break interfaces if you don't care about compatibility. It doesn't matter if you made the new interface incremental - and thereby compatible - or not, it will always be a new version. Just either a direct ancestor or a logical branch.

And this later relationship is what you need to transport to the user. But I don't want to hijack the thread for this discussion, it was already beaten to death in the thread I mentioned.

This threadl? I will give it a peek

It is this one: http://www.orbiter-forum.com/showthread.php?t=33130

Just to clarify... English is not my mother language. Did I anyhow (involuntarily) stated that fred18 was in some kind of error?

Well, your advice of not being afraid of having to rewrite everything two or three times to get to a good code base could certainly be seen as... discouraging. It also implies that he is doing it wrong now, otherwise he wouldn't have to rewrite it, right?

Also his statement that he finds the prospect of opening the code embarrassing is telling that he is not feeling that comfortable with his work yet. So I thought encouraging him might lessen that angst a bit.

IMHO there really is no reason to be afraid of opening code to the community.

 

[Lisias]

You can break interfaces if you don't care about compatibility. [...] But I don't want to hijack the thread for this discussion, it was already beaten to death in the thread I mentioned.

My point is that you can break it even by caring - and this is the only situation that can be embarrassing.

But I agree, there's no need to discuss this.

Well, your advice of not being afraid of having to rewrite everything two or three times to get to a good code base could certainly be seen as... discouraging. It also implies that he is doing it wrong now, otherwise he wouldn't have to rewrite it, right?

I don't see how this could be discouraging, I was trying to be encouraging! Some posts above he stated:

I will. It will be a bit embarrassing: since i'm not a professional programmer the code sometime will look silly to the expert people, but I think that could be useful to everyone to have the code available for this. If i had the vinka one, now my life would be a lot easier.

And what I'm trying to say is, besides inadvertently breaking interfaces (what's different to changing it on purpose), there's no such thing as an embarrassing code. You can write the worst CPP code in the World that everything is alright: you can rewrite the thing better later until you be satisfied with the resulting code (or stopping to care, what is ok too).

He will made mistakes? Everybody does (including me). But almost all of them are easily fixable with some rewriting later when someone else pinpoint you better ways (or you learn it by yourself) - it's how it worked for my, at least.

Do not fear the error: embrace it. In Extreme Programming, there's a motto where we say: "Fail early, fail often". The failures you don't commit early will be committed later when there would be more code to be fixed.

The only embarrassing mistake is the one you deny to acknowledge.

Also his statement that he finds the prospect of opening the code embarrassing is telling that he is not feeling that comfortable with his work yet. So I thought encouraging him might lessen that angst a bit.

It was what I intending to to.

IMHO there really is no reason to be afraid of opening code to the community.

Baby steps, perhaps? How about he rostering people he thrust to code review the project in order to get confident before opening the source?

 

[Face]

Baby steps, perhaps? How about he rostering people he thrust to code review the project in order to get confident before opening the source?

Well, if he doesn't open the source, the project is actually quite useless IMHO. It would just be another proprietary framework people can't trust to build upon, lest they are in danger to get stuck with yet another unmaintained (and unmaintainable) upstream.

In light of this, what good would a private review do? Deferring public release until a perceived quality is reached, defined by a small team of trusted people? I think especially in terms of XP thinking ("fail early, fail often"), it would be better to go public as soon as possible.

 

[Lisias]

In light of this, what good would a private review do? Deferring public release until a perceived quality is reached, defined by a small team of trusted people? I think especially in terms of XP thinking ("fail early, fail often"), it would be better to go public as soon as possible.

yes, I share your opinion: the sooner the code go public, the better.

However, I'm trying to address a "peoppleware" "issue", fred18's uneasiness on turning his code public.

 

[Face]

However, I'm trying to address a "peoppleware" "issue", fred18's uneasiness on turning his code public.

I see. "Peopleware" is a nice term. Indeed it is important to think about it with open source projects. :tiphat:

 

[fred18]

Hi guys,

I didn't expect to promote such a discussion :hide:

Actually my thinking is quite simple: I think that the code in the end will work fine, and that it is already not too bad, since I've been developing for orbiter for a while now. I'm not a professional so sometimes the code will look silly as said, but I won't stop developing, no worries

Thank to both of you for your consideration!

PS: I'll release the code already with the basic version of MS2015 (the Vinka's replica), so it will be open source immediatly.