[1.8.x-1.12.x]R-T-B's Kopernicus Unified "Bleeding Edge" Branch[REACTIVATED]

[Vabien]

5 minutes ago, R-T-B said:

I don't see how it could freeze the main menu but maybe...  let me dig through that.

Release 6 was also before that, btw.

The issue is in release 8, and the user already tested release 7, but for the sake of testing, I tried 6. The bug wasn't there. No clue why release 8 is different unless somehow you deleted a gameobject in the mainmenu. God knows how that would work.

[Leprechaun]

18 minutes ago, R-T-B said:

JNSQ should not be able to freeze the main menu through Kopernicus systems even if it wanted too.

So yeah, this is a bug.  I'll look into it.

Can you both do me a favor, and see if Release 6 does the same?  It was the first release to support 1.10.1, and maybe this multistar mess is leading to this issue as well (it lacks that stuff).

https://github.com/R-T-B/Kopernicus/releases/tag/UBE-release-6

I have just re-tested Release 6 and 7 and bug is not present. Upgraded back to Release 8 and the bug is back. I'm running Kerbal 1.10.1.2939.

15 minutes ago, Shawn Kerman said:

I got time, if you can start feeding me logs I can go and start hammering out potential issues in JNSQ

My KSP.log is here: https://pastebin.pl/view/184cad4d

Is there any other file I could send to help?

Thanks

[R-T-B]

11 minutes ago, Vabien said:

The issue is in release 8, and the user already tested release 7, but for the sake of testing, I tried 6. The bug wasn't there. No clue why release 8 is different unless somehow you deleted a gameobject in the mainmenu. God knows how that would work.

Yeah...  I have no idea why it wouldn't do it in 1.9.1 as well, too.  So Release 7 works?  Then it is the PQSCity fixes.  I'll look at them again.

It's too bad because I'm pretty sure they were working...  I mean other than this.

Edited August 1, 2020 by R-T-B

[R-T-B]

17 minutes ago, Leprechaun said:

I have just re-tested Release 6 and 7 and bug is not present. Upgraded back to Release 8 and the bug is back. I'm running Kerbal 1.10.1.2939.

My KSP.log is here: https://pastebin.pl/view/184cad4d

Is there any other file I could send to help?

Thanks

I don't think we need further logs, I know exactly what caused it now, the question is how to still fix the PQSCity bug while letting 1.10.1 load the main menu.

It should be as easy as saying "If you are in the main menu, don't run this code."  I just need a few minutes for testing etc.

Edited August 1, 2020 by R-T-B

[Vabien]

Ok, so here's what I've established: It's an issue with the hover detection. Menu Text uses TextProButton3d to determine its hover state. This can be found in both versions, so it's not deleted, it's just not functioning as intended. Other than that, I haven't the faintest clue why the hell it isn't working. Somehow the code was changed in a way to prevent this from triggering. Perhaps a gameobject is over the entire menu, looking into it now.

[R-T-B]

2 minutes ago, Vabien said:

Ok, so here's what I've established: It's an issue with the hover detection. Menu Text uses TextProButton3d to determine its hover state. This can be found in both versions, so it's not deleted, it's just not functioning as intended. Other than that, I haven't the faintest clue why the hell it isn't working. Somehow the code was changed in a way to prevent this from triggering. Perhaps a gameobject is over the entire menu, looking into it now.

Regardless, the fix is the same.  Add main menu detection for the PQSCity2 fixes, and don't run them in the main menu.

I'm on it.

[etmoonshade]

I swear, so much trouble from one little bug I reported...

Good luck with the fix. Or good skill, if you prefer.

[R-T-B]

2 minutes ago, etmoonshade said:

I swear, so much trouble from one little bug I reported...

Good luck with the fix. Or good skill, if you prefer.

It wasn't supposed to lock 1.10.1 users out entirely, lol.  It's all good.  That's why we are bleeding edge, so I have an excuse.

[Vabien]

1 minute ago, etmoonshade said:

I swear, so much trouble from one little bug I reported...

Good luck with the fix. Or good skill, if you prefer.

Tis the issue with programming. Forget a semicolon, now vessels explode immediately. Don't close parentheses, woops now you have negative funds. Fix one bug, another pops up in its place. Exaggeration of course but still lol.

[etmoonshade]

1 minute ago, Vabien said:

Tis the issue with programming. Forget a semicolon, now vessels explode immediately. Don't close parentheses, woops now you have negative funds. Fix one bug, another pops up in its place. Exaggeration of course but still lol.

I've done just enough programming (more scripting lately, 90% of my coding was in C on MUDs) to know exactly what you're talking about.

"Why do you want to delete C:\, derp.ps1? Please don't do that."

[R-T-B]

