Rafael acevedo Posted December 5, 2017 Share Posted December 5, 2017 53 minutes ago, linuxgurugamer said: Would be best to do the following: Contact the authors of the mods 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 Quote Link to comment Share on other sites More sharing options...
linuxgurugamer Posted December 5, 2017 Share Posted December 5, 2017 1 hour ago, Rafael acevedo said: I already contacted Nils for KPBS the link in the message is the link to the KSP log V/R Please re-read my message. You are on Windows, you need to supply the output_log.txt, NOT the KSP.log Quote Link to comment Share on other sites More sharing options...
linuxgurugamer Posted December 5, 2017 Share Posted December 5, 2017 (edited) @blowfish Deleted, was a false alarm. Edit: I just realized that the Tweakscale directory was there, but nothing in it, will try again. Edited December 5, 2017 by linuxgurugamer Quote Link to comment Share on other sites More sharing options...
linuxgurugamer Posted December 5, 2017 Share Posted December 5, 2017 Just an FYI, SXT is now updated Quote Link to comment Share on other sites More sharing options...
Rafael acevedo Posted December 5, 2017 Share Posted December 5, 2017 (edited) 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 December 5, 2017 by Rafael acevedo Quote Link to comment Share on other sites More sharing options...
linuxgurugamer Posted December 5, 2017 Share Posted December 5, 2017 Next time, in the SXT thread or whatever mod it is. Anyway, all fixed and released Quote Link to comment Share on other sites More sharing options...
Gorby1 Posted December 5, 2017 Share Posted December 5, 2017 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! Quote Link to comment Share on other sites More sharing options...
sarbian Posted December 6, 2017 Author Share Posted December 6, 2017 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. Quote Link to comment Share on other sites More sharing options...
Sigma88 Posted December 6, 2017 Share Posted December 6, 2017 (edited) 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 December 6, 2017 by Sigma88 Quote Link to comment Share on other sites More sharing options...
sarbian Posted December 6, 2017 Author Share Posted December 6, 2017 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) Quote Link to comment Share on other sites More sharing options...
Rastan9 Posted December 7, 2017 Share Posted December 7, 2017 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. Quote Link to comment Share on other sites More sharing options...
Poodmund Posted December 7, 2017 Share Posted December 7, 2017 Is this an official, best solution to fix the issue @Rastan9 or is it a workaround? Quote Link to comment Share on other sites More sharing options...
Sigma88 Posted December 7, 2017 Share Posted December 7, 2017 (edited) 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 December 7, 2017 by Sigma88 Quote Link to comment Share on other sites More sharing options...
sarbian Posted December 7, 2017 Author Share Posted December 7, 2017 (edited) 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 December 7, 2017 by sarbian Quote Link to comment Share on other sites More sharing options...
Poodmund Posted December 7, 2017 Share Posted December 7, 2017 (edited) Thank you for the confirmation and correction. Edited December 7, 2017 by Poodmund Quote Link to comment Share on other sites More sharing options...
Lechrenski Posted December 8, 2017 Share Posted December 8, 2017 (edited) 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 December 8, 2017 by Lechrenski Quote Link to comment Share on other sites More sharing options...
Sigma88 Posted December 8, 2017 Share Posted December 8, 2017 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 Quote Link to comment Share on other sites More sharing options...
TranceaddicT Posted December 9, 2017 Share Posted December 9, 2017 (edited) 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 December 9, 2017 by TranceaddicT Quote Link to comment Share on other sites More sharing options...
sarbian Posted December 9, 2017 Author Share Posted December 9, 2017 7 hours ago, TranceaddicT said: So, I'm gonna play dumb and ask how to use -mm-dump on a linux install Open a terminal, go to KSP install dir and ./KSP.x86_64 -mm-dump Quote Link to comment Share on other sites More sharing options...
TranceaddicT Posted December 9, 2017 Share Posted December 9, 2017 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.) Quote Link to comment Share on other sites More sharing options...
maja Posted December 10, 2017 Share Posted December 10, 2017 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? Quote Link to comment Share on other sites More sharing options...
TranceaddicT Posted December 10, 2017 Share Posted December 10, 2017 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? Quote Link to comment Share on other sites More sharing options...
New Horizons Posted December 10, 2017 Share Posted December 10, 2017 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? Quote Link to comment Share on other sites More sharing options...
DStaal Posted December 10, 2017 Share Posted December 10, 2017 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. Quote Link to comment Share on other sites More sharing options...
blowfish Posted December 10, 2017 Share Posted December 10, 2017 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.