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

[Space_Coyote]

I have a simple question as I am using the "Bleeding Eagle" version of this mod, plus OUterplanets. But I would like to delete a planet (Body) from this planet pack (Dres, most notably.)

As I recall and going over previous versions of Kopernicus (non RTB Versions) the format for removing a planet was this line of Code:

Quote

 

@Kopernicus

{

!Body[Dres] {}

}

 

I tried this with the current RTB  Kopernicus  "Bleeding Eagle"  update  an ti seems that this bit of code seeems not to work. Am I doing something wrong?

Space_Coyote

 

[darthgently]

22 hours ago, Dr. Omicron said:

so uh I got the kopernicus was not able to load planetary bodies warning and so then I backed up my save and made a save to test what was going on and it did not load (this was the 1.10.1 kopernicus in 1.10.1 ksp), tried to reinstall it and still went wrong, is there a mod it depends on or something I did not install right?

CKAN told me there was an update available for bleeding edge, when I went to update a new dependency was displayed and I had to install it before the bleeding edge update would install.  I'm sorry, I can't recall the new dependency but I'm thinking this is likely what you were up against.  Installing via CKAN will likely fix your issue, though it may involve circling back for the dependency as I had to do

[jimmymcgoochie]

I'm having some trouble with this mod and CKAN- I've added the BE dev repo to CKAN to get the latest versions, but the most recent version seems to have made CKAN think that it conflicts with ModularFlightIntegrator and won't install MFI with Kopernicus BE, but when I try to update to BE release 46 it complains because MFI is a dependency and isn't there. The 'relationships' tab says it requires ModuleManager 2.8.0 or later and conflicts with Kopernicus and MFI.

[darthgently]

18 hours ago, jimmymcgoochie said:

I'm having some trouble with this mod and CKAN- I've added the BE dev repo to CKAN to get the latest versions, but the most recent version seems to have made CKAN think that it conflicts with ModularFlightIntegrator and won't install MFI with Kopernicus BE, but when I try to update to BE release 46 it complains because MFI is a dependency and isn't there. The 'relationships' tab says it requires ModuleManager 2.8.0 or later and conflicts with Kopernicus and MFI.

I'm not certain, as I do it without thinking about it much, but I may have just checked the latest version in the "version" tab for one or more of the above packages to get to a working state.  I can't think of any other difference that would explain why the latest BE is working on my CKAN on 1.10.1 and your is not.  I do not recall seeing MM2.8.0 conflicting with Kop or MFI however

[infinite_monkey]

On 11/16/2020 at 7:47 PM, jimmymcgoochie said:

I'm having some trouble with this mod and CKAN- I've added the BE dev repo to CKAN to get the latest versions, but the most recent version seems to have made CKAN think that it conflicts with ModularFlightIntegrator and won't install MFI with Kopernicus BE, but when I try to update to BE release 46 it complains because MFI is a dependency and isn't there. The 'relationships' tab says it requires ModuleManager 2.8.0 or later and conflicts with Kopernicus and MFI.

6 hours ago, darthgently said:

I'm not certain, as I do it without thinking about it much, but I may have just checked the latest version in the "version" tab for one or more of the above packages to get to a working state.  I can't think of any other difference that would explain why the latest BE is working on my CKAN on 1.10.1 and your is not.  I do not recall seeing MM2.8.0 conflicting with Kop or MFI however

Which "version" tab, and what "relationships" tab? Do you guys have a different CKAN version (I have 1.29.0), is it that different on Linux or am I just blind? I just have 3 tabs - "Manage mods", "Changeset" and "Status log"

[darthgently]

1 minute ago, infinite_monkey said:

Which "version" tab, and what "relationships" tab? Do you guys have a different CKAN version (I have 1.29.0), is it that different on Linux or am I just blind? I just have 3 tabs - "Manage mods", "Changeset" and "Status log"

L-click on the mod in the main list, down in the lower right will be a set of tiny tabs.  One of them "Metadata", another is "Relationships".  The last one on the right is "Versions".  If you check next to the version you think is ok, it will allow a version exception for that particular mod.  This is how I've gotten a bunch 1.8.x mods loaded in 1.10.1 that work fine mostly.  I had totally overlooked this backwater tab also prior to someone pointing my face at it.  Once you see it, it is quite obvious, lol

[infinite_monkey]

12 minutes ago, darthgently said:

L-click on the mod in the main list, down in the lower right will be a set of tiny tabs.  One of them "Metadata", another is "Relationships".  The last one on the right is "Versions".  If you check next to the version you think is ok, it will allow a version exception for that particular mod.  This is how I've gotten a bunch 1.8.x mods loaded in 1.10.1 that work fine mostly.  I had totally overlooked this backwater tab also prior to someone pointing my face at it.  Once you see it, it is quite obvious, lol

