Lisias

Good point. I initially thought on the upgradepipeline because it was used to fix up a bork with the control surfaces deploy position, that was playing havoc with Atmospheric Autopilot - so I jumped into the conclusion that if it would being used to fix something like this, it would also being used to do any kind of transformations. On TweakScale, I detected that whatever was shoving back into the craft data from the prefab (overwriting the ones read from the file) was being executed after OnLoad and before OnStart (where originally TweakScale had some migration code that suddenly became dead on the water), and this also hinted me on the upgradepipeline. Well, learnt something new today - rarely a bad experience. In a way or another, my last hypothesis was proven wrong. Since I have a craft file that explodes on launch, and the exact same craft rebuilt from scratch on 1.11 and that works, I'm KDIFFing the parts from both files looking for something weird and... Well, nothing is different to the moment. The parts that I identified as probable source of the problem (since changing them on the bugged file solved the issue) are the Mark2Cockpit, ServiceBay.125.v2 and cargoContainer - and these parts are virtually identical on both files, but small changes on the the fields: part persistentId pos, attpos rot, attRot, attRot0 link, attN And this is the last nail on the current hypothesis' coffin. So, being used to change values on crafts or not, the upgradepipeline is innocent on this one.

I'm interested on this, I'm fighting something similar on TweakScale. Can you zip the craft file and post it here? In the mean time, check if the root part of the craft is crewable. I could work around the problem by rerooting the craft to a part what holds no crew - any part should do, I rerooted mine to a nose cone! I'm still trying to zero into the problem, I'm registering my findings here. The upgadepipeline not being updated on the last few releases may corroborate my thesis - some things are being missed when loading KSP 1.10 parts into KSP 1.11 which introduced some new artefacts to deal with (and are not being done on loading 1.10.x crafts on 1.11). It should be something pretty stupid that once found we will all collectively facepalm ourselves while getting drunk after hours - these small pesky bugs are the ones that really plays havoc, huge mistakes are easily detected.

Announce Some Companions were updated! TweakScale Companion for Firespitter Code updated to cope with the newest TweakScale 2.4.4.x series TSCFS goes GOLD! CKAN, SpaceDock and Curseforge will be updated as time allows TweakScale Companion for Near Future Some mishaps on instalment checks were fixed TSCNF goes GOLD! CKAN, SpaceDock and Curseforge will be updated as time allows TweakScale Companion for Airplane Plus Some bugs on the patches were fixed. Thanks for AccidentalDisassembly for the heads up. TSCAPP is now Release Candidate! TweakScale Companion for KIS Code updated to cope with the newest TweakScale 2.4.4.x series TSCKIS is now Release Candidate! Companions promoted to Release are in the process to get their way into CurseForge, SpaceDock and CKAN - but it will take some more days due RL getting into the way as usual. Companions promoted to Release Candidate are in the final steps before going gold, no bugs are expected (what doesn't means there're none), no new features are planned to be added and no existent features will be withdrawn. Happy Scalings!

In the recent past, I remember some add'ons working only on Windows because they were hitting straight into the DirectX - so unless something had changed on Unity, this should be possible yet. I could not agree more, but there's a catch on it: on the URL->pathname transition. the url file://c/somepath/some.file.name could be translated into c:/somepath/some(file)name , c:/somepath/some_file_name , c:/somepath/some_file.name , etc. So even by replacing the original file access code (what's perfectly possible, I did something similar by replacing the while System.IO.File on a project of mine), you will still need to probe the filesystem for the many possible translations in the hope of hitting something on the filesystem. And this is what I think it's wasting time on the process - you would hit the filesystem multiple times looking for candidates, instead of going right into the spot. Of course there's a solution - use only dashes, dots and alphanumeric characters on naming everything on the game (some assets' names are translated into filenames), but so you would need to check and recheck every single possible pathname on the whole system - including Unity itself. In the end, perhaps a Doom's style AWD would be a better solution - or just the good and faithful ZIP files (Java's JAR style). Compressing the data files is saving some loading time on my rig (I'm using spinning platters), and everybody and the kitchen's sink are using multicore CPUs nowadays (so the CPU tax would be minimal, with huge net gains on loading - I/O is expensive). One thing that could also speed things a lot at least on lower end rigs as mine, is caching the downsizing of the graphical assets. I use Quarter Resolution on my rig (otherwise my framerate would plummet as I add add'ons on the thing), and this means that KSP is loading the full resolution assets and then downsizing them into memory on every boot. Caching the downsized assets would save a lot of processing on loading things for people that don't use Full Resolution. It would sacrifice a bit the first load, but from that point... Thanks! I really appreciated it! I 100% believe you - but yet, the bug collection is going bigger and bigger - some of them somewhat silly (as the Instantaneous Craft Annihilation due Heat on launching vessels on 1.11.0), but some others interestingly convoluted as this new one I just found and that appears to be something missing on the upgradepipeline (the same way I'm pretty sure that the ICA due Heat was due something missing on the launching the craft - perhaps the very same upgradepipeline?). Not to mention some old bugs reappearing now and then. Something on the Process is not working right, and I don't think this is something that will be solved by extra efforts from the development team - I really find it hard to pinpoint the team as the source of these problems (I'm not saying the devs don't make mistakes - we do it all the time - I'm saying that the development process is not helping on the prevention of bugs, neither on fixing the ones that pass through). In a way or another, the effects on the user base are being hurtful IMHO. I second that. I'm dying for The Barn to see the light of Kerbol!

