Some Improvements on the Way

[NH4Cl Enthusiast]

1 hour ago, Robin Patenall said:

In KSP 1 where manoeuvres were modelled as a single impulse, it sort of made sense to allow them to have any deltaV the player wanted, but with the KSP2 model where the manoeuvre is correctly modelled over time there's going to be issues if you exceed your real deltaV. With the new planning model the predicted acceleration of the vessel needs to change over the manoeuvre as the mass of the vessel decreases / the TWR increases and if you can exceed your vessel's deltaV then you'd either:

• have to special case what happens when you run out of fuel (i.e. how much does the acceleration change over time when you're burning non-existent propellant)
• run into the point when you have so much negative mass of propellant that your vessel has zero mass and infinite acceleration

Neither of these cases make for good manoeuvre predictions.

But I do understand that some sort of planning mode where you can model future missions to determine the amount of dV needed before designing the vessel would be useful.

Planning for the required dV for a given maneuver has nothing to do with your burn time prediction though. Many players in KSP1 had some kind of a vessel or satellite just to plan maneuvers with. I don't understand why these are built to be so heavily connected in the first place but it does explain a few things about the issues they have with the current planner. 

[The Aziz]

28 minutes ago, cocoscacao said:

 

Sneakpeek it soon please.

Leeky leeks from people digging through code few weeks ago

[Flush Foot]

1 hour ago, Alpha_star said:

seeing my dream come alive at last

I will touch the sky!
And they're not gonna hold me down no more
No, they're not gonna change my mind

[Scarecrow71]

9 hours ago, Alrecenk said:

I've been waiting to play the For Science update until parachutes are fixed. Clouds and colonies stuff is cool or whatever, but none of that matters if I can't rely on the parts of my ship to function, or the navigation UI to be there, or the camera to stay attached to my craft. I'm happy to see an update, but I think it's worth remembering that most players aren't here. The frequency of these posts doesn't matter to them. They only play the game. Often very briefly in the case of KSP2.

These are the kinds of things I was talking about when I mentioned in a previous post in this thread about the gameplay loop itself being infinitely more valuable to get fixed than to focus on clouds and graphics.  There's no point in things looking pretty if the core systems aren't functioning enough to keep people playing.

[mindseyemodels]

15 minutes ago, Scarecrow71 said:

These are the kinds of things I was talking about when I mentioned in a previous post in this thread about the gameplay loop itself being infinitely more valuable to get fixed than to focus on clouds and graphics.  There's no point in things looking pretty if the core systems aren't functioning enough to keep people playing.

Clouds is just blackrack working his magic... the rest of the team is working on colonies and bugfixes as well as visual improvements and heat management

@Nerdy_Mike since you guys are doing that awesome work on exhaust plumes, are we gonna get more reentry improvements this next couple updates? Please let there be sparks at least. I imagine the VFX team is working to blend the current style with what we saw in the SpaceX and artemis 1 reentry videos

[kdaviper]

2 hours ago, NH4Cl Enthusiast said:

Planning for the required dV for a given maneuver has nothing to do with your burn time prediction though. Many players in KSP1 had some kind of a vessel or satellite just to plan maneuvers with. I don't understand why these are built to be so heavily connected in the first place but it does explain a few things about the issues they have with the current planner. 

Here's an experiment: in ksp2, plan a 1000 dv maneuver with a rocket with a 1.0 twr. Now plan the same expenditure with a .01 twr.

Notice any difference?

[NH4Cl Enthusiast]

1 hour ago, kdaviper said:

Here's an experiment: in ksp2, plan a 1000 dv maneuver with a rocket with a 1.0 twr. Now plan the same expenditure with a .01 twr.

Notice any difference?

Sorry I misunderstood you initially so made an edit. I don't understand your point though? 

Edited April 26 by NH4Cl Enthusiast

[Flush Foot]

3 hours ago, NH4Cl Enthusiast said:

Planning for the required dV for a given maneuver has nothing to do with your burn time prediction though. <snip>
I don't understand why these are built to be so heavily connected in the first place but it does explain a few things about the issues they have with the current planner. 

Given that the devs want acceleration-under-time-warp to be possible (still buggy at times) especially for hyper-efficient engines doing week-long interstellar burns, the game does need to be able to take into account the duration of the burn and the (likely) changing TWR throughout said burn.

[Kerbal01]

Clouds from a KSP 1 mod and several paragraphs that say a whole lot of nothing. Great update!

[kdaviper]

1 hour ago, NH4Cl Enthusiast said:

Sorry I misunderstood you initially so made an edit. I don't understand your point though? 

What use is planning a maneuver when the outcome can be vastly different than your plan?

[RileyHef]

9 hours ago, Scarecrow71 said:

These are the kinds of things I was talking about when I mentioned in a previous post in this thread about the gameplay loop itself being infinitely more valuable to get fixed than to focus on clouds and graphics.  There's no point in things looking pretty if the core systems aren't functioning enough to keep people playing.

To quote Nate in the original post, "Most of our team continues to be pointed squarely at the Colonies update. We’re making a lot of progress this month on colony founding, the colony assembly experience, and colony gameplay mechanics."

If it isn't already clear, priority 1 is reaching the next major milestone. Given that we have 0.2.2 and 0.2.3 on the way, I think it's also safe to say that the second priority is gameplay/performance improvements and bug fixes. Yeah, it is a slow process, but I wouldn't want it prioritized any other way.

That said, I am perfectly fine with other members of the team working on smaller, lower priority tasks in the meantime. Even if those smaller projects have no immediate impact on the gameplay loop/experience, they are important for the ultimate goal of reaching 1.0.  As for specifics of clouds/graphics, I'm sure the team has more incentive to work on more optimized graphics and performance with the eventual goal of a console release (which provides them more revenue), so it makes sense for some resources to be allocated there. But an "all hands on deck" mentality in any business can lead to inefficiencies and/or missed opportunities. So yes, let Blackrock and the VFX team work on non-critical work that still improves the game if they have no immediate contributions to be made to the top 2 priorities right now. The critical gameplay shortcomings will likely be fixed or improved, with time, but it is obvious the kind of pace this team can move at and the complexity they feel these issues have.

I doubt we will see any major gameplay fixes until at least 0.3. Speculating here, but I think they prefer to hold off on major gameplay upgrades/improvements until milestone updates to beef up the marketing of the game. Do I agree with it? No, but I think that is why heating came out with 0.2 despite not even being ready/fully implemented. Same goes for wobbly rockets finally getting fixed in 0.2. That's my not so tinfoil hat theory, at least.

 

[Urus28]

21 hours ago, Flush Foot said:

PQS (and planetary surface graphics more broadly) were covered in a prior Dev Update / Diary, if you want to take a look:

 

Thank you for the link !

Unfortunately, I don't have enough background knowledge to really understand it (I tried). But ok, it deals with planet surface rendering, I can live with that

[NH4Cl Enthusiast]

2 hours ago, Flush Foot said:

Given that the devs want acceleration-under-time-warp to be possible (still buggy at times) especially for hyper-efficient engines doing week-long interstellar burns, the game does need to be able to take into account the duration of the burn and the (likely) changing TWR throughout said burn.

That's a fair point for extremely long burns but it kinda ties into my point too.

Whatever the dV requirement is to change from one orbit to another is not intrinsically tied to the properties of the craft. You can calculate them just fine without any TWR, so in that sense the orbital transitions are well defined and that's how we have the delta-v maps. How a particular craft can achieve that transition is another question all together and it can have by necessity a different dV requirement, naturally because no real craft can perform an instant burn. So what we have in the dV requirements as far as orbits are concerned are a different thing from what the craft needs to do to reach the target orbit.

But here's the thing. The maneuver node planner is designed for impulsive maneuvers. It sets the maneuver at a fixed heading, one burn and around a fixed point. So it's by design a maneuver planner for orbits only, not for how you should fly the craft. It's by definition incapable of taking the TWR precisely into account. Otherwise it would have to be able to direct for multiple burns and changing the heading mid-burn.

As a simple example imagine you have a ion engine powered craft at 70km circular LKO with TWR of 0.01 and you want to plan for a Mun intercept. You can't do that with one burn and the planner can never give you that maneuver without multiple burns.  So trying to somehow account for that will always fail one way or another if the burn is long enough.

[Flush Foot]

2 minutes ago, NH4Cl Enthusiast said:

It sets the maneuver at a fixed heading, one burn and around a fixed point

Now that is something I wish could be adjusted / selected in the maneuver planner... (as long as time-warp is not engaged, mind you)

"I want to burn prograde for the next 30 minutes" vs "I want to burn for the next 30 minutes pointing in the same direction throughout the burn, even if that is suddenly a retrograde burn"

[The Aziz]

I'd just like to say that even if dragging the node beyond current dv should be possible, the game should clearly and explicitly inform that THIS MANEUVER EXCEEDS YOUR VESSEL'S DELTA V BUDGET AND PLANNED TRAJECTORY MAY NOT BE ACCURATE. 

[MechBFP]

32 minutes ago, The Aziz said:

I'd just like to say that even if dragging the node beyond current dv should be possible, the game should clearly and explicitly inform that THIS MANEUVER EXCEEDS YOUR VESSEL'S DELTA V BUDGET AND PLANNED TRAJECTORY MAY NOT BE ACCURATE. 

Can't they just add fake dry+wet mass, as if the vessel has additional fuel tanks? I can't see how that would make it inaccurate.

[NexusHelium]

Hey. Just so you guys know for anyone who may have not. They do not have plans to reimplement the current maneuver system once they remove and improve it.

Just wanted to let anyone who hadn’t heard know  

[MechBFP]

1 hour ago, NexusHelium said:

Hey. Just so you guys know for anyone who may have not. They do not have plans to reimplement the current maneuver system once they remove and improve it.

Just wanted to let anyone who hadn’t heard know  

So they plan to remove it, improve it, then not implement it?

wut?

[NexusHelium]

7 minutes ago, MechBFP said:

they plan to remove it, improve it, then not implement it?

wut?

As in. They’re not going to make it so that you can’t plan past Dv again once they fix the calculations. A lot of people were worried about that.

[Scarecrow71]

Would be nice if they would at some point remember to post those kind of responses here in the forum.

Just saying.

[Monotoko]

38 minutes ago, NexusHelium said:

As in. They’re not going to make it so that you can’t plan past Dv again once they fix the calculations. A lot of people were worried about that.

Fantastic news! My craft has been causing all kinds of issues with Dv calculations...

I want to ask why saving/reloading screws my dV calculations as well, is this something you guys have seen internally? I have a craft that causes it 100% of the time so if not I can send that to you guys to test with as well

Edited April 27 by Monotoko

[Temporal Wolf]

On 4/25/2024 at 12:13 PM, EvelynThe Dragon said:

I have said it before. I am going to say it again, and I am sure this is nowhere near the last time I will say it.

Release more frequent, smaller, bug fixes. These gigantic updates are killing this game. There is no apparent progress for months. And then we get another giant bucket full of NEW problems with these. It's a terrible way to do development and expect your user base to stay around.

Honestly, at this point I'd just love them to stick to whatever promise they make.

6 weeks since the last "monthly" KERB, 3 months since the last "every 6-7 weeks" update.

These are self-inflicted wounds... figure out something you can actually do, and do it.

[NexusHelium]

12 hours ago, Scarecrow71 said:

 

Would be nice if they would at some point remember to post those kind of responses here in the forum.

Just saying.

 

To be fair though. They also didn’t put it in the dev tracker and I was just online when it happened to be said by Nate Simpson to Matt Lowne (I believe it’s also posted on his twitter) so a lot of people on discord probably don’t know either  

I do agree they should have put that out there a little more though.

[Kerbart]

12 hours ago, NexusHelium said:

As in. They’re not going to make it so that you can’t plan past Dv again once they fix the calculations. A lot of people were worried about that.

Ha! That won't happen in my lifetime anyway, so I wasn't too worried about that.

[Mutex]

6 hours ago, Temporal Wolf said:

Honestly, at this point I'd just love them to stick to whatever promise they make.

6 weeks since the last "monthly" KERB, 3 months since the last "every 6-7 weeks" update.

These are self-inflicted wounds... figure out something you can actually do, and do it.

Personally I'd be happy if it was just a regular, consistent monthly update. First Friday of the month (for example), we get all the development news, bug fixing progress, screenshots of upcoming stuff. I know some people would prefer more frequent than that, but I think if it was regular and predictable enough people would complain about communication less, because there'd be less uncertainty about when we're going to hear anything next. I think the uncertainty and unpredictability is making the situation worse.