Wow, thanks, I never knew that. However, it doesn't solve the problem

Module "Kopernicus Bleeding Edge Beta - DEV RELEASE" successfully installed
The following inconsistencies were found:
* Kopernicus-BE UBEE_1101_46 missing dependency ModularFlightIntegrator 1.2.7.0 or later
Error during installation!

I wonder why it first says it successfully installed Kopernicus 

Edited November 17, 2020 by infinite_monkey

[darthgently]

9 minutes ago, infinite_monkey said:

Wow, thanks, I never knew that. However, it doesn't solve the problem

Module "Kopernicus Bleeding Edge Beta - DEV RELEASE" successfully installed
The following inconsistencies were found:
* Kopernicus-BE UBEE_1101_46 missing dependency ModularFlightIntegrator 1.2.7.0 or later
Error during installation!

I wonder why it first says it successfully installed Kopernicus 

And you have selected version 1.2.7.0 of ModularFlightIntegrator installed via the "Versions" tab?  That is the version I have checked and that is the version that your error messages says is missing

[HebaruSan]

Hi everyone, the latest Kop-BE release made a change to how its metadata is structured in CKAN. As many of you may know, Kopernicus (Bleeding Edge or otherwise) requires a mod called ModularFlightIntegrator to function. The latest release of ModularFlightIntegrator works on KSP 1.8–1.10, but until the past week or so its version file only indicated 1.8–1.9, which meant CKAN could not install it (easily) on 1.10. To work around this limitation, @R-T-B initially set up Kop-BE to install its own copy of ModularFlightIntegrator integral to the installation of Kop-BE rather than as a separate dependency. Recently Sarbian graciously agreed to update the official version file of ModularFlightIntegrator, so it now officially supports 1.10. Therefore in the latest release (UBEE_1101_46), Kop-BE once again depends on ModularFlightIntegrator as a normal separate dependency, just as the main Kopernicus does.

This means that when you upgrade from UBEE_1101_45 to UBEE_1101_46, ModularFlightIntegrator needs to be installed, replacing pieces of UBEE_1101_45. This peculiar complex transition of relationships has revealed some flaws in CKAN's relationship resolution system. In essence, CKAN gets confused by the fact that ModularFlightIntegrator is part of the "old" version of Kop-BE but not the "new" version. @DasSkelett has investigated this and prepared a set of fixes to make it work normally in the future:

• https://github.com/KSP-CKAN/CKAN/pull/3200

These fixes will be included in the next release of CKAN. Until then, there is a relatively simple workaround: Uninstall Kop-BE before installing the latest release (just this one time), rather than using the upgrade checkbox. This will clear out the confusion around ModularFlightIntegrator so the new version can come in without issues.

[infinite_monkey]

Thanks @HebaruSan, deleting Kop-BE and then installing it again fixed it for me. I tried a reinstall before, but that didn't help. So I downloaded JNSQ two or three times today 

[R-T-B]

  

1 hour ago, HebaruSan said:

Hi everyone, the latest Kop-BE release made a change to how its metadata is structured in CKAN. As many of you may know, Kopernicus (Bleeding Edge or otherwise) requires a mod called ModularFlightIntegrator to function. The latest release of ModularFlightIntegrator works on KSP 1.8–1.10, but until the past week or so its version file only indicated 1.8–1.9, which meant CKAN could not install it (easily) on 1.10. To work around this limitation, @R-T-B initially set up Kop-BE to install its own copy of ModularFlightIntegrator integral to the installation of Kop-BE rather than as a separate dependency. Recently Sarbian graciously agreed to update the official version file of ModularFlightIntegrator, so it now officially supports 1.10. Therefore in the latest release (UBEE_1101_46), Kop-BE once again depends on ModularFlightIntegrator as a normal separate dependency, just as the main Kopernicus does.

This means that when you upgrade from UBEE_1101_45 to UBEE_1101_46, ModularFlightIntegrator needs to be installed, replacing pieces of UBEE_1101_45. This peculiar complex transition of relationships has revealed some flaws in CKAN's relationship resolution system. In essence, CKAN gets confused by the fact that ModularFlightIntegrator is part of the "old" version of Kop-BE but not the "new" version. @DasSkelett has investigated this and prepared a set of fixes to make it work normally in the future:

• https://github.com/KSP-CKAN/CKAN/pull/3200

These fixes will be included in the next release of CKAN. Until then, there is a relatively simple workaround: Uninstall Kop-BE before installing the latest release (just this one time), rather than using the upgrade checkbox. This will clear out the confusion around ModularFlightIntegrator so the new version can come in without issues.

