AccidentalDisassembly

EDIT: OK, I figure it out, nevermind all that. This may not be the most elegant, but it accomplished what I wanted: The trick was applying rescaleFactor after the fiddling with the nodes instead of before.

Had a question about using MM to change part stack node sizes - I figure I am doing this wrong somehow, but I can't figure out what exactly I have botched. Here's my code - it's for IR parts. The goal is copying the part, but larger and with larger stack nodes. Everything does indeed work correctly except node sizes. Larger node sizes don't break anything if I make a new part config manually and change stack node sizes. Using the red code, I'm trying to select the 7th entry on the node_stack_top/bottom lines (the node size entry) and change it to 4 rather than 1, which is what is copied over when the part is duplicated. I read what you wrote about the bits inside the brackets a few pages back - I thought just putting [6] meant that MM looks for the 7th comma-separated value on that line. A typical node_stack_whatever looks like this: When I use those lines in the MM patch, the part ceases to have any stack nodes at all. When I comment those lines out, it regains its stack nodes, but size 1. Is something going on because the node_stack_top values are separated by commas and spaces, or something? Is there a way to edit only one of the node_stack_whatever values like I'm trying to do? EDIT: Thought I found the problem, but neither [6] nor [7] nor [7, ] nor [7,, ] works either...

Was the switch-to-a-different-SOI bug addressed somehow?

Huh, now that you mention it, I'm also getting some funny part costs in career since the 1.52 update. I had assumed it was something else I did, but now that I think about it, it may have been just TS that had been updated when prices in the VAB/SPH started going a little wonky.

Sorry, I have just had a string of people not actually read the contents of my posts, lately, then respond to what they insisted I must have been saying without taking the time to read all of the plain language of what I wrote. It has made attempting to contribute to anything on these forums rather frustrating. Anyway, the code for knowing what scale a part is and the limits on its scaling must already exist, since tech limits are already in. TS knows that a part starts (for its purposes, doesn't really matter what size the part really is in game) at defaultScale X, and, knowing this, won't let it scale up to Y (or whatever) until you've researched a tech node. My proposal is simply a relative limit on scaling (to the original size of the part, as determined by defaultScale in its TS module, I assume) rather than an absolute one like it (apparently) is now.

I see you didn't actually read anything I wrote except for that one line.

Please report back on what happens if you scale an IR part more than 1.999x (in most cases, I think) its original size! I'd be curious to know if it really does somehow work now...

I tried something similar once, and I may be wrong on this, but I think the rigidity/strength of the joint has a lot to do with the mass of the IR part - so you could make a larger-scaled IR part (copying the config or something) and make it weigh quite a lot, and that might possibly work.

Hey Pellinor, Question about tweakscale + the tech tree. I was wondering if it would be possible to implement something like this. Hopefully my description will make some sense-ish. But I'm working under some assumptions that might not be true, so please correct me if they're not. I'm using "Tech node 2.5m" and "Tech Node 3.75m" and whatnot to refer to whatever tech node would unlock those sizes, just for the sake of generic argument. Assumptions: are these true? 1) Right now, the way tech tree + scaling works is that particular scaleFactors in a SCALETYPE{} are connected to particular nodes in the tree, right? Assuming that scaletype has factors 0.625, 1.25m, 2.5, 3.75, and 5 only: 2) So, for example, if you have a 1.25m part, you wouldn't be able to unlock scaling it to 2.5m until you research Tech Node 2.5m. Then, you can scale it to 5m when you unlock Tech Node 5m, etc. 3) But, if you have a 3.75m part from the outset, it cannot be scaled down to 2.5m until you unlock Tech Node 2.5m, and then, later, it too can scale to 5m when you unlock Tech Node 5m. So, if that's actually how it works: Would it be possible instead to implement a relationship to tech nodes like this: 1) Let's assume you start with a 2.5m part, and that its SCALETYPE has major increments at 0.625m, 1.25, 2.5, 3.75, 5.0. 2) When you unlock the first tech node that allows scaling up or down, it allows you to go one "notch" (one scaleFactor) in either direction of the part's defaultScale. So the 2.5m part could, at first, only be scaled to 1.25 or 3.75m. Likewise, a part that starts at 3.75m could only be scaled to 2.5m or 5m after this first tech node. 3) The second node in the research tree that has to do with scaling allows you to scale things two scaleFactors in either direction of the default scale - so now, the 2.5m part can be scaled anywhere from 0.625m to 5m. But a part that starts at 1.25m could only be scaled up to 3.75m. 4) The third related tech node allows moving three increments in either direction of original scale, the fourth four, and so forth. Or, it could allow plus or minus a particular percent of the part's original scale, since everything is FreeScale - that might make it more flexible... Or some other system to figure out how much larger/smaller any given part can be made after a particular technology. Then, of course, the real question is whether that kind of system would even make sense. My thinking is that progression in the tech tree should allow greater and greater manipulation of part size, no matter what size a part starts at. But maybe that's not a good way to do it... thoughts?

