AccidentalDisassembly

Tried the new version with large scaling - doesn't work. Same issue, plus a new issue: in the editor, if the TweakScale SCALETYPE has a large value, clicking more than twice in either direction on the selector arrow causes the context menu control to seem to lock up. Dunno what's up with that. For your testing purposes, if you haven't already, please get rid of the two IR tweakscale configs you have and use these instead: https://www.dropbox.com/s/z2htmyrsfpr9x6z/New IR TweakScale Configs.zip?dl=0 Also, for the sake of scaling, the variable names used to control the movement limits for rotational parts vs. extendable parts need to be different. TweakScale needs a value it can scale for extending parts as a function of the part's size - e.g. maxPosition or maxPositionLimit, which should increase as the size of the part increases so that the numbers work out for how far the part is extending. HOWEVER, rotational parts use the same variable name (in the same module) to represent degrees of motion. This will cause all sorts of bizarre numbers with TweakScale. This is from the Rotatron part, for instance: minPositionLimit = -360 maxPositionLimit = 360 When TweakScale changes the part's size, it will also change those values in a linear fashion - but it should not do so, since they're a measurement of degrees of rotation. Those variables need to be changed to something else so that TweakScale will not modify them.

*Spooky music* Huh... in SVT.v2.1.2.zip, GameData/SVT/configs/Tylo.cfg for me, there are 227 lines in the file, and line 227 should have a closing } but doesn't. EDIT: Just downloaded it again to double check, there's a } missing for sure, or I am on crack, or possibly both. If it doesn't matter, then no big deal, just figured I'd post since I found it with my handy {}-checker python script.

I just looked in the ZIP again, there's definitely one missing... I double checked by going into Notepad++, counting { and counting } - there are 27 { and 26 }

Still unsure if it's relevant, of course, but there is a missing opening brace { in: GameData\NearFutureProps\Patches\RPM\NFProps_RPM_Mug.cfg

Not sure if it matters, but in the latest SVT (2.1.2), the Tylo.cfg config has a missing closing brace } at the end of the file.

I wondered this as well, and am still on the fence about it a little bit. If you play around with it enough, though, you'll find that the LH2/Ox engines allow you to make a tradeoff: 1. Much more volume 2. Probably more expensive 3. However, rather significantly less mass for a given dV so long as we're talking about an upper stage. The same seems to be true for KerbalAtomics, which switches nukes over to LH2: LH2-based stuff is less massive overall for similar dV, and the tradeoff is a LOT more volume (like 6x or 8x the volume compared to setting up a Nerv engine with LiquidFuel instead). At least that's been my impression with them so far. EDIT: One thing I will note, though, is that the engines themselves from this pack tend to be MUCH more massive than vaguely similar ones from other packs. Dunno how each author decided on the balance there, just a thing I noticed (compare to BDB, for instance).

One thing noticed so far: when TweakScaling more than one or two increments from wherever the part starts (e.g. going up or down more than a couple arrow clicks in either direction - I think), torque values for the parts become very small. They can be set back to 30 again, but there's definitely something funky with scaling + torque values. The same issue persists where parts (looks like all parts, now) scaled up past a certain point do not turn or extend, as well. You have to add larger sizes to the TweakScale configs to see this, as below (but without the asterisks, of course): SCALETYPE { name = Rework_Standard freeScale = false scaleFactors = 0.198425, 0.25, 0.314980, 0.396850, 0.5, 0.629961, 0.793701, 1.0, 1.259921, ******7****** scaleNames = Small -, Small, Small +, Medium -, Medium, Medium +, Large -, Large, Large +, *****GigantorTest**** defaultScale = 1.0 } Example: Both servos should be moving (unlimited EC) in this image, but only the non-scaled one moves. If scaled to 1.259921 (as in the above SCALETYPE), it will still move fine. But when scaled to 7x, it does not move at all:

