R-T-B

You say that like it hasn't already. We are already shipping patches for Near Future Solar. Do you have a better way to override a stock method completely? Because i was asking around before I resorted to this. I absolutely cannot allow CalculateTracking on a panel to run while Kopernicus is performing multistar maths. EDIT: Oh, you were talking about the ModuleManager patch then? My apologies. Need more caffeine.

Thanks. I thought it had the same bugfixes but maybe the shader package rebuild did fix some things. I'll restore the latest build. So in other words, all that panic over nothing. Download freely, people. I do hope you work our the source of your white atmospheric bug though. That is weird as heck.

I don't know, but thank you for confirming the bug is not with me so I can restore my build. I was worried and I do appreciate you at least testing for me. Try without RVE64k maybe? Only thing I can think to do in your position to rule it out.

Kopernicus SolarPanels now completely replace ModuleDeployableSolarPanels in order to completely override a function including its base, so unless I misunderstand how your mod works, that might work. Yes, we completely override stock solar math now and just whole replace the module. And yes, had to be done for multistar. You are probably looking in the wrong area of the code, like master which we never use. Look in branch 1.9. It is extending ModuleDeployableSolarPanel and does pretty much everything short of moving the panels itself. That blob of math is OhioBob's and I's pride and joy. https://github.com/prestja/Kopernicus/blob/1.9/src/Kopernicus/Components/KopernicusSolarPanels.cs No, I didn't remember your name or I would've used it.. appologies on my part.

I agree... to a point. I think they should simply add the ability to very easily make another system, like Kopernicus but improved. Oh wait that's a popular opinion....

Those nullrefs are normal, actually (though maybe blackrack should try/catch them). It's just saying that it can't load those bodies in the main menu, because uh... they aren't there in the main menu! Pretty harmless.

You can also just disable Kopernicus's solar panel subsystem, though it was broken (as in it did not turn off) until a release that dropped just tonight (Release 19), so make sure you are on at least that. Also the Hotfix 3 at stable has it. https://github.com/R-T-B/Kopernicus/releases If you are on that or newer, then just put this in a cfg somewhare, and as long as you are not in multistar, your solarpanel should work (it just reverts to stock solar code). If on multistar planet pack, well, you need Kopernicus then to support multistar and I don't know what can be done, contact the author of TweakScale I guess. @PART:HAS[@MODULE[ModuleDeployableSolarPanel]] { %useKopernicusSolarPanels = false } Oh, and @hemeac's above solution may work as a fix as well, no idea.

That being said, if you want to help move things along, please test our latest release candidate, that just dropped, Hotfix 3! https://github.com/prestja/Kopernicus/releases It fixes a pretty insidious bug where Kopernicus solar panels wouldn't turn off when told to do so. Insidious not because it's a huge bug, but because of how much work was required to fix it. We'll need to test this one for a few days before declaring it ready for CKAN due to how much code was changed with the fix. Please do your part if you can, it should work but testing is always appreciated to confirm that fact.

lol, honestly, we're probably always going to have CKAN-stable be one release behind. 1.10.1 will remain in the bleeding edge likely for some time yet. Here's why: We can update Koperncius to a new release really quickly, as illustrated by how fast bleeding edge supported 1.10.1. And it works mostly, yes, but what about the new stuff? But how long did it take it to say, get comets? And it still doesn't have control over them. Lots to do. By the time 1.10.1 is stable (as in, all features controllable and work), 1.11 will likely be out. I mean I hate to admit this because I really wanted to do better, but it's kind of the nature of the Kopernicus beast. That being said, there's nothing stopping you from picking a release on bleeding edge and playing a campaign on it. It really isn't as bad as it sounds, I just make the name scary just in case something horrible happens so I have an excuse. To date nothing has really. (Famous last words?)

It's fine, if you get "revert to previous" out of that post, you understood enough. I am sorry it did not fix your issues. My main reason for the revert was to fix the "white atmosphere" bug some people had.

