pellinor

It needs a recompile, and an official update of the dependency KspApiExtensions. On my dev install all it looks fine, so that should not take too long.

I could recompile the code just fine, and TweakScale seems to work with it. Still because of the way KAE does its typing, we should wait for an official release.

TweakScale v1.53 is incompatible (needs recompile), still waiting for the dependency KAE to update.

Another observation: the camera bug was not fixed, so 1.0 still does not like scaled root parts.

MODULE { name = ModuleControlSurface useInternalDragModel = True dragCoeff = 0.6 deflectionLiftCoeff = 3.49 // area = 12.28m^2 ctrlSurfaceRange = 25 ctrlSurfaceArea = 0.29 // area = 3.56m^2 actuatorSpeed = 35 transformName = ControlSurface } MODULE { name = ModuleLiftingSurface useInternalDragModel = True deflectionLiftCoeff = 5.0 // 16,5m^2 dragAtMaxAoA = 0.6 dragAtMinAoA = 0.0 } MODULE { name = ModuleAeroSurface // used in airbrake useInternalDragModel = True dragCoeff = 0.6 deflectionLiftCoeff = 0.38 surfaceRange = 70 ctrlRangeFactor = 0.2 surfaceArea = 1 actuatorSpeed = 20 transformName = Flap defaultActionGroup = Brakes liftingSurfaceCurve = SpeedBrake } Surely for the first two deflectionLiftCoeff should scale as an area (exponent=2). For the third I have no idea how it is related to surfaceArea. The drag numbers seem pretty constant across parts (around 0.5-0.6), so I suppose they should not be scaled. The heatshields seem to scale only by the RESOURCE amount of ablator. MODULE { name = ModuleProceduralFairing nSides = 48 nArcs = 3 TextureURL = Squad/Parts/Aero/fairings/fairings_diff panelGrouping = 3 pivot = 0,0.17,0 axis = 0,1,0 baseRadius = 1.25 maxRadius = 3 capRadius = 0.375 snapThreshold = 0.25 xSectionHeightMin = 0.3 xSectionHeightMax = 3 edgeSlide = 0.15 edgeWarp = 0.02 noseTip = 0.5 UnitAreaMass = 0.04 UnitAreaCost = 12 } MODULE { name = ModuleCargoBay DeployModuleIndex = 0 closedPosition = 0 lookupRadius = 1.25 // nodeOuterAftID = bottom // nodeInnerAftID = top } Fairings also look promising for scaling. - - - Updated - - - bulkheadProfiles = size1, srf bulkheadProfiles = size2, srf bulkheadProfiles = srf No idea how those bulkHeadProfiles work, just please tell me they did not hardcode the stack sizes in...

The plugin compiled well against 1.0 and at first view everything seems to work. Still waiting for an official KAE update before I can publish a dev version.

If an upscaled engine is strictly worse than several regular ones, why would you ever want to use it instead of plastering the rocket with small engines? If you want to forbid one direction and nerf the other to death, it would be a better choice to just not provide engine scaling (which is a perfectly fine way of playing and can be done with a single MM patch). My opinion is the larger parts could have some slight advantage, so it makes sense to use the largest part that will do the job.

The more I think of it the more I tend to keeping an exponent >2. I actually scale for performance, and remember that for tiny things the best engine for the job often was smaller than what would look best. And at the moment the weight exponent for engines is not that easy to adjust, this is why I am thinking about writing a TWEAKSCALEBEHAVIOR for them too. For mass/thrustExponent=2, the height of the fuel stack that an engine can lift is preserved. If a 2.5m engine can barely lift two orange tanks, its 1.25m version will lift the same height worth of 1.25m tanks. The typical 0.625m craft will be much smaller than that, so those crafts will typically call for a smaller/lighter engine. For exponent 3, the stack an engine can lift will also scale linearly in length. This might be a bit much. For exponent 2.5, the stack grows with sqrt(scale) in height. This is the old setting, which I kept for boosters (i.e. engines with a tank attached). So when a booster is scaled, the twr scales with exponent -0.5, and the burn time with +0.5. This is also how TWR and burn time scales with length for the (0.90) stock boosters. This might actually be a good middle ground. I'll have to build a few tiny (and large) things to see how well it fits. - - - Updated - - - They do not exist in the new tweakable (which was already pulled into KspApiExtensions), and there is nothing useful for them to do. Since both modes take their intervals from the scaleFactors, there are no small intervals anymore. and the slider increment is too small, you'd usually need 25 or more clicks to get to the middle.

Right. Just set freeScale=true and the space between the scaling buttons should become a slider. In an earlier version there were buttons for small and large intervals, but those became obsolete when I wrote my own tweakable for this.

So my strategy for KSP 1.0 will be to get the plugin running as soon as I can and publish a dev version for 1.0. Then I'll take a few days for discussing feedback and deciding on the new scaling behavior. The main point where I need more feedback is mass/thrust of engines. My understanding is that 2 would be a physically reasonable exponent for thrust, and lead to engines that are useful in the game. The old setting is exponent 2.5 for both, probably because my predecessor wanted to avoid part-specific mass exponents. Going as low as 2.5 already messes up the mass fraction of fuel tanks enough. So my guess is that the mass exponent was chosen as a compromise and the thrust exponent was chosen to preserve TWR. At the moment the dev version uses exponent 2 for engine thrust and weight. So a 2.5m engine is equivalent to four 1.25m engines. In this scaling, a (KSP 0.90) 48-7s is reasonably close to a downscaled skipper (both thrust and bell size are a bit bigger for the 0.625m skipper). So what do you think?

Pleased to hear that, so I have finally sorted out all those uncommented exponents. Also removed those from the dev version.

I'd be grateful for any insights on how the balance pass in 1.0 changed how things scale. Current TweakScale balancing (dev version) is * the fuel fraction of tanks is preserved * TWR of engines is preserved * engine thrust scales with scale^2 * solar panel power/mass is preserved * wing weight scales with the area (this might become a problem with wet wings) Also wing lift seems to scale automagically (CoL indicator moves but there is no scaleExponent for fixed wings). I hope they moved fixed wings to a proper partModule now.

I removed the file with the part patches. For the TWEAKSCALEEXPONENTS I'll wait for your feedback, because the list I posted probably contains modules from other mods. The exponents are all in one config file, often missing comments which mod each node is node meant for.

It was more of a quick fix that is ok for DryCost because it is part of the TweakScale module. The "!" in a regular TWEAKSCALEEXPONENTS node seems to work fine, it only makes trouble if I want to override the exponent on a per-part basis with mm patches. So we'll find a better solution, I'd just like to get other things stable first. You sound like you know more about relative scaling than I do, where do you use it? - - - Updated - - - Small change of plan with the scaletypes, we really need to define exponent overrides for a group of parts, in a way that is not tied to scaletypes. Scaletypes are more tied to the form of a part (i.e. stack parts), defining which scales are allowed and how the UI should display them. What is missing is a description that depends on the function of the part (i.e. decouplers) and can be combined with any scaleType. With the recent "copy a whole node" feature of MM I cooked up TWEAKSCALEBEHAVIOR nodes: TWEAKSCALEBEHAVIOR { name = SRB MODULE { name = TweakScale TWEAKSCALEEXPONENTS { name = ModuleEngines minThrust = 2.5 maxThrust = 2.5 } TWEAKSCALEEXPONENTS { name = ModuleEnginesFX minThrust = 2.5 maxThrust = 2.5 } } } So SRBs have the standard cubic (dry)mass scaling, but their engines scale with an exponent of 2.5 (instead of the standard 2.0). This is how it is used in a part patch: @PART[solidBooster] // RT-10 Solid Fuel Booster { #@TWEAKSCALEBEHAVIOR[SRB]/MODULE[TweakScale] { } %MODULE[TweakScale] { type = stack defaultScale = 1.25 } } So the first line copies in a tweakScale module (without scaleType setting). The second fills in the scaleType. Since "%" means "create or edit", the patch looks the same if the first line is present or not. So far I have behavior nodes for boosters and decouplers. Engines and solar panels still work with the stack/free_square scaletypes. I'm not sure if I should port those to something like a "squareMass" behavior, because this seems more complicated and less readable. Any thoughts?

@FreeThinker: I found another file with part patches that look like KSPI. Would you also take this over? https://github.com/pellinor0/TweakScale/blob/master/GameData/TweakScale/Warp_TweakScale.cfg

TweakScale uses "!" in scaleExponents to indicate relative scaling, which conflicts with moduleManager as soon as the config value is part of a patch. So !DryCost=3 Means "DryCost needs relative scaling" in a regular config node. In a MM patch it is interpreted as "If there is a DryCost setting, remove it." For now I will hardcode relativeScaling for DryCost so it can be used without the "!" in patches. So from the next version on, DryCost patches like this should work: @PART[...] { @MODULE[TweakScale] { %TWEAKSCALEEXPONENTS[TweakScale] { %DryCost = 1 } } }

With a MM patch with :NEEDS[Firespitter] it can be added to the parts without depending on the firespitter dll. So the pack would support firespitter but not distribute the dll.

So I've taken the road of providing different scaleTypes, stack and free now have cubic mass scaling (for things like tanks), and there are new types stack_square and free_square for parts like engines and solar panels. The thrust for stock SRBs is patched to an exponent of 2.5, so if a RT-10 is scaled to the same length as a BACC it will have roughly the same TWR and burn time. Stock engines are done but I'm not finished with stock and haven't touched the mod patches yet. Please consider the dev version as [breaking] from now on. Things will still load but physical properties like mass and thrust can be different so existing crafts which rely on scaled parts will likely be out of balance. I'll look into this tomorrow. Spent too much time today getting basic things to work...

Great, so here are the exponents that might be from KSPI. Please check which ones you'd like to take over, and I'll remove those in the TweakScale release for KSP 1.0. TWEAKSCALEEXPONENTS { name = ModuleSolarSail surfaceArea = 2 } TWEAKSCALEEXPONENTS { name = MicrowavePowerReceiver collectorArea = 2 } TWEAKSCALEEXPONENTS { name = ISRUScoop scoopair = 2 } TWEAKSCALEEXPONENTS { name = AtmosphericIntake area = 2 } TWEAKSCALEEXPONENTS { name = FNRadiator radiatorArea = 2 } TWEAKSCALEEXPONENTS { name = AlcubierreDrive effectSize1 = 1 effectSize2 = 1 } TWEAKSCALEEXPONENTS { name = AntimatterStorageTank chargeNeeded = 2 } TWEAKSCALEEXPONENTS { name = FNGenerator radius = 1 maxThermalPower = 3 } TWEAKSCALEEXPONENTS { name = FNAntimatterReactor radius = 1 ReactorTemp = 1.16 PowerOutput = 3 upgradedReactorTemp = 1.55 upgradedPowerOutput = 3 } TWEAKSCALEEXPONENTS { name = FNFusionReactor radius = 1; ThermalPower = 3; resourceRate = 3; upgradedThermalPower = 3; upgradedResourceRate = 3; powerRequirements = 3; } TWEAKSCALEEXPONENTS { name = FNNozzleController radius = 1 } TWEAKSCALEEXPONENTS { name = FNNozzleControllerFX radius = 1 } TWEAKSCALEEXPONENTS { name = InterstellarFissionMSRGC radius = 1 PowerOutput = 4.4 upgradedPowerOutput = 4.4 } TWEAKSCALEEXPONENTS { name = InterstellarFissionPBDP radius = 1 PowerOutput = 3 upgradedPowerOutput = 3 powerRequirements = 3 } TWEAKSCALEEXPONENTS { name = InterstellarInertialConfinementReactor radius = 1 PowerOutput = 3.18 upgradedPowerOutput = 3.18 } TWEAKSCALEEXPONENTS { name = InterstellarTokamakFusionReator radius = 1; PowerOutput = 5.13; resourceRate = 5.13; upgradedThermalPower = 3; upgradedResourceRate = 3; powerRequirements = 3; }

@FreeThinker: TweakScale includes some TWEAKSCALEEXPONENTS definitions for interstellar and you modify them with MM patches. Supposing this is the only version of KSPI that is actively developed, would you like to take over those definitions and distribute them with KSPI? I think this makes more sense than having the configs in two places. KSP 1.0 would be a good time to make the transition. There are a couple of module names starting with "FN" that I can not match to a mod yet, do they also come from KSPI?

I've never tried BDArmoury. TweakScale only works out of the box if the other module can live with having its variables manipulated without notice. So I'd suggest to start small and see which values can be changed without glitches. A second way is that BDArmoury can use the TweakScale API to get notified on rescale and update their module themselves. I know that IR and MFT/realFuels successfully use method. Not known for TweakScale. But I've seen this before, and I remember a comment that this symptom was fixed in some mod (don't remember which one). That was quite some time ago, so it should not affect anything CKAN distributes. As I told you, scaling of the root part is known to be buggy and not supported at the moment. Though I have some hope left that the problem will vanish next monday. EDIT: now I also see a mass issue! Still have to see if I broke that in my dev copy or in a published version. EDIT: found it! It seems that the stock info window does not update often enough, so it misses rescales (but probably displays the right number once it catches up). Detaching parts seems to update it. If I open a mechjeb info window mass changes as (and when) it should.

