Lisias

Not impossible, but unlikely. And even by this happening, the atribute would not had vanished from the Module... I created a new sfs on my test bed and launched something with rovermate (roverBody.v2) attached. This is what I got: PART { name = roverBody.v2 cid = 4294425198 uid = 1796168931 mid = 1153095492 persistentId = 761111113 launchID = 41 parent = 0 position = 0,1.1615695953369141,-1.3355612615839618E-08 rotation = -0.707106829,0,0,-0.707106829 mirror = 1,1,1 symMethod = Mirror istg = -1 resPri = 0 dstg = 0 sqor = -1 sepI = -1 sidx = -1 attm = 0 sameVesselCollision = False srfN = , -1 attN = right, -1 attN = left, -1 attN = back, 0 attN = front, -1 attN = bottom, -1 attN = top, -1 mass = 0.150000006 // HERE!!! Not only I have an attribute called mass (and not modmass!!!), but they are positive. TweakScale scales values by multiplying them to an exponent, that are always positive. There's no way to have a positive value going to negative by multiplying it with a positive multiplier (unless someone intentionally mangled the scale exponents?? something to be investigated). The scaling attributes are accessed by reflection, and TweakScale does not creates "temp" or "backup" attributes on the process. I don't know how TweakScale could be involved on this mess (except as a screaming victim - TweakScale is pretty vocal when being murdered... ) I also noted that "your" cost was renamed to modcost on your savefile. On a personal note, I find these renaming extremely ... less than desirable. It appears that something is replacing the stock Modules with derivatives, and these derivatives are "rewriting" the well known game interfaces to something else. I think this is somewhat hostile to the Modding Scene - why not moving these new values to a dedicated module, keeping compatibility with everybody else? ----- POST EDIT ---- Found something related here. However, this is not available on the KSP API for the Part!!! And I didn't found anything mentioning it on Stock and DLC. ----- ANOTHER POST EDIT ---- Scaled down the roverbody to the minimul the interface allows, 10%. Got this on the SFS: mass = 0.000149995089 So I edited the SFS file and manually shoved 1% on TweakScale: MODULE { name = TweakScale isEnabled = True currentScale = 1 defaultScale = 100 Loaded the game, switched to the crudge on the runway and saved the gane again. The poor thing wasn't even rendered anymore. mass = 9.99999975E-05 HOWEVER... Yeah, I found modMass and modCost on the thing! rTrf = _default modCost = 24498.2188 modMass = -0.149999857 moduleVariantName = White Well, I think modCost and modMass are internal data used by the PartModule, and since they are not published on the KSP API, I think these are protected or private atributes from the part. Since TweakScale don't mind these details, as it changes values by Reflection, theoretically it's possible to mangle these values - as long someone write a Scale Exponent telling TweakScale to do it - but no default patch mention them. So, no, TweakScale must not be mangling on them In a way or another, the bigger question remains: where is mass on your savegame? Who is removing this atribute from that module? ------------------------- Yes, it's a bug. But until the moment, it was not determined to be related to TweakScale - TweakScale appears to be the screaming victim on this mess. It's the same thing as these two problems reported earlier - that I didn't reproduced on my rig, by the way, besides installing B9PS with some other combinations of add'ons (that used to cause problems in the past, but not nowadays). So, until someone manage to build a very straight forward way of forcing this problem (install KSP, TweakScale, B9PW and this add'on), I`m afraid I can`t be of too much help - I just can't fix what I can see (and it`s on TweakScale), and until the moment, I could not reproduce this on TweakScale (and I tried). I will check your KSP.log by night, but I have little to no hope to find something I can fix. In a way or another, TweakScale is deprecating all patches non Stock and non DLC, with third party support being implemented on the TweakScale Companio Program. Assuming this is not a bug on some third party patch or part config and TweakScale needs to support something new, this something new will be implemented on a Companion.

Well, I think this solves the case. Things are calculated on KSP more or less as follows: DEF main(): WHILE NOT quit_flag: threadlist = list() do_something() FOR craft IN World.CraftsUnderPhysicsRange: t = Thread(callable = handle_craft, args = (craft,)) t.start() threadlist.append(t) do_something_else() FOR t in threadlist: t.join() RETURN DEF handle_craft(craft : Craft): FOR part IN craft.part_list FOR module IN part.module_list: module.update() RETURN That's a python inspired pseudocode. You fire up KSP, it initialised itself, and eventually it enters on the game main loop. While you don't quit the game, it stays in that loop doing a lot of things, and some of these things involves updating the living crafts. To save time by taking advantage of our modern CPUs with multiple cores, the most threads you are able to fire to paralelnize the job, the better. It's the reason I simulated it with that Thread stunt - every craft will be updated using a CPU core, if there's cores enough. The cannonical way of firing threads is what you see above: we create them, fire them up and added them to a list, and the last thing we do before finishing a cycle (in KSP's case, a frame on your monitor), is to "join" all of them on the main thread, i.e., the main thread will check if every threat is already finished and the ones that are not, will halt the main thread until they are finished (imagine a multilane road joining the lanes into a single one). And this is where Exceptions plays havoc with our crafts as there are many forms of finishing a thread: the desirable one is when the code reaches the RETURN normally, but other ways can happen. If any update of a module module of any of the parts throws up an Exception, the thread is killed on the spot - finishing prematurely and leaving a lot of modules without having their updates called! (i.e., everything that would be updated after the borking module being called). And then other things that need that modules updated will start to throw Exceptions too because data will be inconsistent, and then other threads will die too, on an avalanche of bad news to your gaming. And this is the reason that Exceptions *MUST BE DIAGNOSED AND FIXED*. (a few ones are safe to be ignored, of course, but since we don't know KSP's source code in order to determine when an uncaught Exception will doom our game or not, we need to be conservative on our approach!). Of course, there's a thing called TRY CATCH, where you intercept the Exceptions and do something about instead of having the thread killed. For example: DEF handle_craft(craft : Craft): FOR part IN craft.part_list FOR module IN part.module_list: TRY module.update() CATCH Log.Error("Bad doggy {:s}, no donut for you! You screwed up {:s}!", module.name, craft.name) RETURN So, if instead of using my previous version of handle_craft, we use this one. If a module's update borks, instead of killing the thread the code will log something and then will keep running, calling the update of the next module. The borked module will still be doomed, but everything else will keep working - minimizing the chances of something really terrible happening. You will still have a buggy game, but with way less collateral effects. However.... Every time you enter a TRY, the compiler generates a thingy called context on a place called stack, and everytime you leave the TRY CATCH (entering or not the CATCH block), the compiler generates code to clean up the stack. Handling contexts takes time, cpu cycles and a bit of memory and if you do it hundreds of times per frame, you ends up with a pretty mediocre frame rate. You can easily waste 10% of your potential framerate due this stunt. And yeah, KSP in the past was doing something similar to what I described above, and one of the reaons KSP is way faster nowadays (as long you don't blow up the GPU's VRAM) is because Squad are getting rid of TRY CATCHes on what we all "hot code". But without a TRY CATCH, an Exception will potentially kill the whole game!! So, a new revised handle_craft follows: DEF handle_craft(craft : Craft): TRY FOR part IN craft.part_list FOR module IN part.module_list: module.update() CATCH Log.Error("Bad doggy {:s}, no donut for you! You screwed up the {:s}!", module.name, craft.name) RETURN Doing this we still get our craft screwed up by Exceptions, but at least not all of them - most will survive the catastrophe (unless their modules borks too!). We save time and CPU cycles by only creating contexts once per craft, but the price we pay for this extra performance is dooming the craft those parts have a problematic Module. This last version is near what KSP uses nowadays, I think. Now, with this wall of text (hopefully) on your head, lets check your log: [LOG 23:52:18.934] [TweakScale] WARNING: No valid member found for diameter in Part for <unk> [LOG 23:52:18.954] [TweakScale] WARNING: No valid member found for mass in TweakScale for roverBody.v2 TweakScale runs outside what we call "hot code" - once you fire the craft, all the job is already done (except by some details on unpacking the craft, but they happen only once), so I (and the previous maintainers) shoved safeguards everywhere. You found one of them, when someone tells TweakScale to apply a Scaling Receipt on a Module, but the Module is missing some of the things that receipt is telling TweakScale to do. We have a Part called "<unk>" - to tell you the true, that part is missing the partName and so TweakScale can't name it! - missing the diameter attribute. So TweakScale logged the problem and ignored this step of the receipt. But... Why we have a Part without a name? What else is missing besides the name? Such missing things are playing havoc on the hot code of some other Module? All of these are questions we need to answer in order to understand why your game is borking. The second line is yet more interesting. The part "roverBody.v2" is missing the mass! But this part is a stock one, I know it, and this part must have mass. Just for the sake of completude, let's check the "source code" for this part, it's on a file called <KSP_root>/GameData/Squad/Parts/Command/probeRoverBody_v2/probeRoverBody_v2.cfg : PART { name = roverBody_v2 module = Part author = AlexanderM MODEL { model = Squad/Parts/Command/probeRoverBody_v2/probeRoverBody_v2 texture = QBE_New_diffuse, Squad/Parts/Command/probeCoreCube/QBE_New_diffuse texture = QBE_New_NRM, Squad/Parts/Command/probeCoreCube/QBE_New_NRM } rescaleFactor = 1 node_stack_right = 0.510226, 0, 0, 1, 0, 0, 0 node_stack_left = -0.510226, 0, 0, -1, 0, 0, 0 node_stack_back = 0, 0, 0.22407, 0, 0, 1, 1 node_stack_front = 0, 0, -0.22407, 0, 0, -1, 1 node_stack_bottom = 0.0, -0.746285, 0.0, 0.0, -1.0, 0.0, 0 node_stack_top = 0.0, 0.746285, 0.0, 0.0, 1.0, 0.0, 0 TechRequired = fieldScience entryCost = 6200 cost = 800 category = Pods subcategory = 0 title = #autoLOC_500349 //#autoLOC_500349 = Probodobodyne RoveMate manufacturer = #autoLOC_501633 //#autoLOC_501633 = Probodobodyne Inc description = #autoLOC_500350 //#autoLOC_500350 = A sturdy housing for a robust probe and battery system - no assembly required! Thought intended as the body for surface rovers, we've been told by our most day-dreaming of engineers that the possibilities are endless! While it has a Stability Assistance System, the RoveMate lacks reaction wheels so bring some along if you want to hold that attitude. attachRules = 1,0,1,1,0 mass = 0.15 // <<<< HERE!!! THE MASS IS HERE!!!!! dragModelType = default maximum_drag = 0.2 minimum_drag = 0.15 angularDrag = 1.5 crashTolerance = 12 maxTemp = 1200 // = 1200 explosionPotential = 0 vesselType = Probe bulkheadProfiles = size1 tags = #autoLOC_500351 //#autoLOC_500351 = command control (core kerbnet probe rover sas space steer <yada yada yada> } Nope, Squad didn't messed up the config for this part, the mass is there. So why TweakScale didn't found the mass of that part? Who removed it? Weird things happens when you have a part with ZERO MASS (this used to crash the game on the past, but nowadays a safeguard was build on KSP to prevent the crash). So we have another thing to diagnose on your rig. TweakScale, for sure, DOES NOT removes any attribute from any part. It only removes the whole TweakScale section from a part when it detects well known conditions where TweakScale would behave terribly (as when someone shoves more than one fuel switch on the part, a situation where the fuel switches misbehave and induces TweakScale to bork). So I'm pretty confident that it's a problem on one of the other Add'Ons you installed together TweakScale! (perhaps both of them, or perhaps only when these two are installed together, as the fuel switches stunt I mentioned). I will check the whole KSP.log by the morning and will get back to you with any findings.

Looks like a problem on the colliders. I have similar issues using the wheels from Firestpitter, by the way. By some reason, the wheel collider (that it's embedded with the wheels mesh) is not being recognized, and the tires are so... "etereal" and it sinks into the ground until some other collider on the mesh is found. It's not TweakScale related for sure, I did some tests with and wihout TweakScale and got the same results... Sounds like something borking in NRE`s, killing the thread and so things that should had ran, was not running.... The KSP.log would help. It would pinpoint something borking mentioning TweakScale (and, so, perhaps TweakScale would be involved somehow - but it smells more like a victim than a perpetrator by the way you describes it). Are you sure that crafts not using TweakScale does not presents that behaviours you mentioned?

Whe the game crashed. The Player.log is important too, as KSP.log don't have all the information we need.

Editor Extensions Redux can't help on this? The additional editing tools worths the install by themselves, by the way.

Welcome! I'm working on supporting the new 1.11 parts right now, I think I will have them implemented on the weekend. Adding support for the parts is not a big deal, but adding support for the new cargo and inventory modules is going to give me some trouble...

Well, since we are here, post the log and let us give a look on it.

He and a huge amount of people! That source of crashes was happening on Windows and KSP <= 1.7.3 . On KSP 1.8.0, Squad updated Unity to 2019, and this solved some problems that were plaguing KSP, the one that sparked this thread being one of them. However, there's a major bork on the Unity minor version currently in use by KSP that it's also leading to crashes - so, in essence, vendors are stilk screwing up Squad. Check the thread below to see if you issue fits. The most informative posts are on the last pages, when we apparently nailed the problem. But, until this moment, a work around wasn't found yet... Anyway, if this fits your issue, please follow suit on posting your logs and commenting something on the issue track. The more people affected complains, bigger the chances we have to get this fixed.

Humm... I did forget about this. I will do my best to find time to see about this...

I have absolutely no problem on sticking with 1.3, but... had you tried 1.7.3? It's my main gaming rig until now, and it's working pretty fine to me. There're some good parts on the Making History, and perhaps Serenity would allow you do do some interesting stunts on the plot? In a way or another, I have a lot of add'ons backported down to 1.3 if you need something with bug fixes (under the KSPU hierarchy - no official support, but yet it's more support than you have now, so...), and I have no problem on backporting something else to 1.3 if there's a demand. TweakScale, in particular, is way more robust on 2.4.4.x series, and backporting it to 1.3 is a breeze now after the last batch of refactoring. Cheers!

ANNOUNCE Release 2.4.4.5 is available for downloading, with a last minute fix. This build fixes some embarrassing borks on the default patching. Special thanks to @AccidentalDisassemblyfor detecting them! (this time I reacted fast! ) See OP for download links. This Release will be published using the following Schedule: GitHub, reaching first manual installers and users of KSP-AVC. Right now. CurseForge -Right now. SpaceDock (and CKAN users) - Right now. Being another important bug fix, and being it the only change from the last version, I shoved the release everywhere at once.

I understand your objections, but this solution aims to prevent unattended people of running the game on a probable inconsistent and dangerous state. Most people just click on the "OK" button without caring, and your description of your objections just comproves the thesis! Yes, I want people to pesky me here in order to get rid of that FATALities, and if they choose no to do so, I need to be absolutely sure it's a conscious choice, and not some automatic reflex on clicking on "OK". I do not want, never more, under no circumstances, to have again users here complaining because "TweakScale ruined his 3 years old savegame". If this is so much a problem for you, I can compile for you a version without any warnings - but, by then, I will not provide support neither accept responsibilities (i.e., no bug reports) on what can happen on your rig. You will be on your own. Good for you, you survived the Russian Roulette. But not because the problem was imaginary, but because I (and/or Squad) cooked a lot more safeties on TweakScale (and/or KSP) that apparently is working most of the time. At least for while - anything changes, even a new mishap of mine, and weird things that was working by plain luck start to bite your SAS. A Russian Roulette with a 100 bullets capacity on the cylinder and only one bullet on it it's still a Russian Roulette. The name for what you want me to do is Normalization of Deviance. Sorry, I will not do it. Again, I can compile a specialised version of TweakScale for you, without any of the peskiness you don't like as long you agree that I will not provide any kind of support for you.

If you compare it with bigger and more complex games yes. On the other hand, comparing to some others, not that much... Different teams, different scopes, different models of revenue. It's hard to draw a parallel. Perhaps with Space Engineers or Empyrion? Utterly needed. Launching vehicle with some older parts leads to Instantaneous Craft Annihilation (from now on, ICA) due heat (!!!). This can't be worked around with cheats, but KSP Recall 0.0.6 (currently beta) fixes it. Launching pretty heavy vehicles (above 120 tons, my test bed uses a 500tons one) shoves the craft below any colliders on the launch point, placing it directly on the PQS ground level - also inducing ICAs. Worst, by switching scenes (or, better yet, by doing something that packs the craft), when you switch back and the craft is unpack, if there's anything with a collider under the craft and on the ground, the craft is placed inside it and you have ICA again. This can be worked around with the Indestructible Cheat, but this is annoying on switching crafts. World Stabiliser cannot help on this, as it tries to fix another problem and not this new one. Besides the panels, the landing lights on my crafts are always "lit" - but they only casts light with the lights on (U key). All of these hints me they are failing in properly initialise something on craft launch (and/or on the unpack) what suggests a common root cause. I hope they find and fix the root cause, instead of patching the effects where they we find them, what IMHO is the current M.O. around here and the underlying reason by so many bugs keep resurrecting on every new release, as well some clearly related new ones being spawning when new features are created.

Excellent! But so I don't understand why the patch above failed, because TS does kinda the same, but using introspection... Anyway, by night I will check this - I must had done something stupid on that patch... Welcome. I understand this solution is less than desirable, but there're so much time available to check and pursue every new change (and bug introduced) on each new KSP version, so Authors need some time to understand what's happening to cope with - for example, I managed to understand why some old parts are blowing up due heat on launch, but now I realised that heavy crafts are blowing up too!! (and heavy crafts are one of the reaons people use TweakScale...). All of this can easily overwhelm our free time - yet more to who works on this time of the year, as me... I'm pretty sure these parts are suffering something near the heat problem I think I solved on KSP Recall 0.0.6 (beta!!!), so there's a good chance I can manage to cook a workaround (if someone else don't do it first!). But for now.... Humm... When you rolled back, you did the installing one by one, or just moved the GameData's folder contents (except Squad and SquadExpansion, of course) to the 1.10.1 one? These errors should had happened on 1.11 too. In a way or another, I found the problem - such a amount of FATALities are usually related to installing something twice on the system. Essentially what's happened on you rig: [LOG 18:05:46.140] Config(@PART[Tube1p5]) TweakscaleMakingHistoryConfigs/Structural/@PART[Tube1p5] TweakScaleMakingHistoryConfig was an old add'on that was retired (and I think incorporated into TweakScale - that was before my time here), and since now TweakScale is the canon patches for Making History, there's no need for this add'on anymore. Frankly, I can tell you you don't want it, because TweakScale's patches were revamped and some little details fixed. Remove TweakScaleMakingHistoryConfig from your GameData and everything will be fine. In time, can you check the licensing terms of the TweakScaleMakingHistoryConfig and, if the license allows it, can you pack it and send me a copy? I can't find a pristine copy of it anywhere in the Web (it was distributed once on SpaceDock, but as I said, it was withdrawn...) I need to check if TweakScale original MH parches came from it and, if yes, I need to proper acknowledge it - current patches are a complete rework from scratch, but until 2.4.3, that patches were the canon and I think that guy deserve the credit for the work.

Because you would ended up with 9 times more storage than the original part, not 3! Suppose you have a container 3 meters by 3 meters, with slots with 1m³ each. So you have 9 slots, and the container has 9 m³. By scaling the container to twice the size, you till have a container with 6 meters by 6 meters, or 36m³. BUT, by scaling the slot's size and the quantity of slots on the container, you will end with 36 slots with 3m³ each = 108m³ - the numbers don't fit. (unless you are a fan of Doctor Who, of course! ) Damn. Or I did something wrong on the patch, or I will have to follow suit with you and brute force my way into the problem. I will give it a shot by the night, stay tuned!

This explains your interest on support for ModuleCargoPart and ModuleInventoryPart. What I plan to do is to support these things the same way I did on KIS: allowing the user to choose to scale the quantity of slots, or the size of each slot (those quantity remains the same). It's essentially what I'm working on now, and I expect a new TS release (or, at least, a new 2.5 Beta with it) in a couple weeks. But since this is not necessarily what you may want to do with your part, and since TweakScale will provide Exponents aiming to support the stunt I mentioned in the previous paragraph, there's a chance you would prefer something else. I think that, so, the solution for you is the SCALEBEHAVIOR. Behaviours are a way to override the Exponents when needed. For example. there's a Behaviour for Engines because their weight scale at 2.5, and not 3 as (almost) all the other parts. And since TweakScale nowadays just don't touch anything non Stock or DLC, you can rest assured that TweakScale will never touch any of your parts, so anything you do will be preserved now and in the future. Third parties, however, may be a problem on it. In a way or another, your SCALEBEHAVIOR should be something like this: TWEAKSCALEBEHAVIOR { name = KSPIE-ModuleInventoryPart MODULE { name = TweakScale TWEAKSCALEEXPONENTS { name = ModuleInventoryPart InventorySlots = 3 # Use this one //packedVolumeLimit = 3 # OR this one. NOT BOTH! } } } and then @PART[KSPIE-RadialCargoContainer]:AFTER[TweakScale] { #@TWEAKSCALEBEHAVIOR[KSPIE-ModuleInventoryPart]/MODULE[TweakScale] { } %MODULE[TweakScale] { type = free # for radial parts, usually free is the choice } } I agree this is a bit convoluted, but I could not think on anything so better than could worth changing years of already made patches, so... Of course, you may want to customise the numbers above. Perhaps you would like 2.95 as the InventorySlots exponent (for any reason you could think of, as the need to cope with the extra mass needed by the extra slot's walls), or perhaps 3.1 on the packedVolumeLimit (idem). You can tinker with the mass exponent too, crewed parts on TweakScale patches has a mass exponent of 2.5. Toy with the numbers if you are in the mood, sometimes we get results more related to real life (as someone did in the past by using 2.5 with the engines) playing "what if". (boy, I miss the times in which I could tinker with the parts by mangling the craft files, now I need to restart KSP...)

Yes. It doesn't helps on KSP 1.11 . The craft already spawns under the runway. Interestingly, I spawned that 500 tons rover using Vessel Mover and let it place it gently into the ground.. .Dude, that thing moved up the rover to 300 meters, and started to down it to the ground at less than 0.5M per second! It took minutes to lay the craft on the ground! This hints me that the weight is the key. I think that something on spawning the craft is placing the rover on the PQS ground level, instead of firing a ray from the skies into the ground to find the runway collider. Then, before the physics kicks in, something else finds the nearest collider and moves the craft there - but the routine used, by some reason, uses the weight of the craft to decide the speed the thing will move into the proper place (as it happened with Vessel Mover!), and with very heavy crafts, things ends up too slow and the physics kicks before the craft is on the right place... In time, I just checked. It's not on spawning the craft, it's on unpacking the craft! I just tricked KSP into spawning the 500tons rover (using the cheat), then I unchecked the cheat, then I moved to the Space Center. Then I moved back to the craft, and it exploded too. Then I respawned the rover using the cheat (again), drove it to the grass (on the PQS ground level), unchecked the cheat (again) and moved to the Space Centre. Now, by going back to the rover, it didn't exploded! So I have confirmation for my thesis - the craft is being spawned on the PQS ground level, and heavy crafts are failing to be placed over the neared collider on unpacking. Well, another confirmation for the craft's weight thesis. :)

Now you lose me, I think I need further information about what you need to do - otherwise I may be only making things worse... About extending stock classes, I tried it some time ago and got some unwanted misbehaviours... Once you extend a stock Module, every single instance of the original module will be replaced by yours instead - no matter what you call it. I was trying to extent the ModuleControlSurface (to tell you the true, I was trying to tinker with Atmospheric Autopilot that does that), don't remember the details, but let's call this new class ModuleControlSurfaceHacked. Well, every single part on the game ended up instantiating the ModuleControlSufaceHacked, and not only the parts I created using explicitly this Module. Worst, on saving the craft (and the savegame), every part is serialized using the ModuleControlSurfaceHacked. And so you can't export crafts or remove the add'on without needing to manually edit every single craft and savegame to rename ModuleControlSurfaceHacled back to ModuleControlSurface. I found, some time ago, a post on this forum explaining something that leaded me to conclude that in some previous KSP version (older than 1.4 for sure), you could do this stunt because KSP would load the Module by the name you used on the ConfigNode, and not by the topmost extending class. On that times, what you want to do would be safe, but nowadays, I think you are going to have more problems than the one you want so solve worths. What I would do instead is creating a "Helper" Module that would monitor your Module of Interest and then call TweakScale to do what you need when something happens - it's essentially how I implemented support for FSBuoyance for Firespitter, and also how I implemented that fancy scaling on KIS (you can scale the number of slots, or you can scale the size of each slot). I think this way is safer nowadays.

Can't really tell. I had had problems in the past on editing root nodes using MM, and didn't found a way to workaround it and what you asks implies on creating a new root node. I didn't managed to do it (what's different of not being possible however). It's the reason I gave up and just allowed some ScaleExponents on TweakScale Companion for Firespitter to duplicate the deprecating ones on TweakScale "core" for while - I'm going to get rid of anything non stock/DLC on the main TweakScale, and replacing them with optional Companions - what will prevent a lot of problems TweakScale had in the past to happen again. IMHO, if you have some disagreement about how TweakScale scale things, the best line of action is to create a new ScaleExponent for you and then apply them on the parts you want it (after removing any previous TweakScale patches on that part). I remember you asking in the past about the Converters, for example. I could not fulfil your request because that would break some assumptions that every TweakScale user have about the Converters, breaking savegames. But this doesn't means you had a bad idea, au contraire - I just could not fulfil it on the Stock TweakScale without an extended behaviour, otherwise every station already made will unexpectedly run out or resources. And so on. That can create some situations nearly impossible to detect without a lot of hard digging (and lot of wasted time). But if you create your own customised Exponents and apply them using your patches, this will keep things easy to track on the MM log. I got good results with 120tons, a hacked Driftless and Wheels without auto dampers. Less than 40 to 50 tons worked well without Driftless. So what we need is somehting that would turn off the Spring/Damper Auto on rest, and restore them when moving. That made the trick for me, at least. 500 tons, however... I made a Ore Train using Serenity hinges as connectors. Even driftless didn't helped on it. I'm trying that Ore Train on KSP 1.10.1, and is just became a fur-ball after less than an hour. So I'm not really sure if Driftless is really helping at all on KSP 1.11 - it surely didn't helped on 1.10.1. On the other hand, that monster didn't exploded on launch on KSP 1.10.1, so we definitively have a new misbehaviour on KSP 1.11.0 . Squad forgot some initialisation procedure for sure, probably the same procedure those absense is exploding some old parts due pornographic amounts of heat (the thing ChillingOut from Recall 0.0.6 is trying to overcome) coming from nowhere at launch. Interesting enough, my laggy rig can be useful sometimes - I noticed that by one or two frames the craft was below the runway before exploding - I think KSP is spawning the craft on the ground level, instead of spawning it over the runway and due the extreme weight of the craft, whatever is pushing up the craft is not being able to do so fast enough.... What hints me that perhaps the problem is the CPU load. The PIDs that controls the Wheel's dampers and springs may be skipping some frames due CPU overload, and then they start to overshoot themselves. That would explain why Driftless didn't helped at all on KSP 1.10.1, but apparently did some good on KSP 1.11 - on 1.11, Squad implemented something called "Anchoring", and Driftless may be doing some weight lifting on the problem, making things easier to that Anchoring.

The last one on the GameDatabase will prevail. The ScaleExponents are stored on a dict, so any duplicate will overwrite the previous one. You raised a very good question - such a stunt can potentially ruin the savegame - next release of TweakScale will have a Sanity Check for it! The code uses introspection to check the type of the atribute being scaled, and apply the correct operation. floats are operanted with float operators, etc. It's not different from using a variable, standard C# coercion applies. Still about this behaviour, follow some findings on KSP 1.11: 1) Light crafts with scale up wheels drifts a lot, unless you deactivate the Spring/Damper Auto setting. 2) Somewhat heavier crafts with scaled up wheels don't drift too much, if at all. 3) Really heavy crafts with scaled up wheels drifts heavily no matter the Spring/Damper settings. 4) Using Drifitless from KSP Recall solves the drifting in all cases, as long the Spring/Damper is deactivated. With the Spring/Damper Auto activate, there's a very tiny [the drift is proportional to the weight and/or part count!] drift even with Driftless installed. Your mileage should vary, as I'm convinced that this is related to how much the physics engine taxes the CPU - my heavier designs were yellowing the M.E.T. display all the time, so perhaps the problem could not be exactly weight, but part count. Really heavy rovers are blowing up on launch, unless you activate the No Crash Damage cheat. Yep, you read it right, the problem is not the joints, the problem is that KSP is "crashing" the heavy crafts on the runway at launch. You can deactivate the cheat after launch, the cheat is only needed on launch. Spawning the crafts with Vessel Mover also works, what hints me that this is not a physics engine problem, but again something not being initialised soon enough while launching crafts (the same problem with some older parts, burning up instantly - the reason for the ChillingOut module from KSP Recall 0.0.6.0 Beta).

Yes. Work in Progress at this time. There are 2 new modules and 24 new parts I need to map and support, but since KSP 1.11 release date I only had time to work on it this weekend! Version | ReleaseDt | ∑Modules | ∑AllParts | ∑AllDeprecated | ∑Stock | ∑MH | ∑Serenity ------------+----------------+------------+------------+----------------+----------+--------+------------ 0.22| 2013-10-16 | 31| 156| 0| 156| 0| 0 0.23.0| 2013-12-17 | 36| 157| 0| 157| 0| 0 0.23.5| 2014-04-01 | 37| 157| 0| 157| 0| 0 0.24.0| 2014-07-17 | 38| 158| 0| 158| 0| 0 0.24.1| 2014-07-24 | 38| 158| 0| 158| 0| 0 0.24.2| 2014-07-25 | 38| 158| 0| 158| 0| 0 0.25| 2014-10-07 | 38| 153| 0| 153| 0| 0 0.90| 2014-12-15 | 41| 168| 0| 168| 0| 0 1.0.0| 2015-04-27 | 69| 245| 1| 245| 0| 0 1.0.1| 2015-05-01 | 69| 246| 1| 246| 0| 0 1.0.2| 2015-05-01 | 69| 246| 1| 246| 0| 0 1.0.3| 2015-06-22 | 71| 250| 1| 250| 0| 0 1.0.4| 2015-06-23 | 71| 250| 1| 250| 0| 0 1.0.5| 2015-11-09 | 74| 263| 1| 263| 0| 0 1.1.0| 2016-04-18 | 80| 267| 0| 267| 0| 0 1.1.1| 2016-04-29 | 80| 267| 0| 267| 0| 0 1.1.2| 2016-04-30 | 80| 267| 0| 267| 0| 0 1.1.3| 2016-06-21 | 80| 267| 0| 267| 0| 0 1.2.0| 2016-10-11 | 89| 275| 0| 275| 0| 0 1.2.1| 2016-11-01 | 89| 275| 0| 275| 0| 0 1.2.2| 2016-12-06 | 89| 275| 0| 275| 0| 0 1.3.0| 2017-05-25 | 90| 276| 0| 276| 0| 0 1.3.1| 2017-10-05 | 90| 276| 0| 276| 0| 0 1.4.0| 2018-03-06 | 92| 279| 12| 279| 0| 0 1.4.1| 2018-03-13 | 94| 340| 12| 279| 61| 0 1.4.2| 2018-03-28 | 94| 340| 12| 279| 61| 0 1.4.3| 2018-04-27 | 94| 340| 12| 279| 61| 0 1.4.4| 2018-06-21 | 94| 340| 12| 279| 61| 0 1.4.5| 2018-06-26 | 94| 340| 12| 279| 61| 0 1.5.0| 2018-10-15 | 94| 340| 19| 279| 61| 0 1.5.1| 2018-10-17 | 94| 340| 19| 279| 61| 0 1.6.0| 2018-12-19 | 94| 340| 27| 279| 61| 0 1.6.1| 2019-01-09 | 94| 340| 27| 279| 61| 0 1.7.0| 2019-04-10 | 95| 342| 19| 280| 62| 0 1.7.1| 2019-04-30 | 106| 371| 19| 280| 62| 29 1.7.2| 2019-06-12 | 106| 371| 19| 280| 62| 29 1.7.3| 2019-07-11 | 107| 388| 19| 280| 62| 46 1.8.0| 2019-10-16 | 108| 398| 20| 283| 64| 51 1.8.1| 2019-10-29 | 108| 398| 20| 283| 64| 51 1.9.0| 2020-02-12 | 109| 399| 22| 284| 64| 51 1.9.1| 2020-02-27 | 109| 399| 22| 284| 64| 51 1.10.0| 2020-07-01 | 117| 409| 22| 292| 66| 51 1.10.1| 2020-07-28 | 117| 409| 22| 292| 66| 51 1.11.0| 2020-12-17 | 119| 423| 24| 308| 66| 49 On a side note, or I have a bug on my "database builder", or Serenity lose 2 parts on KSP 1.11..... About this drifting, I found that turning off the Spring/Damper Auto eliminated the drift on KSP 1.11 and KSP-Recall (instrumented to shove Driftless on KSP 1.11). I let the computer running with the craft sitting on the runway with brakes applied for 1:30 hours, and the craft didn't drifted a single degree. I'm repeating the test without KSP Recall to see what I get, but in a way or another, I found the root cause of your problem. A new module for KSP Recall will be created to handle the wheels. I just need to know if Driftless helped on the issue, or it's just placebo on it.

Humm... You should not be drifting on KSP 1.11, they implemented that "anchoring" stunt exactly to prevent that. I tried KSP Recall on KSP 1.11, but it apparently didn't made (good) differences on me - but it screwed up the "anchoring" when the craft is not visible by camera, and so I decided to withdraw Driftless from 1.11 . I wonder if it would not make a difference here, since even the anchoring is failing on your wheels. What is the weight of your craft? I'm trying to reproduce the problem here, but no dice . [edit: I reproduced the problem on a 120ton rover using 240% scaled up wheels. I will give KSP Recall a try on it.] Thanks! What you are describing happens when an exception is thrown when KSP runs the code that "attaches" a part into the vessel. Of course, this doesn't happens on a "vanilla" instalment, otherwise I would not had released the thing, what implies there's something on your rig causing it. Since 2.4.3 works, I'm guessing it's something on the Variant support. And the parts being affected supports this thesis. I'm investigating it. At the time the latest 2.4.3.x release was issued, it was not known if KSP 1.11 would change something that could render TweakScale playing havoc on the crafts, as it did on KSP 1.9. The bad side of TweakScale misbehaving is that things that were scaled before are bluntly descaled - or, worse, badly scaled with some non visible problems being applied to the craft - and then you save it, launch it and just then you realise the part's resources were not scaled at all. The same also happens on every living craft on the savegame you load, so this is the reason I used that scaring message on TweakScale: when things go bad, boy, they really go down through the tubes. Nowadays it's known that KSP 1.11 didn't changed anything on TweajScale, so you can ignore the message for now. -- -- -- POST EDIT -- -- -- DUDE, your player log is scattered with Exceptions. Really, there are about 3016 of them. 2727 are NullReferenceExceptions. TweakScale is not the only victim of the problem, it's the only one suffering visible effects. It's borking while creating the internal structures needed to scale things - what implies that such data is unavailable by some reason. At the point in which TweakScale is borking, the problem is on the prefab - something on the prefab is corrupted, and TweakScale trusts that prefact is upright. It worths to mention that KSP itself is borking due the problem: liquidEngineMainsail.v2 added to ship - part count: 10 (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) NullReferenceException: Object reference not set to an instance of an object at PartModule.get_HasAdjusters () [0x00006] in <f8bc9e2b903e48a5b248ab0083c07c62>:0 at PartModule.Save (ConfigNode node) [0x0005c] in <f8bc9e2b903e48a5b248ab0083c07c62>:0 at ShipConstruct.SaveShip () [0x00949] in <f8bc9e2b903e48a5b248ab0083c07c62>:0 at ShipConstruction.CreateBackup (ShipConstruct ship) [0x00000] in <f8bc9e2b903e48a5b248ab0083c07c62>:0 at EditorLogic.SetBackup () [0x0012a] in <f8bc9e2b903e48a5b248ab0083c07c62>:0 at EditorLogic.<SetupFSM>b__190_29 () [0x000f2] in <f8bc9e2b903e48a5b248ab0083c07c62>:0 at KerbalFSM.RunEvent (KFSMEvent evt) [0x0007b] in <f8bc9e2b903e48a5b248ab0083c07c62>:0 at KerbalFSM.updateFSM (KFSMUpdateMode mode) [0x00080] in <f8bc9e2b903e48a5b248ab0083c07c62>:0 at KerbalFSM.UpdateFSM () [0x00057] in <f8bc9e2b903e48a5b248ab0083c07c62>:0 at EditorLogic.Update () [0x00022] in <f8bc9e2b903e48a5b248ab0083c07c62>:0 UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Logger:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) So, in essence, your savegames may be being silently corruped as you play, because things are borking while being saved (to a craftfile, to a savegame, you name it), and Kraken knowns what is not being saved that it should. Without the full KSP.log I cannot further help - the KSP.log has a lot of information that is not logged on the Player.log. My best guess is a borked PartModule being shoved on some parts, as the Mainsail, and the KSP.log will tell me who is patching it, so I can try to pinpoint a suspect. In a way or another, I would rollback to KSP 1.10.1 on your place. Whatever is borking on KSP 1.11, is borking on the worst place possible!

As long no one shoves more that one fuel switch on the same part, B9PWS is fully supported as long as I know - I have no reports of problems, at least, and my sporadic tests didn't raised any problems: If you are unsure, build a mockup of what you are planning to do and then check if anything goes wrong - be advised that everything non-stock (or DLCs) is being gradually deprecated on TweakScale "core", with fresh support being implemented on the TweakScale Companion Program. -- POST EDIT -- Talked too soon. B9PS per appears to do not be a problem, but some parts using it are triggering some NRE on TweakScale. I will not list the problematic parts because this may be realted to some new features on KSP 1.11 that are in need to be initialised, but obviously old parts cannot initialise what they don't know that exists and KSP itself appears to fail to proper initialise some things (see KSP Recall 0.0.6.0 beta for info). In time, this finding can be related to this problem reported early.

God bless the Users - without them, developers would not have reasons to be blessed! It's more complicated. There's not a hardcoded rule for scaling things, each part can have it's own scaling receipt - but virtually all of them are classified into "categories", and the receipts are cooked for each category. For example, the weight of most parts are scaled cubicly, but engines and crewed parts are scaled by 2.5 (yeah, fractions!) - it was realised that this scaling is kinda more related to real life. Engines's thrust are usually scaled by 2.5 too (bigger engines has bigger moving parts, and this taxes the net result), but SRBs are scaled cubicly!!! So, SCALE THAT Clydesdale, BABY!!! Cheers! Near enough for most applications!

In the dark ages of 2.4.3.x , yes. But that was less than optimal - smaller wheels got incredibly strong by their size, and bigger wheels terribly weak and fragile. Scaling wheels now has a functional purpose, not only cosmetic anymore - and without nasty collateral effects! However, there're still some work to do.