KSP Loading... A closer look into Update 1.6

[T1mo98]

27 minutes ago, basic.syntax said:

Making an orange texture for the 2.5m nose cone would be a welcome and fairly easy step.... but... to take it to an extreme, I would like to see new geometry as well. Check out this profile comparison:

 

Probably not exactly like the SS Tank, because the 2.5m tanks are too small. Maybe something like the Delta 4 Heavy sidebooster nosecones. What would be better is orange varients of the 3.75m tanks and a tankbutt for every tanksize

[passinglurker]

@StylusHead thanks again for responding its good to have a dev who'll provide insight into his work

15 hours ago, StylusHead said:

we needed to create nosecones that matched previously revamped parts in 1.5 release like the FL Tanks

Way I see it this is backwards I'm afraid. While its good that you can detail panels like porkjet at this point or rather since you started revamping the adapters onwards your style has turned into "panels for panels sake" there doesn't seem to be consideration paid to why there are panels especially those symmetrical rings of tiny panels your team seems fond of. For example why is say the C7 cone fabricated and assembled the way it is instead of just being formed as a single piece? it serves a purely structural function, and no plumbing runs through it so there is no need for an access hatch and its quite a small part so there would be no need to break it up into even smaller pieces for transport. 
 

15 hours ago, StylusHead said:

 keeping that same look & feel which was of course based on the porkjet style and if I'm not wrong those new options were quite well received

half the active forum users here you could probably feed an untextured cylinder and they'd receive it well you should see the stuff they used to praise and defend before you got here... as for the other half which are more discerning speaking from my perspective the FL tanks were the first to at least tick the mandatory checkboxes, and taking in allowances for creative liberties they could have gone either way, but things have gone a bit panel happy since then. I'd now say they've gone the wrong way if they're acceptance is being used as evidence to support this creative direction.
 

15 hours ago, StylusHead said:

these new nosecones can now be combined with their respective variants plus UVs and meshes were optimized where needed

My only concern here is the porkjet nosecones the rest you could have just scrapped and started fresh honestly I never cared for seeing old meshes recycled as you already know.
 

15 hours ago, StylusHead said:

and for the porkjet ones we didn't actually removed them just kept the paneling based on the parts that usually go attached to those nosecones but mostly kept their original spirit. Different from what others could think these are not thought as one only part but as part of a whole vessel.

My concern here is you've basically made it so they can only be paired with thier usual accomplices, and they'd look terrible anywhere else (the C7 cone for example now only goes with the NCS adapter as part of a complex spaceplane, and instead looks out of place when used as part of a cheap sounding rocket whereas before it could do both with reasonable versatility).

The advanced nose cone meanwhile I've basically just seen for rockets and rockets can mismatch nose and body styles with industrial impunity so I'm not sure what you were trying to pair it with. Still its not as bad off as the C7 is with the paneling gore but I hate how loud it looks now. I try and imagine a whole vessel incorporating these, and I think its just gonna look extra busy especially if you keep changing other porkjet parts to match these tastes. Wouldn't you agree that part of a good whole vessel design is giving player some options for subtler structural and fuel pieces so the can control what on a vessel grabs attention instead of making everything the same degree of attention grabbing?

Edited December 14, 2018 by passinglurker

[kivikallo]

I really dont like the new engines and the nose cones. We fo not need more textures or features. Just please fix the thousands of bugs this game has. Come on.

[releansol]

now i definitely have to wait for 1.6 to continue my career. who wants to shoot up old rusty parts? 

[DfA-DoM]

1 minute ago, releansol said:

now i definitely have to wait for 1.6 to continue my career. who wants to shoot up old rusty parts? 

Absolutely,

Let's install @DMagic's Basic DeltaV to accomodate to the UI enhancement and keep setting up new crafts in a sandbox.

[klgraham1013]

4 hours ago, passinglurker said:

there doesn't seem to be consideration paid to why there are panels

4 hours ago, passinglurker said:

you've basically made it so they can only be paired with thier usual accomplices

@StylusHead

My father was fond of the eternal questions.  What, why, how, and when?  What is the part used for?  In KSP, the answer is everything.  KSP is a building block game.  Every piece needs to be able to fit together and appear as a consistent whole.  Is that a rocket fuel tank?  A grain silo?  A tanker truck?  That's for the player to decide.  The parts must be flexible enough for this.  Why is the part this way?  How is the part this way?  Are those bolts actually for anything?  What about those panels?  "When" might seem less relevant here.  I'm ready for the little green men defense, but were all human.  Humans place human traits on things.  So, we must consider what general Kerbal time frame these parts were made.  Is this the dawn of the space age, or sometime further on?  What technologies are the Kerbal's working with here?  Once you establish this, all parts need to reflect it.  Refer back to KSP being a game of building blocks.  Parts need to work together and not be anachronistic with each other.

