pellinor

Has anyone figured heatProduction yet? In .90 I could scale it to give scaled engines the same overheating behavior as the original size. Now KSP ignores the scaling, just like maxThrust. For maxThrust the solution was to scale maxFuelFlow instead. Is there a similar change for heat? Do the values make sense to anyone? Without scaling, large engines heat up faster and further, to the point that a 5m basic jet will explode on the pad when running long enough at full thrust. So it seems like a relative quantity. Still the value seems to go up for larger engines, though there is no obvious pattern (Ant=8, skipper=306, mainsail=180, KR-2L=70).

Just throwing an idea into the room: Heatpipes could function like struts with very high heat conductivity, or even act like a direct connection between parts. They are physically plausible, compatible with the heating mechanics, and could act as a kind of 'duct tape' to add a bit more player control (just like ordinary struts do for mechanics). As a model I would imagine a retexture of the fuel line.

It is also getting late for me. So if no large issues pop up until then I will release tomorrow. This will be TweakScale 2.0, because the mayor things I thought were wrong are now in: * usable free scaling support for everything * conservation of both TWR and fuel fraction

Replicated, no Idea what is different for this part. TweakScale patch removed until I understand the issue. Thanks for your help. - - - Updated - - - You know, the question is not if I believe you, but if there is anything that I can/should do about the situation. It is a good thing to mention issues you are seeing because others might have them too or recognize some error pattern. Just for your situation I do not have any good advice, nor do I see an action that I should take for TweakScale now.

