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

[Electrocutor]

1 minute ago, Sigma88 said:

mm patches don't target cfgs, they target nodes.

@PART[*]:FOR[zzzVSRPathPatch]

So the FOR keyword does not require that some mod exists with that name, but instead gives this cfg a name that decides when it will be applied in alphabetical order?

It looks like Ven's cfg is set to apply to all parts at the end if that is the case.

[Sigma88]

19 minutes ago, Electrocutor said:

@PART[*]:FOR[zzzVSRPathPatch]

So the FOR keyword does not require that some mod exists with that name, but instead gives this cfg a name that decides when it will be applied in alphabetical order?

It looks like Ven's cfg is set to apply to all parts at the end if that is the case.

Exactly

EDIT: technically not to all parts, *only* those that have a name (which is usually all of them)

Edited December 13, 2017 by Sigma88

[Starwaster]

1 hour ago, Sigma88 said:

Exactly

EDIT: technically not to all parts, *only* those that have a name (which is usually all of them)

If a PART exists then it has a name. It's possible to encounter some node like stores that don't have names, PART isn't one of them being a named config node

2 hours ago, Electrocutor said:

@PART[*]:FOR[zzzVSRPathPatch]

So the FOR keyword does not require that some mod exists with that name, but instead gives this cfg a name that decides when it will be applied in alphabetical order?

It looks like Ven's cfg is set to apply to all parts at the end if that is the case.

Also, if FOR[someModName] doesn't actually exist as a mod, the use of it as an execution pass will also result in :NEEDS[someModName] being met just as though someModName were installed, even if it is not installed.

[Sigma88]

@Starwaster that's not necessarily true

For example:

1- a mod could create a nameless PART to avoid getting targeted by those patches that use @PART[*] and provide a name later in the patching process

2- a mod could just have bad configs (this has actually happened to me)

 

Granted, these are pretty rare occasions, and in fact that's why I said it usually doesn't happen

[Nightside]

7 hours ago, Sigma88 said:

@PART:HAS[#title[fuelTank]]

is the "#" needed for this to work? I think I've been doing this:

@PART:HAS[title[fuelTank]]

does that have the same effect?

[Sigma88]

4 minutes ago, Nightside said:

is the "#" needed for this to work? I think I've been doing this:

as far as I know you need # to tell MM "title" is a key inside the PART 

4 minutes ago, Nightside said:

 

@PART:HAS[title[fuelTank]]

does that have the same effect?

I don't think this would work, I'm actually surprised it doesn't throw an error

Edited December 13, 2017 by Sigma88

[Starwaster]

4 hours ago, Sigma88 said:

@Starwaster that's not necessarily true

For example:

1- a mod could create a nameless PART to avoid getting targeted by those patches that use @PART[*] and provide a name later in the patching process

2- a mod could just have bad configs (this has actually happened to me)

 

Granted, these are pretty rare occasions, and in fact that's why I said it usually doesn't happen

1. Sorry, I thought we were talking about valid config nodes, not ones that are purposefully crippled (at any stage in the patching process) and there are certainly better ways of dealing with such situations.
2. Same as #1 except not purposefully done; such a config has a more serious problem than whether or not it can be successfully targeted by a Module Manager patch given the issues it would have in the game.

[Sigma88]

7 minutes ago, Starwaster said:

1. Sorry, I thought we were talking about valid config nodes, not ones that are purposefully crippled (at any stage in the patching process) and there are certainly better ways of dealing with such situations.
2. Same as #1 except not purposefully done; such a config has a more serious problem than whether or not it can be successfully targeted by a Module Manager patch given the issues it would have in the game.

I don't know why this is a problem

all I said is that @PART[*]  targets all PART nodes with a name, which is correct

@PART will target all PART nodes regardless of name being defined or not

 

most of the errors I find in cfgs from mods are caused by the fact that people mix up the MM syntax with the KSP objects defined by the cfgs

for example, considering PART nodes "special" when infact they are the same as any other (root) node

 

or misunderstanding the meaning of [*] (which means "with any name" rather than "any of these nodes")

Edited December 14, 2017 by Sigma88

[Starwaster]

@Sigma88 then it probably would have been a good idea to provide a caveat with that to the effect that your statement applied to improperly configured parts (for whatever reason). I likewise don't understand why you would have a problem with me raising concerns over it.

[Sigma88]

8 hours ago, Starwaster said:

@Sigma88 then it probably would have been a good idea to provide a caveat with that to the effect that your statement applied to improperly configured parts (for whatever reason). I likewise don't understand why you would have a problem with me raising concerns over it.

maybe you didn't read my post 

here it is again:

17 hours ago, Sigma88 said:

17 hours ago, Electrocutor said:

@PART[*]:FOR[zzzVSRPathPatch]

So the FOR keyword does not require that some mod exists with that name, but instead gives this cfg a name that decides when it will be applied in alphabetical order?

It looks like Ven's cfg is set to apply to all parts at the end if that is the case.

Exactly

EDIT: technically not to all parts, *only* those that have a name (which is usually all of them)

 

Edited December 14, 2017 by Sigma88

[Electrocutor]

Is there a way to copy nodes between different roots?

for example, something like:

+PART[OldPart]
{
	@name = NewName

	+Child(PART[OldPart2].MODULE[ModuleName])
}

The idea if there are tons of properties set in some other parent node, it'd be easier to just copy them than to re-write it all; it would allow you to pull in any value changes from other mods from it.

[Daniel Prates]

I think this is worth mentioning. 

I reported an error by MM during start-up patching (in this case, planetarybase + TAC LS, which I commented on the KPBS thread).

Other members reported similar errors, and one of them said that the newest MM version is creating the issue. He suggested regressing to 2.8.1.

I did so and the errors stopped immediately! 

I don't know if this was reported already, but it would seem the newest 3.0.x version warrants some inspection!

[SFCGunny313]

Do you have any idea how many players had to revert back to 2.8.1 so we could still play the game?  Your recent "updates" just broke a bunch of mods

[blowfish]

5 minutes ago, SFCGunny313 said:

Do you have any idea how many players had to revert back to 2.8.1 so we could still play the game?  Your recent "updates" just broke a bunch of mods

Yes, sorry about that.  I had hoped that posting a rerelease version well in advance would give mods time to adjust, but evidently that wasn't exactly the case.

Do you have a list of mods you're having issues with?  We've been trying to clean them up after the fact either by notifying the authors or by submitting fixes directly.

[SFCGunny313]

Honestly, I didn't track them all down.  I had 72 errors when I tried loading, so I quit the game, reinstalled 2.8.1 and everything still works fine.

I'm not sure what benefit 3.0.1 brings to the game, but all of the mods seem to work just fine without it, and I'm running in excess of 100 mods (some small tweaks to some very large part packs and visuals)

[blowfish]

3 minutes ago, SFCGunny313 said:

Honestly, I didn't track them all down.  I had 72 errors when I tried loading, so I quit the game, reinstalled 2.8.1 and everything still works fine.

I'm not sure what benefit 3.0.1 brings to the game, but all of the mods seem to work just fine without it, and I'm running in excess of 100 mods (some small tweaks to some very large part packs and visuals)

If you're willing to run with 3.0.1 again, you could post KSP's log here and we can inspect it to see which mods have this issue.

3.0 and 3.0.1 do improve the speed of applying patches, and code changes in them pave the way for future improvements.

Edited December 15, 2017 by blowfish

[Electrocutor]

2 minutes ago, SFCGunny313 said:

Honestly, I didn't track them all down.  I had 72 errors when I tried loading, so I quit the game, reinstalled 2.8.1 and everything still works fine.

I'm not sure what benefit 3.0.1 brings to the game, but all of the mods seem to work just fine without it, and I'm running in excess of 100 mods (some small tweaks to some very large part packs and visuals)

The biggest problem is that previously, a lot of broken syntax was being written that didn't actually work, but was just being ignored by MM. Now a lot of that broken syntax actually throws errors saying that it is broken (and prevents that part from moving forward while broken).

[sarbian]

20 minutes ago, SFCGunny313 said:

Do you have any idea how many players had to revert back to 2.8.1 so we could still play the game?  Your recent "updates" just broke a bunch of mods

Do you have any idea who annoying it is to deal with people who complains about our free work and do nothing beside that ?

Yes, we had was some problems. They will be fixed. If you want a refund feel free to ask for one.

Edited December 15, 2017 by sarbian

[Electrocutor]

So... getting back on topic, is there a way to clone nodes from a different hierarchy instead of just siblings?

[sarbian]

Just now, Electrocutor said:

So... getting back on topic, is there a way to clone nodes from a different hierarchy instead of just siblings?

Indeed there is 

 

[Deddly]

Some rude comments, and replies to them, have been removed from this thread. Thank you for reporting it.

[Electrocutor]

4 minutes ago, sarbian said:

Indeed there is 

 

Okay...

#@MY_NODE_LIBRARY/MODULE[MechJebCore] { }

I assume that @MY_NODE_LIBRARY is the same as @MY_NODE_LIBRARY,0 and is not required that you create an arbitrary node library?

Which means I should be able to use:

#@PART[OldPart2]/MODULE[ModuleName] {}

to pull everything over?

[sarbian]

1 minute ago, Electrocutor said:

Which means I should be able to use:

#@PART[OldPart2]/MODULE[ModuleName] {}

Yes. You could even be more specific with the usual HAS

#@PART[OldPart2]:HAS[#id[something]]/MODULE[ModuleName]:HAS[#value[that]] {}

[Electrocutor]

	#@KSP_TEXTURE_SET[Transparent]/TEXTURE,0
	{
		mesh = Shine
	}

In the above example, the TEXTURE node is copied in, but the additional 'mesh' property is not added. Adding a % before 'mesh' does not change this either. Is this by design or a bug?

[sarbian]

Design. You have to add a patch under it to edit. 

#@KSP_TEXTURE_SET[Transparent]/TEXTURE,0 	{ 	}

@TEXTURE,0 
{
mesh = Shine
}