Lisias

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.

Nope. @dprostock maybe?

ANNOUNCE KSP Recall 0.1.0.2 KSP Recall 0.1.0.3 is on the Wild, featuring: Pretty stupid mistake on Refunding fixed. Updating KSPe Light. The problem fixed on 1.0.2 was masking another problem on Refunding that, once fixed, regressed the over-billing problem. GameEvents related to vessels don't work as I expected. The solution was to step back a bit, and risking some over-refunding on FMRS on automatic recovery. All Distribution Channels are up to date. Cheers!

You really believe that? They have a page to report KSP1 errors and I would say less than 5% had treatment. (ha! getting a grasp on nesting quotes! ) These are two different things. Fixing bugs on an Early Access is "cheaper" because usually you don't have too much final content developed for the thing - so fixes are most of the time "cheap". Once the product is shipped, the content that was made for it is shipped too, and any medium to minor bug that would incur on rework on the content is, usually, plain ignored. Reworking a piece of code is one thing, reworking a lot of content because they were made relying on the bug is way more expensive that fixing the bug. Not to mention that the content creators may had been already reallocated to something else, and then we have a scheduling problem too,

ANNOUNCE KSP Recall 0.1.0.1 is on the Wild, featuring: Minor revision to make life easier for Package Managers as CKAN. Will allow installing on any KSP >= 1.4.1, even by not having (yet :P) any fix for them. Closes Issues: #14 Make Recall safe to be installed on any KSP version instead of yelling about not being compatible All Distributions Channels are up to date. Cheers!

Hi, thanks for reaching me. Yep, I had noticed that. On KSP >= 1.8, nope. It's safe for sure. But on KSP <= 1.7.3, perhaps - I'm trying to make KSP-Recall safe to be use anywhere, but didn't tested it yet on anything less than 1.8. To tell you the true I should, but ended up forgetting about (besides being a non functional requirement since the beginning... I'm getting old! :P). Give me some hours, I'll use a time window I stoled found on my working hours and check it. If anything weird happens, I will try to issue an update by the night, then we can update the CKAN file. -- -- -- POST EDIT -- -- -- Nope, KSP-Recall will complain on KSP < 1.8. I will revise the thing and make it to work (or, better, make it to DO NOT work but allow being installed) on any KSP version. Task: https://github.com/net-lisias-ksp/KSP-Recall/issues/14 -- -- -- POST POST EDIT -- -- -- KSP Recall 0.1.0.1 on the Wild. Pull Request to NetKAN adding KSP-Recall as a dependency applied as requested. Let's hope I didn't messed up something!

Hi! Doing fine, besides these turbulent times. Hope the same for you! So we are on the same page, with me being there since 2018. What happens is that the MH patches were initially a 3rd party Add'On, and later it was incorporated into TweakScale. The guy that wrote the MH patches did a good job, as you found. The original TweakScale patches are pretty older, built on KSP 1.0 times I think. And time wasn't gentle with them. I didn't. When MH patches were made, the guy that made it had the original patches and some time playing with them to know how to improve things. On the other hand, TweakScale had to cope with an unforgiven environment where you cannot change a scaletype already on the wild without breaking the savegames - on the 1.3 times and older, there was no mechanism on KSP to allow "migration" between PartModules data - so if you change a PartModule, existent savegames will break because they will not have the new data the Module needs. So TweakScale implemented its own migration code (clever trick, by way). However, on 1.4.0, a new KSP mechanism called UpgradePipeline was created to allow migrating older savegames into new KSP versions - and the way this were implemented rendered TweakScale own migration code dead on the water. At that time, with all the problems TweakScale had to cope (some from TS itself, some others not), the fact is that revising the patches just were not a priority. Even nowadays I still fighting to have enough time to correctly implement scaling parts with ModulePartVariants - I'm this close, but RL is playing havoc with my free time, and, frankly, KSP itself is not collaborating too much since some time already. What does not means I'm not working on the issue you found. Check the patches on the TweakScale 2.5 Beta development branch. I think you will like what you are going to see. On a side note, these new patches were not introduced yet (besides TweakScale now being able to migrate scales, as I learnt how to cope with the UpgradePipeline) because I tried to suggest a solution to solve a triangular dependencies problem. Unfortunately, without success. So I'm wetting my feet using the TweakScale Companion Program to test new patches deployment mechanisms gradually, instead of risking a utter carnage by moving these new patches into mainstream prematurely. These new patches work fine for me, I constantly switching TS 2.5 Beta and 2.4.x ones on my test beds, and I still didn't found a problem - but.. I'm not hard playing on TS 2.5 yet, neither I use a lot of famous add'ons that choose to do patchings in a less than ideal way to allow a safe transition. So I'm probing them step by step - because a mistake of mine on these patches can screw up the scales of an entire savegame by breaking a fickle equilibrium reached by plain luck on less than ideally written patches that don't care about triangular dependencies. This delayed promoting the new patches to Mainstream, and I ended up deciding that it could be better delaying the new patches to TS 2.5, and declare 2.5 incompatible with previous versions - not because they are, but because I can't foresee how 3rd parties add'ons will behave. -- -- POST EDIT -- -- Since we are here, what follows is my sweet dreams about patching: @PART[AdvancedCanard]:THIS[TweakScale]:NEEDS[Squad,TweakScale]:FOR[Squad] // Advanced Canard { %MODULE[TweakScale] { type = free_square } } What essentially means "this is TweakScale (so create it on MM), it needs Squad and TweakScale and it should be applied for Squad". Making things this way, anyone wanting to second guess TweakScale patches for Squad would just write: o@PART[AdvancedCanard]:THIS[SomeOneThatDontLikeTweakScalePatches]:NEEDS[Squad,TweakScale]:AFTER[Squad] // Advanced Canard { %MODULE[TweakScale] { type = free } } And this would be the end of my 3rd parties patching nightmares.

Never met one of these... I'm talking about this one, before the times people realised they need cursor keys for up and down! (source) Interesting... Looking into it, I realised I was wrong! The A2 move keys were IJKM. IJKL were the firing keys for a A2 game I enjoyed a lot, crossfire! Interesting how our memory works (or doesn't...)

Well, a mishap on the part definition so. Yep, we can safely ignore this issue - other that showing "Refunding Jettisoned" on the screen, nothing bad will happen. The code that handle fuel switches fixed this by side effect.