pellinor

Here are two reference images for wheels and legs, shrunk and enlarged by writing the member localScale of the part's "model" transform: http://imgur.com/a/cxMsU http://imgur.com/a/PHmFS It looks like something more needs to be done to get the wheel collider and the suspension limits right. When rolling, the rotation speed is also wrong (probably from using a wrong wheel radius). This behavior broke with the switch to unity 5 and the new wheel modules. When using the config value "rescaleFactor" for scaling, KSP seems to do these things right. The fields mentioned in the part.cfg are all unchanged for such a wheel, and I couldn't get the physical behavior right by tweaking them. Can anyone tell what needs to be done to bring those wheels to the right scale? PS: poking around I found that ModuleWheelBase::Wheel seems to always be null (checked OnLoad and OnStart), isn't this meant to lead to the inner workings of the wheel system?

Not yet, planned for the next release

A good start is to search for "exception" in the logfile (and there are many of them). These are problems that could cause collateral damage elsewhere. First thing I would try is to test without the mods mentioned in the exceptions (like partAngleDisplay). I didn't see any TweakScale related problem in the log.

I'm not too attached to that value, and don't really use scaled cargo bays myself. Any more opinions about the mass scaling of cargo bays?

Do you really need an active control or would it be enough if the object is aerodynamically stable (supposing an atmosphere)? If you drop a dart from space it should always orient itself along the airstream (hopefully before burning up, so you'd need the right amount of stability).

As far as I remember the cargo bays are tweaked to be consistent with stock balance (comparing mk2 and mk3). I'd say anything between 2 and 3 makes sense (so the wall thickness may or may not scale with the part). For changing you can change the scaletypes of those parts (stack -> stack_square).

Dev update: * move workaround for UI_ScaleEdit bug into the plugin (so it works for all scaletypes) * tweak some exponents and remove obsolete ones * compile against KSP1.2.0.1523 PS: still needs a recompiled MM to work

Recompiled the dev version. Consider it as unstable. I'll post updates in the dev thread:

Dev update (will not work without a new ModuleManager, so totally untested) * recompile for KSP1.2-prerelease * patches for two new smartParts * refactoring: do things earlier so the prefabPart is in a more consistent state I'll probably not have time to continue this before next week. If someone beats me with a fix: feel free to make pullRequests or post your own forks. Issues/todo: * no updated moduleManager available (or am I not looking in the right place?) * autoscale is broken (missing method, commented out) * upgrading mechanic will likely need support. No idea yet what is needed * check wheels and their exponents * any new parts to add?

I struggle to even find a different example or metaphor to compare this to in order to highlight how nonsensical this notion is. "You know a game is no good when it comes with a modding interface"

This. Things are pretty similar with bug reports: no one likes a sloppy "this doesn't work" from from that guy with a huge mod list. However well written reports are worth their weight in gold. The same is true for feature requests if they make sense, are well thought out and placed at a mod where they fit well.

Right, games are a product like any other, made to satisfy certain requirements. Industry demands quality, and is willing to pay for it. The majority of players prefer games to be cheap, and to be available as soon as possible.

Could someone confirm this feedback issue: http://bugs.kerbalspaceprogram.com/issues/9330 UI_ScaleEdit is the tweakable used in continuous scaling ("freeScale=true"). When checking with the current TweakScale version, you can only test the lower end because of the other stock issue (#9743). The official process says that feedback issues should be set to "confirmed" by a second person to show that there is more than one guy interested.

Fuel Wings bundles MFT, so this is the same bug as already discussed.

I can confirm that TweakScale+MFT can mess up part mass. MFT seems to mirror the behavior of the TweakScale module, so any mass change due to scaling is applied twice. So shrinked parts go below zero and enlarged ones get heavier than they should. Edit: it looks like I can work around this by not reporting my moduleMass if an MFT module is present. Not the cleanest way but it should work.

Known issue: http://bugs.kerbalspaceprogram.com/issues/9743, doesn't look like it has gotten any attention yet.

I'd like to execute code on the prefab before parts are copied from it. In my tests with the TweakScale partModule it looks like OnLoad is not called in the editor. I put a simple debug output at the start of the method and it appears in flight (so I guess that OnLoad is declared correctly) but not in the editor. Am I doing something wrong? Source: https://github.com/pellinor0/TweakScale/blob/master/Scale.cs The code already postpones its setup to OnStart when in the editor, so this behavior is probably not new. Edit: Found it, earlier in the log than expected. And the one from the flight scene is probably for loading the persistent data from the craft file. Slowly things start to make sense...

Is that speculation or did you test it? SMURFF sounds very unlikely because it just changes config values. I should have said "two mods which manipulate mass at runtime". The configured mass (after MM is done with it) should make no difference as long as it is positive.

Seems I can't properly extract that .rar file, will check on a windows system later. Looks like you and @raxo2222 have the same problem, any chance it appeared after updating or adding some mod? It is very likely an interaction issue of at least two mods who manipulate part mass.

Could you narrow that down a bit, i.e. check if you can reproduce it with less mods (ideally that would be only TweakScale + one other)? The last time that sort of bug appeared it was a bad interaction with FAR (and should have been fixed some time ago in FAR). Not sure how you know it needs MFT tanks at all. Not possible yet, I still have to do a config interface for that.

Sorry, TweakScale has always treated all dimensions equally. I think the model transform of a part allows non-isotropic scaling. However, including it in TweakScale would introduce a lot of complications (starting with UI and ending with an unknown amount of connections to other mods). Also there are very few models that look reasonable when distorted that way. Anything interesting in your log? First look for "exception" and then for "tweakscale".

So for some reason it refuses to load the dll. No real idea how to continue from here. The missing modules are a consequence of this, there is nothing to apply if KSP does not know the partModule. Actually this is what most people expect when they scale a part. What you are looking for is called chain-scaling (toggled with leftCtrl+K). Had to look this up in the code because it is a feature I never used. This propagates a scale change to child parts (recursively so scaling the root part will try to scale the whole vessel).

I didn't really test scaled wheels because I couldn't even get them touch the floor like wheels should (scaled wheels tend to either float or clip into the floor). Since I got no answer from the devs and wheels will again change significantly in the next version, I'm postponing this. Of course I'm always open for pull requests if someone finds a solution that works better than what we have now.

That should work. Just make sure it also works if TweakScale is not present (it might throw errors/warnings). The clean way would be to add the TweakScale module via MM with :NEEDS[TweakScale].

Then it should work. Maybe something helpful in your log (like the .dll refuses to load for some reason)? Do the TweakScale modules appear in a saved craft file (if not the moduleManager patches are not applied correctly)?