Jognt

Heya. So, about those icons. I’ve been thinking. Why not use the same symbols as the dV map where applicable? Because the dV map covers most stages of flight and will be known by most. Alas, no example to show. I do far more thinking than actually doing. Edit: With regards to the colors, I know they’re customizable now, but consider replacing red with greyed-out. After all, it’s not dangerous, it’s just not possible. (Though I guess that could be dangerous..)

Assuming this is possible: You’d risk running into problems if any other mod whitelisted any of the stock assets for their own mod. Also, since the space you’d save isn’t all that much: Why would you wish to do this?

If you know the ins and outs you could ask them if they could use an extra keyboard? [snip]

Not having any problems for the few times I played

Tip if you’re also annoyed by decimals after moving the slider: you can alter the value to an exact number by editing it in the savefile. (Disclaimer: Backup before modifying, just in case, etc)

Just now I realized I commented about problems I encountered but did not come back to properly thank you for fixes @Gotmachine So thank you. Edit: Sadly I cannot help or say anything regarding problems encountered by others here as I haven’t played since 1.7.

There's a lot of ways to get stuff done so my main question would be "What are you trying to achieve when you say you wish to 'disable' them?" (literally no thrusters? thrusters that are toggled off by default? Just the effects but no thrust?) With regards to :HAS[@MODULE[ModuleCommand],@MODULE[ModuleRCSFX]] -> the comma means AND. A pipe means OR. Note that OR does not work within a HAS statement.

Not sure if I’m glad to know I’m not the only one! But yeah, accurate.

Uhm. Check your ModuleManager.configcache file. Do a search for the experiments in question and check the xmit value. It should be 1 when using the applicable mod. If it’s not, then your player.log and/or ModuleManager log (if it’s still a thing in the logs folder) can tell you what specific CFG applied the change to the specific part. (They’re all listed like “applying patch XYZ to part.cfg”-ish)

Apology for the reference but it’s not meant to be funny. I actually turn some of them off because they really sound like a Hitler speech..

Literally every body is reimagined, atmosphere heights were tweaked, lots more. I’d lean towards calling JNSQ a total overhaul instead of just a rescale.

Use CKAN to manage your mod install. Either that or tell us what actually happens/goes wrong.

Don’t worry. Nobody is attacking you or your exquisite mod.

In world filled with Kerbals that believe MinMus tastes like pistachio I wouldn’t stray too far into the ‘real life’ angle. Duplicating reality is a great way to make stuff no fun to do.

Just to check: You have completed a SCANsat Biome scan of the body in question?

yes, it does.

Honestly? I can't remember the exact details, but back when Breaking Ground was released I must have added it for a reason! Past-me probably found that the Breaking Ground surface feature experiments (which this applies to) have a usecase where modifying them is undesirable. Note that you may as well just grab the Full Reward and/or Full Transmit mods as those do exactly this and will be updated along the way. Edit: I take that back. The ROC experiments that I just checked already have basevalue == sciencecap. So there shouldn't be scary stuff (or even changes at all) by ex or including them. I must have excluded them on a "Don't tweak what I don't yet fully understand" basis or to keep unneeded modifications to a minimum. My apologies.

Works fine here with these two patches: // Set the amount of science you get for an experiment to its max value. Now you don't have to perform the same experiment in the same situation several times to get that last bit of science. @EXPERIMENT_DEFINITION:HAS[~id[deployed*],~id[ROC*]]:FOR[MyStuff] { @baseValue = #$scienceCap$ } // Small config to set the xmitDataScalar value for numerical science @PART[*]:HAS[@MODULE:HAS[~experimentID[ROC*],~experimentID[surfaceSample],#rerunnable[?rue],#xmitDataScalar[<1]]]:FOR[MyStuff] { @MODULE:HAS[~experimentID[ROC*],~experimentID[surfaceSample],#rerunnable[True],#xmitDataScalar[<1]] { @xmitDataScalar = 1 } } Not to mention that x Science only activates experiments, as far as I know it does not interfere with the amount gathered and/or sent. Ps. you will have other issues down the line if you don't add ROC experiments to your exclusion, just saying. Also working fine here KSP 1.9.1 + x Science 5.26

Should be fixed in the next update: Im guessing the comments about it being normal behavior are referring to the fact that everyone experiences it at the moment.

Good to know, thanks. I don’t see X Science adding compatibility for anything any time soon though. Considering the fact that DM’s Generic module works but his non-generic does not and that it has repeatedly been stated that compatibility Isn’t planned. It may be possible to slot in DM’s generic module into US2 experiments clientside similar to my DMOS patch. Once I have the time to play or tinker, I’ll have a look.

Fair enough. It’s no more than a personal suspicion after all *activates anti-derail-system* Let’s get back to the topic at hand shall we?

Nah. Just my suspicion with the rate of updates and the (what feels like) reduced changes per .x update. Felt to me like increasing the version number was more important than the patch itself. Otherwise 1.9 could’ve just been another 1.8.x patch.

On the plus side, I’m guessing the KSP1 team wants to release ksp1 2.0 at the same time as Ksp2, so with that being delayed I’d guess we’ll be on 1.9 for a while

Stay safe! And thank you

Xmit impacts how much of the gathered science you can transmit. It doesn’t change the max amount of Science you can gather per go. Are you sure you’re not confusing xmitdatascalar and science value?