Kerbal Space Program 1.4.2 is live!

[RoverDude]

8 hours ago, Foxster said:

For the Mastodon you mention, it has three variants, all of which have the same-sized shroud, the same-sized bell and on the smallest variant the base is between sizes 1 and 1.5. So there is little to guide us on what mesh size will be used for drag.

The mesh guide is literally the mesh you see.  Drag cubes for variants are calculated on the mesh itself.

[Foxster]

13 minutes ago, RoverDude said:

The mesh guide is literally the mesh you see.  Drag cubes for variants are calculated on the mesh itself.

Err, I can't see a mesh. I can see a rendering of an engine. Could you please explain this for the mesh-illiterate?

[Mr. Peabody]

The bugfixes are nice but I am not redoing my game to update. This happens too often.

[DMagic]

43 minutes ago, Foxster said:

Err, I can't see a mesh. I can see a rendering of an engine. Could you please explain this for the mesh-illiterate?

The mesh is what you see. It's the collection of triangles rendered on the screen with a texture slapped on top of it.

So if the mesh leaves part of the tank above it bare, then it is expected that the drag for the bottom surface of that tank would only be partially occluded. If the extra aero information is turned on for the part context menu then this would most likely show up in the negative Y axis, which I think is displayed as YN = ##, ##, or NY or something like that (the first number being the surface area not occluded, the second being a value having something to do with the drag applied).

Edited March 29, 2018 by DMagic

[Foxster]

Just now, DMagic said:

The mesh is what you see. It's the collection of triangles rendered on the screen with a texture slapped on top of it.

Ah, right. Calling it a mesh made me think of the outline you can see with mods like Sarbian's DebugStuff. In that mod, the box outline of the part does not change with variants. 

1 hour ago, RoverDude said:

The mesh guide is literally the mesh you see.  Drag cubes for variants are calculated on the mesh itself.

But what bit of the mesh is the drag calculated on? The bell size, the base size, the shroud size?

[DMagic]

Just now, Foxster said:

Ah, right. Calling it a mesh made me think of the outline you can see with mods like Sarbian's DebugStuff. In that mod, the box outline of the part does not change with variants. 

DebugStuff exposes several aspects of the part model. It shows a wire frame of the collider in blue, a wire frame of the mesh in orange, and the bounds box in pink (the bounds is basically the smallest cube that contains all components of the mesh, they are normally used for camera culling, to determine when an object is onscreen or not so that the camera can decide what actually needs to be rendered, for KSP they also seem to have something to do with drag, since the bounds are specified in the drag cube).

As far as I know it shows all of that stuff regardless of whether the corresponding mesh/collider is actually active, so what you see is the overlapping meshes, colliders, and bounds for all variants.

[mystifeid]

10 hours ago, iAMtheWALRUS said:

FYI, my LT-2 landing tail-strut on my space plane explodes on any contact with solid ground.  It does not say over-stressed in the F3 messages, just "LT-2 Landing Strut crashed into terrain".   This happens at 0.5 m/s.   I've reverted to 1.4.1 and it fixes the issue.

All my LT-2 landing struts on all my landers are exploding. Landing at 0.1 m/s seems to help but still need to be careful.

[Foxster]

Thanks for that. 

I'm still not a lot closer to figuring out what each tank size I can put each variant on and have a drag match. 

[DMagic]

1 minute ago, Foxster said:

Thanks for that. 

I'm still not a lot closer to figuring out what each tank size I can put each variant on and have a drag match. 

That's the point I was trying to make, at least partly. For the "bare" variants of an engine they probably won't, and shouldn't, exactly match any tank size, since some of the tank will be left exposed on the bottom surface.

