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

[Furious1964]

Is there a way to find out what items are hidden?

[BudgetHedgehog]

Is there a way to find out what items are hidden?

The reason they're hidden is because they have unmet :NEEDS - I seem to recall something in the output_log.txt about 'not applying patch because its :NEEDS were not satisfied' or something. So yeah, your output_log.txt would be the first place to look.

[sarbian]

I have seen several problems with modulemanager in .24 that didn't exist in .23.5 mostly concerning matching functions and example being active texture managers boulderco folder config.

Your examples have nothing to do with ModuleManager. They are ATM config file and MM don't process them.

[PringleMan]

Can someone help me with a MM config for the Versatile Toolbox System? Since KAS is being finicky, I want to make a work around patch to allow store/release behavior. Basically, the logistics rack already behaves like a container bay, but he coded it to where all four nodes are on one store/release command. If the grab function was working right, that would not be a problem, but as it is right now if you click release (as a work around to grabbing the container directly) it releases all four nodes. I want it to behave like each node has its own store/release. I dont know if this is even possible.

Here is what the relevant part of the code from the original is:

MODULE
{
	name = KASModulePartBay
	BAY
	{
		attachNode = bottom01
		type = containervts
		type = containerA
        	type = containerB
	}
	BAY
	{
		attachNode = bottom02
		type = containervts
		type = containerA
        	type = containerB
	}
	BAY
	{
		attachNode = bottom03
		type = containervts
		type = containerA
        	type = containerB
	}
	BAY
	{
		attachNode = bottom04
		type = containervts
		type = containerA
        	type = containerB
	}
}

I tried changing it to:

		-MODULE[KASModulePartBay]{}
	MODULE
	{
		name = KASModulePartBay
		BAY
		{
			attachNode = bottom01
			type = containervts
			type = containerA
        	type = containerB
		}
	}
	MODULE
	{
		name = KASModulePartBay
		BAY
		{
			attachNode = bottom02
			type = containervts
			type = containerA
        	type = containerB
		}
	}
	MODULE
	{
		name = KASModulePartBay
		BAY
		{
			attachNode = bottom03
			type = containervts
			type = containerA
        	type = containerB
		}
	}
	MODULE
	{
		name = KASModulePartBay
		BAY
		{
			attachNode = bottom04
			type = containervts
			type = containerA
        	type = containerB
		}
	}

This actually gave four store/release commands, but they all stored and released on the same node lol. Is the store/release stored as a transform in unity? Or did I write something dumb? My main suspect is that the modules are sort of overwriting each other since they all have the name KASModulePartBay, and I am not sure how to work around that.

[AlphaAsh]

I think you can't delete a part, but you can disable them. But i can be wrong.

@TechRequired = NotINmyGameSucka

[toadicus]

Sarbian, in light of the KSP "feature" that replaces PartModules from persistence files by name, would re-enabling MM's persistence fixer work around the issue? Could it be applied to .craft files as well?

[drtedastro]

Hello to all.

I am looking for a mm config file that would allow me to put "LazorSystemDockingCamera" from Lazor mod into all docking ports.

If anyone has one and would be happy to share, please let me know.

Best regards,

DrTedAstro.

[NathanKell]

It already was applied to craft files, when it was enabled.

[drtedastro]

Can't get much easier than that... LoL... Thanks NathanKell.....

[toadicus]

Based on super-preliminary "I'm at my desk at work" testing, it looks like re-enabling MM's SaveGameFixer probably does work around the new 0.24 "feature".

Also, a few lines like this in Awake() ought to upgrade stock craft, so people can fly the Kerbal X in x64:

char ds = Path.DirectorySeparatorChar;

UpdateCraftDir(string.Format("{0}{1}Ships{1}VAB", KSPUtil.ApplicationRootPath, ds));
UpdateCraftDir(string.Format("{0}{1}Ships{1}SPH", KSPUtil.ApplicationRootPath, ds));

