Lechrenski

Alright, I'm trying this out now. I still get the message that Kopernicus requires terrain settings ultra when I try to change it, but if I understand you, that's just because it's saying it wants the highest usable settings, so no worries there. Logs look a lot cleaner and performance seems to have vastly improved. Thank you! I'll keep "testing", but it looks like this is working so far!

Not a problem. It just seemed this was the sort of forward compatibility issue that might have a solution. I didn't mean to be a pain.

I didn't realize this was a bug. I thought it was expected behaviour that I'd just have to work around. OK, give me a bit of time and I will compile the very latest, launch the game, and post the logs.

So I, too, tried compiling Kopernicus against 1.9 and gave it a shot using JNSQ. Aside from scattering doing weird things like causing the oceans to disappear, the game "works". However, Kopernicus seems to want to force on the "ultra" terrain shaders, which causes the logs to be spamed with messages of the form: Material doesn't have a texture property '_NormalTex' Material doesn't have a texture property '_AtlasTex' and there is a pretty extreme performance penalty, especially when switching scenes, both of which I assume it are due to JNSQ not being ready for the ultra shader yet. Therefore, my question is: is there a way to force Kopernicus to just play nice and use the "high" shader setting instead of overriding my choices in the graphics options?

Yeah, I'm running 1.6.1, and I only tried installing SVT after I updated, so that's probably it. I'll see about playing around with it some more later, but I've already spent a few hours figuring out what else does/doesn't work, so I'm a bit exhausted of that for the time being. Thanks again!

Huh. Then I guess I have more experimenting to do to figure out what is causes the problem. Thanks for the reply.

@Galileo do you think you could put a warning not to use this terrain pack with the Community Terrain Texture Pack (and/or have CKAN flag them as incompatible)? I had OPM installed, which I had forgotten has CTTP as a dependency, and was briefly confused about my terrain disappearing. I understand that you emphasize in the OP that his is for stock and all, but SVE works so...

From my KSP.log [LOG 22:40:49.465] [INFO] ContractConfigurator.ContractConfigurator: Loading CONTRACT_GROUP: 'CareerEvolution' [WRN 22:40:49.467] ContractConfigurator.ContractConfigurator: Multiple assemblies with name 'ContractConfigurator' found! [WRN 22:40:49.609] ContractConfigurator.ContractGroup: CONTRACT_GROUP 'EarlySpaceProgram': No minVersion or older minVersion provided. It is recommended that the minVersion is set to at least 1.15.0 to turn important warnings for deprecated functionality into errors. [WRN 22:40:49.610] ContractConfigurator.ContractGroup: CONTRACT_GROUP 'Satellites': No minVersion or older minVersion provided. It is recommended that the minVersion is set to at least 1.15.0 to turn important warnings for deprecated functionality into errors. [WRN 22:40:49.612] ContractConfigurator.ContractGroup: CONTRACT_GROUP 'MinmusExploration': No minVersion or older minVersion provided. It is recommended that the minVersion is set to at least 1.15.0 to turn important warnings for deprecated functionality into errors. [WRN 22:40:49.613] ContractConfigurator.ContractGroup: CONTRACT_GROUP 'MoonExploration': No minVersion or older minVersion provided. It is recommended that the minVersion is set to at least 1.15.0 to turn important warnings for deprecated functionality into errors. [WRN 22:40:49.614] ContractConfigurator.ContractGroup: CONTRACT_GROUP 'CrewedMilestones': No minVersion or older minVersion provided. It is recommended that the minVersion is set to at least 1.15.0 to turn important warnings for deprecated functionality into errors. [WRN 22:40:49.616] ContractConfigurator.ContractGroup: CONTRACT_GROUP 'UncrewedFlybys': No minVersion or older minVersion provided. It is recommended that the minVersion is set to at least 1.15.0 to turn important warnings for deprecated functionality into errors. [WRN 22:40:49.617] ContractConfigurator.ContractGroup: CONTRACT_GROUP 'UncrewedOrbits': No minVersion or older minVersion provided. It is recommended that the minVersion is set to at least 1.15.0 to turn important warnings for deprecated functionality into errors. [WRN 22:40:49.618] ContractConfigurator.ContractGroup: CONTRACT_GROUP 'UncrewedLanding': No minVersion or older minVersion provided. It is recommended that the minVersion is set to at least 1.15.0 to turn important warnings for deprecated functionality into errors. [WRN 22:40:49.619] ContractConfigurator.ContractGroup: CONTRACT_GROUP 'Rovers': No minVersion or older minVersion provided. It is recommended that the minVersion is set to at least 1.15.0 to turn important warnings for deprecated functionality into errors. [WRN 22:40:49.621] ContractConfigurator.ContractGroup: CONTRACT_GROUP 'SpaceStations': No minVersion or older minVersion provided. It is recommended that the minVersion is set to at least 1.15.0 to turn important warnings for deprecated functionality into errors. [WRN 22:40:49.622] ContractConfigurator.ContractGroup: CONTRACT_GROUP 'CrewedFlybys': No minVersion or older minVersion provided. It is recommended that the minVersion is set to at least 1.15.0 to turn important warnings for deprecated functionality into errors. [WRN 22:40:49.623] ContractConfigurator.ContractGroup: CONTRACT_GROUP 'CrewedLanding': No minVersion or older minVersion provided. It is recommended that the minVersion is set to at least 1.15.0 to turn important warnings for deprecated functionality into errors. [WRN 22:40:49.624] ContractConfigurator.ContractGroup: CONTRACT_GROUP 'SurfaceBases': No minVersion or older minVersion provided. It is recommended that the minVersion is set to at least 1.15.0 to turn important warnings for deprecated functionality into errors. I'm sure that's not as dire as it sounds (things seem to work mostly fine, at least), but it's probably worth considering.

