Lisias

What is a serious maintenance nightmare. Why TweakScale should need to be aware of USI, when the patches [and the converters] are on USI itself?

Nope. Theoretically this is on USI's shoulders. USI MKS and LS has embedded patches for TweakScale, the support is added there, not on TweakScale - so changes on USI that affect the patches, ideally, should be applied to the USI Patches itself, not on TweakScale that doesn't even have them at first place.

Soon™ . I'm currently tackling down Variants on TweakScale (including Attachment Points), but the thing is fighting back fiercely (and KSP 1.9 is not making my life easier). But once I manage to make TweakScale understand Variants, doing the same on the Welding Tool will be trivial. I have a working work around for this however, and it should work on both forks (mine and the oficial one). Add <ModuleAttribute AttributeName="ModulePartVariants"/> on the <ModulesToIgnore> section of moduleAttributeList file. Any variant applied will be ignored, of course. But at least you will avoid the Variant Welding Mess for while. I understand this is far from ideal. But I'm kinda of overwhelmed as there're really few people really maintaining things lately - what renders me insanely task switching to cover up holes everywhere and this is delaying everything I'm doing. — — POST EDIT — — Sadly, I can't pursue implementing new features on the Welding tool anymore. It's nearly 3 years since this post, and I didn't managed to do it, I don't see how things would change now - I still have the same problems I had at that time, things didn't improved as I was expecting it would (how naive I was…). It's not impossible that I would work on this again sometime in the future - but I wouldn't hold my breath on it. Sorry.

Wait....Are you on KSP 1.9? -- POST EDIT -- never mind. They really changed the modules. Not only that, the whole subsystem was overhauled, the current exponents just don't work anymore. New exponents are needed, built specially for the new modules. Problem. There're two years since the change, and nobody cared to fix this until the moment. I'm afraid a Companion will be, in fact, the best way out of the mess.

So the modules named was changed. Well, less worst. Technically, it's a USI problem. And since I found people discussing TweakScale on both threads, (LS and MKS) and on none of them I found the "TweakScale not supported" coin, I think you should ask there too. Well, the diagnosis is done. I know what's happening, so it's not too much of a job to check and add the Exponents to a file and kick a HotFix for USI through the doors. But this should be really tackled down on USI, as they are the ones distributing the patches and so I'm reticent on kick starting a TweakScale Companion for them (Official Add'On maintainer distributing "official" TweakScale patches - this is not the "market share" the Companions aims to).

Since we talking about tanks... Ruskies!!! -- POST EDIT -- Whoops.... Involuntary double post. @razark post it first!

Something is crossed somewhere... See, there's a patch for TweakScale on LS. And for Kontainers too! TweakScale distribution have only the exponents for USI (and I wonder why these ones are not on the USI_Tools, that appears to be the right place for them).

It's a bit frustration, not? I would agree with you if you answer "yes". Some bugs take a long time to be fixed (too much time for the user's perspective), but this is because some real nasty bugs happens in a waterfall effect, and you need to change things from the basement to the penthouse first. It's essentially what happened with supporting Variants with Cost and Mass on TweakScale - there was something really weird happening on the field since 1.5 (more or less), and it took some time until I finally identified it and worked around it, before daring to try to shove new things related to Mass and Cost what could make things worse (Mass played havoc in the past, but not more nowadays - but it would seriously imbalance your crafts, making them unusable later). So the Issue #13 took 18 months (more or less) until I finally not only regained control over the whole situation, but had time to spend on the relatively long time needed to code, test, recode, retest - since KSP doens't allow you to reload DLLs anymore, some tricks we used in the past to save time on KSP reboots doesn't sticks anymore (disclaimer: there're new ways to accomplish that, but I would need time to built them and this would delay even more tackling down TS issues). However, now that I tackled down Mass and Cost on Variants, I realized that KSP 1.9 also mangles Attachment Points the same ways it does with Resources, and so now I need to update KSP Recall to handle this before finishing the implementation. KSP 1.9 is heavily used, as some very popular Add'Ons were not updated to 1.10.x yet, so pushing TS through the doors without this handled would render me a support nightmare later. And that's it. This "little" essay tries to explain to users why some times things take so much to be fixed. You are being presented to the very basic fundamentals of Software Engineering, a class I took on College. From it, I learnt that's suicidal to keep building things over defective basements, as the thing is doomed to collapse sooner or later (if you were around on the 1.4.x era, we had a pretty nasty situation around when a toe stomping fest between add'ons rendered parts with zero mass, playing havoc with the physics engine). So TD;DR : besides frustrating, it's way less frustrating than having to cope with the consequences of new features shoved on the product without care before paving the way for them, preventing them to work correctly at first place. Even the slightest hope of Control over things deployed on the field is pure illusion, "Rectangular Pieces of White Paper" happens no matter how clever you think you are. Send me a message if this bug starts to bug you too much. I gave a look on the problem, USI has TweakScale support embedded (I wonder why the exponents ended up on TweakScale, they should be on USI together the patches), so chances are that the problem is really on the USI side.