Yep, I bolded that in the release notes but some people missed that...  heh.  Happens.

On 11/16/2020 at 7:43 AM, Space_Coyote said:

I have a simple question as I am using the "Bleeding Eagle" version of this mod, plus OUterplanets. But I would like to delete a planet (Body) from this planet pack (Dres, most notably.)

As I recall and going over previous versions of Kopernicus (non RTB Versions) the format for removing a planet was this line of Code:

I tried this with the current RTB  Kopernicus  "Bleeding Eagle"  update  an ti seems that this bit of code seeems not to work. Am I doing something wrong?

Space_Coyote

 

That looks like it should work...  maybe somethis is wrong with the modulemanager syntax.  It has to work in some form or system replacement mods would fail to remove bodies.  Try something like this, maybe:

@Kopernicus:AFTER[Kopernicus]
{
	!Body[Dres] {}
}

BTW, why u hate Dres?  It's just a potato.  Everyone knows it's not a planet.

 

On 11/15/2020 at 11:08 PM, Dr. Omicron said:

  https://drive.google.com/drive/folders/1VJ5qEasfFG901Xw_0_0KZ8DvRwocdZ9n?usp=sharing 

 

The logs

 

Thanks.  It's bugging out on Moho.  What planet pack are you using?  In your logs/Kopernicus folder somewhere, there should be a Moho.log file with the specific cause of the error.  Can I get that?

Edited November 17, 2020 by R-T-B

[darthgently]

Since I installed BE 2 days ago my 5 Sentinel sats have found zero new asteroids.  They usually find several a day.  Is there a setting or something I can look at and fix?

[darthgently]

I uninstalled BE and all my ships won't load now because BE patched all the solar panels so they use the Kopernicus solar panel module instead of the norm.  Shouldn't uninstalling, in a sane universe, revert the modules from the ships in current persistent.sfs file?  Do I have to edit the sfs and craft files?  It seems optimistic for the current mod approach to assume the mod will never, ever, be uninstalled.  Installing many mods is like sticking your fingers in a chinese fingercuff: a one-way operation.  Not friendly.  Any advice appreciated

[edit] I jumped the gun, only my new craft files are affected, not ships in game built and launched prior to BE, but still, that is a problem with the mod ecosystem: that removing a mod breaks ships.  I've thought before that if every mod had placeholder parts and modules for their own parts and modules that could be left behind on uninstall so the craft files would still load and editing the file would be easy because of easily found strings in the placeholder parts and modules or similar

Edited November 18, 2020 by darthgently
correction

[Dr. Omicron]

On 11/17/2020 at 2:04 PM, R-T-B said:

  

Yep, I bolded that in the release notes but some people missed that...  heh.  Happens.

That looks like it should work...  maybe somethis is wrong with the modulemanager syntax.  It has to work in some form or system replacement mods would fail to remove bodies.  Try something like this, maybe:

@Kopernicus:AFTER[Kopernicus]
{
	!Body[Dres] {}
}

BTW, why u hate Dres?  It's just a potato.  Everyone knows it's not a planet.

 

Thanks.  It's bugging out on Moho.  What planet pack are you using?  In your logs/Kopernicus folder somewhere, there should be a Moho.log file with the specific cause of the error.  Can I get that?

https://drive.google.com/drive/folders/1NvS-sClv4JFO88cJklATWoOxaQp-CRah?usp=sharing

of course its moho, also there was a log for the sun so I also put it in there if needed. 

 

Edit: no planet pack.

Edited November 19, 2020 by Dr. Omicron

[R-T-B]

8 hours ago, Dr. Omicron said:

https://drive.google.com/drive/folders/1NvS-sClv4JFO88cJklATWoOxaQp-CRah?usp=sharing

of course its moho, also there was a log for the sun so I also put it in there if needed. 

 

Edit: no planet pack.

Thanks for this.  Bug seems to be with stock system then, but I am unable to replicate.  Can I see your gamedata folder please?  Screenshot will do.

 

On 11/17/2020 at 5:03 PM, darthgently said:

Since I installed BE 2 days ago my 5 Sentinel sats have found zero new asteroids.  They usually find several a day.  Is there a setting or something I can look at and fix?

I'm going to readd the ability to use the stock asteroid generator next release as an optional setting.  The Kopernicus one is customizable, but breaks sentinel contracts as you noted.  It will be replaced longterm, but for now, options are better than just forcing people to use a somewhat broken system.