YMMV, IANASarbian, etc. etc. Seems worth looking into, at any rate.

Hello to all.

I am looking for a mm config file that would allow me to put "LazorSystemDockingCamera" from Lazor mod into all docking ports.

If anyone has one and would be happy to share, please let me know.

Best regards,

DrTedAstro.

I think NathanKell might have been talking about something other than your question. If you still need an MM patch, it would look something like this:

@PART[*]:HAS[@MODULE[ModuleDockingNode],!MODULE[LazorSystemDockingCamera]]:Final
{
    MODULE
    {
        name = LazorSystemDockingCamera
    }
}

"Final" is a bit deprecated, but for a personal patch you should be fine.

Edited July 22, 2014 by toadicus
Struck "testing at work". I would never do that. Who would do that? I wouldn't do that, would I? Also answer DrTedAstro.

[Starwaster]

If you guys do go back to the old pre 2.2.0 behavior of trying to fix save files, please PLEASE change how dynamic PartModules are handled. Don't wantonly delete them because can be and are used for persistence and if they get deleted then whatever state was being tracked is lot as well.

[Twinkee]

I'm something of a noob to coding and I'd like to get my head round this fairly cool way of adjusting KSP. Perhaps you guys can help.

Please compare the following code

@PART
[*]:HAS[@MODULE[ModuleScienceContainer]:HAS[~allowRepeatedSubjects[]]]     
{    
    @MODULE[ModuleScienceContainer]     
    {
        allowRepeatedSubjects = True     
    }
}

and this code:

@PART
[*]:HAS[@MODULE[ModuleScienceContainer]]     
{    
    @MODULE[ModuleScienceContainer]     
    {
        %allowRepeatedSubjects = True     
    }
}

I think they both do the same thing.

1/ Am I correct?

2/ Which is better?

3/ Is there a way of using :NEEDS to look for a folder name rather than a dll name?

I've tried to get my head round the instructions here, but I'm sure you'll know the answers straight away. I'm not usually squeamish with the 'socket and see' approach, but I've enough bugs while updating to 0.24 without creating my own.

Thanks

[toadicus]

I'm something of a noob to coding and I'd like to get my head round this fairly cool way of adjusting KSP. Perhaps you guys can help.

Please compare the following code

@PART
[*]:HAS[@MODULE[ModuleScienceContainer]:HAS[~allowRepeatedSubjects[]]]     
{    
    @MODULE[ModuleScienceContainer]     
    {
        allowRepeatedSubjects = True     
    }
}

and this code:

@PART
[*]:HAS[@MODULE[ModuleScienceContainer]]     
{    
    @MODULE[ModuleScienceContainer]     
    {
        %allowRepeatedSubjects = True     
    }
}

I think they both do the same thing.

1/ Am I correct?

2/ Which is better?

3/ Is there a way of using :NEEDS to look for a folder name rather than a dll name?

I've tried to get my head round the instructions here, but I'm sure you'll know the answers straight away. I'm not usually squeamish with the 'socket and see' approach, but I've enough bugs while updating to 0.24 without creating my own.

Thanks

So, the two patches will things slightly differently:

Patch 1 will apply ONLY to parts that have a ModuleScienceContainer but that do NOT have any definition for allowRepeatedSubjects (true or false; if they have any allowRepeatedSubjects = <stuff> line, they won't match). It will then modify the first ModuleScienceContainer on such parts and add the value allowRepeatedSubjects = true.

Patch 2 will apply to ALL parts that have a ModuleScienceContainer. It will then modify the first ModuleScienceContainer on such parts and modify or add the value allowRepeatedSubjects, setting it to true.

So, which is more correct depends on what you're trying to do. If you're trying to fill in some gaps, the former will do what you want. If you're trying to change the behavior of all parts bearing ModuleScienceContainers (except those for which allowRepeatedSubjects = true already; they'll match and the patch will apply, but since nothing's change you won't notice a difference), the latter is correct.

