R-T-B

WUT!? Dem dere's fighting words, toady. No one can sling incomprehensible insults like me, so you'd better watch your back, Nematoad. I don't know about you, but I am totally professional. I just lost all my paychecks in the mail. Someday I'm going to get a new video card... Seriously, do take your time. Your mod may be the one holding me to 1.9.1 at the moment, but I love your attention to detail and I get that it doesn't come overnight. Quality can't be rushed, even with money, honestly. Some publishers could use a lesson there /OT.

Yeah, if we can trace where it starts in Kopernicus releases, we can decide with better certainity if it's a Kopernicus bug, or a SCANsat/Stock bug. Basically say who needs to work on what. There's no doubt it's misbehaving from what the user would expect, though. You don't need to do any more testing necessarily, I have a few testers for it, or I'll get to it tomorrow. Just enjoy the game and see what else you find.

I'm unsure where they are defined either (new maintainer syndrome). It's odd they don't give you tech though on nonstock worlds, this may be an old bug though because we didn't change anything with regards to them. If anyone could test if this occurs in the stable 1.9.1 build, I'd be appreciative. Catching up on work here but those details would help me log the bug in our issues database. The actual poles have anyways been odd (whatever you do, don't walk or drive on them, they are Kraken bait), but I've never heard of this. It's a mostly harmless bug at least, but still, probably a bug. I'll wait to enter that one until I can see how far back it stretches in versions, as well.

JNSQ is what I run on my install when I game! Granted I run 1.9.1 BE, but it is a good sign I think that it should work. I have reports 1.10 works fine too, and 1.10.1 I have at least one report it LOADS. Technically, not much should've changed there, so fingers crossed?

Yeah actually I made the "bleeding edge" edition for that reason. This release tempo is nice, but way too fast for stable branch, lol. This way users can pick. So far for bleeding edge it's been mostly bloodless though. Nice kraken...

I think that was taken over by @Vabien, who is doing pretty well over at his own github. Footsteps are working in 1.9.1 anyways! https://github.com/VabienArt/KopernicusExpansion-Continueder/releases

I just updated 1.10.1 on my bleeding edge branch. Grab it if that's your fancy. It has some swanky new multistar math, which while cool, also has some limits I'd like to discuss here before considering it for mainline. Warning technical details follow, skip ahead to the bottom if easily bored: It seems there are several assumptions done within the stock game engine that assume a single star. This makes implementing multistar properly (without crazy bad math) hard to implement. Let me try to explain. KSP only allows a single star to be active at any given time. Kopernicus tries to get around this with an elaborate "light shifter" system that "pulses" each star during a frame once, and tallies the ECs, heat flux, etc on the panel during that pulse, and then at least for ECs, the net result of ECs from every star pulse is the total. The call for the light portion (the portion solar panels care about) rather than the flux/heat portion is called "ApplyPhysics), and unfortunately, it's way way too slow. So slow in fact that the physics don't get applied in the same frame, and we get a Sun with the properties of a Red dwarf, or vice versa, or all sorts of crazy combinations and the math goes nuts, leading to thousands of or sometimes (I've seen this) even negative EC production. Fortunately, the heat part, ApplyFlux, works quickly and fine. This means that: At least as of now, I can't do multistar light support. Light accepted at the panel (and thus, contributing to EC) will be limited to the tracked body. Flux/heat/"that thing that melts you", as the game engine considers it, works fine and will apply like it always did, from all stars. But the panels will only get ECs from the tracked body. So track a smart body and don't run out of EC! Also fortunately, autotracking still works, because it can wait a few frames to decide what star to select without consequence. So the panels still do auto pick the best body, if needed. Bottom line: For sanity reasons, and maybe even what is technically possible, right now Kopernicus limits panels to only accept light to the tracked star. How big of a deal is this to most of you? It may/may not be permanent, depending on the amount of effort required to fix major bugs in KSPs logic around stars (it really can't grasp more than one in terms of ECs). The link the other guy gave you is now good, I updated. It's the "_1101_" zip file (lol that sounds like binary code).