Unfortunately the answer is not all yes or all no. Yes, it works with IR. No, you cannot scale parts very much bigger. 1.something times original size is the maximum. Why? Apparently because IR parts only work if the node sizes on the parts are size 1 or smaller after being scaled in-game (or something vaguely like that, my explanation is most likely incomplete and wrong). Why? I don't know, because you can (I think, anyway, have to check that) make node sizes larger in the configs and the parts maybe still work. But that means you can scale IR parts smaller (in-game) and it doesn't break. So far, anyway. IR includes tweakscale values to do so. If you want larger IR parts, you'll need to either: A) Copy the configs for the parts, make new ones scaled up, scale up all values appropriately, or Use a module manager patch to do the same thing. This works, I've done it, but not always with all parts for mysterious reasons.

Your log says you ran out of memory. You need fewer mods / smaller textures / ATM / whatever.

The answer is yes, if you're willing to write a lot of configs. You can either: 1) Change the mass = X variable in scaleExponents.cfg to be 2.0 rather than 2.5, or something, and that will make engines' TWR increase as a square function (I think thrust also follows square, so if mass increases as square...). 2) You can write new tweakscale configs where engine parts are assigned either a) a new scaletype with mass = 2 (or whatever), or given TWEAKSCALEEXPONENTS{} with appropriate mass = X in their individual patches. 3) If you REALLY want to personalize it, you can write configs that define the exact mass/thrust of a given engine at a particular size.

Ah, ok, so for the harvesters something happens along the lines of multiplying everything going on (EC consumed, resources produced, whatever) by the efficiency number? I had thought that scaling "efficiency" would simply scale the output without changing EC consumption. At least that one's covered then. So for parachutes, then, I assume the best option would be to specifically make a scaletype for them where the mass scales as a square function - rather than 2.5, as it is now - since I'm just assuming that the parachute's drag would roughly correspond to the surface area of the chute. That's easy enough to do! Thanks for the info!

If anyone's interested, here's a radical simplification of the TweakScale stuff for KF wheels/tracks. It allows everything to be scaled from 0.2x to 10x its original size. Also compatible with the new way TweakScale 1.51 does things. You could fiddle with the values as you see fit, or make a non-freescaled flavor, I guess. Really, every single TweakScale module in the individual part configs could be converted over to one single SCALETYPE type by doing something like this - something that would be made infinitely easier if TweakScale modules were not defined in individual part configs and added instead via MM config. Makes things much more accessible/moddable. Setting the TWEAKSCALEEXPONENTS definitions as I have done allows you to define ANY range of scaleFactors for the parts while having the tweakScaleCorrector variable scale appropriately (it scales linearly anyway, so there's really no point in defining 2983590382059382523 values for it in individual SCALETYPEs - just set the upper and lower limits for your scaling, or if you really want a discrete-steps scaletype, you still don't have to define the individual steps for tweakScaleCorrector). TWEAKSCALEEXPONENTS { name = KFModuleWheel !tweakScaleCorrector = 1 } SCALETYPE { name = KFScaleM freeScale = true minScale = 20 maxScale = 1000 defaultScale = 100 incrementLarge = 50 incrementSlide = 10 suffix = % } SCALETYPE { name = KFScaleS freeScale = true minScale = 20 maxScale = 1000 defaultScale = 100 incrementLarge = 50 incrementSlide = 10 suffix = % } SCALETYPE { name = KFScaleL freeScale = true minScale = 20 maxScale = 1000 defaultScale = 100 incrementLarge = 50 incrementSlide = 10 suffix = % } SCALETYPE { name = KFTrack freeScale = true minScale = 20 maxScale = 1000 defaultScale = 100 incrementLarge = 50 incrementSlide = 10 suffix = % } SCALETYPE { name = KFTrackSmall freeScale = true minScale = 20 maxScale = 1000 defaultScale = 100 incrementLarge = 50 incrementSlide = 10 suffix = % } SCALETYPE { name = KFRepulsor freeScale = true minScale = 20 maxScale = 1000 defaultScale = 100 incrementLarge = 50 incrementSlide = 10 suffix = % } SCALETYPE { name = KFMainGear freeScale = true minScale = 20 maxScale = 1000 defaultScale = 100 incrementLarge = 50 incrementSlide = 10 suffix = % } EDIT: I should have noted that this replaces the KFScaleType config in the KF directory.