Well, I have some bad news and some good news: The bad news is that the ModuleManger devs have finally broken out the +1 Vorpal sword and started enforcing the Highlander rules on the behavior of BEFORE, FOR, and AFTER passes for patches. Now there really can be only one... and that has completely broken HPTechTree's mod support. The good news is that the fix is relatively straightforward -- I was able to restore expected behavior by replacing every instance of :NEEDS[modname]:AFTER[modname]:FOR[ZZZZZHPTECHTREE] with either :NEEDS[modname]:FOR[ZZZZZHPTECHTREE] or just :AFTER[modname] in the mod support cfg's. Ah, and as a bonus, it turns out the reason the greenhouses keep showing up in the Survivability node when USI-LS is installed is that RoverDude changed the names of them in their PART files. @PART[Fert_Tank_250,Fert_Tank_375,FertilizerMiniPack,Fert_Tank_125,USILS_Greenhouse_Cupola,USILS_Greenhouse_MiniCupola,USILS_Greenhouse_Inline,MulchMiniPack,USILS_Recycler,USILS_LgRecycler]:NEEDS[USILifeSupport]:FOR[ZZZZZHPTECHTREE] { @TechRequired = ModernCrewSupport } seems to fix that.

Now I think I'm understanding this less. Wouldn't :NEEDS[SETIrebalancet]:AFTER[TacLifeSupport] (or :NEEDS[TacLifeSupport]:AFTER[SETIRebalance], assuming SETIRebalance is already using an AFTER instead of a FOR) be better, since it still forces the check for both mods (instead of abandoning the check for SETIrebalance) while still patching in the correct order? From reading the wiki, I was under the impression that BEFORE, FOR, or AFTER tacitly imply NEEDS, since the patch wouldn't be applied if the [modname] after them does not exist. Man, it's stuff like this that really makes me with I got around to taking that formal logic class in college...

Ah. I'm currently playing my first game with CLS, so I thought there might be a reason. I'm not sure such a small thing makes sense for me to set up Git for since I don't (yet) mod. However, here is the updated patch to fix all of the parts that I've encountered so-far in my career run: @PART[bigbyFairing,WBI_BigbyDecoupler,WBI_OMSKit2,WBI_SolarBatteryModule,WBILDEFTrippleRack,WBILDEFDoubleRack,WBILDEFRack,WBIMOLEServiceBay,WBI_Backseat2,WBI_MK85HeatShield,WBI_WB400,WBI_FCP,WBI_SD18,WBI_SD25,WBI_TitanInstrumentUnit,WBI_Adapter,WBI_Coach225,WBI_Coach300,WBI_Coach500,WBI_Brumby,WBI_StationHub2,WBI_Mk1DockingPort,WBI_DR18,WBI_S18Separator,WBI_S25Separator,WBI_fairingSize18,fairingSize3,WBI_PowerModule,WBI_AirlockModule,WBI_MK2-5HeatShield,WBI_BigCrewModule,WBI_ShortInterstageAdapter2,WBI_InterstageAdapter,WBI_InterstageAdapter25,WBI_InterstageAdapter375,WBI_MK85ISC3,WBI_WB700,WBI_MOH18,WBI_MOBL18,WBI_Mole182,WBI_MOLEDrydock,WBI_Mk375Drydock,WBI_BatteryModule,WBI_BOW,WBI_LargeSAS,WBI_OMSKit2,WBI_SlantedAdapter]:HAS[!MODULE[ModuleConnectedLivingSpace]]:NEEDS[ConnectedLivingSpace] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[WBI_Mk1RadialDockingPort,WBI_Mk2DockingPort,WBI_DR18]:HAS[!MODULE[ModuleConnectedLivingSpace]]:NEEDS[ConnectedLivingSpace] { MODULE { name = ModuleConnectedLivingSpace passable = true passableWhenSurfaceAttached = true } } If I come across more things, though, I'll start making pull requests. I also have USI Life Support installed in this run, so that might be my next compatibility target...

Just out of curiosity, I was wondering what the rational was to have WBI_Mk1DockingPort have CLS support while WBI_Mk2DockingPort does not? I've noticed a few other pieces that seem to be missing CLS where I would have expected it, but that is the one that really confuses me.

oh, gosh, I'm being silly. I got it: in the 10.625x scaled one, I think the dayLengthMultiplier needs to = 4 instead of = 2. That seems to fix it. I miscounted; it was 2 days per "day", not 4.

Thanks for the advice, and thanks for making these cfgs! I was using Kerbal 10x last time I played about a year ago, but it looks like that hasn't been updated in a while. However, I do have a question about the time issue. I have Kronometer installed, but Kerbin still seems to be rotating way too fast -- about 1/4 rotation in about 1.5 h, and thus about 4 Kerbolrises/Kerbolsets per 24 hour (according to the ingame clock) "day". Is there something I'm doing wrong here?