Poodmund

Added the following: PQS Mod:VoronoiCraters Guide - by OhioBob

Well with regards to OPM and terrain textures, OPM already uses CTTP for its terrain textures and so utilizing SVT's would just been trading for taste rather than quality.

Thank you for your explanations, yes that should be fine. When you specify the folder for DiRT to also load textures from, does that only apply to the textures that are contained within KSP's "Default" texture directory? It doesn't necessarily matter too much for me personally but would be good to have clarity. With respect to the other bits, no rush at all! Enjoy real life as you're busy and just do any dev work when you want to. I'm in no hurry.

I did: Although its a bit dated now and only shows the stock system but you should be able to make a copy to your own Google account and change the system stats to GPP's own (and edit the other necessary dependables).

Added a few more tutorials: Realistic Mountains with Photoshop and Wilbur - by Miguel Bartelsman Simply Making Mountains in GIMP & Wilbur - by Ludgarthewarwolf Making Mountains for the Artistically Challenged - by Unknown Realistic Coastlines in Photoshop/GIMP - by Old Guy Gaming Libnoise Designer - Procedural Noise Generation tool using Libnoise library. Executable file located in \Bin\LibnoiseDesigner.exe

Then you should raise awareness of this issue in those other mod packs too so that the authors can either remove, change or purchase the licenses required to utilize this textures.

Have you checked out the Planet Wiki mod? ---- Linux, unfortunately the stock KSPedia is pretty lackluster when it comes to giving information about the stock bodies.

You can't legally go from a share-a-like license to the more restrictive no derivatives license without there being issues. You'd have to go the way Linux is suggesting and make KSS share-a-like to do so, unfortunately. EDIT: To do so, however, you're whole Dev team would have to be in agreement to go towards the newly, more permissive share-a-like license.

Also just to let you know some of the planet textures in this mod were legally/illegally sourced from Robert Stein III's licensed collection of planet map works that require the mod owner to purchase a royalty free license of usage before they can include the textures within their mod: https://gumroad.com/duael The following planet map textures I can see off the top of my head are: KerbalGalaxy\Abbadon System\Icy -> Recoloured version of Robert Stein III's Planet Bog KerbalGalaxy\Abbadon System\Icy -> Robert Stein III's Planet Jinx KerbalGalaxy\Gargantua System\Mann's Planet -> Robert Stein III's Planet Klendathu KerbalGalaxy\Osiris System\Ida -> Robert Stein III's Planet Hoth KerbalGalaxy\Osiris System\Hoth -> Robert Stein III's Planet Dank So there are potentially 5 violations here. Just thought I'd let you know, @StarCrusher96, as you'll be wanting to change them as to not violate Robert Stein III's usage rights.

Okay, I was just making sure that the player-base and your dev team was aware of this issue.

Just so everyone is aware, Kerbal Galaxy operates a CC-BY-NC-SA license which is incompatible with KSS' CC-BY-NC-ND license and therefore the two cannot be merged.

I think the caged responses that the idea has been getting here is due to the fact that the OP is trying to sell the idea that is only, really, going to appeal to the ignorant, uninformed users to the majority of forum users who are ingrained within the modding culture of this game who possess a wealth of knowledge about the modding database. Basically, OP, you're preaching to the wrong crowd I think.

Basically you would set a smart part to link to an engine(s) on a stage and set the smart part to change their thrust limit setting (tweakable setting) to a specified amount on the smart part activation. I was actually thinking how I could do this in game as I wanted my main core engine to be thrust limited upon ascent whilst my SRBs were firing but then upon SRB separation I wanted my main core engine to ramp back up to 100% thrust limit immediately. There was no way to really activate this "smart" process but I thought, "ah, that's exactly the kind of smart staging activation thing that the mod 'Smart Parts' might be able to do". That's essentially why I've asked about it as I thought it would be very in-keeping with what this mod tries to achieve; smart, logical processes firing upon conditional activation.

Thanks for the suggestion, I have spoken briefly to Cydonian Monk about changes to DiRT to increase extensibility when it comes to using CKAN and may have another work around which could help on a personal mod level. Hopefully this can be resolved soon'ish(TM).

Is the Thrust Limiter % a tweakable that these parts could interact with upon activation? For example, when a smart part triggers, it could change an engine's thrust limit % from X% to Y%.

Seems fine to me: https://github.com/Kopernicus/Kopernicus/issues/309#issuecomment-420730413 Will just need the head honchos to give the code a few times over to make sure that nothing untoward may be happening as a result I guess. P.S. I hit 165fps as I have the game set to V-Sync and my max refresh rate on my monitor is 165Hz.