Ok, fairings do not work (large gaps between the pieces, can't relate them to any config value). Commented the patches out. Feel free to tinker with them, I'll gladly include them if someone gets this to work.

Dev Update: * scaling support for new stock parts: Fairings, Airbrake etc. * switch for scaleability of crewed parts (defaults to OFF) - - - Updated - - - Ok now I also have engineer installed and its values look reasonable. Mechjeb just saw no thrust scaling at all, so it would not give useful results.

The current mechjeb does not see the scaled thrust, it worked with the old exponent (which KSP now ignores) and stopped working with the new ones that work with KSP. But when I launch and read the right click menu of the parts in flight, the thrust seems correct. Delta-v is not a property of an engine, and I would be wary with the current calculators because the mechanics have changed.

I was about to write 'the new stuff', just when realizing that I put in all the the exponents to support the new modules but the parts are not maked as scaleable yet! I'm off to write patches... - - - Updated - - - What does 'efficient' mean? At the moment scaling in both directions should have 'neutral' efficiency in the sense that the gameplay-relevant properties (ISP, TWR, and cost/thrust) are conserved. I'm actually thinking about giving upscaling a slight advantage so you would prefer using one large engine to spamming small ones.

Update: fixed thrust scaling. Though the config values still are min/maxThrust, the kspFields that matter are now called min/maxFuelFlow. RCS still seems to work the old way. - - - Updated - - - Any more test results? I'd also be pleased to hear if any of the new modules work as intended. Haven't found the time yet to build a single plane in 1.0 myself.

Known issue, and already fixed. maxTemperature was scaled, which obviously did not make much sense.

Oh, stupid copy&paste errors when changing lots of config lines. fixed. Thanks for reporting! - - - Updated - - - The small manifold works for me, you probably have some version from yesterday where the exponent for maxTemperature is still in. It was always there (and never made any sense), but did not attract any attention because maxTemp did not do much before 1.0. As for the versions, I usually increase the version number only when the dll is recompiled, so it does not reflect every single config change. - - - Updated - - - Good finding. TweakScale and MechJeb agree that thrust scales as it should. Just KSP seems to ignore it. So the jets have the maxThrust value like other engines but seem to ignore it in their calculations...

I can not replicate this on my install: * I saved a craft with a part of scaleType 'stack', the craft file says Ds=1.25, Cs=1.25. * After changing the TweakScale config to free, I restart KSP, reload (looks ok) and save the craft. Now the craft file says Ds=100, Cs=100. * Then I edit the craft file to Ds=0.5, Cs=1. The part correctly shows up double-size and is later saved to Ds=100, Cs=200. The feature of surviving changes like these is pretty recent but was added before recompiling for KSP1.0 and moving parts from scaleType surface (Ds=1) to free (Ds=100%). So at the moment I could only explain what you see by the combination of an old Scale.dll and younger TweakScale configs.

I'm trying to make TweakScale-able crew pods an option that can be toggled via MM patch (and would default to off). So far I fail to write the last condition right, without it the modules are removed correctly. Does anyone know better how to write this? TWEAKSCALESETTINGS { scaleCrewPods = 0 // set to 1 for scaleable pods } @PART[*]:HAS[@MODULE[TweakScale],#CrewCapacity[*],~CrewCapacity[0],#../TWEAKSCALESETTINGS/scaleCrewPods[0]]:FOR[TweakScale] { !MODULE[TweakScale] {} }

Update: the dev version now has support for the new part modules. The exponents are mostly based on guesswork so far. If you'd like to help, please test. I didn't touch the exponent for moduleEngines:heatProduction yet, so that might be completely off.

So you had a working game, didn't touch anything and suddenly everything is broken? Sorry, no idea what could have happened there.

I'm trying to make scalable crew pods an option that can be toggled via MM patch (and would default to off). So far I fail to write the last condition right, without it the modules are removed correctly. Does anyone know better how to write this? TWEAKSCALESETTINGS { scaleCrewPods = 0 // set to 1 for scaleable pods } @PART[*]:HAS[@MODULE[TweakScale],#CrewCapacity[*],~CrewCapacity[0],#../TWEAKSCALESETTINGS/scaleCrewPods[0]]:FOR[TweakScale] { !MODULE[TweakScale] {} } EDIT: on the issue with small things overheating, there was an exponent "maxTemp=1" which made no sense at all. Also removed the crashTolerance exponent because this value is also constant for stock parts of different scale. EDIT: put some exponents for the new modules. Some guesswork inwolved, so this needs testing. A first glance parachute modules seem not to need any scaling, the open question is just how weight and cost should scale. My guess is scale^2 because this is how the drag would scale when calculated off the visual model. So the main open things now are * scaling heatProduction in moduleEngines/FX (currently 0.85 which looked reasonable back in 0.90) * scaling the bulkHead property of parts (which is not a number but a list of strings) * testing Minor things (old issues I noticed when updating things) * resource consumption for reaction wheels does not scale * moduleAlternator does not scale * ModuleLandingLeg is missing, is there anything that needs scaling? Now the main things I wanted to do for KSP1.0 are in, and the rest should hopefully be tweaks that do not break games/vessels too hard. So TweakScale should be close to a release.

Updated dev version: I reverted the thrust exponent to 2.5 (TWR ist still preserved). This means they have their own TWEAKSCALEBEHAVIOR now, which makes it much easier to tweak the scale exponents for all engines in one place (including RCS, excluding boosters).

It's a bit more than just inside/outside. As I understand if you make a ball out of radially attached parts, it is modeled as a ball for reentry heating, but as a pancake for drag (just like FAR does).

I just hope they fix the underlying code issue this time, and not just tweak the cfg to avoid the use of rescaleFactor.

Thanks! Fixed the config in the dev version, I'll fix the code later (a mistyped/missing scaleType should not break the game). - - - Updated - - - Scaling of the new aero and heat properties is a completely open question. So I'd be glad about any insights on what needs scaling and what would be reasonable exponents.

TweakScale has a recompiled dev version, I'd list it under 'mostly compatible' because I still expect balancing changes in the next few days.

Updated the dev version! For an official release, I'd like to get the scaleExponents a bit more stable, so I won't break crafts directly afterwards.

There should be a related bug report by biotronic on the tracker, I just can't find it now.

I can reproduce it. * Virgin 1.0 install, unpack ksp-linux-1.0.0.zip, start new sandbox. * Build craft: Flea booster as root(important), mk1 pod on top. * Launch (so the flight scene starts and it sits on the pad) * Revert to launch. Now the booster is too small, just like in the above picture. The same thing happens if I quicksave and quickload instead of reverting to launch. When tinkering with tweakScale I made the observation that the value/object part.transform.GetChild(0).localScale; for the root part seems to behave differently on launch compared to revert-to-launch/quickload. When I write it on vessel load, part.transform.GetChild(0).localScale = (someValue); part.transform.GetChild(0).hasChanged = true; part.transform.hasChanged = true; everything is fine on launch and for non-root parts. But on revert-to-launch or quickload the value for the root part gets reverted to 1.0, which reverts the size of the visual model, and the camera bug is triggered. My theory is that the common factor is localScale!=1.0, which is first set to the right value and then overwritten by some default. The additional bad things in TweakScale's case are probably connected to setting the hasChanged flags.

What bugs me more is that they are not equal anymore, so everytime you unlock a new SRB all others will be obsolete. Parts becoming obsolete is an easy way to do a progression but not the best design for a sandbox game.