Jump to content

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

sarbian

By sarbian
in KSP1 Mod Releases

 Share

Recommended Posts

Electrocutor

Electrocutor

Posted
Posted
3 minutes ago, blowfish said:

Can you also show the patch this stuff is in? 

StockPBR_Templates {
	SpecularFixed {
	MATERIAL {
		name = SpecularFixed

		shader = TU/Metallic
		float = _Metal, 0.0
		float = _Smoothness, 0.2
	}
	}

	Transparent {
	MATERIAL {
		name = Transparent

		shader = TU/Transparent/Metallic
		float = _Metal, 0.0
		float = _Smoothness, 0.0
	}
	}
}

---- Other File ----
KSP_MODEL_SHADER
{
	model = Squad/Parts/Command/Mk1-3Pod/Mk1-3
	#@StockPBR_Templates/Transparent/MATERIAL
	{
	}
	@MATERIAL[Transparent]
	{
		mesh = Flag
	}
	#@StockPBR_Templates/SpecularFixed/MATERIAL
	{
	}
	@MATERIAL[SpecularFixed]
	{
		mesh = M1-3
	}
}

 

Link to comment
Share on other sites
blowfish

blowfish

Posted
Posted
2 minutes ago, Electrocutor said:
Spoiler 


StockPBR_Templates {
	SpecularFixed {
	MATERIAL {
		name = SpecularFixed

		shader = TU/Metallic
		float = _Metal, 0.0
		float = _Smoothness, 0.2
	}
	}

	Transparent {
	MATERIAL {
		name = Transparent

		shader = TU/Transparent/Metallic
		float = _Metal, 0.0
		float = _Smoothness, 0.0
	}
	}
}

---- Other File ----
KSP_MODEL_SHADER
{
	model = Squad/Parts/Command/Mk1-3Pod/Mk1-3
	#@StockPBR_Templates/Transparent/MATERIAL
	{
	}
	@MATERIAL[Transparent]
	{
		mesh = Flag
	}
	#@StockPBR_Templates/SpecularFixed/MATERIAL
	{
	}
	@MATERIAL[SpecularFixed]
	{
		mesh = M1-3
	}
}

 

Ah, so it's not a patch.  That's normal, expected, and has always been the case.  ModuleManager commands are only evaluated within patches, not root insert nodes.  It may be possible to change this in the near future, but for now you need to put this all in a patch.

Link to comment
Share on other sites
Electrocutor

Electrocutor

Posted
Posted
1 minute ago, blowfish said:

Ah, so it's not a patch.  That's normal, expected, and has always been the case.  ModuleManager commands are only evaluated within patches, not root insert nodes.  It may be possible to change this in the near future, but for now you need to put this all in a patch.

Okay, thanks.

Link to comment
Share on other sites
Gapone

Gapone

Posted
Posted

So i use Show All Fuels (the mod thad adds patch that shows oxidizer & others gauge).

@PART[*]:HAS[@MODULE[ModuleEngines*]]:FINAL{
    @MODULE[ModuleEngines*],*{
        @PROPELLANT[*],*{
            %DrawGauge=true
        }
    }
}

But i want to it to do NOT show Intake Air.

BUT! I! DO! THIS! THE! FIRST! TIME!

So i don't know how to make it select EVERYTHING BUT NOT IntakeAir.

How do i do that?

Link to comment
Share on other sites
JH4C

JH4C

Posted
Posted (edited)

@sarbian, @blowfish: while I appreciate that there's greater error checking and reporting now, I'm getting error reports for patches that aren't even being applied to my game because I don't have the relevant dependency or play using the relevant language pack. Perhaps a switch could be added for this more granular report being offered to mod writers, while the rest of us don't get panicked by mistakes that will never impact our game? It would also be nice if the cache got built regardless of any errors, because it makes reviewing the problems much easier when you only have to dig through the one smaller file.

Also, when I was helping someone look through their errors over the weekend using MM3.1.1 there was a report in KSP.log that explained what was causing the error. This seems to have been removed in 3.1.2? Please give it back!

Edited by JH4C
extra thoughts
Link to comment
Share on other sites
blowfish

blowfish

Posted
Posted

@JH4C what errors are you seeing?  A bunch of the non-critical stuff has already been downgraded to warnings.

Nothing should have changed between 3.1.1 and 3.1.2 with respect to what errors appear in the log.  Could you be more specific about what you’re seeing on that front?

Link to comment
Share on other sites
Wyzard

Wyzard

Posted
Posted
On 11/25/2018 at 1:56 PM, blowfish said:

@Wyzard not currently possible to use or in that context.  Will probably be done eventually but need to clean up a lot of code first.  But patches in the same file and pass will be applied in order.

