Sigma88

generally speaking planet packs in kopernicus can get away with a bunch of errors and still load (the errors are still there, you just are not notified about them at startup) adding SD changes everything since it will make MM go crazy if it finds some errors in how the planets are defined this is actually a useful side-effect of SD, I managed to pinpoint a lot of bugs in RSS by just loading it with SD in this case I would guess there are problems with the cfgs of IAR which are found by SD when loading and notified by MM the solution would be for @ProtoJeb21 to take a look at those configs that have errors and try to understand why SD has problems with his mod If you manage to find that it's actually a SD issue I will fix everything I will also take a look when I get some free time, just to make sure it's not a SD issue, but I can't give you an ETA since I'm a bit busy in this period (easter and everything) EDIT: @garithmar could you please send me the mm cache as well? the one you get when you don't have SD installed thanks

Sorry?

Ok, so try asking them if this is an intended feature. If it is I can tell you how to change it. If it is not then I'll tell them how to fix it so in future other people wont have this issue

Depending of where your probe orbits eeloo it will either stay in the same orbit (if it is inside eeloo's SOI in OPM) or it will get its orbit messed up (if it is outside eeloo SOI in OPM) It's impossible to predict what will happen exactly

Are you using SSRSS? Or are you making your own rescaled RSS?

try asking on those mods' threads, I'd bet on EVE but I really have no way to know

ok

neither base Kopernicus nor OPM add rings to jool

you should probably report to the developer of the mod you are using

could this update cause issues with SASS?

no idea sometimes nesting HAS can cause issues, I never really nailed what the issue is, but if I were you I would always try to avoid doing that when possible EDIT: out of curiosity, try to use your previous patch, but using :FINAL instead of :Final

try this patch: @PART:FINAL { @MODULE[ModuleEnginesFX]:HAS[!PROPELLANT[Oxidizer],!PROPELLANT[IntakeAir]] { @PROPELLANT[LiquidFuel] { @name = LqdHydrogen @ratio = 1.0 } } }

Seems fine to me Do you have a mm cachefile and the full patch to take a look?

if I decide to add the mod to GN I will contact you to give you the opportunity to choose the type and name of the star unless your mod already has a custom star, in which case I should not need to bother you right now the bottleneck is my free time which is pretty limited so I am not sure what is the time frame, in the meantime if you already have ideas for star type and name please send me a pm

I could make a list of posts that explain how all the features work, but I probably won't add stuff to the settings cfg to keep it as simple as possible ultimately SD was never supposed to be a tool for users, it was intended to be a tool for modders who want to make resized systems. sadly, after I started SD those kind of mods fell into disuse (mostly) which is why people tend to consider SD a substitude for those mods here's a more detailed explanation of how atmoTopLayer works

it would be explicitly defined as in you use FOR for all the patches and they are executed in order usually I put all steps in the same "time frame" so that if someone wants to do something before or after my patch they can use BEFORE or AFTER but of course that's up to you

as long as you put them in the correct order you don't need a BEFORE

there should be 7 parts without oxidizer

actually I just tested this and it works with the syntax used by @linuxgurugamer I used this patch: TESTPART { TESTRESOURCE { testmaxamount = 5 } } @TESTPART { test = #$TESTRESOURCE/testmaxamount$ @test += #$TESTRESOURCE/testmaxamount$ } and this is the result UrlConfig { name = TESTPART type = TESTPART parentUrl = /test url = /test/TESTPART TESTPART { test = 10 TESTRESOURCE { testmaxamount = 5 } } } which means the only reason why MM would throw an error is that the part in question is missing Oxidizer linuxgurugamer are you sure all parts have oxidizer?

ah right, you forgot the @ in front of resource let me test this, I'm not sure

you don't check that the part has those resources so a possible error could come from the 2 origLFO lines not finding the resource they point at EDIT: and that's exactly what happened Line 10435: [ModuleManager] Error - Cannot parse variable search when editing key origLFO = #$RESOURCE[Oxidizer]/maxAmount$ Line 10443: [ModuleManager] Error - Cannot parse variable search when editing key origLFO = #$RESOURCE[Oxidizer]/maxAmount$ Line 10451: [ModuleManager] Error - Cannot parse variable search when editing key origLFO = #$RESOURCE[Oxidizer]/maxAmount$ Line 10479: [ModuleManager] Error - Cannot parse variable search when editing key origLFO = #$RESOURCE[Oxidizer]/maxAmount$ Line 10487: [ModuleManager] Error - Cannot parse variable search when editing key origLFO = #$RESOURCE[Oxidizer]/maxAmount$ Line 10499: [ModuleManager] Error - Cannot parse variable search when editing key origLFO = #$RESOURCE[Oxidizer]/maxAmount$ Line 10535: [ModuleManager] Error - Cannot parse variable search when editing key origLFO = #$RESOURCE[Oxidizer]/maxAmount$ I suggest using this patch: @PART[TPtank*|TPcone*|TPdome*]:FOR[FuelTanksPlus]:NEEDS[ModularFuelTanks] { origLFO = 0 } @PART:HAS[#origLFO[*],@RESOURCE[LiquidFuel]]:FOR[FuelTanksPlus]:NEEDS[ModularFuelTanks] { @origLFO += #$RESOURCE[LiquidFuel]/maxAmount$ } @PART:HAS[#origLFO[*],@RESOURCE[Oxidizer]]:FOR[FuelTanksPlus]:NEEDS[ModularFuelTanks] { @origLFO += #$RESOURCE[Oxidizer]/maxAmount$ } @PART:HAS[#origLFO[*]]:FOR[FuelTanksPlus]:NEEDS[ModularFuelTanks] { MODULE { name = ModuleFuelTanks volume = #$../origLFO$ type = Default } } this will assure you to target only those parts that have the resource you want but it will still vulnerable to error if those resources don't have a maxAmount variable if you want to be 100% covered you should add that as well: @PART[TPtank*|TPcone*|TPdome*]:FOR[FuelTanksPlus]:NEEDS[ModularFuelTanks] { origLFO = 0 } @PART:HAS[#origLFO[0],@RESOURCE[LiquidFuel]:HAS[#maxAmount[>0]]]:FOR[FuelTanksPlus]:NEEDS[ModularFuelTanks] { @origLFO += #$RESOURCE[LiquidFuel]:HAS[#maxAmount[>0]]/maxAmount$ } @PART:HAS[#origLFO[*],@RESOURCE[Oxidizer]:HAS[#maxAmount[>0]]]:FOR[FuelTanksPlus]:NEEDS[ModularFuelTanks] { @origLFO += #$RESOURCE[Oxidizer]:HAS[#maxAmount[>0]]/maxAmount$ } @PART:HAS[#origLFO[>-1]]:FOR[FuelTanksPlus]:NEEDS[ModularFuelTanks] { MODULE { name = ModuleFuelTanks volume = #$../origLFO$ type = Default } } as far as I can tell this last one should be 100% faultproof assuming you only want to process parts with maxAmount >= 0 if you want to exclude the case where origLFO = 0 then you should change the -1 at the end with a 0 (zero)

at this point there's not much I can do, the values you want are applied correctly, so if you believe they are not, it means it might be a kopernicus issue you should provide the logs and wait for @Thomas P. to have the time to look at them if you want to know which files to share click on the nyan cat in my sig

the kerbin one should work fine fadeStart = 60000 fadeEnd = 150000 deactivateAltitude = 200000 minLevel = 2 maxLevel = 6 minDetailDistance = 6 maxQuadLengthsPerFrame = 0.03 minLevel = 2 maxLevel = 6 minDetailDistance = 6 maxQuadLengthsPerFrame = 0.03 this is the content of your PQS node those values are those read by kopernicus

Gaia is not named Gaia it's named Kerbin and has cbNameLater = Gaia so you need to use @Body[Kerbin] plus you probably want to use %PQS { %minLevel = 1 %maxLevel = 4 } so that you are sure your changes are applied