R-T-B

Kopernicus R-T-B Unified "Bleeding Edge" Edition Release 35 R-T-B released this 19 minutes 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 35. It contains the following changes: 1.) We no longer enforce shader settings in the default package, that is up to the texture pack author and/or user to decide. 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

Yes, it does. It also informs them it is doing this (thus allowing them to edit the config file if needed). But out of the box, I do understand your concern that it may be an overreach, and am honestly reconsidering it in hindsight. As such next release will most likely not force any setting by default, and allow the pack to choose to do this only if needed. We were mainly doing this to prevent buggy pack/setting combos, but... the pack should test that really. And anyways, I mean that'll get logged and I can manage the bug reports. I think the harm outweighs the benefit of enforcing it on stock. tl;dr: If you aren't using atlas, don't worry about it, I'll remove the hardlock to "high" pretty soon here.

Hello @Poodmund, Just a heads up, Kopernicus now defaults to shader level 2 (high) enforcement rather than ultra (3) to avoid the 1.9 atlas retrocompatability issues with nonsupporting atlas packs. You seem to nicely navigate around these issues in your pack, so you may want to enable atlas support. To do so, you'd simply need to ship a modulemanager config, similar to as follows: @Kopernicus_config:FOR[OPM] { EnforcedShaderLevel = 3 } Up to you if you want to do this yourself or simply advise your users who wonder where their pretty stock atlas-textures went, but just thought you should know.

Kopernicus 1.9.1-6 R-T-B released this now New in this version (1.9.1-6) 1.) We now use the "high" shader setting by default. This works better with most planet packs out there, and eliminates many system replacement pack bugs from packs being non-atlas ready. If you are using a mostly stock system, you may try the atlas shader out by setting config/Kopernicus_Config.cfg EnforcedShaderLevel = 3. 3 = Ultra, 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 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! This release should fix the "square patch" bug we have had for some time with Joolian moons. We should note with this release we are forcing the shader setting to "high" instead of Ultra. This is intended. We are officially encouraging planet devs to move towards Parallax shader project over squads "Ultra" Atlas shader. If you must use Atlas, or are using a largely stock pack that benefits from atlas, you may try the atlas shader out by setting config/Kopernicus_Config.cfg EnforcedShaderLevel = 3.

Kopernicus R-T-B Unified "Bleeding Edge" Edition Release 34 R-T-B released this 4 minutes 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 34. It contains the following changes: 1.) An additional config parameter was added to Kopernicus_Config.cfg, EnforcedShaderLevel. This allows packs to choose the shader level enforced by Kopernicus on a per pack basis. The default is 2 (high) to avoid issues with old packs that do not support Atlas (most do not at this point in time). It can also be set to 3 (Ultra) to enable Atlas, or 1 (medium), or even 0 (low) on a per pack preferential basis. Note if a pack does not support atlas behavior is undefined. Setting 3 (Ultra) is best used thus in stock scenarios, or close to stock packs, like OPM. 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 NOTE!!!: This fixes the above bug for planet packs by disabling the atlas shader in most cases, and will be pushed to stable very soon! If you still want the atlas shader (Usually applicable to those using a stock-alike pack like OPM, or just plains stock), simply set "EnforcedShaderLevel = 3" in config/Kopernicus_Config.cfg. If you are developing a custom planet pack, the Kopernicus dev team strongly recommends considering Parallax over Atlas (KSP's builtin "Ultra" shader). It is both equally performant, and much prettier!

I got mixed up with the reporter of the farm patch issue, will edit, lol. Thanks! As an interesting note, the latest atlas changes seem to have made the JNSQ KSC beachfront property. I think when using the atlas shader, this is correct behavior given the altitude/location, JNSQ devs probably did not intend this though. EDIT: This is a bug. It is being fixed now and will apply soon. EDIT: Below bug was fixed in latest release.

Kopernicus R-T-B Unified "Bleeding Edge" Edition Release 33 R-T-B released this 7 minutes 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 33. It contains the following changes: 1.) Additional fixes to the Atlas shader for bugs relating to square patches, particlularly noticiable in the Joolian moon templates (Thanks To @StollD for the help). 2.) More edge cases dealt with in SolarPanels.cfg, thank you forum user Gordon Dry. 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 This release is pretty big in terms of the changes to fix the square-texture / "farm patch "issue on moons of Jool. It also may implement Atlas better in general. Download and test please? We'd like to push this to stable as soon as possible, but need more widespread testing.