Hi pellinor and/or others who could chime in - a quick thought. Wouldn't adding this to the ScaleExponents config make it so that parachutes could be tweakscaled successfully? Has anyone tried tweakscale + parachutes yet? TWEAKSCALEEXPONENTS { name = ModuleParachute semiDeployedDrag = 2 fullyDeployedDrag = 2 } I assume that semiDeployedDrag and fullyDeployedDrag are the variables that ought to increase with size, right? And that the parachute's visual model (including its canopy) will all get scaled up with the container's model... maybe? EDIT: Also, perhaps someone can assist me with Regolith's resource converter and harvester modules and the code I'd need to use for a TWEAKSCALEEXPONENTS{} that would work with it. Here's what the module looks like: All I could figure out how to do for sure was change the "Efficiency" (which is what controls the rate of extraction of the harvester... it's a weird nomenclature...) by doing (successfully) the following: But what about the other variables, like the RecipeInputs (which isn't just a simple Variable = Number setup) that are in a list-ish format? How could I do a correct TWEAKSCALEEXPONENTS{} definition for those? And what about lists like "RecipeInputs = ElectricCharge,21.0,Ore,0.16"?

Yeah, am using TweakScale, but autoscaling shouldn't be functioning at all... though since you say it, that would totally fit with what seems to be going on with the part. I'll try it with an engine as Kerbas_ad_astra recommended and see what happens.

Tweakable everything sounds like a reasonable culprit for me too, gonna go try removing/modifying that to see what happens!

Hello! Had a kind of weird behavior with the SpaceY A3-12 Adaptive Structure. I *think* it's because it's placed on top of a procedural fairing part, because if I remember correctly, something about proc fairings threw exceptions when I tried to launch the craft - but I'm not sure. Sorry I don't have a log, but I have a picture. When reloading a craft, the part goes a little crazy: You'll notice the scale of the part is just plain weird. The fairing beneath it is 3.75m, and the part itself is supposed to have a 3.75m base. The struts used to be on its surface. This particular weirdness actually prevents you from launching this craft directly from the launchpad interface in the main space center screen. Just won't do it. Anyway, I'm posting this here just in case it has something to do with your part specifically. Reproduction (for me anyway, with lots of mods going) is easy-ish: 1. Make craft, proc fairing piece like that in it. 2. Put one of the multi-adapters on top of it, put stuff on top of that. 3. Save, reload (may or may not have to quit KSP in between for this).

