Cannot Deploy While Stowed "Mechanic"

[swjr-swis]

5 hours ago, AlamoVampire said:

@Arsonide that mechanic is now a part of your bug tracker. the images failed to work on it

Adding the link to the new issue you posted:

http://bugs.kerbalspaceprogram.com/issues/10088

A few suggestions about that report:

• Can you upload the craft files of the craft that show the issues with the solar panels and the landing gear? That way I can confirm the report.
• Also, as much as this thing has plagued us, 'critical' is not the right level, game can still run as long as we don't use any fairings/bays at all. Not saying that makes it any better, but you should know it'll be downgraded.
• Asking for it to be removed completely is likely pointless, and pretty much guaranteed to get protested by others. A setting that lets us globally disable it in our individual games would be more realistic to request, and keep those that like the mechanic happy as well. The ideal, in my view, would be to allow to disable/enable it per-part, as a toggle, but as that's more of a coding effort, I'm afraid to ask. I'd settle for a global setting.

I'll see if I can add some examples to show the absurdity of making parts inoperable inside a hollow container, when those same parts work as normal inside solids, just to ensure that that side of this whole issue is properly reported as well.

[AlamoVampire]

5 hours ago, swjr-swis said:

Adding the link to the new issue you posted:

http://bugs.kerbalspaceprogram.com/issues/10088

A few suggestions about that report:

• Can you upload the craft files of the craft that show the issues with the solar panels and the landing gear? That way I can confirm the report.
• Also, as much as this thing has plagued us, 'critical' is not the right level, game can still run as long as we don't use any fairings/bays at all. Not saying that makes it any better, but you should know it'll be downgraded.
• Asking for it to be removed completely is likely pointless, and pretty much guaranteed to get protested by others. A setting that lets us globally disable it in our individual games would be more realistic to request, and keep those that like the mechanic happy as well. The ideal, in my view, would be to allow to disable/enable it per-part, as a toggle, but as that's more of a coding effort, I'm afraid to ask. I'd settle for a global setting.

I'll see if I can add some examples to show the absurdity of making parts inoperable inside a hollow container, when those same parts work as normal inside solids, just to ensure that that side of this whole issue is properly reported as well.

For the landing gear, here is the 100% stock shuttle I made for Arsonide while 1.1.3 was in experimentals and have linked already in this thread. As for the Solar Panel one, I will check shortly to see if its still doing this. I suggest taking a moment to look at the vessel description in the VAB as it has a note that should be read.

http://www.filedropper.com/landinggeartestshuttle

*EDIT* The solar panel one is hit and miss, right now <its not been altered at all since creation, which makes this one peculiar> it is NOT showing this behavior anymore (as far as the solar panels go). *EDIT*

Why on Earth would people protest the removal of something NO ONE wanted in the FIRST PLACE? No really? This has done NOTHING to IMPROVE KSP in the slightest. It has grounded at least HALF my fleet of shuttles, it has borked other players stations where its literally requiring people with KIS/KAS to EVA, dislodge the "broken" items deploy them, then reaffix them to their stations. With all respect, I think not a SINGLE person would protest this pointless mechanics removal.

Edited July 6, 2016 by AlamoVampire

[Arsonide]

5 hours ago, swjr-swis said:

Can you elaborate on what you feel would be a 'proper' report? As in, what needs to be added/changed to the following to make them 'proper' enough to get the visibility we're being teased with:

Ideally one that was confirmed on the latest version, and one that mentions the error that you are receiving. The only one of those issues that does mention the error is eight months old, and appears to be a fairing specific issue. We like the issue to be as specific as possible, so that if we do read it eight months down the road, it is obvious that it is not an unrelated physics and/or aero issue. Only one of these issues has reproduction steps, and none of them have logs or save files attached. The craft files do help, but we generally want as much information as we can get. The wiki has information on how to find all of these things.

As for if the issue is feedback about an intentional mechanic, or an actual bug, I would classify it as a bug for sure, but a "normal" priority one. The mechanic is not crashing the game, but is also clearly not intended to occlude parts outside of the cargo bay. Normal priority does not mean it is not important, but we reserve high and critical for things like "the game cannot run". This does affect gameplay, so we want it as high as we can get it without dipping into crash territory.

I understand that the issue is frustrating for you, which is why I want to make sure that we get it cataloged. We like to keep a detailed written paper trail of these issues, because it allows our QA team to follow up on them in an organized manner. If there is enough information on the issue, they will be able to reproduce it. If they can reproduce it, we can fix it. Once we fix it, they can double check it, and hopefully resolve it on the tracker. Even after it is resolved, it remains on the tracker for future reference.

[AlamoVampire]

With respect @Arsonide as this is not a bug, but a Squad designed and developed feature behaving in the manner in which it was developed, no log is produced. As for replication steps, my 100% stock parts shuttle made at your request during 1.1.3 experimentals contains in its description box below its name in the VAB all pertinent replication information. I also somewhere in this thread gave those same steps, but for efficiency sake will list them again here.

Cannot Deploy While Stowed: Stock Landing Gear Test Shuttle steps:

1. Select the shuttle in VAB.

2. Click launch.

3. Assuming stock key binds hit G or Click the gear button or manually try to deploy the nose gear.

4.  Watch as the game declares its stowed.

[The_Rocketeer]

@AlamoVampire just because it's not a bug it doesn't mean it's not a Public Issue that belongs on the Public Issue Tracker.

@Arsonide I think the paper trail on this issue is pretty obvious, the replication steps are also obvious, and the short-term solution is simply to disable the feature until it's properly updated. Complaining about a lack of evidence in the face of such obviousness is kind of ridiculous.


