The White Guardian

Yep! Slow progress, but progress is progress. Completely. KS3P is not tied to planet mods. The update that I am working on will feature synergy with Kopernicus, but will not depend upon it, and will be pretty forgiving to installation errors.

Guess who came rolling out of his cryo-pod? Hey again y'all, sorry for the long silence. I'm back and I'm getting ready to get back to KSP modding. I've made a structured planning to be able to manage both personal life and personal projects, which currently extends all the way to the end of October (since I don't know what the university will throw at me I can't plan beyond that) and wherein I've set aside a total of 14 hours currently for modding. KS3P is first on the planner, followed by Cerillion, Cyran and Arkas. I also have a new code-based project nicknamed 'KLEUR' in development which I hope to release in tandem with the updated Cerillion.

It's currently been shelved in favor of KS3P, since it is more versatile. They're both planet packs that I really would like to revise though, especially since I now have the programming insight to add PQSMods if the built-in ones don't suffice.

Hmm. Perhaps it's time I left my cryo chamber then.

This is correct, though there is no such thing as perfection in programming. The second edition of the post-processing stack is somehow even faster than the original and more flexible. Another large performance boost will be the GUI, which currently uses a c#-based GUI generation solution that rebuilds the GUI every frame, and is meant mainly for creating debugging interfaces and not for finished products. Moving to Unity's main solution for UI systems (IE canvas layers and 2D graphics) is more memory-persistent, requires less setup, and is much closer to the GPU in terms of processing. Since I can build the GUI in the editor using many custom scripts, this also means that I can much more easily design interfaces for communicating with, for example, color wheels. While I can now focus solely on the draggable handle and let any relevant graphics update their status in a subsequent update-loop, previously I would've had to create the entire GUI in code, which means that I'd have to guesstimate positions and generally spend an awful amount of time testing. Thus this new GUI-approach makes both development and execution faster, and also generates less garbage as the GUI will now have a persistent memory address. This last thing is particularly important: any object in C# deriving from the class-type is created on the heap, and unless you give it explicit memory management, losing all references to a heap memory item will not automatically free up that memory. As far as both the OS and Unity are concerned, that part of the RAM memory is still occupied. So when KSP tries to store another thing in memory that is, say, 1 MB in size, it might be that there is, say, over 5 MB of memory available, though distributed in portions of free memory no larger than 0.5MB. In this case the memory allocation fails, and the garbage collector kicks in. The garbage collector sweeps through all RAM memory occupied by KSP, looking for any object that is no longer referenced by KSP and thus can no longer be retrieved by the program. Such data is called "out of scope" and only serves to pollute memory at that point since the program can no longer use it. The garbage collector scrubs the memory wherever possible by removing all 'out of scope' data, and then Unity tries again to place the 1 MB object. If this once again fails, Unity will double the amount of memory that KSP has available. This can actually cause a crash on 32 bit machines which have a maximum memory quota for any given program, and the OS will terminate any program exceeding its memory size. This is also true for 64-bit machines, but the RAM-quota on 64 bits is so absurdly high that it is essentially unreachable. Anyhow, this heap memory expansion also cannot be completed instantly. Consequently poor memory management can lead to the infamous lag spike, which is something I strife to avoid at all costs. Consequently I'm thrilled to be able to use Unity's main GUI solution as it is better in literally every respect. TL;DR: New GUI solution: premium-quality well-decorated cake Old GUI solution: moldy bagel that is starting to grow a beard New GUI solution: Fomula 1 racecar Old GUI solution: Flintstone mobile New GUI solution: Jeb approves Old GUI solution: Jeb screams New GUI solution: The Outer Worlds Old GUI solution: Fallout 76 New GUI solution: Beethoven Old GUI solution: TF2 frying pan New GUI solution: RTX 2080 Ti Old GUI solution: Lil' Timmy with a crayon New GUI solution: Old GUI solution: https://youtu.be/2Oa2XK_5jBg?t=610