METAR KSP 1.11.0 introduced a new misbehaviour. [Nope. This behaviour is there for some time, I detected it on KSP 1.11 by plain luck!] Some imported crafts from previous KSP versions are exploding on launch. To tell you the true, what's happening is that some crafts is being spawned at PQS ground level, even when there's a runway, launchpad or any other static with collider under the wheels - and so everything explodes due collision. The absolute weirdness if that the craft must be something like what follows: The root part must be a crewed part (command pod, crew cabin, doesn't matter - what's important is to be crewable) There must be a SEQ9 (probably any part with Storage Support) between the root part and the heaviest part. There must be a Service Bay (probably any part with Cargo support) between the root part and the heaviest part. The craft must be very heavy (130 tons on my tests). The thing must have wheels. Apparently TweakScale must be involved, but I can't rule out this happening without it installed - I had read some reports about not being possible to import older savegames into KSP 1.11. There're solutions, however, and they are somewhat astonishing: Build the craft from scratch on KSP 1.11; or By building the craft entirely on KSP 1.11, the problem does not happens! Reroot the craft so the new root part is not crewable; or Move the SEQ9 or the Sevice Bat or both to be out of the line between the root part and the heaviest part. It sounds like a mishap on the upgradepipeline thingy. Since I finally have two craft files with the same parts, one working and other not, I can stop chasing ghosts and try to do something about - there's something on the native craft file missing on the imported one, I finding what it is, I can cook something on KSP-Recall for it. I will keep the issue on TweakScale for while, as I only managed to reproduce the problem using scaled parts until the moment - but I nave good reasons to believe TweakScale is not involved, as my previous attempt to reproduce the issue without TweakScale was made already on the KSP 1.11.1 release, instead of creating the damn thing on KSP 1.10 and then importing it. Stay tuned, I'm finding my way out of this mess.