The stowage mechanic needs to be:

a) able to tell the difference between parts attached inside and outside a container-part;
OR able to tell the difference between a payload-subassembly and a functional part of the mother-vessel-assembly.
b) toggleable by the player through the RMB tooltip interface per container-part.

[Corona688]

19 minutes ago, WildLynx said:

@Arsonide

Can you elaborate on "stowed" mechanic?

It's the way the game prevents you from extending ladders, wheels, antennas, and solar panels inside a cargo bay whenever the cargo bay is closed.  This happens in the VAB too.  I think it's done with a hitbox, with the result that parts radially attached to the OUTSIDE of a cargo bay often fail to deploy as well.

Some people have worked around it by using the offset tool to push radially attached parts further out of the hull but at present there's not a reliable way to make this happen.

Edited July 6, 2016 by Corona688

[AlamoVampire]

@The_Rocketeer Except there are multiple instances of this mechanic being called out already.

I am going to be blunt. Squad designed, developed and implemented a mechanic late last year that no one asked for or wanted. They claimed to have removed it after countless explanations on not only how its unkerbal and how real world rockets do exactly what this unwanted mechanic was stopping. I myself have decried this mechanic as a theft of learning. 

Its clearly back and clearly worse than ever. They need to get rid of this mechanic. 

Edited July 6, 2016 by AlamoVampire

[Corona688]

1 minute ago, AlamoVampire said:

@The_Rocketeer Except there are multiple instances of this mechanic being called out already.

And calling the devs out here, where they don't read, is more likely to work than the bug tracker they do read?

[The_Rocketeer]

@AlamoVampire I'm not contesting that, but arguing that it doesn't need to be reportedon the tracker because it isn't a bug is a fallacy.

[AlamoVampire]

4 minutes ago, The_Rocketeer said:

@AlamoVampire I'm not contesting that, but arguing that it doesn't need to be reportedon the tracker because it isn't a bug is a fallacy.

Except its been reported multiple times. @swjr-swis linked multiple instances.

[The_Rocketeer]

27 minutes ago, The_Rocketeer said:

@AlamoVampire I'm not contesting that, but arguing that it doesn't need to be reportedon the tracker because it isn't a bug is a fallacy.

^^ This.

[Snark]

Howdy folks,

I think this discussion has run its course.

It's clear that there's a problem, it's clear that it's frustrating people.  Also, it's clear that it's a bug, statements like this notwithstanding:

4 hours ago, AlamoVampire said:

With respect @Arsonide as this is not a bug

...because it is a bug.  It's unintentional behavior that nobody wants.  The program is behaving in a way that the devs did not intend; that's the very definition of what a "bug" is.  Here we have it, straight from the source:

4 hours ago, Arsonide said:

As for if the issue is feedback about an intentional mechanic, or an actual bug, I would classify it as a bug for sure, but a "normal" priority one. The mechanic is not crashing the game, but is also clearly not intended to occlude parts outside of the cargo bay. Normal priority does not mean it is not important, but we reserve high and critical for things like "the game cannot run". This does affect gameplay, so we want it as high as we can get it without dipping into crash territory.

There.  Right there.  There's a developer, from Squad, telling you in so many words that this is a bug, this is not the behavior that the developers intend.  Furthermore, that they put a lot of importance on it and want to fix it.

As a user impacted by this, you're entitled to call it out and say "I don't like this, it should be fixed."  You're not really in a position to determine how to fix it-- that's something that nobody but a developer can do, since they're the only ones who have enough of a view into the full problem (and the code behind it) to work out how to attack it.  You can certainly give some suggestions, if you have ideas, but you also need to recognize that you're not in a position to deal with all the other potential cans of worms that might be opened by implementing a particular suggestion of yours.  So by all means make the suggestion... but once you've said it (which you have, here, clearly and repeatedly), you've made your point.

Looking over the thread, it seems to me that pretty much every issue has been addressed as thoroughly as it's going to, here.

• Issue:  "I have this technical problem with my landing gear and need a way to work past it, now, in the currently released version of KSP."
• Solution:  Discussed and answered.  If it's still not clear how to fix your problem, I'd suggest opening a thread in Technical Support.
• Issue:  "I want to make sure the developers know we want this, and hear what they say."
• Solution:  Developer has responded in thread.  Developer made clear that this is unintended behavior and they want to fix it.

Aside from just venting (which I understand; problems like this are really frustrating), that's basically what the productive content of this thread is, and the point has been made.  Repeatedly rehashing the above won't accomplish anything.  Accordingly, locking the thread.

 

...Taking off my moderator hat for a moment, speaking on a purely personal note, both as a game player and as a software engineer with over 20 years of experience in the industry:  I really appreciate how engaged the Squad developers are in the forums.  I've never seen any other software company (either as a user, or as a developer) where users posting in the product's forum get such active and frequent engagement from the actual people who write the code.  It's not just refreshing, it's astonishing.  Try posting in the forum of some major AAA hit from one of the big-name game companies, and see how much of a response you get from them.  When someone like @Arsonide jumps in on a thread like this... we're very lucky to have that level of engagement.

If you feel annoyed at a thread like this... just consider how much more annoyed you'd be if Squad simply ignored the thread and nobody there gave you the time of day-- which is what would have happened with pretty much any other software company I've ever heard of.  As far as I'm concerned, that's an above-and-beyond level of passion that the Squad devs show to the community.  I hope we can all show our appreciation for that, and actively encourage such engagement.

So the next time a thread like this comes up... maybe take a few moments to think about that?