I'm not 100% sure, but I think :NEEDS will match mods as defined by a) the presence of a plugin .dll with a given Assembly.Name, a mod name as declared in a :FOR[] block, or c) a mod name as discovered by the name of a directory child of GameData.

[Starwaster]

I'm not 100% sure, but I think :NEEDS will match mods as defined by a) the presence of a plugin .dll with a given Assembly.Name, a mod name as declared in a :FOR[] block, or c) a mod name as discovered by the name of a directory child of GameData.

:FOR will not affect what :NEEDS matches on. Only (a) and © are correct. (dll name or folder name)

:FOR is just used for scheduling which pass the patch is applied in. There's 5 passes

FIRST

BEFORE

FOR

AFTER

FINAL

[Twinkee]

So to confirm... using an example:

@PART[dockingPort2]:NEEDS[B9_Aerospace]
{
!mesh = DELETE

    MODEL
    {
       model = Squad/Parts/Utility/dockingPort2/model
       position = 0, 0, 0 
       scale = 1, 1, 1
       rotation = 0, 0, 0 
    }

    MODEL
    {
       model = B9_Aerospace/Parts/Utility_Light_N/N1_White
       position = 0.0, 0.15, 0.0
       scale = 0.75, 0.75, 0.75
       rotation = 0, 0, 0
    }

%scale = 1
@title = Clamp-O-Tron - Illuminated
@description = A docking port enhanced with lighting, courtesy of the B9 Engineering boffins and implemented by Ingenuity Ltd.
}

will ONLY try to illuminate the clamp-o-tron if the B9_Aerospace folder exists?

PS thank you for your responses

[Starwaster]

So to confirm... using an example:

@PART[dockingPort2]:NEEDS[B9_Aerospace]
{
!mesh = DELETE

    MODEL
    {
       model = Squad/Parts/Utility/dockingPort2/model
       position = 0, 0, 0 
       scale = 1, 1, 1
       rotation = 0, 0, 0 
    }

    MODEL
    {
       model = B9_Aerospace/Parts/Utility_Light_N/N1_White
       position = 0.0, 0.15, 0.0
       scale = 0.75, 0.75, 0.75
       rotation = 0, 0, 0
    }

%scale = 1
@title = Clamp-O-Tron - Illuminated
@description = A docking port enhanced with lighting, courtesy of the B9 Engineering boffins and implemented by Ingenuity Ltd.
}

will ONLY try to illuminate the clamp-o-tron if the B9_Aerospace folder exists?

PS thank you for your responses

Correct. (although, if there were a DLL with that name, that would also cause that NEEDS to be met)

[Bison Steve]

With MM installed, my game always crashes while loading. It is only when I have MM. All installs are fresh. Any ideas?

[toadicus]

:FOR will not affect what :NEEDS matches on. Only (a) and © are correct. (dll name or folder name)

:FOR is just used for scheduling which pass the patch is applied in. There's 5 passes...<snip>

Just for kicks, I tested this:

@PART[longAntenna]:FOR[MakingThingsExpensive]
{
	@cost *= 20
}

@PART[longAntenna]:FOR[MakingThingsInexpensive]:NEEDS[MakingThingsExpensive]
{
	@cost /= 2
}

No folders or dlls installed named "MakingThingsExpensive", but MakingThingsInexpensive does resolve its NEEDS and is applied.

[NathanKell]

I have an idea: post the log! We can't magically figure out what's going on without information.

It's almost certain not to be MM; all MM will be doing is changing configs, and presumably when you remove MM all your *other* mods get disabled, because they are no longer added to parts, etc.

