R-T-B

Actually, there is. You can report bugs like that on our stable Kopernicus bug tracker if it's happening in the 1.9.1 build, because it really shouldn't be there (the only change we have really made is to gas giants, which slate is not, so it should be rendering them the same). We'd love a detailed report on something like that so we can fix it properly, rather than forcing terrain/planet artists to work around issues they shouldn't have to. It looks like Poodmund may already have done that, which is nice, but that's really not the best way to fix the bug globally so we could still use a report if anyone is able. I actually encourage this (it's how we find Kopernicus bugs), but there's a caveat: Report bugs to me if using an unsupported version, not poor Poodmund. It's my fault almost certainly, not his, and there is really little he can do (or, as we just saw, it can just make it harder for us to replicate by patching it for just his mod with workarounds). You can do so here for my 1.10 builds: https://github.com/R-T-B/Kopernicus/issues And yes, I know this Kopernicus update is messy and has so... many... releases... vs the previous. Keep in mind we are all learning a very complex machine here, and patience will yield a good product at the end of the day.

Yeah, the logs I got there aren't the ones I'd really need. See above.

Not that I know of. But there are a lot of bugs, so almost certainly has to be one. Don't say things like that... It's not like we are dealing with a real monkey squad. *laughs nervously*

Thanks. I will assume other mods or maybe even hardware issues are at play until told otherwise in a reproducible fashion. This is not to say this pack runs perfectly, I've no idea, but at least that bug doesn't seem valid.

The reporter is known to run on a potato PC so that would be appreciated (no offense to him). EDIT: Wait, I have him confused with someone else, still, do test to rule out potential potato PC interference.

Yeah, we version check now. It was always supposed to be on. True ready and proper 1.10 is available though, in my bleeding edge branch. It's not as scary as it sounds, it's basically the same features as here with just an occasional experimental patch for a bug here and there: We are waiting to officially support 1.10 until patch 1 or whatever comes out.

We have some who have been filing reports against it though. We have an issue right now, as a matter of fact, we are trying to interpret and deal with. The issue report is here, and includes an image of the body and summary of the issue: https://github.com/prestja/Kopernicus/issues/26 Could anyone here just tell me the following so i can try to get a handle on this? What body is this? (that's the big one) Is flickering/glitching on this body a "known issue?" (I noted some bodies do have known "physics issues in local space" in OP, which could mean bug is on your end.). BTW, the goal by CKAN release is for Kopernicus 1.9.1 to be "Drop in ready" to use with 1.8 planet packs, so there is no reason it should behave any different here than the old 1.8.1 Kopernicus, behaviorally. We'll let you know when we get there.

What grade of issue? If the game loads it may be some change they have to make, but if it's a full "crash and burn" I should probably fix it...

Thanks, I will revert that bit of the change.

I appreciate you taking this on! I was trying to do it but couldn't work it out, mainly due to lack of time from mainline Kopernicus.

Pretty much. This is why it's important to "clean your room" as a coder. Basically, not updating a comment led to all of this. I must admit it really could've been avoided, and it was my fault. The bottom line is though, the one that's up now, works, and this won't happen again, because I have a good list of testers now to run it by first... (thanks guinea pigs!) Serious thanks to @OhioBob too, guy almost sacrificed lunch-break to get this fixed. The horror!

That's... really weird. Especially considering this release is using the same code as my bleeding edge in the section the error occurs, and you told me it loads fine on bleeding edge. I will fix this, but I need more time. I'd advise you to stay a release back for now, as you are dealing with some new bug seperate from my build bugs (not that cleaning my environment was bad, needed to happen anyways). I will make a bug for you and get to work on it. If you could PM me SIrona's config, that would probably help. EDIT: Wow that's a pretty plain gas giant as far as config... um, I'm going to pull this build. Sorry guys, but my build environment or something, is all out of whack and we need to determine what before making another release. EDIT AGAIN: WE FIXED IT! Please redownload if you downloaded this morning before 10:30ish PST. No more redownloading though, I promise. This one works. Appologies, I'll keep my build environment less messy in the future. Special Shoutout to @OhioBob for debugging through starvation at lunchtime... https://github.com/prestja/Kopernicus/releases

I actually found a few residual files (from 1.10 builds no less) in my local tree that were causing havoc. If your file for release 6 you downloaded was downloaded earlier than this post (approx 9:20am PST), please redownload the release 6. It had a few things broken, as noted above. EDIT: Release pulled due to build environment issues. Expect it tomorrow or the next day. Now the work for me is to find out how that happened, friggin ghosts in the machine I swear...

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.