Lisias

It's a big company that lost a huge amount of money on one of the subsidiaries due a incredibly series of bad releases, including the sequel for the game we are pleading the (controlled release) of the Source Code. There're advantages of doing it, both technical and marketing ones, see the fuzz ID Software got in the past for every source code they released. It's a viable and time proven solution for the current mess they got themselves into. Bluntly ignoring the claim is the way of the dodo, the new management has the duty to consider every possible minimally viable way out of the current mess they are into. I'm not implying that releasing of the Source Code will be the best solution, it's possible that they may find something else that would do the same - but bluntly ignoring this alternative, the same way the previous management ignored the technical state of the KSP2 and pushed it ahead anyway is, as I had said above, the way of the dodo.

It's not how things work. In order to put something on the table, the Company must be aware that there's demand for it and that it's a good (or a less worst) solution for the problem. Until now, nobody was asking for it. Now we are. Someone, somewhere, will listen to it and - perhaps, if they are intelligent enough - ponder the pros and cons of the thing and do something about. Not necessarily what we want, but probably something they realised they need to do. PD and IG got a harsh throat cut event recently, we have new blood on the system; NOW is the time propose solutions for long standing problems that the previous management ignored or wasn't able to fix.

If we believed it was on the table, we won't be asking for it!!!! [snip] What we are asking is to make it available for the EULA and Forum Rules abiding community members too.

Doom, Quake, between others had did it. Unity publishes it's full source code under a Shared Source style license (you can read it, you can compile it in your machine, and that's all). [snip] Officially and legally publishing the Source code (even on a restrictive shared source license as Unity does) will not only be hugely beneficial to KSP itself (potentially being beneficial to KSP2 too by collateral "undamages"), but will help to protect the I.P. with more eyes monitoring what's happening int the wild. [snip] It is a possible and viable option for the Franchise.

Wondering that perhaps the best way to help KSP2 (and us, KSP(1) die hards) is to make KSP(1) Open Source - or perhaps Shared Source, as Unity does. People are already decompiling the code, openly watering the Forum rules not to mention the EULA. Having the source code published will help to identify unauthorized use by 3rd parties at very minimum - right know, with the KSP reverse engineered source code at hands of a very few, there's no plausible way to do such. Too many hands, to fewer eyes. The genius is already out of the bottle, we have no other choice but to deal with it.

