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

[Lisias]

On 6/10/2024 at 1:38 PM, lBoBl said:

Hello, I'm struggling to remove entire parts from the game, I'm trying this but it doesn't work

!PART[KKAOSS_Storage_Metal]:FINAL
!PART[KKAOSS_MetalOreDrill]:FINAL
!PART[KKAOSS_Storage_RocketParts]:FINAL
!PART[KKAOSS_PartRecycler]:FINAL
!PART[KKAOSS_ScrapMetal]:FINAL
!PART[KKAOSS_Smelter]:FINAL

I suspect more than one thing is wrong with this syntax because I've tried making changes but none have worked

Any help would be greatly appreciated. Thanks!

Edit: figured it out, I forgot the {}

You can't remove "root nodes", it's a limitation of MM (never bored to check exactly why, it was almost surely related to how Unity manages the prefab - I doubt they ever foresaw the need to remove something from there!). EDIT: I was wrong! You can!

And you forgot the "{ }" anyway, so you have a syntax problem too.

Spoiler

But you can rename the node itself!

@PART[foobar]:FINAL
{
	|_ = PARTDELETED
}

This will change the nodes name from PART to PARTDELETE, and since KSP don't know what's a PARTDELETE, it will just ignore the whole node - effectively removing he part from the database.

edit: You can't rename ROOT NODES neither!!! (krap).
 

--- -- - POST EDIT - -- ---

That said, why not just hide them? The meshes and textures are going to be loaded anyway, there's no real savings (in load time or memory) by doing it, and it will break eventual craft files and savegames that may be using them.

How about

@PART[KKAOSS_Storage_Metal,KKAOSS_MetalOreDrill,KKAOSS_Storage_RocketParts,KKAOSS_PartRecycler,KKAOSS_ScrapMetal,KKAOSS_Smelter]:FINAL
{
	%TechHidden = True
	%category = none
	%subcategory = 0
}

This will make the part hidden, and only already existent crafts will be able to use them.

Edited June 14 by Lisias
POST EDIT

[lBoBl]

20 hours ago, Lisias said:

You can't remove "root nodes", it's a limitation of MM (never bored to check exactly why, it was almost surely related to how Unity manages the prefab - I doubt they ever foresaw the need to remove something from there!).

Oh then I suspect something weird is happening, because it seems to be working at the moment. I just added the { } and that was it. I knew there was a patch in MKS that did pretty much what I wanted to do, which was to remove Extraplanetary Launchpads parts that are made redundant by MKS. I found said patch, and it isn't working anymore because the parts from EPL have been renamed (prefixed with EL to avoid conflicts with other parts I presume). I just copied the syntax from the patch which seems to delete the entire parts. Idk if that might cause problems and if it would be better to hide the parts instead...

[JonnyOThan]

On 6/13/2024 at 10:41 AM, Lisias said:

You can't remove "root nodes", it's a limitation of MM

No that's 100% incorrect.  ConfigNodes have nothing to do with Unity or prefabs either.

 

3 hours ago, lBoBl said:

Idk if that might cause problems and if it would be better to hide the parts instead...

Generally hiding/deprecating parts is preferred because if the part is deleted then any craft files or vessels that use it will have problems.

Edited June 14 by JonnyOThan

[Lisias]

1 hour ago, JonnyOThan said:

No that's 100% incorrect. 

I will be damned, you are right! Deleting is allowed! Renaming, replacing, creating,  pasting and "special" are the ones not allowed! But deleting is!!

https://github.com/sarbian/ModuleManager/blob/c4561925f983e7ae81d9dfd4d11356a35cb6b9b6/ModuleManager/PatchExtractor.cs#L50

Command command = CommandParser.Parse(urlConfig.type, out string name);
                
                if (command == Command.Replace)
                {
                    progress.Error(urlConfig, $"Error - replace command (%) is not valid on a root node: {urlConfig.SafeUrl()}");
                    return null;
                }
                else if (command == Command.Create)
                {
                    progress.Error(urlConfig, $"Error - create command (&) is not valid on a root node: {urlConfig.SafeUrl()}");
                    return null;
                }
                else if (command == Command.Rename)
                {
                    progress.Error(urlConfig, $"Error - rename command (|) is not valid on a root node: {urlConfig.SafeUrl()}");
                    return null;
                }
                else if (command == Command.Paste)
                {
                    progress.Error(urlConfig, $"Error - paste command (#) is not valid on a root node: {urlConfig.SafeUrl()}");
                    return null;
                }
                else if (command == Command.Special)
                {
                    progress.Error(urlConfig, $"Error - special command (*) is not valid on a root node: {urlConfig.SafeUrl()}");
                    return null;
                }

Good to know you are double guessing all my posts, I will rest assured that any mistakes will not pass unchecked!!

Sorry for the mistake, @lBoBl! I think the age is starting to bite

