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

[computercat04]

1 hour ago, Poodmund said:

Asteroid rates went way up! 

 

Stonks

[Murdabenne]

Giving it a go tonight in Sandbox mode, then a career mode for a few hours where I amd going to cheat like mad (giving myself a tonne of science and money repeatedly, along with lots and lots of time warp)

[SendYouIntoSpace]

why i cant find it in CKAN?

[R-T-B]

3 hours ago, SendYouIntoSpace said:

why i cant find it in CKAN?

The stable branch is the only one in CKAN unless you opt into this beta branch.  Right now, it only supports up to 1.9.1.  You won't have to wait long though, unless a problem pops up, I will probably push this branch which supports all the way to 1.11.1 to stable in the next few days, then you can just find it like usual.

If you want it via CKAN now, there are instructions in the OP on how to get the "bleeding edge" beta branch.

Edited February 4, 2021 by R-T-B

[modus]

Had no problems yesterday, everything seemed to work just fine. Didn't do anything spectacular though.

[R-T-B]

14 hours ago, modus said:

Had no problems yesterday, everything seemed to work just fine. Didn't do anything spectacular though.

My feeling is there won't be many problems, which is good.

The one thing I'd stil like to do before stable release is improve the performance of the multistar Kopernicus panel math, sort of like I did with terrain scatters.  Right now, it's rather CPU heavy in a similar way.

Sound like a good idea for next BE release?  Then if that tests out to be stable, we're good?  That's the plan anyways.

Edited February 4, 2021 by R-T-B

[R-T-B]

So...  I rate limited the solar math to calculating every physics frame (50 times a second) to twice per second, which should be enough for any situation with no gameplay impact.

With this change, I managed an improvement, but honestly, the math is pretty good as is.  Here is before and after, with FPS in top left:

BEFORE:

After:

~20FPS gained.  I also detected a bug in the estimated solar panel output (it's 2x what it should be, though actual flowrate is correct, so no gameplay impact).  Fixed that as well.

I will be releasing these bugfixes for one final testing release.  The goal is to be 1.10.1/1.11.1 stable by the weekend, and we are on track for that (if not beating it!) right now.

Also, I added a codepath to update existing configs, so it doesn't wipe out Kopernicus_Config.cfg every update.  Rejoice!

This release will be on bleeding edge in a few minutes.

Oh, and one final important announcement:

With this final stable release this weekend, bleeding edge may be stagnant for a tiny bit.  That doesn't mean it's dead, and it's still where features will get pushed first.  We are just debating what to work on next.

Edited February 5, 2021 by R-T-B

[ZYKerman]

Werid.Why can't I find this one on CKAN?

[R-T-B]

Unfortunately, quality checks have revealed the solar math is not only optimizable as seen above, but also horribly off in it's calculations in some extreme multistar scenarios.  It will need a rework, and it's long overdue honestly.  I still think we can finish it on time, but this release may take a bit longer than the few minutes cited above.  Expect it in a few hours

7 minutes ago, ZYKerman said:

Werid.Why can't I find this one on CKAN?

Was delayed for reasons above.  Optimizing is no good if it's broken, heh.  I am confident it will be out sometime this evening PST timezone.

Edited February 5, 2021 by R-T-B

[ZYKerman]

11 minutes ago, R-T-B said:

Unfortunately, quality checks have revealed the solar math is not only optimizable as seen above, but also horribly off in it's calculations in some extreme multistar scenarios.  It will need a rework, and it's long overdue honestly.  I still think we can finish it on time, but this release may take a bit longer than the few minutes cited above.  Expect it in a few hours

That is to say,all mods rely on Kopernicus (eg OPM) for 1.11 won't be able to install through CKAN (before this night)? 

Edited February 5, 2021 by ZYKerman

[R-T-B]

26 minutes ago, ZYKerman said:

That is to say,all mods rely on Kopernicus (eg OPM) for 1.11 won't be able to install through CKAN (before this night)? 

no, there is still a release up on the beta branch.  You can follow the instructions in OP here to get it (at bottom of FAQ) if you don't mind the solar bug that presently exists (or are in a single star system where it does not matter).

But yes for CKAN standard with no additional steps, we need to wait for stable.  That will probably be until tomorrow.  This is to ensure quality for everyone.

Edited February 5, 2021 by R-T-B

[Murdabenne]

21 hours ago, ZYKerman said:

That is to say,all mods rely on Kopernicus (eg OPM) for 1.11 won't be able to install through CKAN (before this night)? 

FYI, the BE beta works just fine with CKAN if you add the repository.  And CKAN conveniently lists it so you can add the BE repository with just a couple mouse clicks.

[R-T-B]

So today's work report:

I fixed the solar math for multistar.  It was pretty buggy.  I managed to both optimize it similar to the above and apply my new knowledge of Inverse Square law to do the math much much better.  The result is a much more acurate implementation.  It's so acurate, I think it actually reveals slight math errors in KSPs own implementation.  This means that in general, stock panels get SLIGHTLY more power than stock because it "finds" energy lost due to stock KSP math errors, but we are talking about amounts well under 10% of the panels output in the best case, so don't get too excited.  I didn't feel like correcting the math to be "more buggy" like stock (stock uses singles and I use doubles, for those curious, and the losses primarily occur in floating point imprecision).

I also did some optimizations that may look odd is select instances, but save major performance and are unlikely to have any gameplay impact.  They are as follows:

1.)  Flat Solar Panels (with the exception of curved and/or nonstock exotic types) do not consider a body 180 degrees from their tracking direction for light calculations (they do for tracking, but not for EC input, basically).  This is because by logic, all flat one sided panels can't accept light on the back side, and that would be silly to track.  This manifests itself in both a not insignificant performance gain, and a weird side effect of briefly losing power input if you are between two stars and order the panel to "spin" to the other star (it happens because for a brief moment, the panel is facing a star that by logic, should not be considered for light calculations, so it doesn't get light from it in the game logic).  This should not be a problem in a well designed craft, and will not be fixed as the power will return in literally seconds as soon as the servos rotate the panel to the right target star.