Lack of logic may not be the only explanation - perhaps it would be more of a side effect than root cause of the problem. They could be just overwhelmed by the back log, with some political deadlines being imposed on them and so they would just work to satisfy the metrics, instead of solving problems. "Issue solving" is a terrible metric, it favours fixing side effects instead of solving root causes, as solving root causes gets you no points on the end of the month's performance review - not to mention that by solving a root cause, the kludges made everywhere by the "issue solvers" would break, and so you will be bashed by reopening a lot of issues. Disclaimer: this is plain speculation based on my previous experiences on big companies, I have absolutely no inside information to support my speculations. No that much. Users are, usually, inclined to prefer fast rewardings and the Issue Tracker, by it's very nature, is not prone to fast rewarding. More over, some bugs are rally nasty and take a huge amount of effort to diagnose - no to mention the amount of efforts to solve it. On an environment where "issue solving" is promoted instead of "problems solving", these issues tend to be forgotten - wasting the time of the users that expended their free time diagnosing the problem instead of playing the game. And users are inclined to get liquided when this happens. There're a significant amount of people getting CTDs out of the blue for years, and yet no formal acknowledge or at least a work around were issued. People those big problems are ignored usually avoid reporting the small ones - what would be the point? The real big issue would not be solved, after all... Not only that. Bugs should be correlated with each other - if different bugs are 'fixed' by doing the same thing or by changing the same code, we have an evidence of a root cause being overlooked somewhere else. The same for recurrent bugs. Check when different bugs are reopened at the same time, what is an evidence of a real problem being ignored. Solve the problems, not the issues. That list should, ideally, be classified by game Version. Some things are broken only on some versions, while working fine on others. With these alternating on releases... I could not agree more. There's no doubt about this. Some people are bashing their arses here for years, creating work arounds for the worse bugs, or just plain fixing them. We would not be doing that if the game wasn't so great. However... The list of bugs don't stop growing, every single new release comes with an Axe being used on the user's toys, so the user end up having to choose to abandon his/her career on the previous game to start a new one on the new Release as some of his/her add'ons (or part of the add'ons) just don't work o the new Release. I heard somewhere else on this forum that more than 90% of the users just don't leave the Kerbin sphere of influence. Well, why they would do so? Every 3 or 4 months a new Release is issued that renders their ongoing game unusable and the user need to choose what's more important: the new release bug fixes and eye candies, or his/her current ongoing game - so most users just engage on fast, short gaming sessions that lasts no more than 3 or 4 months and that's it. I still playing 1.7.3, by the way. I do some things using the newer KSP versions to check the add'ons I author, but my long running gamings are still on 1.7.3 and I don't see this changing on the foreseeable future. In a year more os less KSP2 is expected to be launched, anyway - so I don't think it will worth the hassle to update my "production" savegames. What's a pity, because nowadays the game is faster, prettier, and with some new well finished toys to play with. But I'm not interested on restarting from scratch on every Release, neither I'm willing to withhold these pesky bugs that are never solved - not to mention some very cool add'ons that just don't work anymore, or are being crippled on the newer releases. So I download the newer KSP, play a bit with it, update my add'ons as time allows and on the very few occasions that life allows me to really play the way I like on KSP, I go back to 1.7.3.

May I suggest a patch switching the stock inventory support for KAS/KIS? (and vice versa, so the user can choose what support to use). I think we don't need to have a zero sum game on this, there're real value on both approaches.

Good! You know math! How about then: Now explain where this affects the core of my argument? You know, the reason because I created that example and ended up making a mishap late night before sleep. You need to download it again. I download things from Steam, and Steam tells me what changed between a Release and another. Making History has a new Release for 1.11.1, but the language packs were not updated - so you need only the main package. Breaking Ground, on the other hand, had new language packs too, so you need to download again the language pack you need. (You need to download the language pack for the main game too, as they also were updated)

I hope for a 1.11.2 release, but experience taught me to be skeptic about. If I understood correctly one recent altercation on github, bugs are being selected to be fixed based on "popularity", not severity or even criticality . I.E., if the bugs affects more than 50% (I'm guessing), it's fixed. Otherwise, it is not. It's, IMHO, a sad compromise with a "middle ground". And the problem I see with this is that the "middle ground" for a bug is not necessarily the "middle ground" for another one! Let's assume a product with 5 bugs, A, B, C, D and E. Bug A affects 30% of the user base, bug B affects 5%, bugs C, D and E affects 20%. However, and this is where things get hairy, the set of users being affected by these bugs are not mutually exclusive! Users are being affected by a collection of bugs, not only by one. So, users suffering the Bug B can also be suffering the A, C, D or E too. So, let's imagine the following scenario: 1) Users suffering from A are also being affected by B, C, D or E 2) Some users (obviously not all) being affected by C, D and E also are being affected by B. 3) Approximately half of the users suffering from C, D or E also suffers from the others C, D, E but not necessarily all I.E, CD, CE, DE - with only a few ones suffering all the C, D and E. How you decide what bug needs to be tackled down? How would you decide what to fix or not? Well, one naive approach would be to fix A, then try to fix C, D and E as time allows and completely ignore bug B - after all, only 5% of the user base is being affected but it. By time constraints, Bugs A, D and E were fixed - ignoring B and C.. Sounds reasonable? Perhaps, but it's wrong! People that got A and C will still be liquided off because of C. People suffering from B, so we have at least 25% (5% of B and 20% of C) of the user base less than happy. Since half of users suffering D and E also suffers C, we have 10% + 10% = 20% additional users mad with you. So 25% + 20% = 45%. Almost half of the user base! The less worst aftermath would be fixing C, D and E and ignoring A, as A+B = 35% of the user base, way less than the 45% I said before. And if fixing B is easy and/or fast, it should be fixed nevertheless, as it would drop the unhappy users to 30%, less than one third. And since no one will be left with more than one unfixed bug, chances of losing them are smaller. People don't get mad because small bugs. They get mad because big ones - or too many small ones at once. And since big bugs are easily detected and fixed on the spot (ideally, at least), the corollary is that you lose your users due small bugs... Yep. It would be better to walk slower, as the aftermath is the same and you would save resources by not wasting "steps".

KSP 1.11.1 had fixed this problem, so no planes exploding on launch due insane amounts of heat when using some older add'ons. #HURRAY Users of KSP 1.11.1 should not install the 0.0.6.0 Beta. However, really heavy crafts (the test I did had about 500 tons) are still exploding on launch and on unpacking the craft when the craft is over something with a collider (i.e., it's not directly on the PQS ground). I'm still scratching my head about this one, don't have a clue on how to work around it -- -- -- POST EDIT -- -- -- Hummm.... Interesting. I think I found the magic number. At least on my rig, crafts with more than 129.5 tons blows down into the ground due the problem I described above. Crafts with less than 129.5 tons launchs fine. Now that I have a M.O., I know (more or less) what to do. I only need to make work a new stunt of mine. -- -- -- POST POST EDIT -- -- -- I was wrong. It's not related to weight. It's related to TweakScale *and* the MK1 Inline Cockpit as the root. Creating extra heavy crafts without TweakScale is not problem. Rerooting the affected craft to prevent the Mk1 Inline Cockpit from being the root (at least of the test craft) solves the problem. This problem was moved to TweakScale's Issue Tracker as Issue #162. -- -- -- POST POST POST EDIT -- -- -- I wrong on thinking I was wrong. It's not TweakScale (but I still need to do some more tests to be absolutely sure). It's something on the upgradepipeline, that it's not upgrading propely some crafts from previous KSP versions. More details on this post on TweakScale thread.

The KSP.log and the Player.log are needed, otherwise one would need to create a new install and download every single add'on you use, what's a hell of a work. By analysing these logs, we can pinpoint the problem at 99% of the time, saving a lot of efforts! Check this thread for how to find the logs:

Yes. Every time you load a Craft (or savegame), the part parameters are "defaulted" by the engine, and so TweakScale needs to "rescale back" what you did on the Editor. So, if the game's guts mangles with the data before allowing us (Modules) to get it, TweakScale will scale the thing using the new numbers, and not the ones you got on the Editor. (this happens for sure on Loading because KSP shoves back prefab data into parts on loading from file, apparently as a way to allow you to install new add'ons on the rig without risking blowing up things later, keyword: upgradepipeline). About the StageRecovery, if it is not handling the OnShipModified event, so it's for sure suffering from the same problem TweakScale did in the past. However, if SR is handling the OnShipModified, then the source of the problems must be something else, not necessarily the Editor. If Modules fails to communicate the Editor about changes on the parts, then obviously the Editor will report wrong values to whoever asks it for them!

