totm nov 2017 [1.3.0] Community Database of Module Manager Patches for Stock KSP

[Blackline]

Thanks, and for stuff like a survey scan (700  dish) it works without losses, since there is (almost) no science involved. Never noticed, that some of the science was lost, but if you can repeat it without any problems, i don't get why it shouldn't transmitt 100% in the first place...

Is there a tweakable for that? Like this example for full science values:

Spoiler

@EXPERIMENT_DEFINITION[*]
    {
        %baseValue = #$scienceCap$
    }

 

Edited July 26, 2017 by Blackline

[Aelfhe1m]

1 hour ago, Blackline said:

Thanks, and for stuff like a survey scan (700  dish) it works without losses, since there is (almost) no science involved. Never noticed, that some of the science was lost, but if you can repeat it without any problems, i don't get why it shouldn't transmitt 100% in the first place...

Is there a tweakable for that? Like this example for full science values:

  Reveal hidden contents

@EXPERIMENT_DEFINITION[*]
    {
        %baseValue = #$scienceCap$
    }

 

ModuleDataTransmitter (on antennae) doesn't have any fields that seem to be relevant and poking around in various "global" settings files didn't turn up anything obvious either. Of course there might be something with a non-obvious name or that doesn't get a default value so you need to look in the code to find it.

[Blackline]

1 hour ago, Aelfhe1m said:

ModuleDataTransmitter (on antennae) doesn't have any fields that seem to be relevant and poking around in various "global" settings files didn't turn up anything obvious either. Of course there might be something with a non-obvious name or that doesn't get a default value so you need to look in the code to find it.

Is that part of code available, like legaly?

[Aelfhe1m]

23 minutes ago, Blackline said:

Is that part of code available, like legaly?

You don't need to decompile the Squad code which is against the license terms. You can learn a lot about what fields and settings are available by the API web documentation and looking at the class signatures in Visual Studio (or other IDE):

 

Edited July 26, 2017 by Aelfhe1m
Rephrased slightly

[NomenNescio]

I've been wondering, is it possible to add an "invert" option to control surfaces using this method? I'm a bit of noob at this, so any help is appreciated.

[KerbMav]

23 minutes ago, NomenNescio said:

I've been wondering, is it possible to add an "invert" option to control surfaces using this method? I'm a bit of noob at this, so any help is appreciated.

As far as I know, control surfaces automatically decide which way to move depending on their position relative to the crafts center of mass - if this should be of any help to you.

[NomenNescio]

9 minutes ago, KerbMav said:

As far as I know, control surfaces automatically decide which way to move depending on their position relative to the crafts center of mass - if this should be of any help to you.

That's exactly the problem, whenever I try to make a craft with swept wings, even if the wing is placed in front of the center of mass, the control surfaces aren't, which then means they're inverted incorrectly. The option to invert them myself is something I've been begging/hoping for for a long time.

[KerbMav]

39 minutes ago, NomenNescio said:

That's exactly the problem, whenever I try to make a craft with swept wings, even if the wing is placed in front of the center of mass, the control surfaces aren't, which then means they're inverted incorrectly. The option to invert them myself is something I've been begging/hoping for for a long time.

Oh.

Can you try something? Attach the wings behind the COM and use the widget to move them where you intended them to be.

[NomenNescio]

17 minutes ago, KerbMav said:

Oh.

Can you try something? Attach the wings behind the COM and use the widget to move them where you intended them to be.

Alright. *Testing* It didn't work. Is it possible to do this with an MM.cfg file? Because if not, we should probably move this discussion to PM.

[Aelfhe1m]

2 hours ago, NomenNescio said:

Alright. *Testing* It didn't work. Is it possible to do this with an MM.cfg file? Because if not, we should probably move this discussion to PM.

The control surfaces - elevons for example - do not have a tweakable setting to control their direction, only the "deploy" direction. Therefore there is nothing for MM to work with. Sorry.

[TheRagingIrishman]

9 hours ago, NomenNescio said:

That's exactly the problem, whenever I try to make a craft with swept wings, even if the wing is placed in front of the center of mass, the control surfaces aren't, which then means they're inverted incorrectly. The option to invert them myself is something I've been begging/hoping for for a long time.