Edited June 14 by Lisias
Tyops, as usulla...

[dave1904]

How do I find where the module manager warnings are in the log. I was working on something last month and forgot where I was and now I don't know what patch file it is :))) Warning and not Errors. 

[Lisias]

Weird how nobody cared to answer this simple question before... Had I not came here due a support I'm doing...

On 6/18/2024 at 5:20 PM, dave1904 said:

How do I find where the module manager warnings are in the log. I was working on something last month and forgot where I was and now I don't know what patch file it is :))) Warning and not Errors. 

Module Manager saves a copy of the patching log into a file called <KSP-ROOT-DIR>/Logs/ModuleManager/MMPatch.log .

Open it using a good text editor like Notepad++ and search for lines starting with [WRN (yeah, all caps, starting with a left bracket).

[dave1904]

11 hours ago, Lisias said:

Weird how nobody cared to answer this simple question before... Had I not came here due a support I'm doing...

Module Manager saves a copy of the patching log into a file called <KSP-ROOT-DIR>/Logs/ModuleManager/MMPatch.log .

Open it using a good text editor like Notepad++ and search for lines starting with [WRN (yeah, all caps, starting with a left bracket).

Cheers. BTW. What is the difference between a module manager error and a warning? 

[JonnyOThan]

2 hours ago, dave1904 said:

Cheers. BTW. What is the difference between a module manager error and a warning? 

Errors are typically a value that failed to be pasted/copied.  Most importantly, if you have any patching errors then the configcache doesn’t get created and your startup times will be longer.  Warnings are incorrect but non fatal syntax in a patch - usually stuff like multiple NEEDS blocks (only the first is used), multiple pass specifiers. Etc.  The mod author goofed up and something might not be working the way they intended, but it also could be fine.

[Lisias]

On 6/14/2024 at 11:07 AM, JonnyOThan said:

No that's 100% incorrect.  ConfigNodes have nothing to do with Unity or prefabs either.

[snip]

ConfigNodes are an inhouse serialization solution on KSP, and I never implied that it was a Unity thing. I cogitated (wrongly, granted) that some MM rules should be related to Unity's handling of the prefab, because the ConfigNodes are a tool to customize data used to instantiate some specialized GameObjects inside KSP, and such data are called prefab.

As an example, and again, check the API:

Quote

Part AvailablePart.partPrefab

A reference to the part prefab for instantiation

https://www.kerbalspaceprogram.com/ksp/api/class_available_part.html#a9eddfffd5104378fa0661f40ae7d57b7

Even by KSP internally replacing (just a hypothesis, I didn't read KSP's Source Code) completely the Unity's prefab with its own solution, also called prefab, it's still called prefab and it's directly associated to ConfigNodes - please note that the stock Parts are defined by ConfigNodes.

Your efforts are appreciated, but please be aware that merely reading the Manual is not enough. Sometimes not even reading the Source is enough - experience on the field is the source of the knowledge, as the code and the manual are consequences of such knowledge and not rarely there's not a 1 to 1 correlation between them.

 

On 6/22/2024 at 4:24 AM, dave1904 said:

Cheers. BTW. What is the difference between a module manager error and a warning? 

A good answer was already provided, but I want to add that the source of the problem (being a error or a warning) is not always the author's fault. Anything wrong on any ConfigNode in the system can lead to an ERROR or a WARNING being issued on your patch.

For example, some time ago some Config files from Stock had a merger error (some "===========" strings scattered on the file) and this, obviously, changed the content of that specific Node, as the processing of it was silently aborted (a terrible mistake, but unfortunately it's the usual M.O. on this scene - some devs just keep processing ignoring the error, hoping nothing important get broke and that Heavens will provide). Patches relying on that information that were not processed on that specific KSP version due that unfortunate mistake, obviously, failed to be applied correctly (sometimes due an ERROR, sometimes due an WARNING). And this wasn't the patch's author fault.

So, rule of thumb: MM complains are, usually, something you did wrong because, well, we (humans) just err our way into success - it's how we work. But you should never silently assume it's on you the cause, because now and then the problem is a mistake made by someone else somewhere else, planting a land mine that you just had the bad luck to step on.

It's not that bad nowadays because development essentially stopped in the last 18 months (more or less) for the majority of the cases - but now with new kids on the block wetting their feet on KSP's development again, that same old problems we had in the past will come back from the Death to haunt us again (#michaelJacksonThrillerFeelings)

Quote

"Due my strong personal convictions, I want to stress that this post in no way endorses a belief in the occult.
(other than Krakens, of course.)"

 

Edited July 1 by Snark
Redacted by moderator

[dave1904]

1 hour ago, Lisias said:

A good answer was already provided, but I want to add that the source of the problem (being a error or a warning) is not always the author's fault. Anything wrong on any ConfigNode in the system can lead to an ERROR or a WARNING being issued on your patch.

For example, some time ago some Config files from Stock had a merger error (some "===========" strings scattered on the file) and this, obviously, changed the content of that specific Node, as the processing of it was silently aborted (a terrible mistake, but unfortunately it's the usual M.O. on this scene - some devs just keep processing ignoring the error, hoping nothing important get broke and that Heavens will provide). Patches relying on that information that were not processed on that specific KSP version due that unfortunate mistake, obviously, failed to be applied correctly (sometimes due an ERROR, sometimes due an WARNING). And this wasn't the patch's author fault.

So, rule of thumb: MM complains are, usually, something you did wrong because, well, we (humans) just err our way into success - it's how we work. But you should never silently assume it's on you the cause, because now and then the problem is a mistake made by someone else somewhere else, planting a land mine that you just had the bad luck to step on.

It's not that bad nowadays because development essentially stopped in the last 18 months (more or less) for the majority of the cases - but now with new kids on the block wetting their feet on KSP's development again, that same old problems we had in the past will come back from the Death to haunt us again (#michaelJacksonThrillerFeelings)

I'm pretty good at using module manager but warnings are something that I almost never encounter. Errors all the time. Typos for the most part. It was a contract pack that is giving me a warning. I changed something and forgot what but its working. I dont care enough about contracts to fix it for now. 

[JonnyOThan]

[Snip]

What, when I said ConfigNodes have nothing to do with prefabs?

Sorry, I thought it was obvious that KSP’s code generates the part prefabs from the PART config nodes.

What I meant was that there is no direct link.  ModuleManager only deals with ConfigNodes and therefore it does not care what the KSP code does with them afterwards.

Edited July 1 by James Kerman
Redacted by a moderator

[Lisias]

51 minutes ago, JonnyOThan said:

Sorry, I thought it was obvious that KSP’s code generates the part prefabs from the PART config nodes.

What I meant was that there is no direct link.  ModuleManager only deals with ConfigNodes and therefore it does not care what the KSP code does with them afterwards.

Your mistake was exactly that. ConfigNodes are a KSP thingy, not MM's. MM handles an (ab)use of the ConfigNode syntax in a way to create a special notation to allow it to patch whatever is created at load time into memory (and that it's called prefab by the KSP API) by KSP using the config nodes.

So, yeah, there's a direct link between KSP's prefab and Config Nodes on KSP, and MM (ab)uses this link to do its magic - AFTER KSP had loaded them into memory, and not before or while. MM does not handle Config Files, it works with whatever was already loaded by KSP into the prefab. So, in a nutshell, MM only really handles the prefab.

It's imperative to understand this, otherwise you will not be able to understand why sometimes MM fails to cope with some errors - the problem is not alwaysMM, but the code that reads ConfigNodes from Config files that fails to generate the prefab data MM needs to work with.

 

[Fizzlebop Smith]

There should be a comprehensive thread for module manager patch collections & requests.

Seeing as many many mods use module manager... and sometime a single mod not is the result of the issue.. but a combination of.

Having such a place would ensure I don't accidently enter into someone else thread request assistance for something.

I mean I know essentially..99% of QOL additions are MM "patches".. but I do not know the trade language for those patches that act as compatibility fixes.

I've been pouring over spacedock and searching around when the problem arises.. some of it is trying to get outdated mods working & not wanting to necro.

This being a thread for modul manager itself.. I feel it's use is prolific enough to justify a MM patch thread... but who knows I say stupid shot all the time.

Maybe a Comprehensive List of Kerbal Patches..

CLOPK

Edited June 30 by Fizzlebop Smith

[Krakatoa]

It exists already.

[JonnyOThan]

[snip]

On 6/30/2024 at 12:28 PM, Lisias said:

MM does not handle Config Files, it works with whatever was already loaded by KSP into the prefab

100% incorrect. MM deals with the ConfigNodes (I never said files) that are loaded into the GameDatabase.  This isn’t called a prefab.  I suggest searching for “prefab” in MM’s source code. There’s one tiny bit regarding fixing drag cubes which is only active in KSP 1.6.0.

 

Edited July 1 by Snark
Redacted by a moderator

[Fizzlebop Smith]

2 hours ago, Krakatoa said:

It exists already.

Thank you...

This is the greatest thing I never knew Existed. 

Edited July 1 by Fizzlebop Smith

[Krakatoa]

20 minutes ago, Fizzlebop Smith said:

Thank you...

This is the greatest thing I never knew Existed. 

Thread title makes it look old, and some of the patches will certainly be from an earlier time in the development of MM, but I imagine it is still the best place to keep that info consolidated and to talk about best practices.

[ttikkoo]

1 hour ago, Krakatoa said:

Thread title makes it look old, and some of the patches will certainly be from an earlier time in the development of MM, but I imagine it is still the best place to keep that info consolidated and to talk about best practices.

I can confirm that a lot of the patches in the first post still work in 1.12.5 even though that post hasn't been updated in several years. I added a bunch to my game a couple of weeks ago and they've been working very smoothly.

There is also this:

 

[James Kerman]

Some content has been removed, this is a public forum and all members have the right to comment in all threads provided content is not in breach of the forum guidelines. We also do not allow personal attacks so please keep the discussion civil

[Lisias]

[snip]

Again, see the KSP's API:

Quote

Part AvailablePart.partPrefab

A reference to the part prefab for instantiation

https://www.kerbalspaceprogram.com/ksp/api/class_available_part.html#a9eddfffd5104378fa0661f40ae7d57b7

Whatever MM does, it reflects on the AvailablePart.partPrefab . Such data is worked by MM using the GameDatabase helper - so, by inference, the GameDatabase is the tool used to inject data into the Part's Prefab. Logical Conclusion - MM uses Config Nodes to rework the Prefab.

[snip]

Edited July 1 by Snark
Redacted by moderator

[JonnyOThan]

[snip]

ModuleManager takes the ConfigNodes  from the GameDatabase and modifies them.  That's ALL it does.  It does not touch prefabs.  Again, please go read the source code of ModuleManager and show me where it interacts with prefabs (other than the drag cube part I mentioned).

This should be pretty apparent when you consider that ModuleManager does not have special rules for different types of ConfigNodes.  There are many, many ConfigNodes that do not become prefabs.

[snip] Yes, ConfigNodes are USED by KSP to create the part prefabs.  But that occurs after ModuleManager is done modifying the ConfigNodes.

Edited July 1 by Snark
Redacted by moderator

[JonnyOThan]

2 hours ago, Lisias said:

so, by inference, the GameDatabase is the tool used to inject data into the Part's Prefab

This is also a little bit off (or lacking detail).  The GameDatabase sits at a lower level and deals with ConfigNodes and raw assets like models, textures, and audio (search for part on that page - it's not there).  The PartLoader uses the data from the GameDatabase to create the part prefabs.

So, the total flow is: Config Files -> ConfigNodes in GameDatabase -> ModuleManager patching -> ConfigNodes in GameDatabase -> PartLoader -> Part Prefabs.

Note that parts are NOT the only thing that uses ConfigNodes (I know you know this).  Prefabs are a unity-specific concept, and there are lots of things that use ConfigNodes that are not Unity objects.

Edited July 1 by JonnyOThan

[Lisias]

4 minutes ago, JonnyOThan said:

The PartLoader uses the data from the GameDatabase to create the part prefabs.

And since MM is a tool to mangle with the GameDatabase, it's the reason I'm claiming MM is a tool to rework the prefab!!

[R-T-B]

I hate to fuel this, but...  yeah.  Unity Prefabs are actually a technical term and thing, and indeed config nodes have nothing to do with them.  It's like saying ini files contain code.  They don't.

[Snark]

Further content has been redacted and/or removed, due to personal remarks and off-topic "arguing about arguing".

Folks, please don't make things personal.  In an open community like this, you will encounter people who disagree with you, and arguments will result.  This is fine, and is to be expected.  But please keep a few things in mind:

• It's about the post, not the poster.  Please contain your remarks to the objective topic under discussion, and don't let your irritation with the person sucker you into making personal remarks.  It never ends well.
• In that vein:  Please address the person's points.  How they choose to make those points, and their style of writing or argument, is not your concern.  If you think that someone is so egregiously rude that they're breaking forum rules, then please file a report and the moderators will have a look.  It's what we're for.  Beyond that, though, it's not your place to tell anyone else how to be, so please don't.
• Try to stay germane to the topic, please, which is this mod.  Arguing about how someone else argues, or defending your own behavior, is off-topic.
• Please bear in mind that if you're rat-holing on some esoteric technical point, 99%+ of the people here will have no interest in it because they're unaffected.  Doesn't mean you can't discuss it, but a lengthy esoteric technical argument doesn't help people.  Quite the opposite.  Please don't drown people in matters that don't concern them.

The debate about ModuleManager and prefabs, in particular, appears (AFAICT) to have run its course, here.  I'm seeing tons of vociferous, heated yes-it-is no-it-isn't technical arguments about prefab minutiae, none of which (AFAICT) has anything to do with actually helping a ModuleManager user solve a practical problem.  The argument is all about who's right and who's wrong, which nobody cares about other than the people arguing.

So, with that in mind:  Please drop the prefab argument, folks.  It's not helping.  If you have a concrete recommendation for ModuleManager users-- such as "if you have problem X, you should do Y to resolve it", then by all means post that, because that will actually help people.  But anything else is technobabble that users don't actually need at this point, so if you want to discuss that, take it elsewhere, please.

Thank you for your understanding.