Lisias

NOTAM Preliminary support for WaterfallFX is work in progress, and we have a working prototype. #HURRAY!! Soon, on a GameData near you. -- -- -- POST EDIT -- -- -- $@$#@$#$ $@^%@

It's raining...

Another one?

Lower the Texture Quality on Main Menu / Settings / Graphics. On the Rendering Section, you will find a Slider called Texture Quality. It's usually on Full Res, and the other options are Half Res, Quarter Res and Eighth Res. Everybody is upgrading the Textures to 4K nowadays, and this not only is a waste for people gaming on 1080p, as it more than doubles the memory needed for textures both on GPU as on GPU (including loading times). By lowering this setting, the Textures will be downgraded on loading, saving you some precious memory. Even if you have a beefier machine, if you are playing on 1080p this setting would save some VRAM, allowing you to get better FPS or even rendering the game playable on cheaper GPU cards. The bad side of this solution is that Textures that are fine for 1080p will be downgrade too (it's all or nothing), and this can render the U.I. somewhat problematic (some widgets can get so blurred on Eighth Res that you can't tell if a checkbox is checked or not.

Burevestnik Jet Hydrofol. They shoved two IL-18 (aviation) gas turbines on the boat and called it a day. https://pro-fishman.ru/en/kater-raketa-na-podvodnyh-krylyah-opisanie-tehnicheskie-harakteristiki.html

"Ohhh, we have a bingo!!" @Bej Kerman is around? [Uhh.. I messed up! )

TAC Life Support was previously supported, but current patches (still) embedded on TweakScale are deprecated, so it will not be maintained anymore - so any changes on the TACLS weren't implemented (neither will) on it. But updated (with support for legacy versions) patches are on the backlog, to be tackled down as time allows. There's a Companion on the cooks for updated patches for Life Support and Health add'ons (what includes TACLS), but works on it will start only in a week or two, now that I finally am getting some time to breath on Job. https://github.com/net-lisias-ksp/TweakScaleCompanion_FitAndHealth I have some other older tasks on the backlog, but this one will be worked first for sure.

TL;DR: (not everybody is willing to read this wall of text) "I don't want Recall installed" - it's a CKAN problem "Recall was installed (no matter why) and it broke something" - it's my problem The problems are not mutually exclusive, so the presence of one problem doesn't exempt the other. If removing KSP Recall fixed the problem, it's still a bug on KSP Recall. This thingy must be safe to be installed, being it needed or not - otherwise is a major bug that must be tacked down. Users do what users do - some people just shoves everything on the GameData and call it a day, and if this didn't changed in 10 years, will not change now - so it's up to Recall to handle such problems, not the user (or even CKAN - besides I would still prefer it could, I hate bloatware) It's what I do. https://github.com/net-lisias-ksp/KSP-Recall/blob/master/GameData/999_KSP-Recall/KSP-Recall.cfg Everything is deactivated by default. At startup time, the main DLL detects the running environment and selectively creates the tags that Module Manager uses to apply the patches. And the DLLs, even if patched (perhaps by someone toying with the patches), they still check if it's really a good idea to run: https://github.com/net-lisias-ksp/KSP-Recall/blob/master/Source/KSP-Recall/Globals.cs https://github.com/net-lisias-ksp/KSP-Recall/blob/d3f85c8efc5b437db22c86fe4ba4ac4fc295a40f/Source/Refunding/EditorHelper.cs#L38 (so merely blindly patching the Modules on parts it's not enough, you really need to mangle the Globals somehow - i.e., you need to really, really want to activate the damned things!) And even by these flags being active and the modules patched and loaded on the parts, it's still possible to deactivate each one of the WorkArounds on a specific part, by disabling them on the PAW on Editing Time. So, if even by all these safety measures something is still borking on your rig then it's a major flaw that I need to tackle down the fastest as I can!

They didn't had Ubiowelding at that time!

Now I see. Well, it appears so that's a CKAN problem. Please move the discussion to CKAN Thread as requested by CKAN guys. You may be interested on this post and the follow ups in the mean time. In an ideal Word, users should install Recall only if needed and desired. However.... In time, I'm interested on the memory leak problem. Currently, Attached and Resourceful are the current suspects - but both are not activated on KSP 1.11 - They are not even patched on the parts on KSP 1.11, so I'm pretty confused about this. I will need your Module Manager ConfigCache and Patch Log in order to inspect how things are patched on your rig to know where to start looking...

Yep. Old bug, but only diagnosed recently. https://github.com/net-lisias-ksp/TweakScale/issues/175 The problem happens because the current code always assume that every part is "facing forwards". You invert a part and attach it on a scaled part, and TweakScale ends up replacing the attached part relative to the wrong node. If you flip the radial decoupler, the parts should be displaced correctly. It may workaround the problem for now.

Yes. You can just remove it. TweakScale will pesky you about it, but will work. HUmm... Resourceful could be the culprit, but it is deactivated on KSP 1.11. It's is not. Recall is needed to prevent KSP to mess up your gaming due internal bugs - from KSP itself. You can run TweakScale without Recall, but so you will have to cope with the bugs. And such bugs affects a lot of add'ons, not only TweakScale - it only happens that TweakScale appears to be the only one talking about. On KSP 1.9, Recall is needed by TweakScale and any add'on that handle resources (As Fuel Switches like B9PS, Firespitter, Modular Fuel Tanks, etc). On KSP 1.11, Recall is needed by any Add'On that uses IPartCostModifier. And so on. The whole idea is to prevent people having to do so. In a way or another, TweakScale WORKS without Recall. It's KSP that is borking, not TweakScale (or any other add'on). You CAN remove Recall and the affected add'ons (not only TweakScale) will work (or not, on KSP 1.9, the game became unplayable). No. It would be exactly the opposite, I would have to create and maintain different add'ons for fixing things unrelated to add'ons. And so I would have to create and maintain different CKAN netkan files. And in the end, everything would be installed anyway. See below. And Recall only activates the fixes where it is needed. The convoluted ways to make things work would not be necessary if KSP had not such bugs. The headaches are about working around the bugs, not to maintaining the code running. They are just modules that need to be patched into parts in order to work - you don't patch them, they are not activated and so, don't run. Moreover, the present solution satisfies CKAN requirements. CKAN doen't have any dispositive to allow conditional installations. It's all or nothing. So even by me splitting KSP-Recall in many different add'ons (what I don't want), all of them would be installed anyway due CKAN. No gain, just pain. The historic for this request can be followed on TweakScale thread, starting on this post.

From the OP: The limitation is Kopernicus. If Kopernicus is running fine on your system, then N.O. will too.

Ewok Space Program... Hummm....

Because Apple is getting vicious on forcing their hand to induce us to upgrade. On the CKAN executable script, you are specifying bash as the shell to be called to execute the script: And on Catalina and forward, that binary is a frontend that prints this message before forwarding to the old BASH 3.0 Apple still provides. Expect BASH to be away soon, and this will be a major setback because ZSH is not compatible with BASH. Lots and lots of things will need to be rewritten. You will need to choose to rewrite the startup script using ZSH and then perhaps lose everybody using MacOS before Catalina (as we are still using zsh 5.3 or older, and God knows what they are going to do on the newer versions of it - Apple is not known to be fond of their legacy), or to recommend everybody to install BASH via MacPorts or Brew (what a lot of us are already doing to have access to BASH 4 or 5 anyway), and then change the shebang line to #!/usr/bin/env bash . Probably the Safari autocomplete had bitten me (I must had forgot to switch the language to EN_US, and Safari autocompleted Contents to Contentes - a valid word on PT-BR). Autocomplete can be dangerous sometimes... Not anymore. The original VB UI was a abstraction over the Windows GUI. It was implemented over it, not it. And Visual BASIC born on the Windows 3.11 era (yep, Win16!!!), way older than you think. On Windows 95, the Forms were ported to use the Win32 GUI. Newer Forms, obviously, were ported to current Windows's GUI. Besides being highly tied to the Windows way of life, it can be ported to foreign GUIs (as it was, indeed, ported). With variable degrees of success, as we can see. The problem with the Mono port is that they didn't expended enough time debugging the thing to check small behaviour differences between the host GUI and the Windows one. Some things happen in different ordering, as an example. Not to mention the skill of the developers that did the thing - Windows Forms was implemented by Microsoft developers with years of experience on the Windows GUI subsystem, while on the Mono port we had people with a good knowledge on Linux, but not the same level of experience on Windows (and so, a lot of these nuances probably just weren't caught). Some missing features were rewritten on C# and, so, have a performance hit compared to the original C coded ones. And so on. Being the reason GTKSharp appears to be a safer bet IMHO. It's way less convenient that these "modern" UI being launched everyday (as Avalonia), but it's assured to work correctly on every system that ever had the gtk libraries ported to it and this one is here to stay. Expect your grandsons to be using something build on GTK in the next decades.

Apple's Support had seen better days. I plain quit trying to figuring out things from there. Stackoverflow appears to be the way to go, the best technical info for MacOS I have come from there. But, granted, that guys are, most of the time, more technical oriented than user oriented... (the current drama about Notifications being missed on iPhone is getting epic...) If I understand it correctly, CKAN is "divided" in 3 main "components": The Core The Command Line Interface The Windows Forms (Graphical) Interface Only the item 3 is locked into a 32 bits environment because nobody ported the Mono's Forms implementation out of the Carbon library. (Mono is a open source port of the C# runtime, Carbon is the Library for User Interface used on MacOS since the Classic Macs until MacOS Mountain Lion, when it was declared deprecated). Theoretically someone could migrate the Forms over something else, as SDL but nobody cares for Forms too much nowadays, as it appears. (I surely don't! ) Items 1 and 2 work fine on 64 bits. So, yeah, all it needs is someone to rewrite the Item 3 to use something else, ideally GTK because this thing is 100% supported by Microsoft and it's available even for toasters nowadays. -- -- POST EDIT -- -- Oh, yes... I forgot to explain about the command line interface. It will works on the zsh without porblems, you will find a full guide here. On a MacOS, you will probably need to type something like: mono /Applications/CKAN.app/Contents/MacOS/ckan.exe help on your terminal to use it. Hint: use an alias. Edit your ~/.profile file and add to it: alias ckan="mono /Application/CKAN.app/Contents/MacOS/ckan.exe" and you will be able to just ckan help to use it. -- -- -- POST POST EDIT -- -- -- hey, I found something interesting that I didn't knew about!!! Calling CKAN with consoleui option will open a TUI driven menu for CKAN! Very handy, I think this will be a nice workaroud for you until someone writes a new GUI for CKAN! Assuming you added that alias into .profile, type on a terminal: ckan consoleui And you will get: No as smooth to use as a GUI, but it's better than the command line.

You are toasted. Sorry. CKAN is still using Windows Forms, a jurassic UI C# borrowed from Visual BASIC, and on Macs this thing is only available on Carbon, i.e., 32 bits. MacOS Mojave was the last MacOS version to support 32 bits applications (IIRC), so there's no way for you to use CKAN on UI mode (you can't even revert back to Mojave once you install Big Sur, you are really locked on it now. Sorry!) But you still can use it on command line at least.

Yes, it will do. But, to tell you the true, the "DIR /S" should be listing all directories inside GameData too, I was expecting a huge text file with every file inside GameData. Obviously, I made something wrong - but without a working Windows Machine around, I can't test it properly. In a way or another, I had messed up something on my side - I have an old Dell 1U server that I use to munch data, but it's broken. I bought the new part to fix it, but I bought the wrong part and so I could not fix the damned machine today as I was expecting... So I could not finish my "reverse engineering" program that would rebuild a CKAN file from a DIR/S thingy like I asked from you - building all that inverted lists would take too much time on my MacPotato (and I don't even have the disk space needed...) The replacement parts (screw it, I'm improvising now) will arrive only on Monday. Damn. Well, @Crimor had nailed down his side of the problem, so I will give it a shoot now. With a bit of luck, one of the dependencies that is causing the problem it's also present on your rig and this can help diagnosing it. Fingers crossed! I'll be back to you soon. -- -- -- POST EDIT -- -- -- @CrimorFull details here. We have a confirmation, BDB parts are not being fully scaled - the maxAmount of a Resource is being reset while OnCopying (but the current amount is preserved). My best guess at this moment is the same as yours: something on B9PS. I don't think it's something on BDB patches for TweakScale, as the part is being scaled correcly on the original part. The problem appears to be on the OnCopy processing. -- -- -- POST EDIT -- -- -- Yep... I checked B9PS code. It is not handling the OnCopy callback. I'm investigating if there's something I can do.

To tell you the true, KSP-Recall it's a dependency for a modded KSP. TweakScale is only the one being vocal on it. (lots of Add'Ons need KSP-Recall to work on KSP 1.11.x - check github and see for yourself!) Or a third-party patch or DLL those presence triggers something on B9PS that's only perceivable using TweakScale or Recall. Last "problem" I fixed on Recall was due a third party doing checks about the storable volume of the Resourceful volume and borking due it being zero, and the "fix" was to use a so small value that would be rounded down to zero by KSP, but since was still non-zero, that third party DLL stopped complaining. This can be something like this again.

It's happens everywhere, and for a lot of Add'Ons at that time. It's a KSP bug, You are using KSP 1.8.0, and it broke every single Add'on that uses a thingy called UI_ScaleEdit, (and also UI_FloatEdit and UI_FloatRange) and this thingy is used by a lot of Add'Ons (not only TweakScale!). TL;DR: upgrade to 1.8.1 were this was fixed by KSP itself. It will allow not only TweakScale, but a lot of others add'ons to keep working. The diagnosis was initially reported here: And a pretty intense diagnosing process documented here: I had tried to implement a fix for it on KSP-Recall, but apparently I need a thingy called EZGUI SpriteText , and this thing is closed source and last time I checked it, it was unavailable on Unity's Store. So I need to code a replacement for SpriteText, but since only KSP 1.8.0 have this problem, the priority for such a stunt is pretty low... So your best option is, indeed, to update to KSP 1.8.1 . A lot of annoying bugs were fixed on 1.8.1, there's really no good reason for using 1.8.0. -- -- -- POST EDIT -- -- -- If you have Steam, you can download 1.8.1 by using the Properties / Beta (right click on the KSP icon):

Someone reminded me this one today. (This video can't be embedded so... "Dare to be stupid" by Weird Al Yankovic ttps://youtu.be/SMhwddNQSWQ Trying to decide if I give him a laugh or a punch.

weird. type a single "dir" instead and print the screenshot. "My Kraken... It's full of tyops...."

Nope. I forgot about a idiosyncrasy from Windows. type "F:" to change the current drive to the one you use for KSP" cd "F:\the\full\pathmame\where\your\KSP\is\installed" f: dir /n /s GameData > GameData.dir.txt

This is going to be a nightmare to reproduce... I think we need a tool that, given a GameDatabase, could "reverse-engineer" it to generate a CKAN export file that could reproduce. This would allow non CKAN users to be better served while asking for support without the need to use something some users (me included) prefer not to use... @ElonsMusk do you know how to come with the DOS Command/Command Line terminal? If yes, try this cd "C:\the\full\pathmame\where\your\KSP\is\installed" dir /n /s GameData > GameData.dir.txt And publish the GameData.dir.txt thingy on dropbox or something. With that , I can try to hack my way to forge a CKAN export for us.

But using both is slighter faster when the NEEDs clausule is not satisfied, because the :NEEDS is ripped out on early stages of the patching and it's one less patch to be handled later.