pellinor

Update: [.zip] v2.2.5 * recompile for KSP 1.0.5 * update MM * patches for the new parts I am still using the old KspApiExtensions, so far everything seems to work. Happy launching, and please complain if you find any new bugs! - - - Updated - - - I'll have a look at near future construction. Since much of NFT is already supported this would make a good addition.

The public bugtracker looks pretty much like a one way street to me. People can report bugs but there is no information flow in the other direction. Looking at the closed issues, I find only duplicates and rejected reports.

With this import script: http://forum.kerbalspaceprogram.com/threads/111483 Esinohio helped me with a few parts (like getting the solar panels in the extended state).

Short version: you can't. The TweakScale UI always starts at the size of the original part. DefaultScale is just a UI value that is used to display rescale factors in an intuitive way ("Which scale should the UI use to describe the original part?"). So if you set defaultScale to 3.5m, you should still get the original size in the editor. Just the TweakScale UI should show "3.5m". You could do some hacks to get what you want, like setting defaultScale to 50% and the minimum allowed scale to 100%, but I don't think that is a good idea. Better to do what V8jester suggests, preferably with MM patches.

Is there a way to separate the angle-snap setting from offset-snapping? I usually build with the first on and the second off, so I am constantly switching and always end up in the wrong mode.

The release is out! So now AVC (and probably CKAN) should nag everyone to update.

Two additions to the prerelease: * Partial fix for editor mass display not updating * Another patch for scaling of lists. This should fix the trouble with cost of FSFuelSwitch parts. So we are now at version 2.2.4. I plan to do a release on friday, so there is still a bit of time for testing.

Dev update: * Added another patch for scaling of lists. This should fix the trouble with cost of FSFuelSwitch parts.

I added a partial fix for "stock editor mass display not updating correctly".

I had a quick test with auto-parking recoverable boosters, and noted two things: * It would be handy to set autoPark from the editor so it is saved with the craft file. * When switching to a auto-parked piece of debris, auto-unpark does not trigger and the vessel stays frozen in the air. Since the vessel has no control part, I can not un-park it manually. Why this exception for the active vessel? For me the most logical behavior would be to always do both actions (park and unpark) manually or both automatically.

I am not aware that they were broken. When fixing the 3.75m claw I did a quick test grabbing parts at the launchpad and that looked good. I'll check some more with asteroids. Be aware that even the 1.25m claw is not known for its grabbing reliability (and it definitely has a max speed, I'd guess something in the order of 1m/s). - - - Updated - - - The easiest is to look into the TweakScale/patches folder and copy from there. Find a part that is similar to yours (like "another 2.5m engine" or "a structural part that is scaled in %") and use its patch as a template.

PreRelease v2.2.2 [.zip] Since we haven't had a release for too long, I promoted the dev version to a prerelease. As usual, you only need the GameData Folder of the zip. Please complain if there are any new issues! I'll wait a few days before putting it up on KerbalStuff and Curse.

PreRelease v2.2.2 [.zip] Since we haven't had a release for too long, I promoted the dev version to a prerelease. As usual, you only need the GameData Folder of the zip. Please complain if there are any new issues! I'll wait a few days before putting it up on KerbalStuff and Curse. ChangeLog since v2.2.1 * update of NFT patches * Fix scaling of resource lists * support for a few missing stock parts * partial support for a few other mods * stock radiator support * Scale ImpactRange for stock drill modules (this is what determines if the drill has ground contact or not) * scale captureRange for claw (this should fix 3.75m claws not grappling) * removed brakingTorque exponent (not needed and breaks stock tweakable) * Removed MM switch for scaleable crew pods * new file Examples.cfg with frequently used custom patches

