Biotronic

New version of TweakScale is now up! sirkut, get to fixin'!

So thar! New version up! Real Fuels and Modular Fuel Tanks support currently disabled since they're not yet 0.24 compatible. Also, this update features the heavy rewriting I mentioned earlier, so I expect there to be at the very least some problems. Please do file bugs, either here or on GitHub. Oh, and one more thing: it's currently unpossible to change the cost per-part, so rescaled parts cost the same as their unscaled brethren.

A long while later, I find that it's caused by empty cfg files, and not actually caused by module manager, KSPAPIExtensions or TweakScale. Well that's good.

Had a closer look, and it appears this bug is in Module Manager. So I'm off trying to make TweakScale work.

As I haven't been able to get the game running with KSPAPIExtensions, I don't rightly know what problems TweakScale might have. I hope a simple recompile just makes everything work, but I'm much to pessimistic to actually expect it to. KAE gives me a silent crash on the loading screen: NullReferenceException: Object reference not set to an instance of an object at UrlDir+.MoveNext () [0x00000] in <filename unknown>:0 at GameDatabase+.MoveNext () [0x00000] in <filename unknown>:0 (Filename: Line: -1) Not exactly helpful.

Sadly TweakScale is also dependent on KSPAPIExtentions, which I've not gotten to work on my computer (even the 0.24 alpha version). So for now we play the waiting game.

Yeah, I finally got some time to work on this, and I see the whole house of cards has collapsed. I'm dependent on KSP API Extensions, which is not yet updated, and apparently its updater is down with a case of the RL. Hope it passes soon. I've tried getting it to run with the 0.24 alpha version he has, but even that makes KSP crash on my end, so I'll just sit tight and hope thing embetter themselves with time.

That would be correct. In 1.21b, mass is scaled exactly the same as everything else, so instead of massFactors = 0,0,1, you'd write mass = 3. As you can see in the example, mass = 3 is already there. Part, scales as a list of values: MODULE { name = TweakScale type = stack TWEAKSCALEEXPONENTS { mass = 1, 2, 3, 4, 5 } } ScaleType, scales with area: SCALETYPE { name = myType freeScale = true suffix = m minScale = 0.25 maxScale = 5 defaultScale = 1.25 TWEAKSCALEEXPONENTS { mass = 2 } }

None, sorry. Real life has been in the way of my tinkering for about two weeks now, and likely will for one more. I've found bugs in 1.21 beta that force me to delay its release, so... sorry?

Great, that's the kind of report I want! So this is with TweakScale 1.21beta or 1.20? What do you mean by 'no longer scales'? Does the slider show up, but no scaling occurs?

I've refactored a bit. Got rid of some special cases, and now support TWEAKSCALEEXPONENTS inside SCALETYPES, at global scope, and per-part. One cool thing I can show off is this code from ScaleExponents.cfg: TWEAKSCALEEXPONENTS { angularDrag = 2 breakingForce = 2 breakingTorque = 2 buoyancy = 3 crashTolerance = 1 explosionPotential = 3 maximum_drag = 2 maxTemp = 1 minimum_drag = 2 mass = 3 Resources { amount = 3 maxAmount = 3 } attachNodes { breakingForce = 2 breakingTorque = 2 } } That's right, I'm now using TWEAKSCALEEXPONENTS to rescale fuel tank volume and node strength. I'm not ready to call this an official release though, so I'll just leave a beta here. Please do test it, please tell me if there are any new bugs. I'm still in the process of reorienting myself after a week of vacation, so I actually haven't yet a good idea of what problems people experience. I'll try and learn more about that tomorrow.

The variable can be overridden on a per-part basis: @PART[advSasModule] // Inline Advanced Stabilizer { MODULE { name = TweakScale type = stack defaultScale = 1.25 MODULE { mass = 2 } } There you go, equivalent to massFactors = 0, 1, 0, and only for that one part. I think I should change the inner MODULE to TWEAKSCALEEXPONENTS, though. Oh, and it works today. Even better than massFactors = 0, 1, 0, due to a bug in how massFactors are handled. I haven't bothered making it possible to override the exponents per scaletype, as a scaletype isn't intended to say anything about the part's properties except its size. That's something I'm more than willing to consider, though. Probably not, no. Of course, the answer would likely be a lot more complex than 'scale the mass with the surface', but somewhere in between might make sense.