Okay.  I'm done rambling now.

 

[Ozymandias_the_Goat]

2 hours ago, klgraham1013 said:

Okay.  I'm done rambling now.

It was very nice while it lasted 

As for the rant itself, I could not agree more. I feel like the time period question is important, and I do feel like the game is a bit barebones in giving you the recourses needed to spread kerbal civilization across the solar system after you pollute it with flags. This is why I feel that I can’t really play that game without habitat system mods, but I suppose that this is merely a matter of preference. And even with the stock game, and select stockalike mods, you can still emulate the progress that human space flight is likely to make in the next 50 years. Ultimately, KSP gives you the means to emulate any time period in the realm of modern space flight.

As for the interactions between parts, I agree that they all fit together nicely (due in part to the fact that I make all my parts white). Not much more needs to be said of that.

[Gapone]

The new orange Rockomax color isn't the same as the old Jumbo-64. And orange J64 needs square fuel line caps, not curved.

[V7 Aerospace]

To be honest, I think the solution to most problems here is just to have more variant textures available for most parts.

The 1.25m fuel tanks are probably the best so far. 4 texture choices with each of them not being too far a step in any direction, I'd like to think that all other structural parts and fuel tanks will follow in that regard.

[Dirt The Space Dirt Fox]

Very happy with most of these changes, but I really do hope eventually we get to see orange foam variants of the biggest tanks as well, especially the 5M making history ones, because that's what we really need to pull off genuine looking shuttles in stock KSP or other shuttle hardware derived looking builds. I just really, really love orange foam tanks period, I just want to see more of such ^w^. Oh and of course nose cone variants to match accordingly as well.

[BudgetHedgehog]

On 12/12/2018 at 7:00 PM, SQUAD said:

metallic parts, such as the Probodobodyne Stayputnik will now also reflect the surrounding environment on their surface.

 

You mentioned it applies to visors - does it also apply to cockpit windows and solar panels (or any glass surface)? One of my favourite gifs of KSP is this one, it'd be glorious to have it stock:

Spoiler

 

 

EDIT: Hoping post edits ping correctly - @nestor

Edited December 14, 2018 by ObsessedWithKSP

[Wkf Kerman]

Really nice-looking revamps! Also will miss the old appearances. 

Very excited with the built-in delta-v tool.

I have an idea/suggestion about the delta-v feature. Is that possible to add a function of recording the amount of delta-v spent as game/user's data? For example, recording the delta-v used to achieve a low-Kerbin orbit (80km) for overall launches or in recent 10 launches. It also can be delta-v amount used for landing or transferring to a celestial body.

With this feature, players may be able to explore and create their own delta-v map easily.

[JERONIMO]

oh well, i guess this update no new parts again. R.I.P KIS, i needed you only for the helmet stuff

[FleshJeb]

5 hours ago, Wkf Kerman said:

With this feature, players may be able to explore and create their own delta-v map easily.

You don't want to do it the fun way?

https://wiki.kerbalspaceprogram.com/wiki/Kerbol_System/Table

https://en.wikipedia.org/wiki/Hohmann_transfer_orbit#Calculation

https://en.wikipedia.org/wiki/Orbital_inclination_change

[OHara]

On 12/13/2018 at 9:30 AM, DMagic said:

automatically generated drag cubes which are well known to fail on hollow parts.

Just confirming that this general concept matches the engine-drag symptoms mentioned above in detail.  

The Mastodon and other DLC engines have surface areas in PartDatabase.cfg that numerically match what the models look like with shrouds, and discounting the hollow spaces.  So the medium variant without a shroud looks like it fits 1.875-m tanks, but the drag model sees its 2.5-m shroud being attached.

The affected parts in Making-History-DLC all have configurations with " author = @RoverDude ".  Tubes and engine plates and KV-pods are in the bug tracker, but not the engines yet.

The base-game engines have two cases for drag, "Fairing" and "Clean", which seem to be auto-generated from the models.  In those parts, in the case with fairing attached, the auto-generated areas in the staking direction always matched the tanks of the same nominal size (and thus faired the stack for drag purposes) because all their shrouds were tight-fitting and left no hollows all the way through.

Edited December 16, 2018 by OHara
Drag surprises from M.H. engines now at #20683 on the bug-tracker. Engine plates don't have the hollow-part problem; they have complaints about drag on their *contents* which is conceptually different.

[AVeryNiceSpacePenguin]

I feel the nose cones did not require the retexturing. Besides, I would rather have a good running ugly game, than a bad running beautiful game.

