R-T-B

My plan is to make an interim release with a few small bugfixes (mostly performance related, nothing major) and removal of that old remove-dependency thingy tomorrow, so I'll hold off on editing since it would be irrelevant in 24 hours. I'll do an edit with new instructions then. As for the "big release" that fixes the heating bug. Soon, but not tomorrow, sadly. Maybe. The code that handles asteroids/comets is... weird. It's been changed a lot lately on the bleeding edge and we finally just decided it needs a rewrite rather than trying to fix something that seems eternally broken. I can't really advise other than say it will be better soon.

I can't say what CKAN is thinking exactly. I just know if you back out by uninstalling Kopernicus and ModularFlightIntegrator in their entirety in CKAN, and then attempt to install Kopernicus BE, it generally works even with the present workarounds. If you have it working though, I'd just go with it.

Those files are unused, but it is odd that there are 0kb versions anyways.

It should still be spawning asteroids, just not making Sentinel contracts, as they were broken. Has anyone else experienced this bug? Or rather, has anyone seen an asteroid/comet in 1.10.1 recent builds? Note that as soon as the heating bug I am workng on now (approximately 75% done) is finished, the next thing I plan to do is completely rewrite the asteroid/comet spawning code, so if it's buggy, you shouldn't have to wait long for it to be fixed. A week or two I'd say at most. Due to a temporary packaging limitation (should be fixed next release), you need to have ModularFlightIntegrator uninstalled before trying this (it's included anyways). That should fix you in the short term, next release will fix this oddity (MFI finally got updated with true 1.10.1 compatibility in the version file).

It's true, the scatter code is insanely inefficient, and honestly, I don't know how to fix it, and I've got so much to do it is very low on the priority list to figure out. Still, not wanting to leave user hanging, I offered a work around some few releases ago in the form of the "culling range" parameter. You can find it as the parameter "ScatterCullDistance" in GameData\Kopernicus\Config\Kopernicus_Config.cfg. Basically it's a range in meters and scatters outside that range around the vessel aren't rendered. I believe it's set to something approximating stock by default, probably 10000 (10km) which even kills me with my 5ghz OC'd i9 9900k (Kopernicus just can't keep up with the stock scatter density and range even on high end cpu due to inefficient replacement code). I've heard lowering it to 5000 (around 5km visible scatters) makes it have virtually no performance impact on modern hardware vs no scatters, you might try this. I personally run at 7500 but I feel that might be a bit much for most users who don't OC their CPUs. I'm assuming it's because the scatter code is singlethreaded in Kopernicus or something and ends up competing with the physics thread, but I can't really deal with that now until I understand it further. Got too much on my plate right now. So the work around parameter will have to do. I think next release I will ship it as 5000 meters by default, even if not technically correct, it's better than lagging to death. @stephm

Yes, I'd start by removing OPM VO and SVT. The stock shaders will provide a better appearance at their highest settings, anyways. Squad has done a lot there and it's likely a shader conflict of some kind.

The bug is still likely the same. Are you certain you are using the latest OPM mod? Try this: https://github.com/Poodmund/Outer-Planets-Mod/releases/ If you are already using that, let me know and I'll look into it further. Post a screenshot of your gamedata folder in that instance, please. Praise the Kraken! Enjoy your game! *Vanishes back inside Visual Studio*

Most likely. Sorry for the slow replies, hope it works for you now!

Is this a universal issue on stable 1.9.1 version? If it is, I should probably add it to my tracker for fixing.