For the other variants, either with tank butts or the shrouded versions they should just match the size visually. So if the shrouded Soyuz engine (can't remember the KSP name) looks like it fits a 1.85m tank, then it probably also fully occludes that tank. If it doesn't then maybe that's a bug, or the drag cube for that variant is just wrong.

[klesh]

So this makes the drag work as a layman would expect it to based on the visuals?  Cool.

Edited March 29, 2018 by klesh

[Foxster]

23 minutes ago, klesh said:

So this makes the drag work as a layman would expect it to based on the visuals?  Cool.

Dunno, cos there are three visuals: The bell, the shroud and the base (which may or may look like it's the same as a tank size). 

25 minutes ago, DMagic said:

That's the point I was trying to make, at least partly. For the "bare" variants of an engine they probably won't, and shouldn't, exactly match any tank size, since some of the tank will be left exposed on the bottom surface.

For the other variants, either with tank butts or the shrouded versions they should just match the size visually. So if the shrouded Soyuz engine (can't remember the KSP name) looks like it fits a 1.85m tank, then it probably also fully occludes that tank. If it doesn't then maybe that's a bug, or the drag cube for that variant is just wrong.

Yup, I get that. I just want to know for sure tho. 

It was a lot easier with the old tanks engines. They all had a clearly defined base and you could see what tanks an engine matched and so give a low-drag use. 

Edited March 29, 2018 by Foxster

[Starwaster]

5 hours ago, genbrien said:

the fact that we see plasma/fire throught parts now with that new effect IMO is the biggest problem

Believe it or not, the cause of that has always been there. It's just usually not noticeable because when the effects were at their most extreme it tended to obscure the problem. Render depth issue probably.

[basic.syntax]

2 hours ago, Daniel Prates said:

I made that very observation during development and got bashed by everybody in the forum....  "its not supposed to be a contract creator!",  some unimaginative peoole said. Well,  then why couldn't it? Nobody could answer that.

I would explain from time to time that Squad had decided missions would not interact with contracts,  but I agree that "it would be nice, if."  I think if Squad does not make an extension to the contracts system that can draw from a player's collection of missions at some point in the future, an enterprising modder is going to come up with something    Some would have to be restricted to one time per career - it would feel strange to re-roll "dawn of the space age" more than once. Some will be meant to be run consecutively, where the contract system is semi-random with some "weighting" mostly based on contract type you accept more often. You'd want to select or edit a list of which ones to permit into your career; consider that some will be short, some very long, and all written in different styles. 

[klesh]

3 hours ago, purpleivan said:

Those stripes just look wrong to me, as they pass over the circular parts of the texture. It almost looks like an accident that they're there rather than by design.

 

 

Yes, I agree.  I wonder if they are not intentional as well.  While the electrical hazard symbol is on the SM-25 is mirrored on both sides of the part, these stripes are only on one side.

 

Here you see the opposite side of the part, sans stripes:

Edited March 29, 2018 by klesh

[DMagic]

14 minutes ago, Foxster said:

Dunno, cos there are three visuals: The bell, the shroud and the base (which may or may look like it's the same as a tank size). 

Yup, I get that. I just want to know for sure tho. 

It was a lot easier with the old tanks. They all had a clearly defined base and you could see what tanks an engine matched and so give a low-drag use. 

It's still pretty easy, at least to me the values make sense. If you want to really check you could open the PartDatabase and compare values, but checking in-game works pretty well, too.

If you squint you can see what's happening.

 

On the right are 1.25m tanks with different variants of the 1.8m RK-7.

Check the YP values for the engines to see how exposed the top of the engine is to airflow (imagine looking down the rocket with the tank at the top and engine bell pointing away).

The biggest variant obviously doesn't fit and has a non-0 YP value, meaning the engine is not shielded from the "top", or its positive Y axis. The small shrouded variant has YP = 0, meaning it is fully occluded, as expected. The bare variant has a YP value between the other two, which also makes sense, all those bits and bobs are now exposed to the airstream instead of being hidden inside the smooth shroud as they are in the other variants. If you check the 1.25m fuel tanks above the engines you see that all of the have YN = 0, meaning the bottom of the fuel tank is fully occluded.

 

The 1.8, tanks in the middle are also attached to the RK-7. In all cases the engines are fully occluded from the top, as expected. And for the smaller variants the fuel tanks are partially exposed from the bottom, as expected (the tanks connected to the large shroud engine variant has a small YN value, 0.03, but that probably doesn't really matter).

 

On the left are 2.5m tanks with the 2.5m AJ10. The tank butt version matches the tank and occludes both sides as expected. And the bare version leaves part of the tank exposed as expected.

[Fireheart318]

We need a 1.25m engine plate. And a Mk2, Mk3, and 0.625m while you're at it!

[klesh]

23 hours ago, UomoCapra said:

+++ Parts
* Fix centering on the Rockomax Jumbo-64.

 

 

Almost! 

This fix too is going to need a do-over:

 

 

 

 

 

 

 

 

 

1 minute ago, Fireheart318 said:

We need a 1.25m engine plate. And a Mk2, Mk3, and 0.625m while you're at it!

 

Check out the Missing History mod:

 

Edited March 29, 2018 by klesh

[Daniel Prates]

41 minutes ago, basic.syntax said:

I would explain from time to time that Squad had decided missions would not interact with contracts,  but I agree that "it would be nice, if."  I think if Squad does not make an extension to the contracts system that can draw from a player's collection of missions at some point in the future, an enterprising modder is going to come up with something    Some would have to be restricted to one time per career - it would feel strange to re-roll "dawn of the space age" more than once. Some will be meant to be run consecutively, where the contract system is semi-random with some "weighting" mostly based on contract type you accept more often. You'd want to select or edit a list of which ones to permit into your career; consider that some will be short, some very long, and all written in different styles. 

My idea,  by the time I suggested it (now I do not know how I feel about it amymore) is that career mode should/could have a "create your own remunerated goal,  with a few drags and clicks of the mouse" type of thing. Since so much effort was spent with the creation of an interface for the mission builder ("canvas" this.... "canvas" that...),  I couldnt and still cant understand why the system created for the mission builder could not be adapted (if not outright copied) to career mode. 

Oh well.

Edited March 29, 2018 by Daniel Prates

[DMagic]

To add to the above, even a more uncertain case makes sense when you look at the numbers:

 

The bare variant of the AJ-10 is fully occluded by the 2.5m and 1.8m tanks, but not the 1.25m tanks. Which visually makes sense.

[Foxster]

Riiiiiight...So we just need to turn on a debug option and figure out a bunch of obscure numbers? Well that's fine then. 

Not. 

What we need is something much simpler like, oh say,  the engine base to match a tank size it's supposed to be attached to, like wot we have with pre-1.4 engines.  

 

Edited March 29, 2018 by Foxster

[klesh]

Is anyone else getting a wiggle on the ground/launchpad/runway with any craft that has landing legs on it?  Any landing leg will do.

 

 

I wonder if it is related to the LT-1 fix or not.  Perhaps all the landing legs share some component that was altered?  This behavior is unique to 1.4.2 for me.

 

 

Edited March 29, 2018 by klesh

[basic.syntax]

DMagic just used numbers to prove that ... you don't need to look at numbers; looking at the size of the engine bell in his examples is good enough. Moving up to the KE-1, I see a 1.8m tank fits perfectly under the engine bell and it includes a 1.8m "mid" base, so I expect that 1.8m will "just work" to occlude the bare variant.  

[Foxster]

The engine bell stays the same size for the variants, so that's not much of an indicator.

Edited March 29, 2018 by Foxster

[DMagic]

33 minutes ago, Foxster said:

Riiiiiight...So we just need to turn on a debug option and figure out a bunch of obscure numbers? Well that's fine then. 

Not. 

What we need is something much simpler like, oh say,  the engine base to match a tank size it's supposed to be attached to, like wot we have with pre-1.4 engines.  

 

No, you look at the size of the engine and the size of the fuel tank. If the engine has a tank butt or a shroud, then you match the tank butt or shroud to the fuel tank.

If it doesn't, if it's a bare variant, then it will never perfectly match any size fuel tank. But it's not hard to guess about sizing. If the engine bell is huge and the fuel tank is tiny then there will be drag and you should maybe reconsider the pairing. If they look pretty close visually then they will probably be pretty close in terms of drag. That dinky three-AJ-10 thing above was pretty stable once the fuel mass was balanced (and gravity was set to ~0.9 to get off the ground). 

I don't think there is anything complicated about that.

For occluding parts below the engine, like an engine in the middle of a stack, just use an engine plate or interstage fairing.

[basic.syntax]

Yes, the engine bell stays the same size, that's your guide. I mentioned the base size, but it does not matter.   RoverDude said: just look at the mesh (geometry / diameter) of the engine.  Smaller bases look better under engine plates and other custom mounting we might do.