pellinor

It seems like I can't set a target when KSP is out of focus (on windows non-fullscreen with option -popupwindow, if that makes any difference). When called from a boot file while KSP is not the active window, the following code gets stuck until I bring the KSP window to the top. local count is 0. until HasTarget { set Target to tgt. wait 0. set count to count+1. } if (count>1) print "WARNING: setTarget: count="+count. It looks like only the "set target" is ignored while everything else runs normally. Is this a known limitation? I remember a discussion about input locks in the past, maybe this is related?

Not sure what examples you are referring to. You are looking for chain-scaling (LeftCtrl-K), this means if you rescale a part it will (try to) propagate that change to its children. This works recursively on whole subassemblies provided all parts in between are able to follow the rescale (I never use this so I do not have much experience with it).

Look into defaultScales.cfg, and add extra values to scaleFactors

Gives the term "duna escape" quite a new meaning...

Release TweakScale-v2.3.3: * recompile for KSP 1.2.2 * fix cost bug with fsfuelswitch (ignore resource cost because FSfuelSwitch takes it into account) * added a bit of documentation Known issues: there is are still cost issues in the interactions with fuelswitch mods (other than FSFuelSwitch).

I just had a look at IFS in the game and noticed a "dry tank cost" display that changed with the tank type. And wanted to mention that writing DryCost is a legitimate way to manipulate TweakScale from the outside (if the interaction problem is there). Dev update: * a bit of documentation (thanks to linuxgurugamer)

