Sigma88

Sigma Dimensions v0.8.1 Updated to the latest Kopernicus all the links are available in the OP If you want to follow the development of my mods: If you want to buy me a cup of coffee: This mod would not be possible without the work of: - sarbian (ModuleManager) - Thomas P. (Kopernicus) Changelog: v0.8.1 - Updated to Kopernicus 1.3.0-4

-

If you are using any of my mods, don't. I haven't had time to update them to the latest Kopernicus yet If you are not, send us some logs and we'll take a look (click the nyan cat in my sig for the list of files)

I assume from reading this that now biomes also have "displayName" If that's the case I doubt you can change that with kopernicus, I can take a look and make a PR when I have some time

Yup, haven't had time to update my mods to kopernicus 1.3.0-3 yet But I did post about it in my threads, if you check the forums abitually I suggest you keep an eye on those threads, it might save you from the hassle of having to look for bugs

then either the issue was outside of my knowledge of kopernicus and I left it to @Thomas P. or I just ignored it because there were too many mods / it was incomplete can't remember which one dude EDIT: now I remember, I think the issue was caused by an incompatibility between Kopernicus and Interstellar Extended this issue has been fixed in one of the last kopernicus releases (you are running Kopernicus 1.2.2-7 I think there are better options now) I can't remember in which patch this issue was addressed maybe @FreeThinker remembers EDIT2: Kopernicus 1.3.0-3 and 1.2.2-8 should have solved that specific issue

If you have an issue with kopernicus click on the nyan cat in my sig. Provide all the files required and we will take a look. Incomplete reports will be ignored. Overmodded reports will be ignored. If you want to provide a good bug report it has to be generated from an install with the minimum amount of mods that generate the issue. Since you are sure it's a kopernicus issue just stock ksp + kopernicus/mfi/mm should suffice

won't take long, but I'm at work now so I can't publish an update

Kopernicus 1.3.0-3 broke compatibility with SD/SB/GN/SASS please use 1.3.0-2 with my mods, or don't use my mods if you want to upgrade to latest kopernicus

Kopernicus 1.3.0-3 broke compatibility with SD/SB/GN/SASS please use 1.3.0-2 with my mods, or don't use my mods if you want to upgrade to latest kopernicus Kopernicus 1.3.0-3 broke compatibility with SD/SB/GN/SASS please use 1.3.0-2 with my mods, or don't use my mods if you want to upgrade to latest kopernicus

Kopernicus 1.3.0-3 broke compatibility with SD/SB/GN/SASS please use 1.3.0-2 with my mods, or don't use my mods if you want to upgrade to latest kopernicus

Kopernicus 1.3.0-3 broke compatibility with SD/SB/GN/SASS please use 1.3.0-2 with my mods, or don't use my mods if you want to upgrade to latest kopernicus

Try with kopernicus 1.3.0-3 (link on github)

yup

As long as you know the name of the texture you want to replace there should be no problem in doing so

now that I know MM and TRR can work together I'd like to propose a new syntax for TRR with this new syntax it will be possible to allow much better levels of customization, at at the little cost that old packs will need to add very minor changes to be compatible: THE FOLLOWING IS NOT IMPLEMENTED, IT'S JUST AN IDEA I AM CONSIDERING The config structure I have in mind looks something like this: TextureReplacerReplaced { Folders { Default = EnvMap = Heads = Suits = } ReplaceByName { Texture { name = newTexture = } } } the idea is that, the "Folders" node will contains a list of folders from which TRR loads the textures. so if your mod used to put head textures in the "TextureReplacer/Heads" folder, now you just need to move them into a custom folder (let's say KSPINSTALL/GameData/MyMod/MyTextures) and add a cfg with the following content: TextureReplacerReplaced { Folders { Heads = MyMod/MyTextures } } all the folders included into "MyTextures" will be loaded like they were put into the old "KSPINSTALL/GameData/TextureReplacer/Heads" if anyone has ideas please feel free to share them here so I can get a feel of what most TR(R) users might need

what kind of setup is this? I might take a look if it's possible to avoid those kinds of optical illusions

It's not guaranteed that they will, it's not guaranteed that they won't.

if two cfgs are in the same folder and use the same :BEFORE[] / :FOR[] / :AFTER[] then they will applied in alphabetical order the same works if they don't use any :BEFORE[] / :FOR[] / :AFTER[] (be careful that windows and linux use a different alphabetical order so try to use file names that are in the same order in both OS)

:BEFORE[] :AFTER[] :FOR[] whatever you want to call them

it's not possible, but if it's a situation like my mods, where more mods are in the same folder (in my case named Sigma) then it's very likely the mod author is using a :FOR[] tag somewhere to signal that his mod is installed. so, to check if the mod is installed you would need to use :NEEDS[] with inside the name used in the :FOR[] from the mod you want to check if is installed. for :AFTER[] and :BEFORE[] it doesn't matter what folder the mod is in, it matters what tags that mod is using so before you need to see when that mod applies its patches, and then you can choose what to put in your :BEFORE[] / :AFTER[] tags keep in mind that, when using the same :BEFORE[] / :AFTER[], the patches are applied following alphabetical order of the folders in gamedata

are you sure you can use this syntax? MODULE[MuMechModuleHullCameraZoom,1] I've never seen it used anywhere, does the manual mention it somewhere? EDIT: yes that's the problem, I told you before that it wasn't the correct syntax and I was right from the handbook: @MODULE[Example],1 { <...> } Looks for all the "Example" MODULES. Filters the second one and edits it. Note that this is a named MODULE, but this doesn't prevent you from filtering them by numbers. the use of that syntax is never shown in the "duplicate node" function, but if it works, I would assume it would follow the same syntax of the "edit node" function so I guess you need to use #$MODULE[MuMechModuleHullCameraZoom],1/cameraForward$

this should be possible, I'll add it to my todo list, which at the moment is pretty full

I know, but I thought it was a worthy addition... it wouldn't be the first time I see people using wrong syntax because they copied it from GN

@Astrofox Please don't copy stars from GN, they rely on custom stuff I do with my plugin so parts of the code might not be compatible with standard kopernicus