9 minutes ago, Vabien said:

Tis the issue with programming. Forget a semicolon, now vessels explode immediately. Don't close parentheses, woops now you have negative funds. Fix one bug, another pops up in its place. Exaggeration of course but still lol.

Add that that Kopernicus is seriously one complex code beast, and yeah, she gets angry easily.

Anyways, there will be another release fixing that today, it may be later though.  I'm still trying to get that EC math fixed right.  KSP insists I'm doing it wrong and does it over, with 20x worse results.

Edited August 1, 2020 by R-T-B

[kubi]

19 hours ago, R-T-B said:

I have identified the problem with the solar panels and EC math.  Surprisingly, my math was good this time.  The problem is the stock game was still running it's math, and screwing up the results.  I'll have this fixed in a little bit.  There'll be a hotfix today, and I'm hoping we can also implement solar-panel atmospheric extinction with OhioBobs help soon here.

At the rate he is providing math and tests, I'm going to be putting him on the contributors list.  He's enabled a lot we could not of otherwise done.

Great news. Reading this before posting to the stable thread would have been saving some digging work

I'd get the in-orbit EC calculation straight first, then look into the in-atmo and the temperature efficiency curve.

Anyways, some comments to the current dev1101 solar panel file. First code review after 20 years, so might be a total nonsense...

Unnecessary iterations

You go through all the solar panels and within that you go through all stars to find the home luminosity. It is not needed to do it for each and every solar panel. It would have been better to do it outside of the main SP loop. It does not cause any error, just a bit of a waste of CPU power.

So, just move the first star iteration

Spoiler

for (Int32 s = 0; s < KopernicusStar.Stars.Count; s++) { ... homeStarLumaConstant = PhysicsGlobals.SolarLuminosity; ... }

 

outside of the SP iteration

Spoiler

for (Int32 n = 0; n < SPs.Length; n++) { }

 

Or make sure that it runs only once with a simple condition.

Tracking body restoration

For each SP iteration, you restore the original tracking body and run CalculateTracking then update the tracking body again but do not run CalculateTracking.

Spoiler

                        // Restore the old tracking body
                        SP.trackingBody = trackingStar.sun;
                        SP.GetTrackingBodyTransforms();

                        // Run The MDSP CalculateTracking
                        SP.CalculateTracking();
...
                        if ((bestStar != null && bestStar.sun != SP.trackingBody) && (!_manualTracking))
                        {
                            SP.trackingBody = bestStar.sun;
                            SP.GetTrackingBodyTransforms();
                        }

 

To me, having an unconditional update, then a conditional update is again a bit of a waste at least. You can simply move the unconditional update to the else branch of the conditional.

Not running CalculateTracking after the conditional update might be a bit of a fault. I'm not sure if/what would it cause.

Also, you restore the tracking body at the end of the nested star iteration cycle too. It seems a bit strange too.

 

Flux & EC calculation

The flux update seems fine to me. You just sum the flux from all stars (totalFlux) and load to vessel.solarFlux. I assume this is for the heat calculations, or whatever.

But I'm confused a lot by the flow rate update.

First of all, I'm not sure about the difference between SP's (float)flowRate and (double)_flowRate public attributes of Class ModuleDeployableSolarPanel. Is it only the chargeRate constant multiplier?

You increase totalFlow twice, why is that?

Spoiler

                            float panelEffectivness = ((SP.chargeRate / 24.4f) / 56.37091313591871f) * SP.sunAOA;
                            totalFlow += (float)starFlux * panelEffectivness;
                            totalFlow += ((float)starFlux * panelEffectivness) * (1360 / (float)homeStarLumaConstant);
                            _totalFlow += totalFlow / SP.chargeRate;

 

It is like

Spoiler

totalFlow+= effectiveFlux * (1 + lumaRatio);

 

Is this intentional?

Edited August 1, 2020 by kubi

[R-T-B]

24 minutes ago, kubi said:

  Reveal hidden contents

totalFlow+= effectiveFlux * (1 + lumaRatio);

 

Is this intentional?

Actually, no, it's not.  That may just be the weird duplication bug I've been unable to track down, thanks.

Most of the optimizations you mentioned have already been implemented I was just waiting to fix that to do a release.  Last release was kind of just a "well, it's bleeding edge and I'm tired" product... lol.

[kubi]

4 minutes ago, R-T-B said:

Actually, no, it's not.  That may just be the weird duplication bug I've been unable to track down, thanks.

Most of the optimizations you mentioned have already been implemented I was just waiting to fix that to do a release.  Last release was kind of just a "well, it's bleeding edge and I'm tired" product... lol.

You are welcome. It might be only one of the issues as in rel8 it is still 3x the rate than it should be, not only 2x...

 

 

