The White Guardian

  • Content Count

  • Joined

  • Last visited

Community Reputation

1,773 Excellent

About The White Guardian

  • Rank
    Kopernicus Grandmaster

Contact Methods

  • Website URL Array
  • Twitter Array

Profile Information

  • Location Array

Recent Profile Visitors

17,009 profile views
  1. No? The latest build works fine in 1.7.3 with the exception of rings looking weird and scatterer being broken.
  2. 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.
  3. 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.
  4. 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.
  5. @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.
  6. 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.
  7. 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.
  8. It should be. I didn't test that explicitly. If not, I'll write a hotfix for that.
  9. 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.
  10. 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. Check above for the actual status of development for the mod.
  11. That's better than my build for all but the GPU (I run an RTX 2080 Ti) so yeah, that's more than enough.
  12. 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.
  13. MAN it's way overdue I give this pack some love, eh? I'll start working on it right away.
  14. Firstly, it will not affect your save game. Orbits in KSP work in a simplified manner. In the real world, there is something known as the N body problem, which dictates that it is impossible to perfectly describe an orbit mathematically, since every bit of matter attracts every bit of matter. One can however create a reasonably accurate approximation by considering only the significant gravitational attractors. KSP only considers a spacecraft's 'parent body' (IE the object this spacecraft orbits) and describes the spacecraft's orbit around that parent body. The position of that parent body is largely irrelevant. HOWEVER Moving a planet closer to the sun or a moon closer to its parent planet reduces the sphere of influence, IE the region of space in which this object is the primary attractor. For example, if you move Kerbin towards its sun, "Kerbol's" gravity will crunch down much harder on the SOI thereby shrinking it significantly. Thus if you move planets inwards significantly, spacecrafts in distant orbits around the moved celestial will now find themselves outside the SOI, and KSP should adjust the orbit accordingly (IE the spacecraft will now orbit whatever it would be orbiting if it were to leave the SOI of the parent object). Similarly, moving a planet's orbit outward may cause it to scoop up nearby spacecrafts. In order to do this without affecting your saves' stability, move the planets in such a matter that: 1. The moved objects never come too close to any vessel, taking the potential change in SOI into account. 2. The moved objects, if moved inward, have no vessels in orbit that might be kicked out. And lastly, there is a potential glitch that might occur with distant moons of planets that are moved inward. Similarly the moon's orbit might be outside the SOI. KSP however does not fix orbits for celestial bodies. So pay attention to any potential moons when doing this. Secondly, to change the main menu body back to Kerbin, navigate to: [KSP Directory]/GameData/KerbolOrigins/SarvinSystem/Sarvin and open up 'Sarvin.cfg' You will notice that, on line 36 it reads: %mainMenuBody = Sarvin This line tells Kopernicus to change the value applied to mainMenuBody (that's what the little percent means at the front, it tells ModuleManager not to create a new config value, but to patch an existing one) to be the celestial body named 'Sarvin'. Either change this to: //%mainMenuBody = Sarvin Or delete the line entirely. KO will work perfectly regardless since it doesn't rely on Sarvin being the main menu body. I hope this answers your questions. If you'd like to ask me to explain something in more detail, let me know. On a separate note, perhaps I should explain my long absence when it comes to helping develop this mod. Rest assured that I've been working on several exciting new features pending the next release: - Hand-crafted terrain scatters for the mod - [Possibly] ambient sound on atmospheric planets (wind, thunder, etc) - Better 'surface' for Sarvin - EVE and Scatterer configurations for all applicable objects - [Possibly] Monoliths and other easter eggs scattered throughout the system. - [Possibly] Active (read: erupting) volcanoes on Manai and Keelon The main holdup is a consequence of a new mod I've been developing in the shadows that allows for objects to be spawned from Asset Bundles into the planetary system. This results in nigh limitless versatility, but implementing it properly takes some time to do.