Well. now we have a functional bug to handle. In order to pursue this one, I need you to restart KSP, fly the craft, try to scoop some hydrogen, then land it (or just revert the flight) and quit KSP. Then publish the KSP.log on DropBox or something and link it here. humm... Before that.... Do you have all the dependencies installed? KSPe is critical for II.

(shhh, talk softly please - it's late Friday and I'm already on a hangover!!) Well, you don't. You need the Hydrogen Scoop, but also a Hydrogen Tank (it's the gray one, not the radioactive blue) and a Hydrogen Converter (that weird hexagonal tank). So you use the scoop to fill the tank, then activate the Converter (that eats a lot of electricity) to convert the Hydrogen into one of the other fuels. The dynamic pressure of the atmosphere dictates how much hydrogen you scoop - on the lower atmosphere you fill the tanks faster. Problem: there's a glitch on the Hydrogen Converter's mesh that demands installing World Stabiliser, otherwise the craft will suffer the "Jumping Jack Effect" and will be kicked into 1.000 meters high on launch (this started to happen on 1.4.x, if memory servers me well). However..... The Hydrogen Tank and Converter have a serious problem on KSP 1.10 with the colliders, way worse than just needing World Stabiliser - I just can't right click on them, so you can't activate the Converter!!!! The tank is being filled, besides you won't being able to select it to transfer the fuel, but without being able to open the Converter's PAW, the thing is plain useless. The devil is in the detail. Yeah. I completely missed this one. Well, there's a workaround. You will need to assign the Converter's Actions into a key. You will probably will want to use Action Groups Extended. On the sample craft, the Key 3 will activate/deactivate converting Protium into Tritium and Deuterium. You can check the thing working by hitting 2 too, what activates the Fuel Cells (that eats Tritium). And then hitting 3 multiple times and checking the Resources Inventory. When the Converter is active, the Hydrogen Tank stops filling, and the Tritium and Deuterium stops being consumed. When the Converter is inactive, the Hydrogen Tank fills up, and Tritium and Deuterium are consumed. In the mean time, I will reschedule things. Apparently, I will be meddling with the meshes way before tackling down the textures sizes.