Thanks.  My workaround will be fine for now, since the order is guaranteed.

Link to comment
Share on other sites
JH4C

JH4C

Posted
Posted
15 hours ago, blowfish said:

@JH4C what errors are you seeing?  A bunch of the non-critical stuff has already been downgraded to warnings.

Nothing should have changed between 3.1.1 and 3.1.2 with respect to what errors appear in the log.  Could you be more specific about what you’re seeing on that front?

My apologies, somehow I'd gotten myself confused. I'd found an error in someone else's log much more easily than I did in my own, and misremembered where that information had been presented. As for the fact the errors were in files that I'm "not using", the errors were located in the files in such a way that there was no way for MM to know they weren't meant to be applied - one specifically was an error in the FOR/NEEDS chain at the start of such a patch.

I shall now slink off with my tail between my legs and think about what I did. :( To save this from being utterly useless, I'll ask for help with the other issues.

A lot of the warnings appear to be related to having multiple HAS/NEEDS declarations. It's okay to smush them together using commas? Something in the back of my head's saying that pipes should be the delimiters, I think I'm mistaking one type of list for another... 

HAS[MODULE[FOO],!MODULE[BAR]]:NEEDS[Dependency,VeryImportantMod,!Antithesis]

The above should apply a patch only if I have MODULE[FOO] and mods Dependency and VeryImportantMod, correct?

Link to comment
Share on other sites
blowfish

blowfish

Posted
Posted
1 minute ago, JH4C said:

A lot of the warnings appear to be related to having multiple HAS/NEEDS declarations. It's okay to smush them together using commas? Something in the back of my head's saying that pipes should be the delimiters, I think I'm mistaking one type of list for another... 


HAS[MODULE[FOO],!MODULE[BAR]]:NEEDS[Dependency,VeryImportantMod,!Antithesis]

The above should apply a patch only if I have MODULE[FOO] and mods Dependency and VeryImportantMod, correct?

Only the first HAS/NEEDS was ever processed.  It just never complained before.  Combining them is the right thing to do.  NEEDS accepts &/, for AND or | for OR.  HAS only accepts &/, though this might change in the future.

Link to comment
Share on other sites
Tyko

Tyko

Posted
Posted

Hoping to get some syntax help here. I'm still challenged by setting up conditions correctly. 

Here's my goal - I want to standardize monoprop vacuum ISPs. Different mods have wildly different takes on monoprop efficiency - some are around 240 like stock. Other mods have them in the mid 300's like LFO. I'm trying to clean it up by narrowing all monoprop vacuum ISPs to around the 280-310 range. This would put them a step below most LFO vacuum engines and create a tradeoff between between weight and efficiency.

The logic would look like this - move all current Monoprop engines into 2 classes for vacuum ISP - 

  • For all monoprop engines with < 300 ISP -> make the new ISP 280
  • For all monoprop engines with > 300 ISP -> make the new ISP 310

I realize this isn't very granular, but it would be quick and dirty and wouldn't require me to tweak each engine. Since the current ISPs are fairly arbitrary anyway, this is as least better.

Ideally RCS would be left untouched at 240, but at the end of the day RCS use is so small that i don't think it would make an appreciable difference in overall fuel use.

If anyone could help me get started on proper syntax it would be most appreciated. Thanks!  :D 

Link to comment
Share on other sites
blowfish

blowfish

Posted
Posted
5 minutes ago, Gordon Dry said:

With MM 3.1.2 I had some occurances, where a node check with ,* at the end only worked when there were really more than one node with the same name in a part.

If it was only one, the patch did not occur.

In previous versions of MM it always worked.

Could you provide a specific example?

Link to comment
Share on other sites
Gordon Dry

Gordon Dry

Posted
Posted 
@PART[*]:HAS[@MODULE[LaunchClamp],@MODULE[ModuleGenerator]]:NEEDS[!RealismOverhaul,ZZZ_REFUSE]:AFTER[ZZZ_REFUSE]
{
	@MODULE[ModuleGenerator],*:HAS[@OUTPUT_RESOURCE[LiquidFuel]]
	{
		@OUTPUT_RESOURCE[LiquidFuel]
		{
			@name = Kerosene
		}
	}
	@MODULE[ModuleGenerator],*:HAS[@OUTPUT_RESOURCE[Oxidizer]]
	{
		@OUTPUT_RESOURCE[Oxidizer]
		{
			@name = LqdOxygen
		}
	}
	@MODULE[ModuleGenerator],*:HAS[@OUTPUT_RESOURCE[MonoPropellant]]
	{
		@OUTPUT_RESOURCE[MonoPropellant]
		{
			@name = HTP
		}
	}
}

 

Link to comment
Share on other sites
Gordon Dry

Gordon Dry

Posted
Posted

After some hick-hack I made it working with this: 

@PART[*]:HAS[@MODULE[LaunchClamp],@MODULE[ModuleGenerator]]:NEEDS[!RealismOverhaul,ZZZ_REFUSE]:FINAL
{
	@MODULE[ModuleGenerator],*
	{
		@OUTPUT_RESOURCE,*:HAS[#name[LiquidFuel]]
		{
			@name = Kerosene
		}
		@OUTPUT_RESOURCE,*:HAS[#name[Oxidizer]]
		{
			@name = LqdOxygen
		}
		@OUTPUT_RESOURCE,*:HAS[#name[MonoPropellant]]
		{
			@name = HTP
		}
	}
}

 

Link to comment
Share on other sites
Jso

Jso

Posted
Posted
5 hours ago, Tyko said:

The logic would look like this - move all current Monoprop engines into 2 classes for vacuum ISP - 

  • For all monoprop engines with < 300 ISP -> make the new ISP 280
  • For all monoprop engines with > 300 ISP -> make the new ISP 310

This depends on the vac Isp being listed in the first key, but I've never seen it not. Isp upgrades can become downgrades doing this so I'm just removing them. 

@PART:HAS[@MODULE[ModuleEngines*]:HAS[@PROPELLANT[MonoPropellant]]]
{
	@MODULE[ModuleEngines*],*:HAS[@PROPELLANT[MonoPropellant]]
	{
		@atmosphereCurve
		{
			vacIsp = #$key,0[1, ]$
		}
		@atmosphereCurve:HAS[#vacIsp[<300]]
		{
			@key,0 = 0 280
		}
		@atmosphereCurve:HAS[#vacIsp[>300]]
		{
			@key,0 = 0 310
		}
		@UPGRADES
		{
			@UPGRADE,*
			{
				!atmosphereCurve {}
			}
		}
	}
}

 

Link to comment
Share on other sites
Tyko

Tyko

Posted
Posted
11 hours ago, Jso said:

This depends on the vac Isp being listed in the first key, but I've never seen it not. Isp upgrades can become downgrades doing this so I'm just removing them. 


@PART:HAS[@MODULE[ModuleEngines*]:HAS[@PROPELLANT[MonoPropellant]]]
{
	@MODULE[ModuleEngines*],*:HAS[@PROPELLANT[MonoPropellant]]
	{
		@atmosphereCurve
		{
			vacIsp = #$key,0[1, ]$
		}
		@atmosphereCurve:HAS[#vacIsp[<300]]
		{
			@key,0 = 0 280
		}
		@atmosphereCurve:HAS[#vacIsp[>300]]
		{
			@key,0 = 0 310
		}
		@UPGRADES
		{
			@UPGRADE,*
			{
				!atmosphereCurve {}
			}
		}
	}
}

 

wow, thanks so much for your time! I'll play with it this weekend  :) 

Link to comment
Share on other sites
jlcarneiro

jlcarneiro

Posted
Posted (edited)

Thanks, once again for the "mother of almost every mod"! ;)

With version 3.1.1, I've found out I have 3 errors and 4 warnings in my MM patches (7000+). How do I identify each error and warning? I assume they are in KSP log. But how do I find them? And the log entry shows the excerpt I have to fix (or at least the line)?

Edited by jlcarneiro
Link to comment
Share on other sites
LatiMacciato

LatiMacciato

Posted
Posted
19 minutes ago, jlcarneiro said:

Thanks, once again for the "mother of almost every mod"! ;)

With version 3.1.1, I've found out I have 3 errors and 4 warnings in my MM patches (7000+). How do I identify each error and warning? I assume they are in KSP log. But how do I find them? And the log entry shows the excerpt I have to fix (or at least the line)?

on Linux I'd try parsing the log file like this:
  

cat KSP.log | grep 'err ' > errors.txt

 

Link to comment
Share on other sites
Drew Kerman

Drew Kerman

Posted
Posted (edited)

not getting the expected behavior with this patch: 

+PART[RCS_025T_*]
{
  @name = ^= :$:_CG
  @title ^= :$: (CG)
  @cost *= 0.5 
  @mass *= 0.75
  @MODULE[ModuleRCSFX]
  {
    @thrusterPower = 0.02
    @resourceName = Coldgas
    !atmosphereCurve {}
    atmosphereCurve
    {
      key = 0 080
      key = 1 060
      key = 4 0.001
    }
  }
}

There are six parts that begin with RCS_025T_ but this only clones one of them. Does the +PART not use a wildcard to search for all instances and only just copy the first one it finds? Is there a way I can get it to clone all six of the parts with one patch or do I have to do them individually?

Edited by Drew Kerman
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing
×
×
  • Create New...