[R-T-B]

18 minutes ago, kubi said:

You are welcome. It might be only one of the issues as in rel8 it is still 3x the rate than it should be, not only 2x...

 

 

Rel8 is even worse off than that in some instances.  Don't go too far from home orbit... lol.

It was indeed only one of many issues (this release actually has to redo how Kopernicus replaces solar panels entirely, so it will not fix existing craft in flight unfortunately), but it's the one issue I could not find...  sometimes we just can't see our own mistakes.  And now it's fixed.  Release incoming.

Edited August 1, 2020 by R-T-B

[StoneWolfPC]

17 hours ago, R-T-B said:

Add that that Kopernicus is seriously one complex code beast, and yeah, she gets angry easily.

Anyways, there will be another release fixing that today, it may be later though.  I'm still trying to get that EC math fixed right.  KSP insists I'm doing it wrong and does it over, with 20x worse results.

If it helps to know, I've been watching solar panels and just tested them again.  On my end, they're separating star light.  And it drops as you go farther from the star like it should.  So if I go to Eeloo I have no need for solar panels now because they don't do crap that far away.  However when I get close they do as they should.  I transfer to another star using the cheats and use RSB's to fix the orbit bug that is introduced ( the line moving wildly and not knowing what's going on) and they switch to that star, and EC changes accordingly.  I switch the panel to sun again, and it gets .000012 or something ec at that distance.  Enough to know it exists but not enough to charge.   That's exactly how I think it should work.  Oh.... then again......... I didn't do this on my test bench today, this was with Near future, and Interstellar extended (which has a lot of changes in solar panels from what I can tell).  Never paid attention during stock use..........

 

[kubi]

47 minutes ago, R-T-B said:

Rel8 is even worse off than that in some instances.  Don't go too far from home orbit... lol.

It was indeed only one of many issues (this release actually has to redo how Kopernicus replaces solar panels entirely, so it will not fix existing craft in flight unfortunately), but it's the one issue I could not find...  sometimes we just can't see our own mistakes.  And now it's fixed.  Release incoming.

Might be. I was only 0.5 to 2 AU in the vanilla Kerbol system (power of set orbit cheat). The table I've linked above shows quite constant 3x difference (with random errors and MechJeb was not there to help setting the craft's direction exactly)

[R-T-B]

51 minutes ago, StoneWolfPC said:

If it helps to know, I've been watching solar panels and just tested them again.  On my end, they're separating star light.  And it drops as you go farther from the star like it should.  So if I go to Eeloo I have no need for solar panels now because they don't do crap that far away.  However when I get close they do as they should.  I transfer to another star using the cheats and use RSB's to fix the orbit bug that is introduced ( the line moving wildly and not knowing what's going on) and they switch to that star, and EC changes accordingly.  I switch the panel to sun again, and it gets .000012 or something ec at that distance.  Enough to know it exists but not enough to charge.   That's exactly how I think it should work.  Oh.... then again......... I didn't do this on my test bench today, this was with Near future, and Interstellar extended (which has a lot of changes in solar panels from what I can tell).  Never paid attention during stock use..........

 

The panels report EC correctly.  It's the internal math that's wrong.

...And I'm still having issues with it, unfortunately.  Stand by.

Edited August 1, 2020 by R-T-B

[R-T-B]

So, this branch is buggy in regards to EC charging and will continue to be buggy until I have a reasonable fix for the problem.  I'd like to apologize to all the users eagerly wanting to play 1.10.1, only to find it not working, but I really need to crack this before I can justify another release.  Thank you for your continued understanding.

Edited August 1, 2020 by R-T-B

[kubi]

4 minutes ago, R-T-B said:

So, this branch is buggy in regards to EC charging and will continue to be buggy until I have a reasonable fix for the problem.  I'd like to apologize to all the users eagerly wanting to play 1.10.1, only to find it not working, but I really need to crack this before I can justify another release.  Thank you for your continued understanding.

No problem! This is the beauty of a beta (alpha?) version

If you upload the latest to GitHub, I will have a look tomorrow.

[R-T-B]

2 minutes ago, kubi said:

No problem! This is the beauty of a beta (alpha?) version

If you upload the latest to GitHub, I will have a look tomorrow.

Heh, the code needs cleaning up first.  But if I do not solve it by then, I will be happy to do so.  Check branch dev191, it's where I do work first.

[R-T-B]

A stopgap release just dropped, since fixing multistar is taking way too long.  This release will work properly with single star planet packs.  Beyond one star, the math is not going to work well at all, but one star works fine and that's what most people need.  Also, for the main-menu freeze bug in JNSQ: we are working on it but not entirely sure why it happens, as initial simple fix attempts have failed.  Please use the arrow keys in the main menu until it is fixed.

Kopernicus R-T-B Unified "Bleeding Edge" Edition Release 9

R-T-B released this 11 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 9. It contains the following changes:

1.) Rolled back all multistar math, it just wasn't ready. Please use this with single star packs only for best results.

