Kerbal Space Program 1.4.2 is live!

[Foxster]

OK. I've finally got it...

It's just me, I'm weird and can see a problem that no one else does. Fine. 

Moving on...

[Foxster]

Nope. I just can't let it lie.

Look at the two variants of the Skiff...

That's a Shrouded variant (where's the shroud?) on the left and Bare variants in the centre and on the right. 

Now, if I was going to guess I'd say the drag would be low on the left and right engines when attached to those tanks because the sizes match, and the middle one will be more draggy because there's obviously a size mismatch, right?

Wrong...

The left one has a zero YP as anticipated but then so does the middle one, despite looking like a complete mismatch. 

The right one, that looks as though it's a good fit to it's tank, has a positive YP, so it doesn't really fit as well as it looks. 

Where's the logic?

 

 

 

Edited March 29, 2018 by Foxster

[Elric Kerbonaut]

On 3/29/2018 at 6:55 AM, radonek said:

After upgrading to 1.4.2 I get lots of  spammy "Control Parameter Complete" messages. Anyone seen this?

I am getting this as well - sometimes over 100 - I play mainly in contract mode and its close to a game breaker for me.

[ritz]

I'm also having the contract spam issue. I get like 100-200 parameter updates frequently. On my end it seems related to my satellite contracts, i.e. any ship I fly that has any of the components required for a satellite (even if I'm doing something totally unrelated) results in fulfilled contact parameter spam. As a very OCD person, I cannot resist acknowledging all these messages even though they are going to come right back when I switch vessels. I will not be making much career progress until the next update it seems.

I tried to revert to 1.4.1 but unfortunately my career save is no longer compatible with this version. (Does anyone know a work around?) I'm new to KSP and was not wise enough to keep a backup save.

Also FWIW, KSP is an incredible game and I'm very happy to see it is still being actively worked on. Thanks team.

[klesh]

11 minutes ago, Foxster said:

Now, if I was going to guess I'd say the drag would be low on the left and right engines when attached to those tanks because the sizes match, and the middle one will be more draggy because there's obviously a size mismatch, right?

 

That was my guess based on whats been discussed.

 

 

Though I suppose this could explain it to some degree:

 

While the bare plate on the lower engine looks like it should fit a 1.25m tank nice and snug, the visual model of the bell on the upper engine does go past 1.25m width (not all the way to 1.875 mind you) ever so slightly.  I suppose that should alert us to it not being a 1.25 appropriate engine?

Edited March 29, 2018 by klesh

[betaking]

regarding the nodes in the T-25 "Structural Tube: it still shows a gap/is slightly too far. (as in there's a noticeable void between the 2.5m structural tube and any 2.5m section of (say a battery or fuel tank) you place below it)

 

 

Edited March 29, 2018 by betaking
clarification.

[AccidentalDisassembly]

20 minutes ago, Foxster said:

Nope. I just can't let it lie.

Look at the two variants of the Skiff...

That's a Shrouded variant (where's the shroud?) on the left and Bare variants in the centre and on the right. 

Now, if I was going to guess I'd say the drag would be low on the left and right engines when attached to those tanks because the sizes match, and the middle one will be more draggy because there's obviously a size mismatch, right?

You are making a nonsensical assumption within the context of the game. Analogy: If you draft behind a semi on the highway (the tanks), and if you radically simplify the model of drag you use so that it's more like the game's (which simply looks at parts' sizes to figure out whether one's big enough to "push the air out of the way" for another behind it), why would drafting with a narrow car mean MORE drag for you + the semi together than if you were drafting with a car the same width as the semi? Isn't the semi still moving the air out of your way for you? It's not mismatches that create more drag, it's the cross-sectional area (width of semi/tank) hitting the air in the first place.

On the other hand, if your car was WIDER than the semi (as the engine bell is WIDER than the tank in the third example), wouldn't that mean more net drag on the combined "craft"? Bigger overall cross-sectional area, because now the craft is wider?

Obviously that's a reductive analogy - but KSP's drag model is a reductive model, so...

Edited March 29, 2018 by AccidentalDisassembly

[Elric Kerbonaut]

On 3/29/2018 at 7:02 AM, TriggerAu said:

There is a "Contract Parameter Complete" Info message that was added to the debug log to help with identifying contract issues if people still have that "lotsa funds" bug that some people found. Could this be what you saw?

