Jump to content

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


sarbian

Recommended Posts

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.

Link to comment
Share on other sites

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 by Sigma88
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

@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

Link to comment
Share on other sites

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 by Sigma88
Link to comment
Share on other sites

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.
Link to comment
Share on other sites

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 by Sigma88
Link to comment
Share on other sites

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 by Sigma88
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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 by blowfish
Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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 by sarbian
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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]] {}

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.

×
×
  • Create New...