Sovetskysoyuz

Is it possible to use ModuleManager to modify the definitions of RPM Custom/Math/Select Variables that are created by another mod? I'm trying to patch the ASET props to understand LqdHydrogen (from Cryogenic Rockets) as a fuel. I've figured out how to make new custom variables that add the amounts of LF and LH, but I can't figure out how to patch the variables that are already defined as part of the ASET props. For example, ASET has a Custom Variable to determine whether total fuel is below 10%, which various ASET props then reference (Low Fuel warning lamps, and parts of fuel indicator gauges that turn red when fuel is low): RPM_CUSTOM_VARIABLE { name = ALCOR_LOWFUELSTAGE_ON operator = AND SOURCE_VARIABLE { name = SYSR_LIQUIDFUELSTAGEPERCENT range = 0.01, 0.1 } SOURCE_VARIABLE { name = CUSTOM_ALCOR_POWEROFF range = -0.1, 0.1 } } I thought that I would be able to patch this with: @RPM_CUSTOM_VARIABLE[ALCOR_LOWFUELSTAGE_ON]:NEEDS[CryoTanks]:AFTER[ASET] { !SOURCE_VARIABLE[SYSR_LIQUIDFUELSTAGEPERCENT] SOURCE_VARIABLE { name = MATH_MULTIFUELSTAGEPERCENT range = 0.01, 0.1 } } where MATH_MULTIFUELSTAGEPERCENT is my new variable that calculates the percentage of LF and LH together left in the stage, but the patch doesn't seem to have taken effect - props that use CUSTOM_ALCOR_LOWFUELSTAGE_ON still only activate when LF is below 10%, and don't do anything on LH rockets. I'm assuming that this is the correct thread for this question, since this is (as far as I can tell) a question of how to modify RPM props generally, not something specific to the ASET props. Am I just making some kind of error, or are these kinds of variable out of ModuleManager's reach? If it's the latter, I assume I'll have to create my own variables and have the props reference them. EDIT: I wound up finding that this patch works, and it's more efficient than what I was trying originally so I'll stick with it: @RPM_CUSTOM_VARIABLE[ALCOR_LOWFUELSTAGE_ON]:HAS[@SOURCE_VARIABLE[SYSR_LIQUIDFUELSTAGEPERCENT]]:NEEDS[CryoTanks]:AFTER[ASET] { @SOURCE_VARIABLE[SYSR_LIQUIDFUELSTAGEPERCENT] { @name = MATH_MULTIFUELSTAGEPERCENT } } I don't fully understand why the HAS statement is necessary, since there's only one RPM_CUSTOM_VARIABLE with that name, but it only works with the HAS statement.

Agreed; if this mod had such a feature, I wouldn't need Fusebox anymore for working out whether my SCANSat probes have enough battery life to make it through their time in eclipse.

Is that this bug perhaps? Are you playing KSP 1.11?

AFAIK KSP physics use the rounded-off 9.81, so that is the appropriate value.

I tried the workaround ModuleManager patch that you posted, but it didn't seem to have an effect in-game for me. Directly modifying Physics.cfg did the job though.

It's not working for me on 1.11 - could be incompatibility with other mods, but I'd be really surprised that a 1.7 graphics mod would work on later versions given the Unity upgrade that happened in 1.8.

ASET IVA for Making History Pods does exactly what the name says!

They are working well together for me.

I'm having trouble getting the "send the first probe to another planet" contract to be offered. All of the requirements say "Met", but it stays grayed out in the menu. Any idea what could be preventing it from coming up? I haven't visited any other planets in this career, but I have already accepted an "Explore Duna" contract. Could this be the cause?

Update: I also found that the SVT textures actually do show up when I fly to e.g. the Mun, but they still don't show up in the Map view., and they fade back to the stock texture if I zoom out really far. My ksp.log has lots of this repeating in it: [LOG 11:15:04.931] [OD] <--- ScaledSpaceDemand.UnloadTextures destroying NewMunSurfaceMap00 and NewMunSurfaceMap01 [LOG 11:15:05.796] [OD] --> ScaledSpaceDemand.LoadTextures loading NewMunSurfaceMap00 and NewMunSurfaceMap01 Is this possibly related to the Kopernicus load-on-demand settings, or some sort of memory management?

