Thomas P.

  • Content Count

  • Joined

  • Last visited

Community Reputation

2,255 Excellent

About Thomas P.

Contact Methods

  • Website URL Array

Profile Information

  • Location Array

Recent Profile Visitors

12,491 profile views
  1. 1.7.3-1 is out, plus backports and Kittopia. Apart from recompiling against 1.7.3 it only contains a fix for the barycenter and selectable options, thanks to @Sigma88 Sorry for the long break and skipping one version, but I just had to get a break and do something else for a few days or weeks.
  2. [Moderator's note: This thread has been extensively pruned due to off-topic kvetching about Kopernicus' version lock, after a moderator request to cease doing so. However, Thomas' comments here are particularly cogent, since he's the author, so this post has been left in place for future reference, after anonymizing the quotes involved.] The solution to the problem is removing the checker and maintaining it like every other KSP mod without version locking. However, for various reasons that I keep posting every KSP release, I am not willing to do that. If someone shows up and takes Kopernicus out of my hands I am heading for the airlock faster than you can blink. I am still maintaining it because - as you said - people depend on it and I don't want to leave them standing in the rain, but as for myself, I have lost almost any interest I have in KSP. I am not going to spend my time with user errors that happen because of obscure errors that a new version introduced. Fine. If you can tell me any way, how to properly unit test a blackbox that can change at any time (hint: KSP updates do that, rumors say), without knowing anything about how this blackbox changed, and that at runtime, every time the game is launched, without lagging it to death, then I will happily accept it. Given that this test doesn't end up being bigger than the entire mod. For those of you who don't know it: KSP's planets (and basically the entire game) consist of objects that are parented to each other, creating a tree-alike structure. Each of these objects can have multiple scripts attached that are executed each frame. What KSP does is storing a copy of one of these trees, with all planets parented to it. At some point in the loading process, it takes this tree, and searches it's children for a predefined planet structure, and spawns them into the planetary system. Those planet prefabs have multiple sub-trees, like the PQS object, the scaled space etc. etc., all of which are spawned into different trees at runtime. (ScaledSpace for example is seperated from the PQS so you can disable and enable them independently). Kopernicus edits this prefab tree and lets KSP spawn the planets, so they are spawned exactly like KSP would like to have them. Spawning them manually has been tried before (=> Planet Factory), and yeah, it is even more chaos than Kopernicus is. But the spawner just copies objects and restores some references, everything else is assumed to be correct. At runtime, KSP then assumes that some things exist, like certain components that interact with each other etc. That is not a problem for Squad because they know (I hope) how their planets work, and can adjust to changes. But because Kopernicus uses stock components all the time to build the planets, if it doesn't create or edit one correctly - or in the right place, everything can break and kill your savegame. For example, the colliders on the terrain are a component. If Squad would change the place where that component goes, Kopernicus would still add it in the spot that worked before, and none of your bodies would have terrain colliders. And you wouldn't notice until it is too late and you loaded your vessel which is now falling into the void. Of course this is all a huge oversimplification, but I hope it gets the point across. Actually, an even simpler example: It is like figuring out if a car works or not, without actually starting the car. Even if you are a top class mechanic, you will have problems doing this when your car is a huge gigantic blackbox, that you cannot open, and you don't even know whether it drives with gasolin or rainbows. When you only see the surface you have no idea how things work behind it, and therefor cannot test for it. There are people who can test unlocked versions of Kopernicus and do so. However, the moment I release unlocked betas, people will think (or want to think) that they are stable. People are not reasonable. 4 releases in one day is an obvious consequence of me touching every file of the codebase and being an idiot sometimes (=> forgetting to update my build scripts, see 1.7.0-2 ). Game breaking bugs can get catched by testing. If there are obvious errors in the loading process (as in: code errors instead of logic errors in the KSP blackbox), you get greeted with the same warning to not load your saves. Yes, we make errors too, and yes we don't catch everything. We are just humans too. But some testing feels better than none at all. You forget that Kopernicus can be used for much more than just visuals. I could install an entire galaxy in KSP and populate it, and still start from Kerbin. If I don't edit Kerbin, there is no change to the main menu kerbin. But if all other bodies stop loading (for example with Outer Planets Mod), every vessel orbiting them is moved to the trashcan. Again, try figuring out how that hypothetical car work without actually starting it and seeing if it explodes or turns into a pumpkin. So, we will probably never agree and thats completely fine. Maybe it is possible to unit test KSP. I don't know. But I don't have the time to care about it either. My solution works for me and seemingly the majority of the people. If it wouldn't work, people would fork it and remove it. Thats the beauty of opensource after all. [One final moderator reminder, folks. This post by the mod author has been left in place as a useful reference. Please do not attempt to respond or continue the argument. Thank you for your understanding.]
  3. (so much for wanting nice code and changing every file of the code) 1.7.1-5 and the associated backports are out. Kopernicus shouldn't crash anymore when trying to load other bin files (crude solution, but it works for the moment I hope. I am just hoping there is no mod that stores 2GB bin files somewhere ), and I fixed two other issues, related to scaled space on demand loading, and the parser misinterpreting node names. These two bugs were never reported in public, so I won't go into detail on them. If you want to know what happened, check github.
  4. Kopernicus tries to preload all .bin files in GameData since they are used for caching scaled space meshes. The only other mod that used .bin files that I was aware of was Kerbalism, and they mentioned that they changed their file extension, but aparently Trajectories uses the same code that Kerbalism uses. I will look into how this can be solved properly tomorrow and probably make another release then, but until then you can only remove the mod, sorry.
  5. And there we have 1.7.1-4, lol. Does making so many releases give me extra points on the "Kopernicus is not working on new KSP version, please update yesterday" scale?
  6. And there we have 1.7.1-3. I really hope that everything works now.
  7. Nice, I didn't knew that! CKAN users shouldn't have problems then, I guess.
  8. Aaand, expect 1.7.1-2 soon because my build server messed up and didn't update the version numbers. Sorry. EDIT: 1.7.1-2 is out. Have fun. Sorry again.
  9. Release time! What was released: Kopernicus 1.7.1-1 Kopernicus 1.6.1-4 Kopernicus 1.5.1-6 Kopernicus 1.4.5-11 Kopernicus 1.3.1-20 KittopiaTech 1.7.1-1 Changelog: * refactored a large part of the codebase to align more with the coding style preferences in my IDE. This also includes merging the three core Kopernicus .dlls into one .dll again (+ Kopernicus.Parser). * Cache more properties of the generated scaled space mesh and preload them, to reduce the amount of calculations and disk IO that is done when loading planets * Reduce the amount of IO that is done by the logger * The `texture` and `normals` values from `ScaledVersion/Material` are no longer loaded on demand. If you want on demand loading for scaled space textures, you have to specify their paths inside of a `ScaledVersion/OnDemand` node, using `texture` and `normals`, just like before. * Allow loading `fogColorRamp` through a gradient instead of a texture * Abort loading planets if System.cfg was modified directly. There is no reason to do that except if you want to make your mod unremovable without breaking every other mod. Planet packs are supposed to use ModuleManager (I am looking at you, KerbalGalaxy Remastered) * Fix an error that prevented bodies with `invisible = True` from staying invisible, unless they templated the sun. * Take over the mesh generation / spawning for scatter meshes. Stock merges them into one big mesh which makes it impossible to detect their actual position, or give them sub-objects. Every scatter instance is now it's own dedicated object, which greatly simplyfies things. * Added a `HeatEmitter` scatter component that turns the scatter objects into a heat source. * Removed `ScatterExperiment` and replaced it with `ModuleSurfaceObjectTrigger`. It's a part module that can be added to parts, and enable / disable KSPActions when the vessel is near a surface object with a certain name (surface objects are scatters and PQSCity). It also sends events to all other PartModules on the part, so plugin developers could handle scatter with custom logic * Added a `useBetterDensity` option to the Scatter config. It tries to randomize the density a bit, and avoid rounding it down to an int like stock does. In stock, a scatter can either appear once (or more) per quad, or not at all. The idea behind useBetterDensity is to allow them to spawn, but not strictly on every quad. * Added a `ignoreDensityGameSetting` option to the Scatter config. If everything fails, this can be used to stop the density game setting from influencing your scatter, so you only have to find one density config that works. The scatter will be treated as if the game setting was set to 100% * Allow scatter rotation control through the `rotation` option. By default it is set to `rotation = 0 360` which means the scatter can rotate between 0 and 360 degrees. Set it to `rotation = 0 0` to fix the rotation * Allow specifying multiple meshes and randomly selecting one through the `Meshes` node in the scatter config. It can contain multiple entries (choose the key as you like), that point to .obj files in GameData. Kopernicus will load them all and assign one randomly to every scatter object that gets spawned. * Added a `spawnChance` option in the scatter config, that can be used to fine tune density even more. * The ScatterColliders component allows specifying a simplified collision mesh (.obj), through the `collider` option, as opposed to using the visual mesh for collisions * Added a scatter module that forces the scatters to spawn at sea level (with a settable offset), this can be used to create floating objects. * Readded the ability to set a custom mapMaxHeight for texture exports in Kittopia ATTENTION: This release will break plugins that depend on Kopernicus While the old files still work, it is recommended to regenerate your scaled space cache, to take advantage of the improved format and caching You have to adjust your configs to get scaled space OD working again Since this release reduces the amount of dlls that come with Kopernicus, you have to delete the Kopernicus folder from GameData before installing. Do not overwrite the folder. CKAN users probably have to uninstall and reinstall Kopernicus. DLC Surface Features: There is no need for Kopernicus to support adding or removing the surface objects from the DLC because they have their own config files in SquadExpansion/Serenity. Even if they would have to be managed through Kopernicus, I wouldn't actually want to add that, because it would fragment players between two similar systems (terrain scatters and surface objects), where one is behind a paywall. Thats why this release tries to make more use of the terrain scatters than before, with similar features to the DLC. Of course Squads code will always be more polished than this, and I think the DLC is absolutely worth it's price, but I like having an alternative.
  10. Have you ever thought that maybe some day you don't have time to maintain this mod? After so many years maybe you should try to contact with Squad see if they would like to take over your mod so that you don't have to maintain this mod all by yourself. It's just a suggestion. It doesn't mean anything else.

  11. precisely 2 weeks after 1.8 comes out. and everyone who demands answers that aren't silly is out of luck
  12. Ok, so PSA: The next Kopernicus update will completely kill any plugin that depends on it (this means mods who interact with Kopernicus through anything except the config interface). The reason is that I did some really big refactoring to the code, so isn't full of warnings in my IDE and changed some of the more stupid choices I made in the past (like splitting Kopernicus into 3 dlls) The config interface is stable so far (and actually the new version might be able to load mods from pre 1.3.1-3 again, since I just deleted the config option that caused those bodies to error out - KSP always overwrites it with a default that I cannot change) - but I have some ideas that might require changes. When changes are neccessary I will post something about them. However, as previously said, all plugins that interface with Kopernicus or it's parser directly (i.e. the IC plugin, Sigmas plugins and so on) will need at least a recompile but probably some larger code changes. The logic didn't change, but a lot of parameter names did. If you need help with updating a plugin, feel free to ping me and I will see what I can do. I would appreciate if you could try (i.e. compiling the source code on github and checking if your plugin builds against it) before I release that version so that I can revert something before releasing it in case it is neccessary.
  13. I am not going to revive this. It was made as a proof-of-concept mod, and while it still has concepts that I am pretty proud of, and that noone has re-used so far, I don't have the time nor the motivation to maintain it. Additionally, noone was ever able or willing to fill the PQS database to a reasonable degree, and I dont expect that to change. The ACCRETE based planet generation has lots of problems as well when integrated into KSP. If you want to revive and fork this, go for it, but I rather see this as a proof of concept mod that shows what can be done. If you want something that has reasonably active development, go check out To Boldly Go, but I am not sure how many planet-related features it has these days.
  14. 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.
  15. 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.