Well, it's not that bizarre as you start to get a grasp on how things work on KSP. There's no parallelism while calculating things on the same craft, so every part is calculated after the other. If you have a mishap on the code that handles symmetry where the first part on a list ends up getting a bigger share of the burden, then parts switching its order on that list will change the previous behaviour. I think that the first part you attach to the craft ends up being the first on that list, with the symmetric clones being pushed after it. So if detach and reattach a part, all the clones are destroyed and the "surviving" part became the first part of that list, followed by its clones. So, since we have a unbalanced burden division between the parts, with the first part on the list being biased to be more taxed, the place you put the "original" part will change the behaviour of the entire craft. Besides, what you describe looks like the times in which TweakScale was not firing up the OnShipModified: the cost gauge was always showing the previous cost of the craft when I TweakScaled something. I.e., I scale a tank, the cost on the gauge shows the cost of the craft before the scale. I scale another part, then the cost goes to what should be when I scaled the previous part. By Adding or removing a part (any part), someone else would fire the OnShipModified, and then the cost of the craft was correctly updated. It took me months until I finally realised the problem! Uh.. Ups. My bad. Anyway, I misunderstood it with "lie" (from not telling the truth) because of the problem I got on the OnShipModifier stunt. I spent months and months trying to figure out where in hell TweakScale was "lying" about the cost to the KSP Engine until I realised the pattern I described above, and then the answer hit my dull head with the finesse of a piano falling tom the 13h floor. (it event sounded like one in my head) Need is not he best word - but I recommend using S.A.V.E. all the time. You know, Cheese Happens. On KSP 1.11, if by any reason your crafts start to blowup on launch, then you will need KSP Recall 0.0.6.0 (BETA at the moment). There's a bug on KSP where some older parts just blow up on launch due pornographic amounts of heat coming from nowhere. The 0.0.6 "fixes" it (without installing anything KSP 1.11 doesn't need, don't worry).

