Sigma88

there's a comment in the PR with an example it uses the same syntax used by TR, the only difference is that now you can use MM patch to change the content of the cfg files instead of having to manually edit them https://github.com/HaArLiNsH/TextureReplacerReplaced/pull/1#issuecomment-307576093

just to be clear, MM is not really needed to load textures from other folders. TR already supports that. the only issue being that the cfgs used to tell TR which folders look into cannot be edited via mm, they need to be written correctly in the file (and with my PR, that issue has been fixed as well - meaning that now you can even edit the cfgs using mm)

derp, now I see what was wrong with your cfg you forgot to add the ../ @PART[aerocam|aerocam180] { MODULE { name = cccam speed = 0 cameraForward = #$../MODULE[MuMechModuleHullCameraZoom,0]/cameraForward$ cameraUp = #$../MODULE[MuMechModuleHullCameraZoom,0]/cameraUp$ cameraPosition = #$../MODULE[MuMechModuleHullCameraZoom,0]/cameraPosition$ } } this should work

@linuxgurugamer that's very weird syntax, I had no idea MM could do that out of curiosity, why don't you just copy the whole node since the keys you want have the same name?

,0 is what is causing your issue "MODULE[MuMechModuleHullCameraZoom]" will automatically pick the first, so you don't need to worry about it

anyone interested in more MM compatibility for TR this discussion might interest you

the bug is not very consistent, sometimes it shows up and sometimes it doesn't I haven't been able to really understand what's going on, I remember posting about this in the past, but I can't find where right now

no renaming a node changes the name of the node but it breaks the functionality of targetting the node using "@NODE[XXXXX]" as I explained there are 2 way around this: either you target the node using "@NODE:HAS[#name[XXXXX]]" or you duplicate the node first (changing the name in the process), then you delete the old node so you avoid having duplicates

I would suggest you start your own thread so you can handle things easier (but it's not 100% required) also I have managed to add MM support, it was so easy that I wonder why nobody ever bothered honestly, I am still testing but all things seems to look good. I'm sending you a PR right now

// we remove those first, but just after Squad parts are loaded /// should you encounter a mod, which changes properties and fuels of MK1 parts, /// please add ":BEFORE[xxxx]" just after "[Squad]" below, working all the way down to the end, /// with xxx being directory name of the mod. /// for example: -PART[mk1pod] --> -PART[mk1pod]:BEFORE[FuelChanger] /// this will cause replacer do the job before the said mod touches the parts. -PART[mk1pod]:FOR[PartOverhauls] {} -PART[liquidEngine3]:FOR[PartOverhauls] {} -PART[liquidEngine]:FOR[PartOverhauls] {} -PART[liquidEngine2]:FOR[PartOverhauls] {} -PART[fuelTankSmallFlat]:FOR[PartOverhauls] {} -PART[fuelTankSmall]:FOR[PartOverhauls] {} -PART[fuelTank]:FOR[PartOverhauls] {} -PART[fuelTank_long]:FOR[PartOverhauls] {} // then we create newer parts with older part names. // precise names were tested against ksp wiki. +PART[fuelTank100]:FOR[PartOverhauls] { @name = fuelTankSmallFlat } +PART[fuelTank200]:FOR[PartOverhauls] { @name = fuelTankSmall } +PART[fuelTank400]:FOR[PartOverhauls] { @name = fuelTank } +PART[fuelTank800]:FOR[PartOverhauls] { @name = fuelTank_long } +PART[mk1podNew]:FOR[PartOverhauls] { @name = mk1pod } +PART[liquidEngineT45]:FOR[PartOverhauls] { @name = liquidEngine2 } +PART[liquidEngineT30]:FOR[PartOverhauls] { @name = liquidEngine } +PART[liquidEngine909]:FOR[PartOverhauls] { @name = liquidEngine3 } // then we delete parts with the new names -PART[fuelTank100]:FOR[PartOverhauls] {} -PART[fuelTank200]:FOR[PartOverhauls] {} -PART[fuelTank400]:FOR[PartOverhauls] {} -PART[fuelTank800]:FOR[PartOverhauls] {} -PART[mk1podNew]:FOR[PartOverhauls] {} -PART[liquidEngineT45]:FOR[PartOverhauls] {} -PART[liquidEngineT30]:FOR[PartOverhauls] {} -PART[liquidEngine909]:FOR[PartOverhauls] {} @PART[liquidEngine]:AFTER[PartOverhauls] { @entryCost = 3200 @cost = 1100 @MODULE[ModuleEngines] { @maxThrust = 240 -UPGRADES {} -atmosphereCurve {} atmosphereCurve { key = 0 310 key = 1 265 key = 7 0.001 } } } @PART[liquidEngine2]:AFTER[PartOverhauls] { @MODULE[ModuleEngines] { @maxThrust = 215 -UPGRADES {} -atmosphereCurve {} atmosphereCurve { key = 0 320 key = 1 250 key = 6 0.001 } } } @PART[liquidEngine3]:AFTER[PartOverhauls] { @entryCost = 1600 @cost = 390 @MODULE[ModuleEngines] { @maxThrust = 60 -UPGRADES {} -atmosphereCurve {} atmosphereCurve { key = 0 345 key = 1 85 key = 3 0.001 } } // -RESOURCE[LiquidFuel] {} // -RESOURCE[Oxidizer] {} } // Remove any engine upgrades @PART[*]:AFTER[PartOverhauls] { @MODULE[ModuleEngines] { -UPGRADES {} } } // Rename part variants @PART[liquidEngineT15]{ @title = LV-T15-A "Valiant" Liquid Fuel Engine } @PART[liquidEngineT15_Boattail]{ @title = LV-T15-B "Valiant" Liquid Fuel Engine } @PART[liquidEngine]:FINAL{ @title = LV-T30-A "Reliant" Liquid Fuel Engine } @PART[liquidEngineT30_Boattail]{ @title = LV-T30-B "Reliant" Liquid Fuel Engine } @PART[liquidEngine2]{ @title = LV-T45-A "Swivel" Liquid Fuel Engine } @PART[liquidEngineT45_Boat]{ @title = LV-T45-B "Swivel" Liquid Fuel Engine } @PART[liquidEngine303]{ @title = LV-303-A "Pug" Liquid Fuel Engine } @PART[liquidEngine303_Boattail]{ @title = LV-303-B "Pug" Liquid Fuel Engine } @PART[liquidEngine3]{ @title = LV-909-A "Terrier" Liquid Fuel Engine } @PART[liquidEngine909_Boattail]{ @title = LV-909-B "Terrier" Liquid Fuel Engine } // Add testing contracts to overhauled parts //@PART[liquidEngineT15,liquidEngineT15_Boattail,liquidEngine,liquidEngineT30_Boattail,liquidEngine2,liquidEngineT45_Boat,liquidEngine303,liquidEngine303_Boattail,liquidEngine3,liquidEngine909_Boattail]:HAS[!MODULE[ModuleTestSubject]] @PART[liquidEngine*]:HAS[!MODULE[ModuleTestSubject]] { MODULE { name = ModuleTestSubject useStaging = True useEvent = True situationMask = 127 CONSTRAINT { type = REPEATABILITY value = ALWAYS prestige = Trivial } CONSTRAINT { type = REPEATABILITY value = BODYANDSITUATION prestige = Significant } CONSTRAINT { type = REPEATABILITY value = ONCEPERPART prestige = Exceptional } CONSTRAINT { type = ALTITUDEENV test = GT value = 4000 prestige = Trivial } CONSTRAINT { type = ALTITUDEENV test = LT value = 8000 prestige = Trivial } CONSTRAINT { type = ALTITUDEENV test = GT value = 2000 prestige = Significant } CONSTRAINT { type = ALTITUDEENV test = LT value = 4000 prestige = Significant } CONSTRAINT { type = ALTITUDEENV test = GT value = 1000 prestige = Exceptional } CONSTRAINT { type = ALTITUDEENV test = LT value = 2000 prestige = Exceptional } CONSTRAINT { type = ALTITUDE test = GT value = 0 // this just registers altitude as something to care about situationMask = 8 } CONSTRAINT { type = ALTITUDE test = LT value = 300000 situationMask = 16 body = _NotSun } CONSTRAINT { type = ALTITUDE test = LT value = 600000 situationMask = 32 body = _NotSun } CONSTRAINT { type = SPEED test = GT value = 0 situationMask = 8 prestige = Trivial } CONSTRAINT { type = SPEED test = LT value = 600 situationMask = 8 prestige = Trivial } CONSTRAINT { type = SPEED test = GT value = 300 situationMask = 8 prestige = Significant } CONSTRAINT { type = SPEED test = LT value = 1200 situationMask = 8 prestige = Significant } CONSTRAINT { type = SPEED test = GT value = 600 situationMask = 8 prestige = Exceptional } CONSTRAINT { type = SPEED test = LT value = 2500 situationMask = 8 prestige = Exceptional } CONSTRAINT { type = SPEEDENV test = LT value = 200 prestige = Trivial } CONSTRAINT { type = SPEEDENV test = GT value = 100 prestige = Trivial } CONSTRAINT { type = SPEEDENV test = LT value = 100 prestige = Significant } CONSTRAINT { type = SPEEDENV test = GT value = 50 prestige = Significant } CONSTRAINT { type = SPEEDENV test = LT value = 50 prestige = Exceptional } CONSTRAINT { type = SPEEDENV test = GT value = 20 prestige = Exceptional } } } this should work. alternatively, why not apply the changes first, and change the names later? that would seem the most efficient option

from your previous message seems like the issues are solved. if you have more issues I'll need you tell me what those are and load only the mods that are strictly required to debug the issue, I can't test anything on an install with that many mods

@KerbMav there are a certain number of errors / incorrect stuff in those cfgs, let's go through one by one: when you have multiple tags (:BEFORE :FOR :AFTER) the cfg will be run when the first one triggers. so ":AFTER[Squad]:FOR[PartOverhauls]" will run only once at ":FOR[PartOverhauls]" also, this is not needed, configs without any tag will run at the start, which means you can delete those parts by just doing: -PART[mk1pod] {} -PART[liquidEngine] {} of course, :FOR[PartOverhauls] will also create a new "mod" definition called "PartOverhauls" if that's not already existent. so you need to keep that in mind if you need it. here I am confused by what you want to do, you put the ":AFTER[Squad]" tag so I suppose you want your cfg to run at that point, but then you say that the following patch, which has only :AFTER[PartOverhauls], should run after but actually it shouldn't. because "PartOverhauls" comes before "Squad" in the alphabet. but, as discussed earlier, your first patches will run at ":FOR[PartOverhauls]" regardless of the ":AFTER[Squad]" (which is completely pointless there) so actually in the end you patches end up running in the order you say you want. regarding the name issue, this is a very old issue I noticed a lot of time ago, when you rename a NODE you can't then use the syntax NODE[name] to target it what you need to do is using the :HAS[] check so something like this: @PART:HAS[#name[mk1podNew]]:AFTER[PartOverhauls] {stuff happens} alternatively: there is a chance that you might be forced to use the syntax NODE[name] instead of the NODE:HAS[#name[name]] if you are forced to do that (for whatever reason) then the solution would be to duplicate the stock part, changing it's name and the delete the original one. like this: +PART[mk1podNew]:FOR[PartOverhauls] { @name = mk1pod } -PART[mk1podNew]:FOR[PartOverhauls] {} +PART[liquidEngineT30]:FOR[PartOverhauls] { @name = liquidEngine } -PART[liquidEngineT30]:FOR[PartOverhauls] {}

SD only affects bodies that have their SOI defined in the cfg. for all other planets KSP automatically calculates the SOI using the approximated formula SOI = a*(m/M)^0.4 not sure what you mean by "only increased kerbin and jool" as explained in the README (linked in the OP) CustomSoISize is disabled by default (set to zero) when disabled SD will multiply the SOI of the planet by it's Rescale parameter when enabled, SD will multiply the SOI of the planet by the CustomSoISize value Again, this will only affect planets that have the SOI defined in the cfg so, assuming your planets have the SOI defined, and have CustomSoISize = 1, the SOI should not change if your planets don't have any SOI defined, it will be calculated by KSP, so that's outside SD control. if you want a specific SOI you need to set that in the cfg and account for the modifications that SD will apply I'll need you to post a more detailed bug report for this. click on my nyan cat and upload here the files I ask rings are scaling with "Rescale" on purpose to be consistent with orbits of moons, if you want them to be rescaled by a different number just use CustomRingSize

I agree about TR needing MM support, and that's one of the major points I wanted to discuss with @HaArLiNsH But for your issue in the meantime you can write a cfg to tell TR to load your textures from a custom folder. The only issue is that the cfg needs to be complete. You cannot edit it using mm. But that should be enough for you for now

This is not a good idea, and it will not keep things orderly. I just creates chaos. Installing multiple packs in the same folder means that if you want to uninstall a single one you need to hunt down the single files. Or uninstall all packs and make new install. To be honest I would propose to make TR completely ignore it's own folder, forcing people to choose another one. But since I know the kind of complaining this forum would come up with I just proposed to start recommending it for now.

Something I always had issues with TR is the fact that most packs store textures in the TR folder. This is a nightmare for installs / uninstalls as merging folders might be easier but unmerging them is a pain Since you are starting a new version I'd like to see some changes in this department, maybe not break compatibility but at least strongly suggest people start moving their suff out of the mod folder and into their own folder I also have other ideas but those can be discussed another time I can also give a little help with the code if it is necessary, I'm self taught as well, but maybe I have just stumbled upon some issues that you will have and figured out the solution

officially? no unofficially? it might, if you feel wild, bakcup you saves and try, worst case scenario you roll back and wait for the devs to put up an update also, in case it doesn't work, keep in mind that the devs didn't update it yet before posting complaints here

Mega is fine As soon as we get some time to look at your issue we'll ping you here

if you click on the nyan cat in my sig it will bring you to a list of files we need to help you

could you define randomly?

Again, the logs will say why the errors occur. Since you don't post them the only thing left is to take wild guess. So, the Part is missing a value named mass?

you are missing a texture, probably a heightmap or something like that and by missing, it means either the texture is not where it is supposed to be, or you put the wrong name in the cfg

all releases are always available on github just click on "releases"

the logs will tell you why the error is occurring

that's not currently possible as far as I know