[1.8.x-1.12.x] Module Manager 4.2.3 (July 03th 2023) - Fireworks season

[sarbian]

Just replace the dll

[MatterBeam]

Hi.

Is there a way to utilize the part's core and skin temperatures as modifiers for say, electrical generation?

Also, is there a way to create a module that generates heat without resorting to ENGINE modules?

[blowfish]

4 hours ago, MatterBeam said:

Is there a way to utilize the part's core and skin temperatures as modifiers for say, electrical generation?

Yes, see this post.

4 hours ago, MatterBeam said:

Also, is there a way to create a module that generates heat without resorting to ENGINE modules?

There are a couple of stock modules that generate heat, the resource converter for instance.  Nothing that just generates heat though.  This isn't really a MM question though.

[MatterBeam]

9 minutes ago, blowfish said:

Yes, see this post.

There are a couple of stock modules that generate heat, the resource converter for instance.  Nothing that just generates heat though.  This isn't really a MM question though.

Thanks. However, I didn't find any mention of temperature in that post

I found the RTG heat generating module.

Edit: Did some more careful reading and I think I'd have to write something like this:

Temperature
{
TemperatureMultiplier  = (Current Temperature)/(Target Temperature)
}
MODULE
{
	name = ModuleGenerator
	isAlwaysActive = true
	TemperatureMultiplier = #$@Temperature/TemperatureMultiplier$
	OUTPUT_RESOURCE
	{
	name = MWt
	rate = 1000
	@rate *= #$TemperatureMultiplier$
	}
}

The problem remains that there is nothing in the cfg files that 'reads' the current part temperature.

Edited February 7, 2016 by MatterBeam

[blowfish]

1 minute ago, MatterBeam said:

Thanks. However, I didn't find any mention of temperature in that post

Because temperature can be used as a variable just like anything else.  I'm not going to write the patch for you, if you're trying to do this you should understand how to patch in maxTemp when you need it.

[MatterBeam]

12 minutes ago, blowfish said:

Because temperature can be used as a variable just like anything else.  I'm not going to write the patch for you, if you're trying to do this you should understand how to patch in maxTemp when you need it.

Not maxTemp, which is fixed during loading, but the Internal and Skin temperatures in-game.

[blowfish]

11 minutes ago, MatterBeam said:

Not maxTemp, which is fixed during loading, but the Internal and Skin temperatures in-game.

Oh, well I don't think there's a way to do that with stock modules, and again, not really a MM question  You'd probably have to write some code to do that.

[MatterBeam]

9 minutes ago, blowfish said:

Oh, well I don't think there's a way to do that with stock modules, and again, not really a MM question  You'd probably have to write some code to do that.

Thank you for your help!

I will try and utilize the efficiency module that comes with the ISRU and the drills, that reduces their output based on their current temperature.

Edited February 7, 2016 by MatterBeam

[sebi.zzr]

27 minutes ago, MatterBeam said:

Not maxTemp, which is fixed during loading, but the Internal and Skin temperatures in-game.

If you want to generate heat (by itself or from generating power) ,you need to use:

MODULE
{
name = ModuleCoreHeat
}

 

[MatterBeam]

11 minutes ago, sebi.zzr said:

If you want to generate heat (by itself or from generating power) ,you need to use:

MODULE
{
name = ModuleCoreHeat
}

 

Thank you. I copied over the module from the RTG.

[Sigma88]

@sarbian it looks like newer versions of mm do not block older versions anymore. Is this intended?

(I would post logs, but the ones I have right now are a bit messy, so I'm trying to reproduce the problem with an easy setup. but it's definitely something that goes wrong only if there are 2 versions of MM installed)

if this is a known issue let me know so that I can avoid losing time on it

probably issue 22

Edited February 10, 2016 by Sigma88

[MatterBeam]

Hello. I'm trying to create an engine with dynamic ISP.

The process I'm imagining requires three steps:

Measure value X = Available Resource Y (ie Propellant Flow in an ModuleEnginesFX module)

Define value Z = (Available X)/(Nominal Resource Y)

Render Isp variable:
atmosphereCurve
{
            key = 0 500*Z
            key = 1 250*Z
            key = 2 100*Z
}

What is the code required for each step?

[Kerbas_ad_astra]

You mean something like VASIMR?  That's not possible with ModuleManager -- you'll need to write your own DLL module to dynamically modify Isp or other variables.

[MatterBeam]

2 minutes ago, Kerbas_ad_astra said:

You mean something like VASIMR?  That's not possible with ModuleManager -- you'll need to write your own DLL module to dynamically modify Isp or other variables.

Can I not perform math on atmosphereCurves?

Also, what would this do?:

{
DynamicISPFactor = 1
@atmosphereCurve
		{
			key = 0 500*#$DynamicISPFactor$
			key = 1 250*#$DynamicISPFactor$
			key = 2 100*#$DynamicISPFactor$
		}
}

 

Edited February 12, 2016 by MatterBeam

[Sigma88]

2 minutes ago, MatterBeam said:

Can I not perform math on atmosphereCurves?

whatever math you do is set before the game starts, once the game starts those values won't change unless you have a .dll that edits them

