pellinor

To my knowledge any modpack troubles in the past were already governed by the licenses of the involved mods. So I don't see what problem this is supposed to solve. People who did not read the rules will still need to be addressed individually.

The words exist but their figurative meaning may not be the same. At least in german, "Raketentechnik" is not commonly used as a synonym for "something incredibly complex". When metaphors or jokes are involved it is often more feasible to write new ones than to translate something existing. Edit: now I think of it I actually remember someone jokingly saying "now I can call myself a rocket scientist" in german. He used the english word because the phrase just does not work as well in german.

(can't see the image without a google account) I also get this behavior with unscaled parts so it is probably not TweakScale related. Sometimes the game just refuses to recognize clicks on the target part for a crew transfer. The "target switch locked" message means it understood a double click (which would usually switch the target vessel). In most cases pressing ESC and doing the transfer again fixes it for me.

Oh, sorry for sending you the wrong way! I meant defaultScales.cfg. It defines the behavior of the scale Tweakable. For most solid parts that show scale in % I use this SCALETYPE definition: https://github.com/pellinor0/TweakScale/blob/master/GameData/TweakScale/DefaultScales.cfg#L44-L52 scaleFactors defines the intervals (for example from 50-100%), and incrementSlide is the granularity of the slider (1%-Steps in that interval). And this is how the scaletype is referenced from a part patch: https://github.com/pellinor0/TweakScale/blob/master/GameData/TweakScale/patches/Squad/Squad_Tanks.cfg#L162-L168

You are trying to scale the model of a part (which is what the link describes) or to add a TweakScale module? Maybe post your patch here so we can help? Generally the link is not relevant to TweakScale at all since ot applies a fixed rescale without using the mod. It should already be 400% for the bundled configs (you find this in scaleExponents.cfg). Mayve that 200% comes with another mod that brings its own scaling configs? If you have MFT/realFuels please try the dev version. There was a negative mass bug (but I thought it would only affect downscaled parts).

try: set antenna to ship:partstagged("antenna")[0]. partstagged returns a list (of parts). You want the modules of the first element in that list.

Sorry, I only know the mod with CTT where things are more spaced out. For me some early progression steps would be * go to orbit without anything * pack supplies and a bit of extra space for a short mun trip * use a recycler to reduce supplies consumption * add a greenhouse to the station/base and ship in fertilizer instead of supplies * drill for ore and make fuel * drill for gypsum and make fertilizer

Actually career mode is a decent beginner setting since you start with the simpler features and the complex stuff won't become relevant until the mid/end game.

The USI Kontainers seem very expensive in terms of mass. The fractions I get are (kit mass / vessel mass) * stock fiel tank: 0.3 * pile of science equipment: 0.75 * USI Kontainer: 0.7 Are they supposed to be that complex to build?

When putting a disc world resting on elephants in the game, why not also take a creative licence for the local gravity field? Define a (spherical) atmosphere around the discworld. Add a custom gravity field that is perpendicular at the disc, and converges to regular gravity at the border of that atmosphere (or maybe at the height where KSP allows on-rails movement).

Just stumbled upon this and it sounds quite like a bug that plagued TweakScale for a long time. This is what NRAP does (and I think TweakScale did in the past): Transform root = this.part.transform.GetChild(0); (from https://github.com/linuxgurugamer/NRAP/blob/master/NRAP/ModuleTestWeight.cs line 118) And this is what TweakScale does today: var trafo = part.partTransform.FindChild("model"); It turned out that the model transform used to always be the first entry of that list in older KSP versions. In newer versions the return value of GetChild(0) was named something with "camera pivot" if the part was root. Getting the model transform by its name fixed things in TweakScale.

Thanks, so does every RF engine have that module or only some switchable ones? What that blacklisting currently does is tell TweakScale not to touch any ModuleEngines(FX) if ModuleEngineConfigs is present. Since RF uses its own engine module now (which is not directly targeted by TweakScale), it probably does nothing today. And when I start to target derived classes it will be needed again.

Make sure the part has no TweakScale module. While TweakScale adds its modules early (in the LEGACY step), other mods might do MM manipulations later on. What part are we talking about?

It would mean that in addition to your patch, TweakScale would find the exponents for ModuleRCS and apply them to your module, so it would read maxFuelFlow and thrusterPower from the prefabPart, scale them and write them in the members your module inherits from the base class. TWEAKSCALEEXPONENTS { name = ModuleRCSFX maxFuelFlow = 2.5 thrusterPower = 2.5 -ignore = ModuleEngineConfigs }

Could you have a look at the dev version? I'd be happy about some feedback before releasing this. And the value I report should probably be a lot more coarse grainded (you can also judge that better than I can).

I would like to make a change to TweakScale to let it affect derived classes of a configured PartModule. So if there is a scaling config for ModuleRCS, it now looks for modules with that name. In my prototype it looks for any module that "is a ModuleRCS", i.e. it also scales ModuleRCSFX. Here is my prototype (including a recompiled dll): https://github.com/pellinor0/TweakScale/commit/4329244702b7fa60b06744a5830bbf137f26883c Now the question is: will this break anything? In other words, are there derived Modules that should not inherit the config of their base class? At the moment the only one I am aware of is ModuleEnginesSolver, which derives from ModuleEnginesFX and is used as a base class in realFuels and AJE. How do they currently interact with TweakScale? Not sure whom to ask, maybe @blowfish or @Starwaster? I also noticed a blacklist entry for "ModuleEngineConfigs" in the TweakScale configs, it probably came from realFuels/RO long ago. Is this obsolete? I could not find any reference to such a module. Another area might be KSPI. @FreeThinker do you see any trouble with such a change?

The negative mass problem with MFT should be fixed in the dev version now.

Should be fixed with the next TweakScale release (and is already part of the dev version).

Has it been confirmed that they talk about ingame models at all? I only read "animation model" which sounds more like the one used in the trailers.

You don't catch log entries, you catch exceptions. An exception is an 'emergency' where something is obviously wrong and it is not clear if the program can safely continue. So the program is skipping code until it reaches a "catch" block, which contains code to handle the situation. This means the exception is handled, but it is still wise to log the incident.

Wow, that was fast, thanks. I already made a similar change in the dev branch (which lead to the KerbalEva parts) but had no clue what the actual problem was.

Hmm, then I have no idea what happened there. The code should only treat parts with a TweakScale module, and it does not trip over KerbalEva in my install. In any case the exceptions are properly catched now (otherwise you would not see the second one) and dryCost should be written properly for all other parts.

Yes, this helps. It tells that you have a TweakScale module on KerbalEva and KerbalEvaFemale. Which is not a good idea. Maybe you have some blanket patch active that tries to make everything scaleable?

Hehe, just noticed the same today, and will include a patch in the next release: @PART[radPanelEdge] // Radiator Panel (edge) { %MODULE[TweakScale] { type = free_square } }

Can someone confirm problems when using KIS to detach docked docking ports? The detached port still shows an "undock" button, and I get an exception when pressing it: StackOverflowException: The requested operation caused a stack overflow. at ModuleDockingNode.Undock () [0x00000] in <filename unknown>:0 at ModuleDockingNode.Undock () [0x00000] in <filename unknown>:0 at ModuleDockingNode.Undock () [0x00000] in <filename unknown>:0 ... This is from a fairly modded career save, and only happens if the ports came together through docking. I remember similar problems when detaching clawed parts from a claw. Likely those attachments are different from normal attach nodes, and KIS would need some specific code to handle them. Getting this to work would be very useful because detaching single parts from the right click menu of a claw often makes them fly away too fast to easily catch them. I occasionally see issues where parts that usually allow clipping seemed to repel each other when surface attaching. That might be the same issue you have, colliders being checked against each other when they usually are not. My case was not completely deterministic, it worked after several tries.