Wing flexing in 1.7.1

[Klapaucius]

I just discovered this issue. It seems things are flexing a lot more in the newest release. Check this out, the same unaltered plane in 1.6.1 and then 1.7.1.  (Update note): The wings were already autostrutted.  Adding rigid attachment ameliorated it a little, but did not solve the problem.

 

Edited June 1, 2019 by Klapaucius

[Levelord]

Have you tried enabling autostrutting for the parts?

[Klapaucius]

2 minutes ago, Levelord said:

Have you tried enabling autostrutting for the parts?

All are autostrutted already.  I've updated the initial post to clarify that.

Edited June 1, 2019 by Klapaucius

[Levelord]

Then I'm just as stumped as you.

[Yakuzi]

Do you experience the wing flexing behaviour in 1.7.0 as well? Still on 1.6.1 myself.

[Lisias]

I had read in another thread that renaming the craft fixed something similar.

That sounded like nonsense to me, but I remember that now there're ".loadmeta" files for every craft on your save. So, perhaps, it's a problem on a new loadmeta format being expected on a old loadmeta.

Delete the "loadmeta" for your craft and see what happens. If this doesn't works, rename the craft and try again (and now I will be stumped).

Edited June 2, 2019 by Lisias
tyops. Who would guess it? :D

[dok_377]

It's probably due to this change: https://bugs.kerbalspaceprogram.com/issues/22733
Autostruts no longer strut parts across symmetry, they only go through one side. 

[Lisias]

9 minutes ago, dok_377 said:

It's probably due to this change: https://bugs.kerbalspaceprogram.com/issues/22733
Autostruts no longer strut parts across symmetry, they only go through one side. 

Ugh. This will cause a lot of breakage…  

[dok_377]

1 minute ago, Lisias said:

Ugh. This will cause a lot of breakage…  

Yeah, I don't know why they changed it. And the worst thing is we don't even know if that's a bug or an intentional change. Squad members seem to ignore those kind of questions for some reason. 

[Lisias]

13 hours ago, dok_377 said:

Yeah, I don't know why they changed it. And the worst thing is we don't even know if that's a bug or an intentional change. Squad members seem to ignore those kind of questions for some reason. 

I can't talk for them, just for me. Take what I'm writing ahead as something that happened to me and I want to share, not as something I think it's happening with someone else (it could, but you get it).

Spoiler

I once worked on a Company that had a shift on the management - we had a very open and no-nonsense approach to the bug track: we discussed openly about the bugs. It didn't matters who caused the bug, we had an agreement that a bug is a collective mishap - one may had did it, but everybody else had allowed it to happen.

