pellinor

Names and folders don't matter as all of these are moduleManager patches (and those files probably do not have the same content). Tweakscale is a partModule (i.e. a piece of code/data) that you need to explicitely add to a part if you want to make it scaleable. This is usually done with a MM patch (that can be placed anywhere in a .cfg file under GameData). The simplest way to write your own patches is to look at the existing files (for example in TweakScale/patches/Squad) and copy from there. I'll have a look. In the meantime you can also experiment with making your own patches, see my above comment. Currently hardcoded, sorry (should only affect downscaled parts). I plan to make a config exponent for this like for the other part properties.

rescaleFactor is a stock config value for parts, and has nothing to do with TweakScale. It only scales the size of the part (including some wheel dimension stuff that TweakScale does not reach), so you have to adjust stuff like part mass yourself. You would use ModuleManager to create a scaled copy of a wheel part.

Then maybe you shouldn't update TweakScale. Each version is compiled against a specific KSP version and might not work with others. The last version for ksp1.1.0 should be v2.2.7.2: https://github.com/pellinor0/TweakScale/releases

I have done this by locking the steering to the heading of the plane, plus a roll angle proportional to the heading error. So a simple p-controller, leaving the PID stuff to the kOS steering. Edit: if it helps, the code is here (functions atmoLandingPlane or atmoAscentPlane, not well commented unfortunately): https://github.com/pellinor0/kOS-MissionFramework/blob/master/Script/libatmo.ks

