Release KSP2 Release Notes - Hotfix v0.1.3.2

[MechBFP]

3 minutes ago, DunaManiac said:

Is it just unpredictability of the code, or other reasons?

Changing end user requirements, changing business requirements, employee turnover, bugs with the vendor software, vacation days, stat holidays, sick leave and other related shrinkage, human error of various kinds (forgetting to save, not documenting something, deleting the wrong things. etc.), technical issues with the users computer, life cycling of computer hardware requiring re-setup.

Just to name a few.

Edited July 13, 2023 by MechBFP

[asmi]

23 hours ago, DunaManiac said:

Interesting, out of curiosity, what are some of the reasons why its so difficult for even experienced teams to stay on time? Is it just unpredictability of the code, or other reasons?

Whenever you do something you've never done before, there is an inherent chance of encountering something unexpected, which will throw all your time estimates out the window. And the more "unusual" is your task, the higher is the chance of something going wrong. So by not announcing time IG is managing expectations, or, more specifically, preventing situations when they have to break their own promised timelines due to factors beyond their control. To give you a more easily understood analogy (and please remember that it is but analogy, so don't push it too far), why do you think courier companies like DHL, Fedex et. al. never tell you precise time of delivery? They generally only tell you a day of delivery, maybe a few hours-wide time window if you're lucky, but never exact time. The reason is that there are certain factors which can affect that time, and there is nothing a company can do about them. So it's the same priciple.

Another approach to this is a rolling release schedule, when a release happens every X weeks, hell or high water, but the scope of release changes based on what is actually completed as release code-freeze deadline hits. This usually workes better with larger teams so that even if some functionality is not going to be ready, there is always something to release because a chance that everyone in a team will get stuck at the same time is rather low, and get lower as number of people in that team increases.

23 hours ago, DunaManiac said:

Regardless though, for the playerbase who are laypeople and are unaware of the problems game devs deal with, Intercept has burned through all of its good will and really needs it back if they want to bring back their mostly disgruntled playerbase.

I suspect that this is mostly beyond IG's control, except maybe for overhyping the game before release, but this problem is very typical for EA games as players tend to have over-inflated expectations and become disappointed when reality hits them. As for the good will, IG is not a 100 dollars bill to be liked by everyone, so no matter what they do, somebody will be disappointed. That said, I have a suspicion that a majority of KSP players either bought KSP2, played a bit and shelved it until some better times, or delayed a purchase until that better time arrives, but don't feel an urge to go to forums and scream&moan about it until the pigs fly. I myself bought the game on a release day, played a bit, and shelved it. Every time an update hits, I fire it up to check it out, and leave it be. I want some sense of progression, so I don't think I will be playing a lot until science hits, but every now and then I still fire it up and do something I feel like doing at that exact time.

Edited July 14, 2023 by asmi

[Periple]

2 hours ago, DunaManiac said:

Interesting, out of curiosity, what are some of the reasons why its so difficult for even experienced teams to stay on time? Is it just unpredictability of the code, or other reasons?

An experienced team will likely be able to stay on schedule pretty well. However, a new team will need to do a lot of work to get there even though they will know what it takes -- even if the team members individually have a lot of experience. 

The reason is that making a game is complicated and you'll need a big number of people and things to work together smoothly to make it any kind of predictable. Every team and every company is different and while the basic industry best practices are fairly well known by now, everybody applies them a little bit differently. So people with different work experiences will need to figure out how to make these slightly divergent experiences work together well. 

A real deep dive into this would be a looong read so I'll just describe a few examples of the things you need to figure out to get it to work. It'll still be pretty long, but you asked!

A studio will have a bunch of designers whose job is to figure out how the game should look and play: they'll be cranking out concept art, wireframes, Miro boards, Confluence docs and what have you for the rest of the teams to make. Then you'll have various teams working on different aspects of the game. You'll have an art team (or several) who are responsible for designing and then modeling parts, environments, kerbals, spacesuits, and so on and so forth. You'll have an animation team that rigs and animates anything that needs to be animated. You'll have a tech art team that does things like clouds and atmospheres materials and VFX and so on. You'll have a programming team (or several) who do stuff like physics, gameplay systems, UI,  terrain/asset streaming, orbital mechanics, and so on. You'll have a QA team who's supposed to verify that everything works. And you'll have a production team that's trying to keep everything working in tandem so nobody's being blocked by anybody else. All of this runs on a bunch of infrastructure, which is maintained by yet more people. You've got your version control system, which is managed by system administrators. You've got your build systems, which run build scripts, which are made by build engineers (or programmers wearing build engineer hats, which is usually not optimal). You've got your platform pipelines where you push the builds for testing and eventually release. 

