R-T-B

Good. Try redownloading now (same releaase link), I think I fixed the bug in our build system but need a test. Is there a link to your planet pack i can get btw, for testing to avoid things like this.

I heard reports of this last release but assumed I had just botched the bundling process due to lack of sleep or something... Does it load ok with my bleeding edge? That'd be a good place to start comparing and see what's different (other than particles, which I know aren't causing it) if so. EDIT: Nevermind, I am 99% certain I know what's going on here. I will reupload in a moment. If you are having issues, just wait a few minutes and redownload. It's my build environment, not the source. Easy fix.

I appreciate the testing you were surely doing @StoneWolfPC, but I got results elsewhere if you got distracted by gameplay (not mad, it happens). All the fixes that were implemented to test are now in the mainline branch. I'll be playing with some new feature ideas here, soonish. Joolian gas giant shader controls, anyone?

That was my understanding then, and it seems correct. Thanks for backing me up with a "just because it looks right, doesn't mean it is right" confirmation. To prevent further burden to planet pack authors, I won't be implementing a work around for this. At least not now. For right now though, there is a new release. It's actually that old bugfix that was pulled for solar flux calculations (important to multistar systems and proper solar tracking/power output) but this time, it actually works and has been well bugtested over several days. Please feel free to download at the OP's link, or here: EDIT: Release pulled due to build environment issues. Expect it tomorrow or the next day. My uncle who wrote manuals for a living (and so speaks a ton of languages, but is rather more a jack of all trades, master of none), said it was ok, so sadly, it's already been merged. Was anything glaringly wrong or was it just minor stuff? I may make corrections in next release.

I tried to update it, but it's... hard. The shaders are proving tricky (I hate having to update shaders). Maybe soon, but we aren't sure. It's not ready yet anyways. I will certainly let everyone here know if we ever "crack the code" to updating this.

Ok, I will test it out later today, thanks.

Honestly, only post a log if you see a bug like nonvarying temps (or something else unexpected). Any form is fine just post them as soon as bug is noticed so it is at logs end. Hopefully there’ll be nothing to post.

I appreciate you going the extra mile to compile and test this. Do you have a git repo I can check out myself just to be sure results match? Again, no promises yet. But I never turn away hard data like this.

I mean, that’s just how I had it explained to me. I am learning here too and could very well be wrong. The issue I see is, if you download a texture pack using the new atlas shader going forward, and are set to high or low or something, it really won’t render right I think. I guess I could remove the forced thing and replace it with just a warning about this though, if there is user demand, and since it seemingly works. We would test at my bleeding edge branch, of course. I would appreciate that. If you would open a PR upon confirmation of this working, I may accept it in my bleeding edge branch. Whether or not it ever makes it to stable is up in the air though, pending more tests. Understand, I did not enforce this decision to be mean or anything. I just assume Sigma and Thomas probably had their reasons, but maybe we can at least let bleeding edge users skirt this a bit.

Basically right now, the test is pretty simple. Go to an atmospheric moon. Fly around... or teleport in a pod and fall to your doom like I did, no real difference. The point is, monitor craft temps with AeroGUI in the debug menu. They should vary during all this, not be flat and static. I did laythe for my test and it worked (Jeb may say it was a crash but ignore him, he’s just salty there were no parachutes), maybe try something different? Other planet packs? Moons of moons with atmospheres? Those sorts of scenarios.

Can I just drop a quick thank you both here OhioBob & Ohara for continuing to produce more properly documented bug reports than anyone else? I know sometimes my coding style can resemble a bull in a china closet, which is why I am moving more and more to my own branch. But all the same, I'm pretty sure this bug is nailed down in my latest beta on my thread, if you'd like to test. Supports 1.9.1 and 1.10. Oh and OHara, I don't think GCC will compile C# for you (I've never heard of it anyhow). You'll need mono... in *nix land C# is really an icky mess. But that's proprietary languages for you. Unity uses it though, so what can we do? I use to dev .net languages on linux, but it was a major PITA and I finally just set up a windows VM. I know that's not an option for everyone, but if it is for you, consider it. We could use someone with your coding talent. I'm not going to pretend I'm fully aware of how Kopernicus works (honestly I'm maybe 25% of the way there), so every little bit helps. Yeah, I didn't just change it for fun... heh. There were already headaches, not so much with your code but moreso with it not running due to some checks, which I removed, leading us to where we are now. See: https://github.com/prestja/Kopernicus/issues/3 I finally just removed that whole override in the latest attempt and made a local "GetLocalStar()" function. I believe that override was unintended or not needed at any rate, as it overrides the standard GetBodyReferencing and isn't used like, anywhere else. FWIW the rest of your code appears pretty darn solid for multistar, which is great.

Nevermind, found time, it's out and at least vaguely tested. It does what I say to fix atmospheric temp calc on moons with atmospheres, at least. As iffy as that sounds, I'd advise updating. Just watch this thread as usual in case additional (most likely, hopefully, minor) bugs crop up. @OhioBob, you'd probably like this. https://github.com/R-T-B/Kopernicus/releases/tag/UBE-release-4 EDIT: After a morning playthrough I can safely say this is a good bugfix and functions as intended.

There was a small bug with the above fix afterall... it does not work on moons with atmospheres (poor laythe). We still had bad, colder and more uniform temp calculations on them. No good, and the origin was pretty simple but just required me to chill out for a bit so my brain could work. Unfortunately, it's too late to run it through proper Q&A though. It will be ready sometime tomorrow. Need more brain sleep.

