pellinor

Fix for the part cost issue is up! Please grab the new version v1.52.1 ! Stupid error that should not survive proper testing. I really miss an automated testsuite for KSP.

Fix is up! Please grab the new version v1.52.1 !

Of course, node size scales linearly, so the default stack sizes should behave just as you would expect.

Feel free. If there are parts missing from the config files bundled with TweakScale, I would prefer to add them there. Just tell me what is missing. This mod was missing some attention for quite a while, so it is probably not up to date with all the supported mods. By the way, I don't consider scaling of crew parts as cheaty from a gameplay perspective. The crew capacity scales too, so a scaled down one man pod has capacity zero, but still won't provide control without a kerbal. And I do like the added detail when scaling down fuel tanks.

Yes, I am developing on linux. Haven't started the windows version for weeks (i prefer it for playing though, because of antialiasing).

Honestly, I've never used the tech limitations myself, so I do not have much feeling for how it should be. My career game usually develops from stock at the beginning to more and more mods towards the end. TweakScale comes into play when docking is available and I'd like stuff like very weak RCS thrusters. I like the old system for its simplicity. scaleFactors may have a tech requirement attached. In the editor, the scaleFactors list is simply filtered by removing the ones which are not researched. Your system has the advantage that you can not end up with a part that is forbidden to have its defaultScale. For the moment I'd like to avoid changing things until there is a need for change and the new version is clearly better (just be aware that such a change would break existing configs). Actually I have no idea how many people or mods use this system at all. (For the old free scaling feature my impression was that it was hardly used at all because of the bad usability)

Now it should, since I brought it to the main branch where it looks for updates. I'll have to look into the download thing. The MM release thread lists 2.5.10 as the current official release, is there some other place to look? Haven't seen anyting like this yet. Do you have more info? Your output log would help, errors and exceptions usually come with a call stack there. Has anyone else had this problem? Have you tested the new freescale interface? The slider increment is meant to be large enough so that you can easily reach the exact intermediate sizes like 1.875m. I'd like to avoid an extra main size that costs usability for everyone else. I haven't looked into interactions with tweakable everything yet. I think there was some code specifically for this, but I am not familiar with that part of TweakScale yet.

Sure, and there is no need to create new parts. The simplest way is to add larger scaleFactors to IR's scaleTypes with a MM config (so you replace the 'scaleFactors' list with a new list that contains the old ones plus the ones you want to add). This will make both the parts and their nodes bigger, so all is fine from TweakScale's side. This is a config I used in one of my old saves for adding a smaller stack size: @SCALETYPE[stack]:Final { @scaleFactors = 0.3125, 0.625, 1.25, 2.5, 3.75, 5.0 @scaleNames = 31cm, 62.5cm, 1.25m, 2.5m, 3.75m, 5m } However, I heard that IR tends to have problems with very large nodes, and I suspect that this has to do with the instant acceleration that IR does. Just like in real life, heavy things do not like to have their speed changed instantly (simple example: driving a car against a brick wall). It happens that this is also an area where I am tinkering at the moment.

Could you close the old TweakScale release thread, and change the 'new thread' link in the OP to the new release thread? (the link currently points to the new dev thread, which will confuse people)

TweakScale lets you change the size of a part. Not just that, but it will figure out how much fuel is in the resized part. And if it's an engine, it will become more powerful by scaling it bigger, or weaker by scaling it smaller. Download: SpaceDock / Curse Source: Github A bit of Documentation Latest dev version (WIP stuff, might contain bees) See also the development thread for the latest unreleased tinkering. TweakScale was originally developed by Goodspeed and Biotronic. [original release thread] Source: Github License: WTFPL Known issues * stock upgrade mechanic not supported yet * CrewCapacity: removed seats in the editor sometimes reappear * CrewCapacity: launch dialog of the pad/runway shows unscaled seats [stock limitation] * particle effects are not scaled [stock limitation] * unloaded relay antennas use their unscaled range [stock limitation] * (see also https://github.com/pellinor0/TweakScale/issues) Changelog v2.3.12 * configs for new parts * fix for exceptions * fix for solar panels * recompile for KSP 1.4.2 Please add TweakScale to your mod! Features How to use

Since noone complained, I published the 1.52 release on Kerbalstuff and Curse. There is also a New Release Thread! so that I own the OP for editing. Please continue discussions and questions about the released versions there.

The first place I would look is search your output.log for exceptions. This sounds like something goes wrong when ksp wants to draw the right click menu. If this happens you'll see errors in the alt-f2 logging window, and find more details in the KSP_Data\output_log.txt file.

Thanks for your interest! I'll sort through the IR code myself first, make a version that people can test, and do some GUI experiments (since this is the only way to test the interpolation). When things get stable we will see how much of my changes you want to adopt.

New dev Version is up!

New dev version is up! The scaleFactors now define the slider intervals, so they work in exactly the same way for discrete and continuous scaletypes. If you ignore the slider, the buttons of the free tweakable now have the same behavior as the discrete one. A side effect of this change is that tech requirements now also work for free scaling. If you set a tech requirement that is not researched yet, some of the scaleFactors are filtered from the list and you can freely scale between the remaining ones. MinScale and MaxScale are obsolete now (I still look for them if there are no scaleFactors defined), as well as incrementLarge and incrementSmall. incrementSlide can be given as a single value or as a list, allowing for different step sizes for different intervals. Sorry for removing stuff that I just introduced in 1.50! I am convinced that the new tweakable allows a better way of configuration with less room for confusion (now all scale types get their limits from the same list). This version is labeled as 1.52, but it is still on the dev branch, so AVC will not yet nag everyone to update. Please test this with your favourite mods, and tell me what you think about the usability of the new tweakable! I will do an official release when I know there are no mayor bugs. ChangeLog * New Tweakable with more flexible intervals. * Better handling of incomplete or inconsistent scaling configs. * Vessels now survive a change of defaultScale. * less persistent data (i.e. less spam in craft and save files)

