PP&TweakScale: wrong part position on craft load in editor

[pellinor0]

Reproduction: make a craft

• start with mk1 pod
• add procedural structural element at the bottom
• add TVR-2160C stackQuadCoupler (the one from 1x1.25m->4x1.25m) at the bottom
• tweak stackQuadCoupler to half size
• save craft
• load craft
  => Now there is a gap between the procedural part and the scaled part. This only happens in the editor, when I launch the craft instead of reloading, everything is fine.

My guess is that the call writeMeshes->Moveattachments->forceUpdate->doTranslation->target.Translate on craft loading does the faulty translation. If I comment out "target.Translate", the quadCoupler stays in the right place on craft loading.

My understanding is that the part positions in the craft file do not need to be changed on load. Only the nodes need to be moved because they are not saved with the craft file.

So my suggestion is to not move child parts on craft load, but trust the position in the craft file. This might also be connected to #103.

More details and analysis here:
http://forum.kerbalspaceprogram.com/threads/112693-0-90-TweakScale-v1-52-1%28Mar-10%29-Fix-for-PartCost-bug?p=1831496&viewfull=1#post1831496

[ItMustBeACamel]

This is fixed with the current release

[svm420]

Alright issue with Pparts and tweakscale is still present.

Place a cylinder tank and an engine under it.
Tweak the engine size
Save craft
Reload and right click or tweak tank diameter. This cause the engine to be separated from the tank and must be re attached to the tank.

Place a non cylinder tank, such as smooth cone, and an engine under
Tweak engine size
Save craft
Reload and the engine will have separated.

Seem the issue is most present on non cylinder parts. However you still get the glitch somewhat following the steps I first listed on cylindrical tanks.

Also would be really awesome if the github had the plugin available and updated when you update your source. This would allow more testers to check new changes before a full update. Thanks!

[ItMustBeACamel]

I still can not confirm.

In order to find the bug I need exact reproduction steps. The issue is, if I can not reproduce the problem and there is only one person reporting, I will not spend hours finding it but rather do something productive (like fixing bugs I have already confirmed or implementing new features).

Don't get me wrong I really appreciate your report but I need more and more detailed information to help you.

• Which PP Version do you use? is it the most recent?
• Which TweakScaleVersion do you use? Is it the most recent?
• Can you reliably reproduce the bug?
• A cylinder tank? Which diameter and length?
• An engine? Which engine? Tweak it to which size?

logs, as always, also might help.

[svm420]

Latest Pparts and latest tweakscale and it is reliably reproduced. Size doesn't matter just shape matters happens with any part that is tweakscaled.

Exact steps

1. Place mk1 pod
   2.a Place PLiquidTank
   2.b Change shape to any NON cylinder
   3 Place ANY part that can be tweakscaled on bottom tank node.
2. Tweakscale the part to any size except default
3. Save craft
4. Reload craft part is now shifted.

Seems to only happen with tanks if the tank itself is NOT the root part. I was unable to produce the bug when I did not use a part before the tank i.e. the mk1 pod. It however will happen if the root part is a SRB i.e. switch mk1 pod for Ppart srb and change shape to cone and attach a tweakscaled part, of any type, to the bottom node, then follow steps 2-6 exactly. Both of the tweakscaled parts will be shifted.

This was a fresh install latest TS and PPs only other mod was Malahs quick search and vens stock revamp. Neither have any effect on the glitch reproduction. Logs! MM cache!

[ItMustBeACamel]

http://imgur.com/a/DAO8W

Tested with PP 1.1.1 and TweakScale v2.1

Only odd thing I found was that your logfile indicates that you are using ModuleManager 2.6.4 while the most recent MM release is 2.6.3. It might not be the cause of the issue, but generally please make sure to not use any experimental/unstable/inofficial plugins before posting bugs.

[svm420]

I am in complete disbelief I have this reproducible 100% of the time. How can it only be me? Was the mk1 pod your root part, and you tweak scale the engine? Did you try with a Ppart SRB in place of the tank still conical? I even tried again fresh downloads and MM 2.6.3,a nd I still have it happen 100% of the time. I am on 64 bit linux could that be it? I just can not believe you can't reproduce this.

[ItMustBeACamel]

I did it exactly like you described... Odd. Might be some kind of linux kink....although I hope it isn't because I do not have a linux machine ready for testing :/

[NathanKell]

For the record, the only change in MM 2.6.4 is that all MM error messages start the same so they can be found in the log more easily. :)

[svm420]

Wanted to update to say this has to be a Linux/64 bit/Mono issue. I did a fresh install this week of Linux Mint 17.1 from Ubuntu and still can replicate this issue 100% of the time the same steps as before. So please do what you can to get a way to test/develop in that environment. This mod is so close to perfect, but this issue is such a pain on aircraft and rockets throws off any work done to balance mass and thrust. Thank you for your continued work!

[pellinor0]

In pellinor0/TweakScale#26, taleteller provided a good example craft that reproduces the bug for me (KSP 1.1.1, PP1.2, TweakScale 2.2.8.1 on windows). So it is not a linux issue, and also happens with cylinders.

It requires the following things for me:

• the parent is a procedural part
• the child is TweakScaled.
  By re-rooting the example craft, I can make the bug happen on a different joint. If the scaled part is the root is does not happen at all.

My understanding is still that PP moves parts on vessel load, while TS doesn't. What I haven't understood is why a part would need to move other parts while loading a vessel.

The error is roughly equal to the distance TweakScale moves the attachment node. iirc the scaling in the editor happens in onStart, so it could be a timing problem netween the two mods. (i.e. TS moves the node after PP has memorized its position, then PP moves the node back by moving the child part)

[qepsilonp]

I can also reproduce the bug reliably and I'm using Windows 10. But unlike Pelli it doesn't happen with Cylinders I have only tested it with cylinders and smooth cones and smooth cones are the once that make the bug happen for me.

Also specifically I'm using the shielded tanks but I don't see how that would effect anything but w.e. But just as Pelli said if you change the scaled part to the root part the bug doesn't happen.

Edit; I just figured out a work around so my passion for filtering through all the different configs to see which once do cause the problem has ebbed.

Just put a non scaled non procedural part in-between the scaled part and the procedural part and the bug no long happens then you can just use the offset/move tool to hide the part. As long as you use a light part it wont effect the vessel much apart from making it a little more flimsy but exactly how flimsy will depend on you're choice of connecting part's obviously.

While I may not of helped fix the part I assume a workaround is the next best thing.

[doubleuudude]

This is still an issue (Windows 7 and 10, KSP 1.2.2). Documented reproduction steps and included images on the forum post:
http://forum.kerbalspaceprogram.com/index.php?/topic/96402-113-procedural-parts-parts-the-way-you-want-em-v125-july-3/&do=findComment&comment=2980301
If no one is currently looking at this I'd be happy to take a peep. Do we have any information on what the possible cause might be?

[pellinor0]

For the record: new link to the post from the OP
http://forum.kerbalspaceprogram.com/index.php?/topic/101540-122-tweakscale-v234jan-23/&page=3#comment-1816132

[Soimn]

I am running realism overhaul for KSP 1.2.2 with procedural parts and countless other mods, and the aforementioned problem occurs every time I load a craft. Especially with interstage decouplers.
I have found that right clicking the misplaced parts and updating/changing one of their values seems to fix the misplacement and making a script that updates the parts's values after load would probably prevent further issues.

I will update this comment if i manage to write a script that fixes the problem.