So, if you want to have a regular, predictable release schedule, you'll need to make sure that all of these teams work together in a coordinated way so that nobody blocks anyone else. For example you'll need to find a way to make sure that the art team always delivers assets in a game-ready state -- that they don't exceed budgets for vertex counts, texture resolutions, and a bunch of other things (and that's after you've figured out what the budgets should be, and you better pray that you got the budgets right because if you have to have a do-over late in the game there will be hell to pay). Same for tech art and each of the programming teams. That means you'll need to have established practices both within and between the teams to catch as many problems as you can as early as you can. Some of this can be automated, but somebody's going to need to implement the automation. The programming teams will need to figure out how they want to apply things like code reviews -- who reviews whose code, what are the coding standards, how many reviewers are required for which kinds of things, what tools are used for the reviews, and so on. They'll need to decide on how to use automated tests and what controls they're going to have on them, both for unit tests and integration tests. They and the producers will need to decide how exactly they're going to use issue trackers like Jira -- who gets to log issues and when, who gets to transition them through each phase in the lifecycle, what exactly the issues should contain and whether there should be formal criteria on how they should be written up, and if so, how strict these criteria ought to be. They're going to have to decide how and for what purposes they use branching -- one main develop branch won't be enough as they'll be working on the upcoming release in parallel with stuff further down the roadmap, and they'll want to be able to hotfix production as well. They'll need to figure out how to make sure fixes in hotfix branches make their way into the sync branches, and how eventually the various sync branches are synced with each other; who's responsible for that, how conflicts are resolved, and how it all gets verified. You'll need to figure out how to freeze and unfreeze things to stop teams from tripping over each other, and not just in code -- for example, if the art team makes changes to the models, that'll affect the animation team, which may affect gameplay programming. And finally, you'll only really know if it works -- not just technically, but also as a game -- when it's all put together. Some of this can be automated but a lot of it is subjective and will only come out in playtesting... which is another thing you'll need to organize, with everything that implies: how the feedback is submitted, how that's turned into a form the designers and all the over teams can work with it, who does that, and so on.  It will turn out that some of the time it won't work: maybe integration flushed out new bugs, or produced new bottlenecks, or the gameplay feature that sounded like tremendous fun on paper is actually a drag when you're experiencing it. So then you have to go right back and start over. 

You could have a bottleneck anywhere in this mess. Maybe your dev team is super efficient and is chugging through tickets faster than the QA team can verify them which means that your releases will be held up in QA and your release branch will diverge from your develop branch. That means you'll need to expand the QA team or change your QA processes or change your QA criteria, and that takes time. Maybe your physics programming team is struggling and that's holding up the gameplay programming team. Maybe the art team is churning out assets faster than the gameplay programming team can hook them up to gameplay or the animation team can animate them. A good production team can juggle this for a while, recognize the bottlenecks and eventually make adjustments to the teams so things start flowing more smoothly but it all takes time!

I could go on but you get the picture. There's just MASSES of stuff like that that needs to be figured out, and while there are known best practices for all of this, every developer who's worked in a bunch of different places -- even ones where this works pretty well -- will recognize that every place does it differently with a different set of trade-offs. If you do really comprehensive QA, it means that it'll take longer to push releases through, which means that you'll have more active sync branches, which means there will be more merging, which will slow down your velocity... but you'll have fewer bugs going out. In the opposite case you'll be able to push out more new features faster but things will be buggier. Spend more time on code reviews? You'll get better code, but the time your programmers spend on reviewing is time they're not programming. If you're able to freeze features early, the game will be easier to make but you and the fans might be disappointed when it's actually implemented; if you keep them open longer, you'll be able to refine them to be more fun, but there will be more churn which produces more bugs and more bottlenecks. Eventually you'll figure out the compromise that works for you, but it'll never be exactly the same in any two studios, or even any two projects in the same studio (because you'll be learning from every project and then applying what you've learned in future projects). 