[Poodmund]

5 hours ago, OHara said:

Just confirming that this general concept matches the engine-drag symptoms mentioned above in detail.  

The Mastodon and other DLC engines have surface areas in PartDatabase.cfg that numerically match what the models look like with shrouds, and discounting the hollow spaces.  So the medium variant without a shroud looks like it fits 1.875-m tanks, but the drag model sees its 2.5-m shroud being attached.

The affected parts in Making-History-DLC all have configurations with " author = @RoverDude ".  Tubes and engine-plates and KV-pods are in the bug tracker, but not the engines yet.

The base-game engines have two cases for drag, "Fairing" and "Clean", which seem to be auto-generated from the models.  In those parts, in the case with fairing attached, the auto-generated areas in the staking direction always matched the tanks of the same nominal size (and thus faired the stack for drag purposes) because all their shrouds were tight-fitting and left no hollows all the way through.

As you seem to have a fair bit of understanding regarding this issue, would you care to open a bug report on the affected engines? I think you did a similar thing for the structural tubes a while back if I remember correctly.

[Lord Aurelius]

Except for that awful new texture for the small nosecone, this looks like it will be a great update. Very excited to see we're finally getting a stock dV readout.

Hoping we'll see stock life support in a not too distant update as well.

[SudAntares]

55 minutes ago, Lord Aurelius said:

Hoping we'll see stock life support in a not too distant update as well.

Which you could switch on/off, for those, who don't want to play with it.

[Lord Aurelius]

19 minutes ago, SudAntares said:

Which you could switch on/off, for those, who don't want to play with it.

Of course, same idea as the stock comm network feature.

[Raptor9]

5 hours ago, Lord Aurelius said:

Hoping we'll see stock life support in a not too distant update as well.

4 hours ago, SudAntares said:

Which you could switch on/off, for those, who don't want to play with it.

While I've never played with any of the life support mods myself, it would be interesting to see that sort of mechanic implemented.  However, I agree that it should have the option of being disabled.  Additionally, if that sort of mechanic is eventually implemented into game, I believe it should go the way of the ISRU/Mining mechanic; in that it takes only a few simple steps to implement or manage properly.

IIRC a "resource mining" feature was originally supposed to be implemented in v0.19 when KSP was well in the pre-alpha stages, but didn't get introduced until 1.0.  The reasoning being that the original plans for it had so many steps (probably emulating real-life processes) that the probability of the average player failing to properly set up the resource flow was too great.  I mean, when players forget ladders or parachutes....   At least with the ISRU process it's just Scan>Drill>Ore tank>Converter while managing power and heat.  Heck, even scanning is optional if you wanna roll the dice.  A life support mechanic of similar simplicity would be welcome I think.

[RJVB09]

I love the delta-V calculator

I've Always dreamed of a sort of kerbal engineer in the stock game

 

[Lord Aurelius]

11 hours ago, Raptor9 said:

While I've never played with any of the life support mods myself, it would be interesting to see that sort of mechanic implemented.  However, I agree that it should have the option of being disabled.  Additionally, if that sort of mechanic is eventually implemented into game, I believe it should go the way of the ISRU/Mining mechanic; in that it takes only a few simple steps to implement or manage properly.

IIRC a "resource mining" feature was originally supposed to be implemented in v0.19 when KSP was well in the pre-alpha stages, but didn't get introduced until 1.0.  The reasoning being that the original plans for it had so many steps (probably emulating real-life processes) that the probability of the average player failing to properly set up the resource flow was too great.  I mean, when players forget ladders or parachutes....   At least with the ISRU process it's just Scan>Drill>Ore tank>Converter while managing power and heat.  Heck, even scanning is optional if you wanna roll the dice.  A life support mechanic of similar simplicity would be welcome I think.

I would expect that any stock life support would be very similar to the USI Life Support mod (it also doesn't hurt that it was developed by Roverdude, who now happens to be a dev). Instead of tracking food/water/oxygen separately like what TAC Life Support does, I would expect the stock implementation to use just a single resource (plus maybe electricity) to keep things simple. Capsules would have some resources by default sufficient for a few days.

[klgraham1013]

1 hour ago, Lord Aurelius said:

I would expect that any stock life support would be very similar to the USI Life Support mod (it also doesn't hurt that it was developed by Roverdude, who now happens to be a dev). Instead of tracking food/water/oxygen separately like what TAC Life Support does, I would expect the stock implementation to use just a single resource (plus maybe electricity) to keep things simple. Capsules would have some resources by default sufficient for a few days.

Yep, yep, and yes.

[roboslacker]

I am fully against stock life support.