Is it out? We're version bound but I can make a build targeting it now. Stand by... no guarantees, naturally. It might. You tell me. The next release I'm baking right now will let you run it, at least. EDIT AND IT'S OUT Let me know if 1.10.1 works as i have no idea, but given it's just bugfixes it SHOULD work: Kopernicus R-T-B Unified "Bleeding Edge" Edition Release 6 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 6. It contains the following changes: 1.) Rolled back the bad EC math in the update in Release 5 2.) Added a new, complete multistar support math system that works perfectly. It does this by limiting accepted light to the tracked star. Vessel heat/flux still consider multiple stars as usual. See the KSP forum thread for why this was done, and to comment on how well it works. 3.) Added Russian Localization, now vetted by locals. 4.) Extremely untested 1.10.1 support. Please download the right output zip for your version. "191" zips are for 1.9.1, while "110" zips are for 1.10. This was a pretty heavy change, might want to check the EC math... it'll be high if anything, so it won't wreck savegames, but I'd appreciate reports. Thanks and as always, report bugs! -RTB Some important technical commentary on this release and multistar support, BTW, please read: It seems there are several assumptions done within the stock game engine that assume a single star. This makes implementing multistar properly (without crazy bad math) hard to implement. Let me try to explain. KSP only allows a single star to be active at any given time. Kopernicus tries to get around this with an elaborate "light shifter" system that "pulses" each star during a frame once, and tallies the ECs, heat flux, etc on the panel during that pulse, and then at least for ECs, the net result of ECs from every star pulse is the total. The call for the light portion (the portion solar panels care about) rather than the flux/heat portion is called "ApplyPhysics), and unfortunately, it's way way too slow. So slow in fact that the physics don't get applied in the same frame, and we get a Sun with the properties of a Red dwarf, or vice versa, or all sorts of crazy combinations and the math goes nuts. Fortunately, the heat part, ApplyFlux, works quickly and fine. This means that: At least as of now, I can't do multistar light support. Light accepted at the panel (and thus, contributing to EC) will be limited to the tracked body. Flux/heat, as the game engine considers it, works fine and will apply like it always did, from all stars. But the panels will only get ECs from the tracked body. So track a smart body and don't run out of EC! Fortunately, autotracking still works, because it can wait a few frames to decide what star to select without consequence. So the panels still do auto pick the best body, if needed.

Yeah it feels more like a stock bug but we'll be keeping an eye on it regardless.

Thanks. I think I'm pulling that build. I'd advise reverting in the meantime, for all users who downloaded it. Something is indeed very not right with the EC math and I really don't get it. The old build works it's just buggy in extreme edge cases of multistar (angled stars close together in the view plane, really). Will look at it again in the next few days (family stuff begins).

Makes me wonder if it's GPU-specific then (I use AMD GPU, but usually, we have the bugs, not vice versa). Either way, odd, and it doesn't help that I as a dev can't reproduce of course. It's a very real bug I am sure though.

It is odd I have never witnessed it with scatterer installed. That's what leads me towards shadows. If you are attempting to fix this with scatterer (Option #2), it appears JNSQ does not allow scatterer to take control of shadows, so you may be getting a bad result there if you don't couple scatterer with the following fix to JNSQ: GameData\JNSQ\JNSQ_Configs\Scatterer\config.cfg, replace: @Scatterer_config:AFTER[scatterer] { @m_fourierGridSize = 64 @terrainShadows = False @shadowsDistance = 5000 } With this instead: @Scatterer_config:AFTER[scatterer] { @m_fourierGridSize = 64 @terrainShadows = True @shadowsDistance = 50000 } Note the extra zero on shadow distance (they set it pretty darn low to disable it) Note there is a performance impact, but it does seem to work on my hardware. The issue is certainly odd.

Yeah, the whole EC math needs a rework. The clamping logic isn't working right at all.

Ouch, I know why the retraction bug happens (it's detecting zero as a negative wrap and clamping, need to tell it zero output is normal). But yeah EC dropoff is supposed to be much more noticable. I will attempt to calibrate it to a more normal curve right now. Don't have long but that should be a simple fix. This is some of the limited math part of KSP I understand.

A lil bump with some potential work arounds from a team Kopernicus member: As posted in our thread: Unfortunately, I have no idea what this is... have not seen it in my personal save either. I feel it could actually be a stock 1.9 issue with shadow tiling (they reduced shadow precision in 1.9) and it relates to the new shadows distance clipping issues some have reported. A few things you can try to fix: 1.)Install scatterer and use it's terrain shadow system in the interim (this is probably why I haven't seen it, I use scatterer). or 2.)You could try turning off "celestial bodies cast shadows" in settings. or 3.) If it really is a stock bug, running in OpenGL mode (google how) will fix it by forcing the old shadow precision, albeit at a large performance cost.

