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

[Superfluous J]

25 minutes ago, sebi.zzr said:

@5thHorseman,why do you struggle so much,just remove resource definition.If there is no definition the resource not exist.

!RESOURCE_DEFINITION[Ore]
{
}

 

I'll try that. It was actually the ultimate goal but I thought (incorrectly?) that just removing the resource definition without also taking care of planetary resources, tank resources, etc would cause problems.

Of course, it can't cause much more problems than I'm having now - considering I've all but thrown in the towel on it due to the fact that the bugginess seems part of the stock game. In that if I remove Ore from the stock ore.cfg and put something else in instead, it fails in the same way as it did with ModuleManager.

EDIT: Nope @sebi.zzr that has the same effect that removing the GLOBAL_RESOURCE had: It does in fact remove ore from the planets but it does not allow (or removes, I can't tell) all other resources I try to add as well.

It really does seem that when it comes to planetary crusts, it's ore or nothing.

Edited January 12, 2017 by 5thHorseman

[sebi.zzr]

24 minutes ago, 5thHorseman said:

In that if I remove Ore from the stock ore.cfg and put something else in instead, it fails in the same way as it did with ModuleManager.

I see.Well if this is only for your use,you could remove "ore.cfg" from resource folder,because MM can't find "GLOBAL_RESOURCE".

[Sigma88]

@5thHorseman

sorry, forgot about the curly brackets

!GLOBAL_RESOURCE:HAS[#ResourceName[Ore]]:FINAL {}

this *should* work

 

[Superfluous J]

2 hours ago, Sigma88 said:

@5thHorseman

sorry, forgot about the curly brackets

!GLOBAL_RESOURCE:HAS[#ResourceName[Ore]]:FINAL {}

this *should* work

 

I totally agree that it should. But it doesn't. The only thing I've got to work consistently is to set all the "distribution" parameters to zero.

In the original config. A Module Manager config won't cut it.

Seriously there's something wonky here I just don't know what it is.

[Sigma88]

11 minutes ago, 5thHorseman said:

I totally agree that it should. But it doesn't. The only thing I've got to work consistently is to set all the "distribution" parameters to zero.

In the original config. A Module Manager config won't cut it.

Seriously there's something wonky here I just don't know what it is.

have you checked the cache to see if the module gets actually deleted?

[Pappystein]

Just looking for confirmation on what I THINK I have already discovered

!MODULE[ModuleEngine*] {}

and

!MODULE[ModuleEngine*]

{}

Are not the same.  The First Example will delete any module that starts with the name ModuleEngine, the second will do nothing?    My currently MMed engines all are showing two engines in KSP at the moment using the 2nd set of code.  

TIA!

[Phineas Freak]

@Pappystein if you leave a blank line between the MM check and the brackets then the patch will fail (invalid syntax) and wil not operate. The first one is correct though.

Edited January 12, 2017 by Phineas Freak

[Sigma88]

@Pappystein

I'm not sure about what @Phineas Freak said but regarding your first example it won't delete all modules with that name

Only the first one

 

Maybe if you use that code to delete root nodes it will delete all of them, but I am not sure

[sebi.zzr]

6 hours ago, Sigma88 said:

have you checked the cache to see if the module gets actually deleted?

I checked that yesterday and the patch don't get applied,because MM don't see "GLOBAL_RESOURCE".There is no such parameter in cache.

[Phineas Freak]

@Sigma88 The second patch has a blank line:

!MODULE[ModuleEngine*]
<----- Blank line
{} 

MM will fail to compile that patch. I am assuming that that is the actual way that the patch is written and not:

!MODULE[ModuleEngines*]
{
}

@Pappystein And a bit of a failure on my part: the first patch will delete only the first ModuleEngines(FX/RF) that MM will find in the config. In order to delete all engine modules then you need to use a second wildcard:

!MODULE[ModuleEngines*],*{}

 

Edited January 12, 2017 by Phineas Freak

[Pappystein]

3 minutes ago, Phineas Freak said:

@Sigma88 The second patch has a blank line:

!MODULE[ModuleEngine*]
<----- Blank line
{} 

MM will fail to compile that patch.

@Pappystein And a bit of a failure on my part: the first patch will delete only the first ModuleEngines(FX/RF) that MM will find in the config. In order to delete all engine modules then you need to use a second wildcard:

!MODULE[ModuleEngines*],*{}

 

 

7 minutes ago, Sigma88 said:

@Pappystein

I'm not sure about what @Phineas Freak said but regarding your first example it won't delete all modules with that name

Only the first one

 

Maybe if you use that code to delete root nodes it will delete all of them, but I am not sure

Thanks again to both of you for answering.   I am currently only deleting a singular ModuleEngines* so the original code is OK.  I will keep the second argument in mind for the future though!   I am trying to make a patch for Bluedog_DB to give me several variants of the Delta Upper stage powered by their actual fuels.   I have the engines working with the old code but Mechjeb and all other similar mods do not detect ISP because the first engine is the stock LF engine module I am trying to delete.

Edited January 12, 2017 by Pappystein

[Sigma88]

Another option would be to use

:HAS[#name[ModuleEngines*]]

 

That will target all modules instead of just the first

[Phineas Freak]

@Pappystein another way is to target the specific module in the index:

!MODULE[ModuleEngines*],0{}

This will delete the first ModuleEngines(FX/RF) instance of the part config. The indexes are zero-based, so 0 = First, 1 = Second etc.

Edit: ninja'ed by @Sigma88

Edited January 12, 2017 by Phineas Freak

[blowfish]

If putting a blank line between the node name and the brackets causes an error, then that's the fault of KSP's cfg parsing code, not MM.

[Jenyaza]

Just noticed: PART{} node has attachRules parrameter.

For example, part KIS_bomb1 has

_           attachRules = 0,1,0,0,0
stack attachment allowed /\
radial attachment allowed  /\

Looks like you solving problem with node_attach, but maybe it helps too

[Enceos]

Does ! exclamation mark blacklisting work on # nodes?

I want to write a patch which adds a node_attach line if it is not present.

@PART[*]:HAS[!#node_attach[*],MODULE[ModuleKISItem]]:FOR[KIS]
{
   node_attach = 0.0, -0.1, 0.0, 0.0, -1.0, 0.0, 1
}

 

[Sigma88]

11 minutes ago, Enceos said:

Does ! exclamation mark blacklisting work on # nodes?

I want to write a patch which adds a node_attach line if it is not present.

@PART[*]:HAS[!#node_attach[*],MODULE[ModuleKISItem]]:FOR[KIS]
{
   node_attach = 0.0, -0.1, 0.0, 0.0, -1.0, 0.0, 1
}

 

You have to use ~ (which means "does not have")

:HAS[~XXX[123]]

Edited January 14, 2017 by Sigma88

[Enceos]

@Sigma88 Never knew about that syntax. Does this look good?

@PART[*]:HAS[~#node_attach[*],MODULE[ModuleKISItem]]:FOR[KIS]
{
   node_attach = 0.0, -0.1, 0.0, 0.0, -1.0, 0.0, 1
}

[Sigma88]

25 minutes ago, Enceos said:

@Sigma88 Never knew about that syntax. Does this look good?

@PART[*]:HAS[~#node_attach[*],MODULE[ModuleKISItem]]:FOR[KIS]
{
   node_attach = 0.0, -0.1, 0.0, 0.0, -1.0, 0.0, 1
}

No

Just ~ instead of ~#

 

[Enceos]

@Sigma88 MM takes neither ~ nor ~# in my case. During loading it says that it found an error in my config. I tried all kinds of combinations but to no avail.

[Sigma88]

12 minutes ago, Enceos said:

@Sigma88 MM takes neither ~ nor ~# in my case. During loading it says that it found an error in my config. I tried all kinds of combinations but to no avail.

@PART:HAS[~node_attach[*]] {}

this means "any PART that does NOT have any node_attach"

[Enceos]

2 minutes ago, Sigma88 said:

@PART:HAS[~node_attach[*]] {}

this means "any PART that does NOT have any node_attach"

It seems to work if I remove the check for the ModuleKISItem. But how do I keep both checks?

[Sigma88]

Just now, Enceos said:

It seems to work if I remove the check for the ModuleKISItem. But how do I keep both checks?

ah yes

you are missing an @

@MODULE instead of just MODULE

[Enceos]

17 minutes ago, Sigma88 said:

ah yes

you are missing an @

@MODULE instead of just MODULE

I got rusty, how could I miss such a thing  thank you, man!

EDIT: @Sigma88 Lol, strange things happen. MM still doesn't like the patch with the module check. I'm trying to feed him this:

EDIT2: forget it  an extra space after the comma was killing it for me.

Edited January 14, 2017 by Enceos

[TheRagingIrishman]

7 hours ago, Enceos said:

Does ! exclamation mark blacklisting work on # nodes?

I want to write a patch which adds a node_attach line if it is not present.

@PART[*]:HAS[!#node_attach[*],MODULE[ModuleKISItem]]:FOR[KIS]
{
   node_attach = 0.0, -0.1, 0.0, 0.0, -1.0, 0.0, 1
}

 

You should use needs instead of for.