I am not aware of any issues related to TweakScale and air intakes. Your screenshot looks like the exception happens in kerbal engineer. TweakScale only appears in the call stack because it notifies kerbal engineer of a part rescale.

Look into the scaleexponents config file. This is where you find the current behavior, and this file is probably what you want to change (preferably with MM patches instead of editing the file). But check the current values first, the exponents for mass and thrust are not that different, which already surprised a few people (including me). If you want to keep densities constant, mass needs to scale with scale^3. If you also want to keep TWR constant, thrust also needs to scale with scale^3. As I understand, the consensus is that thrust should be more like scale^2, density is not that important, and TweakScale patches should be as generic as possible (otherwise they are a mess to maintain). So the current situation is a compromise between several conflicting things. - - - Updated - - - It should be off by default in the new version. Otherwise there's the hotkeys which also should are persistent as far as I know (they might not save their state correctly if you exit with alt-f4 instead of through the main menu). One thing you can try is to edit the .xml file in the TweakScale/.../plugindata/scale/ folder. This is where those states are saved. If autoscale/chainscale is set to 1, set it to 0. This also works for olderversions of TweakScale.

Of course, the acceleration limit applies to braking as well. This thing is designed to stay within its limits no matter what commands you throw at it. It will slow down on its own when approaching end positions. When given a commandPos closer than the current braking distance, it will overshoot and come back. This is not meant as a patch for a specific part, but as a core piece of IR (provided the current maintainers are interested in it). I would envision a code structure consisting of * A UI layer that creates commands. Ideally, it would let the user create custom buttons or sliders and bind them to commands. This layer does not need to enforce any limits. * The interpolator takes commands and updates positions. This layer takes care of part-specific or user-defined limits, modulo behavior etc. It does not know any of the other objects. * A physics layer that takes the positions and updates part transforms, nodes etc. It knows the part-specific stuff (like the difference between rotation and translation) and provides limits for the other layers.

Hi everyone, I'd like to show a pet project from the last couple of days. After getting stuck with some TweakScale problem, I took a break to play with another thing I always wanted to do: smooth interpolation for IR. The result is a small interpolator class that takes commands in the form "go to position X at speed Y", and takes care of * acceleration limit * speed limit * position limits (for finite movement range) * modulo behavior (for freely rotating axes) So far, I somehow hacked the interpolator into IR for testing. The first tests with a fast rotatron look pretty good: The test rotor takes its time to build up speed, and is still reasonable stable around 1500 deg/s, which is 30deg/frame. With just two float parameters, the commands include all that IR currently offers. They would also be a great interface to other plugins. [cmdPos / cmdVel] x / 0 : stop x / v : move to pos=x at speed 10 x / inf : move to pos=x as fast as you can +-inf / v : move forward/back at speed v +-inf / inf : move forward/back as fast as you can I can't publish a test version yet as the interface is still too bad (all parameters are hardcoded).

A quick status update for everyone, I made a custom tweakable to allow increments of varying size. Moved TweakScale over to it and am very happy about the result. But there's a problem. I used the floatEdit Tweakable from KSPApiExtensions as a template, so the new one is now part of a custom KAE version. So it is not a good idea to give out (a compiled version of) the current dev version until the new tweakable is either * accepted into KSPApiExtensions or * separated from it. At the moment I'm still waiting for an answer about the first, and fail at doing the second. I described the problem here, and would be thankful for any help. The problem seems to be about item-prefab registration in unity.

Starting from the KSPApiExtensions FloatEdit tweakable, I wrote my own tweakable for TweakScale and fail to separate it. The main dependency to KAE are these two lines from UIPartActionsExtended.cs, which somehow lead to the prefab registration. controller.fieldPrefabs.Add(UIPartActionScaleEdit.CreateTemplate()); fieldPrefabTypes.Add(typeof(UI_ScaleEdit)); The first line seems straightforward, since I do not need KAE to reach the controller object. However I do not get what the second one does, other than adding something to a local list that is never used afterwards. I get the following error in the log: So it is missing some sort of registration for the type/prefab. Can anyone tell me how to do this? If it helps, here are the code versions I am talking about (trying to move UIPartActionScaleEdit.cs): https://github.com/pellinor0/TweakScale/tree/dev/ https://github.com/pellinor0/KSPAPIExtensions/ EDIT: Solved! I managed to copy the registration code and sort out the things which should not be done twice.

Still does not occur for me. I can move scaled hinges in both directons, in the editor and on the launchpad.

Any status on this, taniwha, NathanKell? If you are not interested in the class, would you help me separate it from KAE? I just don't get how this item prefab registration works. At the moment I have moved TweakScale to the new tweakable and would like to give out a dev version. Which probably is not a good idea as long as it depends on a custom version of KAE. EDIT: solved. I managed to separate it.

I can not reproduce your issue, tried with the latest release of TweakScale(1.51.1) and IR(0.19.3) from KerbalStuff. So far, I put a hinge on a mk1 pod, moved it, launched, moved it again in both directions. Not seeing any exceptions, and both directions work for me. It might depend on the part though, as IR has several custom scaletypes.

For now, the freescale mode does not know scalefactors (I'm working on a new version of the KAE tweakable to allow this in future versions). In the current version you need to set the increments for the arrow buttons explicitely. I'd recommend something like this: incrementLarge = 1.25 incrementSmall = 0.625 incrementSlide = 0.025