Thomas P.

Release time! What was released: * Kopernicus 1.7.0-1 * Kopernicus 1.6.1-3 * Kopernicus 1.5.1-5 * Kopernicus 1.4.5-10 * Kopernicus 1.3.1-19 * KittopiaTech 1.7.0-1 Changelog: * Deprecated the barycenter config option. The same functionality can be archived by using the selectable option in Properties, the invisible option in ScaledVersion and givesOffLight in ScaledVersion/Light. Barycenter caused all sorts of bugs that don't exist with the new, more fine grained, mechanism * Added the ability to use the Unity "Standard" shader for terrain scatters * Added an option to enable GPU instancing on scatterer materials. The actual effects are to be determined * Improved the texture exporter. It has a more useful output, and should correctly calculate the min and max altitude of the planet, to clamp the heightmap correctly. * Fixed assigning multiple UBIs to a body through the implements option * Updated to KSP 1.7.0 * Don't archive previous log zips anymore, since that caused some problems on Windows that I cannot debug properly. It didn't seem to be used anyway.

Oh if you knew... The reality is that axial tilt is no "small change", it's an entirely different way of doing the physics calculations at some points. Hence why the first (and only) working version is from Principia which just does everything on it's own. Also, if I could fix it, I could have also written it long time ago. Which I haven't. Dagger has really done a great job with this, which is why I refused from the very beginning to integrate it into the core of Kopernicus (and instead showed Dagger how to make it a Kopernicus plugin): Dagger deserves all the credit and attention for this. But that attention is part of the problem I guess. Dagger hit some of the same roadblocks everyone who tried to make an axial tilt mod (including me) hit. But his mod already got a lot of (premature) attention at that point, especially by people going around and annoying, even pressuring planet makers to add Tilt'Em support immediately. As a developer, that puts such a high pressure onto you, that I can understand why Dagger seems to have abadoned it. And to be honest I cannot see anyone voluntarily loading that pressure onto their own shoulders by forking, fixing and maintaining it. Also Kopernicus development is very active. I willingly break it on every KSP update so it rather has to be.

I am not 100% sure how the Kethane grid works, but have you tried to verify it in a savegame (if you can see it there, in the Tracking Station or with some scanner)? The reason is Kopernicus replaces the planet in the main menu and it is entirely possible that Kethane does it's (visual-only) changes before Kopernicus just deletes them - and therefor you don't see them. I cannot spot any actual errors from Kethane in your log so the problem might be entirely visual and limited to the main menu

It is HIGHLY unlikely that your issues are caused by MFI itself. I rather suspect that Kopernicus causes the issues and by removing MFI you are preventing Kopernicus from loading, since MFI is a hard dependency. Of course you have to upload your log files for us to do further troubleshooting.

What was released: - Kopernicus 1.6.1-2 - Kopernicus 1.5.1-4 - Kopernicus 1.4.5-9 - Kopernicus 1.3.1-18 - KittopiaTech 1.6.1-2 Changelog: - Fix a broken starlight occlusion check - Add UBI to some places, also fix PostSpawnOrbit not using UBI properly - Make the main menu respect the initial rotation value The links are in the OP