Ah, now I see. The part changed the internal name (the code uses to reach it, it's different from the name we see on screen), or perhaps a module (and so the scaling exponent is missing it). The bitter true is that the "stock" patches for 3rd parties on TweakScale are all terribly outdated, and this is the reason I deprecated all of them (except the Squad and SquadExpansion parts) and I'm pushing the TweakScale Companion Program instead. Well, let's make a deal. Give me a pretty simple craft (it doesnt needs to make sense, all I need is the parts working togheter) with the parts bothering you most - 6 to 8 parts is good enough. Then I will cook a hotfix for you, buying a bit of time so I can properly work on a Companion for USI. I'm a bit fed up with C# (man, I hate Variants! ), I dying to do something else and doing patches is better than doing the dishes.

To tell you the true, it's probably easier to adapt II to use Community Resource Pack instead, that is directly supported by IFS. I finish TweakScale 2.5, and we can call it a year!

These were cheap around here at that time. I bought that 1425 cheaper than a Raspberry Pi! -- post edit -- Bringing the discussion back to thermals. @Boyster, that screaming crap I call a server is a perfect example about what we are discussing here. That thing have 16Gb of server RAM, TWO formidable electric heaters acting as CPU called Xeon with 2 Cores each at 3.6GHz, two SCSI 10K rpm disks spinning crazily trying to accelerate entropy into the World. All of that packed on a case with 1.75 inches high. Less than 5 cm. And yet, that thing runs cooler than an MacBook - God knows I wish it would run quieter too. You can't have the cake and eat it too. If you want small form factors, you need to compensate the lack of thermal dissipation by using powerful turbines, I mean, coolers on the system. Powerful and silent MiniPcs and notebooks are, frankly, pure scams. No one can fight entropy.

Music? This beast has some "music" for you!

Announce Users (if any! ) of TweakScale Companion for Firespitter Beta need to update to the latest version, as some changes on TweakScale Beta will cause older versions to misbehave while calculating costs. Announce² TweakScale 2.5.0.24 Beta is now available for the brave Kerbonauts that don't fear burning savegames in sacrifice to the Krakens. This is a maintenance release, mitigating some annoying bugs not handled on the .23 -- it's safe to use this version, no more missing attachment nodes on scaled parts with variants with attachment nodes. Attention please: Parts with variants that change cost and mass are now correctly supported, but I having my cheeks bashed on scaling variants with attachment nodes. I managed to kinda locate where the problem is, but (as usual) run out of time to try a real fix, so I compromised on solving the missing attachment nodes problem (something that potentially be a headache for your crafts later). There's also a new (but not unexpected) misbehaviour on KSP 1.9 related to Attachment Nodes. In a nutshell, Attachment Nodes are also reset by KSP 1.9 the same way it's done to Resources (and yeah, I was developing on 1.9 with Recall and completely forgot about! ). A new KSP Recall release will be issued before I can publish a near ready release of TweakScale 2.4.4.0, as it appears. Please note that TS Beta is to be used on disposable savegames only. I'm using this stunt on my own savegames, obviously, but now and then a bug passes through - but I know how to edit and fix my own savegames, and I'm a S.A.V.E. heavy user! Any reports about it (being a bug or not) should be posted on issue #42 (or I will get lost - again - on the sea of bug reports!).

Compiling an add'on against KSP 1.10.1 is a waste of time and resources. Compilers are not magical entities that fix bugs automatically, and I'm afraid this myth had done a lot of damage around here. Test the thing. If it works, it works - recompiling will not make any improvements on the situation. Also, keep in mind that the TweakScale Companions are not tied to a KSP version, and only a few are really tied to a specific TweakScale version (being the 2.5 beta, due the new calls I'm implementing to support them). So you can use the Companion on any KSP version that supports the target Add'On you are using. The Companion for APP was tested from KSP 1.4 to the 1.10, where I installed the corresponding APP version to run on that KSP version I was testing. (And yeah, I'm that meticulous. No KSP version will be left behind - reestablishing support for KSP 1.3 is one of my next goals as soon as I tackle down the current TweakScale's technical debits.) What really matters is doing things in the way the KSP version you are using like it, and sometimes newer KSP's versions have some calls on the API that are unavailable on the previous versions - but just recompiling the thing will not use that new calls, you need to write code to use them. A perfectly good example is the thingy that KSP Recall's Resourceful does: it uses only calls available since KSP 1.4 at least (probably 1.3 and even 1.2, I just didn't tested on them) to workaround something that was happening only on KSP 1.9, but not on 1.8 and 1.10 . Resourceful will gladly runs on any KSP version that have the API calls it uses, but that would be a waste of memory and CPU cycles because only KSP 1.9 is doing that things that Resourceful works around. Driftless is another perfect example of what I'm saying. It can run on any KSP version I have here if I compile it with Mono 3.5. But... Only KSP >= 1.8 have the problem that Driftless solves, so I coded it to do not apply the workarounds on KSP 1.7.3 and older (even if someone recompile it on Mono 3.5 to run on them). The same is valid for every single Add'On around here.

More or less. The patches on the Companion Program are carefully crafted, using every trick I know to maintain the GameDatabase safe - no double patching, not bad patching, no toe stomping fests. The Companions on Release Status (ReStockPlus at this moment) are prefectly good to be used on "production" savegames. The Release Candidates are almost there - it only needs some weird borderline tests to be sure they will behave when weird and borderline things happens. It's somewhat hard to test every possible toe stomping fest, and it takes some time to download everthing and the kitchen's sink into my testbeds to do these extreme testings. It's the reason these two are not Release yet, lack of time from my part - but they are safe enough to the most common cases, so if you use S.A.V.E. (just in case), they are good to be used at 99.95% of the installments out there (being that 0.05% the ones I don't know yet). The Betas and (most of all) the Alphas are bleeding edge, and you can hurt yourself by using them if you don't know what you are doing. I appreciate you using them on disposable installments in order to help me testing these things, but really, don't risk your valuable savegames on them (unless you are using copies to see what happens, and then delete these ones). TweakScale 2.4.3.21 is safe to be used (as long someone else don't really screw up, of course), it's the latest official release of TweakScale. The ones I publish on CurseForge, Spacedock and CKAN are the safe ones. The same on the Companions, if you find a Companion on CurseForge, Spacedock or CKAN, it's safe to go. I have no notice of problems of TweakScale 2.4.3.21 on KSP 1.10.x, by the way - and if someone arise, it will fixed and a 2.4.3.22 bug fix release will be issued. TweakScale 2.5.x beta are unstable and you should be really careful on using it. I'm changing a lot of things, what is allowing me to implement new things without playing havoc with legacy - but at a cost: new things can lead to new bugs. This last release, 2.5.0.23, have a known bug on scaling the Mastodon and the Structural Tubes that I didn't managed to fix yet, and made this release so people can try and perhaps identify what in hell I'm doing wrong (or not doing right). It's a problem on scaling Variants that change the attachment nodes (and this will bite any part doing it, including any third party Add'On). These beta ones are only published on GITHUB, and you need to dig on the site to get them.

Yes. It's impossible to software demand more than the hardware can withhold, as much it's impossible to you to drive your car faster than the engine can drive the wheels. Of course you can use nitro on the fuel and make the engine runs faster - but that would damage the engine. It's the same with the overclocking - yes, you can overclock the computer to make software runs faster, but this will eventually damage the computer. (and not the software). If your computer dies while playing some demanding game, there's only two possibilities: 1) You didn't cleaned up the cooling system, and so it could not cool the computer as needed. It's the same of letting your car's radiator without collant. 2) The manufacturer lied to you, selling a computer that was not designed to sustainably cool the CPU it shoved on the motherboard. It's like someone selling you a car with 12 cylinder engine but with a radiator made for a 4 cylinders engine. The car will break. Impossible. If the hardware can't sustain the load without melting, it's a hardware problem, not software. Nope. The BSOD happens due two different and unrelated problems: 1) A bug of the software that leaded the kernel to a crash. You fix the software, the problem ends. 2) A hardware problem that leaded the kernel to a crash. You need to fix the hardware. Essentially what happened here in Brazil with the Fiat Tipo Sedicivalvole from Italy. Some rubber tubes that worked perfectly on Italy just melted on Brazil's summer and the car catched fire on the garage after being used, because with the engine off the cooling system that was keeping the rubbers in an acceptable temperature ceased to work, and the rubber tubes melted leaking inflammable fluids on the hot engine. And yes, Fiat had to make a recall here to fix the problem, because the car was imported and sold by Fiat itself. When a properly maintained and unchanged car overheats, it's always manufacture's fault. Computers are the same. It's up to the manufacturer to assure the computer operates on acceptable thermal parameters (as long you maintain it clean as the manufacturer says, and does not change anything on the hardware). If an unchanged and well cared computer overheats, it's the manufacturer's fault. yes. Because a much lighter and better version of the software will be able to do more things at the same CPU speed. The CPU will still be running at it's (designed) max speed - unless the software artificially drags its feet on the processing. You can always run slower with your car if it overheats, right? But it will still be broken.