The basic design for cost scaling seems to be the following: (1) TweakScale calculates the dryCost of the prefab and uses its moduleCost to scale that (TweakScale::DryCost is the scaled value). Other partModules generally calculate their cost from their data fields, which are already scaled where apropriate. Therefore TweakScale does not try to scale their moduleCost. (2) TweakScale assumes that it is responsible for any change in resource nodes and compensates for that with its moduleCost. If another mod touches resource nodes on the same part we need to understand the interactions, and code exceptions for those rules where needed (I'll put this into the upcoming documentation for TweakScale): FSFuelSwitch: all interaction is done from the TweakScale side. The prefab part has no resource nodes, and the part cost is configured accordingly. So the dryCost is the cost from the part config and does not change when the tank type is switched. The resource cost is part of the tankCostList in FSFuelSwitch. This list is scaled by TweakScale, and the cost is applied by FSFuelSwitch. TweakScale does not do (2) if a FSFuelSwitch module is present on the part. MFT/RealFuels: unknown (Volume is changed via part message from TS to MFT, but I do not know how cost works). Currently MFT seems to apply resource cost twice (even when on its own), which makes it hard to tell if there is an additional interaction problem or not. InterstellarFuelSwitch: unknown (handled from IFS). @FreeThinker would it help if you overwrite TweakScale::DryCost with the one shown in IFS? ConfigurableContainers: unknown (handled from CC). Currently it looks like the dryCost is wrong because the prefab has its resources removed but its cost still includes them. @allista could you have a look at this? (and ping me if I should do anything differently on my side) B9PartSwitch: unknown (handled from B9PartSwitch).

The one from part.partInfo, that should come from the part config (but there might also be mods which manipulate it).

In my opinion it would help to understand the cause instead of putting all sorts of band aids in our code which make the interactions more and more complex. The common factor (or the first thing that broke) seems to be dry cost calculation. It is currently calculated as availablePart.cost - (resource cost of the part) and recently changed the dev version to availablePart.cost - (resource cost of the prefab part) The second one gives the right dry cost when FSFuelSwitch is present, and also seems more consistent to me. I suspect that something changed with the initialization of resource nodes of the prefab or the part, so that mods that manipulate tanks mess each other up.

German has a lot of "er" and "en", but I would say most of them come from grammar (like articles, pronouns, verb declinations) and those combinations are not used that heavily in names. @SQUAD If you do your statistics over arbitrary text, you might get better results by adding a list of actual first names in that language and give a bit more weight to the combinations found there. Edit: the same is probably true for the amount of "e"s. I would bet that vowels are more equally distributed in german names than in arbitrary written text.

I second this. And I wouldn't tie it to the character set (as suggested somewhere else) since it's a pretty personal thing which languages sound familiar to someone and which don't.

This. And full of people who think they are the center of the universe (we were during early access, but a lot of SQUAD's attention has moved on to a much wider target group since then).

The problem is that the relay functionality is usually used when the relay vessel is not loaded, so the partModules do not come to life. It might be possible with a custom module derived from ModuleDataTransmitter, which overloads the method(s) for unloaded antenna power. Then the relay computer would act as a relay antenna and would report the combined range.

stack_square or free_square. They are same as the standard stack and free types, just with a mass exponent of 2 embedded. There was an idea how to set the starting scale of a part, but still need to investigate that. Currently there is no simple way. In any case, defaultScale is not what you are looking for. Its meaning is more like "how should the size of the unscaled part be named in the UI?" Known issue, already documented in both mod's github pages and won't be solved until someone at the PP side finds time to dig into it (I found the line that does the displacement but don't know enough about PP to fix that behavior).

I would say don't try too much to understand everything, take existing mod code and try to understand or change something specific. For finding API pieces, the best way is often to find a mod that does something similar and look at its code. That and the symbolic information that visualStudio draws from the game libraries. And don't be shy to ask specific questions.

It should be possible via configs like other fields but I don't think it is a good idea. It would mean that small parts might already blow up at room temperature. My understanding is that large parts should resist the same temperatures but need more energy/damage to reach them. So maybe some mass / thermal-mass related behaviour is not working the way it should? I remember the term "thermal mass" from somewhere but don't see a TWEAKSCALEEXPONENT for such a value, so this might be the property you are looking for.

Thanks, any help is welcome. It has been a recent advice for the modding community to have a look at garbage reduction. As a c++ guy my knowledge about garbage is very thin, and I can't really tell how much there is to gain. At least TweakScale does its work when parts come to life, so any performance impact should only happen at occasions like vessel loading. http://wiki.kerbalspaceprogram.com/wiki/Garbage_Reduction

There is lots of existing code here that could do with some more attention, and pretty much all modders are happy about contributions. I'd recommend you to find something that you want in the game and start digging into that. Like bugs in a mod you like or an extra feature. For me that was continuous scaling and bugfixes for TweakScale, and later smooth acceleration for IR. Some ideas: * From my part, TweakScale could use help in several areas, like support for the new stock part-upgrade mechanic, investigating interaction issues with other mods, or de-Linq-ing (for garbage reasons). (see github issues) * KCT seems to be under heavy development by someone with very limited time * iirc KCT-KIS-integration is something both parties would be interested in but have more pressing things to do * KOS is a highly collaborative project which could use more helping hands

It depends. Changing the size of the meshes is pretty simple (with a few extras like updating drag cubes if the part scale differs from the prefab). Most of the TweakScale complexity comes from changing the various properties of the partModules to follow the scale in a somewhat reasonable way. Which has its balance issues, so I prefer to scale sparingly and consciously. Actually it could be pretty straight forward to change the value tweakScale (value of the tweakable) from a MM config to make a part start at something other than 100%. Will have to test because I never thought of doing it that way.

Most people who say this phrase have no idea what it actually means. First and foremost, scaling would be optional and support would need to be done by the authors of the part mods (today most patches are supported by me). Which means that many mod parts would just not be scaleable anymore. Stock support would be reduced to the smallest common denominator (like tanks, aero and structural). Any functionality that has its quirks (like scaling crew capacity) would be cut out. Last but not least, no updates between KSP versions. Is this really what you want? The upside would be one folder less in your GameData.

Dev update: * fix cost bug with FSfuelSwitch Edit: there seem to be problems with several fuel switch mods lately, probably something changed in the base game. MFT applies resource costs twice (even when on its own), interaction with CC also seems broken. If FSfuelSwitch is present, I now ignore resource costs when calculating GetModuleCost. It might make sense to also do that for (some of) the other fuelSwitch modules.

This is a very good start, thanks a lot! I'll see what I can correct or expand and include it for the next version. That would be something like (taken from TweakScale/patches/Squad/Squad_Tanks.cfg): @PART[nameOfYourPart] { %MODULE[TweakScale] { type = stack defaultScale = 3.75 } }

Better documentation is one of the things I keep procrastinating. The best advice I can give at the moment is to take a look at the TweakScale/patches/Squad folder and copy the patch from some similar part (with :NEEDS[TweakScale] if distributed with your mod). If you want I can also make the patches. Which mod is it? You have grown quite a collection by now :-)

Should be pretty simple (the "localScale" member of the "model" transform is a vector so you can scale each exis individually). And I think there was some mod about anisotropic scaling, but I don't remember a name. However, since the complexity of TweakScale is about 1% about scaling the model and 99% about keeping all other part properties in sensible ranges, this is not in the scope of this mod.

For a significant amount of danger you'd probably need to generate them on the fly like asteroids. So most of the pieces only pop into existence when they are near the active vessel. Makes me think of a game mode where there is no KSC and your only source of parts is debris around kerbin, and ships are built with the help of KIS.