Ah I have an idea: the highest interval of the tweakable is broken (which unfortunately is stock now so I can't fix it or even look at the code any more). In the TweakSCale configs this does not hurt much because the max scale is very generous. If RO puts tighter limits to its scaling configs (and it probably does) you will miss the highest interval. My current workaround is to define an additional interval whose only purpose is to absorb the bug. Finding the ScaleType of your part (somewhere in the configs that come with RO) and adding an extra scaleFactor will probably solve your issue. Scaletypes from other mods would be a reason to code this workaround into the plugin instead. That is a better solution than asking every other mod to change its scaletypes (and to change them back when/if the tweakable gets fixed).

So far it is hardcoded, but I plan to make it configurable with an exponent like everything else. A workaround would be a MM patch to define a scaled copy of the MPL.

Crewmember Jebediah Kerman assigned to Mk1 Inline Cockpit, seat # 0 (crew seat index: 0) (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64) Cannot add crewmember Bob Kerman to Large.Crewed.Lab. Part Crew Capacity Exceeded. (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64) Crewmember Bob Kerman assigned to Mobile Processing Lab MPL-LG-2, seat # 0 (crew seat index: 0) Not sure what to make of this. I need to look deeper into the crew scaling, but most likely won't find time until the start of august, sorry to keep you waiting. Bad wording on the first page, to make it clearer: there is a mod named KRASH which currently conflicts with scaled crew capacity, and I still need to look into what goes wrong there.

The release should only contain a GameData folder. The download of the dev version (which is currently identical to the release) contains the whole repo and you only need the GameData folder. From my side nothing changed. Thanks for the link. Noone else here with RSS/RO? I have no knowledge of RO other than the fact that it changes lots of things including its own TweakScale configuration.

Release v2.2.13: * recompile for KSP 1.1.3 * fix for solar panels * rewrite of chainScaling: propagate relative scaling factor to child parts

FYI, I won't be able to update until friday. So if 1.1.3 comes today feel free to post recompiled/fixed versions if necessary.

Have you tried adding ":FINAL" to the first line? Just in case some other patch comes later and overwrites yours.

Dev update: * another fix for solar panels KER should display those values. For engines, ISP is preserved so you're only interested in mass and thrust. And in the end you're interested in TWR and deltaV, which is also shown in MJ.

Also happens for me, reproduction: * take new stock LFO tank * rescale (amount scales) * switch tank type (ok) * switch tank type back to LFO => amount resets to unscaled values Edit: opened an issue for B9PartSwitch. I'd like to get crew scaling stable before adding more crewed parts. But feel free to write your own custom patches.

Thanks for noticing. I switched to yet another of those numerous undocumented float values and it seems to work now (fixed in the dev version). Is the part scaled? TweakScale should not touch that transform for unscaled parts (v2.2.12 or dev version). Even for a scaled pod I can not reproduce it. Could you upload the craft that causes this? Unfortunately no, I have no idea what to do with those wheel modules. Obviously Squad fixed it for the "rescaleFactor", so as a workaround you can define your own scaled wheels this way. However I have received no answer to my question if whatever they do can also be done by TweakScale after loading the part in flight. Might also not be worth their time since the wheel code will again change a lot for KSP1.2.

Sounds reasonable, just like B9 splitting off the HX parts into its own package. You could also keep one bis package but separate the contents in a way that makes it easy to remove parts. Like subfolders that can be removed without breaking the remaining parts. Performance is totally independent of the number of subfolders in your GameData, or the number of zip files you used to install the contents. It does depend on things like the amount of textures, which is actually an argument to split things up into optional packets instead of large monoliths. Also partlist cluttering can be quite a problem in a heavily modded install.

Thanks I'll have a look. The crew scaling feature is new so it's very likely that there are still interactions to sort out.

So did you test with a minimum install or are still supposing that your other mods have no influence? Cryotanks has its own boiloff module but it also patches parts with fuelswitches (so the result is likely to depend on which other mods are installed). And did you look what modules are on that tank? Craft file are just regular text files, you can copy&paste text from there into a forum post (use spoiler tags if copying more than a few lines). I'll look into this as soon as I can, but not sure if I'll find the time before next monday. @Parallax59 Did a quick test and found that cryoEngines bundles an outdated version of B9PartSwitch (v1.1.4). The current version v1.2 explicitely says "TweakScale integration" in the changelog. Does updating B9PartSwitch solve your issue? I can reproduce that v1.1.4 does not work with TweakScale. Just switching first scale and then tank type in the editor is enough for fuel amounts to revert. Edit: I can't recommend KSP-AVC enough, just starting KSP was enough to see what was wrong with the install.

Thanks, this already helps a lot. Yes, because I don't consider this apparent at all, especially in a heavily modded install. There are many modules that can end up on the same part with TweakScale, and will manipulate the same things. For example FAR, modularFuelTanks/realFuels, a variety of fuel switches, or even kOS (which also modifies part mass). Also, exceptions can cause code to be skipped (see my post above), which could in principle also cause all sorts of "reverting" problems. Could you upload a minimal craft file that reproduces the bug for you? A one-part craft would be enough, just so I can see what modules are on that part in your install. A game log would also be helpful. So, to sum up the most obvious symptoms from your report: * downscaled tank: launch, revert to VAB => fuel amount is ok, but maxAmount is reverted * upscaled tank: just launch => maxAmount reverts (rest might be a consequence) Sounds very much like a new interaction problem with one of the fuel tank mods. Which of course does not mean it's their fault.

Or a messed up install (supposing you still have all those exceptions happening). You could fix those gaps in a text editor, but it would mean shifting the part by an odd amount, maybe in an odd direction. Not something to do manually. To my knowledge the best fix is to reconnect the parts in the editor. And if you have vanishing nodes then try to solve the exceptions first. An exception literally means that the program comes to a situation where it can not continue, and the only safe thing would be to crash. Then it skips code until finding a "catch" statement, hoping that this has not left an inconsistent mess behind. This can cause all sorts of issues that might not become obvious immediately. I think KER does that. Also RscBuildAid (probably the sum of all engines).

Can you tell what broke? The main change was to disable the TweakScale module in flight if there is no rescale. Did this have side effects I should know about? Edit: and I apologize for the inconvenience.

Unfortunately no, my understanding is that the problem happens on load in the editor, and persists. So if you save the ship without a gap, you should be able to launch the saved craft from the space center scene without creating a gap (because this avoids the "loading in editor" part).

There are exceptions in that log from a variety of mods (but none from TweakScale). Things like vanishing nodes can be a symptom of exceptions in the editor. The displacement on loading is probably this bug: https://github.com/Swamp-Ig/ProceduralParts/issues/118

2.2.11.1 and 2.2.11.2. The links go to the github commits and you find those numbers in the TweakScale.version file there. I have no idea how this database reload does and how a plugin needs to behave to survive it. Is there any documentation about this?

@Parallax59 @ss8913 this is a second issue that makes a certain optimisation from last week look suspicious. Could you try to reproduce your issues with the version from before and after that change? (you only need to replace Scale.dll) If you can confirm that this change broke your crafts I'll revert it and push out a new version. before: https://github.com/pellinor0/TweakScale/blob/a346b6a2191cc8c0cb94fc194ac1b63804ecb7de/GameData/TweakScale/plugins/ after: https://github.com/pellinor0/TweakScale/blob/f9a730b17723558469d5b8d634cb10750ed0af49/GameData/TweakScale/plugins/

"very latest version" is release or dev (v2.2.12 or v2.2.12.3)? I can not reproduce it, testing the following with v2.2.12.3: * SPH, make new plane with BigS wings (delta, tail fin, elevons) scaled to 50, 100 or 200%. * launch * revert to SPH => both sizes and scale display look correct Maybe this needs some other mod to be present? Were your wings scaled or not? The only suspicious change I can think of is that I deactivate the part module in flight for unscaled parts. If some effect would bring this state back to the editor we might have a problem. But I'd need it reproduced on my machine to see what exactly is happening.