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

SkyFall2489 · June 1, 2022

10 hours ago, sarbian said:

People have been asking their questions here for years without any problems. I do not see the point of having a new thread

Actually, in various threads for other mods, the users didn't come here to ask questions. It seems like this is just a release/bug reporting/dev thread, and even if it is more than that, it's not sending the message so. In my opinion, having a separate ModuleManager Help Thread would be very useful. All of the knowledge would be in 1 place for easy viewing, not cluttered up with bug reports and new releases. It would be very clear that it would be a thread for helping with module manager, and so unsure forum users could go there. Instead of having to re-ask, it would be much more feasible to search through older questions. Commonly used knowledge could be put in the OP for even easier access. It all would greatly help users of modded installs across the forums. Even people who don't have a forum account, if they found the thread, could find what they need without having to create an account to ask.

EDIT: Oh, and you won't have to do a thing about it. I can accept full responsibility for the thread, and you don' have to help anyone unless absolutely no other forum user knows what to do.

Edited June 1, 2022 by SkyFall2489

Zelda · June 1, 2022

Just my $0.02 -

While I acknolwedge this is a megathread and is therefore difficult to browse, having everything in one thread makes it much easier to search since you can limit the search to this topic only. Unless you also were somehow wanting to port over the existing treasure trove of knowledge to a new thread (which would be near impossible given the amount of info here), that would mean needing to look in two places for possible answers moving forward. Also, regardless of how clear it is in the OP, there will still be people who ask their MM questions here before finding the new thread. Likewise, there will be people who could have found their answer searching this thread, but won't realize it and ask duplicate questions in the new thread. So there will be a bit of a tax in redirecting people / looking up old answers that the asker could have found if in the same thread anyway.

Again, just my opinion, but I think the time for a separate help thread was years ago. It's a little hard to do that now and not lose some knowledge in the process.

SkyFall2489 · June 1, 2022

50 minutes ago, Zelda said:

Just my $0.02 -

While I acknolwedge this is a megathread and is therefore difficult to browse, having everything in one thread makes it much easier to search since you can limit the search to this topic only. Unless you also were somehow wanting to port over the existing treasure trove of knowledge to a new thread (which would be near impossible given the amount of info here), that would mean needing to look in two places for possible answers moving forward. Also, regardless of how clear it is in the OP, there will still be people who ask their MM questions here before finding the new thread. Likewise, there will be people who could have found their answer searching this thread, but won't realize it and ask duplicate questions in the new thread. So there will be a bit of a tax in redirecting people / looking up old answers that the asker could have found if in the same thread anyway.

Again, just my opinion, but I think the time for a separate help thread was years ago. It's a little hard to do that now and not lose some knowledge in the process.

I feel like much of the knowledge in this thread is duplicates, and would be not too hard to port over. It's not as big of a task as some may think. People ask again and again for the same knowledge. Yes, some people may search the old thread, but if it's literally called the modulemanager help thread I assume people will go there first if they see it. And if not, they can ask in the old thread, and be redirected to the new one. Yes, it's a huge volume, but that doesn't mean we can put it off. It'll be a while til KSP2, and even then, people will still play the original, meaning that it will still be of use, Yes, years ago would have been better, but that's a sunk cost.

Stone Blue · June 1, 2022

20 hours ago, SkyFall2489 said:

e noticed that often people don't have much experience using ModuleManager, but it is important to tweaking heavily modded installs the way you want. Can I get permission to start a ModuleManager Help Thread?

Theres also *two* very good wiki's to reference

damerell · June 2, 2022

11 hours ago, SkyFall2489 said:

Oh, and you won't have to do a thing about it.

I'm not sarbian, obviously, but I'm really not sure what you're asking. If you want to start a thread, no-one is stopping you. You don't need permission from anyone if it's in line with the forum rules. If people use it, great. If not, well, it turns out it was easier to keep stuff in this thread.

June 2, 2022

@SkyFall2489As Stone Blue said, you can check the wikis and maybe complete or expand them. For example, the "Top level nodes" and "selections" explanations are empty here https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Syntax#top-level-node