So yeah, it's hard and it's complicated, and even if you start by hiring a dream team of experienced professionals, they'll still need to figure all this out, all coming from their unique experiences... and also it often turns out that experienced people can be pretty opinionated, and sometimes the opinions conflict, which can lead to interpersonal problems, which can really mess up your project.

In sum... yeah, IG's progress on KSP2 hasn't been as fast as I had hoped back in February, but it is clear that they're continuously improving, and that's the main thing. This stuff is hard and even if IG started out with a core of people who had worked together, that was just a leg-up: they still needed to figure all the rest of it out, and this assuming that Star Theory had mature processes and solid practices to build from. 

Making a game all by yourself is hard, and it only gets harder when you add more people. You'll be able to make bigger games but you won't be able to make them any faster or any better!

Edited July 13, 2023 by Periple

[mattihase]

1 hour ago, DunaManiac said:

Interesting, out of curiosity, what are some of the reasons why its so difficult for even experienced teams to stay on time? Is it just unpredictability of the code, or other reasons?

Planning inherently involves making assumptions, and those are often wrong unless you've done that exact thing before with all the finicky bits exactly the same.

[schlosrat]

17 hours ago, herbal space program said:

The nice thing in KSP1 is that if you set the node at the spot that would give you the most efficient trajectory change as an instantaneous impulse, aligning to that target marker  automatically points you along the  secant parallel to your optimal burn vector wherever you are in your orbit.   I am certain that there are even more efficient ways to calculate your optimal start time and attitude through the burn, but that was really pretty good, at least in short burns that involved small changes in heading. I don't really understand how to do that in the KSP2 representation yet, so it seems worse to me, but maybe once I figure it out it will be as good.

That is pretty much exactly what FP does in such cases. It calculates the required burn as an impulse, applies it at the Ap, Pe, AN, whatever you pick, then works out the time offset needed and applies a “correction “ so the vector direction of the burn stays the same with an earlier time of 1/2 the burn duration. It’s definitely not as simple and just moving the node earlier as the node uses prograde, radial, normal coordinates which will rotate in an inertial frame. Effectively it’s just giving you the secant, but it does this by grabbing the node’s burn vector and converting to an inertial frame, setting the node earlier, and then rotating the resulting vector to make it like back up.

[Strawberry]

Also the current ksp2 team is definitely pretty volatile and slower then normal currently. We know the team is split upon what theyre working on, a lot of people are going on vacations right now, and a lot of new people are being brought on on top of that, all of this slows down production a lot and makes it harder to predict when stuff will be done as theres a lot more variables (new people will help in the long term, but when you can get past the expensive onboarding phase is an unknown).

I feel like itd be pretty hard to predict timelines right now, but the plus side is in the next few months when people are back and theres more people then ever development should be a lot faster and more consistent.

Edited July 13, 2023 by Strawberry

[stilrare]

The SOI bug is finally gone, hopefully more hotfixes in the future

Edited July 13, 2023 by stilrare

[Alexoff]

4 hours ago, Periple said:

The reason is that making a game is complicated and you'll need a big number of people and things to work together smoothly to make it any kind of predictable.

But you can say that about anything. Thousands of years ago it was complicated to irrigate the fields of Egypt. It's hard to make cars, it's hard to teach students, it's hard to make cans of Coke, it's hard to make money, it's hard to manage a family, it's hard to moderate forums, it's hard to make games. Billions of people are doing difficult things, but we accumulate experience, share it with each other, learn, and for the most part we are successful in what we do. Perhaps now, instead of releasing large patches for hundreds of bugs once a month, we will see one hotfix once a week-two with one or two fixes. After all, it's easier.

[KUAR]

1 hour ago, schlosrat said:

That is pretty much exactly what FP does in such cases. It calculates the required burn as an impulse, applies it at the Ap, Pe, AN, whatever you pick, then works out the time offset needed and applies a “correction “ so the vector direction of the burn stays the same with an earlier time of 1/2 the burn duration. It’s definitely not as simple and just moving the node earlier as the node uses prograde, radial, normal coordinates which will rotate in an inertial frame. Effectively it’s just giving you the secant, but it does this by grabbing the node’s burn vector and converting to an inertial frame, setting the node earlier, and then rotating the resulting vector to make it like back up.

I have to ask...when you and Herbal are talking about the secant, of which angle are you talking and to what value are you ascribing it as a multiplier?

I do generally get trigonometry (studied crazy amounts of maths for a physics degree) and can apply it to circular motion here when I think about it. But you're clearly using it as shorthand here for a more complete expression.

[herbal space program]

1 hour ago, KUAR said:

I have to ask...when you and Herbal are talking about the secant, of which angle are you talking and to what value are you ascribing it as a multiplier?

I do generally get trigonometry (studied crazy amounts of maths for a physics degree) and can apply it to circular motion here when I think about it. But you're clearly using it as shorthand here for a more complete expression.

Not actually talking about the trigonometric function. In basic geometry, a secant is any line that intersects a circle or ellipse in two spots, dividing it into two separate areas. In this context, I was saying that if you have a prograde maneuver node placed in KSP1,  the vector defined by boosting on your target marker anyplace other than exactly at the node will be a secant of your orbit that is parallel to the  (tangent) vector that would be defined by boosting exactly at the node. It  actually works the same way for boosting in any direction in the prograde/radial plane, except that both vectors would be secants if the node is in any direction other than pure prograde or retrograde. Anyway, in the KSP1 system, that means that boosting on your target vector a short time before and after the node does a pretty good job of maintaining the optimal attitude to actually achieve the trajectory you want.  I'm not quite sure how that idea translates to the KSP2 system, since if you are boosting prograde at the spot you placed your node,  you won't be  boosting prograde anymore at the midpoint of your burn.

[Superfluous J]

10 hours ago, Alexoff said:

But you can say that about anything.

But you can't. I mean you CAN, but you'd be wrong. There is an inherent difference between the "difficulty" of doing something new *to you* and doing something actually new, that no one's ever done before.

10 hours ago, Alexoff said:

Thousands of years ago it was complicated to irrigate the fields of Egypt. It's hard to make cars, it's hard to teach students, it's hard to make cans of Coke, it's hard to make money, it's hard to manage a family, it's hard to moderate forums.

The very first people who tried to set up fields in Egypt probably didn't just have unexpected delays. They probably died. Cars are ridiculously easy compared to software. In fact, the only thing that my 8-year-old car has had to go in for was a fix for its software (and it's due another now). Students take 13+ years to teach and that often goes horribly awry. I'm sure it was difficult to DESIGN the FIRST can of whatever soda was first canned, but right now it's so simple you don't even need people there anymore. Yeah it's hard to make money, but that's a different scope. The rest I won't speak on as I've never done them.

10 hours ago, Alexoff said:

it's hard to make games

But there's a difference between doing Call of Duty Insert Several Words Here, or Madden Roster Update And More Polygons 2023, and creating a from-scratch system for your from-scratch game with ridiculously lofty planned features.

Someone mentioned FedEx not being able to pin down the time, but being able to pin down the day. That's how most games are. And movies, for that matter.

KSP2 is more like if someone slapped a FedEx patch on Lewis and Clark and asked them to make sure they get that package to the Pacific Northwest by 5am on Thursday.

Edited July 14, 2023 by Superfluous J

[RocketRockington]

14 hours ago, Superfluous J said:

KSP2 is more like if someone slapped a FedEx patch on Lewis and Clark and asked them to make sure they get that package to the Pacific Northwest by 5am on Thursday.

No, it's nothing like that.  It's like the unfamous people who did the same trip following Lewis and Clark, just for the profit, but with 10x more money to prepare for it, an exact map to the destination, and more experienced porters on the team, and who also told everyone they were almost to the Pacific Northwest, that they were JUST about there, but then it turned out they'd made a wrong turn at albuquerque so they were nowhere close.  And then they were ALMOST there again - but nope, this time they wandered into Florida, needed some more time.  Then again, almost there - nope, they're back where they started.  Finally, they show up, but they lost 95% of what they were bringing, and then said that was arriving shortly.  Now the cargo has also failed to arrive  after 5 more.months...but it's almost here...yeah right.