Yeah the solar panel code in Kopernicus is undergoing a rewrite right now, it's part of why I'm so quiet (apologies all, it's a tough one). You can revert to the "stock" solar code by deleting solarpanels.cfg from the config folder of Kopernicus. Do be advised this only works for single star systems, as the stock code is not aware of more than one star. For everyone else: I am working on it. I do apologize things are not moving faster but it's a combination of my job and the task to fix it being increasingly complex the more I dig into it. For the bug reported by @Daxion and @computercat04, the situation is a bit better. The fix needed is config side. We may want to report the change needed to RSS devs, which I will do. The thing is, Kerbin uses several shaders by default now (depending on your settings) so templating it without specifying a shader type is not supported. This can be fixed by simply settings a PQS materialType, like so in the PQS node on earth: materialType = AtmosphericTriplanarZoomRotation I've attatched a file that does this, fixing the loading bug, and reported it upstream to RSS devs. Thanks for helping narrow that down. To use the attached file, download the zip, and replace the Earth.cfg in your GameData\RealSolarSystem\RSSKopernicus\Earth folder with the one in the zip. Thanks. http://glacialsoftware.net/EarthRSSFix.zip EDIT EDIT: After looking over the RSS repo it seems you are using an out of date version. Though my fix will work, it is advisable to use the latest versions. Since they have already fixed the "bug" I have removed my bug report. Find the right versions here: https://github.com/KSP-RO/RealSolarSystem/releases https://github.com/KSP-RO/RSS-Textures/releases

Ok, I found something else: [EXC 21:33:08.854] Exception: Failed to load Body: Kerbin Kopernicus.Configuration.Loader.Kopernicus.ConfigParser.Interfaces.IParserEventSubscriber.PostApply (ConfigNode node) (at <19b75557b052466a841d36b5c4af25e4>:0) Kopernicus.ConfigParser.Parser.LoadObjectFromConfigurationNode (System.Object o, ConfigNode node, System.String configName, System.Boolean getChildren) (at <395892e8bc6a43f7a7ef20a5d37d4d79>:0) Kopernicus.ConfigParser.Parser.CreateObjectFromConfigNode[T] (ConfigNode node, System.String configName, System.Boolean getChildren) (at <395892e8bc6a43f7a7ef20a5d37d4d79>:0) Kopernicus.Injector.Awake () (at <19b75557b052466a841d36b5c4af25e4>:0) UnityEngine.Debug:LogException(Exception) Kopernicus.Injector:Awake() UnityEngine.GameObject:AddComponent(Type) AddonLoader:StartAddon(LoadedAssembly, Type, KSPAddon, Startup) AddonLoader:StartAddons(Startup) AddonLoader:OnLevelLoaded(GameScenes) AddonLoader:OnSceneLoaded(Scene, LoadSceneMode) UnityEngine.SceneManagement.SceneManager:Internal_SceneLoaded(Scene, LoadSceneMode) This seems to imply it is failing to create the "Kerbin" (earth) homeworld. Can you go into the Logs/Kopernicus folder, and post Kerbin.body? It should be a text like file you can upload somewhere. It will tell me what is breaking, and what we need to do to fix it. Also can you link the RSS download you are using for my testing use?

No worries, it's not a bother. I will take another look at your logs in a few, looking for something else. Will be in touch.

basically just comets and the heating bug (which is also present in 1.9 stable right now). The heating bug is priority and slowing things down, but it only affects multistar configurations. I'd actually say 1.10.1 is stable, but it's just not ready for planet pack authors to use yet without proper comet facilities. End users need not fear it right now though.

Analyzing your log this time shows something a bit more telling. Kerbal Engineers is complaining it is missing some config node. Perhaps try reinstalling that? It may not be the issue but it's a start, and I will continue to look this evening. Relevant error: [LOG 21:18:35.285] [AddonLoader]: Instantiating addon 'GeneralSettings' from assembly 'KerbalEngineer' [EXC 21:18:35.517] XmlException: Root element is missing. System.Xml.XmlTextReaderImpl.Throw (System.Exception e) (at <b92efb6eef6e41b5abd458f107e6d92e>:0) System.Xml.XmlTextReaderImpl.ThrowWithoutLineInfo (System.String res) (at <b92efb6eef6e41b5abd458f107e6d92e>:0) System.Xml.XmlTextReaderImpl.ParseDocumentContent () (at <b92efb6eef6e41b5abd458f107e6d92e>:0) System.Xml.XmlTextReaderImpl.Read () (at <b92efb6eef6e41b5abd458f107e6d92e>:0) System.Xml.XmlTextReader.Read () (at <b92efb6eef6e41b5abd458f107e6d92e>:0) System.Xml.XmlReader.MoveToContent () (at <b92efb6eef6e41b5abd458f107e6d92e>:0) Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderList1.Read3_ArrayOfSettingItem () (at <d3dc0aebc0654b0b8c15c7e8c03bec4a>:0) System.Reflection.MonoMethod.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) (at <ad04dee02e7e4a85a1299c7ee81c79f6>:0) Rethrow as InvalidOperationException: There is an error in XML document (0, 0). System.Xml.Serialization.XmlSerializer.Deserialize (System.Xml.XmlReader xmlReader, System.String encodingStyle, System.Xml.Serialization.XmlDeserializationEvents events) (at <b92efb6eef6e41b5abd458f107e6d92e>:0) System.Xml.Serialization.XmlSerializer.Deserialize (System.Xml.XmlReader xmlReader, System.String encodingStyle) (at <b92efb6eef6e41b5abd458f107e6d92e>:0) System.Xml.Serialization.XmlSerializer.Deserialize (System.IO.Stream stream) (at <b92efb6eef6e41b5abd458f107e6d92e>:0) KerbalEngineer.Settings.SettingHandler.Deserialise (System.String fileName, System.Type[] extraTypes) (at <df610534f02e44eabb2fe7c95c06a0aa>:0) KerbalEngineer.Settings.SettingHandler.Load (System.String fileName, System.Type[] extraTypes) (at <df610534f02e44eabb2fe7c95c06a0aa>:0) KerbalEngineer.Settings.GeneralSettings.OnEnable () (at <df610534f02e44eabb2fe7c95c06a0aa>:0) UnityEngine.GameObject:AddComponent(Type) AddonLoader:StartAddon(LoadedAssembly, Type, KSPAddon, Startup) AddonLoader:StartAddons(Startup) <LoadObjects>d__88:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) <CreateDatabase>d__69:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) GameDatabase:StartLoad() <LoadSystems>d__11:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) LoadingScreen:Start() That'd certainly be nice, and we've talked cooperation at times, but nothing solid has come of it yet.

Because JNSQ massively increases the draw distances. The bodies have approximately 2.5x more radius. It really tanks performance. I'm looking at optimizations but that's where it is now.

Hey all, I made some JNSQ configs for the stock texture pack linx is distributing in beta on Patreon (eventually will be free). For now, subscribe to his patreon (you should still do this but don't have to) download and get the stock textures for Parallax. Rename the ParallaxStock folder "ParallaxJNSQ" Then put everything in this zip inside that folder, replacing all: http://glacialsoftware.net/KOP_DEBUG_BUILDS/ParallaxJNSQ.zip You now have a "JNSQ ready" stock textures set. Keep in mind beefy computer is needed, Recomend RTX 2070 or better really. (my 2080 Super does 40-50FPS in this screenshot at 4K, so just barely playable, obviously lower resses help). EDIT: Patreon no longer required, you can just use the stock release that is public.

We've had issues with this and our multistar SolarPanels.cfg support in the past. You can try downloading the latest bleeding edge release to see if it helps (be sure and completely replace the directory, especially the SolarPanels.cfg file), or simply delete Kopernicus/Config/SolarPanels.cfg to see if it helps (this will make it only support one star, mind). If that doesn't help, let me know and I'll take another look.

My release model is very different from the previous devs (I allow us to peak at the bleeding edge where they kept it very "behind the curtain"), so while it may create the illusion of a ton more work, truth be told, they still moved mountains. Make no mistake though, this is definitely an intense project. I took it on because I couldn't play KSP without Kopernicus, so finally just said "screw this, I'm gonna update it." Lol, my modding has always been like that. For me first and you guys second. That's ok though, it still works.

That log is pretty useless, I'll admit. It's basically saying Kopernicus loaded and then quit. There may be more details in another log file (Kopernicus makes several). To b be clear are you having any issues? If not that looks normal. Hi @computercat04, sorry I'm just getting around to replying to you. Can I get a modlist to go with this bug report? You are running a slightly older version but it still should not be bugging out like that. I'd like to help you determine why this is happening, and if we can fix it (either on my end or yours). The first thing I would try is the latest release, found here. It probably won't fix your issue, but it's always worth a try: Kopernicus R-T-B Unified "Bleeding Edge" Edition Release 45 On that note: I apologize I haven't been more responsive on the forums, all. I have been busy busy busy at work and with the heating bug. Between the two, I find very little time to communicate right now. But I'm working hard, for certain, and I still try to get around to your questions when I can.

An update on the comet system that is holding up 1.10.1 stable release, and on the new bug that's surfaced (bolded above) that is now taking priority and slowing down it's implementation: The comet system is 50% done, approximately. It's going to be a very high quality product upon release and will mark the first time 1.10.1 can be up for consideration to be promoted to a "stable" build on CKAN. Unfortunately, that is now on hold as I have been made aware of a bug with our multistar implementation, particularly with vessel heating. ECs work fine, but vessels do not heat up on non-root stars. They don't even burn on extremely close orbits, being perfectly happy to be 50m from the literal surface of the sun. This is obviously, not ideal. We looked into a quick fix for this, only to find the problem is quite deep rooted in how multistar works, and basically requiring a rewrite of the system. Basically, it's a complex problem to tackle, and it's taking all of our resources away from the comet system at the moment. I expect to have it done by next weekend though, and then we will be back full steam ahead for the proper comet implmentation. If you asked me now when "1.10.1 stable" would be here, I'd estimate 2-3 weeks (no commitments of course). Sorry for the delays, but a big bug like that can't be ignored. It is being worked on. The multistar heat bug will probably be fixed within 1 week (with a likely 1 week testing period following) for comparison. It is complex indeed (nearly as complex as the comet system), but NOT insurmountable. Thank you again for your patience. Rest assured, work continues, but there may be a lull in releases for a bit while we work on this. If you try to land on a star in the meantime, that's on you, not us (just for the record).

Yep we had a release with severe logspam. It was harmless but annoying and it's fixed now.

I suspect we will continue to use this topic for stable 1.10.1 and all future builds, but have not discussed it with Prestja yet so that COULD change. I don't think it will though. When 1.10 is release btw, we won't be dropped support for 1.9.1. The new unified build system I pioneered in the bleeding edge should allow us to continue to support 1.9.1 indefinitely (or at least until something really bad stops us).

A wild hotfix just appeared, for some logspam issues: Kopernicus R-T-B Unified "Bleeding Edge" Edition Release 45 R-T-B released this 4 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 45. It contains the following changes: 1.) Bugfix for some logspam relating to meshes, updating is advisable. Known Bugs: 1.) Solar flux (heat) is not applied to the vessel if you are orbiting a non-center/root star. EC generation still works on solar panels, though. This is an old bug we are just now being made aware of and is mostly applicable to complex systems with multiple stars. We hope to fix it by next release. 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

