pellinor

Nice! Thanks for helping out. Discrete scaling is currently not used by the default config. You could test it by setting "freescale=false" in one of the ScaleTypes in DefaultScales.cfg. The only change I am aware of is that the UI_ChooseOption tweakable now comes from KSP instead if KSPApiExt. Other than that I'd expect a few changes in ScaleExponents.cfg where values have moved to a new partModule, or new properties have been created. So keep an eye open for parts whose scaled behavior is not right. Can anyone confirm if the root-part bug is gone?

Sorry, should have crossposted that here. I'll update it as soon as 1.1 is out. TweakScale is an open source project, no official title needed to offer contributions. Even a simple recompile means work, requires code changes and gives others something to play with. So thanks for helping out!

It should be something like LATLNG(latitude,longitude):ALTITUDEPOSITION(altitude) Taken from the example here: https://ksp-kos.github.io/KOS_DOC/math/geocoordinates.html?highlight=latlng#attribute:GEOCOORDINATES:ALTITUDEPOSITION

Vectors live in a coordinate system where the ship is the origin. For example the position (0,0,1) is always 1m from the ship's CoM. I'm not sure about the orientation, that might also change over time. So if you log positions at different times things might get wonky. Have you tried logging latitude, longitude and height? These are safer for storing over time, so I would log the data in this form and convert them to a position when drawing the vectors.

A quick word on the opt-in prerelease: I don't have steam access so an update will have to wait until the full release. If anyone gets a recompile to work, feel free to share it here.

Sure, MFT is special because it is supposed to have its own scaling code and TweakScale is set to not interfere if a MFT module is present in the part.

The code for that interaction is part of MFT, and currently not part of the release. I hope we will get it back for 1.1. You can not fix this with a MM patch.

I'm having an issue with the warp display: I regularly come to a state where the display is stuck in "rails" mode (1x) while physics warp is active. In this state, even shutting down the KOS core and manually resetting the warp does not help. So it might be a KSP issue. Is this known? I haven't found any reference for it, the closest is an old kOS issue where warp behavior would be stuck in physics mode.

KSP still breaks camera mode switching when the root part is scaled, and the bug can still be reproduced without TweakScale (via the "rescaleFactor" config value). Following one of the last devnotes, the issue should be fixed in KSP1.1. Honestly, I ran out of ideas how to code around it, as did my predecessor more than a year ago.

// function can not be compiled function lockSteering { parameter x. lock Steering to x(). } // this part can be compiled lock st001 to Heading(...). lockSteering(st001@). The new delegates allow for a nice workaround to the problem of compiling Steering/Throttle locks. This works as long as each of the compiled locks has a unique name (st001, st002, ...). This saved me a ton of loading time for scripts that could not be compiled before!

I don't use KW myself, so most likely the config is out of date. I'll have a look.

Just keep in mind that people like to share crafts. So it would be nice to keep some compatibility (like "craft from the restricted config will load and behave the same under the liberal config").

It also happened to the Flea booster on its first release (and was fixed by avoiding the 'rescale factor' config option). And yes I tried to code around it, asdid my predecessor. Obviously we did not find a way that wouldn't break other things.

The problem is large thermometers. If size and weight are negligible, a larger thermometer should not become cheaper. So preserving the price sounds like a good solution to me. I'm not sure yet what to do wiht probecores, probably some sort of inverse pricing. Which is why there is a config switch for scaleable crew parts. Configuring your game is not cheating :-) TweakScale serves many different playstyles, and career mode is only one of them. Another would be aesthetic building, where often people do not care for the function of a part at all. And I can't tell how big the different groups are since I get almost no feedback about the user base of this mod. I mainly build it for my own playstyle (occasional scaling in career mode, where it seems reasonable and looks good). Personally, I tend to overlook the more unreasonable sliders because I never search for them. It's like having Hyperedit installed but still using rockets to get my payloads into orbit. If someone wants to put in the work to publish and maintain a proper restrictions config for career mode, feel free. There clearly is a demand for it. It just hasn't happened yet because nobody wanted it badly enough.

Maybe double-use of attachment nodes? With partClipping/non strict attachment checks from the debug menu you can use the (outward-facing) end nodes of the bays to put stuff on the inside, effectively using the node twice. This can confuse the fuel flow logic, which tends to ignore one of the connections.