I'm having compatibility trouble with OPM: with OPM installed, the SVT textures don't show up for any stock bodies. KSP.log with no OPM installed KSP.log with OPM installed (I used a regex to remove the [LOG], [WRN], and similar timestamps to facilitate comparing the two logs) I did notice that, when going into the Tracking Centre, there's a difference in how the stock bodies' textures are referenced: without OPM, it's [OD] --> ScaledSpaceDemand.LoadTextures loading SVT/textures/PluginData/NewMunSurfaceMapDiffuse.dds and NewMunSurfaceMapNormals [OD] --> ScaledSpaceDemand.LoadTextures loading SVT/textures/PluginData/KerbinScaledSpace300.dds and KerbinScaledSpace401 With OPM, it becomes [OD] --> ScaledSpaceDemand.LoadTextures loading NewMunSurfaceMapDiffuse and NewMunSurfaceMapNormals [OD] --> ScaledSpaceDemand.LoadTextures loading KerbinScaledSpace300 and KerbinScaledSpace401 I also found that installing Scatterer fixes the problem; unfortunately, it also makes the game lag too much on my computer, so I can't keep it. OPMVO doesn't seem to help.

Installing this update on my (modded) KSP setup caused it to fail to load any parts other than struts and fuel lines; KSP.log is full of errors like this: [LOG 21:43:53.497] PartLoader: Compiling Part 'ASET/ALCOR_LanderCapsule/Part/ALCOR/ALCOR_LanderCapsule' [ERR 21:43:53.502] PartCompiler: Cannot find Part of type 'PartTapIn' [ERR 21:43:53.502] PartCompiler: Error parsing config [ERR 21:43:53.502] PartCompiler: Cannot compile part This repeats for every part in my GameData. Reverting to 0.1.6.3 cures the issue. I haven't yet tried to diagnose whether it's a mod incompatibility issue.

I believe I've fixed the issue. I was causing it. The chain of events was: Due to my unfamiliarity with Unity, I was editing the IVA cfg file in SquadExpansion/Spaces, rather than a dummy file that I could copy into a ModuleManager cfg When I then created a new cfg file to act as the ModuleManager patch and add the RasterPropModuleComputer module, I didn't realize that Windows was appending a .txt extension after the .cfg that I had typed. This prevented ModuleManager from loading the file. Because the cfg wasn't getting loaded, the game was just loading the stock cfg file that I'd been editing. The RasterPropModuleComputer module wasn't being called out, so any prop function tied to JSIInternalRPMButtons wouldn't work properly. The stock button functions were unaffected because they were already there. After I fixed the file extension, everything seems to be working correctly. Now to figure out how to replace the mediocre texture on the stock control panel...

I'm trying to make an IVA for the new KV-1 pod. So far, I'm able to get ASET props to show up in the game, but I'm running into an issue with all of the SAS push-buttons: clicking on them plays the button-press sound, but the selected SAS mode doesn't actually change. I've compared the .cfg file I've made to the .cfgs for the Near Future pods, which have the same buttons working correctly, but can't find any differences. This is my first time using the Unity editor and PartTools, so I assume that I'm missing some necessary step after spawning the props and positioning them where I want them. Update: I checked my ksp.log and found a bunch of errors of the forms "Cannot find an InternalModule of typename 'JSIInternalRPMButtons'" and "[InternalProp]: Failed finding module JSIInternalRPMButtons for method ButtonSASModeStabilityAssist". More investigation is required.

When I tried it, everything looked OK except for the labels for the Mission Elapsed Time and Mission Name screens at the top of the wall, which were upside-down. Everything on the actual control screens was fined. This was with the ASET props, not the default RPM screens.

I ran some tests on the Launchpad with newly-build rovers, and the normal-sized docking ports wouldn't work, but the Junior-sized ones do. DPAI didn't think the normal-sized ports were pointed at each other, when they were clearly aligned. It seemed like they were 90 degrees off in one axis. Perhaps the new docking port model has a coordinate swapped somewhere?

The bug is specific to DirectX, and doesn't seem to be affecting OpenGL, so RPM works fine on Mac and Linux, as well as on Windows if running in OpenGL.

Make sure you do the mission while remaining inside a box the rough size of the capsule.

What about using the EVA suit lights?

You're doing better than me… I can't get ScanSat to work with RPM either, even using the dev build. Is there an RPM-specific patch for ScanSat that I'm missing?

Apple keyboards have both keys labelled as Delete, thanks to thirty-plus years of Being Different.

1st: Mun Rovers: Dangerous at any speed.