I might be able to do this (I have an idea of how to do it but I'm not sure if it will actually work). Pop it as an issue on Smart Actuators Github (https://github.com/theRagingIrishman/SmartActuation/issues) so I don't forget about it. 

[NomenNescio]

19 hours ago, Aelfhe1m said:

The control surfaces - elevons for example - do not have a tweakable setting to control their direction, only the "deploy" direction. Therefore there is nothing for MM to work with. Sorry.

Ah well, thank you anyway.

13 hours ago, TheRagingIrishman said:

I might be able to do this (I have an idea of how to do it but I'm not sure if it will actually work). Pop it as an issue on Smart Actuators Github (https://github.com/theRagingIrishman/SmartActuation/issues) so I don't forget about it. 

I will take any solution you my have!

[eddiew]

I might be wrong, but I think Editor Extensions provides a tweakable slider for control surface strength; up to 150%, and down to -150%. A negative value effectively inverts the surface.

...if it's not EE, then it's one of the other mods I use. Which will take a while to work out  

[Wyzard]

53 minutes ago, eddiew said:

I might be wrong, but I think Editor Extensions provides a tweakable slider for control surface strength; up to 150%, and down to -150%. A negative value effectively inverts the surface.

...if it's not EE, then it's one of the other mods I use. Which will take a while to work out  

I think that's a stock feature, enabled via "advanced tweakables".

[eddiew]

3 minutes ago, Wyzard said:

I think that's a stock feature, enabled via "advanced tweakables".

Oh, that's even easier then  

[jlcarneiro]

Hello, guys! I need some help...

This may sound strange, but is there a way to avoid automatically upgrading SAS on the probe cores? I mean, I don't mind being able to upgrading them manually (via tweakables), but I think new OKTOs being as controllable as HECS automatically unbalances the game...

What can I do to maintain the option to tweak them but keep them with stock functions by default?

[Alshain]

1 minute ago, jlcarneiro said:

Hello, guys! I need some help...

This may sound strange, but is there a way to avoid automatically upgrading SAS on the probe cores? I mean, I don't mind being able to upgrading them manually (via tweakables), but I think new OKTOs being as controllable as HECS automatically unbalances the game...

What can I do to maintain the option to tweak them but keep them with stock functions by default?

Automatically upgrading probe cores?  Sounds like you are running a mod, that isn't stock functionality.

[Blackline]

10 hours ago, jlcarneiro said:

Hello, guys! I need some help...

This may sound strange, but is there a way to avoid automatically upgrading SAS on the probe cores? I mean, I don't mind being able to upgrading them manually (via tweakables), but I think new OKTOs being as controllable as HECS automatically unbalances the game...

What can I do to maintain the option to tweak them but keep them with stock functions by default?

Are you using my cfg from here by any chance? (Last post)

@Alshain will you add my contribution to the list? The one I posted a page ago. The cfg from the linked thread could be useful as well.

[jlcarneiro]

On 28/07/2017 at 10:50 PM, Alshain said:

Automatically upgrading probe cores?  Sounds like you are running a mod, that isn't stock functionality.

Sorry, forgot to mention it! This is the result of TweakbleEverythingContinued.

[Messy Recipe]

Here's one to turn off flags on pods and such by default:

// Turn off flag decals by default
// Author: Messy Recipe

@PART[*]:HAS[@MODULE[FlagDecal]]:FINAL
{
	@MODULE[FlagDecal]
	{
		%flagDisplayed = false
	}
}

 

[jlcarneiro]

On 30/07/2017 at 1:34 PM, jlcarneiro said:

Sorry, forgot to mention it! This is the result of TweakbleEverythingContinued.

Is there any way to avoid it?

[theshepherd]

Here's my go at adding some additional love for Pilots.  This will decrease fuel usage with more experience.  I have tested that the extra delta-V does not show up on KER or MJ, so you will have to do the maths in your head, etc....  So without affecting Thrust or Specific Impulse, this reduces the fuel flow and increases delta-v by up to 15% for fully experienced pilots.

// Give pilots fuel efficency as a skill
// Author: theshepherd
@EXPERIENCE_TRAIT[Pilot]:Needs[SQUAD]:Final
{
	%EFFECT[FuelUsage]
	{
		%modifiers = 0.99, 0.97, 0.94, 0.90, 0.85
	}	
}

It seems balanced but if you think it is OP, adjust the numbers accordingly.

[Wyzard]

Here's another suggested patch for the database:

// Add in-vessel transfer support to all parts that can hold science, unless
// explicitly disabled by the part.  This is the same ability that the stock
// Experiment Storage Unit has; it doesn't really make sense for it to be
// limited to just the that part.
// Author: Wyzard
@PART[*]:HAS[@MODULE[ModuleScienceContainer]]
{
	// Allow "Container: Collect All" and "Container: Transfer Data" by
	// default.
	@MODULE[ModuleScienceContainer]:HAS[~canTransferInVessel[]]
	{
		canTransferInVessel = True
	}

	// Allow targeting by "Container: Transfer Data" on other parts by
	// default.
	@MODULE[ModuleScienceContainer]:HAS[~canBeTransferredToInVessel[]]
	{
		canBeTransferredToInVessel = True
	}
}

This is similar to an existing patch by steve_v that's already in the database, but there are a few differences:

• It applies to all parts that have ModuleScienceContainer, not just command modules and science labs.  (I don't see a reason to treat those things specially.)
• However, it only applies to parts that don't already specify whether they allow science transfers.  (If the part's author has explicitly said no, rather than just leaving it unspecified, it's probably for a good reason.)
• It doesn't add the "showStatus" flag, since that's not really useful.  (It adds a line to the part's right-click menu saying "status: 0 experiments" if there's no science data, but you can already tell there's no data because there's no "review stored data" button.  Command pods' right-click menus already get kinda crowded, and the status line would just take up more pixels.)

[KerbMav]

@Wyzard Huh, neat.

I use Ship Manifest to move science around. In cases when I know where the science is stored (i.e. not a massive station), this would actually be really handy!

[Rodhern]

On 7/24/2017 at 10:15 AM, Kerbal101 said:

Make Stayputnik available earlier

Apart from making career more historically correct, it significantly decreases risks associated with test-driving prototype planes and rockets when playing on Hard without reloading. It moves Stayputnik and (inline attachable) fitting battery Z-200 from Tech Level 3 "Electrics" to Tech Level 2 "Engineering 101", allowing much earlier unlock. Solar panels NOT included.

@PART[batteryBankMini]
{
 @TechRequired = engineering101
}

@PART[probeCoreSphere]
{
 @TechRequired = engineering101
}

 

I only recently 'discovered' how convenient it is to use module manager patches to tweak the tech tree (otherwise I would just edit the config files themselves). I see @Kerbal101 already quoted an excellent example. For the most part I like the stock tech tree, but it is nice to be able to tweak it a little. To enhance the immersion you might even want to change the display name of some RD nodes:

@TechTree
{
  @RDNode:HAS[#id[stability]]
  {
    @title = Basic Flight
  }
}