I have very, VERY exciting news. With KSP 1.8, KSP now uses Unity 2019, which means that it is now compatible with the second edition of the post-processing stack. This really couldn't have come at a better time since I'd been planning to move KS3P closer to the approach taken by the second edition of the post-processing stack. Allow me to elaborate. With the second edition of the post-processing stack, all I now need do is create a gameobject carrying a "post-processing volume" component. I can set this component's effective range to be unlimited with a single button press, effectively skipping any range check entirely. Next one adds a "post-processing layer" component to any affected camera, set the component's layer to match the volume's layer, and hey presto. Besides supporting a "regular" profile format (IE a scriptable object that is then assigned to the appropriate camera) it will also become possible to add scene-specific modifications upon a base profile. So instead of creating a unique profile for every scene, one can now make but a handful of more generic profiles and apply some small, scene-specific changes in a separate config node. I'm also going to work on getting a fully custom UI ready and working, using Unity's default UI rendering system rather than the popup-menu system KS3P currently uses. This should make KS3P's GUI prettier, faster, simpeler and more flexible as it will now adjust to the screen settings of the user machine instead of expecting a 1920x1080 monitor 100% of the time. This will also allow me to create more advanced UI tools such as trackballs and color pickers, and move rendering a color preview closer to the GPU rather than creating and updating an entire texture on the CPU. All in all, although it'll take me some time to complete, the next release of KS3P will be faster, more simple, more performant, with better effects and with more versatility. As an example, this change will add the support of Subpixel Morphological Anti-Aliasing as an option, besides the already available Fast-Approximate and Temporal AA-solutions. Next I'm working towards KS3P being able to load custom post-processing effects, both correctly loading and invoking a custom shader and indexing a custom GUI to modify it.

Hey all. First and foremost my most sincere thanks to @clusta and everyone else who has worked hard to keep this mod maintained in my absence. I must admit I was having the perhaps fallacious mindset that my mods didn't matter, and so I'm quite moved to see how the community has come together to take care of this mod when I couldn't. With that said, I think it's long overdue that I step once more onto the breach and resume development of this mod. Beside implementing the changes made by the community, I'm going to be working towards support for importing and applying custom post-processing effects, as well as giving the GUI a redesign to make it clearer. I'm also going to try to reduce the GUI hotkey from a necessity to an option with the inclusion of a button in KSP's main GUI that can open and close the UI. All in all I'm excited to continue development now that uni's no longer hogging all my time.

