Jump to content

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


sarbian

Recommended Posts

11 minutes ago, lookolookthefox said:

@blowfish @Lisias Thanks for your help! tried both of your suggestions but I've discover that the thing I'm trying to do is pretty much impossible, it involves incompatible modules and i do not have the knowhow to rewrite that kind of stuff.

Post the problem here. Worst it can happen is the three of us end up crying together in shame. :sticktongue:

Link to comment
Share on other sites

@Lisias If you insist :). Basically, I've built this great modpack, but it involves USI life support and MKS, but also a bunch of Nertea's stuff, specifically SystemHeat. The problem arises with how both MKS and SystemHeat work. MKS has a bunch of drills which use a different harvester module due to their resource swapping system, something about requiring materialkits yada yada. Point is that SystemHeat, to implement its changes to the heat system of KSP, replaces the standard harvester modules entirely with a module of its own. This module does exactly the same as the regular harvester other than having a different thermal mechanic. In the end, i can't figure out how to integrate two different resource harvesting modules into a single file. I though about splitting the difference, somehow having both modules in communicating, the systemheat one not mining but doing heat and efficiency calculations, and the USI one not producing heat, but I'm not sure if that is possible at all. Even if it were, I've got no clue how.

Link to comment
Share on other sites

58 minutes ago, lookolookthefox said:

@Lisias If you insist :). Basically, I've built this great modpack, but it involves USI life support and MKS, but also a bunch of Nertea's stuff, specifically SystemHeat. The problem arises with how both MKS and SystemHeat work. MKS has a bunch of drills which use a different harvester module due to their resource swapping system, something about requiring materialkits yada yada. Point is that SystemHeat, to implement its changes to the heat system of KSP, replaces the standard harvester modules entirely with a module of its own. This module does exactly the same as the regular harvester other than having a different thermal mechanic. In the end, i can't figure out how to integrate two different resource harvesting modules into a single file. I though about splitting the difference, somehow having both modules in communicating, the systemheat one not mining but doing heat and efficiency calculations, and the USI one not producing heat, but I'm not sure if that is possible at all. Even if it were, I've got no clue how.

Yeah that's a cry of shame moment. Both USI and SystemHeat use custom modules that extend the ResourceConverter and ResourceHarvester modules. Someone would have to write an entirely new module that implements the functionality of both into one. MM patches can't do anything about it.

Link to comment
Share on other sites

I'm trying to make a patch for the BeamedPower mod that applies a WirelessReceiver module to every single solar panel, using a crude scale factor assuming that panel area is directly proportional to EC/s produced.

.cfg attached, but I'm getting errors and thus far haven't been able to get this patch to work. Any tips for where I'm going wrong?

