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

[ThorBeorn]

Darn it. I found a MM 1.5.6 in an old backupfolder of KSP which I had completly forgotten about. That should solve it then. Will try later today.

Thanks for your help and patience. I will probably come back here or in the RO thread if I run into further problems, if nobody minds ofcourse

[ThorBeorn]

Darn it. I found a MM 1.5.6 in an old backupfolder of KSP which I had completly forgotten about. That should solve it then. Will try later today.

Thanks for your help and patience. I will probably come back here or in the RO thread if I run into further problems, if nobody minds ofcourse

-Nope, deleting the old MM 1.5.6. didn't do it either. I'm totally stuck and out of ideas. Need help. Can any other .dll's interfere, any other mods cause trouble etc?

Edit: I think I found a solution. Replacing "MODEL, n" with just "MODEL" seems to work even for parts with several models. Here's an example of what works:

@PART[FusTekKuestAirlock]:Final
{
	@MODEL
	{	
		%scale = 1.76, 1.76, 1.76
	}
	@MODEL
	{
		%scale = 1.76, 1.76, 1.76
		%position = 0.0, 1.925, 0.0 //was 1.09375	
	}
	@MODEL
	{
		%scale = 1.76, 1.76, 1.76
		%position = 0.0, -1.925, 0.0 //was -1.09375		
	}

	// Top Hatch
	@MODEL
	{
		%scale = 1.76, 1.76, 1.76
		%position = 0.0, 1.76, 0.0		
	}
	//Bottom Hatch
	@MODEL
	{
		%scale = 1.76, 1.76, 1.76
		%position = 0.0, -1.76, 0.0
	}

I don't understand why it works though. I'd still like to hear what you guys has to say about this.

Edited April 26, 2014 by ThorBeorn

[NathanKell]

Because @foo will match the first foo that is found; and MM, when it edits a node, moves that node to the end of the list of nodes (which is a problem, see above). Thus each time you edit the first node, a new node will be first.

WAIT.

That would explain the problem with indexing! Since MM reorders nodes when editing them, indexing will fail after the first!

[sarbian]

oh yeah, try with ,0 for all nodes.

I'll think of some thing or swamp_ig will fix it before.

[Starwaster]

oh yeah, try with ,0 for all nodes.

I'll think of some thing or swamp_ig will fix it before.

Derrrrr, I thought ,0 was first node. You know, 0, 1, 2, 3....

[NathanKell]

Yes, it is. But see my above as to why that fails.

[Starwaster]

Yes, it is. But see my above as to why that fails.

Yeah but I was having issues modifying something that had only a single MODEL{} so that shouldn't enter into it

[swamp_ig]

oh yeah, try with ,0 for all nodes.

I'll think of some thing or swamp_ig will fix it before.

I haven't actually done anything yet, got lots of stuff on my plate at the moment. (RL too)

[RaccoonTOF]

Ah...I thought that indexing was supposed to be "properly" fixed in 2.03 already. If not, that would certainly explain the failures

[sarbian]

I thought so too :=

[nanowinner]

Thanks for this

[DMagic]

Does anyone know if it's possible to add science reports for the stock science experiments?

I've been trying several variations on the code below

@EXPERIMENT_DEFINITION[*]:HAS[#id[seismicScan]]
{
	%RESULTS
	{
		KerbinSrfLandedLaunchPad = New seismic scan!
	}
}

This version (and switching the % for @) successfully adds the new result, but deletes the old ones. I've also tried adding :Final and putting {} or [] after RESULTS, to no avail. I can just copy over all of the results in the stock ScienceDefs.cfg file, which is what I've seen others do, but I was hoping for something more elegant.

[Starwaster]

seems like this is going to be somewhat painful switching over until modders start implementing the new ordering keywords for their mods. no point in specifying BEFORE/AFTER mod-x until mod-x has been switched over to have its configs using :FOR

[sarbian]

Well it should be :

@EXPERIMENT_DEFINITION[*]:HAS[#id[seismicScan]]
{
	@RESULTS
	{
		KerbinSrfLandedLaunchPad = New seismic scan!
	}
}

[DMagic]

Well it should be :

Thanks.

I suppose it would help if I weren't an idiot. @ or %RESULTS seems to work fine, it's just that I had inexplicably commented out the default seismic scan results in the ScienceDefs.cfg file and there are no other Kerbin specific results, so it was giving me the fallback result and making me think the rest were deleted too.

[Starwaster]

Thanks.

I suppose it would help if I weren't an idiot. @ or %RESULTS seems to work fine, it's just that I had inexplicably commented out the default seismic scan results in the ScienceDefs.cfg file and there are no other Kerbin specific results, so it was giving me the fallback result and making me think the rest were deleted too.

the difference between @ and @ only modifies existing nodes and % modifies existing nodes BUT adds the node if it doesn't exist.

However.... I think experiment definitions are at the root level which is read only so we're limited in what we can do with it... you can edit the existing nodes within but you can't add a node to it.

[cantab]

Hopefully this isn't too dumb a question. Where should Module Manager configs/patches/whatever be circulated? In the regular Add-On Development or Add-On Releases forum as appropriate, or is there somewhere particular for them?

[BudgetHedgehog]

Hopefully this isn't too dumb a question. Where should Module Manager configs/patches/whatever be circulated? In the regular Add-On Development or Add-On Releases forum as appropriate, or is there somewhere particular for them?

Depends on the patch in question, but a safe bet is in that mods thread. If I made a cfg that adds KAS grab functionality to a RT2 antennae, I'd post it in the RT2 thread. If I made a cfg that limits data transmission for KSI antennae according to Antennae Range parameters, I'd post it in the KSI thread.

[cantab]

What I'm thinking of working on is a patch to the stock parts, to change some annoying part attachment limitations.

[RaccoonTOF]

seems like this is going to be somewhat painful switching over until modders start implementing the new ordering keywords for their mods. no point in specifying BEFORE/AFTER mod-x until mod-x has been switched over to have its configs using :FOR

Unless they are already using the :FINAL keyword, it should work fine even if you code to using the new standards yourself - every mod with a DLL gets a pass added for it already, even without the mod author creating a mod config file for it.

[Starwaster]

Unless they are already using the :FINAL keyword, it should work fine even if you code to using the new standards yourself - every mod with a DLL gets a pass added for it already, even without the mod author creating a mod config file for it.

Yes, but if they don't actually use a config that places that mod's desired changes in one of those passes then they don't happen in those passes. Maybe that's a bug and they're supposed to, but they do not. Understand?

If for example, Real Fuels does not have something like @PART[b9_Engine_SABRE_S]:FOR[modularFuelTanks]{<changes>} then it will not happen in the pass for modularFuelTanks. (which is where RF passes actually occur because of the dll name)

So if I want to do something :BEFORE[modularFuelTanks] or :AFTER[modularFuelTanks] it's pointless. I cannot guarantee that it will happen :BEFORE or :AFTER. My options are :FIRST or :FINAL.

I don't know if that's the intended behavior or not but that is what is right now. In fact looking at my output_log.txt, it looks like all configs that aren't using :BEFORE, :FOR or AFTER are happening before those passes.

Edit: Which is why, assuming the current behavior is correct behavior, it's imperative that as many mods as possible start making use of :FOR[]

Edited April 28, 2014 by Starwaster

[sarbian]

I wonder if using the base dir name as default FOR[x] would be a good idea.

Yesterday : Toadicus found a big bug in MM 2.0.3. When you use a :HAS directive for a subnode it may lock up on load. I made a quick fix in a 2.0.4 but I won't push it as official without more testing.

Those who want to test can get it here: https://ksp.sarbian.com/jenkins/job/ModuleManager/lastSuccessfulBuild/artifact/jenkins-ModuleManager-3/ModuleManager-2.0.4.zip

If this one works I'll most likely release a .5 that count the square bracket before parsing a line tonigh and use it as a new official.

[RaccoonTOF]

@Starwaster: Ah, gotcha. I understand the issue you mean now Still, as long as you code with the "proper" format for your patches right now, it should "gracefully fail" (aka - act as if they were not there) until such time as the mod authors start using :FOR for their own native configs as well.

@sarbian: Having a pass for each base directory might not be a bad idea, as long as a few things held true:

a) you ensure that any changes from config files in that directory run during the :FOR cycle assigned to that directory UNLESS specified explicitly within the CFG itself.

you only "process" config files that reference a file in that base directory in the :AFTER cycle for that directory UNLESS specified explicitly within the CFG itself. (this to prevent MM from multiplying its workload by huge amounts for those that merely have many base directories in their gamedata folder, without having configs that reference most of those directories).

The latter is my primary concern - with nearly 2k parts spread across 69 base directories currently, I wouldn't want MM to have to be searching all 2k parts an extra 207 times for every config file it reads in...

[sarbian]

The point is not adding an AFTER, but having a default FOR if not specifed in the patch. This would ensure that mod that start using the new system can expect a staring base. ( or I did not understand your point correctly)

The main trouble would be that some mod could use something else than their dir name later, and other mods would have to change too. Don't know if it's worth it.

[toadicus]

I wonder if using the base dir name as default FOR[x] would be a good idea.

Yesterday : Toadicus found a big bug in MM 2.0.3. When you use a :HAS directive for a subnode it may lock up on load. I made a quick fix in a 2.0.4 but I won't push it as official without more testing.

Those who want to test can get it here: https://ksp.sarbian.com/jenkins/job/ModuleManager/lastSuccessfulBuild/artifact/jenkins-ModuleManager-3/ModuleManager-2.0.4.zip

If this one works I'll most likely release a .5 that count the square bracket before parsing a line tonigh and use it as a new official.

Sarbian, I've tested the 2.0.4 build and it did resolve the problem I was having. Didn't get a chance to test indexing.

FWIW, I think a default :FOR pass -- probably related to directory name -- is a good idea if only as a transitional tool. Right now if I wanted, for example, to run after all of the Realism Overhaul patches, there's simply no good way to do it. Best option would be to guess whether KSP would alphabetically load Wheels_Squad.cfg or pFairings.cfg last, and use an :AFTER on one of them. If I could say :AFTER[RealismOverhaul] as a catchall for everything in that folder, it'd be useful during the transition and, IMO, it's a fair bet that the RO authors are going to use :FOR[RealismOverhaul] when they get to updating those patches, so the risk of my needing to change the name is low.