Here's a fun patch I've been working on - I wanted the NF Spacecraft engines to be both LFO and MP engines, so I made a config that makes that happen. It's used INSTEAD of the LFO patch included with the NFSpacecraft download. For anyone's use who likes that idea: EDIT: requires RealPlume + RealPlume Stock, just to be clear. // Add the PLUMEs at the right time so that RealPlume adds appropriate EFFECTS @PART[orbital-engine-0625|orbital-engine-25]:FOR[RealPlume]:NEEDS[SmokeScreen] { PLUME { name = Hydrolox-Lower transformName = thrustTransform localRotation = 0,0,0 localPosition = 0,0,0.75 flarePosition = 0,0,0.72 flareScale = 0.45 plumePosition = 0,0,1.2 plumeScale = 0.45 fixedScale = 0.5 energy = 0.2 speed = 0.75 } } @PART[orbital-engine-125|orbital-engine-375]:FOR[RealPlume]:NEEDS[SmokeScreen] { PLUME { name = Hydrolox-Lower transformName = thrustTransform localRotation = 0,0,0 localPosition = 0,0,1.0 plumePosition = 0,0,1.3 plumeScale = 1.5 flarePosition = 0,0,0.75 flareScale = 1.3 fixedScale = 1.7 energy = 0.25 speed = 0.8 } } // Remove the shock cone flare because it doesn't look quite right IMO @PART[orbital-engine-*]:HAS[@PLUME[Hydrolox-Lower]]:FINAL { @EFFECTS { @Hydrolox-Lower { !MODEL_MULTI_SHURIKEN_PERSIST[shockcone] {} } } } // After RealPlume has added its stuff, come back and add MultiMode stuff, the LFO engine, and fix the heat animation @PART[orbital-engine-0625]:FOR[zzRealPlume]:NEEDS[SmokeScreen] { MODULE { name = MultiModeEngine primaryEngineID = LiquidFuel secondaryEngineID = MonoPropellant } @MODULE[ModuleEnginesFX] { %engineID = MonoPropellant } MODULE { name = ModuleEnginesFX thrustVectorTransformName = thrustTransform powerEffectName = Hydrolox-Lower exhaustDamage = true ignitionThreshold = 0.1 minThrust = 0 maxThrust = 14 heatProduction = 160.011766 engineID = LiquidFuel PROPELLANT { name = LiquidFuel ratio = 0.9 DrawGauge = True } PROPELLANT { name = Oxidizer ratio = 1.1 } atmosphereCurve { key = 0 315 key = 1 190 key = 4 70 } } @MODULE[FXModuleAnimateThrottle] { @responseSpeed = 0.01 %preferMultiMode = True } } @PART[orbital-engine-125]:FOR[zzRealPlume]:NEEDS[SmokeScreen] { MODULE { name = MultiModeEngine primaryEngineID = LiquidFuel secondaryEngineID = MonoPropellant } @MODULE[ModuleEnginesFX] { %engineID = MonoPropellant } MODULE { name = ModuleEnginesFX thrustVectorTransformName = thrustTransform powerEffectName = Hydrolox-Lower exhaustDamage = true ignitionThreshold = 0.1 minThrust = 0 maxThrust = 140 heatProduction = 201.4078447 engineID = LiquidFuel PROPELLANT { name = LiquidFuel ratio = 0.9 DrawGauge = True } PROPELLANT { name = Oxidizer ratio = 1.1 } atmosphereCurve { key = 0 325 key = 1 210 key = 4 90 } } @MODULE[FXModuleAnimateThrottle] { @responseSpeed = 0.01 %preferMultiMode = True } } @PART[orbital-engine-25]:FOR[zzRealPlume]:NEEDS[SmokeScreen] { MODULE { name = MultiModeEngine primaryEngineID = LiquidFuel secondaryEngineID = MonoPropellant } @MODULE[ModuleEnginesFX] { %engineID = MonoPropellant } MODULE { name = ModuleEnginesFX thrustVectorTransformName = thrustTransform powerEffectName = Hydrolox-Lower exhaustDamage = true ignitionThreshold = 0.1 minThrust = 0 maxThrust = 110 heatProduction = 139.534354 engineID = LiquidFuel PROPELLANT { name = LiquidFuel ratio = 0.9 DrawGauge = True } PROPELLANT { name = Oxidizer ratio = 1.1 } atmosphereCurve { key = 0 328 key = 1 195 key = 4 90 } } @MODULE[FXModuleAnimateThrottle] { @responseSpeed = 0.01 %preferMultiMode = True } } @PART[orbital-engine-375]:FOR[zzRealPlume]:NEEDS[SmokeScreen] { MODULE { name = MultiModeEngine primaryEngineID = LiquidFuel secondaryEngineID = MonoPropellant } @MODULE[ModuleEnginesFX] { %engineID = MonoPropellant } MODULE { name = ModuleEnginesFX thrustVectorTransformName = thrustTransform powerEffectName = Hydrolox-Lower exhaustDamage = true ignitionThreshold = 0.1 minThrust = 0 maxThrust = 560 heatProduction = 202.5754264 engineID = LiquidFuel PROPELLANT { name = LiquidFuel ratio = 0.9 DrawGauge = True } PROPELLANT { name = Oxidizer ratio = 1.1 } atmosphereCurve { key = 0 337 key = 1 213 key = 4 105 } } @MODULE[FXModuleAnimateThrottle] { @responseSpeed = 0.01 %preferMultiMode = True } }

