Lisias

No, it's just how reddit works. You need time to get traction on a post there, and in the mean time, you need help to prevent people from downvoting you enough to remove you from the main page. You need help to upvote your post to counter-measure the downvoting from the trolls. The trick is to monitor the voting count, and every time it reaches 0, someone upvote to get it positive again. Lots of people upvoting preemptively not necessarily helps, because all the trolls need to do is to use their ghost accounts to downvote and the work is undone. The trick is to upvote gradually, just enough to get to 1, and then start monitoring again until the trolls attack again - rinse, repeat.

It's a way out of the problem, probably the best. But this would involve expending resources that, at this time, I don't think they have available - I don't think they have even a budget to hook these expenses right now. This kind of OpenSource may get expensive to run, you need skilled people available to code review the pull/requests - you become responsible for every commit you merge in your repository (and, yeah, there's always a risk on merging ARR code into your ARR code). I had already said it in the past (premonition!!! hehe), one of the best examples of a ARR code base going Open Source is the Netscape, not only due the huge success they had in the past, but also due the major screw ups they had to survive - and, boy, they had a steep learning curving to cope with! And since I really doubt they would release the code under a OSI license (what, frankly, may backfire on them later), allowing pull-requests into an ARR code may be legally tricky - not impossible, tricky. And this may be a one trick more than are willing to handle at this point. P.D. is in a messy state, whoever is trying to cleaning it up need to be careful to do not add yet more burdens to their shoulders. Having the source code in an archived/read-on git repository (it may be bitbucket, it may be gitlab - you know, this CoPilot thingy is really a concern for everyone willing to publish code on github!!) [edit] under an Unity's style Share Source license [/edit] will be, by itself, a huge difference for the best by itself. Even by not being able to apply patches, being able to clone it into a local repository and submit the codebase to some tools (or even compile it under debug mode and firing it up) will by itself be of a huge service. At very least, will make my work on Recall insanely easier and safer - and this is only me, just imagine what the others Authors may be able to accomplish - from Waterfall to Principia. Make no mistake, I would love your solution - but IMHO we need to aim first into the ones they may manage to afford. You can always go further later, these are not mutually exclusive alternatives. But, in a way or another, this is not a decision to be made lightly.

I'm afraid it was, sadly. [snip] From now on, I'm afraid the best line of action is to mutually ignore each other. [snip] Have a nice day.

Sir, you are completely misguided. We are not free cheap work-force that will drive all the work for them. You don't need to rewrite the entire game, the absolutely most terrible bugs are rooted on silly mistakes and mishaps on the code - and a few bad decisions, granted. I'm seriously questioning your ability to keep this discussion productive, you really appears to do no understand about what you are talking about. Some of them, yes. Some others, are rock solid as soon as you detect where KSP is breaking them and work around the problem. There are more things in heaven and earth, Horatio, Than are dreamt of in your philosophy. There are different ways inside KSP to accomplish some things, including how to deploy some really deep fixes. I had detected them in the past, but never managed to understand how they work precisely by not being able to see the Source Code without breaking Forum's Guidelines and the EULA. Really, you need to stop thinking that every add'on Author is a kid trying their way to see what happens. There were (and still are) very skilled professionals around here, and that's the reason it's important to do some things right (as access to SC) - because professionals can't break the law without consequences to their day-jobs.

You are not well acquainted to the KSP Modding Scene, are you? Such affirmation from someone out there that never had played KSP before is understandable, but from someone that its a frequent user on this Forum, it's quite hard to believe that you had said that. KSP is highly modular. There're a lot of things that can be made to work around almost all flaws on it - all of them way easier to accomplish when we have access to the SC and know exactly what's happening, instead of taking days on black box test sessions in order to finally nail down some ancient bug that nobody was able to detect before. There're a lot of internal mechanisms that we don't know exactly how they work, and once we manage to get a grasp on it, will help us a lot to accomplish exactly what you said is not accomplishable - and following the Forums' Guidelines and the EULA.

nasty, perhaps. But it's effective? Some pills are bitter to swallow, but they still are the pill to cure us. As far as I know, it is. Patching is the only choice. We are not the publishers, we can't just recompile the damned thing and republish it ourselves. They had years to fix things. They didn't. It's time to @HarvesteR what they had sowed.

Perhaps we should try reddit? No one is proposing rewritting KSP1. The goal is to patch its flaws and give the Franchise a bette chance on the short term. There's life everywhere else - ESA has teamed up with Jundroo to launch a ESA mission inspired update for Juno:New Origins. Do I need to say more? The time is now. Tomorrow is too late.

Not only that. They are, right now, on the verge of a Strategic Inflection Point. [snip] We are asking that such privilege be extended to people that does mind Forum's Publishing Guidelines and the EULA. Whatever is their decision about this subject, will shape the people that will be around here publishing add'ons for the Community. This may change with more skilled people with real experience on handling and refactoring legacy systems being able to help. If we can manage to fix KSP(1) properly, without risking our SASes on shady practices and being able to see in situ the effects of what we do, we may give the Franchise some air to breath, what will increase the KSP(1) incoming, that so can be injected into funding KSP2. They get some skilled QAS being able to do their magic easier and quicker, and we finally get the game we had paid for for starters. A good bargain, if you ask me - this will be a real improvement on the status quo. Of course, there will be drawbacks - there're always drawbacks. Perhaps one of them may hinder the endeavour - but, hell, really big guys did it in the past, and still do it and it also will help to detect unduly use of the reversed engineered SC that it's already in the field. The benefits may outweigh the risks by a mile if things are done properly. This will not solve all T2I problems, no doubt. But every surviving mosquito lay eggs that leads to more mosquitos - we don't clean up our houses to completely kill all the mosquitos of the Word, we clean our houses to keep them in an acceptable level.

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!