2.) We now only warn about the Ultra Shader being the only supported shader, we don't force it.

3.) This time actually tested 1.10.1 support beyond "it loads"

4.) The multistar math will come back someday, but not today. It's been too problematic.

Known Bugs:

1.) The experimental bugfix for PQSCitys (like randoliths) sticking to templates can sometimes freeze the mainmenu in 1.10.1 (most notably in JNSQ). We are working on this. You can navigate by keyboard arrow-keys in the meantime.

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

 

 

6 hours ago, kubi said:

No problem! This is the beauty of a beta (alpha?) version

If you upload the latest to GitHub, I will have a look tomorrow.

The main issue is every call of CalculateTracking seems to add unremovable ECs to the panel that mess up all my nice, pretty math.  I have no idea what to do.  You don't really need to see my code because it was a mess by the end.  I just am stuck in this thought loop:

1.) I can't use CalculateTracking because it acumulates rogue ECs from the stock game

2.) I have to call CalculateTracking to get the proper flux figures from the star.

It's a catch-22, and unless I can "reset" the panel EC output somehow that I'm missing, I'm stuck, frankly.

Edited August 2, 2020 by R-T-B

[kubi]

Thanks for the hard work!

I'm checking the changes in the code, but started to feel that I need to put together a dev environment. Can you point me to a howto (PM is OK too).

[etmoonshade]

57 minutes ago, R-T-B said:

A stopgap release just dropped, since fixing multistar is taking way too long.  This release will work properly with single star planet packs.  Beyond one star, the math is not going to work well at all, but one star works fine and that's what most people need.  Also, for the main-menu freeze bug in JNSQ: we are working on it but not entirely sure why it happens, as initial simple fix attempts have failed.  Please use the arrow keys in the main menu until it is fixed.

Kopernicus R-T-B Unified "Bleeding Edge" Edition Release 9

R-T-B released this 11 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 9. It contains the following changes:

1.) Rolled back all multistar math, it just wasn't ready. Please use this with single star packs only for best results.

2.) We now only warn about the Ultra Shader being the only supported shader, we don't force it.

3.) This time actually tested 1.10.1 support beyond "it loads"

4.) The multistar math will come back someday, but not today. It's been too problematic.

Known Bugs:

1.) The experimental bugfix for PQSCitys (like randoliths) sticking to templates can sometimes freeze the mainmenu in 1.10.1 (most notably in JNSQ). We are working on this. You can navigate by keyboard arrow-keys in the meantime.

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

 

 

The main issue is every call of CalculateTracking seems to add unremovable ECs to the panel that mess up all my nice, pretty math.  I have no idea what to do.  You don't really need to see my code because it was a mess by the end.  I just am stuck in this thought loop:

1.) I can't use CalculateTracking because it acumulates rogue ECs from the stock game

2.) I have to call CalculateTracking to get the proper flux figures from the star.

It's a catch-22, and unless I can "reset" the panel EC output somehow that I'm missing, I'm stuck, frankly.

Can't you apply negative EC based on what CalculateTracking returns? So if CalculateTracking gives 3EC/s, and your function gives 1.5 EC/s, you have your function return -1.5EC/s?

I know it's almost insulting to think that you didn't consider that, but I know I've spent hours staring at a problem only to have someone come by and point out the obvious.

[R-T-B]

4 hours ago, etmoonshade said:

Can't you apply negative EC based on what CalculateTracking returns? So if CalculateTracking gives 3EC/s, and your function gives 1.5 EC/s, you have your function return -1.5EC/s?

I know it's almost insulting to think that you didn't consider that, but I know I've spent hours staring at a problem only to have someone come by and point out the obvious.

No, because for whatever reason, these rogue ECs aren't measurable in code in any form I can find.  CalculateTracking is a void, it doesn't return any information.  You only discover the ECs after you launch the game and it's literally added every star twice, once with stock math, once with mine.  And the stock math can be crazy off in multistar situations...

4 hours ago, kubi said:

Thanks for the hard work!

I'm checking the changes in the code, but started to feel that I need to put together a dev environment. Can you point me to a howto (PM is OK too).

Basically , it will build in Visual Studio if on windows with only changes to the csproj file (point the paths in there to your ksp install).

The only code changes up right now are actually frustrated reversions to old math models now, so perhaps best wait for me to get in touch with a dev.  I've already started to ask around.

 

Edited August 2, 2020 by R-T-B