Heads up @Entropian and others, while not certain we are the cause of the white atmospheric issue on scatterer with certain hardware, we pulled our latest release as a precaution. I would advise all users to revert to the 1.9 release still up on github if they are having issues of any kind. We think there might be something up with the shaders bundle (think, haven't confirmed yet, but are just being careful). It won't hurt your savegame or anything, just may introduce visual bugs. The 1.9 release is identical in bugfixes, runs on 1.10, and is missing only one feature that hasn't been in EVE in ages so no on has had the change to reuse it yet in a texture pack. Tl;dr, you aren't missing anything by reverting.

Just FYI, the latest release of stable (and Bleeding edge too) ship with a file GameData\Kopernicus\Config\Kopernicus_Config.cfg The file is as follows: // Kopernicus base configuration. Provides ability to flag thigns and set user options. Ships at defaults for stock system and warnings config; Kopernicus_config { EnforceShaders = true WarnShaders = true UseStockAsteroidGenerator = true } If you really don't want to use ultra shaders, I think you can figure it out. Also if your pack has custom asteroids, be sure and set UseStockAsteroidGenerator to false. Otherwise they won't spawn and you'll only get stock ones. That line is a (hopefully temporary) hack to make SENTINEL contracts work. Yes, turning it off does break sentinel contracts right now, but at least you get your custom asteroids back. It's about choices, people. Other than those little notes, no big bad bugs at all!

I have no problem with trying to help... sorry it's not working well. That being said. I'm not above considering I may be, for lack of a better term, the root of all evil here. Could you guys try with the old Environmental Visual Enhancements build, before I used BIOZ's shader recompile? That was about when I posted my thread and also about when these reports started coming in. It is a little too coincidental. It's available here: https://github.com/R-T-B/EnvironmentalVisualEnhancements/releases/tag/1.9.0.3-RTB It's got the same bugfixes but does not support certain features BIOZ added back. Few texture packs use that Terrain feature though, so you aren't missing anything. Just sad for future devs. I'd like to know if the code I integrated is bugged, because we could pull it and save a lot of people some grief. Or not, and then we could rule out that possibility. Either one is nice. If it's bugged, it's certainly only bugged on select hardware, which is really weird. EDIT: Now that I notice, the shaders bundle BIOZ provided is a bit smaller despite having more features. That's odd... I'm going to pull my latest release while I investigate a bit. There's nothing worth using in it over the previous one right now, anyways.

A bit of a "oh nos!" news moment with regards to CKAN. A major bug has crept up with regards to compatibility with some mods. Fear not, for we already have a fix! But the fix altered some fairly fundemental code, so I have no choice but to delay release a few more days while we wait and test the new hotfix, which will probably ship tomorrow. At this rate, if all goes well, rather than a Monday release we are looking at a Wednesday-Friday one, realistically. It's for the greater good, honest. Thanks for all who test, still, you make the quality product that this'll be come to life.

I mean those lines are only telling it to obey the useKopernicusSolarPanels directive. Why would one want to override that? I don't see it, really.

no, this is a generalized CFG for Kopernicus, needs JNSQ would make it only work with JNSQ... FINAL makes sure those cfgs apply. It's ok man, wake up.

Just FYI, I got some helpful help with the above syntax, and it is now generalized in case Nertea needs to add more modes to b9partswitch or something. Final result that will ship with Kopernicus: @PART:HAS[#useKopernicusSolarPanels[*]]:FINAL { // This cfg will enable KopernicusSolarPanels // to allow support for multiple lightsources // // If you want to avoid this, add "useKopernicusSolarPanels = false" to the PART node // That will stop Kopernicus from changing the behaviour of SolarPanels @useKopernicusSolarPanels,* ^= :F:f: @useKopernicusSolarPanels,* ^= :A:a: @useKopernicusSolarPanels,* ^= :L:l: @useKopernicusSolarPanels,* ^= :S:s: @useKopernicusSolarPanels,* ^= :E:e: } @PART:HAS[@MODULE[ModuleDeployableSolarPanel],~useKopernicusSolarPanels[false]]:FINAL { // Hijack the first ModuleDeployableSolarPanel @MODULE[ModuleDeployableSolarPanel] { @name = KopernicusSolarPanels } } //B9PartSwitch support @PART:HAS[@MODULE[ModuleB9PartSwitch],~useKopernicusSolarPanels[false]]:FINAL { @MODULE[ModuleB9PartSwitch] { @SUBTYPE,* { @MODULE:HAS[@IDENTIFIER[ModuleDeployableSolarPanel]] { @IDENTIFIER[ModuleDeployableSolarPanel] { @name = KopernicusSolarPanels } } } } } Thus, to turn off panels, one need only have a cfg like follows: @PART:HAS[@MODULE[ModuleDeployableSolarPanel]] { %useKopernicusSolarPanels = false } That is all. Thanks for helping me learn the in's and out's of KSP's MM syntax.

Do you also have a GameData > GameData > Scatterer > Scatterer.dll? This seems to be what's going on, two copies running around somehow. If not (or actually, even if so), I advise deleting the scatterer folder, downloading the new zip Blackrack made without the old compression, and trying again. Plus the rogue GameData folder if you have one.

No, it should still reveal asteroids. It just won't generate contracts that can't be fullfilled because the asteroids weren't "made" by the stock generator (that's apparently a requirement). Is that desired behavior? I don't mess much with Sentinel.

Sounds like it may be a scatterer thing unfortunately, which was what I thought but figured it did not hurt to try. I'll talk to blackrack and see if we can't figure it out between us.

Correct, and I would advise future releases of that planet pack (or any really that bakes their own asteroids) to set that automatically (easy to do with modulemanager). Unfortunately this does mean you'll lose SENTINEL contracts (they don't work with custom asteroids), but we at least did the liberty of scrubbing them from the list for you to so they don't take up contract space when that setting gets set to false. If we ever figure out how to make SENTINEL contracts work with custom asteroids, we'll probably remove that setting. But for now it is what it is.

