pellinor

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.

while we're talking music:

If this is supposed to execute once per frame, you should add a "wait 0." at the beginning or at the end of the loop. Otherwise * it would execute multiple loops until the IPU run out (wasting EC). * at the end of the frame, the last loop would be interrupted at some random line. Such interruptions have caused a few hard to find bugs for me. For example this looks like perfectly safe code: if HasTarget print Target:Name. However, suppose that one frame ends after the first line is executed (with HasTarget=true), and then the target is lost. In this case kOS will execute the second line, and fail with the error that there is no target. I had something like that in a docking function that would sporadically fail in this way. Since then I sometimes add "wait 0." at the start of a section that should happen within one frame.

In general things should execute in sequence just like C++. The best way to help you is if you post simple code examples of the things that seem not to make sense. I usually debug my scripts with lots of tracecode. Either one-time as a new line in the terminal, or updated every frame at some fixed location (note to self: finally clean up those scripts so I can give them a thread in the forum) https://github.com/pellinor0/kOS-MissionFramework/blob/master/Script/libatmo.ks#L145#L149

They have their pros and cons. As you say the patches are more efficient, but they may also be less obvious to read (a search for the part name will not find the patch) and might catch parts that were not intended. So I use them with a bit of caution.

It is no secret that my most active days in the community are long past. All I had envisioned for TweakScale is done, and I am merely doing housekeeping these days. So I'd just like to state that I would be happy to become dispensable in the future. It seems to already work well for the configs, feel free to also dive into the code and add (or fix) things you are missing. There are surely enough known bugs and ideas. Just keep in mind that TweakScale is used in different ways and no one should force his playstyle over everyone else. @eberkain @Mikeloeven there is a merge conflict for the NFT configs, and you both reordered that file, so I see no simple way of merging this pull request. Maybe one of you still knows what he changed and could check if the other file misses any of those parts? Layout-wise I am fine with either style.

We also have the TWEAKSCALEBEHAVIOR nodes I use for group-specific exponents https://github.com/pellinor0/TweakScale/blob/master/GameData/TweakScale/ScaleExponents.cfg#L456-L504 or MM patches that look for specific modules.

I'm not talking about this. All I am saying is that the tech to scale any engine up one scale factor could be the same. I don't know if a part needs to have a bulkhead profile. What I know is that it can have multiple ones and people can invent their own profile names. So probably not a good idea to rely on people using them in a consistent manner.

Never mind, I just read something with using smokescreen in real time and thought that implied coding (because configs are only read once at the start of the game). I see no fundamental problem with having a single tech that would for example allow all engines to be scaled up. We could also code something with child techs but note that a tech may have multiple children or none at all. Also if the restrictions are scattered too far across the tech tree, how shall the player know when which scale is unlocked? Trial and error in the editor? Spam the tech tree with dozens of dummy parts? You don't want a flood of bug reports from people who don't understand the restriction system.

Yes because changing antenna power does not work while a vessel is unloaded (which is the main use case for a relay antenna). This is a problem of the base game: non-persistent values can only be modded for loaded vessels.

Why 2? Shouldn't all geometry scale linearly (exponent=1)? And do we need a config interface for this? My understanding is that it can be hardcoded because these things should always scale like the rest of the model geometry. This is what TweakScale does today concerning particle effects (I'm not familiar with that code yet): https://github.com/pellinor0/TweakScale/blob/master/Updater.cs#L140-L241 Maybe you could have a look, if you are already familiar with the smokescreen interface?

I don't really understand, this does not look simpler to me than what eberkain already has. My idea is more like this techRequiredPlus = largeTech, largerTech, hugeTech techRequiredMinus = smallTech, never which can be defined globally, in a scaletype, or on the part level. By default everything is allowed at start. If the list is shorter than the available scales, the last entry would be applied. So in the example hugeTech would allow arbitrary upscaling, and downscaling would always be limited to one step. Known issue with MFT+TweakScale, fixed in the dev version