Jump to content

PSA: Don't set scanners as your first part.


Frybert

Recommended Posts

...How did that not get caught in testing!? I would think "check to make sure that every part that can be made the root of the vessel does not cause problems when set to be the root of the vessel" would be a pretty high-priority item on the checklist of things to check...

Link to comment
Share on other sites

...How did that not get caught in testing!? I would think "check to make sure that every part that can be made the root of the vessel does not cause problems when set to be the root of the vessel" would be a pretty high-priority item on the checklist of things to check...

Ever did software development? Do you want KSP 1.0 now or in 2016? As checking everything would take forever. The workaround/fix for this would be easy. We can just not use the scanner as root part, and Squad just has to flip a flag on the part for the next patch. Little harm done, and there are tons of more important things to check (for example, making sure the persistence file is never messed up, which would ruin your game a lot more then this small bug)

Link to comment
Share on other sites

Ever did software development? Do you want KSP 1.0 now or in 2016? As checking everything would take forever. The workaround/fix for this would be easy. We can just not use the scanner as root part, and Squad just has to flip a flag on the part for the next patch. Little harm done, and there are tons of more important things to check (for example, making sure the persistence file is never messed up, which would ruin your game a lot more then this small bug)

Oh I know a lot about software development. And one thing I know is that you either dedicate a part of your testing team to checking the mundane potential issues involving basic decisions the user can make, or you code an app to do that checking for you. A well-run testing cycle does both random and systematic testing, as the usual method of "just do whatever and report any bugs you find" is going to miss a lot of bugs that a systematic approach will find.

Link to comment
Share on other sites

An update:

I tried to 'rescue' my cloaking probe. Once I got within what I'm assuming was the physics bubble, everything (my ship, the mun even Kerbin) disappeared. I couldn't revert, so I went back to space port where the game crashed (literally just went right back to desktop). The save is now corrupt.

Link to comment
Share on other sites

An update:

I tried to 'rescue' my cloaking probe. Once I got within what I'm assuming was the physics bubble, everything (my ship, the mun even Kerbin) disappeared. I couldn't revert, so I went back to space port where the game crashed (literally just went right back to desktop). The save is now corrupt.

Ouch. :( Squad, how didn't the testers notice this?

EDIT: Ninja'd by Roverdude. Glad to see the team is on the case!

Link to comment
Share on other sites

@Thomas988 - my only issue really with reports that include stuff like 'how didn't the testers notice this'...

People are human. And even a bunch of incredibly smart and passionate people are going to miss things. Or do things in a different way than you (I for one have never used the scanner as a root part - I start with a pod). And it also discounts the thousands of things they *did* find, just so you folks would not have to experience them.

Link to comment
Share on other sites

Wow, and I thought the Training scenarios glitching out was already a "how did that make it through testing" kinda thing. This is literally awful. D:

And how many times have you started with a part that is not a pod/cockpit/probe? For every tester (~100?) there is a thousand players. Guess who will realistically try more combinations? Don't blame the testers, ever.

Link to comment
Share on other sites

And how many times have you started with a part that is not a pod/cockpit/probe? For every tester (~100?) there is a thousand players. Guess who will realistically try more combinations? Don't blame the testers, ever.

Eh. Blame the testers sometimes, but not always.

For this particular bug, I'm not terribly surprised it was missed. Setting root parts, launching, then reverting is possibly easy to put in a QA script, but you have to have someone think that it might be a problem, first. It's not guaranteed to come up in normal gameplay or testing.

Link to comment
Share on other sites

And how many times have you started with a part that is not a pod/cockpit/probe? For every tester (~100?) there is a thousand players. Guess who will realistically try more combinations? Don't blame the testers, ever.

+1

Already looking at this.

I'm sure you're already aware then, but I'll post it anyway:

Anytime I would leave the craft and come back to it via the tracking station it would bug out. Not just around the mun (I had one in Kerbin orbit as well).

Link to comment
Share on other sites

Oh I know a lot about software development. And one thing I know is that you either dedicate a part of your testing team to checking the mundane potential issues involving basic decisions the user can make, or you code an app to do that checking for you. A well-run testing cycle does both random and systematic testing, as the usual method of "just do whatever and report any bugs you find" is going to miss a lot of bugs that a systematic approach will find.

Actually I know programming too. Seems someone forgot to set this part as Not a root part like other science equipment. Its a simple mistake. I make them all the time. Humans are not perfect so we should stop pretending the developers are perfect. Sure this part is not meant to be a Root part.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...