I apologize to release two releases in one day, but we had a logspam issue, so here's the hotfix. Bleeding edge will also get the same fix in just a moment. Kopernicus 1.9.1-12 R-T-B released this 39 seconds ago · 1 commit to master since this release New in this version (1.9.1-12) 1.) This is a hotfix to address logspam issues that were otherwise mostly harmless (may hurt performance but not your game). Updating is still advisable. New in major release (1.9.1) 1.) Solarpanel.cfg fixes to support more third party solar panels with less work. 2.) Fixes for the colliders on land scatters (due to a small bug in the distance-culling system). 3.) Added an RGB+A parser (MapSOParserRGBA) for devs who requested it. Largely an under the hood change with no end-user impact immediately visible. 4.) Added a culling range to land scatters, by default at 10km, configurable by the Kopernicus_Config.cfg parameter ScatterCullDistance. This massively improves performance in scatter-heavy planet packs with land scatters on. 5.) We now support "Breaking Ground" anomalies out of the box, eliminating the need for "MyRocksAreBiggerThanYours." 6.) Material names have been simplified. You can still use the old ones, but there are simpler alternatives now. You can see https://github.com/R-T-B/Kopernicus/pull/28/files for details, or simply wait for the wiki to update. Remember, the old names still work and we have no plans to change that, this is just for usability. 7.) Planet pack authors (or you) may now specify the packs target shader level by by setting config/Kopernicus_Config.cfg EnforcedShaderLeve. 3 = Ultra/Atlas, 2 = High, 1 = Medium, and 0 = Low. Planet pack authors may use this via modulemanager module if needed as well. Note that we encourage of the KSP Parallax shader project over use of Squad's ATLAS shader. It is both equally performant and more flexible. 8.) Performance Optimization and bugfixes enabling KittopiaTech support. Particle support restored. 10.) All 1.9.1 bugs that are known fixed. Full support for 1.9.1 9.) Multistar support. The math on ECs in single star may be slightly different than stock in some situations, but it should be similar in most and not enough to matter. 10.) Added GameData\Kopernicus\Config\Kopernicus_Config.cfg file, with options to configure shader warnings and enable or disable shader locking, as well as set preferred shader level. Easy to edit, just look inside!

We also had a bug when this thread was made (about 6 months ago) which has now been fixed that may have been contributory. Not sure if the user was experiencing that or a normal map issue, could be one or both.