Hello, as you might know, in the past weeks and months @Pkmniako and myself have been working on creating a plugin for Interstellar Consortium. At first this plugin was supposed to be a bare orbit calculator, that transforms a stars position into an orbit the star has in-game. But now, after some experiments and various changes merged into Kopernicus itself to support our usecases, the plugin is ready for a first release and quite powerful. The basic goals of Interstellar Consortium are the following: Allow for a static star map Seamless integrate planet packs with minimal mod-dev interaction Allow users to install multiple planet/star packs with little disruption Interstellar Positioning The plugin is able to calculate static orbits for the stars based on their position. The position value is relative to the center of the universe, so as per the spreadsheet from @Pkmniako the stock sun is located at 10,0,0. You define the position like this: Body { name = My Star InterstellarConsortium { position = 20, 0, 0 } } The orbits the plugin generates are static (i.e. have a very high orbital period so they don't move), and have invisible orbit lines. That way it looks like you really have a star cluster / galaxy and not multiple stars orbiting another star at the center of the universe. The automatically generated orbits completely replace most of the contents from the Kopernicus Orbit node, which means that your star can work in standalone mode and together with IC without additional ModuleManager magic. If you are not satisfied with the automatically generated orbits, you have the ability to adjust them manually using a Orbit node inside of the InterstellarConsortium node. It's contents are applied after the autogenerated orbit was calculated. Since stars in IC might have different SOIs than in standalone, the InterstellarConsortium node includes an SOI parameter that you can use. Unlike the builtin sphereOfInfluence it isn't specified in meters but in KI, the custom distance unit the spreadsheet uses. Homeworld Switching The nature of IC, and the fact that we already wanted to write a plugin for the orbit calculations anyway, made it hard to not explore the possibility of being able to dynamically set your starting point to a different planet / star system. In a recent Kopernicus release we added the possibility of having any world that is named Kerbin be the homeworld, as opposed to depending on the homeworld actually having a Kerbin template. This feature makes it possible that the IC plugin dynamically assigns the name Kerbin to whichever world is defined as the homeworld. In the InterstellarConsortium node of your star config you can include a home parameter set to the name of the body that serves as the homeworld around the star. If your star has no homeworld, don't include the parameter. If you open the file GameData/InterstellarConsortium/InterstellarConsortium.cfg you will find a value home, you can change this to point at the star you want to start at. You can override the default home planet using the homePlanet option as well. What happens when you set those values is, that the IC plugin first searches every body called Kerbin or Sun and assigns them a randomly generated name. Then it assigns the name Sun to the selected home star and the name Kerbin to the associated home planet. The positioning system now shifts all positions by the position of the selected home star, so that the home star is at 0, 0, 0, i.e. the center of the galaxy. All other calculations now use the shifted positions, which means all other stars orbit the selected home star now. The bodies will keep their original names for the user, since their displayName isn't changed, only the internal name changes. However, the dynamic names impose one problem: Every mod that references a body by it's internal name will break as soon as the names of that body change. Take for example an EVE cloud configuration that targets Kerbin. As soon as you change your home world to, let's say, Gael from GPP that Kerbin configuration would suddenly target Gael because internally, it would be named Kerbin. The same applies for lots of other things, mainly mods like Scatterer etc., but also features like Kopernicus referenceBody tracking (which used the internal name). When you switch the homeworld all moons that orbit it would move. The solution to that is simpler than it sounds, a system / standard we called UBI - Unique Body Identifier. It is basically an overlay over the naming that is imposed by KSP without it's restrictions. As you might know, in KSP the central body has to be named Sun and the home body has to be named Kerbin to prevent KSP from failing horribly. That also implies that we have to change those names dynamically to allow for homeworld switching. UBI doesn't have those limitations. In fact, one body can even implement multiple UBIs and therefor be targeted through multiple names. A UBI is composed by a system / author name and a body name. You can set the main UBI of a body through the identifier value in the Body node, like this: Body { name = Kerbin identifier = Squad/Kerbin } All UBIs have to follow that format, to a) make their structure more clean and b) make it almost impossible to confuse them with the internal name. All values that accepted body names in Kopernicus were changed to support UBI, with a fallback to the internal name. This means, that if a body should orbit around a body with the UBI Squad/Sun, their referenceBody would be Squad/Sun not Sun A body can implement multiple UBIs through the implements value in the Body node. You can have multiple implements values. This is especially useful for dynamically assigning "roles" to one body or another. For example, let's take OPM. If it was compatible with IC, there could be a configuration option to decide, whether it should add itself to the stock system, or whether it should spawn around another star in the IC galaxy. The idea is, that the OPM bodies could be configured to orbit around a OPM/Sun body, and that depending on the settings, this UBI would be either assigned to the stock sun (additionally to Squad/Sun) or to a different star that is spawned for that purpose. That way, the amount of ModuleManager magic that is required is minimal. At the point of writing, Kopernicus already fully supports UBI. It includes a small helper class that can be copied by other mods to implement UBI support themselves. If time and motivation allows it we will probably patch some of the more common mods ourselves as some kind of reference implementation. Configs for those mods could then switch to the UBI syntax as well and full support IC, while having the same fallback to the internal name that Kopernicus has. Making a planet pack compatible The general idea of making a planet pack compatible with IC is porting it to the UBI syntax and adding the InterstellarConsortium config to your star. If your planet pack doesn't include a star, you have to decide whether it should stay in the stock system, move around it's own star, or have that part of it be configurable (more about that later). You can use the perviously mentioned tricks with UBI to limit the amount of ModuleManager magic you have to use. If you edit planets it becomes a bit more tricky, but not much. Basically what you have to do is copy the planet if you have IC installed, and still edit it if it isn't. But instead of changing it's properties, the only thing you do is assing an identifier to it. That means, if you have IC installed the copied body gets the identifier, if you haven't, it gets added to the stock body. What you can do now is change your main editing config to not target the body using it's name, but using the identifier value. @Body[Sun]:NEEDS[!InterstellarConsortium] { @identifier = GPP/Sun } +Body[Sun]:NEEDS[InterstellarConsortium] { @identifier = GPP/Sun } @Body:HAS[#identifier[GPP/Sun]] { // Your edits here } In that example, all the GPP planets would use GPP/Sun as their referenceBody, so that they automatically reparent themselves when IC is installed and the edited body changes into a copied one. Overall the system, while being rather simple, turned out to be quite powerful and pretty useful for IC as whole. Configuring planet packs Previously I mentioned that a user could choose between multiple modes for their planet packs (whether OPM spawns around the stock sun or a custom one in my example). This is possible because of another feature we have added. In the InterstellarConsortium.cfg you can add those options into a node called Settings. The IC plugin will take those values, and convert them into :FOR nodes. This means you can target them using :NEEDS in your configs. For example: InterstellarConsortium { Settings { Test = False OPM { SpawnAroundStock = True } } } would produce the following :FOR tags: IC-Test IC-Test-False IC-OPM-SpawnAroundStock IC-OPM-SpawnAroundStock-True Although it is not a technical requirement, it is recommended to only use Boolean values, since thats how you will use them anyways. If you have any questions about integrating IC compatiblity into your mod, feel free to ask them here or post them in the #interstellar-consortium channel on the Kopernicus Discord server. The download link for the plugin: https://github.com/Kopernicus/interstellar-consortium/releases Simply extract it into GameData and you should be ready to start using it. P.S: Please note that IC at the moment is not compatible with ScienceDefs since those don't support UBI. We are working on a solution for that, but it needs some testing and explaining it here would probably cause total brain input overflow.

What was released: - Kopernicus 1.6.1-1 - Kopernicus 1.5.1-3 - Kopernicus 1.4.5-8 - Kopernicus 1.3.1-17 - KittopiaTech 1.6.1-1 Changelog: - Fix buggy sunflares from 1.6.0-1 - Collect all required logs and zip them up when the game closes. If people ask for logs, ask for that .zip file and you get all of them. - Update to KSP 1.6.1 ==== Kittopia ===== - Fix some of the value editors like the color editor - Add an editor / selector for enum values - Remove the task manager window, since you can now close windows directly - Improve the number editors The links are in the OP

Generally this is true and for most mods it works just fine. However, since the Kopernicus community is not as monolithic as other community, and scattered across various planet packs threads etc. it can happen that different planet authors judge differently on how well Kopernicus works on new KSP versions (see the link I posted above). Combine that with how much hacks I had to put into Kopernicus to get certain features working, and how much a failing Kopernicus can impact your savegame (vessels vanishing from the orbits of unloaded planets). The version lock makes sure that the question to "Does it work on the new KSP version?" is clear: No, it doesn't. There is less room for speculation, experiments and misinformation. Basically, I rather take the flak for locking Kopernicus (and therefor definitly giving everyone a reason to not touch their saves) than being responsible for breaking savegames because of not reacting fast enough to KSP updates.

Thanks for taking over the full support for any version your unlocked .dll runs on. Which is, uh. every version. (See how that sounds? Another reason for a version lock - you only support the versions you feel comfortable supporting. Totally aside from making sure that in the fragmented support-eco system where planet makers are mostly the first station when asking for help, the state of Kopernicus on a new KSP version is clear.) But hey, this means I can use my weekend for actually working on the university stuff I'm supposed to do, instead of working on Kopernicus. ¯\_(ツ)_/¯ Snarking aside, dammit at least you could just ask me before you put that out. I literally even wrote when I will update Kopernicus before. But hey, I can't stop you and certainly won't try to do it either so do what you want.

I still love how Squad can wait a month to release a bugfix to a version that has serious problems with modding and noone says anything, but if they update Kopernicus apparently should become sentinent and autoupdate itself. Not just the case for 1.6.0 as well, but as it seems Squad gets infinite patience in releasing updates without complains (even with weekly(?) teasers). Just saying. -------------------------------------- Kopernicus updates when I have time. Which is likely the weekend, maybe even earlier. It also contains a bugfix to the star flare issue (lets try the teaser method - I have a feeling it doesn't work. Lol)

Because KSP's loading system ignores any files inside of a PluginData folder. If you want to load it from there, you should use ConfigNode.Load

Release time! What was released: - Kopernicus 1.6.0-1 - Kopernicus 1.5.1-2 - Kopernicus 1.4.5-7 - Kopernicus 1.3.1-16 - KittopiaTech 1.6.0-1 What was changed: - Reworked some of the code to allow a plugin for Interstellar Consortium - Fix the Sun shining through Jool - Fix Kittopia Normal Map Generation - Fix Kittopia not being able to edit bodies who use AtmosphericExtra - Allow to add multiple HazardousBody configs - Allow to controls HazardousBody using a greyscale map for heat distribution - Fix the .version file - Added the ability to recolor the editor grass - Spawning a Kopernicus asteroid triggers the stock onAsteroidSpawned event now - Kittopia windows include a close and a minimize button in their headers now. (This causes some jittering, I hope thats ok) -> Links are in the OP

This should be fixed with the next Kopernicus release, I figured out that Kopernicus was overriding a part of the stock code. This code contains the fix that 1.5 already ships for this bug, so I just removed the (useless) override for it Thanks for the research!

Kopernicus has it's own logs inside the folder "<KSP dir>/Logs/Kopernicus", which include more information about the loading and the errors occuring. In your case you would want to check the file Vall.Body.log, since thats where the loader fails, according to KSP.log

You somehow copied your GameData folder into your GameData folder, so you have this: Loading assembly at D:\Steam\steamapps\common\Kerbal Space Program\GameData\GameData\Kopernicus\Plugins\Kopernicus.dll That means you have two Kopernicus installations which won't work.

There might be a release on GitHub. You should probably check it out (yes I am the only one who makes stupid git jokes on my release notes) Changelog: - Updated to KSP 1.5.1 - Fixed a bug where BiomeMap OnDemand Loading would lag a lot in MapView. BiomeMap OD is now disabled by default. - Fixed the Kittopia planet thumbnails, thanks to Sigma Expect Squad to release 1.5.2 out of nowhere tomorrow and completely screw with my life

Would y'all at least gracefully allow me to sleep one night after a day of university before I have to make a release instantly after a KSP update releasing, before you turn the thread and my mailbox into a firestorm? Thank you. marks snarky reply as done, now to some serious answers Kopernicus is going to update to 1.5.1, unless Squad releases 1.5.2 instantly after me writing this message. That "brain-damaged checker" has prevented lots of people from blindly loading their saves just to discover that Kopernicus failed to load and everything that orbited a custom body was gone, or stuck inside of a hill due to terrain incompatiblities, and and and That "brain-damaged checker" has prevented me from lots of stress and headaches because of having to rush out updates because the old version breaks other peoples installs, or reading the posts of people (rightfully) accusing me of causing their hard work getting deleted after an (potentially automatic) ksp release That "brain-damaged checker" has motivated me to test and rebuild Kopernicus on new KSP versions and not leaving it in health support for multiple releases That "brain-damaged checker" has allowed me to read some funny email threads on my phone while in school when Squad released an update overnight. that "brain-damaged checker" made it possible that I can still joke about that (see above) For more reasons about why the checker exists and it won't go for the foreseeable future, check out this GitHub comment: https://github.com/Kopernicus/Kopernicus/issues/299#issuecomment-406890108 And to be clear, I am not going to give support for any version that has been version-unlocked. If someone publishes such a tool, they agree that I send everyone who plays on a version that can be unlocked to them for support. If you think that I have fun doing updates and version locking Kopernicus, you are completely wrong. I hate doing it. I really do. If the world was an ideal one I would just autocompile every commit on the github and people could go nuts with that, but thats not how it works. I tried doing releases without the version lock, and bad things happened. Version-locking and explicit release upgrades are the system that works for me. If it was for me I would have stayed on 1.3.1 forever (and I really considered that as an option when all that EULA/Analytics crap happened before 1.4). But I fear that me staying on one version will cause someone else forking (which is not bad at all!) Kopernicus, which could add incompatibilities to the already existing chaos of planet modding (see: my example from the github comment above). Instead I am doing backports, which adds even more time to the pile because you have to check if they compile against their respective KSP version at all, and if not rewrite the code or add switches that disable those parts. (I realize that I am not always good at testing the backports on their KSP versions though, which is why have been a bit buggy in the past) TL;DR: I don't have fun creating release updates for Kopernicus. But I understand why people want it so badly that my mailbox regulary explodes and moves every mail from the forum to the spam folder. I don't have much time to do release upgrades. But I will take the time as soon as I notice an update has been released. I don't notice release updates instantly. They either release at night when I sleep or at midday when I am at school / university. So give me some time to realize that Kopernicus needs an update I don't know that Squad doesn't allow you to downgrade to 1.5.0, therefore I don't know that an updated Kopernicus is probably even more urgent to you. So just show some patience and give me 2 or 3 days to update my build stuff, test Kopernicus a bit if I think it might fail, and then publish the release (or rather the 4 releases if you count both backports and Kittopia (which is btw. the perfect example of me leaving a mod in limbo and letting it decay until nothing works anymore)) You usually wait weeks or months (or a year for good old 1.1) for KSP updates, with weekly teasers. Just do the same for the 2 or 3 days it takes me to push out a proper release. (I bet I forgot a thing I wanted to say because of that wall of text, oh wait I wanted to stay serious. Dammit.) KSP (and by extension Kopernicus) use 9 (Atmosphere), 10 (Scaled Space) and 15 (Local Space - Terrain) for planets yes. Kopernicus doesn't do much of the rendering assignment itself, in fact it just uses the instanced Stock prefabs wherever possible, and otherwise applies the same settings Squad would apply.

Are you in the Kopernicus Discord? I posted an explanation there some time ago, if you are there just ping me. If not I can PM it to you.

Probably better to pose that question to the CKAN team since I have no control over that.

I would prefer to keep UBI secret for the moment, since not everything about it is ironed out, and its main usecase (IC) is not even finished. It might just break more than it gives you at this point. (Now look away! You have seen nothing ) KSC transformation is as easy as changing the template of Kerbin to the body you want to start from (and deleting that body from the system / transforming it into a Kerbin clone). I am sure I can work with Gregrox (or whoever maintains Alien Space Program these days) to set it up with them. I would appreciate a writeup on Orbit Icons if you want to do that.

Basically it allows you to change the template of Kerbin to Duna, and end up with your KSC being on a Duna clone (that has the same orbit as stock duna if you don't delete that). Since you have to have the KSC on the planet named Kerbin, based on the template Kerbin (since thats where the KSC comes from), you had to manually copy all the PQSMods of Duna (or any other body for that matter) to the Kerbin body to make it look like Duna, but without removing the KSC. But be aware that this might still summon monsters from the depths of your installation.

I just updated Kopernicus to KSP 1.5.0. Links are in the OP. Changelog: - Updated to KSP 1.5.0 - Improved performance of orbit icons, thanks to marr75 - Fixed the DDS palette loader - fixed biome maps not loading in the tracking station - Automatically inject the KSC transform into Kerbin, this makes it possible to change the template to something different - fixed the 1.3.1 backport - added a 1.4.5 backport Have fun!

I haven't had the chance to test it yet, but this should work https://gist.github.com/StollD/cdf365e1a07de379cddfacbeada6486b

I saw it and I was too busy to answer it Basically what you have to do is tell Kopernicus that it should load the textures. Sadly I only have the code KittopiaTech uses as a reference, which is compiled against Kopernicus so I can reference it directly. What you would have to do is to use reflection to call the load and unload functions. Load: https://github.com/Kopernicus/KittopiaTech/blob/master/src/UI/PlanetSelector.cs#L142-L151 Unload: https://github.com/Kopernicus/KittopiaTech/blob/master/src/UI/PlanetSelector.cs#L162-L165 I can write a quick reflection wrapper later (maybe tomorrow) if that's helpful for you. (and I still don't understand why OD doesn't trigger itself because it should load the textures as soon as they are visible in a camera. Unity I love you) I wanna say(if u don't listen thats fine) but do your log upload work in 1.4.5?Cuz it didn't

The changes should be applied instantly, as soon as you leave the textbox where you entered them (pressing Enter might be enough, but I am not sure about that)