KvaNTy

@linuxgurugamerHi. I know you have many more mods to maintain, but I've made a fix to folder icons disappearing on every scene change. Pull request is on github. Take a look when you got time.

RO team is busy with upcoming release, so I'm making configs myself. And I come with questions Most of configs for simple parts are already done, some require more precise balancing. The only major thing left is RealFuels. I've been playing with your switching modules and US2 code and came up to these options: 1. MM Wizardry. For fuel-related parts we can add empty ModuleFuleTank, remove USFuelSwitch and use USModuleSwitch to change MFT's volume, also let USMassSwitch/USCostSwitch do their things. This should do the trick on parts that change only in height, but it wont be a clean solution for things like Hex and Octo which have additional modes. CLS-passable variant leave part with crew tube and tank with zero volume. Though planned monoprop and xenon modes could be regarded just at usual fuel, I guess. Or... you know, what if we switch between these three visual tank variants and also switch MFT tank type between Default, Cryogenic and ServiceModule? This will require yet another USSwitchControl+USModuleSwitch tho, which also shouldn't be visible when part has no tank. Is it even possible currently, I mean this conditional button behavior? Correct me if I'm wrong. As I understand USSwitchControl is just buttons, it doesn't know how many states there are, it just tells every other module with same SwitchID that button was pressed? And it's up them to act accordingly and keep track of current states. And if we have a bunch of modules listening to same SwitchID, but some of them have for example 5 possible states while other have 4, than pressing button long enough should cause them to "unsync", right? Also this is "Then rebalanced with other structure parts (see Universal Storage 2 Excel workbook)" being mentioned in all configs, but I can't seems to find it anywhere. 2. Out of the box RF support. Cleaner and more consistent option, but implies changes on US2 side. What I've tried so far: Added a couple of methods into USTools.cs to check and keep track of whether RealFuels is installed and whether part has ModuleFuleTank. Made USFuelSwitch.setupTankInPart() account for presence of RealFuels, and add new MFT if there is none, or change it's volume(wipes the content tho), or delete MFT module if we are in "Structural" mode. Testing showed that some numbers are a bit off but in general everything looks good. I think there is a way to make it add not just an empty tank of various sizes but also put intended resource in it, without changing current USFuelSwitch config structure too much. So what do you think would be a better way?

First of all US2 is simply amazing! Thank you for such a wonderful work! No, really, you guys are legends But I'm trying to figure out a way to make it work with RealismOverhaul. RO hes a bunch of configs for US1, but it doesn't look like there is a convenient way to just swap them, not even mentioning new parts. Am I missing something obvious? I wasn't sure where this question should be asked, here or in RO threads, decided to start with you.

Link is wrong. There you go Sketchfab

Reuse is not always an option. Especially in upcoming RO/RP-1. It is nice that this Energia is built also considering standalone usage. As long as it is able to lift actual Buran with 25-30t of his payload to LEO of cause.

@Li0n, oh thanks for dll. But the thing is that your previous 1.2.2 build doesn't have any of those issues. I've just double checked - no exceptions in ModuleBeaconLightEngine on entering VAB. Loos like it was somehow related to other problems with my local builds. Maybe the problem is only on my side, idk. Maybe something is just not right in my VS environment or in some settings.

So it goes like this: Last DEV build recompiled against 1.2.2. On First flight scene: On somewhere closer to sunset: Later on each scene change to VAB: Also noticed that after sunset CL turned on only stock and surface light but ignored 2 of 4 aviation lights for some strange reason. As for AGM, it looks usefull, thanks for the tip. But no chance it can be easily backported to 1.2.2. UPD: Damn, those two not working AL lights were beacons. So basically everything seems to be working as it should. The only thing is that light error spam.

@Li0n Thank you, now everything works like a charm! And logs are clear. And I confirm lights turning on after sunset. Actually that could be my bad - I forgot that all those light are added to default action group. Once I removed them from AG CrewLight began to do its magic with all stock, aviation lights and surface lights. Can you show content of your actual working CrewLight.csproj? So we, or someone who might be reading this topic later, could figure out what was the problem?

Hello @Li0n, I need your help. I'm Trying to make last builds of CrewLight work on 1.2.2, particularly for AviationLights and Ven's Revamp support, but nothing seems to be working. First of all: Released 1.9 loads normally and does it's job but when I switch to vessel I get TypeLoadException in logs(full trace in spoiler). 1.9 recompiled with 1.2.2 libraries works but shows the same exception. Released 1.5 works as intended. No exceptions. Recompiled 1.5(without any changes in code) shows the same exception anyway. Error in question: Which makes me think I'm doing something wrong with rebuilding. But the thing is that I've took your project from guthub as is, just fixed .cs file path and reference issues and built it. And it still shows that exception. Am I missing something? Btw, why was ModuleBeaconLightEngine.cs never included in CrewLight.csproj? And second: Looks like SunLight logic ain't doing well. Not only due to that LightDirector.SunLightAddVessel(Vessel) issue, but even on released 1.5 build tested on stock 1.2.2 KSP setup. I saw no exceptions in logs, light switching worked good, but when I warped till sunset lights did not turn on. I guess they just blinked for a moment at some point, but it is hard to notice during warp. I used stock lights and some parts from surface lights mod. Again, nothing related was found in logs.

Yep, looks like taking earlier revision solved the issue. So looks like the only thing making CL incompatible with earlier KSP builds are KSP.Localization references. Took me some time to fix MM configs for Mark3-9 pod from pre-1.3.0 version of VenStockRevamp(it had different model and part name) and to make it work well with RO rescaling. Ended up with such universal config: Still having some buoyancy issues with stock Mark1-2 pod. It kinda works on its own, and even CL does it's job. But with RO Mk1-2 suddenly gets buoyancy of a solid brick, no matter with CL or without. Actually CL goes crazy as soon as pod starts to sink, repeats this exception over and over again: Can't yet figure out what exactly in RO makes it sink like that.

@Icecovery thanks for such a nice mod! Especially for it's built-in functionality so we don't have to add another bunch of strictly situational parts to our already monstrous part packs. First things first: Is there a way to make it comparable with KSP 1.2.2? I've removed all "using KSP.Localization;" references throughout the code and recompiled it for 1.2.2 to make it at least load correctly but nothing happens during descent anyway. I'm getting this in logs: And second: I can't seem to find if those retro rockets are just eye-candy thing or do they actually do stuff?

The problem is that yours target audience, people who like more realism in ksp, can't use it with their must-have mods. Like Realism Overhaul for example. Sure it makes ksp more realistic, somewhat middleway between stock and RO/RSS, but I hope you'll consider making it more compatible with what other people already done on this. And after all, it's much easier to tell your program not to do something in certain conditions than to program that "something" in the first place.

You know, it would be awesome to have an option to leave life support on TAC, malfunctions to DangIt/Entropy and communications to RemoteTech. I really like the idea of radiation, space weather and that quality of life stuff, but sacrificing mods above for less realistic analogs would be somewhat cheaty.

Tried precisely the same in the beginning of month, but got lost digging current FAR's mechanic. Finally, thank you! Let's all hope that FAR wont mess with public API any more.

Check this out.