Yeah, not up to the task professionals eventually were reallocated (I don't remember anyone being effectively fired). But whatever - hiring is a risk, what matters is if it worths on the end, and usually it's better to fire one or another under par coworker than let a excellent one go to the competition due inadequate hiring processes. And every hiring process is inadequate by definition.  

But then management changed (we were bought by the competition - TWICE in a year!!). People from overseas started to take decisions on staff that were used to be taken by someone that was looking us in the eye day after day, and was the ultimate responsible for the team's success or failure.

And when the guy taking decisions are not the one responsible for the consequences… You have a rupture on the chain of thrust.

If you are worried that by accepting your share on the mishaps you do it would be used against you on a promotion or handoff decision, you just don't. And when people on a team are used to refuse responsibilities on the borks they do, there's another rupture on the chain of thrust: you can't fully thrust your colleague's works at the risk of being you the one taking the heat.

So you end up solving things on the safer way for you, not the best way for the problem. Good teams under a not so good management usually protect themselves under a development process that would hinder pinpointing individual responsibilities. This works for some time, but then newcomers arrive, and not every newcomer will be ethical and cooperative to the situation. When that happens, it's usual that exactly the best ones choose to leave, and soon you have a bunch of newcomers (some good, some bad) and since no one knowns who's who, everybody ends up being handled as bad. And since the good ones tend to leave,  we have a vicious circle that perpetuates the problem.

The funny thing about all of that is that it happens even when the management is not going to do that nasty things we are afraid of. The problem is, essentially, the rupture on the chain of thrust. We don't know the guys, but hey… Someone else once did something that these new brass is doing now and in the end I got screwed, so it's better to cover my SAS.  

Yeah. Self-fulfilling prophecies. These stuffs bite.

Of course, there're a lot more of possible explanations that would fit. But talking about them would start a flame-war around here - we, old farts, are known to have little to no respect for people's egos. What's a Sin nowadays.  

Edited June 3, 2019 by Lisias
Oh yeah. tyops!

[panzer1b]

Guess im lucky to never have gotten reliant on autostrutting anything (except launch stages on rockets cause i cant be bothered to use normal struts on something i will see exactly 2 minutes before its jettisioned from  payload).

 

Still, i can see how this is a problem for very complex planes, albeit, im pretty sure i prefer the 1.7 version of that plane, the wobbliness is way more "kerbal".

[dok_377]

30 minutes ago, Lisias said:

I can't talk for them, just for me. Take what I'm writing ahead as something that happened to me and I want to share, no as something I think it's happening with someone else (it could, but you get it).

  Hide contents

I once worked on a Company that had a shift on the management - we had a very open and no-nonsense approach to the bug track: we discussed openly about the bugs. It didn't matters who caused the bug, we had an agreement that a bug is a collective mishap - one may had did it, but everybody else had allowed it to happen.

Yeah, not up to the task professionals eventually were reallocated (I don't remember anyone being effectively fired). But whatever - hiring is a risk, what matters is if it worths on the end, and usually it's better to fire one or another under par coworker than let a excellent one go to the competition due inadequate hiring processes. And every hiring process is inadequate by definition.  

But then management changed (we were bought by the competition - TWICE in a year!!). People from overseas started to take decisions on staff that were used to be taken by someone that was looking us in the eye day after day, and was the ultimate responsible for the team's success or failure.

And when the guy taking decisions are not the one responsible for the consequences… You have a rupture on the chain of thrust.

If you are worried that by accepting your share on the mishaps you do it would be used against you on a promotion or handoff decision, you just don't. And when people on a team are used to refuse responsibilities on the borks they do, there's another rupture on the chain of thrust: you can't fully thrust your colleague's works at the risk of being you the one taking the heat.

So you end up solving things on the safer way for you, not the best way for the problem. Good teams under a not so good management usually protect themselves under a development process that would hinder pinpointing individual responsibilities. This works for some time, but then newcomers arrive, and not every newcomer will be ethical and cooperative to the situation. When that happens, it's usual that exactly the best ones choose to leave, and soon you have a bunch of newcomers (some good, some bad) and since no one knowns who's who, everybody ends up being handled as bad. And since the good ones tend to leave,  we have a vicious circle that perpetuates the problem.

The funny thing about all of that is that it happens even when the management is not going to do that nasty things we are afraid of. The problem is, essentially, the rupture on the chain of thrust. We don't know the guys, but hey… Someone else once did something that these new brass is doing now and in the end I got screwed, so it's better to cover my SAS.  

Yeah. Self-fulfilling prophecies. These stuff bites.

Of course, there're a lot more of possible explanations that would fit. But talking about them would start a flame-war around here - we, old farts, are known to have little to no respect for people's egos. What's a Sin nowadays.  

Yeah, I don't want to start anything bad. Just want to know the reasoning behind this change and if this is a bug or not, that's all.

[Lisias]

23 minutes ago, dok_377 said:

Yeah, I don't want to start anything bad. Just want to know the reasoning behind this change and if this is a bug or not, that's all.

It broke expected results on a minor revision. So, yeah. Technically is a bug on my book.

Problem is.. It can be also the easier and "safer" way to close a previous issue - and since on some of that bad scenarios (including the one I talked about) developers are only evaluated by what is being done on the issue he have his name on, there's a chance that they would avoid acknowledging this as a bug (as it had happened in the past).

[MR L A]

2 hours ago, panzer1b said:

Guess im lucky to never have gotten reliant on autostrutting anything (except launch stages on rockets cause i cant be bothered to use normal struts on something i will see exactly 2 minutes before its jettisioned from  payload).

Not sure why you would need struts for a launch vehicle these days anyway... rigid attachment all the way. Unless your designs are more than a little unorthodox... 

[Azimech]

4 hours ago, dok_377 said:

Yeah, I don't know why they changed it. And the worst thing is we don't even know if that's a bug or an intentional change. Squad members seem to ignore those kind of questions for some reason. 

Are you sure about that?

Some high profile builders noticed it and weren't happy about it. Also very vocal. Me included.

3 hours ago, panzer1b said:

Still, i can see how this is a problem for very complex planes, albeit, im pretty sure i prefer the 1.7 version of that plane, the wobbliness is way more "kerbal".

This hurts me. You know I need rigid stuff.

[Klapaucius]

7 hours ago, Yakuzi said:

Do you experience the wing flexing behaviour in 1.7.0 as well? Still on 1.6.1 myself.

I don't know.  I have the 1.6.1 saves that I use for planet packs until Kopernicus gets updated. My 1.7 autoupdated to 1.7.1, so I don't have a 1.7 version to revert to. If you have access to one, the craft is on KerbalX.  Feel free to download and test it.

https://kerbalx.com/Klapaucius/Gogol

[Lisias]

22 minutes ago, Azimech said:

Some high profile builders noticed it and weren't happy about it. Also very vocal. Me included.

Sometimes I think the developers should spend more time playing the game than trying to fix things. That would allow them to get the feeling to minimize breaking things to be fixed at first place.  

Eat your own dogfood.

[dok_377]

27 minutes ago, Azimech said:

Are you sure about that?

Some high profile builders noticed it and weren't happy about it. Also very vocal. Me included.

This hurts me. You know I need rigid stuff.

We might not like it, but it may be intentional, who knows. I tried asking JPL during EJ's stream, but never recieved an answer. I certainly don't like this change and changed my feedback on the tracker to a bug report.

Edited June 2, 2019 by dok_377

[Azimech]

1 minute ago, Lisias said:

Sometimes I think the developers should spend more time playing the game than trying to fix things. That would allow them to get the feeling to minimize breaking things to be fixed at first place.  

Eat your own dogfood.

What makes you think they don't this?
I've made mods myself and playtesting for weeks is a normal thing to do.

But ... there are more styles to play than there are users ... a dev can only anticipate so much.

[Klapaucius]

5 hours ago, Lisias said:

I had read in another thread that renaming the craft fixed something similar.

That sounded like sonsense to me, but I remember that now there're ".loadmeta" files for every craft on your save. So, perhaps, it's a problem on a new loadmeta format being expected on a old loadmeta.

Delete the "loadmeta" for your craft and see what happens. If this doesn't works, rename the craft and try again (and now I will be stumped).

Unfortunately, no luck. I deleted the craft and .loadmeta file and redownloaded it manually from KerbalX. I pasted two versions. One normal and one that I renamed using a text editor. No change for either craft.

1 hour ago, MR L A said:

Not sure why you would need struts for a launch vehicle these days anyway... rigid attachment all the way. Unless your designs are more than a little unorthodox... 

Rigid attachment generally does not work well on planes.  Heavier ones need a bit of give on landing or they just shatter. I almost never use rigid attachment for that reason.

[Gargamel]

3 minutes ago, Klapaucius said:

Unfortunately, no luck. I deleted the craft and .loadmeta file and redownloaded it manually from KerbalX. I pasted two versions. One normal and one that I renamed using a text editor. No change for either craft.

Try a clean install and then build the plane from scratch.  See if it still wobbles.   It might be the importing of existing designs, or it might be in the new code.

[Lisias]

Just now, Azimech said:

What makes you think they don't this?

Changing the behaviour  of the autostruts.

I'm a player since 1.4.0, about a year and a half - and I would not break autostrut this way - I spent a lot of time experimenting with the different types of auostrut to know that changing the behaviour this way would break heavier things. I didn't even considered the hypothesis, so way out of the line it would be to me to do that.

I would add a new autostrut mod : "non symmetric grandparent" or something.

I think I know why they did it. If you use GrandParent autostrut over a robotic part, you weld the moving part. But that I fixed by not using autostrut to parent on the parts connected to the roboti part! And yes, this is something that Infernal Robotics users should be aware for some time now.

Autostruting to root would do the same, by the way.

[Azimech]

12 minutes ago, dok_377 said:

We might not like it, but it may be intentional, who knows. I tried asking JPL during EJ's stream, but never recieved an answer. I certainly don't like this change and changed my feedback on the tracker to a bug report.

Keep reporting. And I'm out of likes today. I was in EJ's stream as well.

1 minute ago, Gargamel said:

Try a clean install and then build the plane from scratch.  See if it still wobbles.   It might be the importing of existing designs, or it might be in the new code.

In any case, this is not acceptable.

[Gargamel]

1 minute ago, Azimech said:

In any case, this is not acceptable.

Understandable, but at this point, we have identified an issue, and we need to narrow down it's root cause.   Only way the devs can get around to fixing it. 

[Klapaucius]

8 minutes ago, Gargamel said:

Try a clean install and then build the plane from scratch.  See if it still wobbles.   It might be the importing of existing designs, or it might be in the new code.

Ugh, if that is the solution for my 60-something craft on KerbalX, all of which I updated to 1.6 just recently and many of which have over 100 parts, then I'm going to be spending a of time on the older KSP.  What I can do is see if I can build something simpler on the same principle in 1.6.1 and reproduce the problem. Then I can go from there.

 

But...I came across this problem whilst trying to help another player who is new to planes-and was experiencing wing flex.  I'm pretty sure he/she is on the new version.  The poster fixed it with actual struts, which to my mind is not an acceptable solution for that kind of plane.

 

Edited June 2, 2019 by Klapaucius