Bug Status [3/11]

[Intercept Games]

Heya Kerbonauts,

Welcome back to the K.E.R.B! A few updates to the table today, but nothing major as a significant portion of our past two weeks was spent on some very exciting sprint planning.

Since you all enjoyed the last bug video we shared, as a treat here's a short clip QA Director Darrin sent over of him and Engineering Director Jeff reacting to a pre-For Science! buoyancy issue. Still had a lot of tuning to do!

Darrin apologizes about using his phone to record his screen

See you in two weeks!

KSP Team

Community's Current Top Issues: 

#	Bug	Status
1	No trajectory lines in map view	Fix being tested, investigating other causes
2	Incorrect "landed" status while in orbit causes trajectory to disappear in Map View	Reproducible
3	Parts inside fairing heating up	Fix implemented and verified
4	Broken DeltaV with multiple engines and/or with side tank attached [fuel tank placement order messes up dV calculations]	Fixes being implemented
5	Rovers are hitting a physics glitch every 1000m from the Location of Rover Being Loaded into the Game with Disastrous Results	Improved, investigating long-term solutions
6	Timewarp limit is too restrictive on some non-atmospheric planets (Gilly, Bop, Minmus...)	Reproducible
7	Landing gear blocked when it is not [also happens with other deployable parts	Unable to reliably reproduce
8	Parachutes didn't deploy	Investigating additional issues post v0.2.1
9	For the difficulty of the LIL CHONKER mission, 35 Science as a reward is too low	Fix implemented and verified
10	A Kerbal on EVA Exerts a Force upon the Vessel	Reproducible
11	Control Surface Oscillation in Atmosphere	Reproducible
12	Accelerate under Timewarp still not working in some cases (post v0.2.0)	Investigating
13	Vessel icons block celestial bodies from being clicked on [when zoomed out] [Vessel Icons have priority over Celestial Bodies]	Reproducible
14	Resource Manager (RM) disallows re-placement of a resource in the Transfer list of the RM, creating duplicates in the parts list of the RM	Reproducible
15	When Trying to Close a Fairing on a Part, it will Disappear Instead	Investigating
16	When targeting another craft close by navball indicators (prograde|retrograde etc) start moving in an erratic way. [Wobbly navball markers]	Reproducible
17	VAB camera offset whenever middle mouse clicking on part after panning	Reproducible
18	Game Thinks Entire Craft is Destroyed Even Though Command Pod is Still Intact	Investigating
19	Flags in saves cause Kerbals, wheels and landing gear to fall into the ground and not function properly on many bodies (terrain bug)	Investigating
20	Can't create a maneuver node within another SOI	Working as intended. Evaluating as feedback

Note: this report is not fully representative of the work our team is focused on. This is just to provide insight into our progress on the most concerning issues to our community. Additionally, the lack of a status update does not imply a lack of importance or general progress - we just do not have anything to share at this time.

[The Space Peacock]

This KERB was brought to you by: Darrin’s Phone

[MARL_Mk1]

I vote to keep that buoyancy bug and ship it as a new feature

Edited March 11 by MARL_Mk1

[Stephensan]

i need more silliness

 

kind regard

-Ksp 2 community

 

[Darrin H]

Ok I know I'm going to get a hard time for that vid, but it was spur of the moment - and had our reaction.

NORMALLY - we definitely record on our computers.   This was special.

[Little 908]

9 minutes ago, Intercept Games said:

Darrin apologizes about using his phone to record his screen

See you in two weeks!

Jebediah kerman nooooo

[dmsilev]

For #20, let me chime in with feedback to say that this behavior should be changed to allow placing nodes in other SOIs. Sure, for some things (e.g. circularizing after arriving at a destination) it's no big deal to plop down a node after the ship has entered the SOI, but there are definitely times when you want to plan out a mission fully in advance (gravitational assists, for instance) and you can't do that if nodes are limited to the current SOI. 

Edited March 11 by dmsilev

[The Aziz]

So... 17/20 did not change. I'll take this space to give some feedback - if it didn't change, replace it with something lower down the list (and maybe bring it back when there's an update on the issue). There's more to it though, because there are six items on the list from the last pre-0.2.1 KERB that also did not change since then. People like progress, people don't like when things appear stalling. If that's the only news we're getting every two weeks (and a bit), add some effort. Yes I know there's probably some work done internally but it's not reflected here so.. People will eventually stop reading if there's nothing interesting to take from these posts. It could've been posted on thursday if most of it was copypasted.

As for the node creation, whose idea was this? We can create one on the main path when it goes through another SOI, far away from camera and everything, but not on the cut piece when we CAN focus the camera for better accuracy? I want to know in advance if I need additional early correction burn that will make orbital insertion cheaper or not.

[Spicat]

 The little videos are always fun keep them coming! 

1 hour ago, Intercept Games said:

20

Can't create a maneuver node within another SOI

Working as intended. Evaluating as feedback

However, this just seems weird to me. It's even weirder that when you're in Kerbin SOI and have an intercept with Jool, you CAN place a maneuver in Jool SOI but as soon you're in Kerbol SOI you can't place the maneuver anymore:

Spoiler

Same thing when you're in Kerbol SOI, you can't plot a maneuver in Jool SOI but can plot a maneuver inside one of its moon SOI:

Spoiler

Want to make a maneuver inside Mun SOI? Just go inside Minmus SOI and now you can! 

Spoiler

It makes little sense to me that this behavior was intended. Either way it is or it is not intended, we should plot maneuver inside any SOI we want (The most obvious one is inside Mun SOI when you're in Kerbin SOI).

Edited March 12 by Spicat

[Superfluous J]

35 minutes ago, Spicat said:

when you're in Kerbin SOI and have an intercept with Jool, you CAN place a maneuver in Jool SOI but as soon you're in Kerbol SOI you can't place the maneuver anymore

36 minutes ago, Spicat said:

Same thing when you're in Kerbol SOI, you can't plot a maneuver in Jool SOI but can plot a maneuver inside one of its moon SOI

36 minutes ago, Spicat said:

Want to make a maneuver inside Mun SOI? Just go inside Minmus SOI and now you can!

Don't tell them! We don't want them to remove THAT functionality too!

[Kimera Industries]

KSP 2 players: Hey this buoyancy bug ruins everything-

The buoyancy bug: 

[ttikkoo]

3 hours ago, Intercept Games said:

6

Timewarp limit is too restrictive on some non-atmospheric planets (Gilly, Bop, Minmus...)

Reproducible

This has been "reproducible" for a while - is there a plan to loosen the time warp restrictions or are these restrictions working as intended?

I find it quite frustrating having to sit through a 1-2 minutes of 4x time warp if my interplanetary maneuver or rendezvous maneuver is a few orbits ahead.

[Sade]

8 hours ago, Intercept Games said:

as a significant portion of our past two weeks was spent on some very exciting sprint planning.

What is sprint planning?

[Darta01]

8 hours ago, Intercept Games said:

 

20	Can't create a maneuver node within another SOI	Working as intended. Evaluating as feedback

Ah yes! The maneuver planning tool that does not allow you to plan maneuver!

This is a terrible design choice

[ShadowZone]

43 minutes ago, Darta01 said:

Ah yes! The maneuver planning tool that does not allow you to plan maneuver!

This is a terrible design choice

I just have to add my voice to the people asking for #20 to switch from "works as intended" to "redesign going on based on player feedback".

It hampers more complex trajectory planning, same as the choice to limit maneuver nodes to stop working when exceeding the calculated dV of the active vehicle (which can be demonstrably wrong often times).

Please change this!

43 minutes ago, Sade said:

What is sprint planning?

In modern software development and especially when using a framework called "Scrum", the development team works in short increments, usually 2 to 3 week cycles called "sprints". At the beginning the team pulls from a prioritized backlog what they believe they will be able to achieve during the coming 2 weeks. The backlog is usually prioritized by a product owner based on business value (based on answering the question: what will provide the most value to the customers/users of the software?).

This process of picking the body of work for the next sprint and committing to it is called sprint planning.

After a sprint, the development team presents their results and gathers feedback and after that usually sits down and discusses what went well and what could be improved in the upcoming sprints.

Switching to these shorter development cycles enables software companies to get feedback faster and improve on software faster than working months or years in the blind and then having to rework a metric ton of code at once if they realize they messed up a foundational feature.

 

At least that's the theory. Most software companies/teams use some variant of this process.

[KUAR]

27 minutes ago, ShadowZone said:

I just have to add my voice to the people asking for #20 to switch from "works as intended" to "redesign going on based on player feedback".

It hampers more complex trajectory planning, same as the choice to limit maneuver nodes to stop working when exceeding the calculated dV of the active vehicle (which can be demonstrably wrong often times).

Please change this!

In modern software development and especially when using a framework called "Scrum", the development team works in short increments, usually 2 to 3 week cycles called "sprints". At the beginning the team pulls from a prioritized backlog what they believe they will be able to achieve during the coming 2 weeks. The backlog is usually prioritized by a product owner based on business value (based on answering the question: what will provide the most value to the customers/users of the software?).

This process of picking the body of work for the next sprint and committing to it is called sprint planning.

After a sprint, the development team presents their results and gathers feedback and after that usually sits down and discusses what went well and what could be improved in the upcoming sprints.

Switching to these shorter development cycles enables software companies to get feedback faster and improve on software faster than working months or years in the blind and then having to rework a metric ton of code at once if they realize they messed up a foundational feature.

 

At least that's the theory. Most software companies/teams use some variant of this process.

At risk of deviating from the topic, have you ever tried running scrum for a hybrid software/hardware product which is subject to waterfall procurement and agile development (internally)? Really struggling to mesh the competing frameworks!

[ShadowZone]

26 minutes ago, KUAR said:

At risk of deviating from the topic, have you ever tried running scrum for a hybrid software/hardware product which is subject to waterfall procurement and agile development (internally)? Really struggling to mesh the competing frameworks!

Unfortunately, no. I have only worked in software projects over the course of my career, no hybrid or hardware. But I was involved in a big project where our team was working agile and the rest pretty much did waterfall. The biggest challenge was syncing up with the other teams that worked differently.

But here is where one of the creeds of the agile manifesto help: "people and interactions over processes and tools". We tried to get in touch with the right people and managed to work with them, no matter what framework they were using. It was still challenging, but defining the interfaces between teams and having constant communication helped.

[magnemoe]

1 hour ago, ShadowZone said:

I just have to add my voice to the people asking for #20 to switch from "works as intended" to "redesign going on based on player feedback".

It hampers more complex trajectory planning, same as the choice to limit maneuver nodes to stop working when exceeding the calculated dV of the active vehicle (which can be demonstrably wrong often times).

Please change this!

I agree, the most obvious one is to check if you have enough dV to circulate, Another is to use the Mun for plane change, here you need an mun intercept burn and an burn at the moon. 
Or do an plane change far from Tylo so you can set up an intercept with Bop at Tylo. 
Just as some simple examples. People doing advanced gravity assists will find this even more useful. 

[magnemoe]

11 hours ago, MARL_Mk1 said:

I vote to keep that buoyancy bug and ship it as a new feature

What is the buoyancy bug? 

And issue with #18 is that if you typically set control from here to an top docking port then crash and destroy the docking port game think craft is destroyed. 

[Scarecrow71]

6 hours ago, Darta01 said:

Ah yes! The maneuver planning tool that does not allow you to plan maneuver!

This is a terrible design choice

Whichever developer is responsible for this feature has obviously never played KSP1.  One of the most common interplanetary maneuvers is Kerbin-Eve-Jool, and it sure is nice when you can create that gravity-assist node to transfer from Eve to Jool well before you get to Eve.

Horrible design choice.  This, coupled with not creating nodes when you are out of fuel, is a real detriment to the game.

[Navoan]

4 hours ago, magnemoe said:

I agree, the most obvious one is to check if you have enough dV to circulate, Another is to use the Mun for plane change, here you need an mun intercept burn and an burn at the moon. 
Or do an plane change far from Tylo so you can set up an intercept with Bop at Tylo. 
Just as some simple examples. People doing advanced gravity assists will find this even more useful. 

Well articulated response with some great examples.  Couldn't agree more.

[kdaviper]

12 hours ago, Kimera Industries said:

KSP 2 players: Hey this buoyancy bug ruins everything-

The buoyancy bug: 

Well dam 

[Biggen]

#20 "Works as intended"??  If that means it works poorly then you guys nailed it. Seriously.  It's a big problem not to be able to create nodes outside of another bodies SOI.  This should be at the top of the list not the bottom.

At any rate, I am glad to see other items getting some love.  I've had to shelve KSP2 currently and go back to KSP1 because the bugs were just getting on my nerves. A lot of what I have issues with are on that list so I think that is good news.

[Cyal]

So these items are the ...  Community's Current Top Issues

Some of these items are on the list since January. They are the TOP ISSUES ?... These things prevent players from enjoying the game as it was intended.  For some of them, there are even some community fixes because they are so annoying.

I waited fot this KERB with great anticipation ... and now i must say that i am sad and disappointed.

Don't get me wrong developers: i love u people for creating this new version of a game i love more than (almost) any other game in existence.
The basic game loop is very well fleshed out, is fun to explore and keeps me playing regular. The advanced stuff, like docking of complex vehicles and refueling, multiple transfers and flybys, getting rovers to other bodies, very low thrust to weight vehicles, are very buggy in my personal experience.

This bug compilation only makes sense if we see some real progress - otherwise it gives the feeling that nothing is happening at all.
I am very much looking forward to the colonies update - but fixing the core game loop should have priority over new feature implementation. At least that is what i would like to see. New features every 2-4 months and fixes every 1-2 weeks would be amazing! 

I was so disappointed, and had the feeling that i was seeing the same items again and again - that i made a progress/comparison list :-D

But again... i don't want to be salty or make anyone feel bad. You are doing great. Only please focus more on the community wishes - this game lives far and foremost because of a very engaged community.

 

1/12	1/25	2/23	3/11		1/12	1/25	2/23	3/11
#	#	#	#	Bug	Status	Status	Status	Status
1				No trajectory lines in map view	Partial fix being tested	Partial fix being tested	Fix being tested	Fix being tested, investigating other causes
2				Stage activation requires a double-click / double-spacebar pressing	Fix implemented and verified	Fix implemented and verified	-	-
3				Incorrect "landed" status while in orbit causes trajectory to disappear in Map View	Reproducible	Reproducible	Reproducible	Reproducible
4				Parts inside fairing heating up	Fix in progress	Fix being tested	Fix implemented and verified	Fix implemented and verified
5				Rovers are hitting a physics glitch every 1000m from the Location of Rover Being Loaded into the Game with Disastrous Results	Improved, investigating long-term solutions	Improved, investigating long-term solutions	Improved, investigating long-term solutions	Improved, investigating long-term solutions
6				"Experiment" button shows available experiments even though the experiments have been done before	Fix implemented and verified	Fix implemented and verified	-	-
7				Signals go through planets and moons (CommNet/Antennas not affected by occlusion)	The current behavior is how it was designed. We will consider the feedback.	-	-	-
8				Upper atmospheres heat up and destroy parts far too quickly	Tuning being tested	Fix implemented and verified	-	-
9				Landing gear blocked when it is not [also happens with other deployable parts]	Unable to reliably reproduce	Unable to reliably reproduce	Unable to reliably reproduce	Unable to reliably reproduce
10				Illuminators (lights) do not function [Flicker/Blink for a second and turn off]	Fix implemented and verified	Fix implemented and verified	-	-
11				SAS does not hold orientation during time warp	Reproducible, investigating alternative solutions	-	-	-
12				Timewarp limit is too restrictive on some non-atmospheric planets (Gilly, Bop, Minmus...)	Reproducible	Reproducible	Reproducible	Reproducible
13				Struts in higher symmetry than the parts they are attached to causes issues	Investigating	-	-	-
14				Control Surface Oscillation in Atmosphere	Reproducible	Reproducible	Reproducible	Reproducible
15				Parachutes didn't deploy	Need more information	Partial fix being tested	Partial fix being tested	Investigating additional issues post v0.2.1
16				For the difficulty of the LIL CHONKER mission, 35 Science as a reward is too low	Fix in progress	Fix being tested	Fix implemented and verified	Fix implemented and verified
17				Inconsistent Framerate During Launch [Edit: The Video Shows a Gradual FPS drop as the Launch Continues]	Need more information	-	-	-
18				Resource Manager (RM) disallows re-placement of a resource in the Transfer list of the RM, creating duplicates in the parts list of the RM	Investigating	Investigating	Reproducible	Reproducible
19				A Kerbal on EVA Exerts a Force upon the Vessel	Reproducible	Investigating	Reproducible	Reproducible
20				Orbit decay still happening [Landing legs or certain parts interacting can cause it]	Fix implemented and verified	Fix implemented and verified	-	-
	16			Dr. Keri Kerman repeating the first textbox on the Minmus discoverable mission debrief	-	Fix implemented and verified	-	-
		4		Broken DeltaV with multiple engines and/or with side tank attached [fuel tank placement order messes up dV calculations]	-	Investigating	Fixes being implemented	Fixes being implemented
		10		Vessel icons block celestial bodies from being clicked on [when zoomed out] [Vessel Icons have priority over Celestial Bodies]	-	-	Investigating	Reproducible
		13		Accelerate under Timewarp still not working in some cases (post v0.2.0)	-	-	Investigating	Investigating
		15		When Trying to Close a Fairing on a Part, it will Disappear Instead	-	Investigating	Investigating	Investigating
		16		When targeting another craft close by navball indicators (prograde|retrograde etc) start moving in an erratic way. [Wobbly navball markers]	-	-	Reproducible	Reproducible
		17		VAB camera offset whenever middle mouse clicking on part after panning	-	Investigating	Reproducible	Reproducible
		18		Game Thinks Entire Craft is Destroyed Even Though Command Pod is Still Intact	-	-	Need more information	Investigating
		19		Can't create a maneuver node within another SOI	-	-	Investigating	Working as intended. Evaluating as feedback
		20		All Noted Tracking Station Bugs For Celestial Body Information (So Far)	-	-	Multiple fixes implemented and verified	-
			19	Flags in saves cause Kerbals, wheels and landing gear to fall into the ground and not function properly on many bodies (terrain bug)	-	-	-	Investigating

 

Edited March 12 by Cyal

[mixaplexilix]

Hi, I have read the forum since early days KSP1 and joined to add feedback to # 20 the "can't create maneuver node in another SOI," bug. As noted it doesn't really make sense as an intentional decision. Careful use of the maneuver node system in KSP1 can let a player plan a mission from Kerbin obrit all the way out to a suicide burn on a moon of Jool and be confident they have the delta-V and time right.

I want to add my voice to those calling for the ability to create maneuver nodes in the next SOI. Thanks.