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

[blowfish]

@theJesuit the first one looks correct to me, I’m not sure why it wouldn’t be applying.  I can maybe try it myself tonight though.

[vardicd]

So I noticed today that all my in game waypoints had their icons changed to be Nyan cat. {april fools haha.} but I noticed that even the stock waypoints were changed, which tells me that they can be edited, and I'm guessing that was done with module manager. Can anyone tell me how I can set it up to rename the stock waypoints, the KSC, desert, island, and woomerang. I've always enjoyed making custom waypoints with custom names for my various games {roleplay reasons} and with the immutable, all ways visible stock waypoints, it complicates things for me greatly. Any help or pointers would be greatly appreciated.

[Jso]

10 hours ago, theJesuit said:

Hi esteemed all,

I want to give all probes a little boost in electrical capability.

Can you please give me a pointer as this doesn't work:

	@PART[*]:HAS[@MODULE[ModuleCommand],#CrewCapacity[>0]]
		{	@RESOURCE[ElectricCharge]
			{	@amount *= 5					// 10
				@maxAmount *= 5					// 10
			}
		}

 

 

Probes don't have CrewCapacity > 0. You probably want to use ~CrewCapacity[>0]

[Celthon]

First, please understand that I know little-to-nothing about writing code, changing codes, etc., and changing the 'under-the-hood' stuff in software like this game...I've never used mods or add-ons in a game before...I want to install MechJeb, and MechJeb-For-All, and so need to install this "Module Manager" also...so my question:  when I look for the KSP 'Game Data' folder in my computer it has another folder inside named 'Squad'...

>steamapps>common>Kerbal Space Program>Game Data>Squad

and inside the 'Squad' folder are approx. 20 more folders...do I put the 'Module Manager', 'MechJeb', and 'MechJeb-For-All' files inside the Squad folder, or just inside the 'Game Data' folder but outside of the 'Squad folder?  

Thank you for your time and assistance.

 

[goldenpsp]

3 minutes ago, Celthon said:

First, please understand that I know little-to-nothing about writing code, changing codes, etc., and changing the 'under-the-hood' stuff in software like this game...I've never used mods or add-ons in a game before...I want to install MechJeb, and MechJeb-For-All, and so need to install this "Module Manager" also...so my question:  when I look for the KSP 'Game Data' folder in my computer it has another folder inside named 'Squad'...

>steamapps>common>Kerbal Space Program>Game Data>Squad

and inside the 'Squad' folder are approx. 20 more folders...do I put the 'Module Manager', 'MechJeb', and 'MechJeb-For-All' files inside the Squad folder, or just inside the 'Game Data' folder but outside of the 'Squad folder?  

Thank you for your time and assistance.

 

Gamedata folder

the squad folder is just for all of the stock parts

It should be like

Gamedata

----Mechjecb

----squad

-----modulemanager.dll

etc

It is very important you put them in gamedata exactly as named.  Don't rename folders or change the path.  Some mods zip files have the files in a gamedata folder, in that case you put the CONTENTS of gamedata into your gamedata.

you should never have a situation where your path those

\gamedata\gamedata\mod folder

Edited April 3, 2019 by goldenpsp

[Celthon]

Thank you.

[linuxgurugamer]

@sarbian @blowfish

I have a problem with the copy, specifically as it is used to copy parts.

The problem is that the copy is put in the same location (dir structure??) as the original.  This is a problem when a mod is making significant changes to a copy of a stock part, but the part is still listed as being in the squad directory.

Specifically, the following:

+PART[wingShuttleElevon1]
{
	@name = B9_Elevon1
}

works, but when looking at the structure in the parts list, it is in the same location as the original part (wingShuttleElvon1)

I'm not sure how, but it would be nice to be able to specify which mod directory the copied part should pretend to be from.  This is (as far as I know) only a significant problem with The Janitor's Closet; when I want to see all the parts for the B9 Wings, this part doesn't show up, but it shows up when showing the Squad parts.

I've looked through the documentation, and can't find anything which might help

I also tried specifying the path in the name, like this:

@name = /GilB9Shuttle_Wings/Parts/B9_Elevon1

but it didn't work either

Edited April 5, 2019 by linuxgurugamer

[SilverState]

On 4/1/2019 at 12:22 PM, linuxgurugamer said:

Try this:

@PART[*]:HAS[@MODULE[ModuleCommand]]
{
	@RESOURCE[ElectricCharge]:HAS[#CrewCapacity[>0]]
	{
		@amount *= 5					// 10
		@maxAmount *= 5					// 10
	}
}

and I think this will also work (not tested):

@PART[*]:HAS[@MODULE[ModuleCommand],#CrewCapacity[>0]]
{
	@RESOURCE[ElectricCharge]
	{
		@amount *= 5					// 10
		@maxAmount *= 5					// 10
	}
}

 

The first one won't work because MM will search for CrewCapacity inside the Resource, which it will never find.

The 2nd one does the exact opposite, it will search for all parts that have ModuleCommand and at least CrewCapacity = 1.

Both of these should work:

@PART[*]:HAS[@MODULE[ModuleCommand],#CrewCapacity[0]]

@PART[*]:HAS[@MODULE[ModuleCommand]:HAS[#minimumCrew[0]]]  

The first one will work for all probe cores that have CrewCapacity defined. I believe some modded ones skip that, so MM will also skip patching them.

The 2nd one is a lot more reliable, as all probes have that in common, modded or not.

@Jso His syntax will also work.

Edited April 5, 2019 by SilverState

[blowfish]

1 hour ago, linuxgurugamer said:

@sarbian @blowfish

I have a problem with the copy, specifically as it is used to copy parts.

The problem is that the copy is put in the same location (dir structure??) as the original.  This is a problem when a mod is making significant changes to a copy of a stock part, but the part is still listed as being in the squad directory.

Specifically, the following:

+PART[wingShuttleElevon1]
{
	@name = B9_Elevon1
}

works, but when looking at the structure in the parts list, it is in the same location as the original part (wingShuttleElvon1)

I'm not sure how, but it would be nice to be able to specify which mod directory the copied part should pretend to be from.  This is (as far as I know) only a significant problem with The Janitor's Closet; when I want to see all the parts for the B9 Wings, this part doesn't show up, but it shows up when showing the Squad parts.

I've looked through the documentation, and can't find anything which might help

I also tried specifying the path in the name, like this:

@name = /GilB9Shuttle_Wings/Parts/B9_Elevon1

but it didn't work either

The basic problem is this.  Let's say you have the following part config

PART
{
    name = somePart
    mesh = model.mu
    // ...
}

And some mod creates a copy of it, maybe rescaling and doing other stuff

+PART[somePart]
{
    @name = somePartModified
    %rescaleFactor = 2
    // ...
}

Because the new part config is still associated with the original file, KSP will find the model file correctly.  If it's instead associated with the file of the patch, KSP will fail to find the model (or will find the wrong one if another .mu exists in that folder).

is this the way I would design it from scratch?  Probably not.  Is this the way it's worked since long before I even started touching ModuleManager's code?  Yes.  Are there patches out there that rely on this functionality?  I would guess that the answer is yes.  So this would definitely constitute a breaking change.

[linuxgurugamer]

4 minutes ago, blowfish said:

The basic problem is this.  Let's say you have the following part config

PART
{
    name = somePart
    mesh = model.mu
    // ...
}

And some mod creates a copy of it, maybe rescaling and doing other stuff

+PART[somePart]
{
    @name = somePartModified
    %rescaleFactor = 2
    // ...
}

Because the new part config is still associated with the original file, KSP will find the model file correctly.  If it's instead associated with the file of the patch, KSP will fail to find the model (or will find the wrong one if another .mu exists in that folder).

is this the way I would design it from scratch?  Probably not.  Is this the way it's worked since long before I even started touching ModuleManager's code?  Yes.  Are there patches out there that rely on this functionality?  I would guess that the answer is yes.  So this would definitely constitute a breaking change.

Oh, I know that.  But I was wondering if a new statement could be added, or expanding the functionality of the name, which could reassign the location.  

It would be up to the script author to ensure that any changes made to the location of the new part would not be broken.  For examp,e, in the part I’m copying, the config already specifies the full path to the model by using a MODEL node.

I dont know how difficult it would be to implement the following suggestions:

use the +PART to specify the new path/location as follows:

+PART[part, newpath]

Another possibility could incorporate the path into the line giving the part a new name:

@name = /GilB9Shuttle_Wings/Parts/B9_Elevon1

A third could be a new statement which would specify the path.

As far as I know, none of these suggestions would break any existing parts

[blowfish]

@linuxgurugamer would it work if there was some sort of accessible history of when a copy patch duplicated a node and what the URL of that copy patch was?

[linuxgurugamer]

5 hours ago, blowfish said:

@linuxgurugamer would it work if there was some sort of accessible history of when a copy patch duplicated a node and what the URL of that copy patch was?

Probably not.  Janitor's Closet uses the URL from the part itself during the filtering process

[Poodmund]

Case: Install Janitors Closet on a vanilla install and then install ReStock.

There is no way for Janitors Closet to filter out which parts are ReStock modded parts or untouched vanilla parts.

[blowfish]

5 hours ago, linuxgurugamer said:

Probably not.  Janitor's Closet uses the URL from the part itself during the filtering process

Right, so it would require a change on that side to be able to look at that history (probably you would just want to grab the most recent entry in every case)

[linuxgurugamer]

It's not the end of the world if nothing gets changed, but I do get questions every now and then about where parts are in JC.

And, the example from @Poodmund is exactly what I'm referring to.

[blowfish]

9 minutes ago, linuxgurugamer said:

It's not the end of the world if nothing gets changed, but I do get questions every now and then about where parts are in JC.

And, the example from @Poodmund is exactly what I'm referring to.

Right, but under your proposed solution you'd have to modify every single part in every mod that duplicates to update the URLs.

It doesn't sound like we really need to change what UrlFile the config is associated with, there just has to be a way for JC to determine that the config was created from a patch, and if so what UrlFile the patch belonged to.  So ModuleManager would have something like this:

public class MMUrlFile : UrlDir.UrlFile
{
  public readonly UrlDir.UrlFile mostRecentUrlFile;
}

For most configs, mostRecentUrlFile would be the same as parent, but for a config created from a patch it would point to the UrlFile of the patch.  Then in your code you could do something like this:

Spoiler

public static class UrlFileForUrlConfigFinder
{
  public static UrlDir.UrlFile Find(UrlConfig urlConfig)
  {
    if (urlConfig is ModuleManager.MMUrlConfig mmUrlConfig)
      return mmUrlConfig.mostRecentUrlFile;
    else
      return urlConfig.parent;
  }
}

 

Or if you prefer not to compile against ModuleManager, a simple reflection-based implementation:

Spoiler

public static class UrlFileForUrlConfigFinder
{
  public static UrlDir.UrlFile Find(UrlConfig urlConfig)
  {
    if (urlConfig.GetType().FullName == "ModuleManager.MMUrlConfig")
    {
      FieldInfo field = urlConfig.GetType().GetField("mostRecentUrlFile");
      return (UrlDir.UrlConfig)field.GetValue(urlConfig);
    }
    else
    {
      return urlConfig.parent;
    }
  }
}

(You could potentially add some more error handling to this but it's not strictly necessary)

I'm just throwing ideas around though, there are other ways to accomplish this as well.

[linuxgurugamer]

7 minutes ago, blowfish said:

Right, but under your proposed solution you'd have to modify every single part in every mod that duplicates to update the URLs.

In my view, I didn't think there were too many parts that this would affect.  This was before @Poodmund mentioned ReStock

I can compile against MM, and test before using it if MM is there, if not then use alternative code.  Avoids messy reflection stuff, I've done this in another mod

I guess the question is whether JC is the only mod which this is an issue.  If it is, then doing a targeted solution is fine, if not, then maybe something else.

This is the current code which accesses the URL:

        static public string FindPartMod(AvailablePart part)
        {
            if (configs == null)
                configs = GameDatabase.Instance.GetConfigs("PART");

            Log.Info("ModFilterWindow.FindPartMod, part.name: " + part.name);
            UrlDir.UrlConfig config = Array.Find<UrlDir.UrlConfig>(configs, (c => (part.name == c.name.Replace('_', '.').Replace(' ', '.'))));
            if (config == null)
            {
                config = Array.Find<UrlDir.UrlConfig>(configs, (c => (part.name == c.name)));
                if (config == null)
                    return "";
            }
            var id = new UrlDir.UrlIdentifier(config.url);
            return id[0];
        }

As you can see, I load all the configs locally for speed, I imagine that a dictionary with the key being the part name and the data being the URL would be fast enough to keep up

 

[Jso]

Somewhat related, could these fields be made available to MM patches? The ability to do this would open some possibilities:

@PART:HAS[#parentURL[ModDir/*]]

 

Edited April 5, 2019 by Jso

[DStaal]

2 hours ago, linuxgurugamer said:

I guess the question is whether JC is the only mod which this is an issue.  If it is, then doing a targeted solution is fine, if not, then maybe something else.

I believe it somewhat affects Filter Extensions as well - You can create filters for 'by mod' and they're affected by this, IIRC.

But other than those two, I don't believe it really affects any other mods that I know of.

[blowfish]

@linuxgurugamer You aren't just using part.partInfo.partUrlConfig ?

@Jso theoretically possible, would need to come up with some unique syntax for it though

[linuxgurugamer]

4 hours ago, blowfish said:

@linuxgurugamer You aren't just using part.partInfo.partUrlConfig ?

@Jso theoretically possible, would need to come up with some unique syntax for it though

I don't remember the details, but I think I had to replace both underscores and spaces with a dot, which is why the following is there:

 UrlDir.UrlConfig config = Array.Find<UrlDir.UrlConfig>(configs, (c => (part.name == c.name.Replace('_', '.').Replace(' ', '.'))));

 

[blowfish]

3 hours ago, linuxgurugamer said:

I don't remember the details, but I think I had to replace both underscores and spaces with a dot, which is why the following is there:

 UrlDir.UrlConfig config = Array.Find<UrlDir.UrlConfig>(configs, (c => (part.name == c.name.Replace('_', '.').Replace(' ', '.'))));

 

I get what you're doing, what I'm saying is that there's no need to find it because the AvailablePart stores a reference to it

[linuxgurugamer]

9 hours ago, blowfish said:

I get what you're doing, what I'm saying is that there's no need to find it because the AvailablePart stores a reference to it

It's quite possible it's unnecessary, but I'd have to go digging to be sure there aren't any other things related.

[NermNermNerm]

I'm trying to figure out what I'm doing wrong in...  What I'm trying to do is a little ticklish, but from what I read, it should work.  So, PlanetaryBaseInc defines a Workshop part that only exists with ExtraplanetaryLaunchpads.  In the PBI config, it adds some EPL stuff to the part:

https://github.com/Nils277/KerbalPlanetaryBaseSystems/blob/771ef186b701cdef782ff69597e0b1d04f32ed37/FOR_RELEASE/GameData/PlanetaryBaseInc/ModSupport/Parts/Extraplanetary Launchpads/Workshop.cfg#L102

But I want to use my own mod's production chain instead.  So I wrote this, which should the modules laid down by PlanetaryBaseInc.  Seems to me like a :AFTER clause should ensure it all works...

https://github.com/SteveBenz/ProgressiveColonizationSystem/blob/8c8828417a6d85d636fee5e06a09d57e19be90bd/src/ProgressiveColonizationSystem/GameData/ProgressiveColonizationSystem/KKAOS.cfg#L36

But it doesn't.  And when I look at the logs, I see:

[LOG 2019-04-09 21:49:26.673] :AFTER[PLANETARYBASEINC] pass
[LOG 2019-04-09 21:49:26.673] Applying update ProgressiveColonizationSystem/KKAOS/@PART[KKAOSS_Workshop]:NEEDS[ExtraplanetaryLaunchpads&PlanetaryBaseInc]:AFTER[PlanetaryBaseInc] to PlanetaryBaseInc/ModSupport/Parts/Extraplanetary Launchpads/Workshop.cfg/PART
[LOG 2019-04-09 21:49:26.673] :BEFORE[PLANETARYSURFACESTRUCTURES] pass
...
[LOG 2019-04-09 21:49:26.748] Applying update PlanetaryBaseInc/ModSupport/Configs/KIS/KPBS_MM_KIS/@PART[KKAOSS_Battery_Tank,KKAOSS_Fuelcell_Tank,KKAOSS_Liquid_Fuel_Tank,KKAOSS_Small_Ore_Tank,KKAOSS_RCS_Tank,KKAOSS_small_Rocket_Fuel_Tank,KKAOSS_ScienceJr_Tank,KKAOSS_Xenon_Tank]:FOR[PlanetarySurfaceStructures]:NEEDS[KIS] to PlanetaryBaseInc/ContainerSystem/tank_xenon.cfg/PART
[LOG 2019-04-09 21:49:27.053] Applying update PlanetaryBaseInc/ModSupport/Parts/Extraplanetary Launchpads/Workshop/@PART[KKAOSS_Workshop]:FOR[PlanetarySurfaceStructures]:NEEDS[Launchpad] to PlanetaryBaseInc/ModSupport/Parts/Extraplanetary Launchpads/Workshop.cfg/PART
[LOG 2019-04-09 21:49:27.053] Applying update PlanetaryBaseInc/ModSupport/Parts/KAS/gangway_flexible/@PART[KKAOSS_KAS_Flexible_Corridor]:FOR[PlanetarySurfaceStructures]:NEEDS[KIS] to PlanetaryBaseInc/ModSupport/Parts/KAS/gangway_flexible.cfg/PART
 

...In spite of the :AFTER, it ran my rules before the PBI rule.  Can anybody give me a clue why?

[blowfish]

@NermNermNerm PlanetaryBaseInc is alphabetically before PlanetarySurfaceStructures

Just to clarify, let's say your mod list is mod1, mod2, mod3.  The order of patches will be:

• :FIRST
• legacy (no pass)
• :BEFORE[mod1]
• :FOR[mod1]
• :AFTER[mod1]
• :BEFORE[mod2]
• :FOR[mod2]
• :AFTER[mod2]
• :BEFORE[mod3]
• :FOR[mod3]
• :AFTER[mod3]
• :FINAL