Thomas P.

Just two hints: I relicensed the framework to the MIT license, and it it version 2.0, not 3.0. Thanks

I released the final v2.0 version. I changed the regular expressions, so they are compiled when the game loads, and not every time they are used. This required a small library that contains the Regex classes from the newer .NET Framework, and that was ported back to .NET 3.5 by me. (Thanks Microsoft!). Another feature I added is an API for mods. Modders who want to allow translation of their plugins can copy the file LanguageAPI.cs into their mods and wrap their strings with LanguageAPI.Translate(<text>). It is context specific, so each mod can have his own set of translations, marked by a "context = <assembly name>" value in the translation node. https://github.com/LanguagePatches/LanguagePatches-Framework/releases/tag/v2.0 As of its 3.0 release, the german translation uses this version of the framework. It is production ready, apart from some small bugs. If you want to thank me, thank the guys from http://kerbalspaceprogram.de, especially @Allan Sche Sar, too, since the framework and the german patch are developed in parallel and they were effectively the beta testers. @simon56modder It would be awesome if you could update the OP!

In theory it is possible, but I think the EULA forbids to remove the Squad Logo and the KSP Logo. The other images can be replaced, but I never tested how it works.

@Sandworm I would need your Logs/Kopernicus files to be 100% sure, but this could be an issue with write permissions, so Kopernicus fails when trying to save the cached ScaledSpace mesh

The problem is that the PQS builds the whole planet at the same time, and rebuilding it dynamically is a pain.

No, because then you would have to keep the horrific PQS active all the time.

Released 1.2.1-1, get it from Github.

Oooooookaaaaaaaayyyy.... Good joke! Sadly, a large part of the community and especially the planet community doesnt behave like adults, but instead they only search the Download button, and dont even read. If it would be that easy, Users would apply this hack, and "forget" that they applied it when they want support, either from the planet pack authors or from me. Trust me, we already had that with the old x64 hack. (I remember a story from sarbian, where he spend some hours trying to replicate an issue that was actually caused by x64 instabilities, but the user hasnt told him that he uses x64) If the users of Kopernicus would behave more mature, I would have no problem with removing the version lock. But sadly this doesn't work. Just look at the last page. Every Single Update, there is a 2-pages spam marathon about why the version lock is silly, and why I have to remove it NAOW. Do you get why I added it in the first place? I added it, when the 1.0.5 update heavily broke my code, and instead of bugging me, the users started to annoy the planet pack makers about why their mod would kill their games. Thats why I am locking Kopernicus to the releases it has been tested on. And by tested I mean tested by me or someone who understands every part of the code, not someone who throws the dll into GameData and starts the game. Additionally I live in Europe, and it is always night for me when Squad releases updates. And in the morning I have better things to do than to check if there were KSP updates - not that it would actually matter as I have to go to school shortly after getting up. So, if you complain about Kopernicus being version locked, you should realize that I always update it as soon as possible, unless people start to annoy me (For example: I never released a Kopernicus for 1.1.1. Why? Because people annoyed me that much that we missed 1.1.1 and went straight to 1.1.2). Also: People say "1.2.1 broke Kopernicus, there are no planets". Does NOBODY read the dammn popup that is shown when you start the game? TL;DR: I will update it when I want to update it, and when I have the time to do so. In the meantime, stop complaining, or I will ask the moderators to close the thread, which would be quite unfair for those who actually need help. P.S. If there would be codevelopers for Kopernicus, I would have no problem if they would update and release versions when I am away. Sadly, I am almost the only person working on it

What is it? Stellarator is a software that can generate random solar systems for KSP / Kopernicus. It is not a mod for KSP itself, but a standalone application. The reason is, that every planet in KSP exists twice, once as a high res version that is shown at low distance, and a lower res version that is shown at higher distances. (Scaled Space). While the local space uses procedural generation to create the terrain and the colors, the Scaled Space relies on pregenerated maps. Because the generation for those maps is very slow, this is done outside of KSP. What you get is a folder with Kopernicus configs that you can copy into your GameData folder. How does it work? Stellarator creates the base solar system using a software called "Accrete", that simulates a dust cloud around a protostar, and formes planets until no dust is left. Accrete is originally written in C, but I ported it to C#/.NET to be used by Stellarator. The orbits and some of the other parameters from Accrete are used as a base to generate the planet. But since Accrete cant take care of everything, Stellarator has a database of prefabs for all the things a planet needs: Atmosphere curves, Names, Rings, Gas Giant textures and so on. This database is loaded at runtime and elements are selected randomly, or using special conditions, like radius of the planet. The most important part is the PQS (the terrain of the planet): As mentioned above we use a database of prefabs to load parameters. The PQS prefabs are special. The definitions, who are stored in ConfigNodes, are loaded, and their values are evaluated by a library called "Dynamic Expresso", which allows for dynamic configs (you could do deformation = planet.radius * 5 for example). After that, the Configs are loaded by the same parser library that powers Kopernicus, and that got included in Stellarator. Since the parser relies on the PQS, and we obviously dont have the PQS available in a standalone app, I reimplemented most of KSPs PQSMods in a standalone library (libpqsmods.dll). That allows us to generate the ScaledSpace maps we mentioned above outside of KSP, but with the same style. Current state The generator code is getting pretty solid and useable, but the database is largely incomplete. There are almost no prefabs for PQS, rings and stars. The texture generator for gas planets, and the name generator are awesome though. Pictures (might be ugly, because some of them were from earlier development phases): http://imgur.com/a/0T6FG Why? Because I wanted to show that it is possible to have randomized solar systems in KSP. And because it is fun. How to use Start the included .exe file, enter a seed, a folder name and choose if the names of the planets should be systematic (Sol-a, Sol-b etc.) or not (Mercury, Earth etc.). The system folder will be in a folder called "systems". Move it to gamedata, install Kopernicus and you should be good ! WARNING ! Do not rename the folder. The texture paths would change otherwise. ! WARNING ! Do not use this on existing savegames. Stellarator generates configs that delete the whole system and rebuild it from Scratch, using different names. Legal Stuff Because it is a proof of concept, I do not want someone to redistribute systems generated by the software, even if they properly credit the people who make Stellarator. That means, that the whole program code of Stellarator is licensed under the Terms of the MIT License, except the namespaces ModLoader and Parser who are LGPL, but the database assets (that means configs and textures) are licensed as All Rights Reserved. Stellarator is based on the following libraries: ConfigNode.dll - Standalone Implementation of KSPs config nodes by @godarklight libpqsmods.dll - Standalone Implementation of KSPs PQSMod types by @Thomas P. / The Kopernicus Team libaccrete.dll - A library that simulates planet formation and accretation. Multiple authors, ported from C to C# by @Thomas P. Dynamic.Expresso.dll - C# expressions interpreter by davideicardi Further credit goes to: @Sigma88, @GregroxMun and @KillAshley for their work on the database @regex for the idea of using Accrete @Teknoman117 for the Kopernicus parser that is (ab)used in this project @eggrobin Name idea. Thanks Download https://github.com/Kopernicus/Stellarator/releases/tag/pre-0.1 Like my mods? Please consider supporting me and my mods on Paypal! I would greatly appreaciate it, since I don't get much money anyways. However note, that this doesn't grant you anything special, but it will help to keep my motivation up. Therefor it's just an extremly nice way to say "thanks".

