pellinor

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.

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.

Ah now I remember, the basic problem is that the cost of a tank part is supposed to include the fuel (very bad design decision on the early days of KSP). So whenever a mod changes tank capacity (like both TweakScale and fsFuelSwitch do) it also has to change the cost of the part. On the fsFuelSwitch side this needs to go in tankCost (in addition to any changes you want to make to dry cost) (and even if the tank starts empty!). You can make TweakScale blind to it by editing ScaleExponents.cfg, but I am sure this is not what you want to do (causes problems like negative cost for scaled parts, I don't remember if up- or downscaled ones). I'll have a look, maybe the interaction with fsFuelSwitch broke (which would surprise me because if that was the case the problem should have come up much faster). It's even worse, you pay normally for the fuel but the dry cost of the part is negative (so you pay money when recovering it empty).

This sounds more like s fsFuelSwitch question. In my understanding tankCost is an extra cost for the tank. So it should increase with size, and you get that money back when you recover the empty tank. You sound like you want to make the fuel more expensive, then you would need to modify the resource definition of xenon (which should be possible with MM).

Actually I'm pretty sure MechJeb is quite modular at the inside, and Sarbian has good reasons to not make the distribution that modular (see @CobaltWolf 's post for some of them). And it even is modular from a user's perspective because you can disable parts of it with MM patches. I have to agree that you make an impression of someone who likes to tell others what to do, but is not willing to do any work himself (even though you seem to consider yourself code-savy). "Community" does not work that way.

Good point ;-) Still my argument is that modularity has a cost in complexity and effort, so it only happens if someone is willing to pay this cost. And if there is nothing more interesting/profitable to do with the available effort. Modders usually only make what they want for themselves (which is a healthy attitude for not burning out), but many are open to contributions. So if you want something, be willing to do it yourself and the ground will be much less stony for your suggestions.

Actually this is the reason why many mods are not modular. Imagine building a car in a way that part of it is also usable as a motorcycle. Both the process and the end product will certainly be more complex and expensive than a regular car.

You have loads of exceptions in that log, some of them suggesting that you might be missing a working copy of ModuleManager. And indeed I don't find any traces of it in the log. This would explain why there are no TweakScale modules, and maybe also the other havoc that is happening in that log. see here: https://github.com/pellinor0/TweakScale/releases The last version for 1.1.3 should be v2.2.13

The location of the log file depends on your operating system, see here for details: To keep the size of the log file manageable, I would * start the game, go directly to the VAB * place a part that should be scaleable * open the right click menu (where the scale slider is missing) * exit the game * and grab the log file (it always contains the data since the last start of the game)

KSPApiExtensions was stockified in 1.2, so if you have it some of your mods are badly out of date. If either TweakScale refuses to load properly or the scaling modules are not applied by MM, the nyour log will probably tell why. I can have a look if you upload it somewhere (first thing I would do is search for 'exception').

These are ModuleManager patches, they just need to be in a .cfg file anywhere in the GameData folder. It is advisable to keep your own patches separate from mods (i.e. not in the TweakScale folder), so you do not accidentally lose them when removing or updating mod folders.