I don't know how familiar you are with CKAN's behaviour but basically it does not allow interactions to take place with existing files; quite rightly so as it ensures that mods that are installed are not tampered with by other mods that could lead to issues. You'll have to excuse the TextureReplacer node name (I'm on mobile an cannot edit it) but I previously suggested, elsewhere, a Module Manager config notation or something similar to allow for this directory pathing if you're looking for somewhere to start from. @TextureReplacer { Directories { Default = GameData/Custom EnvMap = GameData/Custom/CustomSubFolder } } Allowing for individual textures to be renamed and pointed towards the default texture names could also be very handy to allow for interopability but would be going above and beyond. i.e. DiRT/default/rockyMoon01.dds = MyCustomMod/default/texture.dds

@Cydonian Monk, would you possibly consider adding the ability to locate texture files elsewhere within the GameData directory and point them towards DiRT using Module Manager configs (akin to how TRR lets you do so but not TR). This would greatly increase the amount of interoperability/compatibility between mods that use may use DiRT without having to overwrite each other and causing issues down the like, especially in situations like installing through CKAN (as CKAN does not allow interactions between files/textures that already exist at the same location), I am looking for mods that can support my skyboxes going forward but would like to find one that will support CKAN installations through remote pathing outside of the main plugin's directory as stated above.

I already have it set up and working perfectly locally for some time but there is no good way to also implement TR support within the same download. Secondly CKAN doesn't handle mod dependencies that provide the same function very well, currently, there is no way for me to say pick either SR:S or TRR as the plugin provider. You can only list them all as dependencies or suggestions which doesn't really give a good solution in this case. I did bring this up on the CKAN thread and HebaruSan did confirm that CKAN doesn't support this kind of intelligent handling at this time and suggested I raise an issue about it on the CKAN Git repo but in all honesty, I couldn't really be bothered to go through all the rigmarole.

Sigma Replacements: Skybox still works fine in 1.4.5 but if you don't want to use that, you can do as Vaga has said above. I'm trying to come up with a way I can support SR:S, TRR and TR (Not heard of DIRT before) but unfortunately TR is holding back a way for me to do so in a non-egregious way that will work with CKAN and other skybox mods. It may just be some time before a good solution presents itself.

Unfortunately we cannot do this by editing the localization files to change the descriptions of the parts as the info module in the part selector that shows this info is determined by specific parts of KSP's code, ergo, it would require a new plugin mod to be written.

I recently noticed Astronomers Visual Pack used LSM for its loading screen textures, however, as they are .png and .jpg formats they take a long time for KSP/Unity to load and encode them to native .dds format for caching in the VRAM. Is there any scope for adding .dds file format support into LSM?

I can confirm this is the case with the following: KSP 1.4.5 Stock 165fps (monitor limit) KSP 1.4.5 + Kopernicus 1.4.5-4 80fps KSP 1.4.5 + Kopernicus 1.4.5-3 85fps KSP 1.4.5 + Kopernicus 1.4.5-2 165fps (monitor limit) KSP 1.4.5 + Kopernicus 1.4.5-4 w/ Orbit Icons Removed 165fps (monitor limit) I'll post it up as an issue on the Git repo. EDIT: Issue can be found here: https://github.com/Kopernicus/Kopernicus/issues/309

Well, quite honestly, that's your own issue. Community frameworks exist to vicariously help the community and EVOLVE to the betterment of the frameworks usage and effectiveness. Mods that use these frameworks have to evolve and adapt alongside them as to not hold them back. It seems like you have some work to do after this PR goes through so that your mod(s) adapts to the new framework. That's life. Recently in the Community Terrain Textures Pack we rearranged the directory structure to ensure that the textures took advantage of On Demand Loading with the side effect that it completely ruined all the mod configs out there that pointed to these textures. We issued a declaration that we were going to do it, mod makers that took notice changed their configs and everyone adapted to the changes. Would you say it was better that we haven't have done that because everyone was already ingrained within the previous framework boundaries? I don't like to provoke 'he-said-she-said' bickering or derailing the topic but I believe that the proposed changes are logical, provide ample scope for gameplay variation (as has been pointed out) and ultimately is a lot more coherent when it comes to resource allocation for new mod authors when it comes to utilizing this framework for their own mods. That's pretty much all I have to say on this particular matter so I will be refraining from posting about it further. Thanks to all involved who put forward discussion, it seems like a good positive move forward.

Well then that sounds like the obvious solution. So, @FreeThinker, if you required a resource abundance of 0.00005% but the lowest you can go is 0.001%. Just include that resource within its own harvester module and use an efficiency value of ( 0.00005 / 0.001 ) 0.05 for example to simulate the resource harvest rate you'd get with 0.00005% abundance.