In a nutshell: NO. Overheating can damage the computer, but it is not caused by software. It is caused by problems on the cooling system or by simple bad design of the cooling system. The cooling system of your computer is like the cooling system of a car: if the car overheats, it's due bad maintenance or because the manufacturer screwed up. There's a lot of notebooks and mini-pcs dying by overheat lately and the reason is only one: bad design. But since it's cheaper to blame the software to cover up engineering mishaps, this urban legend persists - "let's save some bucks by convincing the customer that he installed a bad software, instead of paying ourselves for our mistakes".

Of course I am. The roadmap is on github, this feature in particular is here.

Announce TweakScale Companion for Firespitter was updated to cope with new features from TS 2.5 Beta. Please note that you will need the absolutely latest TweakScale 2.5 Beta otherwise costs will be badly handled on Firespitter parts with Resources. Please note that TS Beta is to be used on disposable savegames only. I'm using this stunt on my own savegames, obvious, but now and then a bug leaks - but I know how to edit and fix my own savegames, and I'm a S.A.V.E. heavy user!

Announce TweakScale 2.5.0.23 Beta is now available for the brave Kerbonauts that don't fear burning savegames in sacrifice to the Krakens. This is a maintenance release, fixing some annoying bugs introduced on the .22 while fixing bugs that happened on refactoring things to allow the missing features to be implemented on a sane way (less Code Warrior, more Engineering - now with less bugs!). Attention please: Parts with variants that change cost and mass are now correctly supported, but I'm struggling to handle variants that change attachment points, and this can compromise the savegame. The bug is exposed so someone, hopefully, can pinpoint exactly what I'm missing - probably something silly, but I had run out of time due Real Life Issues (tm). Please note that TS Beta is to be used on disposable savegames only. I'm using this stunt on my own savegames, obviously, but now and then a bug passes through - but I know how to edit and fix my own savegames, and I'm a S.A.V.E. heavy user! Any reports about it (being a bug or not) should be posted on issue #42 (or I will get lost - again - on the sea of bug reports!).