2.)  The math in general is as mentioned, using double precision and that means we get a little more power than Squads single precision math.  Squad did all kinds of lossy conversions (truncating decimals) in their code that I do my best to avoid.  This is actually scientifically more accurate, and we are using squads formulas, squad just looses quite a few decimals along the way in stock converting from singles to doubles and worse things (sorry, programming langauge crept in there).  This manifests itself as a 1.64 output panel at homeworld orbit making more like ~1.76.  I thought about correcting this but I feel 10% boost is not going to signifigantly change any design, and as the science is technically correct, I'll be leaving it.  The math is otherwise spot on like stock and should play exactly like stock minus the slight boon in a single star scenario.

That's all.  Have a screenshot of a floating battery illustrating my point while I prepare release (note the slightly increased output in Kerbin orbit, and provide feedback if it bothers you).

Please note, to get this to stable this release will need further testing.  I hope we can accomplish that soon enough though!

Edited February 6, 2021 by R-T-B

[R-T-B]

Unfortunately, I jumped the gun a bit.  The inverse Square logic that is so scientifically acurate, etc?  It breaks down past Kerbin orbit inwards.  Stock must have some kind of cap on it, because my math is indicating ~70x EC generation for Moho orbit by true inverse square, which I agree is a tad absurd.

 

Guess I have to try to emulate stock afterall.  Expect a release tomorrow while I work this out, not today.

EDIT:  Worked out what was happening, it was some kind of squad scaling around the inner planets.  Fixed.  Build incoming soon.

Edited February 6, 2021 by R-T-B

[R-T-B]

Just dropped, expect on Bleeding Edge CKAN soon.

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

R-T-B released this now

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 76. It contains the following changes:

1.) Kopernicus_Config.cfg is no longer included in zip archive, but generated on first run if you need one. This prevents wiping out old config files, on CKAN or otherwise.

2.) Solar math was completely bugged in multistar situations. This has been fixed using math emulating the Inverse Square law. The use of double precision means we get a little more EC solar power than in stock game's math, but it is with a margin of 10% and should not really matter.

3.) The solar math also saw an optimization so solar panel heavy craft can run better! It should be much faster on solar-heavy multistar situations now.

SPECIAL NOTICE: This release is the second release candidate for 1.10.1/1.11.1 going to the stable branch. If it proves bug free in a few days, this will likely end up the stable build. Please help test!

Known Bugs:

1.) At interstellar ranges, heat can sometimes behave strangely. It is best to turn off part heating when traveling far far away.

2.) When zooming out all the way in map view at interstellar ranges, the navbal sometimes behaves oddly. We are working on this and all the interstellar bugs actively.

3.) The ring shader still may have some bugs in opengl environments, though minor. It mostly works in testing.