Stop exaggerating how KSP2 is this monumental effort of new work.  They literally had the code from KSP1.  And their estimates weren't just 'oh we had unforeseen issues' bad but 'Student writing his paper the day before it was due' bad where they have no idea because they haven't actually done anything.

Edited July 14, 2023 by RocketRockington

[Periple]

 

11 hours ago, Alexoff said:

 It's hard to make cars, it's hard to teach students, it's hard to make cans of Coke, it's hard to make money, it's hard to manage a family, it's hard to moderate forums, it's hard to make games. Billions of people are doing difficult things, but we accumulate experience, share it with each other, learn, and for the most part we are successful in what we do.

Some of these things are harder than others! How many years did it take for Tesla to scale to mass production? How many more until it was able to turn a profit? That's a lot harder than managing a family or moderating forums.

Making a game isn't anywhere near as hard as figuring out how to mass produce cars, but it's still complicated -- and the process of accumulating experience, sharing it, learning from it, and applying the lessons takes time. This is true even if you start by hiring a team of experienced people -- they will know their jobs, and they will have previous experience with collaboration, but they'll still need to figure out how to apply all that experience to a new context and new project, how to fill in the gaps in their collective experience, and how to learn to work together effectively.

[KUAR]

10 hours ago, herbal space program said:

Not actually talking about the trigonometric function. In basic geometry, a secant is any line that intersects a circle or ellipse in two spots, dividing it into two separate areas. In this context, I was saying that if you have a prograde maneuver node placed in KSP1,  the vector defined by boosting on your target marker anyplace other than exactly at the node will be a secant of your orbit that is parallel to the  (tangent) vector that would be defined by boosting exactly at the node. It  actually works the same way for boosting in any direction in the prograde/radial plane, except that both vectors would be secants if the node is in any direction other than pure prograde or retrograde. Anyway, in the KSP1 system, that means that boosting on your target vector a short time before and after the node does a pretty good job of maintaining the optimal attitude to actually achieve the trajectory you want.  I'm not quite sure how that idea translates to the KSP2 system, since if you are boosting prograde at the spot you placed your node,  you won't be  boosting prograde anymore at the midpoint of your burn.

Thanks for making that clearer. I'm not surprised that I assumed the trigonometric definition over the geometric - one is useful in the physics I studied, the other less so!

I do see how you're defining it and why it's conceptually useful. However...

I'm going to get a bit picky though as I fear you're playing a bit fast and loose with dimensions. We should remember that the DeltaV is a change in velocity whereas an orbit describes an object's position and so one is a derivative of the other, not a component of. They aren't defined in the same space. So, the normal relations between a conic section and its secant don't apply. In that sense, while one can claim that the desired change in velocity is parallel to the prograde vector at periapsis, it makes no physical sense to claim that it is a vector which intersects an orbit. A velocity vector has no spatial position, no start point or end point. It's apples to oranges.

[Alexoff]

2 hours ago, Superfluous J said:

There is an inherent difference between the "difficulty" of doing something new *to you* and doing something actually new, that no one's ever done before

So you can talk about KSP1, KSP2 is not so different from the first part

2 hours ago, Superfluous J said:

Cars are ridiculously easy compared to software.

This is easy to do when trained specialists bring the finished line, find suppliers, hire and train personnel.

2 hours ago, Superfluous J said:

I'm sure it was difficult to DESIGN the FIRST can of whatever soda was first canned, but right now it's so simple you don't even need people there anymore.

It's easy to hire Nertea and take a bunch of parts from him for the game

1 hour ago, Periple said:

Making a game isn't anywhere near as hard as figuring out how to mass produce cars, but it's still complicated -- and the process of accumulating experience, sharing it, learning from it, and applying the lessons takes time.

You can learn a lot from squads in 6 years. I understand it is very difficult to add anti-aliasing, parachutes for kerbals and frame rate capping to the game. It would be understandable if the developers would have difficulty adding realistic physics, but even the banal things are still not done.

[The Aziz]

3 hours ago, Alexoff said:

It's easy to hire Nertea and take a bunch of parts from him for the game

