Thomas P.

Members
  • Content Count

    373
  • Joined

  • Last visited

Community Reputation

2,289 Excellent

About Thomas P.

  • Rank
    Version Locked on 0.90

Contact Methods

  • Website URL Array

Profile Information

  • Location Array

Recent Profile Visitors

13,060 profile views
  1. What is wrong with people that they can wait months for a KSP update with regular teasers, but not wait until modders put out a proper update when their life permits it? And then not even try to contribute upstream to get stuff fixed faster, but just put out builds of in-development code out there for quick fame? See: I don't care if you fork Kopernicus and recompile it. I don't care if you put out code that is under development out there. I really don't care. But users who install those binaries care. If you don't know the workings of the mod inside-out, you have no idea what might (still) need changes. And if you just push out a binary they will probably end up breaking their saves and then come to the Kopernicus thread (not to yours!), complaining that the saves are broken. What I care about is you shipping dependencies that haven't been updated. The MFI included in Kopernicus might still work for testing, but from the very moment 1.8 released my plan was to not put out anything until sarbian at least had a chance to recompile it against the new KSP version. Shipping that old thing not only throws me under the bus, but sarbian too, potentially. Then, if you have to change the build systems of the mods, at least do it on the right branch. What you did for Kopernicus was checking out one branch, then copying everything onto master, making the commit look like those were your updates to get the mod working under 1.8. Again: I don't care at all. The license allows you to do it. But other people might care and then go on my nerves asking me to check out that branch because it might help me get 1.8 to work. Finally, let's be honest. If I wouldn't have changed the version number of Kopernicus to 900 you would have just shipped it as 1.8.0-1, messing with me even more because then I would have to memorize and compare the assembly checksums to even figure out what users are running once I release the real update.
  2. Released 1.7.3-2 and all the other backports: Removed Kopernicus Buoyancy modifications to fix ocean lag, they never worked anyways Fixed texture loading with on-demand loading disabled Unload normal maps from RAM and only keep them in VRAM when loaded on demand Sorry for the really long delay, I just didn't really have time (or motivation) to do the release work. Note: This doesn't fix the lags that are caused by the DLC scatters! Those lags are not something that Kopernicus can fix, they are a design flaw in the DLC scatter system that is noticeable in rescaled systems (JNSQ for example). If a part of the terrain has reached it's highest subdivision level, the DLC scatters will be enabled in that area. In a rescaled system, the planets have to subdivide way earlier than in stock scale, to keep the same level of detail, meaning the area that gets filled with scatters is higher. I actually did the math, and in JNSQ you have 11x more DLC scatter than in stock. The stock scatters (i.e. the ones that exist for literally years without ever being enabled :P) solve this by not checking for subdivision level, but checking for the distance to the active vessel AFAIK. Of course I could probably hijack them somehow, but I would really prefer if Squad would fix their code to work better with rescaled systems. For a quick and dirty solution you have to disable the DLC scatters in your savegame (set ROCSeed to -1). Alternatively planet makers would have to finetune their subdivision settings for the DLC, but that might have other performance implications (because you need *more* subdivision)
  3. 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.
  4. [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.]
  5. (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.
  6. 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.
  7. 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?
  8. And there we have 1.7.1-3. I really hope that everything works now.
  9. Nice, I didn't knew that! CKAN users shouldn't have problems then, I guess.
  10. 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.
  11. 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.
  12. 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.

  13. precisely 2 weeks after 1.8 comes out. and everyone who demands answers that aren't silly is out of luck
  14. 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.
  15. 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.