I appreciate the detailed write up, with an easy to use means to reproduce this. Unfortunately, I have no idea what this is... have not seen it in my personal save either. I feel it could actually be a stock 1.9 issue with shadow tiling (they reduced shadow precision in 1.9) and it relates to the new shadows distance clipping issues some have reported. A few things you can try to fix: 1.)Install scatterer and use it's terrain shadow system in the interim (this is probably why I haven't seen it, I use scatterer). or 2.)You could try turning off "celestial bodies cast shadows" in settings. 3.) If it really is a stock bug, running in OpenGL mode (google how) will fix it by forcing the old shadow precision, albeit at a large performance cost. I have a feeling when squad finally fixes this, this bug will dissapear, and it won't end up being on Kopernicus's end. Still, we are aware and investigating, and your reproducible case helps.

This was supposed to be an edit, but anyways: My sympathies. Computers I can figure out, engines are evil-machines powered by dark magic in my mind.

Yep. Nyan Cat goes crazy if using an unsupported version of Kopernicus. It's really a bad idea to use Kopernicus on a version it's not intended for, it's configured in the source to match a specific version's data, hence us locking it. It was kind of a mistake that we ever stopped. We offer tons of options though so if you really need it on the latest, you can have it, as you figured out. FWIW I test JNSQ almost religiously as the first mod when I make builds. They may not support it, but I test in it a lot, so it PROBABLY works fine. It's also my mod of choice for my personal 1.9.1 game. And yeah, the muted visuals? I find them "realistic" and pleasing, but YMMV. People like different things... and there are lots of options. That's what's great about modding.

It's all good, I'm away for a friends wedding tomorrow so no rush. I just hope there are no crippling Kraken-esque bugs (there shouldn't be? lol).

If they release them at the same time just to mess with us... lol. Seriously, that's what bleeding edge is for. We'll have 1.11 working... sorta/kinda probably within one day. Just be careful, it may bite.

Good. The monkey squad did the right thing, I appreciate. Squad tends to need one good bugfix as of late, IMO. Unlike us... uh, we try, ok?

That is indeed very good performance, and very cool news. I wonder if the latest update helped: It walks the star list less times during light calculations so maybe? (in old releases it was mistakenly walking it too many times) What really needs testing right now, is situations in which solar panels are getting light from two stars. Make sure the EC values "make sense" if you could, at various orbital distances. I know, it's hard to tell what two stars should naturally do given both humans and kerbals live in a sort of uni-star system and we're used to that, but ideally, we should see results within the realm of reason. Also, auto tracking should pick a sensible star... ideally the one that makes the most ECs.

We have release 5 gentlemen/women! The new feature for this, eagerly being tested for a push to the stable branch, is a fix for the insanely high EC output in multistar enviornments. It should be more reasonable now. See the changelog for details, and report bugs if you would, please: Kopernicus R-T-B Unified "Bleeding Edge" Edition Release 5 R-T-B released this 2 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 5. It contains the following changes: 1.) Fix for a lack of clamping on ECs of solar panels. This was especially notable in multistar environments, where EC output could become absurd or even wrap to a negative (ouch). Please download the right output zip for your version. "191" zips are for 1.9.1, while "110" zips are for 1.10. This was a pretty heavy change, might want to check the EC math... it'll be high if anything, so it won't wreck savegames, but I'd appreciate reports. Thanks and as always, report bugs! -RTB

That's fair. I was just letting you know our policy (I'm not about to spam you with issues outside your control) and I too would strongly discourage people from coming here and for lack of a better term, threadcrapping you with unrelated issues. You should know that 1.10 Kopernicus is intended to function in it's end product (which it is not yet) just like 1.9.1, and furthermore, 1.9.1 is SUPPOSED to function just like 1.8.1. We are trying to keep compatibility, not break it meaning no changes should be needed. Right now though, there are issues, and they ARE NOT for this thread. Report them to the Kopernicus threads on the respective posts. That's really my main point. Keep doing what you do, we'll take care of our stuff.

Ah, that bug. You have the bugged copy of release 6 from the stable branch. Please redownload it as there were some "silent fixes", I think that's your only issue. The bugged copy was only up for about an hour but I think you snagged it. My fault more than yours, really. 1.10 looks fine, I think?