Lisias

Bad patching is always a pain in the SAS, even when it appears to work at first, Try diagnosing the thing as we did last time: do a full copy of the installment, then run the copy eliminating one AddOn at time to see what changes. As soon as the problems vanishes, you found something - but not necessarily the culprit. Publish the KSP.log too, sometimes it's something easy to spot on an eye glance.

Yes, we can. And yes, we do. And that's the problem.

It may be intimidating at first, but it's really not that hard once you get your grasp on it. First thing is to download and install Visual Studio Community Edition. The installer will do the heavy lifting for you. Then, instead of downloading the code, it's better to clone the repository. For that, you will need GIT. Using the embedded GIT client on VS is possible, but I hate this piece of crap, I prefer to use a proper GIT client, as Source Tree or Git Kraken. If you never heard of GIT before, I strongly recommend you to read a good introductory tutorial about the matter. Once you cloned the repository and installed the VS, all you need to do is to open the Solution File (SLN) using Visual Studio, and 80% of your problems are solved. And so you will have something like this on your screen: Now with 80% of your problems solved, we need to solve the other 80%. Every project on KSP has a thingy called Dependency. It's something else that your code relies in order to work. Unity Engine is, obviously, one of them, and the KSP libraries are another. On Visual Studio, we set them on the References "folder" on the Project Explorer: That ones inside the References thingy is each one of the Assemblies I used on this project. An Assembly is a "collection of related code" on C#, and are usually delivered inside a file called DLL (Dynamic Linked File). This is a source of confusion, because DLLs were initially meant to deploy shared C++ compiled code, and when used for this, the dependency is the DLL itself. On C#, however, DLLs are only glorified ZIP files - the dependency is not the DLL, but what is inside it. So the DLL can have any name, as long the Assembly inside it has has the name you need. But, yet, the Assemblies are deployed inside DLLs, and usually the DLL file name follows the name of the Assembly it delivers (but not always, pay attention to this detail as it can bite you on the SAS horribly). What leads us to another problem. You will not get a References list nice and ready to be used as it's shown above. It's almost sure you will have a messed up References list, as shown below: This means that the DLLs I'm using on my machine are not available on the same place on yours. This is the first thing you will have to fix in order to recompile the add'on. There're many professional ways of solving this problem, but usually people playing with KSP add'ons are not professionals and, so, not prone to waste time on learning how to do it professionally. So let's do it the simple way: quick & dirty - it's how I do anyway... The easiest way to fix that, so, it's just to pinpoint the References to your local KSP installment you want to use for toying - I strongly advise you to make a copy of your game and use only that copy for toying add'ons - you can really screw up things by mangling source code, compiling it and running it on KSP. Believe on me, I know what I'm talking. So, take note of every red alerted Assembly name on the References and delete them (there's a glitch on Visual Studio that if you try to add new references for already existing ones, on deleting the crappy one the new one is deleted too - so it's better to delete them first). Click on the crappy Assembly using the right mouse button and select Delete: Now you will add the copies you have on your machine (you took notes of the Assemblies you deleted, right?). To do so, Right Click on References and select Add: It will open a Modal Window, select the Net Assembly tab: And then click on the Browse button under the list of current known Assemblies (I expect your list will be empty, mine if full of Assemblies from many different KSP versions): From now on, it's hunt time, baby. You need to locate every needed DLL. It sounds harder than it is, really. These DLLs are located on very specific places. The KSP and Unity DLLs, on Windows machines, will be on the Managed directory that it's on the KSP_Data directory on the same place where is the KSP.exe file. On Linux, if memory serves me well, it's the same. On MacOS things are different, you will find them on KSP.app/Contents/Resources/Data/Managed . When the add'on your are mangling depends of other add'ons, you will find them on the GameData folder somewhere. You will need to dig a bit on these ones. Now you are done. Build the Solution to see if everything is all right: Once the building is done, you will find your compiled artefacts on the bin folder somewhere on the Solution's folder (dig a little, they are usually on the same place the SLN file is): There 're Release and Debug binaries. While developing, we usually shove a lot of debugging stuff that it's unwanted on the user's machine, so we get these debugging stuff ripped off the code when we compile a Release dll. You select Release or Debug on the top left of the Window (see the screenshot above where I tell how to Build the thing). Now all you need is to copy the compiled DLL (only the one really generated is needed, on the example above, Score.dll) into the right place on the KSP's GameData folder and you are ready to screw up your KSP installment on new and exciting ways!! Just always remember on doing thing on test beds (specialised copies meant to be mangled and mercilessly destroyed while testing things without risking your important savegames), and happy hacking!

Why, by Kraken's Sake, every single thread started by a newbie asking directions about something around here invariably get a one star on the Rate? This is getting ridiculous to the point that I starting to actively look for one star rated posts, as these ones are usually from people really in need of help. Sometimes I wish we could know who is starring the threads.

For the nth² time: this is not customer's problem. I'm sympathise with your problems, but they will not change how customers and shareholders are seeing the product. Blaming previous developers is easy, by the way - and this just don't change the fact that since then, every single opportunity to prevent things from going trough the tubes was just ignored. Your professionalism is measured by what you can deliver with what you have in hands, not by what you could deliver if everything was made right in the past. You accepted the job.

The NREs were fixed on latest Pre Release: https://github.com/net-lisias-ksp/KSP-Recall/releases/tag/RELEASE%2F0.1.0.4 I wil not promote it a proper release yet, because I'm testing if the failed solution for #16 would fix by accident a situation I had foresee on FMRS (over refunding on automatic recoveries). Your over-refunding, however, is due another misbehaviour on KSP, that it's counting TWICE any Resource stored on a Inventory Part. I will take a break in the next hours (RL is calling), but I will be on it again later. Until there, please report anything different using this pre-release. Thanks for the heads up and sorry by the NRE. -- POST EDIT -- I promoted the thing as Release, as it fixed the NRE and a small trick solved the hypothetical problem in which third-parties Add'Ons that would recover Craft themselves would bork the calculations due the Refunding Resource stunt.

I confirm the Exception. That is embarrassing... The code blowing up is this one: private void RemoveResourceIfAvailable() { Log.dbg("Removing {0} from part {1}-{2}:{3:X}", RESOURCENAME, this.part.vessel.vesselName, this.part.partName, this.part.GetInstanceID()); Replacing the this.part.vessel.vesselName thingy with a property guarding against NULLs on this.part.vessel solved the exception problem - as we can see, a part loses it's vessel when moving from the Kerbal to the Storage. (the fix was preemptively replicated on the whole code - better safe than sorry) Well... I was caught with my pants down on this, but thinking a bit on the problem, it makes sense. The fix is on this commit, if you are curious. However, after fixing this, I still got a Over-Refunding!!!! Long story made short, I got twice the intended refunding for this craft. And I know it because Refunding is traceable, and it listed 70 Funds as Refunding besides KSP giving me 140 Funds! The whole history is on Issue #16. I think I know what's happening - the Recovering process is correctly recovering the funds of Stored parts![Nope! The IPartCostModifier is still being ignored on Stored parts - what we found was A BUG INSIDE THE BUG, as the Refunding Resource is being counted TWICE, damnit!] Jesus Christ, how many ways of doing the same freaking thing were implemented on KSP? It's no surprise the code base is so terribly bugged, they implemented the same feature many times, each one on a different way - and once something changes, God knows how may different code that was doing the same thing need to be fixed - not to mention tested! I'm working on a solution for this. Theoretically, it's simple - once the part is stored inside an Inventory Part, the Refunding must be withdrawn, and once it is removed from it, reapplied. But... Nothing is "simple" on KSP, we just don't know how much dirty is under this carpet... [EDIT: I will say it again: Nothing is "simple" on KSP, we just don't know how much dirty is under this carpet...]

My guesses are not the problem. Customer's and Shareholder's guesses are. You know, someone is paying for the Party - and they want the interests back. It's not what I want, sir. It's what the customers want. Being fair or unfair, there's a contract on this thing - and providing bugged products rarely is a way to fulfil such contracts. I don't know who is paying for this Party - I'm sure I am not one of them, because the ones paying for the Party are the ones calling the shots. Obviously, customers like me are not the ones calling the shots around here.

Perhaps. But yet, they are there. Let's hope there're not enough to make you wrong. Faith and Hope. Not exactly a good business plan - but, well, perhaps I'm irrelevant. “The story so far: In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move.” And then the Deflectors of Responsibilities were created. The second most ancient profession, I think.

Lots of people disagree with you. Lots of people disagree with you.

And exactly how pushing terrible, absolutely terrible releases as the recent ones will improve the situation? So I think the devs need to get some financial help from Private Division on this matter, because another core concept not being understood is that the current state of affairs is damaging the brand's reputation to a serious level. We are passing through a peculiar World situation out there (pandemic) where people are spending way too much time inhouse for more than an Year, and so having way more gaming time - and KSP is just throwing all these PR opportunities into the bin, virtually pushing people away from the franchise.

Exactly my point. I'm way less enthusiastic about KSP2 these days, and I think it's reasonable to assume there're lots of people around on the same page...

It was my understanding that the DLCs were intended to mitigate this problem. But 1.11.0 introduced some features (and one of the worst collection of new bugs in KSP's history) that would be better distributed on a new DLC. So it's my understanding that Squad should have receiving some incentive to doing these shining new features "at loss" - after all, "no company would keep a product on the market at a loss". And then, should be expending some efforts on at least preventing new bugs (specially the obvious ones!). Or there's something we are missing here? If there's no money anymore on KSP1, why spending money on developing new features? And if there's still money on it, to the point of giving sellable content for free instead of selling us a DLC, why these features were release on a so horrible collection of new bugs (and I'm not even bothering anymore with the old ones). TL;DR: Who is paying for this party? They are happy with the music the band is playing?

You did it right on the first post, I misunderstood it and ended up getting into your way. Sorry. But at least I understood what was happening, what happened and why. So, lets explain your initial approach: %EC = #$@MODULE[ModuleDeployableSolarPanel]/chargeRate$ it didn't worked because the thing inside the $$ is a path that starts on the root of the gamedatabase. Think of the database as a kinda of file system, and everytime you write something beetwen { } is like creating a subdir on that place. Well, you want a value on the same level of the value you are creating but the patch you wrote was looking for a "MODULE with name = ModuleDeployableSolarPanel" on the root of the gamedatabase, not on the current level. Looking on github, I found patches using "../someValue" inside the $$, fetching things on the parent "folder". Since it was on a MODULE, the parent was a PART. So I tried this: %EC = #$./@MODULE[ModuleDeployableSolarPanel]/chargeRate$ But it didn't worked, and the reason was simple: the `@` thingy is what was making the thing looking for the MODULE on the gamedatabase root level. It took me some time to realise that the samples I got on github did not used @ at all. Then I tried this: %EC = #$./MODULE[ModuleDeployableSolarPanel]/chargeRate$ What I thought it should work, because I found people doing on onversionRate = #$../ROLSCrew$ github. But it didn't. Then, on a gesture of exasperation, I got rid of the dot: %EC = #$/MODULE[ModuleDeployableSolarPanel]/chargeRate$ And, now, the freaking thing worked fine. So... Rules of thumb: Inside $$, we just use @ when the "path" to the thing starts on the root of the gamedatabase Inside $$, ../ leads to the upper hierarchy. But the current hierarchy is addressed by a single slash!! (damn!) MM errors messages are terribly misleading!!! The MM message says it CAN NOT parse the $$ thingy inside a editing/adding/whatever node. This is wrong, the real problem is that MM could not parse THIS $$ thingy because it didn't found it on the gamedatabase. (damn it) (and I will not even talk about the messy syntax used on this whole stunt - this make Perl looking as Classic Poetry).

Yep, but by them you will have TWO copies of the values, what is not a good idea since usually the first copy is used, not the second one. -- -- -- POST EDIT -- -- -- Wait a bit, I missed the "/" detail. Let me check this myself... -- -- -- POST POST EDIT -- -- -- The "/" stunt just get rid of the error, but didn't did what you expected. The original values must be there, and I think you created new values those names start with slash. This is not an operator on MM, it's a path separator - I think this may be creating the value somewhere else on the GameDatabase! [edit: on the same level of the patch]. (I will give this stunt a try to see if I'm right!) Check the Module Manager Config Cache to see the results, it's always recommended to double check things on it just to be on the safe side of the Force.

ANNOUNCE Release 2.4.5.0 is available for downloading, with the following changes: Adds two Module attributes to allow granular control, part by part, of TweakScale behaviour, allowing it to be deactivated at user’s choice, or even made unavailable without the need to deinstall TweakScale (and then screwing up savegames) Intended to make easier to take party on Challenges where TweakScale is not allowed Also allows Challenges to easily ban TweakScale only on some parts by patches (or even code). Issues Fixed: #172 Wait for KSPe bug #10 Some interesting installment checks were updated on KSPe, and the respective KSPe Light for TweakScale was updated with them. #170 Add ‘active’ and ‘available’ properties See OP for the links. Highlights Standard mechanism to control TweakScale availability From 2.4.5.0 and up, it’s possible to deactivate TweakScale on some (or even all) parts by patching or on the user interface without affecting living crafts on the savegame (or even already existent craft files). A patching only feature can lock up TweakScale on the current state, making easier to create artefacts to automatically reconfigure a savegame for Challenges with specific rules. Again, without affecting existent crafts or savegames - once the craft is launched, it’s not affected by these options. See the Documentation for details. Formal support for KSP from 1.4.4 to 1.11 KSP 1.11 didn’t introduced any changes that break TweakScale, so it’s formally supported. However, in order to proper support Variants, the minimal KSP version supported by now is 1.4.4 . Sorry for that. TweakScale 2.5 aims to bring back support for KSP down to 1.2.2 (exactly how, is still work in progress, but it’s feasible as being demonstrated by some Unofficial forks of mine). Parts with Variants Variants that change Cost and/or Nass are now fully supported, but TweakScale is struggling to support Parts with Variants that changes Attachment Nodes. I had planned to withdraw TweakScale support from such parts as I did in the past, but then I realised that most Version 2 parts from already scalable parts (as Terrier…) would had TweakScale withdrawn, and this would render some crafts and savegames corrupted. Since most of these parts didn’t misbehave on a noticeable way, I decided to just let it go as is for while. Just a few stock parts are misbehaving into a noticeable way, and these parts are (until the moment): The Mastodon engine The Structural Tubes T-12 T-18 T-25 T-37 T-50 And probably more, as Add'Ons starts to use such feature. The only workaround at the moment is to descale these parts before applying the variant and then scaling them again. Alternatively, just detach and reattach the misbehaving parts. A proper fix is Work in Progress, and is expected to be released on 2.4.4.1. Deprecating Patches Support for all non Squad parts are on a deprecating status and will be definitively removed on TweakScale 2.5. The TweakScale Companion Program will be the source for supporting third-parties add'ons. It’s advised to install the needed Companions as they reach Gold status. Sanity Checks Parts using Firespitter’s FSbuoyancy needs the latest TweakScale Companion for Firespitter, as only the Companion has the specific code that knows how to handle it. Overrules A overrule, as the name says, is a patch the overrules TweakScale (and anything else) in order to make things broken in a deterministic way. A complete essay can be found here. Hot Fixes A Hot Fix is a hand crafted patch that fixes by brute force patching problems, forcing the original intended result for a given KSP installment. The difference from an overrule is that Hot Fixes don’t break compatibility with sane installments, so you can start new savegames and share your crafts without worries. A complete essay can be found here. New Scaling Behaviour A new TWEAKSCALEBEHAVIOUR, ModuleGeneratorExtended , is available for parts using ModuleGenerator that wants to scale the INPUT_RESOURCES too. This feature wasn’t introduced directly into the ModuleGenerator’s TWEAKSCALEEXPONENTS to prevent damage on Add'Ons (and savegames) that rely on the current behaviour (scaling only the output), as suddenly the resource consumption would increase on already stablished bases and crafts. Just add the lines as the example below (the output resources scaling is still inherited from the default patch!). @PART[my_resource_converter]:NEEDS[TweakScale] { #@TWEAKSCALEBEHAVIOR[ModuleGeneratorExtended]/MODULE[TweakScale] { } %MODULE[TweakScale] { type = free } } WARNINGS The known Unholy interaction between modules (Kraken Food), rogue patches or known incompatibilities between third parties Add'On that can lead to disasters are being detected on the Sanity Checks with a proper (scaring) warning being shown. A full essay about these issues can be found here. Unfortunately, such issues are a serious Show Stopper, potentially (and silently) ruining your savegames. This is not TweakScale fault, but yet it’s up to it to detect the problem and warn you about it. If this happens with you, call for help. A Cancel button is available for the brave Kerbonauts willing to fly unsafe. TweakScale strongly recommends using S.A.V.E.. Special procedures for recovering mangled installments once the TweakScale are installed (triggering the MM cache rebuilding) are possible, but keep your savegames backed up. And DON`T SAVE your crafts once you detect the problem. Reach me on Forum for help. TweakScale stills mangles further affected crafts and savegames with some badly (but recoverable) patched parts so when things are fixed, your crafts preserve the TweakScale settings without harm. THIS DOES NOT FIX THE PROBLEM, as this is beyond the reach of TweakScale - but it at least prevents you from losing your crafts and savegames once the problem happens and then it is later fixed. You will detect this by KSP complaining about a missing TweakScaleRogueDuplicate module (previously TweakScaleDisabled, renamed for clarity). You can safely ignore this. Keep an eye on the Known Issues file. — — — — — This Release will be published using the following Schedule: GitHub, reaching first manual installers and users of KSP-AVC. Right now. CurseForge. Right now. SpaceDock (and CKAN users), Right now. The reasoning is to gradually distribute the Release to easily monitor the deployment and cope with eventual mishaps.

Some of these ambulance chasers eventually hit the jackpot. https://www.nme.com/en_asia/news/gaming-news/cyberpunk-2077-cd-projekt-red-founders-loss-2841730

Appears to be a limitation on the patching mechanism, you can't edit an attribute using "variable search" on the value side.[no, just an idiosyncrasy on how path works] How about removing the any previous value before trying the (re)assignment without using operators? @PART[*]:HAS[@MODULE[ModuleDeployableSolarPanel]:HAS[#resourceName[ElectricCharge]],!MODULE[ModuleCommand],!MODULE[ModuleEnginesFX],!MODULE[ModuleEngines]]:NEEDS[BeamedPowerStandalone] { // Make all NFS panels beamed energy receivers, assuming 1 EC/s = 1m2 of receiving area !EC = deleteme EC = #$@MODULE[ModuleDeployableSolarPanel]/chargeRate$ !Area - deleteme Area = #$EC$ @Area *= 1 // Convert to diameter (since beamed power uses that as a measure... assume a circular receiver) !Diam = deleteme Diam = #$Area$ @Diam *= 0.318309886 @Diam != 0.5 @Diam *= 2 MODULE { name = WirelessReceiver recvType = Directional recvDiameter = #$../Diam$ recvEfficiency = 0.98 } }

Stake Holders don't care. Shareholders less yet. All they care is about the money. See CD Projekt Red recent fiasco.

Being so, why this post: would be an appropriated response to this other one? Being yet more explicit, as perhaps you didn't paid enough attention to the discussion at hand: How your conter argument to @dprostock's reply to @ShuttlePilot's statement I quoted above should be understood?

(emphasis are mine). And exactly how this is supposed to be reassuring?

Load managers to prevent loading unwanted things is a solution for a problem on modded instalments, not stock. And the textures are already compressed - the problem is the DPI used on them, aimed to high end computers by default, and these are the Achilles heel on the loading process: people playing on 1080p are loading 4K textures, that are horribly over-dimensioned to be used on 1080p. So, the user that knows how to set the texture quality to save VRAM e GPU's juice, rapidly finds the loading time slower (as now the textures need to reprocessed on loading), not to mention the U.I. elements being terribly blurred. (some of them beyond recognition). That's the thing: these things are necessary, they are assets that will be used in the game - eventually. Long time ago, on a time where KSP still run on 32 buts and had a pretty small palette of parts, they decided to preload everything in memory because KSP had no "game stages" - the user could jump to anywhere in the "Universe", and they didn't wanted to annoy the user experience with loading times on a insertion burn. Made sense at that time. But we are not on that time anymore, the stunts and tricks that worked fine on small scale will bite you on the back badly on large scale. SSDs and transparent file system compression (BTRFS, APFS and NTFS) helps a lot, but don't fix the extra burden on downsizing textures on loading time to match the selected Texture Quality. Clearly, some thinking are being utterly missed on the whole process. Caching the downsized textures to be reused next load will hugely benefit these users (at expense of some disk space, granted) - and a way to prevent mipmapping glyphs used on the User Interface are terribly needed too.

You don't need a too modern GPU to have a good KSP experience - I'm running too on a HD 4000 graphics, and was using a HD 3000 until recently. Got some decent playing, the bottleneck is VRAM. You need to keep your VRAM consumption under tight control, everything works fine after. Problem - lowering the Texture's Quality will do it for everything, including the widgets' gryphs! So, if you lower the texture's graphics too much, the User Interface's widgets become so diffused that you can't tell if a check box is checked or not!!! Not to mention the time for loading them. The textures are downsized on loading time, every load. So you waste time on loading an unnecessarily big texture (if you are using spinning disks this is specially annoying - not to mention wasting space on expensive SSDs), and also on post-processing the textures on memory to the desired quality level. A simple precomputed cache for the textures would drop the loading times a lot - and avoiding mipmapping textures used for widgets would be a huge benefit for users with modest rigs. "Premature optimisation is the root of all evil" - Sir Tony Hoare. You can bet your mouse that a lot of problems we have nowadays were due premature optimisations - and not only on KSP itself - some core add'ons are also sinners on this. Fix the bugs first. Then try to find out bottlenecks and optimise the worst ones.

I'm hearing lots of OSTs lately! (Oblivion's music is pretty decent, I say)

The consumer, the almighty dollar and some legislation. When you buy a Company, you buy the whole shebang, including assets and also debits - and responds for any previous unsolved misbehaving incurred in the past - including legal ones. Granted, only KSP I.P. was bought - not the Game Studio. Nevertheless, I suggest reading some legislation about transferring of Assets. The recent fiasco from CD Projekt Red also suggests that the almighty dollar is not the only factor to be considered anymore.