Jump to content

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


sarbian

Recommended Posts

53 minutes ago, linuxgurugamer said:

Would be best to do the following:

  1. Contact the authors of the mods
  2. Include a link to the output_log.txt (if Windows), or KSP.log (if Mac or Linux)

 

I already contacted Nils for KPBS 

the link in the message is the link to the KSP log

V/R

 

Rafael

43 minutes ago, blowfish said:

The planetarybaseinc is a different bug actually, but thanks for finding it.  It turns out I broke :NEEDS checking on subnodes/values if the root node also has :NEEDS

Glad to be of some help

Happy holidays

Link to comment
Share on other sites

45 minutes ago, linuxgurugamer said:

Just an FYI, SXT is now updated

thank you Happy Holidays

1 hour ago, linuxgurugamer said:

Please re-read my message.

You are on Windows, you need to supply the output_log.txt, NOT the KSP.log

My Bad 

https://db.tt/v1zlrwxzh1

thanks

 

Edited by Rafael acevedo
Link to comment
Share on other sites

On 12/4/2017 at 1:23 PM, westamastaflash said:

Please review.

https://github.com/sarbian/ModuleManager/wiki/Patch-Ordering

I tried to give some examples too.

 

This is super helpful! Clears up a lot of things I wasn't sure about regarding MM, but never bothered to ask because I was always able to get things working. I was putting lines in there like ":FOR[SomeMod]:AFTER[ThisMod]:BEFORE[ThatMod]", now I see the error of my ways!

Link to comment
Share on other sites

3 minutes ago, sarbian said:

Version 3.0.1

  • Fix NEEDS checking for inner nodes/values 
  • Add a -mm-dump cmd line option and redo the export

Downloads :

ModuleManager.3.0.1.dll

ModuleManager-3.0.1.zip

 

Later today I will build a custom 2.8.1 with the new export so people can compare the result easily.

 

does the cmd line still require KSP?

or would this make possible to run get a cache generated without actually starting the game?

 

I would assume it still requires ksp

in this case, what does the dump actually do?

Edited by Sigma88
Link to comment
Share on other sites

6 hours ago, Sigma88 said:

does the cmd line still require KSP?

or would this make possible to run get a cache generated without actually starting the game?

 

I would assume it still requires ksp

in this case, what does the dump actually do?

Yes, it does. Running MM without KSP would require to much changes to be worth it IMHO.

It creates a "_MMCfgOutput" directory in the KSP install and exports all cfg as they are after patch and using the same directory structure as GameData. So you can compare _MMCfgOutput and GameData with a tool to see exactly what was patched. (as before Beyond Compare helps)

Link to comment
Share on other sites

So, it looks like all of my problems were from people using @EXPERIMENT_DEFINITION[*] when they shouldn't have.  Removing the [*] every time it showed up next to @EXPERIMENT_DEFINITION seems to have fixed everything up as far as I can tell with basic testing.  Thanks to Aelfhe1m, sarbian, and blowfish for taking time to help me figure it out.  I've let the mod authors' for the impacted mods know.

Link to comment
Share on other sites

11 minutes ago, Poodmund said:

Is this an official, best solution to fix the issue @Rastan9 or is it a workaround?

the syntax

@NODE[XXX]

has always been intended as looking for a NODE with name = XXX

so it is the expected result that @EXPERIMENT_DEFINITION[*] would fail if the node is missing a "name"

I'm not sure if in the past this used to work even if it shouldn't have, or it was just failing without giving off an error

 

unless @blowfish and/or @sarbian plan to change the syntax I would say that 

@EXPERIMENT_DEFINITION

is the correct solution rather than a workaround

Edited by Sigma88
Link to comment
Share on other sites

1 hour ago, Sigma88 said:

unless @blowfish and/or @sarbian plan to change the syntax I would say that

No plan to change it since the manual always was perfectly clear :

"This means that FOOBAR[*] will not select all nodes of type FOOBAR, but all nodes of type FOOBAR which have a defined "name" field. (If you want to select all FOOBAR nodes, use FOOBAR,*.)"

It was a bug in versions before 3.0. I guess it was added at some point with a new feature

Edited by sarbian
Link to comment
Share on other sites

On ‎12‎/‎4‎/‎2017 at 7:20 PM, Sigma88 said:

just remove the :AFTER[SETIrebalance] and you will restore the old functionality completely  close enough

Now I think I'm understanding this less. Wouldn't :NEEDS[SETIrebalancet]:AFTER[TacLifeSupport] (or :NEEDS[TacLifeSupport]:AFTER[SETIRebalance], assuming SETIRebalance is already using an AFTER instead of a FOR) be better, since it still forces the check for both mods (instead of abandoning the check for SETIrebalance) while still patching in the correct order? From reading the wiki, I was under the impression that  BEFORE, FOR, or AFTER tacitly imply NEEDS, since the patch wouldn't be applied if the [modname] after them does not exist.

Man, it's stuff like this that really makes me with I got around to taking that formal logic class in college...

 

Edited by Lechrenski
Link to comment
Share on other sites

7 hours ago, Lechrenski said:

Now I think I'm understanding this less. Wouldn't :NEEDS[SETIrebalancet]:AFTER[TacLifeSupport] (or :NEEDS[TacLifeSupport]:AFTER[SETIRebalance], assuming SETIRebalance is already using an AFTER instead of a FOR) be better, since it still forces the check for both mods (instead of abandoning the check for SETIrebalance) while still patching in the correct order? From reading the wiki, I was under the impression that  BEFORE, FOR, or AFTER tacitly imply NEEDS, since the patch wouldn't be applied if the [modname] after them does not exist.

Man, it's stuff like this that really makes me with I got around to taking that formal logic class in college...

The patch was using:

:NEEDS[TacLifeSupport]:AFTER[TacLifeSupport]:AFTER[SETIrebalance]

 

The old behaviour of this was:

1- if TACLS is not installed the patch never works

2- if TACLS is installed, but SETI isn't, the patch is aplied at :AFTER[TacLifeSupport]

3- if both TAC & SETI are installed the patch is applied at :AFTER[SETIRebalance]

 

As far as I know there is no way to reproduce that in the new mm

But I don't think you will need that tbh, just use :AFTER[TacLifeSupport] and it should be fine

Link to comment
Share on other sites

On 12/6/2017 at 2:52 AM, sarbian said:

Version 3.0.1

  • Fix NEEDS checking for inner nodes/values 
  • Add a -mm-dump cmd line option and redo the export

Downloads :

ModuleManager.3.0.1.dll

ModuleManager-3.0.1.zip

 

Later today I will build a custom 2.8.1 with the new export so people can compare the result easily.

 

So, I'm gonna play dumb and ask how to use -mm-dump on a linux install

Edited by TranceaddicT
Link to comment
Share on other sites

9 hours ago, sarbian said:

Open a terminal, go to KSP install dir and 


./KSP.x86_64 -mm-dump

 

Thank you for that.

Just a note for everyone who might use it, that command doesn't just generate a dump file; it will actually run KSP.

(humorous sidenote: I now know my system can run simultaneous KSP instances.)

Link to comment
Share on other sites

On 6. 12. 2017 at 11:52 AM, sarbian said:

Later today I will build a custom 2.8.1 with the new export so people can compare the result easily.

Hi sarbian, did you have time to build a custom 2.8.1 or am I looking for something not done yet?

Link to comment
Share on other sites

2 hours ago, TranceaddicT said:

On a related topic ...

If I create MyGreatMod, is there a valid reason I would need to include the :FOR[MyGreatMod] directive in the configuration file I provide??  Shouldn't :FOR only be used by other mods with configs calling GreatMod?

NO! ':FOR' *creates* the mod, it's not a conditional.  It should *never* be used by other mods who want to call a mod.  It's main use is for things like the USI or WBI suites of mods, where multiple mods are in one folder, as it allows MM to reference those sub-mods that don't have either their own top-level folder or a .dll.

Link to comment
Share on other sites

32 minutes ago, New Horizons said:

Hey everyone, just upgraded from MM 2.8.1 to 3.01 on KSP 1.3.1. MM now throws new errors on the loading screen. Is there any way to see a log about all these errors, at best with hints to the individual sources of errors, too?

The simplest thing to do is just to upload your log.  There's a lot in there, but myself and others who have experience doing this can find what we need to pretty quickly.  Also worth making sure all your mods are up to date - many have been updated for this in the last few days.

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