next dev update: * Removed the MM switch for scaleable crew pods. The mechanic was complicated and not extendable, and it is done simpler with a more explicit custom patch: @PART[*]:HAS[#CrewCapacity[*],~CrewCapacity[0]]:FINAL { !MODULE[TweakScale] {} } * new file Examples.cfg with frequently used custom patches like the above "don't scale crew pods". This changes the default behavior for crew pods scaling back to "allowed". As already discussed, my main motivation is that accidentally reverting this to default (e.g. when updating the mod) should not break peoples saves/crafts.

It is more like "parts whose makers do not maintain their own tweakscale configs". Generally making those patches needs more knowledge about TweakScale than about the other mod. This is why most of them are distributed with TweakScale. A version without patches sounds doable as a CKAN definition, but I don't think doing every release twice is a good idea. I'm working on a couple of example patches like "only scale IR parts", maybe this will also help. - - - Updated - - - Just want to mention that the scale and exponent definitions are outside of the patches folder. So you can safely delete it without breaking TweakScale configs packaged with other mods.

small dev update: * removed brakeTorque exponent for landing gear (not needed and breaks the stock tweakable)

Argh, of course! How could I forget about that? Thanks for the correction.

This looks more and more like a stock problem to me: http://imgur.com/AHBMzEx This is from 1.0.4 stock (linux-64), sandbox, first time in the VAB. The middle is an empty tank. The mass of the cockpit is 1t, the rapier at the other end weighs 2t, so the CoM can not be right. Another observation: when I attach the rapier to the empty tank the CoM barely moves. When attaching the cockpit, it jumps a lot more. So the mass of those two parts does not match their "weight" in the CoM calculation. When I launch the craft it tips to the left, so the CoM display is in agreement with the physics engine. So something with the physics is wrong? Edit: false alarm, I forgot about the new engine CoM placement.

The claw has a "captureRange" value, scaling this seems to fix it. I added the exponent to the dev version. However I am not sure if the grappling node is scaled correctly. I would expect it to be always size1 after grappling, and it might be scaled correctly after a reload (haven't tested this yet). - - - Updated - - - It may change on docking since the merged vessel only has one root part. I've seen the bug vanish this way. But there is no simple way for telling KSP which part should be root. - - - Updated - - - Should be fixed in the dev version.

See this bug report on the KSP bug tracker. It contains a good description of the issue, and even links a mod to solve it. The same behavior is planned as a feature for preciseNode.

Update: I did the prototype and put up a feature request in the precise node thread.

I recently found the intuitiveManeuvers mod by TechnocratiK which changes the stock maneuver node gizmo to use the post-maneuver reference frame. The following bug report for KSP explains the issue better than I can, and also links the mod: http://bugs.kerbalspaceprogram.com/issues/3953 Since I am totally in love with that mod, I made a prototype implementation to make the +/- buttons in preciseNode behave the same way. I also changed the display to two fractional digits for better readability, avoiding those typical "5.67890" entries with an invisible "e-11" at the end. Github (the intuitiveManeuvers and numberDisplay branches) .Zip (you only need preciseNode.dll) For example, the "Normal+100" button is now interpreted as "burn 100m/s while following the normal+ marker". The consequence is that the resulting node preserves the magnitude of the velocity and only changes the orbital plane. Improvements over the current system: * Normal input does not mess up the AP/PE or orbit eccentricity. So a plane change only needs the 'normal' buttons. * Likewise, prograde/radial input preserves the orbital plane (in stock they change the inclination if the node already has a normal component). * Input is actually applied in the direction indicated by the gizmo handles (see the linked bug report for a screenshot why stock does not do this). Downside * Pressing one +/- button may change several components on the node, and lead to odd amounts in the display. This might confuse people at first glance. Since I am convinced that the post-maneuver reference frame is a more natural way of tweaking maneuver nodes, I would like to see it as a feature in preciseNode. The prototype linked above just changes the behavior. I did not open a pull request because the final implementation should probably contain a switch to revert to the current behavior. @Blizzy, would you include this as a feature?

small dev update: * added some patches for several mods, mainly engines (thanks Glidas) This affects OPT, AtomicAge, MarkIVSystems, mk2Expansion, mk3HypersonicSystems. As for many mods I don't regularly use, the patches are neither complete nor well-tested. If something is missing, the best thing is to write your own patches and post them here. - - - Updated - - - Different topic, I'm still thinking about this switch for scaling crewed parts. What about instead including a file with example patches that people just need to uncomment to use? Like * forbid scaling of crewed parts * only allow scaling of IR parts * more general: forbid scaling of parts that [do not] have a certain module * add a tweakscale module to everything [use at own risk]

I'd also love to see some kind of wind tunnel mod, maybe an extension of RCS build aid? This kind of stuff is quite tedious to test in a repeatable way. When 1.0 came out TweakScale did not scale drag at all, and it took quite long for people to even notice.

To my current knowledge this is a known bug in KSP, so you'd need to knock on Squad's door for a fix.