Yes, I did. Since TweakScale scale things, and since KSP is somehow unbalancing the Chute effetcs on each side of the craft, so TweakScale is also scaling the unbalanced values. On the github issue #162 161, you will note that the angle of the craft after the chutes kick in are approximately the same in all tests (and yeah, I deactivated the SAS). The only situation in which I would conclude that TweakScale would be making an already misbehaviour worse would be if the angles of the craft while under the effect of the chutes would be changing between scaled and unscaled chutes - not to mention on the rig where TweakScale is not even installed. See: 1) First try with scaled up Chutes with radial symetry: 2) Same craft, but using mirror symmetry - not sure the the mirror did something different, or I just changed the order in which the chute is calculated by side effect: 3) A scaled down fuel tank and engine, with a unscaled chute: 4) A new craft on a rig without TweakScale: You will note a slightly increase on the angle on the last two screenshots, that I credit to the Chutes having to cope with a somewhat less favourable weight/drag ratio, and not because TweakScale had any beneficial effect on the problem on the first two screenshots. TweakScale can't fix the Physics Engine behaviour - it only gladly scales whatever the game gives it to scale. It's really a dumb operation : whatever is there at first place, it's scaled by it using the Receipt and that's it. And since the behaviour is consistent between a scaled part, a unscaled part and even with a TweakScale-less installment, I really can't pinpoint TweakScale being part of the problem. If the mirrored/secondary chute would not be being scaled at all, that would be on TweakScale shoulders. But by then, one of the chutes would not be visibly being scaled (or we would have an Exception inside TweakScale after scaling the mesh and while trying to scale the module values). Nope, because TweakScale can't "lie". Or it scaled the thing, or it didn't (and then we have a beautiful Exception on the KSP.log). And since TweakScale uses the very same Receipt on both the chutes, any weirdness would happen on the source's value - as the multiplier would be the same for both parts. What you may be experiencing is a mishap on StageRecovery fetching the new numbers from TweakScale. Older versions of TweakScale were failing on sending the OnShipModified event after scaling the parts - and this were giving me some weird values on the Editor gauges what's remarkably similarto what you are describing. Well, since TweakScale started to emit the OnShipModified event every time a part changes scale, I got no more weird values on the UI, so my best guess is that StageRecovery is not handling the OnShipModified . This can be an explanation by what you are seeing - but I'm guessing.

Got it, it's the #161 issue. Well, it's not TweakScale (as usual ), neither an error on StageRecovery. It's KSP itself - the code that should split the loads between the chutes are flawed (pretty similar on the wing's lift, by the way) - I managed to reproduce the problem on a TweakScale-less KSP instalment. There's a good chance that whatever was messed up on the wings is also affecting the chutes. Cheers!

Can be anything. I'm not B9PS maintainer, this is a question you need to ask him. What I know is that by installing the latest TweakScale, the latest B9PS and KSPIE and OPT the problem doesn't present itself. So, until further information is given, I can't say it's a problem on TweakScale. I will install Nertea Mods by the night and see what I get. -- -- -- POST EDIT -- -- -- Found some time before lunch, used it to do a quick test. I made this craft: Using Cryogenics Engines, the latest TweakScale and the latest B9PS. Dude, not a single problem on the KSP.log related to TweakScale. The files (craft and log) are on this github issue. So, and I'm pretty sure about it, this is not on TweakScale or B9PS. It's something else borking, and playing havoc with TweakScale by collateral damages. On the bright side, now I have 3 different KSP.logs with this problem and I can try to find a correlation. I will keep you informed if I find something.