Please download the right output zip for your version. "1.9.1" zips are for 1.9.1, "1.10.1" for 1.10.1, "1.11.0" for 1.11.0, etc.

Thanks and as always, report bugs!

-RTB

Edited February 6, 2021 by R-T-B

[R-T-B]

We have identified some bugs with the solar panels when dealing with barycenters.  They try to track them and glitch out, getting no power, is the idea.  This will be fixed in next release, likely tomorrow.

This is only caused if a barycenter templates a star and has luminosity from the sun template.  You can work around it temporarily by setting a barycenters luminosity to 0 in the barycenters body config file.

Edited February 6, 2021 by R-T-B

[R-T-B]

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

R-T-B released this now

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 77. It contains the following changes:

1.) Panels will no longer consider barycenters (or any bodies that don't emit light) in the star tracking calculations.

2.) The list of bodies to track is now sorted by how close they are to your vessel, close bodies appearing first. This is a practicality change for some systems where the list of solar bodies can stretch off the screen.

3.) The ringshader bundle in 1.8.1 packages was updated to properly support that platform (D3D dual camera, and all).

4.) ModularFlightIntegrator bundle updated to 1.2.9. (You can always update this manually, we use mainline now).

SPECIAL NOTICE: This release is the third and hopefully final release candidate for 1.10.1/1.11.1 going to the stable branch. If it proves bug free in a few days, this will likely end up the stable build. Please help test!

Known Bugs:

1.) At interstellar ranges, heat can sometimes behave strangely. It is best to turn off part heating when traveling far far away.

2.) When zooming out all the way in map view at interstellar ranges, the navbal sometimes behaves oddly. We are working on this and all the interstellar bugs actively.

Please download the right output zip for your version. "1.9.1" zips are for 1.9.1, "1.10.1" for 1.10.1, "1.11.0" for 1.11.0, etc.

Thanks and as always, report bugs!

-RTB

Edited February 6, 2021 by R-T-B

[Murdabenne]

So far so good in my sandbox test with OPM and CA.

[R-T-B]

1 hour ago, Murdabenne said:

So far so good in my sandbox test with OPM and CA.

I'm thinking if I don't hear of any worthwhile bugs from my multistar test group, this may be it.  We may be seeing stable 1.8.1-1.11.1 tomorrow, thanks to all the testers here.  You guys make Kopernicus great, every bit as much as devs like myself.

Have a slightly relevant screenshot of Jeb in my testing vessel, dubbed the "Space Flower":

Edited February 7, 2021 by R-T-B

[R-T-B]

Release 77 has become the latest stable supporting all modern KSP versions, release 27 stable.  I made a new thread to commemorate the occasion, and to stop bugging Prestja (who is busy with school now) with edits to a project he is only minorly contributing to at the moment (no offense man, you are always welcome to help out with us anytime, I know you got the skill).

I would advise all not truly desiring to be beta testers of the latest stuff (and bugs) to switch to that going forward.  It will be a quality build with only quality fixes that are vetted imported, and now that the initial development cycle to get us up to speed is done, will really be the one you want as a daily driver.  It's also on CKAN with no repository hackery (or will be soon).

Bleeding edge may see more blood in the near future as we experiment with things I'm not so confident on (cough cough comets etc).

Edited February 7, 2021 by R-T-B

[linuxgurugamer]

Hi,

While debugging anothe rmod, I saw this in the log file many times:

384414 Uploading Crash Report
384415 UnityException: Find is not allowed to be called from a MonoBehaviour constructor (or instance field initializer), call it in Awake or Start instead. Called from MonoBehaviour 'PQSMod_Subdivide' on game object 'Subdivide'.
384416 See "Script Serialization" page in the Unity Manual for further details.
384417   at (wrapper managed-to-native) UnityEngine.Shader.Find(string)
384418   at PQSModExpansion.PQSMod_Subdivide..ctor () [0x00019] in <b6b3af8f70dd42d7adac8493f5bd45d3>:0 
384419 UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object)
384420 UnityEngine.DebugLogHandler:LogException(Exception, Object)
384421 ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
384422 UnityEngine.Logger:LogException(Exception, Object)
384423 UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)
384424 UnityEngine.GameObject:Internal_AddComponentWithType(Type)
384425 UnityEngine.GameObject:AddComponent(Type) (at C:\buildslave\unity\build\Runtime\Export\Scripting\GameObject.bindings.cs:222)
384426 UnityEngine.GameObject:AddComponent() (at C:\buildslave\unity\build\Runtime\Export\Scripting\GameObject.bindings.cs:227)
384427 Kopernicus.Configuration.ModLoader.ModLoader`1:Create(PQS)
384428 Kopernicus.Configuration.ModLoader.ModLoader`1:Kopernicus.ConfigParser.Interfaces.ICreatable.Create()
384429 Kopernicus.ConfigParser.Parser:LoadCollectionMemberFromConfigurationNode(MemberInfo, Object, ConfigNode, String, Boolean)
384430 Kopernicus.ConfigParser.Parser:LoadObjectFromConfigurationNode(Object, ConfigNode, String, Boolean)
384431 Kopernicus.ConfigParser.Parser:LoadObjectMemberFromConfigurationNode(MemberInfo, Object, ConfigNode, String, Boolean)
384432 Kopernicus.ConfigParser.Parser:LoadObjectFromConfigurationNode(Object, ConfigNode, String, Boolean)
384433 Kopernicus.Configuration.Loader:Kopernicus.ConfigParser.Interfaces.IParserEventSubscriber.PostApply(ConfigNode)
384434 Kopernicus.ConfigParser.Parser:LoadObjectFromConfigurationNode(Object, ConfigNode, String, Boolean)
384435 Kopernicus.ConfigParser.Parser:CreateObjectFromConfigNode(ConfigNode, String, Boolean)
384436 Kopernicus.Injector:Awake()
384437 UnityEngine.GameObject:Internal_AddComponentWithType(Type)
384438 UnityEngine.GameObject:AddComponent(Type) (at C:\buildslave\unity\build\Runtime\Export\Scripting\GameObject.bindings.cs:222)
384439 AddonLoader:StartAddon(LoadedAssembly, Type, KSPAddon, Startup)
384440 AddonLoader:StartAddons(Startup)
384441 AddonLoader:OnLevelLoaded(GameScenes)
384442 AddonLoader:OnSceneLoaded(Scene, LoadSceneMode)
384443 UnityEngine.SceneManagement.SceneManager:Internal_SceneLoaded(Scene, LoadSceneMode) (at C:\buildslave\unity\build\Runtime\Export\SceneManager\SceneManager.cs:244)
384444  

 

should be looked into.

Edited February 8, 2021 by linuxgurugamer

[R-T-B]

1 hour ago, linuxgurugamer said:

Hi,

While debugging anothe rmod, I saw this in the log file many times:

384414 Uploading Crash Report
384415 UnityException: Find is not allowed to be called from a MonoBehaviour constructor (or instance field initializer), call it in Awake or Start instead. Called from MonoBehaviour 'PQSMod_Subdivide' on game object 'Subdivide'.
384416 See "Script Serialization" page in the Unity Manual for further details.
384417   at (wrapper managed-to-native) UnityEngine.Shader.Find(string)
384418   at PQSModExpansion.PQSMod_Subdivide..ctor () [0x00019] in <b6b3af8f70dd42d7adac8493f5bd45d3>:0 
384419 UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object)
384420 UnityEngine.DebugLogHandler:LogException(Exception, Object)
384421 ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
384422 UnityEngine.Logger:LogException(Exception, Object)
384423 UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)
384424 UnityEngine.GameObject:Internal_AddComponentWithType(Type)
384425 UnityEngine.GameObject:AddComponent(Type) (at C:\buildslave\unity\build\Runtime\Export\Scripting\GameObject.bindings.cs:222)
384426 UnityEngine.GameObject:AddComponent() (at C:\buildslave\unity\build\Runtime\Export\Scripting\GameObject.bindings.cs:227)
384427 Kopernicus.Configuration.ModLoader.ModLoader`1:Create(PQS)
384428 Kopernicus.Configuration.ModLoader.ModLoader`1:Kopernicus.ConfigParser.Interfaces.ICreatable.Create()
384429 Kopernicus.ConfigParser.Parser:LoadCollectionMemberFromConfigurationNode(MemberInfo, Object, ConfigNode, String, Boolean)
384430 Kopernicus.ConfigParser.Parser:LoadObjectFromConfigurationNode(Object, ConfigNode, String, Boolean)
384431 Kopernicus.ConfigParser.Parser:LoadObjectMemberFromConfigurationNode(MemberInfo, Object, ConfigNode, String, Boolean)
384432 Kopernicus.ConfigParser.Parser:LoadObjectFromConfigurationNode(Object, ConfigNode, String, Boolean)
384433 Kopernicus.Configuration.Loader:Kopernicus.ConfigParser.Interfaces.IParserEventSubscriber.PostApply(ConfigNode)
384434 Kopernicus.ConfigParser.Parser:LoadObjectFromConfigurationNode(Object, ConfigNode, String, Boolean)
384435 Kopernicus.ConfigParser.Parser:CreateObjectFromConfigNode(ConfigNode, String, Boolean)
384436 Kopernicus.Injector:Awake()
384437 UnityEngine.GameObject:Internal_AddComponentWithType(Type)
384438 UnityEngine.GameObject:AddComponent(Type) (at C:\buildslave\unity\build\Runtime\Export\Scripting\GameObject.bindings.cs:222)
384439 AddonLoader:StartAddon(LoadedAssembly, Type, KSPAddon, Startup)
384440 AddonLoader:StartAddons(Startup)
384441 AddonLoader:OnLevelLoaded(GameScenes)
384442 AddonLoader:OnSceneLoaded(Scene, LoadSceneMode)
384443 UnityEngine.SceneManagement.SceneManager:Internal_SceneLoaded(Scene, LoadSceneMode) (at C:\buildslave\unity\build\Runtime\Export\SceneManager\SceneManager.cs:244)
384444  

 

