Jump to content

[1.8.x-1.10.x] Module Manager 4.1.4 (July 7th 2020) - Locked inside edition


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 post
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 post
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 post
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 = #[email protected][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 = #[email protected][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 post
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 = #[email protected][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 post
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 = #[email protected][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 post
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 post
Share on other sites
2 hours ago, 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 = #[email protected][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 post
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 post
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 post
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 post
Share on other sites
5 hours ago, Jacke said:

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.

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

Link to post
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 post
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 post
Share on other sites
Posted (edited)
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 post
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 post
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 post
Share on other sites
Posted (edited)
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 post
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 post
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 post
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 post
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...