Welcome! Yep, I noticed it on your KSP.log I will not screw the users, so CKAN will be… tolerated into life support. I will keep whatever is on CKAN working, will fix my bugs, but will not really add anything new to it, neither updated what's already published to something that I know will not work because CKAN failed to publish needed requirements early this year. TL;DR: CKAN is not my problem anymore. I fail to understand why I should support someone that doesn't give a rat's <piiiii> to me. Yep, I noticed it. And I think I detected the trigger, appears to be ModuleSwitchableTank. It's from Configurable Containers, and it's scheduled to be supported, you can see it in my backlog. https://github.com/TweakScale/Companion_FuelSwitches/issues The reason you don't have support for it yet it's because I had to update a lot of things simultaneously, and I failed on convincing CKAN to do such (I should had TweakScale 2.5 on the wild by now, where supporting 3rd parties is incredibly easier and safer). So I had to freeze things while trying to make it trough, but then my holidays were over and Real Life® and Day Work™ started to bite, closing my opportunity window to carry on the tasks. I don't have the slightest idea about how to I will manage to publish these new features on CKAN, so I think that you will probably have to do some manual installings, or using CurseForge Installer as a secondary installer. Things are working very tightly on CurseForge, these guys do real support for the Authors (and I'm not implying they do anything I want, they had kicked my back once when I had screwed up - and this is the differential, they reached me to kick me in the <piiiii> instead of just ignoring the problem). So, and I'm sorry to tell you that, I'm afraid that for now you are going to need to choose if you want to use TweakScale or Configurable Containers - and, make no mistake, I want to use it too. I'm also pretty frustrated about the ordeal, and it's one (between many) reasons I'm liquided off with these guys. I bashed my <piiii> for a good part of the last year to reach to this point, and now I'm stuck for reasons that I just don't understand.

Announce! New release 2023.03.28.4 for the TweakScale Companion ÜberPaket with everything (and the kitchen's sink) included for the lazy installers !! Update 2023.03.28.4, removing TestFlightCore support - See Issue 25 for details. Your attention please Completely remove all the previous contents in the GameData/TweakScaleCompanion directory, or you will trigger some FATALities on TweakScale's Sanity Checks! This thingy needs TweakScale v2.4.7 or superior to work Download here or in the OP. Also available on CurseForge and SpaceDock.

Hi! I think such an obvious bork would had been detected by me, but… I checked it anyway. Well, it works fine to me - don't you "love" when your developer tell you that about a bug you found? So it must be something on your rig, so please try the following steps first: Be sure to have installed the latest KSP-Recall A previous release had a bug that kinda screwed up how Recall deactivates itself to prevent borkage with incompatible add'ons, and this may explain why your crafts are being screwed on Load. KSP Recall may be deactivate the bug, and so things that should being fixed under the bonnet are not. Open the PAW of the affected Part and check every Recall related button to make sure they are "Active". Turn then into Active of they are not. If, even by doing that, your craft still is being screwed on Load, please create a new sandbox savegame, create a simple craft, save it and load it, reproducing the problem. And then quit KSP and send me both the KSP.log and the craft file for analysis. If you fail to reproduce the problem on a new craft, things will be simpler to diagnose but a but hairy to fix, but first things first! Cheers!

Do you want do to is for every part in the game or only to the stowaway_Pod? If you only wants into the Part, do as follows: @PART[Benjee10_stowaway_Pod]:NEEDS[Benjee10_stowaway,TweakScale] // CSS-200 "Decondo" Crew Cabin { #@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale] { } %MODULE[TweakScale] { type = stack_squared defaultScale = 2.5 scaleFactors = 0.1 , 0.3125 , 0.625 , 0.9375 , 1.25 , 1.875 , 2.0, 2.5 , 3.0 , 3.75 , 4.5 , 5.0 , 7.5 , 10 , 20 incrementSlide = 0.01 , 0.025 , 0.025 , 0.025 , 0.025 , 0.025 , 0.025, 0.05 , 0.05 , 0.05 , 0.1 , 0.1 , 0.1 , 0.25 , 0.5 } } Note that you need a incrementSlide for each scaleFactor, or you may mess a bit the PAW. If you want to every other part in the Game to have these scales, you can patch the SCALETYPE itself: @SCALETYPE[stack,stack_square]:NEEDS[TweakScale] { %scaleFactors = 0.1 , 0.3125 , 0.625 , 0.9375 , 1.25 , 1.875 , 2.0, 2.5 , 3.0 , 3.75 , 4.5 , 5.0 , 7.5 , 10 , 20 %incrementSlide = 0.01 , 0.025 , 0.025 , 0.025 , 0.025 , 0.025 , 0.025, 0.05 , 0.05 , 0.05 , 0.1 , 0.1 , 0.1 , 0.25 , 0.5 } (I did that from heart, need to confirm if the patch will work as intended) On the other want, of you want to apply these changes only to Benjee10 parts, you can create your own Scale Types (did that for SMCE parts, vey handful!) SCALETYPE { name = benjee10_stack freeScale = true defaultScale = 1.25 suffix = m scaleFactors = 0.1 , 0.3125 , 0.625 , 0.9375 , 1.25 , 1.875 , 2.0, 2.5 , 3.0 , 3.75 , 4.5 , 5.0 , 7.5 , 10 , 20 incrementSlide = 0.01 , 0.025 , 0.025 , 0.025 , 0.025 , 0.025 , 0.025, 0.05 , 0.05 , 0.05 , 0.1 , 0.1 , 0.1 , 0.25 , 0.5 } SCALETYPE { name = benjee10_stack_square freeScale = true defaultScale = 1.25 suffix = m scaleFactors = 0.1 , 0.3125 , 0.625 , 0.9375 , 1.25 , 1.875 , 2.0, 2.5 , 3.0 , 3.75 , 4.5 , 5.0 , 7.5 , 10 , 20 incrementSlide = 0.01 , 0.025 , 0.025 , 0.025 , 0.025 , 0.025 , 0.025, 0.05 , 0.05 , 0.05 , 0.1 , 0.1 , 0.1 , 0.25 , 0.5 TWEAKSCALEEXPONENTS { mass = 2 } } And then: @PART[Benjee10_stowaway_Pod]:NEEDS[Benjee10_stowaway,TweakScale] // CSS-200 "Decondo" Crew Cabin { #@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale] { } %MODULE[TweakScale] { type = benjee10_stack_squared defaultScale = 2.5 } } Cheers!

Nate is not the one calling the shots on TTI or PD, he doesn't have authority for such. But - if he had said it (I don't really know, sorry!), and didn't got any backslash from his bosses, it's because their bosses authorised him to say that. So, yeah. Nate telling that mods are acceptable is a sign that mods are acceptable - but don't put on his shoulders any burden that doesn't belong to him: he is not the one calling the shots about the subject, he is the one passing the word ahead. [edit]: this means that his bosses may change their mind later, and by doing so, you may think that Nate had lied to you, when he didn't. Anything you say, so. But I advise anyone to do a proper research in your own country laws. There're people making really bold declarations about things they don't know squat about. It may be me, or it may be not. It's you to you to look for and decide. [edit]: because it's you that may had to face the consequences of this crap - may you (or me) agree with it or not. Good luck.

You are wrong. From the TTI EULA , that it's mentioned on the EULA displayed on the KSP's Steam Page: Granted, depending on the Country you live, this statement may not be fully enforceable to you. But it is clearly stated on the EULA what's allowed or not, exactly the opposite from your claim. Additionally, from that same EULA: Again, depending on the Country you live on, part of this statement may be dead letter to you - but the EULA clearly states that you can modify and alter the Software if a consent is given. And, you see, we have explicit consent to modify the game, formalised on the Add'On Posting Rules. And, in time, also from the Add'On Posting Rules:

Your call. But you can ping me here if you change your mind later - no hard feelings. More than 90% of the time TweakScake borks are split in two main problems: Someone screw up a DLL loading, triggering a bug on the Assembly Loader/Resolver that screws up TweakScale royally by its turn. Bad patching - less then ideally written patches ends up applying patches indiscriminately, and TweakScale gets confused about how to handle such parts, and then yells about. The first one is relatively easy to diagnose look for Exceptions like this one: [ERR 07:40:39.235] AssemblyLoader: Exception loading 'ATW': System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown. at (wrapper managed-to-native) System.Reflection.Assembly.GetTypes(System.Reflection.Assembly,bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <9577ac7a62ef43179789031239ba8798>:0 at AssemblyLoader.LoadAssemblies () [0x000e6] in <a1ca58b5ca7140639de29a81de5e3f32>:0 Usually, the very first on the KSP.log will pinpoint the first one really triggering the AL/R bug (the other ones will be AL/R screwing up other DLLs in turn). If you have MechJeb installed, the order of the Exceptions will change and so the first one will not be the culprit anymore - temporarily uninstalling MechJeb does the trick, allowing the real culprit to be logged first and so you know what to do. Once the problem is fixed, you can install MJ2 back. Most of the time a DLL fails to be loaded because there's something missing on your rig, but in some less common situations, the problem will be a too old or too new dependency DLL present (the DLL is there, but something the other one needs is not). It's interesting to keep in mind that, besides being annoying, TweakScale refusal to run when these situations happens is saving you from losing the SaveGame. This is specially harsh on the DLL problem (the bad patching sometimes are survivable), as by loading the SaveGame with a missing DLL, everything that was using the features will be reset to default, completely ruining your savegame. TweakScale is not the only victim of the problem, by the way. Fuel Switched parts are also royally screwed if the Fuel Switch gets screwed by the AL/R bug. Good Luck!

Well, apologies accepted. Sheet happens, after all. Send me your KSP.log and I will diagnose the problem for you. You will find instructions about how to do it here. Post the thing on dropbox or similar service and paste a link here and I will look into it.

Speed Racer? It was you?

This mod works, and works well - as long something else doesn't breaks something on KSP, what leads to TweakScale to be screwed. Post your KSP.log and I will diagnose the problem for you. Additionally - I'm not your employee, and even if I would, I would quit. I suggest some manners while asking for help.

Yes, on this context, dashes but also dots and spaces are considered "alphanumeric" for the filters. With Unity aggravating the situation by replacing a lot of non alphanumeric characters (as braces) into a dot - so what you type is not what you get. Since we are here, spaces are also allowed on Unity's names, but MM doesn't handle that. If you have something named using a space, in order to patch it you will need to use a '?' in the place of the space and then pray to have nothing else similarly named with something else in the place of the space. Both will work, but both are dangerous because they will patch everything starting with the given string, not only the NFS parts. You see, "command" is a pretty common name to be used on parts, it's not NFS's prerogative to use them. Some add'ons are making our lifes easier by adding a prefix to their part names, as "nfs-<something>". This make things easier are by prefixing the parts you don't risk patching 3rd parties by accident. On my patches, I choose to address the parts by name without filters. You will not see any of my patching causing trouble to anyone else - unfortunately, the reciprocate is not true. If you really think that using wildcards is the way to go, consider using :HAS[] checking for something that only the parts your target addon uses, as the name of the author (but even this got me headaches once, as one author allowed a part to be used on another add'on, and then I got double patching the same on a user's rig). Option A will add or edit a node called RESOURCE (any one), rename it to `Oxidixer` no matter what it was its name before, and then add or edit the `amount` and `maxAmount` values. This is rarely what you want. Option B will add or edit a node called RESOURCE with name `Oxidizer` - i.e., if theres no RESOURCE node with a `Oxidizer` in the `name` value, one is created. If it exists, the first one is edited with the new values. Since we are here, there's also a Option C: %RESOURCE[Oxidizer] { %name = something-else } This will create a new node called `something-else`, or will edit the first `Oxidizer` node it finds to be named `something-else`. This is what you appears to want (as long the remaining values are the same) However, I would do things differently: -RESOURCE[Oxidizer] { }, * &RESOURCE[Resource1] { yada yada yada } &RESOURCE[Resource2] { yada yada yada } The first patch will remove all nodes named `Oxidizer`, and the following two will add new RESOURCE nodes with the respective name and content. These patches will silently "fail" if the resources `Resource1` and `Resource2` already exists. If you want to be sure to have your definitions overwritting the existent ones, I suggest to use: -RESOURCE[Oxidizer,Resource1,Resource2] { }, * This will guarantee that what you end up having is really what you wanted - some other patch may had added things you don't expect (as flow constraints) on the RESOURCE, and this creates very harsh to debug problems later.

You got bitten by the infamous KSP bug inside a thingy called Assembly Loader/Resolver - when something fails to be loaded by any reason, everything else that tries to load a DLL or use a thingy called Reflection gets screwed. In your case, the problem is really NSI: [LOG 16:57:01.628] [ModuleManager] Intercepted a ReflectionTypeLoadException. List of broken DLLs: NextStarIndustries 1.10.1.1 GameData\NSI\Plugins\NextStarIndustries.dll [LOG 16:57:01.628] [AddonLoader]: Instantiating addon 'Startup' from assembly 'TweakScaleCompanion_PKMC' [ERR 16:57:01.647] [AssemblyLoader] Exception when getting assembly attributes: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown. Additional information about this exception: System.TypeLoadException: Could not load type of field 'NextStarIndustries.NSIExplosionModule:weapon' (13) due to: Could not resolve type with token 0100001d ( from typeref, class/assembly BDArmory.Modules.MissileLauncher, BDArmory, Version=1.3.4.0, Culture=neutral, PublicKeyToken=null) assembly:BDArmory, Version=1.3.4 .0, Culture=neutral, PublicKeyToken=null type:BDArmory.Modules.MissileLauncher member:(null) signature:<none> It didn't liked the v1.6.0.2 version you installed. I don't have a clue how to proceed, you need to get further help from the BDArmory guys or from the NSI maintainer. Good Luck!

Given the uncommon nomenclature, it's surely based on a Soviet/Russia aircraft. I'm reasonably confident it's related to Mig 1.44: https://en.wikipedia.org/wiki/Mikoyan_Project_1.44

Do a full KSPIE reinstall, then remove WaterFall from the GameData folder. I don't know where are the TweakScale support on the KSPIE bundle, but surely appears not to be on the WarpPlugin as it appears. I really over my head now, I don't know how KSPIE do things.

When you reinstall KSPIE, it installs its embedded version of WaterFall back. You need to delete the WaterFall directory that it's installed by KSPIE. This is one of the worst parts of bundles - it's worksome when you don't want a bit of it...

Give SmokeScreen a try - it taxes a bit less your rig, and are still pretty decent!

People have this strange compulsion to hurt and destroy the things they care the most. Caring is about doing what's best for the object of caring, not what you think (from your limited experience) it's best. Caring is about recognising when something is not working for the best, and then make corrections even if this means waving control. As well not to make corrections when things are working perfectly because you are fearing losing it if you don't have enough control about it. Caring is not about control. Controlling is not caring. This is not personal, professional or technical rant. It's just a general rant. God knows people are playing havoc with everything they (think they) had control nowadays.

Hey! Wait! We can't destroy the Launch Pad on KSP2???

I really surprised no one posted this here yet!!! What could be more kerbalistic than Elon Musk destroying his launchpad (what he probably did a lot while playing KSP, by the way!!!) https://universemagazine.com/en/starship-leaves-a-huge-crater-on-the-launch-pad/ https://www.reddit.com/r/KerbalSpaceProgram/comments/3bhgxd/apparently_you_can_destroy_the_launch_pad/

A very selective wife, as they only marry ones with exponential significance!