should be looked into.

This is a bug with Parallax PQSModExpansion code.  It upsets Kopernicus but I do not believe Kopernicus is the origin. Linx says it is harmless and will be fixed in next release.  Any symptoms that prompted your debugging?

Edited February 8, 2021 by R-T-B

[linuxgurugamer]

5 hours ago, R-T-B said:

This is a bug with Parallax PQSModExpansion code.  It upsets Kopernicus but I do not believe Kopernicus is the origin. Linx says it is harmless and will be fixed in next release.  Any symptoms that prompted your debugging?

I just saw it while working on one of my mods.  Figured I'd let you know

[SpacedInvader]

Posting this in multiple places in the hopes of finding someone who could help figure this out...

I'm running into a serious issue with Kopernicus and I've got no idea how to fix it. Things were working fine until last night, running the most recent stable version of Kopernicus on KSP 1.11.1. Then after an 8 hour session the game crashed... hard... I got some blank error messages with progress bars that did nothing except show that they were from Unity and one notification that there had been an overflow of some type before finally forcing me to alt-f4 / end processes to get rid of the messages. Anyway, ever since then, whenever I try to load a save from within the game, this is what I'm presented with:

Spoiler

Spoiler

The first image where KSC is underground is what always happens on the first reload, the second is usually what happens if I try to reload a second time, though sometimes the terrain is so low that you can see water below the floating space center.

Anyway, these are from a bare bones install with just Kopernicus, ModularFlightIntegrator, and Module Manager and KSP installed. I've tried reinstalling all of them, including KSP more than once, always with the same result. Additionally, I get the same results if I try to roll back Kopernicus and MFI to the bleeding edge version I'd been using before the stable release. That all said, whats more interesting / frustrating about this is that it doesn't seem to be restricted to my main KSP install, but instead it affects all KSP installs on my system, even a completely fresh install made after all of this started with freshly downloaded KSP and Kopernicus archives. And that's where I'm fresh out of ideas on how to fix this... I'm not familiar with anything other than logs that KSP stores outside of its home directory and I don't know of anything at all that Kopernicus might store elsewhere that could have become corrupted, so I'm really hoping someone who knows more about the way Kopernicus / KSP works can help me sort out what might be going wrong here because its preventing me from playing my main save as I'm both afraid it could further corrupt if I try to press forward and the mission I was about to launch was a rover to drive around KSC...

Logs

Kopernicus Generated Logs

EDIT: Just to be clear, I only get these results when Kopernicus is installed

Edited February 10, 2021 by SpacedInvader

[dave1904]

There are so many updates here that its sometimes hard to follow the changlogs. In one of the releases you mention that 

"Distant bodies (farther out than Eeloo) sometimes exhibit issues with sinking landing gear and deadly terrain to Kerbals. We are tracking this but don't have a fix just yet."

Just wondering if I have a separate issue or if you have no gotten around to fixing this? 

Edit: Its mentioned in release 64 that you found a fix but testing is still required. Would having 2.5 rescale cause issues? Its Plock from outer planet mod. Its late today but if you need me to give any feedback or logs on the issue feel free to ask. 

2nd Edit: Forgot to update sigma dimensions. Problem solved. 

Edited February 11, 2021 by dave1904