The solar panel code is undergoing a complete rewrite right now, with your complaints amongst numerous other being the chief reasons (the other reason is it's really really buggy).  When it is replaced, it will be far more friendly and less annoying than the current implementation.

This will all be released sometime tomorrow as another "interim patch" before the big heat bug fix (the bug with multiple stars not applying heat properly).

Edited November 19, 2020 by R-T-B

[Dr. Omicron]

http://prntscr.com/vmbrn1

http://prntscr.com/vmbrxq

http://prntscr.com/vmbs7a

[R-T-B]

10 hours ago, Dr. Omicron said:

http://prntscr.com/vmbrn1

http://prntscr.com/vmbrxq

http://prntscr.com/vmbs7a

Thanks.  SVE (StockVisualEnhancements) is the origin of your issues.  It is not compatible with the latest releases...  you aren't missing much though, as the new effects introduced in stock 1.9/1.10 are actually better than what it offered.

Edited November 20, 2020 by R-T-B

[Dr. Omicron]

41 minutes ago, R-T-B said:

Thanks.  SVE (StockVisualEnhancements) is the origin of your issues.  It is not compatible with the latest releases...  you aren't missing much though, as the new effects introduced in stock 1.9/1.10 are actually better than what it offered.

Ah thanks! Also do you mean stock has clouds?

Edit:

Edited November 20, 2020 by Dr. Omicron

[Dr. Omicron]

Wait update I still have the issue, here is the logs unless you want the game data file.

https://drive.google.com/drive/folders/1FxAfTyIgCSkzwMb6eOIB9uP5jh-nBeLx?usp=sharing logs

Edited November 20, 2020 by Dr. Omicron

[R-T-B]

4 hours ago, Dr. Omicron said:

Ah thanks! Also do you mean stock has clouds?

Edit:

No, stock does not ship clouds but the base textures are better than SVT/SVE.  You can use something like Eve's baseline config, or maybe spectra to provide clouds (I'd advise Spectra as it's pretty and has decent performance).

I'll look at what else is wrong in the morning, sorry for being so slow to respond to you I just have a lot vying for my attention.

Edited November 20, 2020 by R-T-B

[Dr. Omicron]

4 minutes ago, R-T-B said:

No, stock does not ship clouds but the base textures are better than SVT/SVE.  You can use something like Eve's baseline config, or maybe spectra to provide clouds (I'd advise Spectra as it's pretty and has decent performance).

I'll look at what else is wrong in the morning, sorry for being so slow to respond to you I just have a lot vying for my attention.

thanks

Also I dont know if this might matter but at the menu when KSP first boots up it says "Spectra" thing as in if I had spectra installed but I dont but whenever I uninstall spectra it stays there might that be something? Im going to try to hard reinstall ksp to see if it is just some thing outside.

Edited November 20, 2020 by Dr. Omicron

[R-T-B]

Just now, Dr. Omicron said:

Dont worry

Also I dont know if this might matter but at the menu when KSP first boots up it says "Spectra" thing as in if I had spectra installed but I dont but whenever I uninstall spectra it stays there might that be something? Im going to try to hard reinstall ksp to see if it is just some thing outside.

Yeah, that sounds like a good idea.  I'd reinstall and start from a clean slate since from your log, it seems like maybe the base Moho config is corrupt, which definitely should not be happening.

[Dr. Omicron]

1 hour ago, R-T-B said:

Yeah, that sounds like a good idea.  I'd reinstall and start from a clean slate since from your log, it seems like maybe the base Moho config is corrupt, which definitely should not be happening.

aye it worked, sorry for all this.

[cyberKerb]

Sorry to ask here, as it's more of a request for information than about the mod...

Is someone able to point me to how to get a current listing of the BUILTIN textures that are referenced for Duna?
I'm looking at an old Kopernicus config to change Dunas topology and it references what I assume is a now non-existing texture:  BUILTIN/red_cliff
Looking to know how I can see it's replacement reference? (if there even is one)

Edited November 20, 2020 by cyberKerb

[Hohmannson]

25 minutes ago, cyberKerb said:

Sorry to ask here, as it's more of a request for information than about the mod...

Is someone able to point me to how to get a current listing of the BUILTIN textures that are referenced for Duna?
I'm looking at an old Kopernicus config to change Dunas topology and it references what I assume is a now non-existing texture:  BUILTIN/red_cliff
Looking to know how I can see it's replacement reference? (if there even is one)

SteepTex is now BUILTIN/Duna Cliff [Diffuse]

You are tinkering with Duna Restoration Project i think. KittopiaDumps, that lists (with some errors) all stock system'things, including PQS material data, can be found here https://github.com/Kopernicus/kittopia-dumps/blob/master/Configs/Duna.cfg

I'd recommend just copy-paste all the material node from modern Duna to patch and you will be fine. Or, maybe, tweak brightness a bit.