Redownload from Github please, it was a bug I hotfixed.

This is not correct. If they were procedurally generated, they would've been exported to some kind of static dump, that cant change easily anymore, like a heightmap. If they are procedurally generated the output parameters are entered into KSP and KSP does the generation on the fly. If you change the formula, the whole planet changes. This is what KSP does. What you mean is "randomly generated (for each save)"

" I fixed them and updated the .zip on Github " It works now

Thats an error in the UI. Nothing related to the config saver. The other issues in the log seem to be related to oceans. I fixed them and updated the .zip on Github

sure, why not?

I released Kopernicus 1.2.0-3 on Github. It contains two untested PQSCity loaders, some fixes for barycenters, and maybe the most important thing: A system that allows for almost bug free reparenting of Kerbin. What the system does is to read a config node named "PostSpawnOrbit" from the Body node, that uses the same parameter names as the Orbit node, and to apply it after KSP has spawned the planetary system prefab. While this is not the best way, and Kopernicus was built specifically to avoid live patching of the system, this is the only way, since it is, apart from some minor visual bugs, stable. (For comparison: if I reparented Kerbin in the prefab in 1.2, the space center was totally black. So yeah..) Planet makers should use the Orbit node to define the orbital elements, and the PostSpawnOrbit node to change the referenceBody. (I really should have called this release 1.2-3)

One of the problems here is the definition of procedural. Procedural does not mean random. Procedural does not mean dynamic / endless generation (like in No Mans Sky) Procedural does mean that the terrain and maybe the properties of the planet are defined by mathematical function and rules, who are controlled by a seed. In fact, most of the bodies in KSP have procedural terrain, but their seed is fixed so they are always the same. Randomised planets would be easily possible in KSP, just by iterating over all PQSMods and changing their seed parameters - even though that would be rather ugly, not facing other implications (ScaledSpace generation and whatever). It's doable though. Endless generation simply isn't possible without a lot of hassle. It is certainly possible, but in a game that wasn't built for it, this would not make much fun.

KSC has special support for being moved

To be honest, I would blame the rapid loading of the planets here. This is nothing the stock game, and its planets were designed for. I have no real idea how I could fix this in Kopernicus

Localization of mods only works if the mods support it. It doesnt matter if the solution is built in, or implemented by an external plugin. Indeed I think it is easier to use this plugin, because I dont think KSP is going to iterate over all UI elements it finds, and replaces the texts. So, everything that uses the new Unity UI can be translated using this. Without changes to the mod itself. (IMGUI localization won't work at all though.)

I released KittopiaTech 0.5. https://github.com/Kopernicus/KittopiaTech/releases/tag/alpha-0-5 It fixes an issue with caching, the texture exporter, and represents the Update to KSP 1.2. It relies on Kopernicus 1.2.0-2 and its MFI version.

Sadly, we lost our donated DO nodes some weeks ago, so the site is back on a single server

I can access it. It is slow, but it works

Hi! You probably don't know me, but I am the person that developed, and that is developing, the LanguagePatches Framework, a framework that allows you to translate the UI of KSP without any coding skills. Back in 1.0, there was a XML based version of the framework, which was slow and unefficient. When 1.1 was release I started to rewrite it under the MIT license (as opposed to the former LGPL). It now uses KSPs ConfigNode format, and supports some nice things like regular expressions (for translating "Day 1" to "Tag 1" for example). If you want to play around with the framework, you can get it from GitHub: https://github.com/LanguagePatches/LanguagePatches-Framework/releases/tag/v2.0-pre This is still a prerelease. I think I will do a real release when I am sure no bugs are left. If you need help with the framework, I encourage you to check out the german translation. It is developed in parallel with the framework, because I am involved in both (and I originally only made it for myself / the german patch). https://github.com/KerbalSpaceProgramDe/KSP-Deutsch-Patch/tree/master/GameData Please be aware that the german patch is still beta too.

Dammit... Expect 1.2.0-2 soon then. And its there