KSP Weekly: The Falcon

[Raptor9]

Awesome @SQUAD!  Some nice quality of life improvements with the latest previews. 

I do have a suggestion if not already thought of: include an option in the settings menu for what the default burn time should default to, if someone wants other than the even split across the maneuver node.  I personally don't care, but I think after all the back and forth we saw with the default throttle setting in the past, it would probably be better to get ahead of this potential debate and add the option if feasible.

As it goes with KSP, when faced with the question of "Why would anyone do this?" the answer is always "At least one person will."  

[LegendaryAce]

2 hours ago, GearsNSuch said:

P. S. - To console players: Squad / T2 has not abandoned you. They're probably just getting some contracts ironed out with Blitworks (we all have those "test launch clamp in solar orbit" ones) and will release an update after 1.5. In the meantime, all of this news is console news; it's just coming after-soon rather than coming soon. I'm not the betting type, but I'd put money on it that the majority of the devnotes after 1.5 are going to be focused on you all.

Unfortunately, I'm very apprehensive to believe this. We haven't gotten a single sentence worth of mention in over four months, which clearly shows how much we matter to Squad. 

If this was the case, there's nothing preventing them from saying "Hey console players, we know you've been neglected, but we've been trying to get a contract for another update to bring you guys up to PC specs. We hope to have more news in the future." But no, they've just been ignoring us. Seems they've learned some new tricks from their greedy parent company now. 

Unfortunately, I've got so many reasons to not trust Squad and especially Take Two. I've played enough of their games to know that T2 is only ever in it for the money (looking at you GTA). AFAIAC, I'm done with KSP, Squad, and T2. Say what you want, but my experience with all three has been nothing short of abysmal. And that's saying something because I give every game I get a chance, and I really loved KSP. 

Oh well. Maybe some other outsourced company will give us an update in 2021 or so...

[JPLRepo]

1 hour ago, Raptor9 said:

Awesome @SQUAD!  Some nice quality of life improvements with the latest previews. 

I do have a suggestion if not already thought of: include an option in the settings menu for what the default burn time should default to, if someone wants other than the even split across the maneuver node.  I personally don't care, but I think after all the back and forth we saw with the default throttle setting in the past, it would probably be better to get ahead of this potential debate and add the option if feasible.

As it goes with KSP, when faced with the question of "Why would anyone do this?" the answer is always "At least one person will."  

It is in settings.cfg - or you can change it via the UI with advanced burn indicator on and it will persist as the default value.

[MR L A]

3 hours ago, klgraham1013 said:

...or just have a little more faith in the people buying a game about launching rockets into space using semi realistic physics.

iffy on that one. I, and many others I'm sure, had no idea what dV, TWR or ISP was when I started playing KSP and had no idea that those were things I would need to learn about in order to play.

The reason I bought it was because I'd seen YouTubers having a load of fun on it, the demo was also fun AND because it brought back my inner child - the one with the youthful fascination of space, was lucky enough to travel from the UK to Kennedy SC as part of my 6th birthday and at around the same age decided to send a space station design to NASA (via post back then) to which they responded very nicely

Also, it appealed to the same part of me that loved Lego and AoE.

Sure, there will be a lot of players that already had a great deal of knowledge around rocket science (rather than just a passing interest), but I'm positive there's a huge number that didn't.

[klgraham1013]

30 minutes ago, MR L A said:

I, and many others I'm sure, had no idea what dV, TWR or ISP was when I started playing KSP and had no idea that those were things I would need to learn about in order to play.

Perhaps the game should teach you.  The dV formula is still no where in the game.  Not even the KSPedia.

I didn't know any of these things either, but I had a desire to learn.  It's unfortunate I needed to go to YouTube and Google to learn them.

Edited September 29, 2018 by klgraham1013

[bonyetty]

dV in the VAB and SPH is coming I feel as launching, liftoff, creating manouvor node and reverting to find the dV of your craft will be rather tedious. Continuing to love your work SQUAD. 