Do you have Nertea's SSPXR installed? If so, the visual observation is probably the one that you have to do via putting a scientist in a particular cupola part.

There's a mod that tries to address the jumping, and in my experience it's pretty effective:

OK, thanks! So in that case, it seems to me that you could create any scaletypes you want, with any names you want and any min/max values you want, and it would not affect crafts loaded from someone who used completely different values. Instead, TS would simply read the "resize by factor of X" value, regardless of whether it would in theory be permitted by the scaletypes you've set up for your own game. But, in order to define the attributes other than model size for the part, it would look up your (current) TWEAKSCALEEXPONENTS values to set them - like mass and EC, or values fed to a converter module, or whatever? TL, DR: There should be no problem loading a craft with a part rescaled to 398x size even if your scaletypes don't allow for that value, but if you've messed with TWEAKSCALEEXPONENTS, it could radically change resources or mass or whatever. If I'm understanding correctly, that is...

https://www.dropbox.com/s/sk8dysamh0q0e96/JetSoundsMMErrors.zip?dl=0

Unfortunately ModuleManager throws 101 errors with those configs - not sure why, though, sorry!

Think it needs to be HAS:[!MODULE[TRR_Reflection],!MODULE[ModuleWheelBase]]:etc. <--- meaning only apply to parts that don't have TRR_Reflection, and also don't have ModuleWheelBase. Otherwise - if I'm reading that right, the extra ! in your patch might mean something like: check that the part does not have TRR_Reflection, and does not NOT have ModuleWheelBase... I think a comma alone without an ! might also work inside the !MODULE[] as well.

Small and possibly meaningless discovery (made several of these tonight...): In the following files, there's a missing or extra { or } : RealPlume-Stock\EveEngines\eveEngineAsp.cfg RealPlume-Stock\Squad\liquidEngineMini.cfg RealPlume-Stock\Squad\smallRadialEngine.cfg

Small and possibly meaningless discovery: in these files, the number of { and } are mismatched - dunno if that causes problems or not, just thought I'd throw it out there: NearFutureElectrical\Localization\en-us.cfg NearFutureElectrical\Localization\es-es.cfg NearFutureElectrical\Localization\ru.cfg Other packs: NearFutureLaunchVehicles\Parts\FuelTank\fueltank-5\fueltank-adapter-5-375-2.cfg NearFutureProps\Patches\RPM\NFProps_RPM_Mug.cfg

