Kerbal Space Program 1.6: “To Vee or not To Vee” Grand Discussion Thread

[TriggerAu]

10 minutes ago, Yakuzi said:

I have resubmitted the issue to the bug tracker here: https://bugs.kerbalspaceprogram.com/issues/20423. Any up-votes or comments are immensely appreciated!

...

Thanks for the new report and visibility

I recall the discussions last time and Sals meaning there was reworked, not revoked (from text I cant share) - which has a slightly different context. 

[Yakuzi]

5 minutes ago, TriggerAu said:

Thanks for the new report and visibility

I recall the discussions last time and Sals meaning there was reworked, not revoked (from text I cant share) - which has a slightly different context. 

Thanks @TriggerAu

I was referring to this, I'm obviously oblivious to what was discussed internally:

On 3/21/2017 at 11:27 AM, sal_vager said:

Unfortunately this is a feature, I don't like it either but that's how it is.

I'll ask to get it revoked (again).

Anyhow, thanks again for looking into this!

[Superfluous J]

38 minutes ago, Yakuzi said:

??? Neither are the fuel tanks...

I was a bit terse in my reply. I mean if you ignore the texture the tank is vertically symmetrical, while the cabin is not due to the hatch.

If I'm still wrong I will take it back. I could see maybe if the tank has more lift one way or the other, I don't know. but it's visually the same that's for sure.

[TriggerAu]

24 minutes ago, Yakuzi said:

Thanks @TriggerAu

I was referring to this, I'm obviously oblivious to what was discussed internally:

Anyhow, thanks again for looking into this!

yupp, thats why i mentioned it cause I have vis of extra info

I cant find any ref to the PJ comments so cant add on that one

[Superfluous J]

1 hour ago, Maxsimal said:

If you go to the deltaV app, you can set up various aspects of what you'll see with the dV readout & the expanded readout, including the situation.  Consult the KSPedia for more information.

I just checked KSPedia to make 100% sure, and yes, you are mistaken about what we want

I know that you can set it in the little dV tool. What I want is to not have to set it. I want to be able to tell the game to default to Vacuum dV, so I don't have to go into the tool every time and set it. To be clear, I almost never care what my atmosphere dV is, and when I do, I expect to have to go in to the setting. But by default, I want Vacuum readouts.

[klgraham1013]

1 hour ago, Yakuzi said:

I have resubmitted the issue to the bug tracker here: https://bugs.kerbalspaceprogram.com/issues/20423. Any up-votes or comments are immensely appreciated!

Upvoted.

[AVaughan]

1 hour ago, 5thHorseman said:

I just checked KSPedia to make 100% sure, and yes, you are mistaken about what we want

I know that you can set it in the little dV tool. What I want is to not have to set it. I want to be able to tell the game to default to Vacuum dV, so I don't have to go into the tool every time and set it. To be clear, I almost never care what my atmosphere dV is, and when I do, I expect to have to go in to the setting. But by default, I want Vacuum readouts.

Fully agree.  Provided you have sealevel engines on the first stage (something experienced players will do automatically), you almost never care about atmospheric dV numbers.  For most missions the only numbers you need are the vacuum dV numbers.

[Yakuzi]

5 hours ago, klgraham1013 said:

Upvoted.

Thanks heaps mate!

 

On 1/2/2019 at 6:21 PM, Yakuzi said:

I'm having some serious z-fighting issues with wings in 1.6.0 vs 1.5.1 though, anyone else experiencing this?

Did a bit more testing on the z-fighting issues I've been experiencing in 1.6.0, check out the gifs of 1.5.1 vs 1.6.0:

KSP 1.5.1

 

KSP 1.6.0

 

Both are completely stock installs*, identical settings, same craft file (loaded and launched from the SPH, accelerated to ~120m/s then stopped). As you can see there is some minor z-fighting on the ruddervators in KSP 1.5.1, however, in 1.6.0 all wing parts and most other parts are having epilepsy level z-fighting issues. The z-fighting problems seems to be fixed upon reloading the scene.

Can anyone confirm before I submit this to the bugtracker? The craft above can be downloaded here.

* Apart from some Mk2 config file changes in 1.5.1

Edited January 3, 2019 by Yakuzi

[klgraham1013]

I know I've seen the z fighting issues while watching EJ_SA.  I'm still primarily on 1.3.1, so haven't seen them myself. 

Edited January 3, 2019 by klgraham1013

[coredumpster]

8 hours ago, OHara said:

No, and I would have noticed that by now.   My only guess is that a mod has not gotten a needed update, or maybe the modder doesn't yet know the need. Similar things happened with HyperEdit a few versions ago.  Maybe ask over on whichever Tech Support subforum fits the best.

I have a few mods installed, but most are parts ( Near Future, Planetary Base, etc. ).  Shouldn't be impacting warp / orbit calculations, but I guess you never know.

Tested again with a stock 1.6, and I can reproduce it pretty regularly.  I launch from KSC to a direct munar injection, I don't circularize in LKO first, and it seems that triggers it to be significantly pronounced.  If I inject from a circular LKO then it's much less pronounced / non-existant. 

[Dafni]

51 minutes ago, klgraham1013 said:

I know I've seen the z fighting issues while watching EJ_SA.  I'm still primarily on 1.3.1, so haven't seen them myself. 

Same here, to the letter.

[sendoutheintern!]

This update has been really helpful, expecially the new Delta-V indicators, they have made my rocket building so much better than what it used to be!

[Vanamonde]

Some personal remarks have been trimmed from the thread. Please talk about the game rather than talking about each other. 

[HvP]

8 hours ago, AVaughan said:

...you almost never care about atmospheric dV numbers.  For most missions the only numbers you need are the vacuum dV numbers.