Oh sorry must have overlooked that. Scaling of the root part is not recommended because it will trigger a bug in KSP aud cause bad things. Other than that, there is no known problem with scaling of mass and attachment positions. Part clipping or models reverting scale are usually just visual bugs, so they should not interfere with physics. What you describe sounds like it comes either from a scaled root part or from a problem with your install. Exceptions can also lead to TweakScale code being skipped, which would lead to symptoms like you describe.

So the first thing I'll implement is to scale dryCost with the mass exponent if there is no dryCost exponent defined. This will reasonably cover most parts because usually both mass and cost should scale linearly with gameplay utility. An exception to this could be parts whose gameplay utility does not scale well, like probe cores. At the moment they get both heavier and more expensive when enlarged, which makes no sense. But what if a larger core would be heavier and cheaper? EDIT: DryCost scaling is done in the latest dev version. Next step will be some MM magic for basic engine support, and then finding and solving those parts that need special treatment.

I don't see a good fix from my side. If someone removes a node and puts it back, TweakScale must assume that it was moved intentionally (this is done by procedural parts for example). JSI could save the current position of a node when removing it. This would allow to switch them on and off for a manipulated part, but still break if you rescale it while nodes are switched off. To cover this case, it would need to actively look for a tweakScale module, read currentScale/defaultScale, and calculate the new position of the node.

Now I know IR from the inside, limiting the node sizes should be easy. I don't think they can be scaled with a config, so they need their own code. IR is already notified on rescale, we can limit the node sizes there. This extra manipulation will not break TweakScale because it reads the original sizes from the prefab part. So is there a consensus that nodes on IR parts should globally be limited to size 2? (i.e. the standard node size on 2.5m parts)