The config files should not need updating as far as I am aware. They should work as they did before. I'll take a look at the asteroid code soon and see if something is not amiss. Just so users here are aware, the bleeding edge now has an experimental bugfix for the "farm patch" issue. Please download the latest of that to help test! @Hohmannson, @OrbitalManeuvers, @siimav

Ok, I'll schedule that change in the next bleeding edge release and we'll see how it does.

Fair point. I'm far from encouraging people to do it wrong, but I still will probably use this as the new SolarPanels.cfg in next release. Just to make users lives easier. I assume this is "false" not "?alse" correct? Or am I just not aware of this syntax? On first line: @PART:HAS[@MODULE:HAS[#useKopernicusSolarPanels[?alse]]]:FINAL

Yep, at least on Tylo, can replicate. Weird. The logs are barren though, no errors and nothing amiss.

Hmm. Unfortunately for further fixes I am having a hard time finding a solution that's immediately obvious. I'll advise future planet pack authors to avoid the Tylo template, and continue to look into this. It's not forgotten, just waiting until a path forward hopefully is discovered.

Just FYI, I've been informed that teleportation will always produce a bug like the above, and a quick reload to a save where you did not teleport said flight will fix it in that instance. This is not a fixable bug, but more of a squad thing. Were any of the above reports a result of teleportation?

I'll make an attempted bugfix at this top priority. I can't believe I am only now hearing of this, thank you for the report guys!

Hmmm... Interesting. It's like the whole Jool system loads differently and may need a special handler. I will look into this today. WIthout a clear plan of action, I can't promise a fix timeframe, but watch the bleeding edge in case I have a stroke of brilliance.

Thanks. Inexperience showing. Ah! That one may actually be a separate bug from the one that was occurring on Kerbin. I think I've heard reports the Tylo template is bugged in some situations. I'll look into it. Mainly I need to look around whatever makes Tylo unique as a template, and work from there.

For CKAN, 1.10.1 Kopernicus is only available via our beta branch. You can opt into it following the instructions here, and things should start to work: I would add to those instructions, be sure you have uninstalled Kopernicus and ModularFlightIntegrator before trying this.

