Jump to content

R-T-B

Members
  • Posts

    2,017
  • Joined

  • Last visited

Everything posted by R-T-B

  1. It looks like the solarpanel.cfg had a change that caused this. I will fix this when I get home. In the meantime, installing a solarpanel.cfg from an older version should work.
  2. It's possible the optimization I just did hurts standard situations, as I only tested against synthetic examples with insane numbers of scatters. Can you revert one version and confirm that? If so, I will try a different approach to measuring and improving scatter performance. I have several other ideas.
  3. Interesting! It looks like it's detecting MacOS as linux, and thus loading the wrong shader bundle. I wonder why?
  4. Oh yeah, that bug! Surprised I did not catch he's talking about that. It's been around a while, unfortunately. I think since like 1.7 or earlier.
  5. You shouldn't be using this build anymore unless on 1.8 or earlier. If you are using later, check out the new one that pairs with scatterer by blackrack (currently stickied). If you must avoid scatterer, try my fork here: https://github.com/R-T-B/EnvironmentalVisualEnhancements/releases
  6. Kopernicus R-T-B Unified "Bleeding Edge" Edition Release 37 R-T-B released this 1 minute ago This is R-T-B's "Bleeding Edge" branch of Kopernicus, intended to support the latest features, KSP editions, and also the latest bugs. Please keep in mind this branch may be more buggy than Prestja's mainline Kopernicus branch, but it also supports more KSP versions and has more features implemented for testing reasons. Many features that make it into mainline Kopernicus are born, tested, and trialed by fire here. This is release 37. It contains the following changes: 1.) This adds an experimental performance optimization to land scatters. In some extreme scatter-laden scenarios, double digit FPS improvements have been realized. Please compare performance to the old builds with scatters enabled and report back! Also, do note any strange behavior with land scatters in particular as that may be caused by this update! If it's bad we can revert! Known Bugs: 1.) None known as of now, however that does not mean there is none! Report if you find any! Please download the right output zip for your version. "191" zips are for 1.9.1, "1101" for 1.10.1, etc. Thanks and as always, report bugs! -RTB
  7. That was the behavior when we used the stock generator, which was a stopgap measure to implement comets. We don't use it anymore though, nodes must be defined like in Kopernicus 1.8.1. The pro to this is you can decide where asteroids will spawn. The stock generator was always more of a stopgap solution, because it wasn't customizable. Yes, this was a recent change, though technically it is going back to 1.8 behavior. Sorry for the lack of communication on it. I believe this PDF may help you with the configs you need: https://www.dropbox.com/s/lag8opde3zimjqc/KopernicusAsteroids.pdf?dl=0
  8. It does not look like he included any asteroid configs in his pack, so no, they would not. In the past with Kopernicus, they would've spawned around the homeworld anyways via the stock generator. But this is no longer the case. The pack now has to define asteroids + their spawn locations, or none spawn.
  9. Frankly, Ohiobob's patch is better done. Mine was a quick proof of concept. Use his.
  10. and I'm agreeing, I suppose. By the way, new release. This release adds the same functionality as "MyRocksAreBiggerThanYours" making that plugin obsolete (@Thomas P.'s contribution) Full release notes follows: Kopernicus R-T-B Unified "Bleeding Edge" Edition Release 36 R-T-B released this 3 hours ago This is R-T-B's "Bleeding Edge" branch of Kopernicus, intended to support the latest features, KSP editions, and also the latest bugs. Please keep in mind this branch may be more buggy than Prestja's mainline Kopernicus branch, but it also supports more KSP versions and has more features implemented for testing reasons. Many features that make it into mainline Kopernicus are born, tested, and trialed by fire here. This is release 36. It contains the following changes: 1.) We now support "Breaking Ground" anomalies out of the box, eliminating the need for "MyRocksAreBiggerThanYours." 2.) Material names have been simplified. You can still use the old ones, but there are simpler alternatives now. You can see Pull Request #28 for details, or simply wait for the wiki to update. Remember, the old names still work and we have no plans to change that, this is just for usability. Known Bugs: 1.) The "enableComets" parameter is deprecated now and does not function. Set "cometPercentage" to 0 to get the same effect. 2.) Fogramp maybe doesn't work right, it's been very buggy in reports lately. Please download the right output zip for your version. "191" zips are for 1.9.1, "1101" for 1.10.1, etc. Thanks and as always, report bugs! -RTB
  11. Pretty much. Just make sure you are using one of the more basic material types and not AtmosphericTriplanarZoomRotation (the 1.8+ shader). Alternatively, if you must use that shader, use a inner system body.
  12. I don't see the log file, but if you are using Kopernicus, we had a kinda similar issue that may be fixed by simply updating. Maybe try? Essentially, my first try at spawning comets wasn't spawning all the values they needed.
  13. Correct. I mean, I'm personally of the opinion configs are ok to borrow and modify ethically speaking as they are really just value pairs (unless explicitly forbidden, ofc). The textures and such is more where I'd be bothered. That being said, copying without understanding is the real issue, and it's going to happen, unfortunately. Best approach to it is education.
  14. Beats me. JNSQ apply it manually in their config and several others just followed suit, I guess? If it hadn't been applied manually by several packs, it would've worked. It's the pack authors fault. Which is why I struggled to fix it so much.
  15. Lol your spoiler had me apprehensive. I thought for sure it couldn't be good. Yep, it's just a simple material change. Moons of Jool + Eeloo cannot use AtmosphericTriplanarZoomRotation (the 1.8 shader) as their material. Many packs have made this mistake, I have sent out notifications to those I can. This probably will cease to be an issue when they get the 1.8+ shader in say, 1.11, but for now this is the fix.
  16. As I initially posted here, JNSQ (as well as many many other texture packs) are currently doing some things wrong with regards to the Joolian moon templates. This results in some square tile like patches appearing in later Kopernicus versions on moons templated from Joolian Moons. See screenshot below: I've made temporary patches for this. Please see the original post I linked above for technical details as to what they do, but the bottom line is they fix the square patch bug, for good: http://glacialsoftware.net/JNSQ_FIX/ JNSQ team I would advise you to integrate these very minor changes.
  17. Update to the above: The templates are not broken, pack authors are just using them wrong! I have found a fix and it involves a simple config change. I will be advising relevant pack authors soon. In the meantime, here's a "quick fix" for JNSQ for 1.9.1 and 1.10.1, respectively: http://glacialsoftware.net/JNSQ_FIX/ Credit to team Galileo for their hard work, these are simple config fixes. Grab the 1.9.1 or 1.10.1 version depending on your KSP, and Extract to your GameData and replace any files. Simple. Technical details, which I will be spreading around: This is not a Kopernicus bug so much as an improper use of configs. Most configs (JNSQ included) are using AtmosphericTriplanarZoomRotation as their PQS material. This DOES NOT WORK on the following bodies as they don't implement that shader: Laythe (1.9.1 only), Tylo, Bop, Pol, Eeloo. You must use AtmosphericBasic/AtmosphericOptimized or Vacuum on these bodies or you will get the tile bug! It's that simple! @OrbitalManeuvers
  18. So, at present it appears any bodies not using at least the 1.8 shader exhibit problems with the tiling / farm patch bug. I discourage use of the following templates until this is formerly fixed: Val, Tylo, Bop, Pol, and Eeloo. I'm working on this but obviously it's not easy, or I'd already be done.
  19. Weird. I may be barking up the wrong tree entirely with assuming it has anything to do with atlas. I will look into this again very soon.
  20. Hmm. Try the teleport/reload scenario with shaders set on high, maybe? Only if not tried already obviously...
  21. You are correct. I guess it just wasn't jumping to mind (but I mean, patterns are hard to memorize vs grids) So it does happen on reload?
  22. Curiosity has me wonder if it works with the latest builds.
  23. You can choose whatever setting you want by default using the in game slider. In packs like OPM that are largely stock based, that should be fine. We are basically easing enforcement of shader-settings to a "my pack needs this setting because it's only tested with it" basis. Pack authors can opt for a forced or warned setting if they need it, but we don't use it anymore in stock. Yes. It always breaks if you cheat to orbit, but a reload should fix it. Also, the atlas shader being on (shader quality "Ultra") is most likely going to break Joolian moon-bodies (still working on this, MIGHT have fixed it but I wouldn't be surprised if it's still a thing). This can be worked around by setting the shader setting to "high" until I figure something better out. You still get the 1.8 shader. That particular circled pattern is a new one to me. Does it happen on a reload? That's the only way a cheat-to-orbit is a valid test, unfortunately. Squad limitations.
  24. No, unfortunately as of now we still have the same behavior and pitfalls. I couldn't work out a fix. I hope to someday but comet support is a larger priority. And I mean real support, not just a percentage of asteroids like we have now.
  25. Kopernicus 1.9.1-7 R-T-B released this 11 minutes ago New in this version (1.9.1-7) 1.) We no longer enforce the default shader setting, you may choose whatever you wish by default. Planet pack authors may set restrictions, but we have none out the gate. This is really the only change with this release, and we thought it best for user freedom to push it out quickly after making the decision to do this. 2.) Planet pack authors (or you) may now specify the packs target shader level by by setting config/Kopernicus_Config.cfg EnforcedShaderLeve. 3 = Ultra/Atlas, 2 = High, 1 = Medium, and 0 = Low. Planet pack authors may use this via modulemanager module if needed as well. Note that we encourage of the KSP Parallax shader project over use of Squad's ATLAS shader. It is both equally performant and more flexible. New in major release (1.9.1) 1.) The longstanding ringshader bugs have been fixed. 2.) Performance Optimization and bugfixes enabling KittopiaTech support. 3.) JNSQ & other large world "Farm patch" bug fixed. 4.) Particle support restored. 5.) All 1.9.1 bugs that are known fixed. Full support for 1.9.1 5.) Multistar support. The math on ECs in single star may be slightly different than stock in some situations, but it should be similar in most and not enough to matter. 4.) Added GameData\Kopernicus\Config\Kopernicus_Config.cfg file, with options to configure shader warnings and enable or disable shader locking, as well as set preferred shader level. Easy to edit, just look inside!
×
×
  • Create New...