[Noname115]

19 hours ago, nestor said:

Expect an update on the suits in the following weeks.

 I eagerly await the news!

[swjr-swis]

17 hours ago, nestor said:

The attachment nodes are not involved in the drag properties, so no.

I appreciate the quick response, but your answer leaves things a bit ambiguous. Do you mean to say:

1. you've specifically taken care that attachment nodes are not going to cause extra drag for the Rovermate part? Or,
2. that attachment nodes NEVER cause drag anyway (in other words, that my assertion is wrong), so it is not an issue for the Rovermate either?

If you mean to state nr. 2, I hate to be the one to have to point out you are wrong: open attachment nodes do in fact cause additional drag, as shown quite easily in the game. Proof:

Note that I went to the trouble of showing this drag issue with the one stock part that has attachment nodes pointing 'out of the stack' (iow other than the usual top/bottom). I also placed them two by two in symmetry to preempt the argument that the difference in drag numbers may be caused by the always slightly off-course path - yes that does account for a slight difference too (in the decimals), but there is an order of magnitude of difference with the drag caused by the open nodes, as clearly shown.

In light of this possible ambiguity: are you sure we can expect no additional drag to play a role with the new Rovermate due to the added nodes?

[Delay]

Are you sure that the additional drag is caused by the attachment nodes? Why not the general aerodynamic properties of the object, which in this are are pretty poor anyways?

[swjr-swis]

52 minutes ago, Delay said:

Are you sure that the additional drag is caused by the attachment nodes? Why not the general aerodynamic properties of the object, which in this are are pretty poor anyways?

Hence the 3x2 arrangement, with as only relevant difference the nr of nodes 'plugged'. The difference in drag nrs between the 3 situations, not the drag of any of those individually, is the data we learn from here.

[OHara]

1 hour ago, swjr-swis said:

open attachment nodes do in fact cause additional drag

You might like to think of it the other way around: closed attachment nodes remove drag.  

The exposed surfaces of parts cause drag. Attachment nodes, when used to attach another part, remove some or all of that surface from drag computations.  The attached covering part will add its own drag, but that is often less.

A good guess is that Squad will implement the Rovemate configuration like the the one below:

 

[swjr-swis]

1 minute ago, OHara said:

You might like to think of it the other way around: closed attachment nodes remove drag.

Agreed, that may be the more accurate way of wording it.

[Tyko]

8 hours ago, MR L A said:

For everyone saying a proper dV read out might be too much for new players... advanced tweakables anyone?

seems like a simple toggle on/off would fix this problem almost immediately. 

Also yeah, I think most players realise a dV readout might occasionally be a bit broken depending on the craft, so IMO squad should just implement one anyway and not worry about tiny hiccups. 

Actually, nobody on this thread has said it might be too much for new players. You're the first.

Second, they shouldn't implement something unless it's pretty darned accurate. The first thing I'm going to do is run it alongside KER and see how they compare. I sure hope that Squad is planning to be at least as accurate and flexible about ship designs as KER is.

[Redneck]

38 minutes ago, Tyko said:

I sure hope that Squad is planning to be at least as accurate and flexible about ship designs as KER is.

yeah thats a good point. So yeah squad i would take what Tyko said into consideration it is a very valid point. Precision will need to be at least equal to the mod

Edited September 29, 2018 by Redneck

[Deddly]

30 minutes ago, Redneck said:

yeah thats a good point. So yeah squad i would take what Tyko said into consideration it is a very valid point. Precision will need to be at least equal to the mod

I dunno... I'd be content with something in stock rather than nothing, even if it needs tweaks in the future. If some people are not content with the accuracy, there would be a case for them to continue using mods. But I think players who prefer to play stock (there are plenty of them) would really benefit from a DeltaV/TWR display, even if it isn't perfect. 

[Redneck]

2 minutes ago, Deddly said:

I dunno... I'd be content with something in stock rather than nothing, even if it needs tweaks in the future. If some people are not content with the accuracy, there would be a case for them to continue using mods. But I think players who prefer to play stock (there are plenty of them) would really benefit from a DeltaV/TWR display, even if it isn't perfect. 

I see your point also. The benefit would be there regardless. Agreed

[klgraham1013]

They'll already be calculating dv with the new burn time indicator.  So, any issues it may encounter will already be in the game to an extent.  

[Tyko]

5 hours ago, Redneck said:

5 hours ago, Deddly said:

I dunno... I'd be content with something in stock rather than nothing, even if it needs tweaks in the future. If some people are not content with the accuracy, there would be a case for them to continue using mods. But I think players who prefer to play stock (there are plenty of them) would really benefit from a DeltaV/TWR display, even if it isn't perfect. 

I see your point also. The benefit would be there regardless. Agreed

Maybe "perfect" isn't the right term here. I'm not so concerned about the calculation being off be a few points. I'm more concerned about figuring out interesting staging, fuel flow settings, decouplers, etc.

[Terwin]

12 hours ago, bonyetty said:

dV in the VAB and SPH is coming I feel as launching, liftoff, creating manouvor node and reverting to find the dV of your craft will be rather tedious. Continuing to love your work SQUAD. 

I strongly suspect that the improved burn time indicator was done the way it was because side-steps the biggest problem with a dV indicator in the VAB/SPH: which environment do you want the calculation for?  (it also provides a highly intuitive indicator about how much of your remaining fuel you will need to use, as anyone who is watching it will quickly notice that they must stage when they get to a line)

If you have a burn-node for a specific vehicle in a specific environment, then calculating the dV is much more straight-forward then trying to calculate dV off the launch-pad/air-strip for a vehicle that has an engine that has awful atmospheric performance such as a terrier or poodle.

Any 'per environment' control that does not take up far too much screen-space will be missed by large numbers of users, and no calculator will provide 100% accurate dV information for a given vehicle when it comes to getting to orbit, because so much of that will depend on the launch profile and which altitude you are at when you stage.

I strongly suspect this is more of a 'we will give you what we can, but we are not going to add information that will primarily serve to confuse new players' than a change in attitude about providing dV in the assembly buildings.

[JPLRepo]

8 hours ago, Tyko said:

Second, they shouldn't implement something unless it's pretty darned accurate. The first thing I'm going to do is run it alongside KER and see how they compare. I sure hope that Squad is planning to be at least as accurate and flexible about ship designs as KER is.

QA have been rigorously testing the stock DV calculations used in the Burn Indicator against mods that calculate DV.

[Redneck]

Just now, JPLRepo said:

QA have been rigorously testing the stock DV calculations used in the Burn Indicator against mods that calculate DV.

Good deal thanks!

[Opus_723]

The parts are looking great and I'm very excited about the navball!

I have my fingers crossed that this renewed attention to the game's  art may presage a planets art pass in 1.6 or so. 

[Enceos]

10 hours ago, swjr-swis said:

Hence the 3x2 arrangement, with as only relevant difference the nr of nodes 'plugged'. The difference in drag nrs between the 3 situations, not the drag of any of those individually, is the data we learn from here.

I think deleting or commenting out the attachment nodes in .cfg and comparing the results with the behavior of the default variant should produce more tangible results and answer the question.

Edited September 30, 2018 by Enceos

[Tyko]

26 minutes ago, JPLRepo said:

QA have been rigorously testing the stock DV calculations used in the Burn Indicator against mods that calculate DV.

Thanks @JPLRepo     

[Poodmund]

4 hours ago, JPLRepo said:

QA have been rigorously testing the stock DV calculations used in the Burn Indicator against mods that calculate DV.

For usage extensibility, is it able to also account for non-standard fuel sources and how does it account for monopropellant? Sometimes the satellites/probes that I have built rely solely on RCS thrusters as their propulsion, I know that KER recently updated to show the RCS dV quota; will there be handling for this behaviour?