That's fair. As long as it's as simple as a modulemanager patch on a per-broken-and-relevant mod basis, we can do that. We'll get on it. The above looks to be a good starting point. I'm woefully understudied in modulemanager syntax, so I'll have to spend a day reading about it, but after that no issue at all. EDIT: Wow, that is simple syntax actually. Would something like this work? EDIT: The above works for me, anyone see any issues with it?

Hello @Nertea, Sorry to bother you as I know you are extremely busy. But I thought you should know, Kopernicus is nearing release of it's 1.9.1 variant at CKAN, and your mods currently are unaware of this change to it's solar panel logic. Basically, we hijack the actually solar panel module now to override some solar math. Sadly due to multistar support being tricky and requiring a full method override in one case, this change was required despite knowing it would be less "clean." You can view the relevant cfg here: https://github.com/R-T-B/Kopernicus/blob/dev191/build/GameData/Kopernicus/Config/SolarPanels.cfg an issue report relevant to your mod (closed because we cannot fix) here: https://github.com/R-T-B/Kopernicus/issues/21 If there is anything you'd like done on our side, you can tell me and I'll consider it. But I have a feeling this is a change that should be simple to understand. If you know of any other solar mods broken by this change, feel free to link to this post.

Just a heads up we have another bug to fix. Basically asteroid spawns are doubled in present release. This will be fixed on both stable and bleeding edge soon. Though there have been two reported bugs, there are extremely minor and we feel we are on target for CKAN by monday, barring any major bug reports. So far everything has been minor, which don't get me wrong, we still fix, but nothing show-stopping. Thanks again to all testers for getting even the smallest of bugs smashed. EDIT: Hotfix 2 is out, on both branches: https://github.com/prestja/Kopernicus/releases/

Could you post your main GPU as well? Just looking for clues, as I am unable to replicate (AMD Radeon RX 5700XT).