This is not a debug log issue - for low Kerbin orbit rescue mission - used to get 2 messages - now i get 50 most of which are spam.

I have only one mod Kerbal Engineer and the save was stared in 1.4.1.

[monstah]

2 hours ago, Foxster said:

OK. I've finally got it...

It's just me, I'm weird and can see a problem that no one else does. Fine. 

No, man, it's not just you. I've been seeing so many problems, in fact, I don't even want to play this game anymore. I'm this sad with it, and have been so for a while now.

So, this is it. Good-bye, everyone! It's been a good run, I've had a lot of fun, both with the game and with you guys, but I just can't anymore.

 

@Vanamonde, @Snark, @Dman979, @Deddly, @TheKosmonaut, @Val, @luizopiloto, @Ten Key, @Darth Badie, @UomoCapra, and all the others at Squad and the moderation team: it has been an honor working alongside you. You're great people, you know you are. @adsii1970, @WinkAllKerb'', @NSEP, @tetryds, @5thHorseman, @GoSlash27, @LitaAlto, @regex, @tater and everyone else: there were ups and downs, but to me this has always been a great community, and thanks to you. Keep up! @Red Iron Crown, @Starhawk: I hope you're still out there, somewhere. Damn Canadian UFOs, give us back our friends!  >:( 

 

Really hope wish this game one day becomes the game it promises to be. Maybe I'll return, then!

Until then, love.

 

o7

[klesh]

Thanks for your service, bud.  We'll be here if you change you mind. 

[Foxster]

20 minutes ago, AccidentalDisassembly said:

You are making a nonsensical assumption within the context of the game. Analogy: If you draft behind a semi on the highway (the tanks), and if you radically simplify the model of drag you use so that it's more like the game's (which simply looks at parts' sizes to figure out whether one's big enough to "push the air out of the way" for another behind it), why would drafting with a bike mean MORE drag for you than if you were drafting with a small car? Isn't the semi still moving the air out of your way for you?

Obviously that's a reductive analogy - but KSP's drag model is a reductive model, so...

Yup, but KSP's simple aero model, which has no real aero occlusion, relies on matching same part sizes to determine whether adjacent parts have a low drag buff; a bigger forward part does not reduce the drag of a smaller rear attached part.

So we need to know what parts are the same size drag-wise so we can match them. You could do this with all node-attached pre-1.4 parts but you can't now with the "variant" parts because there's no way in the VAB/SPH to tell just what size the variants are considered to be by KSP. Their visual appearance is misleading as I showed above and the variants' names are meaningless. 

Edited March 29, 2018 by Foxster

[Not Sure]

There's an unrelenting slew of bugs with the 1.4 release it seems. Got one more for you. Kerbals in an EVA chair inside a cargo bay/fairing are not considered stowed and produce (lots of) drag.  This destroys a lot of SSTO designs like @Cupcake...s who submitted an official bug report, and my land speed record attempt with some details here: 

 

[NSEP]

Geuss who is not planning on updating anytime soon?

*salutes @monstah*, thank you for your service pal. We hope to see you again, when KSP is stable again.

[AccidentalDisassembly]

4 minutes ago, Foxster said:

Yup, but KSP's simple aero model, which has no real aero occlusion, relies on matching same part sizes to determine whether adjacent parts have a low drag buff; a bigger forward part does not reduce the drag of a smaller rear attached part.

So we need to know what parts are the same size drag-wise so we can match them. You could do this with all node-attached pre-1.4 parts but you can't now with the "variant" parts because there's no way in the VAB/SPH to tell just what size the variants are considered to be by KSP.. 

OK, well then maybe *I'm* making some wrong assumptions...but I though the "occlusion" simulated by KSP works when it's the last part at the back of the craft, but not when there's a mismatch and another part behind the one that doesn't match (e.g. big part, small part, then another big part). Maybe this all changed? I don't know. But it seems like the first and second cases should in theory be at least a little bit "occluded" (quotes because, as you say, it's just a simplified model), while the third one actually should produce a little more drag than the first two...

[klgraham1013]

9 hours ago, Daniel Prates said:

I made that very observation during development and got bashed by everybody in the forum....

Not everyone.  I was hoping for a contract creator as well.

[AccidentalDisassembly]

8 minutes ago, klgraham1013 said:

Not everyone.  I was hoping for a contract creator as well.

I didn't have any opinion on it before, but frankly, now, it makes zero sense (to me) not to integrate mission building and the contract system. Huge missed opportunity for fun stuff to do in the game as opposed to something that's more or less like another game-within-a-game. Obviously there might be a lot of really good programming reasons (or something) not to do it, maybe it's impossible given constraint X, blah blah blah.. but in theory/on paper, it's a truly bizarre decision to divorce missions from the rest of the game, and you have to wonder about the thought process. Another example of bizarre decision-making evident in the latest versions: separating the process of choosing variant themes into its own "thing" as opposed to simply being able to change themes will still looking at the parts you're theme-ing...

Edited March 29, 2018 by AccidentalDisassembly

[klgraham1013]

1 minute ago, AccidentalDisassembly said:

I didn't have any opinion on it before, but frankly, now, it makes zero sense (to me) not to integrate mission building and the contract system. Huge missed opportunity for fun stuff to do in the game as opposed to something that's more or less like another game-within-a-game. Obviously there might be a lot of really good programming reasons (or something) not to do it, maybe it's impossible given constraint X, blah blah blah.. but in theory/on paper, it's a truly bizarre decision to divorce missions from the rest of the game, and you have to wonder about the thought process. Another example of bizarre decision-making evident in the latest versions: separating the process of choosing variant themes into its own "thing" as opposed to simply being able to change themes will still looking at the parts you're theme-ing...

Having random, occasionally nonsensical, side quests be the main gameplay loop of career mode was a bizarre decision, but here we are.  Nothing surprises me with KSP at this point.

[Foxster]

19 minutes ago, AccidentalDisassembly said:

OK, well then maybe *I'm* making some wrong assumptions...but I though the "occlusion" simulated by KSP works when it's the last part at the back of the craft, but not when there's a mismatch and another part behind the one that doesn't match (e.g. big part, small part, then another big part). Maybe this all changed? I don't know. But it seems like the first and second cases should in theory be at least a little bit "occluded" (quotes because, as you say, it's just a simplified model), while the third one actually should produce a little more drag than the first two...

I've never heard of the penultimate and last parts behaving so as to reduce drag (unless size-matched). I thought there was one "rule" for all parts in a stack, except that the last part would be more draggy because of it's blunt rear end (unless its not an engine and you taper it). 

I could easily be wrong though - KSP's aero model is weird. 

 

Edited March 29, 2018 by Foxster

[DMagic]

40 minutes ago, Foxster said:

The left one has a zero YP as anticipated but then so does the middle one, despite looking like a complete mismatch. 

The right one, that looks as though it's a good fit to it's tank, has a positive YP, so it doesn't really fit as well as it looks. 

Where's the logic?

 

For simple vertical stacks the first YP value, the exposed surface area for the "top" of the part in question, is determined by comparing the YP value for that part when unattached with the YN value of the part it is attached to (that is, the numbers directly from the drag cube, not the values printed in the part context window), the fuel tank in this case.

These values should generally match their visual size, so all 2.5m fuel tanks would have the same YN and YP value, and all of the old 2.5m engines would have a matching YP value. The engine's with variants would have YP values that vary with the top surface size.

So if an unattached fuel tank has a YN value higher than the engine's YP value, then the engine's final YP value will be 0.

Which makes sense here, the middle fuel tank's YN is just a flat circle of 1.8m diameter (the units of these drag surface areas are a mystery, they clearly aren't m²) and the engine's YP is roughly the 1.25m top surface plus some overhang for the very end of the bell So the YP value for the engine would be 0. ie, before attaching, the tank YN is ~4 and the engine YP is ~2, so after attaching the engine YP is 0 (2-4=-2, you can't have negative surface area, so 0); the tank YN would be 2.

The tank YN is where you have the mismatch. I don't know what affect there is from having a high drag surface area on the trailing side of the rocket.

 

The small value for YP for the engine on the 1.25m tank does sort of make sense, all of the non-smooth surfaces are more-or-less exposed to air coming from above. The small value means it might not have much of an effect unless you start going very fast at very low altitudes. Clearly the Skiff is much bigger than the old 1.25m engines, so it's not unreasonable that it might behave somewhat differently. 

[AngryKitty]

