ReStock will not be needed, as it doesn't add new parts. RsStock+ on the other hand, has them - but something gone wrong when I tried it (not sure what, it can be even unrelated to TweakScale), so it's on the Queue waiting to be worked out. But since you are the first to ask it, you can follow the works here.

To tell you the true, I'm waiting 1.7 to add the new parts and test the existent ones, so I kind of dragged my feet on TweakScale this week.

Everything will be tested again, just to be sure I made that fail-safes right this time.

Spoiler

(and I found a stupid mistake I did on the patches, and I'm somewhat ashamed by had committed that. )

Share this post

Link to post

Share on other sites

Hello, I just wanted to ask if this mod is compatibile with KSP 1.6. I got a little confused and can't find the answer. The mod is not working for me and it might be because I am an antitalent with mods, but I am not sure yet thanks for any help

Hello, I just wanted to ask if this mod is compatibile with KSP 1.6. I got a little confused and can't find the answer. The mod is not working for me and it might be because I am an antitalent with mods, but I am not sure yet thanks for any help

Yes, the latest it's compatible with 1.6.1 with some reserves (some parts are not supported yet due some new features).

Publish your KSP.log on some snippet service, so I can give a look on it. It's always possible that you ended up finding a new Unholy Interaction between Add'ons.

I found another source of Kraken Food on my "production KSP". Unfortunately, the parts being affected are Stock ones, so I need to address this. At least is deterministic, by reverting the patches to the last public release things works; by applying back the new patches some parts borks again. It will be a boring but easy (long) debug session - deleting Add'Ons one by one until the problem goes away.

This stunt essentially shoves Free Scaling in every part on the GameDatabase that has "Cone" in the name!This not only mangles the prefab, but also corrupts craft files and savegames, as they are "tainted" by this misconfiguration Once you delete the Add'On and Module Manager rebuilds the cache (and the GameDatabase), all your TweakScaled parts gets rescaled terribly wrong!

So, when you load your craft and savegames after installing such Add'On, a lot of parts are wrong (There're more patches like this! The thing is way "greedy" on this). So you "fix" them, and now your parts are incompatible with everybody that doesn't have that Add'On too. And when you uninstall the thing, your crafts and savegames became "corrupted", as the original "type" is back to be effective and Kraken knows what would happen - one of my crafts got the Cones so big that the craft ended up inside an 'egg" - unflyable. And this includes the savegames. Yeah, I need to fix them all on my installment due this.

It worth to mention that this same stunt when applied on a non visual feature (as resource consumption and mass!) would summon the Sacred Rage of the Krakens on your KSP. This has potential to be very nasty if you don't use the latest TweakScale hat withdraw itself from such parts!

I opened a new issue to address this problem. I expect this to happen again, unfortunately.

Mass of wings is scaled with an exponent of 2, so that a large wing should be equivalent to the same area worth of small wings. dragAtMaxAoA does not appear (hopefully that means that it is a coefficient and not a total value).

Recently, I discovered an third party Add'On with a somewhat nasty broad patches for TweakScale. It was so broad that its own patches were being applying twice in some Stock Parts, and these parts are getting three patches piled up (mine, and then a double from the Add'On patch).

(problem was addressed, and a pull request applied to the - hopefully - new maintainer)

But the damage was substantial - since the prefab became , as usual, "corrupted", all crafts were being saved with the bad module. Not to mention the living ones on the savegame. And since the problem happens on a very used Stock part, of course, most of my crafts were affected. I still fixing the damages manually, as this is something that gone undetected for some time.

Bluntly withdrawing support for these corrupted parts are tempting, as this is already implemented. But now is something that would do some really vast damages - this is not Stock parts that never worked correctly before, we are talking about perfectly fine parts that suddenly became corrupted by a rogue patch. This time I would be promoting really wide breakage - the damage to my savegames were substantial (besides not exactly catastrophic - it's a pain in the SAS fixing it, but that's all), now multiply that for the active forum users and….

My current approach is to show a POP-UP explaining the problem on Space Center, and then closing the game to prevent damages. It's the safer approach, but also the one that would also give me a lot of backslash. It's not some few parts anymore, it's some very widely thrusted and used parts that are being tainted, and so the surface of attack is huge.

One final question, the documentation talks about attachnode breaking force, but I can't find any real reference to that. Where would I get it from?

Not sure if I understood. Are you talking about a reference on TweakScale source code about breakingTorque and breakingForce? (links for my own reference in the future)

If yes, you will find none. TS follows a very clever architecture: simple algorithms, complex data-structures. The beauty of the thing is that you "teach" TS to escale things using CFG files (see the TWEAKSCALEEXPOENTS on the default CFG files), not by writing code.

I can't tell exactly why things were done the way they were done prior to my administration but when crosschecking things due the issues I'm fixing, I'm pretty sure that hard references to some part data are things where "manual intervention" were needed to prevent catastrophic failures due misbehaving patches or new features on KSP that didn't existed when this mechanism were initially implemented. I'm pretty sure that the TWEAKSCALEEXPOENTS can be expanded to support sanity check rules (one of the reasons I want that TweakScale3 thingy done) and even PREFAB recalculation, and so some code would plain vanish from the codetree, as they would be handled in the same clever way as the scaling.

But, right now, I still fighting bugs and fixing their misbehaviours - you need to patch the hull and bring the ship safely to the harbour before doing anything else. Sunk ships don't need maintenance.

I didn't dug so deep on KSP (yet), but it's my current understanding that the CFG files are a kind of "prefab building tool" and, so, they are the default values that end up on the prefab. (take this information with a huge grain of salt)

Share this post

Link to post

Share on other sites

Is it possible to have TweakScale only scale in one direction? ie: have a wing and stretch it front to back (to make it wider), but keep the length the same?

Wouldn't be easier to accomplish same result with B9Partswitch or Firespitter plugin to change part mesh to one of specific size ? You could even choose better texture for such part that is extended only on one axis, instead of messing with tweakscale. Depending on texture for that part, but not all textures would look good if stretched only to one direction.

Wouldn't be easier to accomplish same result with B9Partswitch or Firespitter plugin to change part mesh to one of specific size ? You could even choose better texture for such part that is extended only on one axis, instead of messing with tweakscale. Depending on texture for that part, but not all textures would look good if stretched only to one direction.

I'm trying to not have too many variants of a part. I would prefer if TS could stretch in a single direction as well as all three directions.

I may just make 3 base parts of each part, stretching them as required (I want a 2x and 3x original length)

As it is, I'm including configs for installs without TweakScale, and that is a major PITA. The five initial parts balloon into 35

Share this post

Link to post

Share on other sites

I was wonder what priority this bug was. I ask because 1 of the 2 the reasons I use tweakscale is aesthetics, so this bug is a major issue for me. I understand my priorities aren't yours so I was wondering if you knew when you might start working on it. Thanks!

After tacking down the planned issues for next release ("Room for Scaling" :P), I will repriorise the remaining issues.

That Big Refactoring I want can wait a bit, as it appears, so it will worth to give the current codebase some love now (it will be migrated to the new later anyway).

The Anisotropic scaling (suggested by @linuxgurugamer some posts behind), on the other hand, appears to demand some internal changes that apparently will be handled easier on the new architecture. This will confine inevitable bugs to specific "blocks" of code too, so it will be safer too. (there's a saying here, "Gato escaldado tem medo de água fria" - "scalded cat fears cold water"). I'm planning to be very careful on adding new scaling code.