No pressure, no pressure at all! Apparently the Nertea's Waterfall will help, but it will be a workaround - it will replace some engines' exhaust with meshes based effects - and so, avoiding triggering the problem. At least, until someone else writes something to use the particles on something else, triggering the problem again. A real fix to the problem is described above on @steve_v's link: calling "Complete" or something before the 4 frames timeout. Oukey, it will have a cost as this thing triggers some house-keeping tasks, but it will be better than killing the game for sure! But, and assuming this is really on particles, the fix is on Unity's shoulders. What also means that a new Unity version will have this fixed, ruling out a fix for current KSP versions. But now, something that's bugging em since the first time I had read a KSP.log with this problem: why. by Kraken's sake, this never occurred to me? My machines are probably ones of the worst possible kraps able to run KSP. The only explanation I can think of is exactly this: my crappy rig is preventing the problem because it can't render frames fast enough. And this may be an explanation because it's so hard to reproduce the problem for people that don't have it, and it's so hard to get rid of the problem once it bites your SAS. In a way or another, before bugging Nertea about Waterfall, we need a kind of counter-proof to be reasonably sure it's really the particles. We need to cause the problem somehow by abusing the particles and/or we need to workaround this problem by other means than lowering the frame rate. So I want to ask to some victim of this a new test: set the configurations in a way that the thing crashes again. Then go to the Graphics Settings and crank everything up to see what changes. I think that a good test can be splashing the ship, as the water effects appears to be specially expensive, and they appear to be particles too.

EXCELLENT! It appears to be related to particles!

Ouch.... What hapenned?