Now for something on topic: I've updated the TweakScale dev version for the OPT v1.8 test release. I haven't deleted anything so it should still work for the parts which vanished since v1.7.

small dev update: * patches for the OPT v1.8 test release * cleaned up some unused/outdated stuff * update MM

This is not a general problem with downscaling, but with the behaviour of specific parts. You are right, science parts currently get too strong when shrinked and useless when enlarged. Maybe I should just keep mass and cost constant. Inverse proportional cost would make sense for the material bay but not for the tiny science parts. There is always the possibility to remove TweakScale from certain parts with a simple MM patch. For crew pods (or parts with a certain module) this patch is even shipped with TweakScale (see examples.cfg), you just have to activate it. The same applies to multiplayer: if you want to compare yourself to others you need to agree on a common set of rules. This includes the choice of mods, but also their settings. To allow everything by default was a conscious design decision because reverting to default should not break crafts. Also, if you add a restriction patch, a user with default settings will be able to use all your crafts.

Actually scaling things down can be just as cheaty. For example the tiny stock engines are less efficient and often don't come in the ecact size you need them. If you only want to use TweakScale for a certain mod, you can safely remove some (or all) of the config files in the 'patches' folder. This is the typical solution for people who want to scale something specific but otherwise keep the 'lego blocks' feel of restricted puzzle pieces. There is a config interface for size restrictions, where you can unlock scaleFactors with techs. However it uses absolute scales, so you can write "this scaleType(or part) needs techX to scale to 2.5m" but not "you can now scale everything to half size". I currently don't include restriction configs because I consider them a pain to do and maintain, and it would break easily as soon as someone moves parts in the tech tree.

This is strange because as of today the dev version should still be identical to the latest release. In any case, scale_editor.dll is not needed and yoiu can safely remove it (I'll also remove it for 1.1).

The OPT config is probably incomplete because I expected that the current 'test release' would be followed by another release. I'll update it in time for 1.1. Sounds likely, some of the realism mods heavily manipulate the TweakScale configs. I think there was also a conflict between the RealEngines and TweakScale modules.

Actually this is not an edge case but the end condition, i.e. the regular way of a servo to stop. If maxDeltaVel was high, this means that the servo jumped to its commandPos in the old version. If the new version behaves differently, it does not consider the movement finished, and will be interrupted later by the next command. I guess this invalidates some of my considerations, in this case bypassing the interpolator will behave like the old version before your change.

In my understanding the underlying problem is that you are doing the interpolation yourself, and then the result is streamed to the IR interpolator which is told to come to a stop at each position. I think a cleaner way to handle this would be to offer a mode that tries to keep its target speed until reaching the target position, assuming he will get new commands on the fly. It would only brake after overshooting, or when approaching a hard limit. This could actually work without the realtime requirement of getting new positions every physics tick. Another way is to disable/bypass the interpolation entirely (i.e. write positions directly). This is more or less what happens when you set huge acceleration values. There might still be a bit of weirdness here and there because it was not an intended use case when I wrote the interpolation code. Of course the silver bullet would be true synchronous interpolation, i.e. only one interpolator for a set of servos. You would give it a list of positions, then it would calculate its dynamics (maxSpeed/maxAcc) based on the distance and dynamics of the involved servos, and move them all in sync. This is pretty straightforward for basic linear motion, but can become a huge can of worms once you get nonlinear (e.g. change 'direction' without stopping). Edit: one more remark to the braking code: when determining maxSpeed from the distance to the limit, we are working on a SQRT curve, close to zero where it has a vertical tangent. So the problem is badly conditioned and the code for the last tick was done more or less by trial and error.

Not sure if this is confirmed yet. I remember a dev statement from several weeks ago (either devnotes or squadcast) that in principle unity can split physics into several threads but nothing is done (so far) from the KSP side. So it all depends on how the engine decides to handle things, and they did not want to promise that it actually happens with multiple vessels in physics range. The possibility is a unity feature, so this is public knowledge. It actually happening is a definite observation/promise about game behavior/performance, and they have been quite secretive about that kind of information. I have the impression that those two tings are often confounded in the discussions.

That's the best news I have heard for a long time. My hopes are up that this includes the root part bug that cost this mod so much of its reputation.