Cause the problem. Quit KSP (if it hasn't crashed). Upload your output log (NOT ksp.log) to dropbox or something.

Windows: KSP_win\KSP_Data\output_log.txt OR KSP_win64\KSP_x64_DATA\output_log.txt (depending on which used)

Mac OSX: Open Console, on the left side of the window there is a menu that says 'files'. Scroll down the list and find the Unity drop down, under Unity there will be Player.log Aka Files>~/Library/Logs>Unity>Player.log

Linux: ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log

[Bison Steve]

I have an idea: post the log! We can't magically figure out what's going on without information.

It's almost certain not to be MM; all MM will be doing is changing configs, and presumably when you remove MM all your *other* mods get disabled, because they are no longer added to parts, etc.

Cause the problem. Quit KSP (if it hasn't crashed). Upload your output log (NOT ksp.log) to dropbox or something.

Windows: KSP_win\KSP_Data\output_log.txt OR KSP_win64\KSP_x64_DATA\output_log.txt (depending on which used)

Mac OSX: Open Console, on the left side of the window there is a menu that says 'files'. Scroll down the list and find the Unity drop down, under Unity there will be Player.log Aka Files>~/Library/Logs>Unity>Player.log

Linux: ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log

As I said, it is doing it when MM is the ONLY mod on as well. It is crashing without leaving a log, or I would have posted that. Can I get a useful idea, or just more sarcasm?

[toadicus]

As I said, it is doing it when MM is the ONLY mod on as well. It is crashing without leaving a log, or I would have posted that. Can I get a useful idea, or just more sarcasm?

It's likely that no one can help you without more information. KSP keeps logs at those locations during every run, with or without crashes: if there is anything in those files, it may be more useful towards solving your problem than nothing at all. Thousands and thousands of people use ModuleManager every day without it crashing their games: if anyone is going to help you we need to know what makes your situation different, and "it crashes" isn't enough distiction.

The only idea I have without more information is: do you have any .cfg files in your GameData folder that do not have any nodes (e.g. PART {} or @PART {} ) in them? KSP doesn't like empty .cfg files.

[Starwaster]

Just for kicks, I tested this:

@PART[longAntenna]:FOR[MakingThingsExpensive]
{
    @cost *= 20
}

@PART[longAntenna]:FOR[MakingThingsInexpensive]:NEEDS[MakingThingsExpensive]
{
    @cost /= 2
}

No folders or dlls installed named "MakingThingsExpensive", but MakingThingsInexpensive does resolve its NEEDS and is applied.

Thanks for demonstrating that! That Could be a boon or a curse. It could offer more flexibility but it also makes means that :NEEDS is less reliable in determining if a mod is really installed or not. Any config containing FOR will make future NEEDS invalid. Yeah, curse, not boon. Does it do it for BEFORE and AFTER?

As I said, it is doing it when MM is the ONLY mod on as well. It is crashing without leaving a log, or I would have posted that. Can I get a useful idea, or just more sarcasm?

Ok heres the thing, Bison Steve. If you come in to any thread asking others for help or reporting a bug, then You will let us decide if we need logs or not and which logs we need. Nobody cares if you crashed or not. I'm not trying to be mean and that's candor and not sarcasm. output_log.txt (or player.log for linux or mac) contain too much useful information to do without. Period.

Clarification: Logs are always left behind. Crash or not. If you don't know where to find your log then say that and we'll tell you where.

Edited July 25, 2014 by Starwaster

[NathanKell]

Starwaster, that was in from the original design; originally, the *only* way to declare a mod to exist was to have FOR[] nodes for it. Later support for detecting based on plugin and on path were added.

This is why a mod, and only that mod, shoul use FOR nodes.

Also: the internal order for the loop goes:

All mods wtih DLLs

All mods declared by FOR

All cfgs in folders (detect mod name from folder)

For each mod, do BEFORE[that], FOR[that], AFTER[that].

[DuoDex]

Working for 0.24.1?

[Starwaster]

Getting an error that ModuleManager, FAR, and "aaa_Toolbar" are not compatible when starting up the game. Compatibility issue?

If you just updated to 0.24.1, you can probably ignore it. The version number changed so it's setting off warnings. Assume that it's ok but watch out for new bugs to appear.