Yeah, it was pretty much just a dumb mistake on my part by working too fast. Will try not to let it happen again by working at home in the future and not at work, lol. Thanks for the report. I'll probably push it to stable by tomorrow.

So, I've made the decision to hold off on stable branch having this "release 5" fix until we can test it first, with more than just one person. If you wish to test this new fix, see my bleeding edge branch. It just dropped there. Release 3 (or higher, if there are bugs) is what you are after. For the record, short of really extreme scenarios in multistar packs, I don't see this fix as having a major impact on the majority of Kopernicus users, and not really any impact on gameplay (only statistical data) in most situations. You should be fine using release 4 here if you don't want to play Guinea pig.

Hold off on downloading release 2, it has a bug that was also in Prestja's branch. It's not a MAJOR bug but it does make atmospheric temps a bit lower than they should be, and takes away their variance. I am scrubbing it out and making a new release now. New release of my branch, release 3. It's just a small bugfix of the last bugfix (lol don't you love that) that actually made things worse. Please test and advise. This one should be harmless (not that any of them are "save game eating" bugs but they did have some wrong math on temps). https://github.com/R-T-B/Kopernicus/releases/tag/UBE-release-3

Yeah, I'm waiting a moment so I have time to think. Work being at your back never helps a release, so when I get home and have actual freedom, I will fix the issue properly. I'd advise waiting to download a new release until then. Also, please revert if you did download it as the math is all wrong. Apologies all. Should be home in a few hours. I am pulling that last release in the meantime, as it's only bad changes. More like "don't do things at work, it's a bad idea" but I get you.

New release of my branch, release 2. It's just a small bugfix release to keep us in bugfix parity with Prestja's work. It includes a bugfix for atmospheric temp calculations in multistar planet packs (they were referencing the wrong star). Get it in releases above, or here: https://github.com/R-T-B/Kopernicus/releases/tag/UBE-release-2 EDIT: This one has bugs, hold off.

It could still happen if they just fail to specify a normal map. It was just more common with gas giants because I guess people did not assume you'd need one. Maybe we are talking a different bug and I got my issues crossed too, lol. Anyhow, new stable release everyone. This is a small bugfix release for a heat calculation issue in multistar planet packs. It won't even affect people with only one star, but it's probably advisable to download it if you have a multistar pack so your atmospheric temps are right: https://github.com/prestja/Kopernicus/releases This release is considered a sort of "release candidate" to CKAN. I hope it can be the one that finally gets us there.

Technically all the packs that were having issues were due to declaring the gas giants as not templates of Jool, which is really a mistake. I've worked around it for now, but as I said, I do not plan on babying it anymore than I already have. Planet pack authors need to do their packs right, at a certain point.

For ease of maintanence, that decision was made by the old Kopernicus team in their source. As of now, given the workload in front of us, I have no plan to reverse it, sorry. You might try reverting to 1.8 if performance is important. Not much besides graphics is really missing, just the comets and stuff, but you still get asteroids and "Moar boasters' etc.

The plan, longterm anyways, was to make the new shader available but opt-in with some sort of explicit parameter. Personally I am still of the opinion that is still the best way forward. Ah, that would explain a lot. Still, some planet packs were identified that do no specify a normal map and do not use the Joolian Template. While this may be incorrect behavior, I believe having a fallback normal map that at least provides appropriate shadows is not a bad thing going forward. I won't baby them more than that, though. Oh, so that code tidbit came from you! Sorry, I thought Sigma wrote it. I got my attributions wrong. Long story short, it didn't work. That script you found, purging it, removing it, it all does nothing and they all still appear to have the same new Jool shader. It's odd. I would've thought the same. Also, I tried a technique in the modders notes of adding a instance of GasGiantMaterialControls and telling it to shutdown via .enabled = false. Interestingly, it's .enabled property did nothing as well. Long story short, I'm sure there IS a better way, I've just yet to find it. I'm with you that making Joolian-templated bodies non-template is more of a work around than it should be for retaining retro-compatability. I've just yet to find that magic better way forward that works. And yes, the eventual goal is to not do that. I appreciate your input (and clarifications on your stance). You are a god amongst men here, programming wise, and I'm just trying to keep pace. PS: This is as my friends would tell me "probably a personal issue." Many times when I communicate with Europeans I make this mistake, don't know why, but you guys come across as somewhat... clinical and cold I guess on the internet at times to me? As I said I'm sure it's my fault, lol. I do appreciate you clearing the air. It could be that I am just too silly for reason and anyone else strikes me as being "too serious." The bleeding edge branch has more features but is less tested. In 1.9.1 it has support for particles, which has been missing since 1.8 and may provide extra visuals in older planet packs. Otherwise, I'd say go with Prestja's build because it is more tested.

Technically I support 1.9.1 as well, with extra features like particles. But my branch is more experimental than Prestja's, he is more "slow and steady" reliable where I'm more "let's get this thing updated immediately," hence the divergent versions. A lot of my fixes end up in Prestja's stuff though after testing. I do advise planet pack authors to test on Prestja's branch for 1.9.1, and mine for 1.10 (since it's the only one).

Nope, that's just an extra file the compiler spits out that does nothing. The files being different is due to line endings changing, and is needed. I had a bad version with different line endings in there causing the Kopernicus hash check to fail (we check that files hash to ensure users don't mess with it, this time I messed with it, oops).

Sounds like a good plan.