Also, as an example, yesterday I was trying to rescale all the parts from a mod (Using rescalefactor) and ended up writing something like it's says on the wiki (https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Handbook#specific-names) and it worked. However, it only worked because all the part names (As in that example) start the same, but what if parts of the mod doesn't? Can I put the folder path there and made it easier? etc. That kind of thing would be better written on the manual that asked on a thread IMO.

Not saying that you should do anything, but as you said you wanted to help having complete manuals with a variety of use cases would be better than a thread.
Again, just my opinion.

Also, @Stone Blue besides those links from github, what other wiki is available?

Stone Blue · June 2, 2022

@SkyFall2489 also, looks like someone already tried your idea... vOv

@Forked Camphor huh.. my bad... i used to use Google search to get the links, & there used to be seperate ones for the Syntax & for the Handbook...
now they dont show in my search... only one that does is for that... *other* :roll_eyes: version of MM

anyway, heres a quick link to the *real* MM wiki:
https://github.com/sarbian/ModuleManager/wiki

SkyFall2489 · June 2, 2022

17 minutes ago, Stone Blue said:

@SkyFall2489 also, looks like someone already tried your idea... vOv

@Forked Camphor huh.. my bad... i used to use Google search to get the links, & there used to be seperate ones for the Syntax & for the Handbook...
now they dont show in my search... only one that does is for that... *other* :roll_eyes: version of MM

anyway, heres a quick link to the *real* MM wiki:
https://github.com/sarbian/ModuleManager/wiki

That was way back then, and at least in my opinion I think I can do better. That was an installation tutorial, this will be a help thread for making patches. It will go as in depth as everyone needs, unlike that surface level tutorial. Yes, maybe whoever made that thought they were better than whoever tried before, but at least I can try. If it all comes crashing down or gets lost in the depths of 3 year old threads, it won't be at any cost to anyone but me...

ilmcamam · June 8, 2022

Perhaps a bit of a strange use case, but is it possible to copy arbitrarily many of a top-level node?

The MM_PATCH_LOOP {} functionality does not seem to trigger under any circumstances if the operation for the top-level node is copy. The example case given here, which would be perfect:

Spoiler

Specifically:

TEST
{
	name = Test
}

@TEST
{
  copy = 5
}