I haven't the foggiest. These configs work for me: @PART[km_se0-oms] // FSX0-OMS Micro Shuttle Engine { MODULE { name = TweakScale type = surface } } @PART[km_se4L] // FSX4L Linear Aerospike { MODULE { name = TweakScale type = surface } } Please check your output_log.txt. This sounds like it's a problem with some other mod that interacts with TweakScale.

I managed to recreate this by breaking another mod. Does this still happen if you remove TweakScale? Look through your output_log.txt file and see what exceptions are begin thrown. Or upload it somewhere and I'll have a look.

I have a question for people who use TweakScale for their mods: do any of you use massFactors for anything? Reason I ask is this works: TWEAKSCALEEXPONENTS { mass = 3 } right out of the box. Hence, removing massFactors would lead to a simplification of the code base without loss of features. (that's not entirely true - massFactors "supports" polynomials with more than one non-zero coefficient, but even that is buggy)

There's at least three of us working on replacements, then. That's... interesting. Shows people like the stuff at least.

There is a bug in TweakScale that sirkut just made me aware of, where the mass is scaled improperly. I haven't looked into the what problems it actually causes, but I will, as soon as I get back from vacation. I've probably fixed the bug in the latest commit, but I'm unable to test under the circumstances, so you'll just have to wait. Oh, and that means monday. Possibly sunday if I can't sleep. [edit]Thinking a bit more, these two are probably unrelated. Still, I will probably be able to fix things by monday.[/edit]

That should work, yes. It was a problem as described in post 123, and fixed in version 1.10. As we're currently on 1.20, it shouldn't be a problem. Please do inform me if things don't work as you want it to.

I'd love to help, but I'm going away on vacation until next sunday. I'm guessing the problem might be that it's RF6. I haven't updated the support module to that version. In the meanwhile, you can try this beta. If it works, whoo! If it doesn't, you'll either need to download and recompile TweakScale yourself, or just wait for next sunday. (of course, anyone else who wants to is also welcome to look at the code and try and fix this - please post pull requests!)

0, 0, 1 is volume, 0, 1, 0 is surface, and 1, 0, 0 is... I don't know, for when something scales only with the length of a part. You can also combine them, so a part whose mass is defined by both its surface area and its volume could be 0, 0.5, 0.5, for instance. I've not tested how that works in practice, so... good luck, i guess. The values correspond to the coefficients of a polynomial - given massFactors = a, b, c, the mass will be scaled by the function M*(ax + bx^2 + cx^3), where M is the initial mass, and x is the scale. If you really want to, there's no actual limit to the number of factors you can put there - massFactors = 0, 0, 0, 0, 0, 1 works just as fine, but gives some ridiculous weight after scaling up.

So now there are three sliders to adjust the speed? Do you have a good reason not to simply have one Speed slider with UI_FloatEdit? Apart from that: Neat! Look forward to trying this out.

Thanks a lot to both of you. I've been a bit busy lately, and will be for at least the next week, so nothing will happen before then. But worry not, I... Wait, I got a signal coming in... Yeah, that's a result of me just throwing together some code to make the nodes work relatively more sensible than before. (I've had nodes with size 400. Not pretty.) New algorithm for rescaling attach nodes in 1.20. - - - Updated - - - It should happen to anything with a defaultScale of 0.625. Well, not no more, but the way things were. Oh, and while I remember - I added scaling to stock adapters in 1.20.

Because I wasn't aware of it, I guess. However, that works well for freeScale, not so well for stack, surface and other scaletypes where there's a list of options. I guess I'll have to think it over a little more.

Hm. Two things: Should techRequired support the syntax techRequired = advRocketry = 5, heavyRocketry = 3.75 for when you only want to specify a few techs? This would likely be the way to specify freeScale techs should I get around to implementing that. (techRequired = start = 75..125, advRocketry = 25..75, heavyRocketry = 125..200, e.g) defaultScale needs to be unlocked by default, as things are. That shouldn't be a problem, but in the event that people want the default version to be available at reduced or increased scale, but not the default scale, the plugin currently gets confused.

Since you insist. 1.19 includes tech requirements.