[MatterBeam]

Just now, Sigma88 said:

whatever math you do is set before the game starts, once the game starts those values won't change unless you have a .dll that edits them

That's so sad!

Everywhere I go, trying to do anything above the most basic of modifications, there this great big .dll wall in the way.

[Sigma88]

Just now, MatterBeam said:

That's so sad!

Everywhere I go, trying to do anything above the most basic of modifications, there this great big .dll wall in the way.

you can do pretty cool stuff with MM  just not live changes

[MatterBeam]

Just now, Sigma88 said:

you can do pretty cool stuff with MM  just not live changes

Well then, since the dynamic ISP option is out...

How do I get MechJeb and/or KerbalEngineer to calculate the dV of a rocket using an engine consuming at least 1 massless propellant?

More specifically, how do I get the above two to 'ignore' one of the two propellants an engine is consuming?

[sarbian]

You mark the  propellant  as ignore for isp (see jet engine configs) or give it a density of 0.

[MatterBeam]

Just now, sarbian said:

You mark the  propellant  as ignore for isp (see jet engine configs) or give it a density of 0.

Hello Sarbian!

The objective here is to allow a nuclear engine to consume Megawatts (massless) and LiquidFuel. The density of Megawatts is already set to zero in the ResourceDefinition config, but Mechjeb and KerbalEngineer both calculate dV based on the remaining amount of Megawatts.

I will test with the ignoreforIsp line.

[sarbian]

Current MJ official release here :

propellantSumRatioTimesDensity = engine.propellants.Where(prop => !prop.ignoreForIsp).Sum(prop => prop.ratio * MuUtils.ResourceDensity(prop.id));
propellantRatios = engine.propellants.Where(prop => MuUtils.ResourceDensity(prop.id) > 0 && !prop.ignoreForIsp ).ToDictionary(prop => prop.id, prop => prop.ratio);

And the one in the current dev release : 

var dics = new Tuple<KeyableDictionary<int, float>, KeyableDictionary<int, ResourceFlowMode>>(propellantRatios, propellantFlows);
engine.propellants.Slinq()
    .Where(prop => MuUtils.ResourceDensity(prop.id) > 0 && !prop.ignoreForIsp)
    .ForEach((p, dic) =>
    {
        dic._1.Add(p.id, p.ratio);
        dic._2.Add(p.id, p.GetFlowMode());
    }, dics);

As you can see both ignore resource density <= 0 

[MatterBeam]

10 minutes ago, sarbian said:

Current MJ official release here :

propellantSumRatioTimesDensity = engine.propellants.Where(prop => !prop.ignoreForIsp).Sum(prop => prop.ratio * MuUtils.ResourceDensity(prop.id));
propellantRatios = engine.propellants.Where(prop => MuUtils.ResourceDensity(prop.id) > 0 && !prop.ignoreForIsp ).ToDictionary(prop => prop.id, prop => prop.ratio);

And the one in the current dev release : 

var dics = new Tuple<KeyableDictionary<int, float>, KeyableDictionary<int, ResourceFlowMode>>(propellantRatios, propellantFlows);
engine.propellants.Slinq()
    .Where(prop => MuUtils.ResourceDensity(prop.id) > 0 && !prop.ignoreForIsp)
    .ForEach((p, dic) =>
    {
        dic._1.Add(p.id, p.ratio);
        dic._2.Add(p.id, p.GetFlowMode());
    }, dics);

As you can see both ignore resource density <= 0 

 

Ah stupid me, I kept on looking at the KerbalEngineer deltaV stats. The Mechjeb DeltaV custom window does indeed give correct values.

 

Thyank you for your help!

Edited February 13, 2016 by MatterBeam

[MatterBeam]

Thanks, sarbian, I was looking at the wrong mod the entire time!

[sarbian]

Ok, new features time. v2.619

1. "MM_PATCH_LOOP {}" nodes. They will have the current node loop on the active top node until the HAS condition is not valid anymore. It has some really specific use from complex patch and can easily lead to infinite loops.

A patch that would remove all ressource of all PART (of course there are easier way to do that)

@PART[*]:HAS[@RESOURCE[*]]
{
	!RESOURCE,0 {}
	
	MM_PATCH_LOOP {}
}

 

2. Editing of values outside the current edited node. start the line with * then use a path like the one used for variables and the math operators or a simple equal. It does not work if you edit a value inside the current edited node (@). It works if you are in a copy ($) or anything else.

A patch that would make 5 copy of the test node named Test1 Test2 Test3 Test4 Test5

TEST
{
	name = Test
}

@TEST
{
  copy = 5
}

$TEST[Test]:HAS[#copy[>0]]
{
	*@TEST[Test]/copy -= 1
	
	@name = #$name$$copy$	

	MM_PATCH_LOOP {}
}

 

Those are quite complex features and I strongly suggest you DO NOT USE THEM unless you really know what you are doing.

I m not editing the OP before I am sure I did not break old patch processing.

ModuleManager-2.6.19.zip

ModuleManager.2.6.19.dll

Edited February 16, 2016 by sarbian

[Sigma88]

@sarbian those looks very cool, thanks for adding them to our toolkit