As long as vacuum is only the default for the VAB. I feel like atmospheric should stay the default for the Space Plane Hangar.

[Superfluous J]

11 minutes ago, HvP said:

As long as vacuum is only the default for the VAB. I feel like atmospheric should stay the default for the Space Plane Hangar.

I've like to note that I'm not asking for vacuum to be the default. I'm asking for the ability for me to make it the default for myself.

And you bring up a good point. You should be able to set the VAB and SPH defaults individually.

[klgraham1013]

38 minutes ago, 5thHorseman said:

I've like to note that I'm not asking for vacuum to be the default. I'm asking for the ability for me to make it the default for myself.

And you bring up a good point. You should be able to set the VAB and SPH defaults individually.

I agree and second these statements.

[Tyko]

7 hours ago, coredumpster said:

I have a few mods installed, but most are parts ( Near Future, Planetary Base, etc. ).  Shouldn't be impacting warp / orbit calculations, but I guess you never know.

Tested again with a stock 1.6, and I can reproduce it pretty regularly.  I launch from KSC to a direct munar injection, I don't circularize in LKO first, and it seems that triggers it to be significantly pronounced.  If I inject from a circular LKO then it's much less pronounced / non-existant. 

If you create it in stock you could submit the entire save with steps to repro. That'd be a fairly simple way to show what your seeing   

[AVaughan]

3 hours ago, HvP said:

As long as vacuum is only the default for the VAB. I feel like atmospheric should stay the default for the Space Plane Hangar.

Is atmospheric deltaV useful for planes?  I'll admit I don't build many planes, but I'm not seeing what useful info atmospheric dV would give you for a pure plane with airbreathing engines (as opposed to a space plane).   Once you start talking about rocket engines on spaceplanes, then I would still think that most of the time vacuum dV would be more relevant.    (If you want to look at both stats, then does it matter if the default is vacuum?).

 

EDIT: thinking about this some more, are you actually interested in sea level twr, rather than dV.  (I can see that being useful for judging whether you need more engines for takeoff/climb).

Edited January 4, 2019 by AVaughan

[Aegolius13]

1 hour ago, AVaughan said:

Is atmospheric deltaV useful for planes?  I'll admit I don't build many planes, but I'm not seeing what useful info atmospheric dV would give you for a pure plane with airbreathing engines (as opposed to a space plane).   Once you start talking about rocket engines on spaceplanes, then I would still think that most of the time vacuum dV would be more relevant.    (If you want to look at both stats, then does it matter if the default is vacuum?).

I agree with that - I've never really looked at delta-v for jet engines.  Total burn time is usually more useful.  So delta-v on a spaceplane only becomes useful once I switch to rocket engines, at which point vacuum numbers apply.  But it would be cool to have separate default settings available for each building. 

[OHara]

13 hours ago, Yakuzi said:

Can anyone confirm before I submit this to the bugtracker? The craft above can be downloaded here.

Raptor9 already reported this one, 19079 back in version 1.4.3.   At least, when I try your craft (flies very nicely, by the way) the z-fighting behaves exactly as described in the posted bug report.  Same in version 1.6.1 as in 1.5.1.  

For me, moving down the runway is not the key to starting the shimmer, but rather moving into the 2.2-km range of another craft so that it is loaded into the physics simulation. F5/F9 removes the z-fighting until you leave and re-enter the 2.2-km zone.  Maybe you have a targetting flag at far end the end of the runway?   I had to move my captured-asteroid decoration from the runway out to near the monolith because of this issue.

[Yakuzi]

6 hours ago, OHara said:

Raptor9 already reported this one, 19079 back in version 1.4.3.   At least, when I try your craft (flies very nicely, by the way) the z-fighting behaves exactly as described in the posted bug report.  Same in version 1.6.1 as in 1.5.1.  

For me, moving down the runway is not the key to starting the shimmer, but rather moving into the 2.2-km range of another craft so that it is loaded into the physics simulation. F5/F9 removes the z-fighting until you leave and re-enter the 2.2-km zone.  Maybe you have a targetting flag at far end the end of the runway?   I had to move my captured-asteroid decoration from the runway out to near the monolith because of this issue.

Just checked and there was indeed a flag at the end of the runway Issue upvoted on the bugtracker, thanks for letting me know OHara!

[TriggeredSnake]

If anyone preferred the old pre-redesign parts, then check out OldPartsRedux!

[GrandProtectorDark]

26 minutes ago, TriggeredSnake said:

If anyone preferred the old pre-redesign parts, then check out OldPartsRedux!

Isn't there already another mod that does exactly that?

[TriggeredSnake]

On 1/4/2019 at 2:35 PM, GrandProtectorDark said:

Isn't there already another mod that does exactly that?

Not that I know of. Kerbal Historical Institute used to reimpliment the really old parts from 0.13.3 and 0.14, but it's only updated to 1.4.3. My mod offers classic versions of every part that has been changed or modified in any way since 1.3 in addition to adding the 0.13.3 parts, and is updated to 1.6. I'm shamelessly advertising my mod for the people who don't like the part redesigns in 1.6, like the new Poodle for example.

[snip]

Edited January 6, 2019 by Snark
Redacted by moderator

[AngrybobH]

On 1/3/2019 at 8:29 AM, Yakuzi said:

Can anyone confirm before I submit this to the bugtracker?

I have noticed the exact same behavior with 1.6 stock and slightly modded(6 mods). I would like to note that I did not play 1.5 at all but, I had the same problems in 1.4 and to a lesser degree in 1.3. I have also noticed it is worse when near a runway (any of them) and will get significantly better at a certain altitude(changes but usually about 2000m). Intermittently, dropping below that altitude near a runway reintroduces the z fighting. The dessert runway seems to do this more often (nearly always). Reloading the scene seems to always fix the issue.