$TEST[Test]:HAS[#copy[>0]]
{
	*@TEST[Test]/copy -= 1
	
	@name = #$name$$copy$	

	MM_PATCH_LOOP {}
}

- does not seem to work, even explicitly as presented there (copy-pasted) - the relevant region of the config cache is as follows:

Spoiler

<preamble>
UrlConfig
{
	parentUrl = TestPatches/test.cfg
	TEST
	{
		name = Test
		copy = 4
	}
}
UrlConfig
{
	parentUrl = TestPatches/test.cfg
	TEST
	{
		name = Test5
		copy = 5
		MM_PATCH_LOOP
		{
		}
	}
}
<more patches>

The log (expectedly) makes no mention of a loop -

<unrelated before>
[LOG 06:33:10.700] Applying update SXT/Patches/SquadPartTweaks/Satellite_Contract_Satisfaction/@Contracts to Squad/Contracts/Contracts.cfg/Contracts
[LOG 06:33:10.702] Applying update TestPatches/test/@TEST to TestPatches/test.cfg/TEST[Test]
[LOG 06:33:10.703] Applying copy TestPatches/test/$TEST[Test]:HAS[#copy[>0]] to TestPatches/test.cfg/TEST[Test]
[LOG 06:33:10.705] Applying update VenStockRevamp/Patches/IVA-Placeholders/@PART[InflatableHAB]:HAS[!INTERNAL] to VenStockRevamp/PartBin/Data/Command.cfg/PART[InflatableHAB]
<unrelated hereafter>

The first update being the addition of the count, and then the copy, with no subsequent looping. Those are the only two mentions (barring the "what files changed" at the top of the MM section of ksp.log) of test.cfg.

In my testing, barring the occasional user-error infinite loop, edit-looping works flawlessly.

Is it possible to somehow replicate this another way? For instance, something akin to:

@PART[*]:HAS[#condition]
{
	// somehow copy a different top-level node
	*@TOPLEVEL[Copy]/attribute = foo
}

Swapping the *@ for a *$ (and changing name rather than some other attribute) merely introduces an error - is there a way to accomplish this, if the failing loop on a copy operation is intended behaviour?

Edit: A test case on a fresh install of stock KSP (rather than a slightly out of date RP-1 installation) with MM downloaded through CKAN behaved identically:

Spoiler

Patch:

Spoiler

TEST
{
	name = Test
}

@TEST
{
	copy = 5
}

$TEST[Test]:HAS[#copy[>0]]
{
	*@TEST[Test]/copy -= 1
	
	@name = #$name$$copy$	

	MM_PATCH_LOOP {}
}
TESTA
{
	name = Testa
}
@TESTA
{
	copy = 5
}
@TESTA[Testa*]:HAS[#copy[>0]]
{
	@copy -= 1
	
	@name = #$name$$copy$	

	MM_PATCH_LOOP {}
}

Cache:

Spoiler

<stock game stuff>
UrlConfig
{
	parentUrl = TestPatches/test.cfg
	TEST
	{
		name = Test
		copy = 4
	}
}
UrlConfig
{
	parentUrl = TestPatches/test.cfg
	TEST
	{
		name = Test5
		copy = 5
		MM_PATCH_LOOP
		{
		}
	}
}
UrlConfig
{
	parentUrl = TestPatches/test.cfg
	TESTA
	{
		name = Testa43210
		copy = 0
	}
}
EOF

MM section of ksp.log:

Spoiler

#### BEGIN MODULEMANAGER LOG ####


[LOG 07:16:52.596] Log started at 2022-06-08 07:16:52.596
[LOG 07:16:54.173] Checking Cache
[LOG 07:16:56.145] SHA generated in 1.970s
[LOG 07:16:56.145]       SHA = A0-69-60-89-E5-62-88-CB-93-53-6B-EA-2A-C8-FB-E8-8F-10-B9-F9-A8-9B-C1-5F-5B-0C-50-F1-88-2B-52-29
[LOG 07:16:56.149] Pre patch init
[LOG 07:16:56.288] compiling list of loaded mods...
Mod DLLs found:
  Name                                    Assembly Version         Assembly File Version    KSPAssembly Version      SHA256

  Assembly-CSharp                         0.0.0.0                  0.0.0.0                  1.12                     002870b4a4e4a332c16afa6334f5cae0b241d02bc910e3af2cc67dacd32a6fa6
  ModuleManager                           4.2.1.0                  4.2.1.0                  2.5                      2eb4963f73a5255163953a270026f50a8f1a7dd27f4bb0dd69dd4699d0f2268b
  KSPSteamCtrlr                           0.0.1.35                 0.0.1.35                                          1675fa4fcb61d014eb1babe7eed703e7f76a1008537ee57ca7cec65cd9ff94ac
Non-DLL mods added (:FOR[xxx]):
Mods by directory (sub directories of GameData):
  Squad
  TestPatches
Mods added by assemblies:

[LOG 07:16:56.293] Loading Physics.cfg
[LOG 07:16:56.319] Extracting patches
[LOG 07:16:56.374] Applying patches
[LOG 07:16:56.375] :INSERT (initial) pass
[LOG 07:16:56.427] :FIRST pass
[LOG 07:16:56.427] :LEGACY (default) pass
[LOG 07:16:56.428] Applying update TestPatches/test/@TEST to TestPatches/test.cfg/TEST[Test]
[LOG 07:16:56.437] Applying copy TestPatches/test/$TEST[Test]:HAS[#copy[>0]] to TestPatches/test.cfg/TEST[Test]
[LOG 07:16:56.438] Applying update TestPatches/test/@TESTA to TestPatches/test.cfg/TESTA[Testa]
[LOG 07:16:56.438] Looping on TestPatches/test/@TESTA[Testa*]:HAS[#copy[>0]] to TestPatches/test.cfg/TESTA[Testa]
[LOG 07:16:56.438] Applying update TestPatches/test/@TESTA[Testa*]:HAS[#copy[>0]] to TestPatches/test.cfg/TESTA[Testa]
[LOG 07:16:56.438] Applying update TestPatches/test/@TESTA[Testa*]:HAS[#copy[>0]] to TestPatches/test.cfg/TESTA[Testa4]
[LOG 07:16:56.438] Applying update TestPatches/test/@TESTA[Testa*]:HAS[#copy[>0]] to TestPatches/test.cfg/TESTA[Testa43]
[LOG 07:16:56.438] Applying update TestPatches/test/@TESTA[Testa*]:HAS[#copy[>0]] to TestPatches/test.cfg/TESTA[Testa432]
[LOG 07:16:56.438] Applying update TestPatches/test/@TESTA[Testa*]:HAS[#copy[>0]] to TestPatches/test.cfg/TESTA[Testa4321]
[LOG 07:16:56.440] :BEFORE[ASSEMBLY-CSHARP] pass
[LOG 07:16:56.440] :FOR[ASSEMBLY-CSHARP] pass
[LOG 07:16:56.440] :AFTER[ASSEMBLY-CSHARP] pass
[LOG 07:16:56.440] :BEFORE[KSPSTEAMCTRLR] pass
[LOG 07:16:56.440] :FOR[KSPSTEAMCTRLR] pass
[LOG 07:16:56.440] :AFTER[KSPSTEAMCTRLR] pass
[LOG 07:16:56.440] :BEFORE[MODULEMANAGER] pass
[LOG 07:16:56.440] :FOR[MODULEMANAGER] pass
[LOG 07:16:56.440] :AFTER[MODULEMANAGER] pass
[LOG 07:16:56.440] :BEFORE[SQUAD] pass
[LOG 07:16:56.440] :FOR[SQUAD] pass
[LOG 07:16:56.440] :AFTER[SQUAD] pass
[LOG 07:16:56.440] :BEFORE[TESTPATCHES] pass
[LOG 07:16:56.440] :FOR[TESTPATCHES] pass
[LOG 07:16:56.440] :AFTER[TESTPATCHES] pass
[LOG 07:16:56.441] :FINAL pass
[LOG 07:16:56.441] Done patching
[LOG 07:16:56.441] Saving Cache
[LOG 07:16:56.537] Saving cache
[LOG 07:16:57.517] ModuleManager: 8 patches applied

[LOG 07:16:57.517] Ran in 3.343s
[LOG 07:16:57.604] Done!



#### END MODULEMANAGER LOG ####

Just a sanity check to make sure it wasn't a specific issue with the install I was working with.

Edited June 8, 2022 by ilmcamam

sarbian · June 18, 2022

Thanks to @NathanKell hard work we can now patch the localization nodes.

Support wildcards in nodetype matching so you can do @*,* {}
Support # in value names since loc names start with #
Tell Localizer to reload the language after MM finishes

ModuleManager.4.2.2.dll

ModuleManager-4.2.2.zip

Edited June 18, 2022 by sarbian

CarelessDoughnut · July 6, 2022

@sarbian Is there a way to, instead of reloading the whole Database with the Alt+F11 Menu, reload a single part?

For example: I load the game, try a part I'm modding, correct whatever is wrong in the file, and then reload just that part and only its associated textures,sounds, etc.

sarbian · July 6, 2022

No, MM calls a game function to do the reload and reloading only one item would mean having to dig deep into the KSP loading system. The best I can suggest is to remove most part when you are working on something to keeps the amount of reloaded items to a minimum

CarelessDoughnut · July 7, 2022

I see. Thanks, it's still better than closing the game and going all over the main menu

VostokV5 · July 25, 2022

I would like to write a patch that modifies the maxThrust and atmCurve of the J-404 Panther engines, but it seems that there are two of the same module in its CFG file; one for dry mode and one for wet mode. I've tested this patch I wrote but it doesn't seem to work like I want it to:

+PART[turboJet]
{
	@MODULE[ModuleEnginesFX]
	{
		@maxThrust = 74.6
		@atmCurve
		{
			key = 0 0 2.55 2.55
			key = 0.2 0.51 1.58125 1.58125
			key = 1 1 0.6125 0.6125
		}
	}
	@MODULE[ModuleEnginesFX]
	{
		@maxThrust = 114
		@atmCurve
		{
			key = 0 0 2.55 2.55
			key = 0.2 0.51 1.58125 1.58125
			key = 1 1 0.6125 0.6125
		}
	}
}

linuxgurugamer · July 25, 2022

4 minutes ago, VostokV5 said:
@MODULE[ModuleEnginesFX]

Add an index. For example:

@MODULE[ModuleEnginesFX],1

To reference the first or second occurrence ( not sure if the indexes are 0 based or 1 based, on mobile right now)

Edited July 25, 2022 by linuxgurugamer

VostokV5 · July 25, 2022

33 minutes ago, linuxgurugamer said:

Add an index. For example:

@MODULE[ModuleEnginesFX],1

To reference the first or second occurrence ( not sure if the indexes are 0 based or 1 based, on mobile right now)

Thanks! It works now

HafCoJoe · July 26, 2022

Salutations! I had a question regarding some ModuleManager syntax. I'd like to target and edit a module which does not have a name value, but rather celestialBodyName value instead:

@Scatterer_planetsList
{
	scattererCelestialBodies
	{
		Item
		{
			celestialBodyName = Laythe
			secondarySuns
			{
				Item
				{
					celestialBodyName = Jool
					sunColor = 0.009,0.015,0.0095
				}
			}
		}
	}
}

I'm trying to add the secondarySuns value into an existing Item with a value of celestialBodyName = Laythe. Normally to target a specific module you simply add [name] to the back of the targeted module (I.E. @Item[Laythe]), but because the designator is instead called celestialBodyName I don't know how to properly target it. How would I set up my syntax to target this particular module?

Edited July 26, 2022 by HafCoJoe

Aelfhe1m · July 26, 2022

8 hours ago, HafCoJoe said:
Salutations! I had a question regarding some ModuleManager syntax. I'd like to target and edit a module which does not have a name value, but rather celestialBodyName value instead:
@Scatterer_planetsList
{
	scattererCelestialBodies
	{
		Item
		{
			celestialBodyName = Laythe
			secondarySuns
			{
				Item
				{
					celestialBodyName = Jool
					sunColor = 0.009,0.015,0.0095
				}
			}
		}
	}
}
I'm trying to add the secondarySuns value into an existing Item with a value of celestialBodyName = Laythe. Normally to target a specific module you simply add [name] to the back of the targeted module (I.E. @Item[Laythe]), but because the designator is instead called celestialBodyName I don't know how to properly target it. How would I set up my syntax to target this particular module?

This should help:

Feel free to ask if anything is unclear.

linuxgurugamer · July 26, 2022

Hope someone can help with this.

One of my mods has the following code:

@PART[*]:HAS[!MODULE[ModuleCargoPart],@MODULE[ModuleInventoryPart],!MODULE[KerbalEVA]]:FINAL
{

	MODULE
	{
		name = ModuleCargoPart
		packedVolume = -1
	}
	MODULE
	{
		name = ModuleInventoryPart		
		InventorySlots = #$/MODULE[ModuleInventoryPart]/InventorySlots$
		packedVolumeLimit = #$/MODULE[ModuleInventoryPart]/packedVolumeLimit$
	}
	MODULE
	{
		name = KSPPartVolumeModule
	}
	!MODULE[ModuleInventoryPart] {}
}

Turns out that at least one (and probably more) parts mods don't bother to put in the "packedVolumeLimit" value, so MM borks on that line since there is nothing to reference.

Not being a MM guru, and busy with other stuff, I was hoping that someone could provide some code which would work if the packedVolumeLimit is missing

Rodger · August 5, 2022

Would it be possible to get a setting (via config or something) to disable invalidating the PartDatabase on changes in GameData? Apparently that behavior is on MM's side, not stock? It really adds a lot to load times when you're doing a bunch of small tweaks to a mod when it recalculates all the drag cubes every launch/reload.

Edit: It seems this is exactly what 'quick reload database' does?

Edited August 30, 2022 by Rodger

spaded1 · August 15, 2022

Hey guys I'm trying to make a mod to make the cost of everything more real.

So falcon 9 should cost 100mil to fly. Satellite contracts should pay 25mil not 25k.

Extracting ore and landing should reward with millions in dollars.

Here is my code - but the contracts don't seem to reflect the changes at all.... Can anyone help me out?

```

@CONTRACT_TYPE[*]:HAS[@rewardFunds]:FINAL

{

cash= $rewardFunds

@rewardFunds = 200*cash

}

@Contracts:HAS[@Funds]:FINAL

{

cash= $rewardFunds

@rewardFunds = 70*cash

@Funds

{

@BaseReward *= 70

@BaseAdvance *= 70

}

@BaseReward *= 70

@BaseAdvance *= 70

}

@Contracts:HAS[*,@Funds]:FINAL

{

cash= $rewardFunds

@rewardFunds = 200*cash

@Funds

{

@BaseReward *= 70

@BaseAdvance *= 70

}

@BaseReward *= 70

@BaseAdvance *= 70

}

@PART[*]

{

@cost *= 150.0

}

@RESOURCE_DEFINITION[*]

{

@unitCost *= 150.0

}

```

Jimbodiah · August 29, 2022

Trying to make a patch to add some B9 tanktypes to existing mods....

The part will have this module, plus could have other modules besides the fuelSwitch version.

	MODULE
	{
		name = ModuleB9PartSwitch
		moduleID = fuelSwitch
		switcherDescription = Fuel
		switcherDescriptionPlural = Fuels

Just trying to see if I can wrap my head around the syntax to first check for that module and secondly to alter it...

Would this be the correct condition to only alter parts with that fuelSwitch module type?

@PART[...]:HAS[@MODULE[ModuleB9PartSwitch]&moduleID[fuelSwitch]]:NEEDS[B9PartSwitch&...]:AFTER[...]

and would this change that particular moduleID

	@MODULE[ModuleB9PartSwitch]:HAS[~modulelID[fuelSwitch]]
	{
		// do my stuff
	}

Any advice would be most welcome.

Edited August 29, 2022 by Jimbodiah
OCd

shoe7ess · October 14, 2022

Hey all. The examples thread is all but dead but I have created a plethora of MM patches over the years, but I am having trouble with one that is probably the simplest you will ever see. All it does it set the attachment rules so that every part has surface/stack/etc attach (everything but collision). It has worked for me perfectly well for years but for whatever reason I can not get it to work with a specific part from Davon Supply Mod (well, the only part from the mod really). I have created some patches to add in most of the B9 stock fuels and cryo-fuels with some patches as well as created a variant for the part, but even if I set the actual part config attach rules to 1,1,1,1,0 as well as throw it in every part of the mod loading process, I can not get the part to take the rule update. I am able to get around it with Node Helper but that is only temporary. It's a pretty straightforward code, boiled down without although the modifiers it's just basically:

@PART[*]:FINAL 
{
	@attachRules = 1,1,1,1,0
}

I've used almost every kind of sequence I can think of (LAST, AFTER, BEFORE, etc) to get this work, but :FINAL really should do the trick, especially since the part.cfg has already been re-written in this case. What would be the easiest way to see if and why this part is getting over-ridden by a different MM patch? I've tried scouring the logs but can't seem to find it, and the specific "SurfAttach4All.cfg" patch I made works on every single part I've tried, just not that one.

Let me know if there is some further information/logs I can provide. The part itself does not have any specific modules that should conflict with that behavior change, so it's just kind of odd.

Thanks all! I really do have a ton of MM patches I've made, some of them a few thousand lines long for USILS overhauls and the like that I may start posting if I can find a decent repo to post them for others (I've got them on a .git but I need to do some spring-cleaning on that project first).

Starwaster · October 14, 2022

@shoe7ess hmmm looking at that mod on its github and it already has those attachRules defined.

read your log and see what is patching it.

Edited October 16, 2022 by Starwaster

shoe7ess · October 16, 2022

On 10/14/2022 at 7:17 PM, Starwaster said:

@shoe7ess hmmm looking at that mod on its github and it already has those attachRules defined.

read your log and see what is patching it.

Oh your right, the part.cfg uses those attachrules defined in the primary mod, I must have confused it with another part. I've gone through the MM and KSP logs, and the only MM patches I can find editing parts that include the DSM logistics part are from docking camera KURS, USI for cargo modules, etc, aside from the ones I created for the part itself. Is there any way to guarantee that a patch is loaded last, after all the :FINAL passes? I have to be missing something simple.

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

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Guest

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation