Lisias

It would be a hell of a complicated code, prone to errors, when a single "hack" would do the job. The thing is that I would need to remember not only the parts that were warned, but also what they were and why they broke - some warnings are triggered on combinations of changes (i.e., installing more than one fuel switch at the same time on a part), and so a new add'on being installed or removed can create or fix the condition on which the warning would be triggered - so a part that had a warning last time could be fixed and then broken again in a different way (and this was effectively happening a lot some time ago). So I choose to check the timestamp of the ConfigCache and call it a day.

Because the Console is where the money (still) really is. Consoles are a locked down eco-systems, where piracy are almost non existent and you have a lot of support services handled by the console manufacturer. It's expensive as hell to publish something there, but also (usually) very lucrative. I'm plain guessing here, so take what I say with a grain of salt: KSP and the Add'On Scene are a marvellous laboratory to test ideas, and the best ones can so be later implemented indo DLCs to be sold on Console. Even KSP2 is, now, drinking on years of Add'Ons development experience. This whole thing gives them a good hint about what works and what doesn't, and this maximize their chances of profit on Consoles (where publishing things is way more expensive than on PC, so experimentation is unfeasible). You know, that's not a bad idea... [Except about the JSON/Zipping thing. String processing is expensive, Remote Process Communications are better handled with binary protocols like Google's Protobuffer or the old and faithful RFC 5531] I see some problems with the cost of the stunt, however: Private Division would need to maintain a respectful farm of "manycore" servers in order to provide Processing Services for the players, and this costs money. Lots of money. So they would need probably to switch to a subscription model of revenue...

from BDB thread: Damn, really? I will check what can be done... Can you advance for me what's going wrong with Smart Parts and Recall? Without Recall, Career is seriously hindered on a modded KSP 1.11.x ....

Thank you for zeroing into the problems for me! I will took over from here as soon as some RL issues are solved (everybody are terribly overloaded at job nowadays...) Yes. Once the ModuleManager.ConfigCache is one hour old or older, the Yellow Warnings does not appears anymore (until you install or remove something, what will rebuild the ConfigCache, and then they appear again for one more hour). If this warning keeps showing even after one hour since the last time you added something to KSP, then we may have one of the following problems: I messed up something on the code without being aware. I'll check this in the next hours, as time allows You have an Error on the patches installed on your GameData, and this prevents Module Manager from creating the ConfigCache, so TweakScale will always show the Warning Please check the Module Manager's log for any ERROR messages, and then ask the Maintainer for a fix. (There's also a message in ORANGE on the MM's Patching Messages on boot). It will look like this (I forced an error on Recall to illustrate it) Alternatively, you can try to fix it yourself (some of these errors are simple to fix) Or just remove the offending Add'On. Something else is "touching" the file (UNIX lingo) and updating the last modified property , fooling TweakScale into believing it was regenerated again. It's pretty unlikely, but not impossible. I mentioning it just for the sake of completude. If you are incredibly unlucky to be hit by such stunt, you will need to find the culprit yourself - as I can't help.

The problem, dear sir, is that the binary being distributed by CKAN does not matches the B9 PWings Fork's Forum Thread author. The Current NetKan file says: SpaceDock: https://spacedock.info/mod/2525/B9 Procedural Wings Modified Continued (authors tetraflon, CarnationRED) Forum Thread: https://forum.kerbalspaceprogram.com/index.php?/topic/175197-13x14x15x16x17x18x19x-b9-procedural-wings-fork-go-big-or-go-home-update-40-larger-wings/ (author Jebman82) The Forum Thread pinpoints to B9 Procedural Wings Fork, from Jebman82 and where FAR is not a dependency. It explicilty pinpoints https://github.com/Rafterman82/B9-PWings-Fork as the authoritative source and the link https://github.com/Rafterman82/B9-PWings-Fork/releases/tag/1.0.0 as the latest version. The SpaceDock link pinpoints to B9 Procedural Windows Modified Continued (from tetraflon and CarnationRED), where FAR is a dependency and the repository is https://github.com/tetraflon/B9-PWings-Modified . And I will quote the netkan file: "identifier": "B9-PWings-Fork", "name": "B9 Aerospace Procedural Wings - Fork", And I will quote the SpaceDock page: Please observe that Jebman82 is not listed as owner on the SpaceDock link. The whole mess happened because CKAN since December 2020 is misrepresenting B9-PWings-Fork . Good thing this is licensed under the MIT, as I'm not sure if GPL (and others) would allow such a thing. A new CKAN identifier "B9-PWings-Modified-Continued" would be a better (and probably safer) option. It's also worth to mention that when you select FAR to be installed, a submenu appears asking you to select what fork you want (the original one or the continued). This would be a good solution for the dilema, I think.

This is an utter misinterpretation about what I had said. Please read it again: (emphases are mine) Users can get a lot of "abuse" when they believe you are doing the best you can. That fine white pieces of paper hits the turbo-fan when they start to believe you are not. Perception, dude. It's about perception and empathy. (and perhaps a bit of text comprehension?)

Good question... I checked my history for links I visited this weekend, and only found the download link for a mod_pack, something completely different. Curiously, the CKAN file I got also had some random mods I picked from your modlist.txt - so perhaps I had a false confirmation for something I completely misunderstood? (it was late night when I had time to try this). Well... Give me the CKAN file you are using. This will solve the problem for good.

If you reproduce it again, pack all logs you can find, module manager thingies (configcache, tech tree, etc), the SFS file and the craft file. Exit KSP first, to make ksp.log is not truncated. Also a CKAN export (not only the modllist), so I don't have to convert it on KerbalX (one less variable on the equation). I find this pretty unusual. Every living part belongs to a living craft, and if TweakScale can't find the living craft (what we can know due the <UNK> thingy), it's because something is keeping the part alive after the owner was removed from the game - what's usually someone forgetting to withdraw a Module from a game event on destroying. Another possibility is a third-party booking on a critical section of game, and then a perfectly fine code that would withdraw the part from a gameevent is never run - and we have a similar misbehavior. So I'm confident it's a DLL problem, not a patching one. Worst, something not deterministic.

Hi, @SuicidalInsanity! I found something odd. I just installed Mk3 Expansion via CKAN to diagnose something completely unrelated (but since the user had this installed, so I had to have too), and found this problem on the localization file: #LOC_M3X_CSaddleTank_Name = Mk3 Short Trucated Saddletank #LOC_M3X_CSaddleTank_desc = A short fuselage extension saddletank designed to fit on the side of a Mk3 fuselage. This one is truncated to fit around an open mk3 cargo bay. <color="green">Has three variants.</color> #LOC_M3X_CSaddleTank_tags = mk3 m3x aircraft airplane fueltank jet ?lf only plane propellant tank extension There's a missing EoL between _Name and _desc . However, I just checked on GitHub and everything is perfectly fine there. Some distribution file is messed up somehow! Cheers!

Users only understand about their own problems, and we start to get problems when we are the source of their problems. Users don't mind coping with some problems if they understand this is the best you can do at the moment, but they start to get really annoyed when they perceive it as a way to make your life easier at their expenses - you start creating problems for your users, they will replace you at the first opportunity they manage to find. It's simple like that. (and keep in mind that for each user that complains, there're a lot that just give us the finger and go away). Shoving unnecessary dependencies to make your life easier is not a good strategy to solve problems - it may be a valid last-resource/last-minute workaround, but you expand the surface of attack for problems that just would not happen otherwise. Not to mention forcing the users to cope with things they don't need and don't want. FAR changes drastically the way the game behaves, it's not even something that can be easily deactivated. Forcing FAR as a dependency was a bad move. You are affecting negatively B9PW users, and B9PW itself.

Yep, it helped. thanks. I'm currently downloading the whole shebang (my poor rig is crying quietly in anticipation of the test session - man, what a collection of add'ons!)... I will edit this post with my findings. On a side note, a .CKAN export would be better - the modlist needed to be converted by KerbalX (what's not a problem at all), but when CKAN checked the (current) dependencies, some options had popped up and this means that I may had choose options different from what you had choose. -- -- POST EDIT -- -- Something called CraftImport is issuing some Exceptions on my rig, and I didn't found my way on Construction Time. I'm removing these things from the testbed, but it will take some hours until I find time to check this again. Stay tuned. -- -- POST POST EDIT -- -- @Crimor, I could not manage to reproduce the problem. I used the FT-T400 (after spending some time looking for FT-400 it's late...), scaled it up, scaled it down, attached it something, attached something to it, and nothing. When installing, CKAN added FAR and WildBlue Classic Stock Resources and I had to install them because they were tagged as dependency for something else, and I later removed FAR (after doing some tests with it too, just in case...). A complete report for this test session is here: https://github.com/net-lisias-ksp/TweakScale/issues/92#issuecomment-843140403

And exactly how do you intent to motivate people to work with you on this problem? KSP Recall was engineered since the inception to allow this, as I had foresaw people would take the easiest route to just install it on everything. But yet, a user complained about having it installed without needing it. The present case of B9PW is different, FAR really changes significantly the game experience when installed. Living crafts on the savegame will not work as the user had designed it, this is going to break savegames. [snip]

No, sir. I'm proposing a CKAN plugin to handle the current weakness of CKAN to be unable to handle the present situation - that it's not the only one, as I had to certify KSP-Recall to allow it to be installed on KSP versions it was not intended to run exactly because this weakness. We have conditional dependencies that can or cannot be necessary depending of the current user's rig state. On this specific case, FAR is a workaround needed only when MechJeb is installed at the same time B9PW is (Recall have different rules - but that can be worked out similarly by using the KSP version as a "add'on" to be checked). Given the current notoriously resistance on implementing new features on CKAN itself, writing a plugin for it would reach the same end-result. The PoC proves that you can change CKAN's behaviour using a plugin, so the IGUIPlugin is relevant to the question. What do you expected, that I would solve the problem in a couple hours? I was rebating your argument, where you wrongly stated that IGUIPlugin was not relevant. No reflection was needed, the hooks that can be used to inspect what's happening are available to be used - [snip] no reflection was used at all. I'm being vocal and incisive about a terrible decision made by CKAN, injecting on everybody that uses B9PW unwanted and unneeded dependencies that changes critical behaviour of the game (with consequences on savegames) to workaround a temporary problem that affects only a few use cases.

This log didn't helped me, as it doesn't patches any of the parts I detected something weird on your last log. Sorry. Could you please reproduce the problem again with the current modset, and then publish everything again (including the MM logs)?

Uh... Not exactly. KSP is terribly unoptimised, so the current memory footprint is problematic even on more powerful gaming rigs as the PS4. But on a closed subset of the game, you can optimize enough to be useable on it. The KSP main CPU bottlenecks are the PQS system (the "planets") and the Physics Engine. If someone manages to implement something very simplified but yet useable, a subset of KSP is feasible to be implemented on the Switch. Granted - if that subset would be interesting enough to attract players is something to be discussed, no doubt. Being feasible is something, being lucrative is a completely different beast.

But you can't just ignore the breakage you are promoting in the mean time - [snip] FAR is not compatible with a lot of add'ons that would work fine with PW. IGUIPlugin exists, it's working and can be used to add features to the main CKAN - so it's relevant. And the code that does this trick is here. This is a Proof of Concept of something that can be implemented to check the current installment for the Add'Ons that triggers a problem (MechJeb2 and B9PW on this case), and so alert the user that he should install something else too (FAR, on this case). This solution would be WAY more sensible than just shoving FAR on everybody that installs B9PW - FAR changes the game physics in drastic ways, you are screwing up savegames from people that don't want to use FAR.

Users SHOULD think that other solutions must exist and/or are being pursued. Otherwise they will ditch CKAN, as some (pretty good) Add'On authors did in the past. If no such thing I referenced exists (and if it doesn't exists, how I referenced it?), I strongly suggest someone implement it. FAR changes fundamental behaviours on KSP that the user willing to use PW probably don't want to have them changed (I'm one of them - I have one and only one instalment for toying with FAR, but many with PW).

[Moderator note: This thread was split off from the B9 Procedural Wings Fork thread, due to a lengthy digression into a debate over the best technical way to solve certain problems with CKAN. Since this discussion got off the topic of B9PW itself and more into CKAN and software engineering philosophy, it's been moved off into its own topic.] So, in a nutshell, to solve something that affects MechJeb CKAN added a soft dependency to PW as it would be a hard one (FAR)? Even by FAR being not compatible with some other add'ons that would cope fine with PW? No one ever considered a CKAN Plugin to handle these idiosyncrasies? He did. And he took the most reasonable solution from the developer's point of view. We don't shove unneeded dependencies on a product to fix problems on another one! I understand the problem CKAN had to solve at that time, but that solution created new problems for other people (otherwise LGG would not had did it). What suggests we need a better solution on the long run.

Nothing again. [Found something! I was looking for the wrong problem!] I found some NREs on SystemHeat, Janitor's Closet and MJ2 but nothing related to TweakScale this time.... [EXC 17:06:11.960] NullReferenceException: Object reference not set to an instance of an object SystemHeat.SystemHeatEditor.FixedUpdate () (at <d1c22963482e4eb3bf8a39c8c5c5882f>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) [ERR 17:06:55.272] Janitor's Closet: OnGUIApplicationLauncherReady, 1, exception: Object reference not set to an instance of an object [LOG 17:06:44.178] KerbalEngineer -> at KerbalEngineer.Editor.BuildOverlayPartInfo.OnGUI () [0x00021] in <f7b97258edac489d9f763fc3ebcf33c6>:0 [LOG 17:06:44.178] KerbalEngineer -> Exception // System.NullReferenceException: Object reference not set to an instance of an object at KerbalEngineer.Editor.BuildOverlayPartInfo.OnGUI () [0x00021] in <f7b97258edac489d9f763fc3ebcf33c6>:0 From these, only SystemHeat may (and it's a wide wild guessing) be related because it's happening on the FixedUpdate thingy, and when something borks on the Update or in the FixedUpdate, a lot of unfinished business can spoil the game. You will need an exploratory cirurgy on your rig: make a full backup, and them remove things one by one while trying to reproduce the problem until it vanishes - so you scrap the test bed, make another copy from the original and then remove only the last few add'ons from the last attempt to confirm these are the troublemakers. Pain in the SAS, but it's the only way. But, first, you need to stablish a deterministic method of reproduce the problem... -- -- POST EDIT -- -- I found something, I ended up being distracted by the Exceptions and forgot to look for the TweakScale's WARNING! [LOG 17:02:28.840] [TweakScale] WARNING: No valid member found for diameter in Part for <unk> [LOG 17:02:57.789] [TweakScale] WARNING: No valid member found for diameter in Part for <unk> [LOG 17:02:57.823] [TweakScale] WARNING: No valid member found for diameter in Part for <unk> [LOG 17:03:51.445] [TweakScale] WARNING: No valid member found for diameter in Part for <unk> [LOG 17:03:51.479] [TweakScale] WARNING: No valid member found for diameter in Part for <unk> [LOG 17:04:36.025] [TweakScale] WARNING: No valid member found for diameter in Part for <unk> [LOG 17:04:36.061] [TweakScale] WARNING: No valid member found for diameter in Part for <unk> [LOG 17:06:10.216] [TweakScale] WARNING: No valid member found for diameter in Part for <unk> [LOG 17:06:10.251] [TweakScale] WARNING: No valid member found for diameter in Part for <unk> [LOG 17:06:37.602] [TweakScale] WARNING: No valid member found for diameter in Part for <unk> [LOG 17:06:37.639] [TweakScale] WARNING: No valid member found for diameter in Part for <unk> And a concrete case: [LOG 17:02:27.118] [BetterCrewAssignment] Attached FU09 FL-T400 Fuel Tank. [LOG 17:02:27.118] [BetterCrewAssignment] Crew assignment complete. Assigned 0 kerbals, left 0 slots empty. [LOG 17:02:28.840] [TweakScale] WARNING: No valid member found for diameter in Part for <unk> [LOG 17:02:30.794] fuelTank added to ship - part count: 3 [LOG 17:02:30.795] [BetterCrewAssignment] Ship modified, 3 parts. I'm working on it as time allows. -- -- POST POST EDIT -- -- @Crimor, I will need the ModuleManager patch log. I found a pattern, now I need to inspect who is patching the parts involved on that pattern. You will find the ModuleManager Patch Log on the <KSP_Folder>/Logs folder, together the other logs you already provided.

No warnings were found on this KSP.log. Let's try something: redo the test, but launch the thing and recover it a couple times. Your issue is smelling something familiar, if I'm right this should trigger something that could be logged.

Looks like you need KSP-Recall to overcome a bug on KSP 1.9, but TweakScale would pesky you to install it and you already would had done it - unless you are using a pretty old TweakScale version. So I don't think things will be that easy for me, let's keep digging. There's something smelling cheesy on this, and it's the "no valid member" thing. The first time something like that happened was due TMasterson5's patches - if by any reason you have it installed, you need to get rid of it. At least the patches mentioning TweakScale - TMasterson5's paches for TweakScale didnt' aged very well... Another possibility is that you have an older version of B9PartSwitch, that has a bug on it causing some zombie parts to linger around way after their craft is dead (and, so, a lot of thingies are not there anymore). Update B9PartSwitch for the latest version, this will a fix some glitches for a lot of thingies, not only for TweakScale. If you don't, I will need your KSP.log for further inspection. See this post for further instructions (go to the "Support" section and open the Spoiler)

Well, more or less. I can't detect rogue patches, only badly patched parts. Once something bad is detected, TS issues a Warning or Fatality and then someone (usually me ) needs to hunt down who screwed up by eye balling everybody that touched the broken part. In the end, I just write all my patches without using wide wildcards at all - all of them, not only the hot fixes and workarounds. It's tedious sometimes, but it's way safer (and polite, to tell the true) to "invest" a bit more of my time once than waste it (and others too) forever handling unwanted colateral damage because I could not foresee the future! Conciseness and quality are not synonymous. It's what I did on my patches. But I'm not the only patcher around, and a few authors still rely on such wide wildcards even nowadays. It's a cat and mouse game, there's nothitng else I can do. The madness never ends!

Well, yep - if you are not careful on using it. By example, lets pretend we need to remove all the resources from parts from AddOnA, AddOnB and AddOnC, all of them made by RandomAuthor: @PART[*]:HAS[#author[RandomAuthor]] { -RESOURCE[*],* {} } Looks great, right? RandomAuthor just published these 3 add'ons, so what could possibly go wrong? Well, some time later, RandomAuthor leaves the Scene and his add'ons got dismembered into many others, maintained by different people, that fixed/updated/whatever the parts so they don't have to be edited anymore. Being ethical and law abiding authors, they kept RandomAuthor as the author of the new parts. Yep, you guessed it right - that patch essentially screwed up beyound fix a lot of parts from different new add'ons. And a stunt like this screwed up a good fraction of my modding time once on TweakScale. What I do since them? I enumerate every single that would be fixed one by one: @PART[part-a-from-a]:NEEDS[AddOnA] { -RESOURCE[*],* {} } @PART[part-b-from-a]:NEEDS[AddOnA] { -RESOURCE[*],* {} } @PART[part-a-from-b]:NEEDS[AddOnB] { -RESOURCE[*],* {} } <etc> Usually just the part name is enough, but I add the :NEEDS clausule as more than once I got the original part adopted on other add'on where the fix should not be applied, so I decided to err to the safer side (and :NEEDS would eliminate the whole patch if the Add'On is not installed, what's slightly faster than looking for a part - so it's a win-win situation).

There're people that still believe that uncontrolled wide use of wildcards on patching is a good idea. Kraken knows how many problems in the past would simply not happened without wildcards.... Some of that patches were so broad I could not fix them with a counter-patch - they were essentially a SQL's update without a where clausule.... (I decided to ditch wildcards on all my patching for a reason). It was my understanding that the use of ? didn't worked for you, what I found intriguing and decided to check it myself... Well... Now we have some public documentation to be pinpointed next time someone think it's a good idea to use odd chars on names. Cheers!

You was bitten by the Module Manager (lack of) parser. The code that checks for is is here: if (!urlConfig.type.IsBracketBalanced()) { progress.Error(urlConfig, "Error - node name does not have balanced brackets (or a space - if so replace with ?):\n" + urlConfig.SafeUrl()); return null; } And it is using the IsBrackedBalanced() function, an extension to the string type (and used by side effect on UrlConfig): public static bool IsBracketBalanced(this string s) { int level = 0; foreach (char c in s) { if (c == '[') level++; else if (c == ']') level--; if (level < 0) return false; } return level == 0; } The function itself is OK, but the problem is that this function is being kept hostage from the UrlConfig class. It's not evaluating what you wrote on the patch, but what the UrlConfig constructor made of it, and for this constructor a parenthesis is not part of the "type" thingie (being type anything you use as the node's name). So, in that context, the urlConfig's type is "@PART[CST-100?Heat?Shield?" (i.e., the "type" name parser stops at the first parenthesis), and not "@PART[CST-100?Heat?Shield?(Brown)]" as you are expecting. (Note that, at this time, the type thingie is the raw text on the node's name, way before the Patch Compiling phase starts). TL;DR: Using ? to replace both parenthesis should had done the trick! I made this test here: PART { name = CST-100 Heat Shield (Brown) } @PART[CST-100?Heat?Shield??Brown?] { MODULE { name = ModuleCargoPart packedVolume = 11410 } } and got this on the MM Cache: { parentUrl = __LOCAL/test.cfg PART { name = CST-100 Heat Shield (Brown) MODULE { name = ModuleCargoPart packedVolume = 11410 } } } So it worked. For anyone else still reading this there's a very strong reason we should use only alphanumeric (and a few non alphanumeric chars, as dashes and dots) for naming a part. We have the part's Title to do human friendly naming for a reason!