Aa far as I know, his parts were distributed under license that prohibited commercial use, so unless it was changed, and I don't think it was, they can't just "take" something he did earlier.

Edited July 14, 2023 by The Aziz

[Alexoff]

1 hour ago, The Aziz said:

Aa far as I know, his parts were distributed under license that prohibited commercial use, so unless it was changed, and I don't think it was, they can't just "take" something he did earlier.

In any case, all these parts were made by a master of his work, hired from the outside. Whether he used his old parts or made something from scratch is not so important, dozens of other employees were doing something else with much worse results. And in the threads of his mods, he did not whine how difficult it was to do

[herbal space program]

8 hours ago, KUAR said:

I'm going to get a bit picky though as I fear you're playing a bit fast and loose with dimensions. We should remember that the DeltaV is a change in velocity whereas an orbit describes an object's position and so one is a derivative of the other, not a component of. They aren't defined in the same space. So, the normal relations between a conic section and its secant don't apply. In that sense, while one can claim that the desired change in velocity is parallel to the prograde vector at periapsis, it makes no physical sense to claim that it is a vector which intersects an orbit. A velocity vector has no spatial position, no start point or end point. It's apples to oranges.

Fair enough, but I only actually invoked the term secant because somebody else did first.  I could qualify what I said more to make that representation more accurate terminologically, but the simple way of explaining it is that in the old system, your target marker always closely approximated the same absolute spatial direction as the one you defined where you placed your node.  In the new system, it doesn't work like that anymore, which is going to take some getting used to for me since I have spent thousands of hours doing it the old way.

[MechBFP]

20 minutes ago, herbal space program said:

Fair enough, but I only actually invoked the term secant because somebody else did first.  I could qualify what I said more to make that representation more accurate terminologically, but the simple way of explaining it is that in the old system, your target marker always closely approximated the same absolute spatial direction as the one you defined where you placed your node.  In the new system, it doesn't work like that anymore, which is going to take some getting used to for me since I have spent thousands of hours doing it the old way.

That is interesting, as I never used the target marker. I always just pointed pro grade the whole time. Your way certainly makes more sense in hindsight though.

What were you actually targeting though to get the target marker to do that?

[herbal space program]

18 minutes ago, MechBFP said:

That is interesting, as I never used the target marker. I always just pointed pro grade the whole time. Your way certainly makes more sense in hindsight though.

What were you actually targeting though to get the target marker to do that?

Sorry, I misspoke there. What actually I meant was the "maneuver" marker all along. That's what I was talking about. So you place the node, dragging the handles in whatever direction you want to go, and then boost on that maneuver marker. Obviously in KSP, the " target"  marker  literally means something else. I am just carelessly mangling the terminology.

Edited July 14, 2023 by herbal space program

[KUAR]

4 hours ago, herbal space program said:

Fair enough, but I only actually invoked the term secant because somebody else did first.  I could qualify what I said more to make that representation more accurate terminologically, but the simple way of explaining it is that in the old system, your target marker always closely approximated the same absolute spatial direction as the one you defined where you placed your node.  In the new system, it doesn't work like that anymore, which is going to take some getting used to for me since I have spent thousands of hours doing it the old way.

Yeah, my KSP log was only 2-300 hours (albeit over a short timeframe!) so fewer learned behaviours to shake.

Sorry about my insufferable pedantry, I think I knew full well what you were on about.

[herbal space program]

1 hour ago, KUAR said:

Yeah, my KSP log was only 2-300 hours (albeit over a short timeframe!) so fewer learned behaviours to shake.

Sorry about my insufferable pedantry, I think I knew full well what you were on about.

No worries, pedantry is a baked-in feature of this whole forum community .  And yes, I have a whole lot of learned behaviors to shake wrt KSP1 maneuver nodes.  I've played around 4,000 hours of KSP1 total, and a whole lot of that time was spent plotting complicated multi-gravity assist  ways of getting from here to there by twiddling maneuver nodes.

[Reusables]

Lol people still have high hopes up when only minor bugfixes are dropping

[The Aziz]

>one of the most wanted and gamebreaking bug has been resolved

>"minor"

[Blue_Point]

great work!