Biggest issues for me so far are the LT-2 landing leg explosions, the 5m fairing (now with built-in Kraken damage!), and the contract notifications. Since my entire contract career relies on recoverable boosters with landing legs, I guess I'll have to wait until 1.4.3. It's a shame - I was actually really enjoying MH and 1.4 in general. 

[Foxster]

15 minutes ago, DMagic said:

For simple vertical stacks the first YP value, the exposed surface area for the "top" of the part in question, is determined by comparing the YP value for that part when unattached with the YN value of the part it is attached to (that is, the numbers directly from the drag cube, not the values printed in the part context window), the fuel tank in this case.

These values should generally match their visual size, so all 2.5m fuel tanks would have the same YN and YP value, and all of the old 2.5m engines would have a matching YP value. The engine's with variants would have YP values that vary with the top surface size.

So if an unattached fuel tank has a YN value higher than the engine's YP value, then the engine's final YP value will be 0.

Which makes sense here, the middle fuel tank's YN is just a flat circle of 1.8m diameter (the units of these drag surface areas are a mystery, they clearly aren't m²) and the engine's YP is roughly the 1.25m top surface plus some overhang for the very end of the bell So the YP value for the engine would be 0. ie, before attaching, the tank YN is ~4 and the engine YP is ~2, so after attaching the engine YP is 0 (2-4=-2, you can't have negative surface area, so 0); the tank YN would be 2.

The tank YN is where you have the mismatch. I don't know what affect there is from having a high drag surface area on the trailing side of the rocket.

 

The small value for YP for the engine on the 1.25m tank does sort of make sense, all of the non-smooth surfaces are more-or-less exposed to air coming from above. The small value means it might not have much of an effect unless you start going very fast at very low altitudes. Clearly the Skiff is much bigger than the old 1.25m engines, so it's not unreasonable that it might behave somewhat differently. 

Not sure I got all that but I'll take your word for it. Doesn't mean diddly-squat though for most folks assembling a craft.

I mean, it seems nonsensical to have to go into the part config files to get some numbers and then turn on a debug option to get some more and then compare them just to get the same results we get by eye-balling the non-variant parts.

Edited March 29, 2018 by Foxster

[DMagic]

1 minute ago, Foxster said:

Not sure I got all that but I'll take your word for it. Doesn't mean diddly-squat though for most folks assembling a craft.

I mean, it seems nonsensical to have to go into the part config files to get some numbers and then turn on a debug option to get some more and then compare them just to get the same results we do by eye-balling the non-variant parts.

That's what I'm saying. The numbers verify the expected results. You don't need them unless you want to verify them yourself.

An engine that's visually smaller than a fuel tank will work fine. An engine that's visually bigger won't. An engine where the engine bell is visually the same size as a fuel tank will probably work fine, but you're sort of pushing it. Just look at the old 1.25m engines and compare their bell size to that Skiff. It's obviously a different size class. But nevertheless, the drag effects will probably be minimal, so it would mostly work fine.

[Not Sure]

1 minute ago, DMagic said:

That's what I'm saying. The numbers verify the expected results. You don't need them unless you want to verify them yourself.

An engine that's visually smaller than a fuel tank will work fine. An engine that's visually bigger won't. An engine where the engine bell is visually the same size as a fuel tank will probably work fine, but you're sort of pushing it. Just look at the old 1.25m engines and compare their bell size to that Skiff. It's obviously a different size class. But nevertheless, the drag effects will probably be minimal, so it would mostly work fine.

IMO, with that engine, it looks kind of balanced. Its huge! on the second smallest fuel tank! maybe it needs that drag to make it not super OP and competition for the vector.

[Foxster]

1 minute ago, DMagic said:

That's what I'm saying. The numbers verify the expected results.

Not for me, and I suspect plenty of others. It might do for you because of your knowledge of the parts' internals. 

In my example above, I see the first engine with a nice clean transition to the tank, same with the last one, and I'd expect these to be low drag. The middle one looks mismatched and I'd expect it to be draggy. That also happens to be how non-variant parts work.

So we now apparently have two different ways of figuring out if an engine/tank combo is going to be draggy: If its a non-variant part then we just match the part sizes. If it's a variant part then we apply some different esoteric rules.   

[adsii1970]

@monstah: You're a good friend and will be missed. Please keep in touch, even if it isn't through the forum.