@PART[*]:HAS[@MODULE[ModuleDeployableSolarPanel]:HAS[#resourceName[ElectricCharge]],!MODULE[ModuleCommand],!MODULE[ModuleEnginesFX],!MODULE[ModuleEngines]]:NEEDS[BeamedPowerStandalone]
{
	// Make all NFS panels beamed energy receivers, assuming 1 EC/s = 1m2 of receiving area
	%EC = #$@MODULE[ModuleDeployableSolarPanel]/chargeRate$
	%Area  = #$EC$
	@Area *= 1
	// Convert to diameter (since beamed power uses that as a measure... assume a circular receiver)
	%Diam  = #$Area$
	@Diam *= 0.318309886
	@Diam != 0.5
	@Diam *= 2

	MODULE
	{
		name = WirelessReceiver
		recvType = Directional
		recvDiameter = #$../Diam$
		recvEfficiency = 0.98
	}

}

Log errors are:

[LOG 17:27:52.929] Applying update zzz_MyCustomPatches/Solar/@PART[*]:HAS[@MODULE[ModuleDeployableSolarPanel]:HAS[#resourceName[ElectricCharge]],!MODULE[ModuleCommand],!MODULE[ModuleEnginesFX],!MODULE[ModuleEngines]]:NEEDS[BeamedPowerStandalone] to Bluedog_DB/Parts/Hexagon/bluedog_Hexagon_SolarPanel.cfg/PART[bluedog_Hexagon_SolarPanel]
[ERR 17:27:52.930] Error - Cannot parse variable search when replacing (%) key EC = #$@MODULE[ModuleDeployableSolarPanel]/chargeRate$
[WRN 17:27:52.930] Cannot find key EC in PART
[ERR 17:27:52.930] Error - Cannot parse variable search when replacing (%) key Area = #$EC$
[WRN 17:27:52.930] Cannot find key Area in PART
[ERR 17:27:52.930] Error - Cannot parse variable search when replacing (%) key Diam = #$Area$
[WRN 17:27:52.930] Cannot find key Diam in PART
[ERR 17:27:52.930] Error - Cannot parse variable search when inserting new key recvDiameter = #$../Diam$

Edit: The line that seems to be causing trouble is the one that pulls the chargeRate from the solar panel module. Not sure why, though.

Edit 2: Fixed it! For anyone else's future reference, I changed the chargeRate line to:
 

%EC = #$/MODULE[ModuleDeployableSolarPanel]/chargeRate$

 

Edited by planeguy868
Link to comment
Share on other sites

4 hours ago, planeguy868 said:

.cfg attached, but I'm getting errors and thus far haven't been able to get this patch to work. Any tips for where I'm going wrong?

Appears to be a limitation on the patching mechanism, you can't edit an attribute using "variable search" on the value side.[no, just an idiosyncrasy on how path works]

How about removing the any previous value before trying the (re)assignment without using operators?

@PART[*]:HAS[@MODULE[ModuleDeployableSolarPanel]:HAS[#resourceName[ElectricCharge]],!MODULE[ModuleCommand],!MODULE[ModuleEnginesFX],!MODULE[ModuleEngines]]:NEEDS[BeamedPowerStandalone]
{
	// Make all NFS panels beamed energy receivers, assuming 1 EC/s = 1m2 of receiving area
	!EC = deleteme 
	EC = #$@MODULE[ModuleDeployableSolarPanel]/chargeRate$
	!Area - deleteme
	Area  = #$EC$
	@Area *= 1
	// Convert to diameter (since beamed power uses that as a measure... assume a circular receiver)
	!Diam = deleteme
	Diam  = #$Area$
	@Diam *= 0.318309886
	@Diam != 0.5
	@Diam *= 2

	MODULE
	{
		name = WirelessReceiver
		recvType = Directional
		recvDiameter = #$../Diam$
		recvEfficiency = 0.98
	}
}

 

Edited by Lisias
fix
Link to comment
Share on other sites

1 hour ago, Lisias said:

Appears to be a limitation on the patching mechanism, you can't edit an attribute using "variable search" on the value side.

How about removing the any previous value before trying the (re)assignment without using operators?


@PART[*]:HAS[@MODULE[ModuleDeployableSolarPanel]:HAS[#resourceName[ElectricCharge]],!MODULE[ModuleCommand],!MODULE[ModuleEnginesFX],!MODULE[ModuleEngines]]:NEEDS[BeamedPowerStandalone]
{
	// Make all NFS panels beamed energy receivers, assuming 1 EC/s = 1m2 of receiving area
	!EC = deleteme 
	EC = #$@MODULE[ModuleDeployableSolarPanel]/chargeRate$
	!Area - deleteme
	Area  = #$EC$
	@Area *= 1
	// Convert to diameter (since beamed power uses that as a measure... assume a circular receiver)
	!Diam = deleteme
	Diam  = #$Area$
	@Diam *= 0.318309886
	@Diam != 0.5
	@Diam *= 2

	MODULE
	{
		name = WirelessReceiver
		recvType = Directional
		recvDiameter = #$../Diam$
		recvEfficiency = 0.98
	}
}

 

Per my edit at the bottom of my post, the issue was as simple as removing the @ in the line that assigns the value of EC and replace it with / (not sure why). That seems to have done the trick!

Link to comment
Share on other sites

2 hours ago, planeguy868 said:

Per my edit at the bottom of my post, the issue was as simple as removing the @ in the line that assigns the value of EC and replace it with / (not sure why). That seems to have done the trick!

Yep, but by them you will have TWO copies of the values, what is not a good idea since usually the first copy is used, not the second one.

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

Wait a bit, I missed the "/" detail. Let me check this myself...

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

The "/" stunt just get rid of the error, but didn't did what you expected. The original values must be there, and I think you created new values those names start with slash. This is not an operator on MM, it's a path separator - I think this may be creating the value somewhere else on the GameDatabase! [edit: on the same level of the patch].

(I will give this stunt a try to see if I'm right!)

Check the Module Manager Config Cache to see the results, it's always recommended to double check things on it just to be on the safe side of the Force. :)

Edited by Lisias
post post edit
Link to comment
Share on other sites

On 4/10/2021 at 9:25 PM, planeguy868 said:

What about appending % in front of EC, Diam, and Area? That way it either creates if they don't exist, or overwrites/edits if they do?

You did it right on the first post, I misunderstood it and ended up getting into your way. Sorry. :blush:

But at least I understood what was happening, what happened and why. :)

So, lets explain your initial approach:

%EC = #$@MODULE[ModuleDeployableSolarPanel]/chargeRate$
Spoiler

I made a hell of a confusion because I misread your statement and thought you were using:

/EC = <blablabla>

(sigh)

it didn't worked because the thing inside the $$ is a path that starts on the root of the gamedatabase. Think of the database as a kinda of file system, and everytime you write something beetwen { } is like creating a subdir on that place.

Well, you want a value on the same level of the value you are creating but the patch you wrote was looking for a "MODULE with name = ModuleDeployableSolarPanel" on the root of the gamedatabase, not on the current level.

Looking on github, I found patches using "../someValue" inside the $$, fetching things on the parent "folder". Since it was on a MODULE, the parent was a PART.

So I tried this:

%EC = #$./@MODULE[ModuleDeployableSolarPanel]/chargeRate$

But it didn't worked, and the reason was simple: the `@` thingy is what was making the thing looking for the MODULE on the gamedatabase root level. It took me some time to realise that the samples I got on github did not used @ at all.

Then I tried this:

%EC = #$./MODULE[ModuleDeployableSolarPanel]/chargeRate$

What I thought it should work, because I found people doing on onversionRate = #$../ROLSCrew$ github. But it didn't.

Then, on a gesture of exasperation, I got rid of the dot:

%EC = #$/MODULE[ModuleDeployableSolarPanel]/chargeRate$

And, now, the freaking thing worked fine. :confused:

So... Rules of thumb:

  • Inside $$, we just use @ when the "path" to the thing starts on the root of the gamedatabase
  • Inside $$,  ../ leads to the upper hierarchy.
    • But the current hierarchy is addressed by a single slash!!
      • (damn!)
  • MM errors messages are terribly misleading!!!

The MM message says it CAN NOT parse the $$ thingy inside a editing/adding/whatever node. This is wrong, the real problem is that MM could not parse THIS $$ thingy because it didn't found it on the gamedatabase. (damn it)

(and I will not even talk about the messy syntax used on this whole stunt - this make Perl looking as Classic Poetry).

Edited by Lisias
uh... need some coffee... =P
Link to comment
Share on other sites

  • 2 weeks later...

is it possible for a MM patch to be dependent on the settings in a .version file?  

My problem is that when @R-T-B adopted  Kopernicus he changed the name of a module  KopernicusSolarPanels to KopernicusSolarPanel, but kept the same KSP versions.  So depending on which version of Kopernicus is installed, a contract pack works if it is the earlier one, and fails if it's the later one.

Thanks in advance

Link to comment
Share on other sites

8 hours ago, linuxgurugamer said:

My problem is that when @R-T-B adopted  Kopernicus he changed the name of a module  KopernicusSolarPanels to KopernicusSolarPanel, but kept the same KSP versions.  So depending on which version of Kopernicus is installed, a contract pack works if it is the earlier one, and fails if it's the later one.

Try something like this on your code:

namespace MYMOD
{
	public static class ModuleManagerSupport
	{
		public static IEnumerable<string> ModuleManagerAddToModList()
		{
			List<string> tags = new List<string>();

			if (checkFor("KopernicusSolarPanels"))	tags.Add("MYMOD-Kopernicus-Classic");
			if (checkFor("KopernicusSolarPanel"))	tags.Add("MYMOD-Kopernicus-RTB");

			return tags.ToArray();
		}
		
		private static bool checkFor(string typeName)
		{
			Type type = Type.GetType(String.format("Kopernicus.Components.{0}, Kopernicus", typeName));
			return null != type;
		}
	}
}

Then on a config file:

SOMETHING:NEEDS[MYMOD-Kopernicus-Classic]
{
	// Define something using classic kopernicus
}

SOMETHING:NEEDS[MYMOD-Kopernicus-RTB]
{
	// Define something using RTB's kopernicus
}

I built this from copy and paste from some personal projects, and I didn't tested it - but anything wrong on the code should be easy to detect and fix on the IDE.

Link to comment
Share on other sites

On 4/19/2021 at 8:57 PM, linuxgurugamer said:

My problem is that when @R-T-B adopted  Kopernicus he changed the name of a module  KopernicusSolarPanels to KopernicusSolarPanel, but kept the same KSP versions.  So depending on which version of Kopernicus is installed, a contract pack works if it is the earlier one, and fails if it's the later one.

From my vague memory on these, I think the difference is one is per-solar-panel-part and the other is per-vessel, can't remember which is which.

Link to comment
Share on other sites

On 4/21/2021 at 3:46 AM, linuxgurugamer said:

I doubt that.  Looks like the module was just renamed.  

I am almost certain of it.  I tried looking for the exact posts I remembered, but could only find various comments in the Kopernicus threads on solar math issues that involved the modules from December to February.  You'd have to get a hold of @R-T-B to get the certain difference between KopernicusSolarPanels and KopernicusSolarPanel.

Link to comment
Share on other sites

11 hours ago, Jacke said:

I am almost certain of it.  I tried looking for the exact posts I remembered, but could only find various comments in the Kopernicus threads on solar math issues that involved the modules from December to February.  You'd have to get a hold of @R-T-B to get the certain difference between KopernicusSolarPanels and KopernicusSolarPanel.

From the git log, they only are renamed.  Maybe the  intent is different, but the actual change was merely a rename.  If there were two, we wouldn't be having these issues

Link to comment
Share on other sites

13 hours ago, HebaruSan said:

Hi @sarbian, looks like the server needs a kick:

i7PRBtp.png

(The same is happening to all of your mods.)

You should have spammed me on Discord :)

It's back online. I really need to rework my hosting...

Thanks

 

Edited by sarbian
Link to comment
Share on other sites

On 4/20/2021 at 8:46 PM, linuxgurugamer said:

I doubt that.  Looks like the module was just renamed.  

No, he's right.  The reason for the rename is the core module code is changed from one per vessel (which did not work, basically) to one per panel.

I apologize for not being more responsive.  My work has been at my heels with the reopening in washington state because we're doing well with the pandemic...  which of course is great news!  For everything but modding... lol.

Link to comment
Share on other sites

3 hours ago, R-T-B said:

No, he's right.  The reason for the rename is the core module code is changed from one per vessel (which did not work, basically) to one per panel.

I apologize for not being more responsive.  My work has been at my heels with the reopening in washington state because we're doing well with the pandemic...  which of course is great news!  For everything but modding... lol.

Ok, the rename may have been for that reason, but there isn't one which replaced the old one.  Which causes problems for other mods who'se patches depended on it.

Link to comment
Share on other sites

4 hours ago, linuxgurugamer said:

Ok, the rename may have been for that reason, but there isn't one which replaced the old one.  Which causes problems for other mods who'se patches depended on it.

There is.  It's an optional cfg that is downloaded only if needed that implements the Kopernicus multistar module.  Otherwise it falls back to pure stock logic.

I can see how that might be problematic for mods actively searching for the module if Kopernicus is present..  I did not think of that scenario.  Apologies.  Advice on how to make this better is welcomed.

Edited by R-T-B
Link to comment
Share on other sites

1 hour ago, R-T-B said:

There is.  It's an optional cfg that is downloaded only if needed that implements the Kopernicus multistar module.  Otherwise it falls back to pure stock logic.

I can see how that might be problematic for mods actively searching for the module if Kopernicus is present..  I did not think of that scenario.  Apologies.  Advice on how to make this better is welcomed.

It's too late now, it's been out this way for a few years now.  

Possibly implement the missing one, duplicating the functionality except when the optional cfg is installed.

Link to comment
Share on other sites

On 5/2/2021 at 12:55 AM, linuxgurugamer said:

It's too late now, it's been out this way for a few years  now.

the problem is not the change, it's changing unexpectedly.  Many Add-ons changed this way in the past, dropping or adding features incompatible with previous versions.

A major version bump and a warning about breaking legacy would had helped, @R-T-B, as well as some pre releases in parallel to wet your feet on how the change will impact the ecosystem, and then use this knowledge to make a smooth transition. 

It's a bit laborious, but feasible.

Link to comment
Share on other sites

Hi, need some help.

The following two patches are generating errors:

@PART[CST-100?Heat?Shield?(Brown)]:HAS[!MODULE[ModuleCargoPart]]:Final
{
    MODULE
    {
        name = ModuleCargoPart
        packedVolume = 11410
    }
}
// ----------------------------------------------------------------------
// CST-100 Starliner/Parts/cstHeatShield/cstHeatShield/CST-100 Heat Shield (Black)
// Bounding Box Size: 10372.55 liters
// Volume adjustment: 10%
//
@PART[CST-100?Heat?Shield?(Black)]:HAS[!MODULE[ModuleCargoPart]]:Final
{
    MODULE
    {
        name = ModuleCargoPart
        packedVolume = 11410
    }
}

The errors are:

[ERR 18:19:47.534] Error - node name does not have balanced brackets (or a space - if so replace with ?):
/partVolumes/@PART[CST-100?Heat?Shield?

[ERR 18:19:47.535] Error - node name does not have balanced brackets (or a space - if so replace with ?):
/partVolumes/@PART[CST-100?Heat?Shield?

Is it because of the parantheses?  If so, then if I replace the parens with questionmarks, it should work, right?

Edit:  I tried replacing the parens with questionmarks, didn't change the error

Edited by linuxgurugamer
Link to comment
Share on other sites

14 hours ago, linuxgurugamer said:

Is it because of the parantheses?  If so, then if I replace the parens with questionmarks, it should work, right?

Edit:  I tried replacing the parens with questionmarks, didn't change the error

You was bitten by the Module Manager (lack of) parser. :) 

The code that checks for is is here:

                if (!urlConfig.type.IsBracketBalanced())
                {
                    progress.Error(urlConfig, "Error - node name does not have balanced brackets (or a space - if so replace with ?):\n" + urlConfig.SafeUrl());
                    return null;
                }

And it is using the IsBrackedBalanced() function, an extension to the string type (and used by side effect on UrlConfig):

        public static bool IsBracketBalanced(this string s)
        {
            int level = 0;
            foreach (char c in s)
            {
                if (c == '[') level++;
                else if (c == ']') level--;

                if (level < 0) return false;
            }
            return level == 0;
        }

The function itself is OK, but the problem is that this function is being kept hostage from the UrlConfig class. It's not evaluating what you wrote on the patch, but what the UrlConfig constructor made of it, and for this constructor a parenthesis is not part of the "type" thingie (being type anything you use as the node's name).

So, in that context, the urlConfig's type is "@PART[CST-100?Heat?Shield?" (i.e., the "type" name parser stops at the first parenthesis), and not "@PART[CST-100?Heat?Shield?(Brown)]" as you are expecting. (Note that, at this time, the type thingie is the raw text on the node's name, way before the Patch Compiling phase starts).

TL;DR: Using ? to replace both parenthesis should had done the trick! I made this test here:

PART
{
	name = CST-100 Heat Shield (Brown)
}

@PART[CST-100?Heat?Shield??Brown?]
{
	MODULE
	{
		name = ModuleCargoPart
		packedVolume = 11410
	}
}

and got this on the MM Cache:

{
    parentUrl = __LOCAL/test.cfg
    PART
    {
        name = CST-100 Heat Shield (Brown)
        MODULE
        {
            name = ModuleCargoPart
            packedVolume = 11410
        }
    }
}

So it worked.

For anyone else still reading this :D there's a very strong reason we should use only alphanumeric (and a few non alphanumeric chars, as dashes and dots) for naming a part. We have the part's Title to do human friendly naming for a reason!

Link to comment
Share on other sites

35 minutes ago, Lisias said:

For anyone else still reading this :D there's a very strong reason we should use only alphanumeric (and a few non alphanumeric chars, as dashes and dots) for naming a part. We have the part's Title to do human friendly naming for a reason!

And there are still some mods out there which insist on using spaces, odd characters, etc in the part names (not title).  This is what happened, I fixed it by replacing the parens with questionmarks

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