Something funny going on in 1.51. What happened: 1. In SPH, makin' a spaceplane. 2. Tried to attach a particular part (a repurposed part from some radom mod I have converted into a USI/Regolith resource converter smelter). They do have TweakScale modules in them, written correctly. 3. When attempting to attach it to the nose of the plane - because why not? - attach nodes disappear from the part, part shades red (like unattached parts do), then the node on the smelter that "attempted" to attach to the plane disappears. The part's other stack node remains visible. 4. Discarding the part stops the logspam. 5. If you don't immediately discard the part and click on something else instead, like the spaceplane, in this case, you'll pick up both the spaceplane AND the smelter part, which is now hanging in mid-air wherever your cursor left it, and you can't set any of it back down in the editor - have to discard the lot. 6. Error did not happen with 1.50, at least. 7. Other parts with the REgolith resource converter module do not exhibit this behavior... there goes that theory. Log: https://dl.dropboxusercontent.com/u/59567837/output_logTweakScaleFeb252015.txt Here is the part's config: //Original model and texturing done by zzz PART { name = CompactSmelter375 module = Part author = AccidentalDisassembly mesh = bigtank.mu rescaleFactor = 1.5 node_stack_top = 0.0, 0.7231, 0.0, 0.0, 1.0, 0.0, 2 node_stack_bottom = 0.0, -0.315, 0.0, 0.0, 1.0, 0.0, 2 TechRequired = spaceExploration entryCost = 12500 cost = 16800 category = Utility subcategory = 0 title = Compact Smelter - 3.75m manufacturer = DAA Aerospace description = A flatter, more compact smelter with slightly lower efficiency. attachRules = 1,0,1,1,0 mass = 24 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.2 angularDrag = 2 crashTolerance = 12 maxTemp = 2900 breakingForce = 150 breakingTorque = 150 fuelCrossFeed = True MODULE { name = ModuleAnimateGeneric animationName = e10 startEventGUIName = Navigation Lights endEventGUIName = Navigation Lights } MODULE { ConverterName = Smelt Ore name = REGO_ModuleResourceConverter StartActionName = Start Ore->Metal StopActionName = Stop Ore->Metal RecipeInputs = ElectricCharge,15.0,Ore,0.12 RecipeOutputs = Metal,0.09,False } MODULE { ConverterName = Reprocess Scrap Metal name = REGO_ModuleResourceConverter StartActionName = Start ScrapMetal->Metal StopActionName = Stop ScrapMetal->Metal RecipeInputs = ElectricCharge,7.5,ScrapMetal,0.1 RecipeOutputs = Metal,0.008,False } RESOURCE { name = Metal amount = 0 maxAmount = 600 } RESOURCE { name = Ore amount = 0 maxAmount = 800 } RESOURCE { name = ScrapMetal amount = 0 maxAmount = 250 } MODULE { name = TweakScale type = stack defaultScale = 3.75 } }

Neat parts! I was wondering, though - is the RCS Jet missing a PROPELLANT {} thing? I see one for intakeAir, but I don't see one for liquid fuel (I assume); could be I just don't know how the configs work though.

There was a time when TweakableEverything and TweakScale were mostly in sync and you could very much fiddle with both the scale and the tweakable strength of a reaction wheel, just as an example. I don't think they're particularly "in sync" at the moment, but it's possible (and didn't involve the ignore = stuff, so far as I know). The reaction wheel, when tweaked, would give new min and max values (as it should) to TweakableEverything (or something).

Having a bit of an issue with a scaletype I created for LLL parts. I like the way the new stack/freescale combo works, but something has gone haywire with non-freescaling scaletypes - or my scaletype needs to be updated with the new incrementStuff, but see below. Here's the example you have in the DefaultScales.cfg: That's all well and good. Here's the SCALETYPE I made, and below it the MM patch that applies that scaletype: The trouble is that: 1) In-game, the defaultScale is not set properly when placing a part. In the editor, when you place that particular 2x1 tank, its visual scale, fuel contents, whatever are all correct. However, the scale readout isn't: it thinks the part's current size is scaleFactor 0.5, not 1.0. It can't be scaled down as a result; it begins as if the part's default size were the smallest scaleFactor in the set. 2) Scale increments don't make sense with user-defined discrete scale steps: All of the incrementStuff makes no sense when applied to something with FreeScale = false, but having these in the example makes me think that the absence of this stuff is what's breaking my scaletype. It doesn't make sense because I've just gone and defined the increments using scaleFactors = and scaleNames =, so having major/minor/slider increments conflicts conceptually.

Very easy to change if you want. The resources do grow with an exponent of 3, of course. Sometimes I wonder in reality whether things really use 8 times the material when scaled to 2x the size, though... At least on engines specifically, the 2.5 exponent is much better than 3. An exponent of 3 makes engine scaling very wonky and REALLY favors scaling engines down.

Encountered a weird behavior when editing wings - something happened with KSPAPIExtensions (says ExceptionDetector) and then right clicking no longer worked on any parts in the editor. I don't exactly know what I was doing when that happened, except changing the shape/offset/etc of a wing I had placed on the end of another wing, so I'm not sure if I can provide perfect reproduction steps, sorry! Log: https://dl.dropboxusercontent.com/u/59567837/output_logB9ProcWingsEdit.txt

He used the word install, but was asking about downloading (or both): "it should be right under the donwload link but it isnt."