Tellion

Sure! This is the relevant section: // Prevent unloading for textures whose paths match the following regular // expressions. Some mods access and modify textures, so those shouldn't be // unloaded. // The list must be space- and/or comma-separated and in one line. // Duplicated lists are joined. keepLoaded = ^BoulderCo/(Clouds|Atmosphere)/ ^CommunityResourcePack/ keepLoaded = ^CustomBiomes/PluginData/CustomBiomes/ ^KittopiaSpace/Textures/ keepLoaded = ^Kopernicus/Textures/ ^Romfarer/textures/ keepLoaded = ^WarpPlugin/PlanetResourceData/ ^OPM/ The appended ^OPM/ prevents TextureReplacer from unloading the textures Kopernicus needs.

Everything you need to know is in the first post or the changelog ------------------------------------ Adding an exception for the OPM folder in the @Default.cfg file in the TextureReplacer folder resolves the issue with loading planets. This config might be MM compatible - i think something about other modders was written at the start of it, so maybe you can include a quick patch CptRobau

Quickly thrown together configs for OPM 1.5.5 and 64K 1.0.90.5 can be found here; as always, the probability of me having forgotten or screwed up something is absolutely there - so please tell me if that is the case My main install crashes with the latest update, I suspect it does indeed have something to do with TextureReplacer. Shaw was so kind to add exceptions for Kittopia and Kopernicus folders, but the textures were moved into the OPM folder with the latest update; I guess that will trigger the issue again.

There is an "official" one, that is Gravitasi's planet pack. Should be an excellent template to learn from. Also, back in the days, KCreator made some example configs demonstrating the stuff one could do with Kittopia - you will have to look for that in the respective thread.

Looking magnificent as always

Ah, interesting read - thanks for clearing that up!

Cannot quite confirm. Getting anything manned any further than low low LKO will not even allow you to use the first launchpad ._. And it is only cascading upwards, I mean try landing on moho for example - the 12km/s insertion burn really makes everything stock could throw at you pale in comparison, even with RF, FAR etc.

Not being involved in any mod's development myself, I am very fond of the idea of having both gaseous and liquid components brought into ISRU where it is appropriate. Scooping LH2 from Jools atmosphere just does not feel right for me (which might be very subjective). Also, a significant portion of those resources is already defined from other mods in the CRP at this point. I can see FreeThinker's point about the highly specific resources - because putting six thousand tons of HE and a bunch of converters on the launchpad and converting it into He3 should not be a viable gameplay option (though one might restrict helium's availability during assembly - then again, that narrows possible uses down). Also we have another problem when we allow large portions of a more generic resource to be converted into small portions of a specific one: what about conservation of mass? Are we dumping some perfectly good fuel, or are we keeping it with its name, allowing reconversion? I am not even bringing name changing into this... In the case of He3 for example, defining a resource band in space just above Jool's atmosphere would do the job just fine, avoiding both the issue of overabundance and unmanageable atmospheres.

Which problem specifically? Yes, I do

I turned of R&D purchases and use the mod that slashes building prices tenfold; additionally the one that mostly removes science as a reward for contracts. Works pleasantly so far, though I really relied on some very well paid contracts from station science at the start.

From my own experience, it is doable although grindy. Nothing you cannot get around with either mods or difficulty options imo

Aren't the stock jet engines horribly overpowered?

It can be, apparently...

Aww yiss! Big thanks to everyone involved

Big thanks for the update!

It works fine, but very high timewarp levels lead to more asteroids spawning than are getting removed, which will ultimately cause an overflow of them and very serious lag. Work around that by either not the highest timewarps or staying on 1000x timewarp for a while after you had an "astrolice infestation" - that will lead to despawn rate taking over and cleaning up the mess Also, a more subtle approach would be savefile editing, if staying on 1000x for 15 minutes would mess with your missions.

Sun shining through planets for example is very noticeable once you go into realistic territories with planet radius. Some cloud layers from visual packs might need readjusting as well. Atmospheres stay in place (a 10x Kerbin would have the same atmosphere) if you do not do anything, however they can also be modified with relative ease. The asteroid spawning method fortunately uses values relative to the orbital parameters, so no issues with resizing stuff there at all. Also custom asteroids gives you great freedom in setting up new asteroids populations, and has an excellent documentation from what I saw. Yes and no, it depends on the contract parameters being hardcoded or not. I think the fineprint (stock) contracts use relative values, so no orbits inside planets. The remote tech contract pack does as well afaik; however the scansat one does not. Also there are bugs with exploration contracts on new bodies from what I have read, no idea about the specifics though. [And sorry if this strays too far from the topic, but since we are talking about OPM planets as well and more compatibility surely is a great thing, I figure its justifiable]

Great to hear that, and no need for rushing anything since it turned out to be quite minor

The OS is linux, the linux 64bit version of unity is perfectly stable and so is KSP, which in this case is also supported by Squad and will be in the future. I have however found a workaround - after "extending" the winch for the first time, the gui allows switching plug modes - after that, the winch will extend and behave as expected. Drawback is that you now need a probecore with the winch, but it is totally playable.

How stealthy

Not much effort at all Just take a look at the system.cfg file for all the general parameters, and at the .cfgs in KittopiaSpace/SaveLoad for PQS stuff. Both Kopernicus and KopernicusTech should allow moving stock bodies without issue, although if you want to work off a previously existing resizing config, using RSS alongside Kopernicus has the benefit of integrating all the work that was done on the stock bodies through RSS already, as well as power curves. As to the side effects, well nothing gamebreaking really, some minor visual glitches but nothing much to worry about.

Borisbee, any observations about RAM usage when using the voronoi craters pqsmod? I believe I once read somewhere RSS related that the two had a somewhat troublesome relationship, so I would be curious to know! And amazing work btw, glad to see so much done with Kopernicus!

Because of interoperability and gameplay (Scansat, oh my god scansat) I guess. Nobody wants to deal with multiple interfaces (or none at all, looking at ORS/Scansat) when there is no apparent benefit from it. Also, the reason CRP was made in the first place was the plethora of resources floating about, which where all trying to be the same thing in essence (aquifier, water, lqdwater, h2o, etc)... Starting this again, if not in resource definitions then in frameworks, seems like a bad idea to me. What do you mean with auto-adjusting extraction rates based on density? You have the ability for varied resource abundances and looking at a standard drill config, it also has an efficiency parameter - so you could vary rates based on what resource you are mining without issue. If you are having things like conservation of mass during resource conversion in mind, well the ratios can be calculated, again, without issue. Apart from that, as already suggested, if you feel some important feature is lacking in Regolith, consult with Roverdude, he surely knows best how to get certain results if the specifics are so very important... What a wonderful way of dealing with other people's concerns^^

Yeah, it is really really bad on linux ._. No pretty docking ports for now.

So everything is working now? My pleasure