Lisias

Addendum: I think it would be a good idea to award stock and mod vessels separately.

While looking on the numbers from the spreadsheet (this one, now under ownership of the Challenge Master, and this other I'm messing around), we came to the conclusion that would be very hard (and probably frustrating) trying a "one rule to score them all" approach. How about, then, just open 4 or 5 "awards", each one being ruled by its own formula, and then every vessel would be scored on each one of them? And then the "award" would be granted for the bests scores in each formula. Would be *very* interesting to see a given vessel being awarded in more than one formula! (that would be a challenge by itself!). The following is what we came until the moment (just brainstorming! Please develop the concepts!): The highest altitude (bonus for each original part that touch down with the root part?) The best altitute/crew ratio (which bonus would be nice?) The best altitude*cost/crew ratio (ditto) The biggest crew to cross the Karman/altitude ratio (ditto²) The best crew/max_horizontal_velocity ratio (ditto³) Contests for relaunching the vessels and landing them on pads can be interesting also! I would love to see a 50 crew vessel landing on the VAB helipad! :-D

How KSP handles inertia? I'm getting the grasp on drag, but I'm didn't make my mind yet about inertia... edit: Whoops... wrong window. sorry.

Until the moment, my biggest blunt was a good landing by the book (that one you can walk from). Unfortunately, the last landing the airstrip ever saw. Don't ask how I did it. I never managed to do that again. ;-)

I'm afraid the problem *is* the 1.4.2, not the mods.

As opportunely reminded by @Gargamel , all that matters is vertical velocity. On spacecrafts, if you get enough horizontal velocity, you ended up with vertical velocity too (it`s exactly what we do to launch into space by the way - speeding up horizontal velocity until we get enough centripetal force to countermeasure the gravity), but getting into there while on atmosphere will burn you to ashes. It`s the reason, until now, that small ballistic vessels have an edge - we`re converting all our thrust into vertical speed, what can only be accomplished on light vessels with huge TWR. Some testings here suggests that weighing crew number over altitude counter measure this. And by somehow promoting a better crew/vessel_cost ratio into scoring, one have to build a really fantastic small vessel (and landing it on a pad, if using my scoring) in order to have a chance against a high crewed vessels. 202Km high is an achievement. My best until the moment is about 160km. :-)

Yeah, some empirical testing here demonstrated exactly what you said. Without thrust and without atmosphere, we are essentially doing ballistics here, on a parabolic launching (literal translating for a entry from my local high school books). Incredible how you miss simple things as you get old. =D All that matters is the vertical speed at the moment you loose thrust.

Can I apply for a new entry? 158080 meters, and I landed on the airstrip. I think I loose a part or two, but hey! Every landing you can walk away is a good landing (even when you have to wait the ground stop burning first!)

"A good landing" =P

Destroyed the KSC`s airstrip while landing a spaceplane. Well, any landing you can walk away is a good landing, but in this one Jebediah had to wait the ground to stop burning before walk away from it. :-)

Not one of my brightest moments... =/ How much fuel it had at takeoff, and how much it had at touchdown? Some scores take this in consideration. (and I couldn't take the numbers from the video, Youtube shadows that part of the video, !#$#!#@$)

Read it again. Carefully. :-)

In time, the @hoioh's vessel with 14 crew is a very decent vessel to try our scorings. I could not figure out the vessel total cost, however. Hoioh, can you give this number?

I did. Here. Some data had to be inferred from the screenshots (as the proposed new scorings use them). From the scoring systems until now, I think no one really cut it. =P Mine appears to do a decent job, but then a freaking hacked mastodon, wasting fuel as there're no tomorrow, barely reaches the Kerman Line for a few seconds and gets the highest score. Not fair - the time the vessel stays above the Kerman Line must be accounted for my scoring, or I don't think it will work. @hoioh's one does a decent job, IMHO. But I like @neistridlar approach to promote efficiency. It will prevent a "moar boosters" :-) approach to get high escores (exactly what that mastodon of mine did), what hoioh's approach ignores. But it doesn't promote accuracy (landing on airstrip - or on a Pad as I did). All approaches (including mine) don't count the time the vessel stays above the Kerman Line, what I think would be one of the best metrics for this challenge - if we cook up a way to measure it.

Yep, I noticed that. The fuel used is also accounted for. I think, however, that pilot only vessels should not be written out from your score. I updated my spreadsheet with the various scoring proposals until the moment. Would be interesting if I could use data from the vessels posted here too, for comparison!

Your equation is demoting the landing! This equation makes better to land in anyplace but the airstrip. I think it should be: ((launch cost - recovered cost)*max altitude) / ((kerbal capacity - pilot)*(1.5 if landed back on a runway)) Additionally, I think we could reward landing on a small spot, like the launching pad or a helipad. :-)

I made a Google Sheet using my entries (and some derivatives) here. I think that carrying more passengers should be more weighted than mass, but it's soon to be sure. The time the vessel spends above the Karman Line. I'm trying to figure out a way to measure that without using KRPC. :-)

I think that the time you spend above Karman line should be considered. A heavy vessel that rounds Kerbin @ 71.000 meters should score way higher than mine than reaches 120.000 but stays above the Karman line for a few minutes (given the same number of passengers).

Perhaps using the the aircraft landed weight as a multiplier bonus for the altitude? The more weight you have *on landing*, bigger the bonus. And a bonus for landing in the same attitude you launched, or alternatively, by landing and standing over landing wheels or legs. This will make things a lot harder for vessels like mine. =D And perhaps another bonus for not using clipping, to address my jealously of not thinking on it first!!! :-D :-D How about math.log(num_passengers) as a bonus multiplier? Bonus would start to kick in from the third passenger.

Holy Molly! I'm stupid! I can save TWO parts on the vessel! #facePalm But I got about 800 meters lower this time. 6 * 7621 / 132299 = 0.3456262 -1 = -0,6543738 Pictures, evidences and video in: https://kerbalx.com/Lisias/Karman-Crossing-Challenge-Mk1 or And I managed to save the engine this time! :-)

I think I've scored a good one... 8 * 8461 / 133112 = 0,50850412 [EDIT: No landing bônus, I blow up a engine on landing!) Pictures, evidences and video in: https://kerbalx.com/Lisias/Karman-Crossing-Challenge-Mk0

This is not uncommon (neither necessarily a bad practice) in the industry. Sometimes the way we fix for a problem last release just don't cope with another fixes (or features) we need to code for the next. And given the enormous complexity of this program, I would not be surprised if this happens a lot here. But in a way or another, one should keep track of such events. Closely. And coordinately.

Man, thanks for the symmetry awareness. This will make my life a lot easier. :-)

One change from 1.4.1 to 1.4.2 that got to my nerves is on the Editor. I'm building an aircraft, and there's some clipping needed on a specific part. On 1.4.1, I could snap the thing on the closest spot and then using the Translate tool, fine tune the position until the right place. Well, now this is way harder - I must hit the sweet spot at first try. If I miss the first try, when I try to translate again, the parts just pop-out into a snap hotspot, even with the Snap Button UNSELECTED. I was never too fond from the Snap and Symmetry buttons changing by their own while editing, more than once this bite me in the back - but now the thing is happening even without the feature being selected, so I just can't know what is going to happen because the feature happens without changing the button state! =/ I don't think it's a testing issue anymore. This kind of regression has deeper roots. I think they're loosing control of the code-base - they can't anticipate anymore the collateral effects of a change in a code, and so they don't know for sure what need to be tested once a change is made.

Is the dispute for the last place still open? :-)