Alright, I'm about to test a newly compiled, updated KS3P. Not only did I remove the IndexOutOfRangeException, I also changed the configuration somewhat. Let me explain. Previously, in KS3P/Configuration.cfg, one would find the name of each scene supported by KS3P, with a number assigned to it. This number was the index of the profile within the loaded profiles that KS3P should assign for that particular scene. The problem here is that profile load order isn't set in stone, and honestly I feel a bit silly for actually once having programmed it this way. In this new setup, the name of the desired profile is assigned for each scene. Should KS3P not find a loaded profile corresponding to that name, it will instead target the first valid profile for that scene. If, for some bizarre reason, no profiles are valid at all for a particular scene, KS3P will initiate its emergency fallback protocol, generating an empty Post-Processing profile (if it hasn't done so already) and updating that profile to be valid for each scene that lacks a profile definition. I'm now going to test how this works in action. EDIT: almost forgot, I also cleaned up Unity Technologies' source code for post-processing bundled with KS3P. Previously it contained an HDR check for the camera using a '#if' directive to function differently on older versions of Unity for backwards compatibility. Problem is, I'd be really surprised if someone were still using KS3P in a build of KSP using Unity 5, as KSP has been using Unity 2017 (build 2017.1.3p1 I believe) if not newer, for some time now. Obviously this check isn't necessary with KS3P, so I removed it.

For whoever it might interest: here's what the problem is. TL;DR:

This is exactly what I was looking for: KS3P has an uncaught exception. Consequently KS3P's setup routine cannot finish execution and thus disables itself, hence why the GUI is unresponsive. I'll look into this immediately.

Hey everyone. First and foremost, I apologize for my absence from this thread. I had some personal matters that needed sorting out first, so even after returning from my holiday, I couldn't immediately get started on KS3P. It's concerning to hear that so many people find KS3P completely unresponsive. To everyone experiencing such a problem: I'm going to need logfiles to figure out what exactly is going wrong here. Check KS3P's mod folder, it should generate its own log file. Please upload that logfile in a comment (preferably in a spoiler-wrapper to keep the thread concise). If such a file is absent for some reason, I'm going to need the file 'KSP.txt', in your KSP installation directory (same folder as the executable).

No? The latest build works fine in 1.7.3 with the exception of rings looking weird and scatterer being broken.

Currently swamped with work from my side-job, but I have a new technique for painting terrain maps that I could apply if you'd like. I also have some more custom anomalies on the planner, for example enormous crystal shards or crashed meteorites, or geysers for Fonso. Custom volcanoes for Keelon and Manai are already being modeled and animated (particle systems are almost done, the problem is getting the plume to look right) so that shouldn't take much longer either.

Actually, the default config is supposed to show post-processing effects in the main menu to confirm that it is working. A full 'default profile' is still in development. That said, I've started looking into integration for the post-processing stack V2. Now, this particular edition has a nice little feature that allows for post-processing overrides when coming within range of an override component. I have plans to turn this feature into a custom PQSMod that allows for unique post-processing overrides per planet. Though I'm not sure if KSP is up to the necessary Unity version yet; I may have to wait until it gets upgraded to Unity 2019. That said, I'm already looking into a custom PQSMod that tweaks the 'temperature' value on the color grading post-processing effect, which basically skews the screen's colors to either warmer (orange) or colder (icy cyan) hues, to further convey the ambient temperature. All that this would need is: 1. A way of finding the active vessel (doable through FlightGlobals) 2. A way of finding the ambient temperature (will have to investigate this) 3. Remapping from the temperature bounds to the color bounds 4. Writing the remapped value to the color grading All of this shouldn't be too hard to do, the main issue is getting it working properly. Next, I have several custom effects on the planner, and perhaps a system for loading custom effects from other AssetBundles. Though this is all future music at the moment.

Almost forgot: you can technically brute-force KS3P to use a custom config. In Configuration.cfg one may notice the appearance of several new values, each corresponding to a particular game scene. Here's how they work: when loading a game scene, the appropriate camera operator class asks KS3P to supply the requested profile. KS3P does this automatically: it filters the list of loaded profiles to a list of 'valid' loaded profiles (IE the profiles marked as compatible for this scene). The ID in the config tells KS3P which profile to take from this list. 0 means first entry, 1 means second entry, etc. Don't worry about selecting a non-existant entry, KS3P automatically checks if the requested ID isn't out of bounds and takes the last found profile if so. Since the default profiles are likely to be loaded first, one could try manually setting the value to 1 for each of these entries. Clunky, I know, but this is a prototype system that I didn't have time to implement fully. In a future patch, KS3P will instead save the name of the profile requested for each scene, and when supplying the profile to a camera operator, it selects the profile with the requested name IF PRESENT. If it isn't present, it falls back to providing the first element from the list.

@Zorg @Artemonim I fixed that problem in the hotfix I've just released. Once you're in-game, open the GUI and manually select your custom profile. I've yet to write the code that allows KS3P to memorize these profile preferences. My sincerest apologies for the inconvenience.

What the actual heck? I'll look into that, but I have no idea what could be causing it. EDIT: had KSP with KS3P running anyways so I did a quick test. Placed a stock 'Dove' craft in the SPH and placed the front wheel on a marker on the ground, then messed with the gui. Regardless of how much I moved the camera, I cannot replicate your issue. What mods are you using? That said, I must admit I've found a few mistakes of mine left in the source code that I've since cleaned up. Tomorrow morning I'll release a hotfix to patch a few small bugs.

Yes, with lots of thanks to @jrodriguez As a matter of fact, I tested the in-game GUI with DX11, and only compiled the non-dx11 shaders this morning; so KS3P V6.0 worked with DX11 before I even added support for the normal DirectX version of KSP.

It should be. I didn't test that explicitly. If not, I'll write a hotfix for that.

Aaand it's live.

Alright. It's been a lot of work, but I think I'm ready to release the next update. Stand by as I package and upload.

I've made tons of progress on the next KS3P release. I've taken care of one of the greatest problems the program faced, and am happy to announce that, besides the in-game editor working perfectly (even in 1.7.2), KS3P can now export the currently editing profile as a .txt file. So, no applying all changes to config files by hand. Note that KS3P, when processing a Profile node, assigns the default value when a custom value isn't specified. It does the same thing when exporting a config: if a specific value still has its default value, KS3P skips writing that value when exporting, as it's pointless info at that point. I'm looking at a release in a matter of days, if not hours. In order to keep development organized however, I've created a Trello page for the mod, and have decided to make it public. This way, anyone can check up on the mod's status and progress, and what I have yet to add. https://trello.com/b/e7qEI9Py/ks3p-development Check above for the actual status of development for the mod.

That's better than my build for all but the GPU (I run an RTX 2080 Ti) so yeah, that's more than enough.

I could give that scaledspace an update if you'd like. My computer is really beefy, so even 8K maps don't take more than a minute.

MAN it's way overdue I give this pack some love, eh? I'll start working on it right away.