Small and possibly meaningless note: In the following files, there is an uneven number of { and }. Dunno if that actually causes problems with MM anymore, but thought I'd point them out: \GameData\Mk2Expansion\Localization\en-us.cfg \GameData\Mk2Expansion\Localization\ru.cfg \GameData\Mk2Expansion\Parts\Engines\AASRB\Radial.cfg \GameData\Mk2Expansion\Parts\Engines\AASRB\RadialL.cfg One in M3X as well: \KSP_131_x64\GameData\Mk3Expansion\Localization\en-us.cfg

Small and possibly meaningless note: in RasterPropMonitor/Library/Props/IndicatorPanelReplacement/prop.cfg, there's a missing closing brace }.

Just a heads up - may affect other aspects of the mod, maybe not: In Wheesley_patch.cfg, you are missing a closing brace in running_thrust - the number of { } is unequal in the file.

Made a TweakScale patch if anyone wants to use it. I made some arbitrary choices in it (e.g. minimum of 0.625m scale in new SCALETYPEs based on my personal preferences), so... buyer beware and whatnot. SCALETYPE { name = SSPXR_stack25 freeScale = true defaultScale = 1.25 suffix = m scaleFactors = 0.625, 1.25, 1.875, 2.5, 3.75, 5.0, 7.5, 10 incrementSlide = 0.0625, 0.0625, 0.025, 0.125, 0.125, 0.1, 0.25 TWEAKSCALEEXPONENTS { mass = 2.5 } } SCALETYPE { name = SSPXR_stack freeScale = true defaultScale = 1.25 suffix = m scaleFactors = 0.625, 1.25, 1.875, 2.5, 3.75, 5.0, 7.5, 10 incrementSlide = 0.0625, 0.0625, 0.025, 0.125, 0.125, 0.1, 0.25 } SCALETYPE { name = SSPXR_surface freeScale = true defaultScale = 1.0 scaleFactors = 0.5, 0.75, 1.0, 1.25, 1.5 incrementSlide = 0.05, 0.05, 0.05, 0.05 suffix = x } @PART[sspx-adjusting-base-25-1,sspx-adjusting-base-cradle-25-1]:NEEDS[TweakScale] { %MODULE[TweakScale] { %name = TweakScale %type = SSPXR_stack25 %defaultScale = 2.5 } } @PART[sspx-adjusting-base-375-1,sspx-adjusting-base-cradle-375-1]:NEEDS[TweakScale] { %MODULE[TweakScale] { %name = TweakScale %type = SSPXR_stack25 %defaultScale = 3.75 } } @PART[sspx-adjusting-base-125-1,sspx-adjusting-base-cradle-125-1]:NEEDS[TweakScale] { %MODULE[TweakScale] { %name = TweakScale %type = SSPXR_stack25 %defaultScale = 1.25 } } @PART[sspx-cargo-container-25*]:NEEDS[TweakScale] { %MODULE[TweakScale] { %name = TweakScale %type = SSPXR_stack %defaultScale = 2.5 } } @PART[sspx-cargo-container-375*]:NEEDS[TweakScale] { %MODULE[TweakScale] { %name = TweakScale %type = SSPXR_stack %defaultScale = 3.75 } } @PART[sspx-cargo-container-radial*]:NEEDS[TweakScale] { %MODULE[TweakScale] { %name = TweakScale %type = SSPXR_surface } } @PART[sspx-adapter-125-25*|sspx-cargo-25*|sspx-attach-25*|sspx-hub-25*|sspx-tube-25*]:NEEDS[TweakScale] { %MODULE[TweakScale] { %name = TweakScale %type = SSPXR_stack25 %defaultScale = 2.5 } } @PART[sspx-adapter-0625-125*|sspx-attach-125*|sspx-cargo-125*|sspx-hub-125*|sspx-tube-125*]:NEEDS[TweakScale] { %MODULE[TweakScale] { %name = TweakScale %type = SSPXR_stack25 %defaultScale = 1.25 } } @PART[sspx-adapter-25-375*|sspx-attach-375*|sspx-tube-375*]:NEEDS[TweakScale] { %MODULE[TweakScale] { %name = TweakScale %type = SSPXR_stack25 %defaultScale = 3.75 } }