Yep, I found a post here from 2017. 2014. However, and this is crucial for this problem : THERE'S NO ATRIBUTE CALLED modMass on the public class Part (just checked using Assembly Browser on Visual Studio). And, so, it's beyound the reach of TweakScale. TweakScale can see it, can't touch it. What I found is an attribute called moduleMass , but it's unrelated for sure as this atribute is present only on the KSP 1.11 release of the class Part - not to mention it's an internal attribute: internal float moduleMass; What makes it untouchable by any authors that wants to publish his/her works on Forum: Source. (emphasis are mine) In a way or another, since we have posts since 2017 2014 talking about modMass, I'm pretty confident that the moduleMass stunt is unrelated. Yep, but where are them? There's no mention for ir on the class Part. I think this is something being used on loading time by some other code than the Part class. Yep. But this is an attribute from the AvailablePart class, not from Part. And there's no mention of minimumRBMass on any config file on the GameData neither. So this is also something beyond the grasp of TweakScale. Things are becoming slightly hairy, I think... Interesting. I remember some settings to give Kerbal some mass since ever (the first time I got someone blindly patched TweakScale on everything and the kitchen's sink, and then I instrumented TweakScale to remove itself from kerbals, that settings were already there). We are talking things already available since 1.3.1, I think ever - I remember tinkering with them on the 1.4.x era (yeah, I toyed with the idea of scaling kerbals!! hehehe). So, and happily, TweakScale don't need to worry about it. What I think it's happening is that since the beginning the mass of the Part on the config file was the total mass of the thing, resources and Kerbals included - this is the reason TweakScale needs to calculate thingies called DryCost and DryMass at first place, as TweakScale aims to scale the part itself, and not its contents (we don't scale the fuel, we scale the fuel capacity). So, and I'm speculating now, once you EVA a Kerbal, the mass of the resources and equipment he/she tooks with him/her needs to be subtracted from the Part's mass. The same for the Kerbal him/herself, by the way. On a (another) side note, I think there're better ways to accomplish that. The Part Module has methods called GetModuleCost and GetModuleMass , amd these numbers can be negative (or even zero) without problems. A Module called ModuleCrewRoster or something would keep track of these things, and then would return such mass and cost differences as Kerbals goes EVA and then back. That would save everybody the need to worry about these ghost modMass and modCost stunts... (no to mention the efforts to code and test things that could be implemented by using already existent and tested modules!). Well... I digressed. Yep, and this is the reason TweakScale complaining by not finding the mass is pretty weird, and possibly indicating something extending or changing something on the KSP guts. The values on the config files override the default values you code when you create a Module class. The Config files are, essentially, a user modifiable prefab - you don't add the value on the config, and the Module will use whatever the programmer used while initialising the class (usually zero by default). So, the absence of the mass on the config doesn't means that the object in memory would not have the attribute itself - the reflection will be able to fetch the reference so TweakScale can scale it (even if the value is zero, as scaling zero to anything is... zero.) BUT Somehow, this is not happening on your rig. Since TweakScale is not effectivelly instancing the PartModule, but getting a reference to an Object that descends from PartModule, it's theoretically possible that something could inject something else called PartModule on the runtime that does not exposes (or just don't have) an attribute called mass. It's the only explanation I have at this time for this mishap.... Not only strange, but a coding aberration . Being zero, Infinity or NaN, the attribute must exist on the object the reflection gives to TweakScale. TweakScale don't scale things on the prefab, it scales thing on the living craft. And living craft are made by a collection of Parts, wheve every part is represented by a PartModule with a lot of attributes, mass being one of them. Understanding why TweakScale is being given something else instead is the key to find and fix the problem, I think. This is the reason the smaller scale you can scale something using the UI is 10% or 0.100 meters (free or stack scalings). But yet, if you are right about it, TweakScale needs to prevent the scaling to reach that collider threshold at runtime, instead of just lock the controls to that minimals I mentioned and hope for the best... Something to think about, no doubt. Well, I have some good results scaling things down. Including that pesky wheels (with a lot of adjustments, of course). Most of them I even managed to be persuaded to fly, but the way. This does not invalidades your collider thesis, but on the other hand, I think I would had detect something like what you describes sooner if something too much obvious would be happening. [uh.. nope! } -- -- -- POST EDIT -- -- -- You have a point! Github issue: https://github.com/net-lisias-ksp/TweakScale/issues/160

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.