Jump to content

[1.8.x-1.12.x] Module Manager 4.2.1 (August 1st 2021) - Locked inside edition


sarbian
 Share

Recommended Posts

1 hour ago, maculator said:

Ah that was helpful. Didn't know MM stores its reports there.

But I stil got my problem. It says the warning is about the second :HAS, so I' tried this approach:

@PART[*]:HAS[@MODULE[ModuleDataTransmitter],#antennaType[INTERNAL]]:FINAL
{
	!MODULE[ModuleDataTransmitter] {}
}

didn't work. Now there is no warning, But my patch also doesn't work anymore.

The original patch

@PART[*]:HAS[@MODULE[ModuleDataTransmitter]]:HAS[#antennaType[INTERNAL]]
{
	!MODULE[ModuleDataTransmitter] {}
}

does work. It only says:

[WRN 21:53:31.364] more than one :HAS tag detected, ignoring all but the first: /Axel/@PART[*]:HAS[@MODULE[ModuleDataTransmitter]]:HAS[#antennaType[INTERNAL]]:FINAL

I guess its a syntax problem. And I really don't know how to phrase it otherwise :S

Try this:

@PART[*]:HAS[@MODULE[ModuleDataTransmitter]:HAS[#antennaType[INTERNAL]]]
{
	!MODULE[ModuleDataTransmitter] {}
}

I think this will work! Sorry, I hadn't paid much attention the first time...

Link to comment
Share on other sites

14 hours ago, maculator said:

It did work. And beeing able to filter that way will help me alot in the Future I think! Thank you verry much.

Uh, nope. The patch:

@PART[*]:HAS[@MODULE[ModuleDataTransmitter]:HAS[#antennaType[INTERNAL]]]
{
	!MODULE[ModuleDataTransmitter] {}
}

Is not working as you intended. It is issuing the MM warning:

WRN 21:53:31.364] more than one :HAS tag detected, ignoring all but the first: /Axel/@PART[*]:HAS[@MODULE[ModuleDataTransmitter]]:HAS[#antennaType[INTERNAL]]:FINAL

What essentially says that your path was degenerated into:

@PART[*]:HAS[@MODULE[ModuleDataTransmitter]]
{
	!MODULE[ModuleDataTransmitter] {}
}

What means that you will remove the module from parts not intended to have it removed.

Link to comment
Share on other sites

4 hours ago, Lisias said:

Uh, nope. The patch:

@PART[*]:HAS[@MODULE[ModuleDataTransmitter]:HAS[#antennaType[INTERNAL]]]
{
	!MODULE[ModuleDataTransmitter] {}
}

Is not working as you intended. It is issuing the MM warning:

WRN 21:53:31.364] more than one :HAS tag detected, ignoring all but the first: /Axel/@PART[*]:HAS[@MODULE[ModuleDataTransmitter]]:HAS[#antennaType[INTERNAL]]:FINAL

What essentially says that your path was degenerated into:

@PART[*]:HAS[@MODULE[ModuleDataTransmitter]]
{
	!MODULE[ModuleDataTransmitter] {}
}

What means that you will remove the module from parts not intended to have it removed.

I tested here now and appears to be working!

The correct is:

@PART[*]:HAS[@MODULE[ModuleDataTransmitter]:HAS[#antennaType[INTERNAL]]]

And not:

@PART[*]:HAS[@MODULE[ModuleDataTransmitter]]:HAS[#antennaType[INTERNAL]]

 

Link to comment
Share on other sites

3 hours ago, mateusviccari said:

Is there a way to edit config files and reapply them on the fly, without closing the game and reopening every time I want to change some patches?

Not that I'm aware of.  All the config files have to be read, in order, iaw MM since changing one might have an effect on another.  I don't believe there is any way around this.

Link to comment
Share on other sites

4 hours ago, mateusviccari said:

Is there a way to edit config files and reapply them on the fly, without closing the game and reopening every time I want to change some patches?

Try ALT+F11 on the KSC or the main menu (don't remember if worked with a loaded game)... But here, when I tried, the game freezes!

Edited by Dominiquini
Link to comment
Share on other sites

I seem to be having an issue where :NEEDS[!whatever] doesn't seem to work.  Is this a feature or a bug? Or something that just seems to be very very wrong with my instals?

This is happening on the Simplex and Tetrix TechTrees where a node is moving which should only happen if Near Future Construction is installed.

It has also has affected users of Kerbalism Simplex.

This is on ksp 1.12.1

Edited by theJesuit
Link to comment
Share on other sites

An update but still a question @sarbian

In the Tetrix Tech tree I used the following code:

		@RDNode:HAS[#id[advMetalworks]]
			{	@pos = -1828,1140,-1
				@cost = 240
				!Parent,* {}
				Parent
					{	parentID = specializedConstruction
						lineFrom = RIGHT
						lineTo = LEFT
					}
				Parent:NEEDS[NearFutureConstruction]
					{	parentID = largeVolumeContainment
						lineFrom = RIGHT
						lineTo = LEFT
					}
			}

Adding a second path to advMetalWorks when NearFutureConstruction was installed.  This no longer works and it always puts in the extra path.  I need a second patch now.

		@RDNode:HAS[#id[advConstruction]]
			{	@pos = -2068,1140,-1
				@cost = 60
				!Parent,* {}
				Parent
					{	parentID = generalConstruction
						lineFrom = RIGHT
						lineTo = LEFT
					}
			}

@TechTree:NEEDS[NearFutureConstruction]
	{	@RDNode:HAS[#id[advConstruction]]
			{	@pos = -2068,1140,-1
				@cost = 60
				!Parent,* {}
				Parent
					{	parentID = generalConstruction
						lineFrom = RIGHT
						lineTo = LEFT
					}
				Parent
					{	parentID = fuelSystems
						lineFrom = RIGHT
						lineTo = LEFT
					}
			}
	}

Was this an intentional change as may explain the issues I've been having?

Edited by theJesuit
Link to comment
Share on other sites

I was trying to create a MM patch, and for that I was trying to use '|' on the HAS block and it's not working. Than I saw on the documentation that it is not possible!

Any reason for this!

Thanks.

Link to comment
Share on other sites

I play with Kerbalism and after updating to the latest MM I noticed things were getting added to my craft that shouldn't be there (such as unmanned experiments to manned pods). Reverting back to 4.1.4 solved the problem.

Is this a problem with MM, or is this a case of Kerbalism needing to update to a new convention or some such?

Link to comment
Share on other sites

1 hour ago, BTAxis said:

I play with Kerbalism and after updating to the latest MM I noticed things were getting added to my craft that shouldn't be there (such as unmanned experiments to manned pods). Reverting back to 4.1.4 solved the problem.

Is this a problem with MM, or is this a case of Kerbalism needing to update to a new convention or some such?

Also getting lots of errors with Kerbalism/DMagic config with the new 4.2.0
 

[ERR 13:56:36.085] Error - Cannot parse variable search when inserting new key anim_deploy = #$../MODULE:HAS[#experimentID,~name[Experiment]]/animationName$
[LOG 13:56:36.086] Applying update KerbalismConfig/Support/DMagicOrbitalScience_Science/@PART[*]:HAS[@MODULE[DM*]:HAS[#experimentID[magScan]]]:NEEDS[DMagicOrbitalScience,FeatureScience] to DMagicOrbitalScience/UniversalStorage/USProbeSci/MagBoom.cfg/PART[dmUSMagBoom]

and for plumes

[ERR 14:06:19.171] Error - Cannot parse variable search when inserting new key plumeIdentifier = #$/PLUME[Ammonialox]:HAS[~processed[*]]/plumeIdentifier$
[ERR 14:06:19.171] Error - Cannot parse variable search when inserting new key transformName = #$/PLUME[Ammonialox]:HAS[~processed[*]]/transformName$
[ERR 14:06:19.171] Error - Cannot parse variable search when inserting new key localRotation = #$/PLUME[Ammonialox]:HAS[~processed[*]]/localRotation$
[ERR 14:06:19.171] Error - Cannot parse variable search when inserting new key localPosition = #$/PLUME[Ammonialox]:HAS[~processed[*]]/flarePosition$
[ERR 14:06:19.171] Error - Cannot parse variable search when inserting new key fixedScale = #$/PLUME[Ammonialox]:HAS[~processed[*]]/flareScale$
[ERR 14:06:19.171] Error - Cannot parse variable search when inserting new key name = #$/PLUME[Ammonialox]:HAS[~processed[*]]/plumeIdentifier$-flare
[ERR 14:06:19.171] Error - Cannot parse variable search when inserting new key transformName = #$/PLUME[Ammonialox]:HAS[~processed[*]]/transformName$
[ERR 14:06:19.171] Error - Cannot parse variable search when inserting new key localRotation = #$/PLUME[Ammonialox]:HAS[~processed[*]]/localRotation$
[ERR 14:06:19.171] Error - Cannot parse variable search when inserting new key localPosition = #$/PLUME[Ammonialox]:HAS[~processed[*]]/plumePosition$
[ERR 14:06:19.171] Error - Cannot parse variable search when inserting new key fixedScale = #$/PLUME[Ammonialox]:HAS[~processed[*]]/plumeScale$
[ERR 14:06:19.172] Error - Cannot parse variable search when inserting new key energy = #$/PLUME[Ammonialox]:HAS[~processed[*]]/energy$
[ERR 14:06:19.172] Error - Cannot parse variable search when inserting new key speed = #$/PLUME[Ammonialox]:HAS[~processed[*]]/speed$
[ERR 14:06:19.172] Error - Cannot parse variable search when inserting new key emissionMult = #$/PLUME[Ammonialox]:HAS[~processed[*]]/emissionMult$
[ERR 14:06:19.172] Error - Cannot parse variable search when inserting new key alphaMult = #$/PLUME[Ammonialox]:HAS[~processed[*]]/alphaMult$
[ERR 14:06:19.172] Error - Cannot parse variable search when inserting new key saturationMult = #$/PLUME[Ammonialox]:HAS[~processed[*]]/saturationMult$
[ERR 14:06:19.172] Error - Cannot parse variable search when inserting new key name = #$/PLUME[Ammonialox]:HAS[~processed[*]]/plumeIdentifier$-plume
[ERR 14:06:19.172] Error - Cannot parse variable search when inserting new key name = #$/PLUME[Ammonialox]:HAS[~processed[*]]/plumeIdentifier$-audio
[ERR 14:06:19.172] Error - Cannot parse variable search when inserting new key volume = #$/PLUME[Ammonialox]:HAS[~processed[*]]/plumeScale$
[LOG 14:06:19.173] Applying update RealPlume/000_Generic_Plumes/Ammonialox/@PART[*]:HAS[@PLUME[Ammonialox]:HAS[~processed[*]]]:AFTER[zRealPlume]:NEEDS[SmokeScreen] to Squad/Parts/Engine/liquidEngineMk55/liquidEngineMk55.cfg/PART[radialLiquidEngine1-2]

Additionally MM seems to get stuck in a loop, waiting for patching to finish. So in the splash screen it shows 57 errors, in the log file it is 46K errors. Hence seems to continuously keep writing error log.

Reverting to 4.1.4 seems to remove all that issues. Let me know if I can help somehow.

Link to comment
Share on other sites

I experience the same loop as @chris-kerbal also with the same mod, RealPlumes and with the same need.

Here's that line from my log:

[LOG 16:25:17.403] Applying update RealPlume/000_Generic_Plumes/Ammonialox/@PART[*]:HAS[@PLUME[Ammonialox]:HAS[~processed[*]]]:AFTER[zRealPlume]:NEEDS[SmokeScreen] to Squad/Parts/Engine/liquidEngineMk55/liquidEngineMk55.cfg/PART[radialLiquidEngine1-2]

 

Edit:  redownloading and reinstalling the mod didn't help, only solution was uninstalling. Now the game loads fine.

 

Edited by Mjollnir
Link to comment
Share on other sites

Those players have issues with the new MM, the entire Player.log and KSP.log files are needed, not just parts of the log.

Please do a test run, upload the logs to a file sharing site, then post with the file download link, the principle mods that you think might be the issue, and the steps needed to recreate the issue.

Link to comment
Share on other sites

3 hours ago, Mjollnir said:

I experience the same loop as @chris-kerbal also with the same mod, RealPlumes and with the same need.

Here's that line from my log:

[LOG 16:25:17.403] Applying update RealPlume/000_Generic_Plumes/Ammonialox/@PART[*]:HAS[@PLUME[Ammonialox]:HAS[~processed[*]]]:AFTER[zRealPlume]:NEEDS[SmokeScreen] to Squad/Parts/Engine/liquidEngineMk55/liquidEngineMk55.cfg/PART[radialLiquidEngine1-2]

 

Edit:  redownloading and reinstalling the mod didn't help, only solution was uninstalling. Now the game loads fine.

 

I concur - experiencing the same issue.

Corrected the issue, making the game playable, by reverting to MM v4.1.4 through CKAN
(CKAN > select MM > in the details window, select "Versions" tab > uncheck latest v4.2.0 > check v4.1.4 > Apply Changes)

Link to comment
Share on other sites

2 hours ago, Jacke said:

Those players have issues with the new MM, the entire Player.log and KSP.log files are needed, not just parts of the log.

Please do a test run, upload the logs to a file sharing site, then post with the file download link, the principle mods that you think might be the issue, and the steps needed to recreate the issue.

https://drive.google.com/file/d/1oa5bVdkxleAiYUZXjIO4_Nuojutzygc_/view?usp=sharing

Zip contains complete KSP.log, and a list of installed mods. Note the last line in the log is generated when the application is closed, so it essentially sat there for 12 minutes doing nothing (except looping loading art).

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

×
×
  • Create New...