pellinor

Did you measure this? If it is the case then something is not correctly scaled. You can find the intended numbers in ScaleExponents.cfg (everything is meant to go with scale^3, so all ratios are preserved). What you might argue is that 3 is a bit much, because an upscaled reaction wheel often is more torque than you need (and therefore more mass than necessary).

Dev update: * new stock parts' * new TWEAKSCALEBEHAVIOR[Science] which contains a mass exponent of 2 and a cost exponent of -1. I'm still considering making the cost -2. Bad news of the day: the root part bug is still there. With so much changed there is some hope that a new way of coding around it might present itself. If anyone with a bit of unity knowledge would like to help I'd be grateful.

Science parts will get more expensive when scaled down, so you'll be more inclined to stay closer to the original size. I'm not too happy with the scaling of crewed parts in general. Just don't want to break compatibility until there is a solid concept where the balancing will go. I have this possibility in mind to split the mod into a core and two sets of configs, something like a career- and an artist's version. This would fit much better to the different target groups, but would probably need someone other than me to make and maintain the career configs. And it would mean that "stock+tweakScale" is no longer a well-defined description. With reaction wheels I don't see the problem. An enlarged reaction wheel should have the same weight, cost, torque, volume and consumption as several unscaled copies of the same part.

You also find the zip in the latest dev version link on the first page. You only need the "GameData" folder insinde the zip file.

ModuleResourceConverter is treated by scaling "EfficiencyBonus" (you find this sort of info in ScaleExponents.cfg). This was a workaround because those values could not be changed simply by writing ksFields. Side effect is that converters have their efficiency scaled instead of their base values (which leads to an unintuitive efficiency display). Edit: actually I have no idea how a weldment of differently sized parts should work scaling-wise. Because TweakScale does not scale config values. It scales fields inside the part at a time when the part is already alive. And there is only one rescale factor per part.

Dev update: basic recompile for KSP 1.1 Just did a quick test on windows and simple scaling seems to work. Still struggling to get KSP running stably on my dev system (linux).

We do agree about that part, shrinking science stuff should be expensive.

So scaling up would give you a part with the same abilities, just larger, heavier and a lot more expensive? Then why would you ever build such a thing? I think different configs for up- and downscaling would add too much complexity for the benefit it brings. Actually I consider it as quite a good measure of balance that both up- and downscaled parts should have some use in the game. It is also a good safeguard against the very common habit of "just balance my usecase and punish everything else". This sounds like a problem with remote tech. But might also be a general KSP problem with tiny resource nodes. My thought is just that this is a good time to also make probe cores a bit less broken.

Yes, constant mass is somewhat fishy, might also run into physics problems when densities vary too much. Another big point for just changing the cost side is that physical properties are preserved, so the change will not break crafts. This is a good way for a minimal change that at least makes things less broken than they are now. Next question: which parts and which exponent? We are looking for parts with a size-independent gameplay value, that's more or less science and probe cores. Cost exponent should be zero or less, shall we go with -1 for now?

I already have a half done commit for this lying around, and some doubts that a general solution does not exist. For the materials bay it seems reasonable (my plan is to make mass invariant and cost decreases with size). On the other hand, something like a thermometer (which fortunately is not scalable) should not get significantly cheaper because the mass and size are negligible.

kOS contains a part module that does this on a per part basis. For vessels, a similar thing is probably already part of KSP. When you dock two vessels, the game usually remembers the name of the smaller vessel so that it doesn't end up as "Big's Probe" on undocking. My guess is that this is a field in the command PartModule, and it is just not visible in the editor.

Any idea how this is supposed to work, or what it is used for? 3 dimensional size does not simply add up like mass or cost.

Looks like this is the change in build 1209 that needs an adaption of the TweakScale code: http://bugs.kerbalspaceprogram.com/issues/8908

Wow, this is very generous! Actually I'm not that pressed to get the prerelease in my hands, since a working recompile has already appeared and I have enough other things keeping me busy at the moment. And for the future, if Squad plan to do more prereleases like this, I am quite confident that they will get their patcher to work so the store can efficiently distribute small updates. Still many thanks for the appreciation! Posts like this are rare and help a lot for not burning out.

Are you sure about that? Vdot(AngularVelocity, Facing:ForeVector) should return the roll rate. More general, Vdot(AngularVelocity, axis) is the turn rate around an arbitrary axis.

see here: http://forum.kerbalspaceprogram.com/index.php?/topic/135235-11-pre-release-compatible-mods/

Just one idea, are you using a 1.1 compatible modulemanager? Emerald did not update it in his repo.

I don't have Steam access, but there is a recompile by emerald (switching the Tweakable UI_ScaleEdit to the stock version): https://github.com/emerald79/TweakScale Feedback so far is that the basic functionality works but engine thrust scaling is broken.

Sure, help is always appreciated! You probably know best when your configs are ready for release. There probably will be a release with the most obvious fixes shortly after 1.1, and more to follow later when things get stable.

TweakScale carries a lot of configs for mods I don't use and I'm not too familiar with. So it would make my life easier if users of those mods can help collecting what exactly is broken. I mainly expect broken configs because names have changed. Names of parts, new part modules, or properties that have moved from one part module to another. The engine thrust sounds a bit like a change in the past where the game did not read maxThrust anymore but an internal variable 'maxFuelFlow'. Maybe they have changed something along those lines again. I'll have a look when I get the release version. What was the hassle with the others?

This is true for any sort of parts, and for any mod interaction at all. What makes engines special? The only issue I am aware of is particle scaling, which is purely visual and has noting to do with other mods. Please avoid unspecific suggestions that things are buggy and try to bring up something concrete and reproducible.

You can set a boot file which auto-starts on load. If there is a file boot.ks, you can set it as boot file in the editor (the kos parts have a tweakable for this).

Fun with maneuver nodes: have you seen these glitches when the deltaV of the node flickers, and the node jumps between partly-executed states even without thrusting? I think I've also seen this in stock. In kOS the node:Prograde/RadialOut/Normal values seem to be conserved and the node:DeltaV vector does strange things. A discrepancy of 0.1 seems completely normal, but sometimes things really glitch out. Removing the node and readding it in the next frame does not seem to help. Anyone knows what triggers this or how it can be avoided?

* build a craft with a scaled root part (for example a single scaled mk1 pod) * launch * revert to launch (root part should NOT revert its scale to the default) * change camera mode (hotkey "v") a few times (should NOT zoom out excessively and ultimately crash the game)

some ideas in pseudocode, likely with the wrong sign here and there: v1=Facing:ForeVector v2=nodeVector then axis=Vcrs(v1,v2) is the axis of rotation, and therefore the rotational impulse you need. Since rotational impulse behaves as a vector, you can split this into pitch=Vdot(axis,pitchAxis) and yaw=Vdot(axis, yawAxis) (with pitchAxis=Facing:StarVector and yawAxis=Facing:TopVector) which should give you the ratio (and sign) of pitch and yaw that are needed to rotate around this axis. (roll naturally stays out of the equation because rollAxis=v1 and therefore Vdot(axis,rollAxis)=0 )