pellinor

Update: TweakScale-v2.3.9 * fix interaction with stock ModulePartVariants

Update: TweakScale-v2.3.8 recompile for KSP 1.4 a few patches for new parts Known issues: The new stock texture switch messes up attachment nodes on scaled parts. First switching texture and then scaling seems to work.

Usually dev is newer and will be merged to master every time I do a release. I just noted that the "dev" label currently points to an old commit in the github repo, that's an oversight and I'll clean it up (in the next few days).

If my memory is correct, I once did something so that the scale is not checked on load. So in the editor the scale probably loads like it was in the craft file, and jumps to the nearest legal value once you open a part's right click menu. But better test this if you want to be sure.

Just "resize stuff by X", and all non-persistent values are scaled each time the part is loaded into a scene, according to what the configs say at that time. So each time a craft is loaded it would look up the exponent for EC and apply it to the value from the part's prefab.

The capacitor logic probably has its own part module. You could iterate over all parts of the ship and check which ones have that module. To find the name of the capacitor module, check the config files of those parts.

One solution for the wobbliness problem would be to allow multiple servos in one part. So a whole arm would be one part that holds a kinematic chain with several elements. Each degree of freedom in that chain is governed by a servo module. I think Sirkut (the creator of IR) had an unfinished prototype for this. I only remember a screenshot, at a time when we did the last code overhaul and he was not very active anymore. Roverdude's Konstruction pieces are also quite close to this, just with a simpler interface and without the ability to move attached parts. Since this would need quite a reorganisation of the code (separating the servo from the kinematics-logic), it might fit here.

These should also have an @ (or %) in front, since you want to change the existing values and not add extra ones.

I'm not very active anymore, barely keeping the lights on. Currently I don't have plans for new features in TweakScale, but would be happy about contributions.

Yes, the simplest way is to delete the patches folder in Gamedata/TweakScale. (The configs in GameData/TweakScale should stay)

This is probably not a coordinate system issue. Target:Portfacing gives you a direction (i.e. a full reference frame). By taking the ForeVector and then converting that to a direction again, you first throw away the roll information and then replace it by something random (because the mapping from a vector to a reference frame is not unique). You probably want to lock steering to something like LookDirUp(-PortFacing:ForeVector, PortFacing:UpVector).

No it isn't. You are on a recent version (using KSP 1.3+)? I'd expect to see this only in some older versions. In any case it should not mean any harm.

Here is a piece of code that worked for me (the gMyPort variable points to a part, which can be a dockingport or a claw): https://github.com/pellinor0/kOS-MissionFramework/blob/master/Script/librdv.ks#L240-L251 It looks like you can only access the "control from here" action from the partModule of the claw. kOS seems to do some special thing for docking ports that it does not do for the claw. Edit: the relevant part is if (dockPart:TypeName="Part"){ // special treatment for claw dockPart:GetModule("ModuleGrappleNode"):DoEvent("Control from here"). } else { dockPart:ControlFrom. }

This is where the "20 meters" (or "400%") max scale is configured. You can edit those files directly or (better) use MM. Adding values to a ScaleFactors lists gives you additional intervals for the tweakable. https://github.com/pellinor0/TweakScale/blob/master/GameData/TweakScale/DefaultScales.cfg#L18

https://github.com/pellinor0/TweakScale/blob/master/GameData/TweakScale/ScaleExponents.cfg#L73-L78 It looks like TweakScale currently does not treat parachutes different in any way. They probably behave like any other part, where drag is scaled by scaling some "drag cube" object that is part of (stock) KSP.

Any .cfg file inside the Gamedata folder will do. It is useful to make a new directory for your own patches so you find them again, and don't lose them when updating mods. That should be switched by leftCtrl-k. The effect is that when you change the scale a part, it will try to apply the same change to its child parts. This works recursively so changes are propagated as long as the parts inbetween can be scaled that way.

Ok so you want to orient your shuttle such that the burn vector is 15° below the nose. So you have a vector NP and and need an orientation (i.e. not just where the nose should point but also what the "roll" should be). First choose a plane by choosing a vector that is normal to NP. This choice is arbitrary, I usually use Facing:Up, which means the ship will not need to roll). set vUp to VXCL(Facing:UpVector, NP):Normalized. Now calculate a vector 15° from NP, pointing towards vUp. This makes sure NP is 15° away from the nose. set vNose to Facing:ForeVector*cos(15) - v*sin(15). The "roll" part of your orientation makes sure that NP points below the nose, kOS makes this easy with the LookdirUp function. Then the the shuttle is oriented by lock Steering to LookdirUp(vNose, vTmp).

Did he share his kOS scripts anywhere?

Update: v2.3.7 * recompile for KSP 1.3.1 * only complain about negative dry mass if the number is significant

There is also a version file that refers to 1.3.0 specifically, probably that is where CKAN draws its metadata from. I should change that to 1.3.*.

If it only happens at this size it looks more like a precision problem to me, and not like a bad mod interaction. I think TweakScale should only print the error if the value is significantly negative (will change that for the next version). [edit: somehow sent the post too early]

Update: TweakScale-v2.3.6 * recompile for KSP 1.3 * lots of player-submitted patches (thanks eberkain, mikeloeven, OliverPA77) * set SRB thrust exponent to 3 (so both TWR and burntime are preserved now) * added a few null checks * scaling support for resource lists (for drills and converters) * Fix: don't scale mass if the part has a MFT module * TWEAKSCALEEXPONENTS should now affect not only the mentioned module but also derived modules (e.g. the exponent for ModuleRCS also applies for ModuleRCSFX) Thanks for the hints, and sorry to keep you waiting!

Maybe that brown color is not used anywhere else? Also the saturation stands out. To me it gives the impression of a stock craft with wheels from USI attached.

To cope with oscillations, you could either wait until both the angle and the angular velocity (Ship:AngularVel) are small, or fiddle with the PID parameters in the SteeringManager structure.

This value should only tell the UI what the unscaled part size is called. So if you set 1.25 you should still get the unscaled part, and the UI should show "1.25" (in the case of the surface scaletype). I think I did also make sure that saved crafts would survive a change of defaultScale. I am only aware of issues if defaultScale is not a legal value, for example if defaultScale=1 and the range is from 10-400[%]. The the UI will jump to the nearest legal value (in this case 10), and the part will be huge. Or the other extreme: with type=surface and defaultScale=100 the part will seem to vanish because the max allowed scale of that type is 4. I don't see anything wrong with that particular part patch. Generally it should be perfectly safe to add and remove a TweakScale module from an unscaled part. The only thing I had happen for custom patches is the effect from above with defaultScale outside of the scaling range.