Yeah, seemed to. The legs individually adjusted fine. I tried to autolevel, and it didn't do anything, but I'm not sure how that works anyway (therefore not sure whether TweakScale affected it at all)!

TWEAKSCALEEXPONENTS definition might be needed. EDIT: Nope, I was wrong! Terribly wrong. Scratch that.

What I'm doing is: Creating two new unified TweakScale configs, one for Legacy, one for Rework, in which are combined the necessary SCALETYPE definitions and patches adding TS modules to appropriate parts Making TWEAKSCALEEXPONENTS{} definitions work with the new / differently-named variables in ModuleIRServo_v3. Updating mass exponents to 2.4 across the board - easy to change before anything gets released, if that exponent isn't the right one. Updating EC usage exponent to 2.4 as well. A bit arbitrary, but I figure there's some kind of logic in having EC use be proportional to part mass when scaled... I guess? Niceties: adding tab stops to the config files so they're quicker/easier to read, commenting changes Niceties: Creating a separate, optional patch for people like myself who want larger scales to be possible. I'm not sure why it would be problematic to include larger scales by default, though, [EDIT: looking at the TS configs, actually, at least the original IR allowed for 4x scale...] assuming everything gets fixed with respect to scaling/extension interactions... Especially given the apparent effectiveness of the new KJR. Not sure all is fixed yet, still testing stuff out. With respect to craft sharing - yes, but that's an issue when any part is TweakScaled, and players can already change any of the scales they want by editing configs. I wonder, actually - would things actually be broken if the SCALETYPE on your save was different from the SCALETYPE used to create a craft? What does TweakScale actually save in a craft/part - the name of the scale that got used, or just some numerical value that says "resize stuff by X, EC consumption is now Value Y" and so forth? EDIT: Here are the updated configs. Nothing is changed with respect to how things used to work, I don't think... Hopefully didn't leave any parts out. Put the mass exponent in as a MM patch so that it would be easy to play with, but it could be different for different types of parts easily... https://www.dropbox.com/s/z2htmyrsfpr9x6z/New IR TweakScale Configs.zip?dl=0 ANOTHER EDIT: Playing with TS values, and having just recently downloaded the GameData131.zip from the first post, extension still doesn't work correctly at large scales for certain parts - I made a 5x scale to test, and the stackable extendatron does not extend at all at this scale. However, standard Extendatrons do. When scaled down to 1.25 or so, the stackable one extends just fine...: EC is scaling appropriately, mass too (I think), and the sounds play and stop at appropriate intervals when i try to extend the thing in flight, but it doesn't move. FINAL EDIT: EC is not scaling correctly on the parts that can't be moved when they're scaled above whatever threshold. Off by a factor of 10 or so. Shows correctly in the editor via EEX, but moving the part in flight results in ~10x the power drain.

Not sure if it's what WBI does, but I seem to remember something interesting happening with WBI's Buffalo VTOL/Osprey-style propellers when they're placed in symmetry - there was a toggle (I think) where you could set them as the left vs. right versions. However, maybe that was just cosmetic... perhaps worth looking at? Sorry, I don't have any clue how it actually works.

OK, found the problem with the old TS config and am fixing it (while introducing other niceties). I really think the TweakScale modules should be removed from individual parts' configs and instead applied via a MM patch - this makes it significantly easier to edit, update, correct, modify, or completely disable TweakScale on IR parts depending on users' preferences. Consider for example: if someone wants to play with TweakScale, but NOT with IR parts, they have to go write an MM patch to delete the TweakScale module from every part config rather than just deleting IR's TweakScale patch. Similarly, if I want to change the name of the SCALETYPES in my config so that they're clearer, for instance, I have to use an MM patch to then update each part config rather than copying/pasting one thing in the TS patch. Simplest just to have one TweakScale patch in the first place, IMO. I'll have a working config some time soon! (TM) A random note : There's either a texture missing in the IR_AthleteTruss_XXXX folders (possibly called StructuralSegmentsUV) or the parts weren't ever textured. I seem to remember once having a version of the rework parts where they were textured, though...