The Sentinel relay bug is temporary and known, I'd advise the former release (version 3) if it bothers you. It might work there, but I'm not sure. It's always been iffy. As for the asteroids dissapearing, that's much stranger. I will look at your log, but a revert should work for you in the interim. I'd advise Version 3 as version 4 was critically bugged. If anyone else is experiencing this same bug, please chime in. It could also be that the fairly dramatic asteroid spawner changes we pushed recently require a new game. In that case, feel free to use an earlier release to maintain your game. I really doubt that's the case though. EDIT: You were probably getting asteroids via the stock spawner rather than your planet pack, which we have removed support for. Your planet pack, which I assume is GPP, should provide support for custom asteroids and have this not matter though. Are you keeping the home system with GPP or no? Maybe the packs config behaves differently than you are used to? Here is the asteroid config for GPP if you are curious, it controls where asteroids can/will appear. @Kopernicus:NEEDS[GPP] { !Asteroid:HAS[~author[*]]:NEEDS[!GPP_Secondary]{} //Should be able to allow multiple celestial mods' asteroid fields to persist once they have an author field. Asteroid { name = GalileanBelts author = Galileo interval = 15 probability = 66 minUntrackedLifetime = 10 maxUntrackedLifetime = 20 spawnGroupMinLimit = 10 spawnGroupMaxLimit = 15 Locations { Flyby { Body { body:NEEDS[GPP_Secondary] = Gael body:NEEDS[!GPP_Secondary] = Kerbin minDuration = 15 maxDuration = 60 probability = 50 reached:NEEDS[GPP_Secondary] = True reached:NEEDS[!GPP_Secondary] = False } } Around { Body { body:NEEDS[GPP_Secondary] = Ciro body:NEEDS[!GPP_Secondary] = Sun probability = 50 reached:NEEDS[GPP_Secondary] = True reached:NEEDS[!GPP_Secondary] = False semiMajorAxis { minValue = 24000000000 maxValue = 36000000000 } eccentricity { minValue = 0 maxValue = 0.2 } inclination { minValue = 0 maxValue = 15 } longitudeOfAscendingNode { minValue = 0 maxValue = 360 } argumentOfPeriapsis { minValue = 0 maxValue = 360 } meanAnomalyAtEpoch { minValue = 0 maxValue = 6.283185 } } } } Size { //Even spread of all classes key = 0 0 1 1 key = 1 1 1 1 } } Asteroid { name = RoyalSpuds author = Galileo interval = 15 probability = 10 minUntrackedLifetime = 50 maxUntrackedLifetime = 150 spawnGroupMinLimit = 10 spawnGroupMaxLimit = 15 Locations { Around { Body { body = Nero probability = 100 reached = True semiMajorAxis { minValue = 7500000 maxValue = 15000000 } eccentricity { minValue = 0 maxValue = 0.05 } inclination:NEEDS[EnvironmentalVisualEnhancements] { minValue = 8 maxValue = 12 } inclination:NEEDS[!EnvironmentalVisualEnhancements] { minValue = 0 maxValue = 5 } longitudeOfAscendingNode:NEEDS[EnvironmentalVisualEnhancements] { minValue = -25 maxValue = 25 } longitudeOfAscendingNode:NEEDS[!EnvironmentalVisualEnhancements] { minValue = 0 maxValue = 360 } argumentOfPeriapsis { minValue = 0 maxValue = 360 } meanAnomalyAtEpoch { minValue = 0 maxValue = 6.283185 } } } } Size { //Even spread of all classes key = 0 0 1 1 key = 1 1 1 1 } } } Ah darn. Are you running with Ultra shaders? I really thought we had this eliminated... Guess we need to take another look. That's the Mun, right?

Can you clarify what this does? What do you mean by "catch all cases?"

My advice is similar. It's going to be too hard to pull everything out without getting pieces of Squad removed as well. Just start over.

It COULD be a driver issue. Linux driver quality varies wildly, depending on open-source vs closed-source drivers, and several other choices. It shouldn't all be in GameData/Squad, mods only go in subfolders in gamedata/. Also, Squad has squad stuff you don't want to remove, so be careful when moving them.

I really hope for this too.

I'm actually considering just handing the project off to him, but I can't merge his work because it mostly depends on scatterer for support and that's not in line with my original goals. The only real reason you'd use ours right now is if you don't want scatterer for some reason, or it has a certain feature his doesn't (can't think of many, ours technically doesn't downsample clouds, but that saves performance and doesn't look much worse at all). I'm glad blackrack/LGHassen made that build. I'd gladly hand off maintenance to them if they were going to maintain it for certain. For now it's wait and see. Yep he pretty much has all our fixes plus his magic dust. If you plan on running scatterer please use his version, is my advice. And make no mistake, Blackrack is a shader expert. Honestly, his release is better. When I took this role, it didn't exist in a binary release. Thus this is here. Obviously it's begining to show it's age but it still has a usecase, albeit limited.

Yeah I did, apologies. I was hoping nobody would spot it but I had an embarrassing typo-bugged release stretch from working too late, lol.

It's official. My main game is switching to this mod. I can't stand it anymore. PS: Linx, you may want to correct the lines about Kopernicus. While I tested 1.9.1 and it indeed works now, 1.8.1 isn't supported by your mod I think (or is it)?