Mr. Kerbin Posted December 28, 2024 Share Posted December 28, 2024 Also, @Professor K, you don't need AFTER:[Kopernicus], at all. That isn't a thing needed anymore. news page Quote Link to comment Share on other sites More sharing options...
Professor K Posted December 29, 2024 Share Posted December 29, 2024 5 hours ago, Mr. Kerbin said: Also, @Professor K, you don't need AFTER:[Kopernicus], at all. That isn't a thing needed anymore. That's how the planet pack files came. I'm not the author, I was just writing patches to add support for the deployed science experiments. But the resolution to the issue was to change them to a FOR[name], so they are no longer present. Thanks for the confirmation though. -K Quote Link to comment Share on other sites More sharing options...
Fizzlebop Smith Posted December 30, 2024 Share Posted December 30, 2024 I have encountered an issue that has never happened before. It seems to be coming from SCAN SAT related to celestial bodies. This is the second time i have played a Career Save with ScanSAT and OPM. The first time lasted much longer than this play through without this issue... so now I think I must have done something else. The error that I was given told me to come to this thread and post in the error message. Spoiler Exception occured while attempt to generate contract of type 'CCCP-SCANsat.ScanEveLoRes': System.NullReferenceException: Object reference not set to an instance of an object at ContractConfigurator.Parameters.ReachState+<>c.<BodyList>b__94_0 (CelestialBody cb) [0x00000] in <0ac19348e13c43e280580b62f08ea2eb>:0 at ContractConfigurator.LocalizationUtil._LocalizeList[T] (ContractConfigurator.LocalizationUtil+Conjunction conjunction, System.Collections.Generic.IEnumerable`1[T] values, System.Func`2[T,TResult] strFunc) [0x0001c] in <0ac19348e13c43e280580b62f08ea2eb>:0 at ContractConfigurator.LocalizationUtil.LocalizeList[T] (ContractConfigurator.LocalizationUtil+Conjunction conjunction, System.Collections.Generic.IEnumerable`1[T] values, System.Func`2[T,TResult] strFunc) [0x00005] in <0ac19348e13c43e280580b62f08ea2eb>:0 at ContractConfigurator.Parameters.ReachState.BodyList () [0x00007] in <0ac19348e13c43e280580b62f08ea2eb>:0 at ContractConfigurator.Parameters.ReachState.CreateDelegates () [0x0001f] in <0ac19348e13c43e280580b62f08ea2eb>:0 at ContractConfigurator.Parameters.ReachState..ctor (System.Collections.Generic.List`1[T] targetBodies, System.String biome, System.Collections.Generic.List`1[T] situation, System.Single minAltitude, System.Single maxAltitude, System.Single minTerrainAltitude, System.Single maxTerrainAltitude, System.Double minSpeed, System.Double maxSpeed, System.Nullable`1[T] speedMode, System.Double minRateOfClimb, System.Double maxRateOfClimb, System.Single minAcceleration, System.Single maxAcceleration, System.Double minDeltaVeeActual, System.Double maxDeltaVeeActual, System.Double minDeltaVeeVacuum, System.Double maxDeltaVeeVacuum, System.String title, System.Single updateFrequency) [0x0009d] in <0ac19348e13c43e280580b62f08ea2eb>:0 at ContractConfigurator.ReachStateFactory.Generate (Contracts.Contract contract) [0x00000] in <0ac19348e13c43e280580b62f08ea2eb>:0 at ContractConfigurator.ParameterFactory.Generate (ContractConfigurator.ConfiguredContract contract, Contracts.IContractParameterHost contractParamHost) [0x00016] in <0ac19348e13c43e280580b62f08ea2eb>:0 at ContractConfigurator.ParameterFactory.GenerateParameters (ContractConfigurator.ConfiguredContract contract, Contracts.IContractParameterHost contractParamHost, System.Collections.Generic.List`1[T] paramFactories) [0x0007e] in <0ac19348e13c43e280580b62f08ea2eb>:0 at ContractConfigurator.ParameterFactory.GenerateParameters (ContractConfigurator.ConfiguredContract contract, Contracts.IContractParameterHost contractParamHost, System.Collections.Generic.List`1[T] paramFactories) [0x0008c] in <0ac19348e13c43e280580b62f08ea2eb>:0 at ContractConfigurator.ParameterFactory.GenerateParameters (ContractConfigurator.ConfiguredContract contract, Contracts.IContractParameterHost contractParamHost, System.Collections.Generic.List`1[T] paramFactories) [0x0008c] in <0ac19348e13c43e280580b62f08ea2eb>:0 at ContractConfigurator.ContractType.GenerateParameters (ContractConfigurator.ConfiguredContract contract) [0x00000] in <0ac19348e13c43e280580b62f08ea2eb>:0 at ContractConfigurator.ConfiguredContract.Initialize (ContractConfigurator.ContractType contractType) [0x00221] in <0ac19348e13c43e280580b62f08ea2eb>:0 I have recently viewed Eve with a Telescope and opened it up as a body that I can select / see. I started playing with Research Bodies for the First time. This doesn't appear on the Github repo as a known issue and Im sure that other have played with this combination and think something else must be causing this issue with EVE / ScanSAT. Any Advice to remedy this would be greatly appreciate. I can produce a drive link with full logs if that is needed. Alternatively, I would be happy with a "Do Not Know About a FIX, but it is safe to ignore exceptions and keep playing" Quote Link to comment Share on other sites More sharing options...
Lisias Posted January 2 Share Posted January 2 On 12/30/2024 at 7:58 PM, Fizzlebop Smith said: I have encountered an issue that has never happened before. It seems to be coming from SCAN SAT related to celestial bodies. This is the second time i have played a Career Save with ScanSAT and OPM. The first time lasted much longer than this play through without this issue... so now I think I must have done something else. The error that I was given told me to come to this thread and post in the error message. Looks like a Localization issue. Are you using other language other than EN-US? Quote Link to comment Share on other sites More sharing options...
damerell Posted January 2 Share Posted January 2 On 12/30/2024 at 10:58 PM, Fizzlebop Smith said: I have encountered an issue that has never happened before. It seems to be coming from SCAN SAT related to celestial bodies. This is the second time i have played a Career Save with ScanSAT and OPM. The first time lasted much longer than this play through without this issue... so now I think I must have done something else. The error that I was given told me to come to this thread and post in the error message Perhaps I am missing something, but which part of the log told you to "come to this thread and post in the error message"? Quote Link to comment Share on other sites More sharing options...
Mr. Kerbin Posted January 2 Share Posted January 2 54 minutes ago, damerell said: Perhaps I am missing something, but which part of the log told you to "come to this thread and post in the error message"? Perhaps it was in-game? Quote Link to comment Share on other sites More sharing options...
Fizzlebop Smith Posted January 6 Share Posted January 6 On 1/1/2025 at 9:03 PM, damerell said: Perhaps I am missing something, but which part of the log told you to "come to this thread and post in the error message"? The window that the error appeared in is headed by the message to come to this thread. It is not the alt+f12 / console. But a window that opens with a standard KSP UI theme with a heading & that snippet of log. It has something to do with the (module?) pf2bodies - (I think) this is not being properly populated by the conditions . Then the config file for evelowresolution has a minimum requirement of scanning for Minmus & Mun. I have not scanned these Two bodies to the 35% requirement. The contract is being told to initiate and then conflicting because the requisites are not yet met. At least I think this is it. On 1/1/2025 at 6:05 PM, Lisias said: Looks like a Localization issue. Are you using other language other than EN-US? I do not. It is possible there is a LOC error but I've never messed with language settings. I posted what I thought was happening. That's just from me reading all the config files for scansat & the conteacts though. It is not based on an experienced troubleshooter or anything Quote Link to comment Share on other sites More sharing options...
Lisias Posted January 7 Share Posted January 7 2 hours ago, Fizzlebop Smith said: That's just from me reading all the config files for scansat & the conteacts though. It is not based on an experienced troubleshooter or anything Well... There's no other option but to dig into the mess. Post the full KSP.log and the ModuleManager.ConfigCache when the problem happens. With a bit of luck, we will be able to find the problem. Quote Link to comment Share on other sites More sharing options...
JonnyOThan Posted January 25 Share Posted January 25 On 12/28/2024 at 5:19 PM, Lisias said: TL;DR: Kopernicus should be patching DwarfPlanetsPlus using ":FOR[DwarfPlanetsPlus]:NEEDS[DwarfPlanetsPlus]". The needs will prevent the patch from being applied if DPP is not installed, and the :FOR will patch it in the "FOR" loop, allowing you to correctly apply :AFTER . Kopernicus isn’t the mod doing that patch, it’s DwarfPlanetsPlus itself. Therefore NEEDS is redundant. I don’t know if there are things in the Kopernicus pass that DwarfPlanetsPlus actually needs to be ordered after (probably not). Be careful with FOR and conditional patches, because the existence of FOR is *not* conditional. Any patch that includes a FOR clause tells MM that the mod is installed regardless of whether its conditions are met. It is a cardinal sin to use FOR with a mod identifier that is not the mod containing the patch itself, because it will cause other patches to activate when they shouldn’t. On 12/28/2024 at 10:56 PM, Professor K said: But the resolution to the issue was to change them to a FOR[name], so they are no longer present. Thanks for the confirmation though. Can you elaborate on this? On 12/28/2024 at 3:57 PM, Professor K said: After examining the config files from other planet packs I modified the planet pack files for start with "@Kopernicus:FOR[DwarfPlanetsPlus]" Ah, you added this to the DwarfPlanetsPlus files? That seems reasonable. Quote Link to comment Share on other sites More sharing options...
Lisias Posted January 25 Share Posted January 25 (edited) 11 hours ago, JonnyOThan said: Kopernicus isn’t the mod doing that patch, it’s DwarfPlanetsPlus itself. Therefore NEEDS is redundant. I don’t know if there are things in the Kopernicus pass that DwarfPlanetsPlus actually needs to be ordered after (probably not). Read the post again, you didn't understood the problem neither the solution. The user wasn't patching from Kopernicus, they were patching from other patches that aimed to support DwarfPlanetsPlus. The solution the user ended up coming from was to make these patches to run exactly at the same Pass as DwarfPlanetsPlus, and so the :FOR[DwarfPlanetsPlus]. But since :FOR also creates a tag into Module Manager with that symbol, it would fool everybody (including MM) to believe DwarfPlanetsPlus would still be installed if the user decides to remove DwarfPlanetsPlus from the installment, and so things would get screwed. Using :NEEDS[DwarfPlanetsPlus] prevents the mess, as the whole patch would be removed when DwarfPlanetsPlus is not installed, preventing the :FOR from kicking in. Hint: On 12/26/2024 at 2:57 PM, Professor K said: I'm having a timing issue with a module manager patch. MM appears to be trying to run it before the mod specified in it's AFTER clause. KSP (latest, on PC) Kopernicus 2.19 Dwarf Planets Plus planet pack self written patch Emphasis are mine. ---- POST EDIT ---- And, finally, my thick skull finally got rid of some idealized misconceptions about MM and its Community, allowing me to see I had made a mistake. :FOR always create a "modname" on the MM's taglist, and :NEEDS only prevents the Patching Phase between :BEFORE and :AFTER . The full story will be found here. Edited January 25 by Lisias POST EDIT Quote Link to comment Share on other sites More sharing options...
JonnyOThan Posted January 25 Share Posted January 25 (edited) 33 minutes ago, Lisias said: Using :NEEDS[DwarfPlanetsPlus] prevents the mess, as the whole patch would be removed when DwarfPlanetsPlus is not installed, preventing the :FOR from kicking in. No, it doesn’t. That’s exactly what I’m warning about. FOR[X]:NEEDS[Y] declares that X exists regardless of whether Y does. 34 minutes ago, Lisias said: The user wasn't patching from Kopernicus Sure, but you said “kopernicus should be patching” Edited January 25 by JonnyOThan Quote Link to comment Share on other sites More sharing options...
Lisias Posted January 25 Share Posted January 25 (edited) 16 hours ago, JonnyOThan said: No, it doesn’t. That’s exactly what I’m warning about. FOR[X]:NEEDS[Y] declares that X exists regardless of whether Y does. Yes, it does. :NEEDS remove the patch before :FOR kicks in. This behaviour is documented and confirmed: Additionally, the very MM documentation says explicitly: Quote Nodes with no operator ('insert') are loaded by the KSP GameDatabase first. Patches for modname values in NEEDS, BEFORE, AFTER that don't exist are removed. All patches with :FIRST are applied. All patches without an ordering directive (:FIRST, :BEFORE, :FOR, :AFTER, :LAST, :FINAL) are applied. For each item in the Unicode-sorted list of modname values: All patches with :BEFORE are applied All patches with :FOR are applied All patches with :AFTER are applied All patches with :LAST are applied in order All patches with :FINAL are applied And, of course, there's also the source code. Please let me know if you need assistance on reading it! ---- POST EDIT ---- And, finally, my thick skull finally got rid of some idealized misconceptions about MM and its Community, allowing me to see I had made a mistake. :FOR always create a "modname" on the MM's taglist, and :NEEDS only prevents the Patching Phase between :BEFORE and :AFTER . The full story will be found here. Edited January 26 by Lisias POST EDIT Quote Link to comment Share on other sites More sharing options...
Professor K Posted January 25 Share Posted January 25 2 hours ago, Lisias said: The solution the user ended up coming from was to make these patches to run exactly at the same Pass as DwarfPlanetsPlus, and so the :FOR[DwarfPlanetsPlus]. But since :FOR also creates a tag into Module Manager with that symbol, it would fool everybody (including MM) to believe DwarfPlanetsPlus would still be installed if the user decides to remove DwarfPlanetsPlus from the installment, and so things would get screwed. Using :NEEDS[DwarfPlanetsPlus] prevents the mess, as the whole patch would be removed when DwarfPlanetsPlus is not installed, preventing the :FOR from kicking in. That was indeed was how I had ended up writing them. Example: @DEPLOYEDSCIENCE:NEEDS[DwarfPlanetsPlus&SquadExpansion/Serenity]:AFTER[DwarfPlanetsPlus] -K (In case anyone is curious, the patches add the necessary info to the game for the Seismic deployed science experiment to work on the added planets. ) Spoiler //This file adds Deployed Seismic Science Experiment config values for the Dwarf Planets Plus mod. //Note: This only works for a NEW saved game. //Note: This is the version for planet mods that do not have "mass" keys (they are allowing Kopernicus to calculate the mass) //Stock Energy is roughly: MASS / 1.25e12 //KSP Gravitational Constant is 6.67408E-11 (0.0000000000667408) @DEPLOYEDSCIENCE:NEEDS[DwarfPlanetsPlus&SquadExpansion/Serenity]:AFTER[DwarfPlanetsPlus] { @SEISMICENERGY { ENTRY { BodyName = Morbheana // Energy = (tmpG * (tmpR * tmpR)) / 0.0000000000667408 tmpG = #$@Kopernicus/Body[Morbheana]/Properties/geeASL$ //Get the gee at Sea Level @tmpG *= 9.80665 //Convert geeASL to meter per second tmpR = #$@Kopernicus/Body[Morbheana]/Properties/radius$ //Get the body's radius @tmpR *= #$tmpR$ //Square the Radius @tmpR *= #$tmpG$ //Multiply the Squared Radius by the G in m/s Energy = #$tmpR$ //Set the result of the above for further maths @Energy /= 0.0000000000667408 //Divide by the KSP Gravitational Constant to give us the body's mass @Energy /= 1.25e12 //Divide mass by the stock energy divisor to give us the Energy setting for the body !tmpR = DELETE !tmpG = DELETE } ENTRY { BodyName = Cador tmpG = #$@Kopernicus/Body[Cador]/Properties/geeASL$ @tmpG *= 9.80665 tmpR = #$@Kopernicus/Body[Cador]/Properties/radius$ @tmpR *= #$tmpR$ @tmpR *= #$tmpG$ Energy = #$tmpR$ @Energy /= 0.0000000000667408 @Energy /= 1.25e12 !tmpR = DELETE !tmpG = DELETE } ENTRY { BodyName = Talus tmpG = #$@Kopernicus/Body[Talus]/Properties/geeASL$ @tmpG *= 9.80665 tmpR = #$@Kopernicus/Body[Talus]/Properties/radius$ @tmpR *= #$tmpR$ @tmpR *= #$tmpG$ Energy = #$tmpR$ @Energy /= 0.0000000000667408 @Energy /= 1.25e12 !tmpR = DELETE !tmpG = DELETE } ENTRY { BodyName = Virani tmpG = #$@Kopernicus/Body[Virani]/Properties/geeASL$ @tmpG *= 9.80665 tmpR = #$@Kopernicus/Body[Virani]/Properties/radius$ @tmpR *= #$tmpR$ @tmpR *= #$tmpG$ Energy = #$tmpR$ @Energy /= 0.0000000000667408 @Energy /= 1.25e12 !tmpR = DELETE !tmpG = DELETE } ENTRY { BodyName = Walru tmpG = #$@Kopernicus/Body[Walru]/Properties/geeASL$ @tmpG *= 9.80665 tmpR = #$@Kopernicus/Body[Walru]/Properties/radius$ @tmpR *= #$tmpR$ @tmpR *= #$tmpG$ Energy = #$tmpR$ @Energy /= 0.0000000000667408 @Energy /= 1.25e12 !tmpR = DELETE !tmpG = DELETE } ENTRY { BodyName = Zevrin tmpG = #$@Kopernicus/Body[Zevrin]/Properties/geeASL$ @tmpG *= 9.80665 tmpR = #$@Kopernicus/Body[Zevrin]/Properties/radius$ @tmpR *= #$tmpR$ @tmpR *= #$tmpG$ Energy = #$tmpR$ @Energy /= 0.0000000000667408 @Energy /= 1.25e12 !tmpR = DELETE !tmpG = DELETE } ENTRY { BodyName = Awe tmpG = #$@Kopernicus/Body[Awe]/Properties/geeASL$ @tmpG *= 9.80665 tmpR = #$@Kopernicus/Body[Awe]/Properties/radius$ @tmpR *= #$tmpR$ @tmpR *= #$tmpG$ Energy = #$tmpR$ @Energy /= 0.0000000000667408 @Energy /= 1.25e12 !tmpR = DELETE !tmpG = DELETE } } } Spoiler //This file adds Deployed Science results support for the Dwarf Planets Plus mod. @EXPERIMENT_DEFINITION:HAS[#id[deployedSeismicSensor]]:NEEDS[DwarfPlanetsPlus&SquadExpansion/Serenity] { @RESULTS { %MorbheanaSrfLanded = Seismic data gathered from impacts on the surface of Morbheana. %CadorSrfLanded = Seismic data gathered from impacts on the surface of Cador. %TalusSrfLanded = Seismic data gathered from impacts on the surface of Talus. %ViraniSrfLanded = Seismic data gathered from impacts on the surface of Virani. %WalruSrfLanded = Seismic data gathered from impacts on the surface of Walru. %ZevrinSrfLanded = Seismic data gathered from impacts on the surface of Zevrin. %CruachanSrfLanded = Seismic data gathered from impacts on the surface of Cruachan. %AweSrfLanded = Seismic data gathered from impacts on the surface of Awe. } } //None of the DDP bodies have an atmosphere, therefor this section is not needed. Left here for those who mod the mod to have atmospheres. //@EXPERIMENT_DEFINITION:HAS[#id[deployedWeatherReport]]:NEEDS[DwarfPlanetsPlus&SquadExpansion/Serenity] //{ // @RESULTS // { // %MorbheanaSrfLanded = Weather information gathered from the surface of Morbheana. // %CadorSrfLanded = Weather information gathered from the surface of Cador. // %TalusSrfLanded = Weather information gathered from the surface of Talus. // %ViraniSrfLanded = Weather information gathered from the surface of Virani. // %WalruSrfLanded = Weather information gathered from the surface of Walru. // %ZevrinSrfLanded = Weather information gathered from the surface of Zevrin. // %CruachanSrfLanded = Weather information gathered from the surface of Cruachan. // %AweSrfLanded = Weather information gathered from the surface of Awe. // } //} @EXPERIMENT_DEFINITION:HAS[#id[deployedGooObservation]]:NEEDS[DwarfPlanetsPlus&SquadExpansion/Serenity] { @RESULTS { %MorbheanaSrfLanded = Long term Mystery Goo observation data from the surface of Morbheana. %CadorSrfLanded = Long term Mystery Goo observation data from the surface of Cador. %TalusSrfLanded = Long term Mystery Goo observation data from the surface of Talus. %ViraniSrfLanded = Long term Mystery Goo observation data from the surface of Virani. %WalruSrfLanded = Long term Mystery Goo observation data from the surface of Walru. %ZevrinSrfLanded = Long term Mystery Goo observation data from the surface of Zevrin. %CruachanSrfLanded = Long term Mystery Goo observation data from the surface of Cruachan. %AweSrfLanded = Long term Mystery Goo observation data from the surface of Awe. } } @EXPERIMENT_DEFINITION:HAS[#id[deployedIONCollector]]:NEEDS[DwarfPlanetsPlus&SquadExpansion/Serenity] { @RESULTS { %MorbheanaSrfLanded = Ion detector data gathered from the surface of Morbheana. %CadorSrfLanded = Ion detector data gathered from the surface of Cador. %TalusSrfLanded = Ion detector data gathered from the surface of Talus. %ViraniSrfLanded = Ion detector data gathered from the surface of Virani. %WalruSrfLanded = Ion detector data gathered data from the surface of Walru. %ZevrinSrfLanded = Ion detector data gathered data from the surface of Zevrin. %CruachanSrfLanded = Ion detector data gathered data from the surface of Cruachan. %AweSrfLanded = Ion detector data gathered from the surface of Awe. } } Quote Link to comment Share on other sites More sharing options...
JonnyOThan Posted January 25 Share Posted January 25 2 hours ago, Professor K said: Example: @DEPLOYEDSCIENCE:NEEDS[DwarfPlanetsPlus&SquadExpansion/Serenity]:AFTER[DwarfPlanetsPlus] Cool - just FYI, AFTER implies NEEDS so including DwarfPlanetsPlus in the NEEDS clause is redundant, but harmless. 4 hours ago, Lisias said: Yes, it does. :NEEDS remove the patch before :FOR kicks in. This behaviour is documented and confirmed: No, it doesn't. Why didn't you test it instead of relying on the documentation? The documentation you cited is explaining the patch ordering. It doesn't say anything about how MM gathers which pass identifiers exist, which is where the potential stumbling block is. Given this patch: @KOPERNICUS:FOR[ThisModDoesntExist]:NEEDS[AnotherModThatDoesntExist] { } !PART[mk1pod_v2]:NEEDS[ThisModDoesntExist] { } You'd expect the mk1pod to NOT be deleted, because the first patch should be removed, right? Wrong: [LOG 10:37:34.166] Config(@KOPERNICUS:FOR[ThisModDoesntExist]:NEEDS[AnotherModThatDoesntExist]) /weirdpatch/@KOPERNICUS:FOR[ThisModDoesntExist]:NEEDS[AnotherModThatDoesntExist] [LOG 10:37:34.166] Config(!PART[mk1pod_v2]:NEEDS[ThisModDoesntExist]) /weirdpatch/!PART[mk1pod_v2]:NEEDS[ThisModDoesntExist] [LOG 10:37:34.228] Config(PART) Squad/Parts/Command/mk1pod_v2/mk1Pod_v2/mk1pod_v2 Changed : /weirdpatch.cfg.cfg ThisModDoesntExist [LOG 10:37:33.968] Deleting root node in file /weirdpatch node: @KOPERNICUS:FOR[ThisModDoesntExist]:NEEDS[AnotherModThatDoesntExist] as it can't satisfy its NEEDS [LOG 10:37:34.115] Applying delete /weirdpatch/!PART[mk1pod_v2]:NEEDS[ThisModDoesntExist] to Squad/Parts/Command/mk1pod_v2/mk1Pod_v2.cfg/PART[mk1pod_v2] [LOG 10:37:34.330] :BEFORE[THISMODDOESNTEXIST] pass [LOG 10:37:34.330] :FOR[THISMODDOESNTEXIST] pass [LOG 10:37:34.330] :AFTER[THISMODDOESNTEXIST] pass Quote Link to comment Share on other sites More sharing options...
Lisias Posted January 25 Share Posted January 25 (edited) On 1/25/2025 at 12:42 PM, JonnyOThan said: No, it doesn't. Why didn't you test it instead of relying on the documentation? The documentation you cited is explaining the patch ordering. It doesn't say anything about how MM gathers which pass identifiers exist, which is where the potential stumbling block is. Why you just don't read what people sends you to read? You force people to repeat themselves again and again for no reason. Heck... You can just watch the MM patching log, by God's sake. Take these synthetic patches on a completely clean GameData (but latest ModuleManager): Put each patch on the file I mention between []: [GameData/ModA/config.cfg] PART { name = ModA-Part title = This is the title of ModA. } [GameData/ModB/config.cfg] @PART[this-does-not-exists] { title = Just to force the ModB tag on th MM taglist } [GameData/ModC/config.cfg] @PART[ModA-Part]:FOR[ModA]:NEEDS[ModA,ModB,ModC] // Using ModC in :NEEDS is pleonasm, as we are ModC and we are installed! { @title ^= :$: And ModC was here!: } Run KSP, and check the ConfigCache! This is a piece of the ConfigCache with the ModB present: UrlConfig { parentUrl = ModA/config.cfg PART { name = ModA-Part title = This is the title of ModA. And ModC was here! } } And this is the MM Log: Spoiler [LOG 14:48:47.840] Loading Physics.cfg [LOG 14:48:47.843] Extracting patches [LOG 14:48:48.024] Applying patches [LOG 14:48:48.027] :INSERT (initial) pass [LOG 14:48:48.202] :FIRST pass [LOG 14:48:48.202] :LEGACY (default) pass [LOG 14:48:48.211] :BEFORE[ASSEMBLY-CSHARP] pass [LOG 14:48:48.211] :FOR[ASSEMBLY-CSHARP] pass [LOG 14:48:48.211] :AFTER[ASSEMBLY-CSHARP] pass [LOG 14:48:48.211] :BEFORE[KSPSTEAMCTRLR] pass [LOG 14:48:48.211] :FOR[KSPSTEAMCTRLR] pass [LOG 14:48:48.211] :AFTER[KSPSTEAMCTRLR] pass [LOG 14:48:48.211] :BEFORE[MODA] pass [LOG 14:48:48.211] :FOR[MODA] pass [LOG 14:48:48.215] Applying update ModC/config/@PART[ModA-Part]:FOR[ModA]:NEEDS[ModA,ModB,ModC] to ModA/config.cfg/PART[Mo dA-Part] [LOG 14:48:48.230] :AFTER[MODA] pass [LOG 14:48:48.230] :BEFORE[MODB] pass [LOG 14:48:48.230] :FOR[MODB] pass [LOG 14:48:48.230] :AFTER[MODB] pass [LOG 14:48:48.230] :BEFORE[MODC] pass [LOG 14:48:48.230] :FOR[MODC] pass [LOG 14:48:48.230] :AFTER[MODC] pass [LOG 14:48:48.230] :BEFORE[MODULEMANAGER] pass [LOG 14:48:48.230] :FOR[MODULEMANAGER] pass [LOG 14:48:48.230] :AFTER[MODULEMANAGER] pass [LOG 14:48:48.230] :BEFORE[SQUAD] pass [LOG 14:48:48.230] :FOR[SQUAD] pass [LOG 14:48:48.230] :AFTER[SQUAD] pass [LOG 14:48:48.230] :BEFORE[SQUADEXPANSION] pass [LOG 14:48:48.230] :FOR[SQUADEXPANSION] pass [LOG 14:48:48.230] :AFTER[SQUADEXPANSION] pass [LOG 14:48:48.233] :FINAL pass [LOG 14:48:48.233] Done patching [LOG 14:48:48.234] Saving Cache [LOG 14:48:48.501] Saving cache [LOG 14:48:50.491] ModuleManager: 1 patch applied And now follows after removing ModB: UrlConfig { parentUrl = ModA/config.cfg PART { name = ModA-Part title = This is the title of ModA. } } And this is the MM Log: Spoiler [LOG 15:05:12.685] Loading Physics.cfg [LOG 15:05:12.688] Extracting patches [LOG 15:05:12.706] Deleting root node in file ModC/config node: @PART[ModA-Part]:FOR[ModA]:NEEDS[ModA,ModB,ModC] as it can 't satisfy its NEEDS [LOG 15:05:12.852] Applying patches [LOG 15:05:12.855] :INSERT (initial) pass [LOG 15:05:13.016] :FIRST pass [LOG 15:05:13.016] :LEGACY (default) pass [LOG 15:05:13.023] :BEFORE[ASSEMBLY-CSHARP] pass [LOG 15:05:13.023] :FOR[ASSEMBLY-CSHARP] pass [LOG 15:05:13.023] :AFTER[ASSEMBLY-CSHARP] pass [LOG 15:05:13.023] :BEFORE[KSPSTEAMCTRLR] pass [LOG 15:05:13.023] :FOR[KSPSTEAMCTRLR] pass [LOG 15:05:13.023] :AFTER[KSPSTEAMCTRLR] pass [LOG 15:05:13.023] :BEFORE[MODA] pass [LOG 15:05:13.023] :FOR[MODA] pass [LOG 15:05:13.023] :AFTER[MODA] pass [LOG 15:05:13.023] :BEFORE[MODC] pass [LOG 15:05:13.023] :FOR[MODC] pass [LOG 15:05:13.023] :AFTER[MODC] pass [LOG 15:05:13.023] :BEFORE[MODULEMANAGER] pass [LOG 15:05:13.023] :FOR[MODULEMANAGER] pass [LOG 15:05:13.023] :AFTER[MODULEMANAGER] pass [LOG 15:05:13.023] :BEFORE[SQUAD] pass [LOG 15:05:13.023] :FOR[SQUAD] pass [LOG 15:05:13.023] :AFTER[SQUAD] pass [LOG 15:05:13.023] :BEFORE[SQUADEXPANSION] pass [LOG 15:05:13.023] :FOR[SQUADEXPANSION] pass [LOG 15:05:13.023] :AFTER[SQUADEXPANSION] pass [LOG 15:05:13.025] :FINAL pass [LOG 15:05:13.026] Done patching [LOG 15:05:13.027] Saving Cache [LOG 15:05:13.280] Saving cache [LOG 15:05:15.755] ModuleManager: 0 patches applied (0 %) [LOG 15:05:15.755] Ran in 3.664s [LOG 15:05:15.801] Done! And I want to pinpoint these lines: [LOG 15:05:12.688] Extracting patches [LOG 15:05:12.706] Deleting root node in file ModC/config node: @PART[ModA-Part]:FOR[ModA]:NEEDS[ModA,ModB,ModC] as it can 't satisfy its NEEDS [LOG 15:05:12.852] Applying patches Being logged before anything else. The :NEEDS behaviour can be easily verified by merely checking your ModuleManager.log. The documentation matches the code (had you read the code?), the tests above matches both. End of history. If you found a different behaviour on a long time documented feature that have even concrete examples that is proven to work as documented (and, again, there's the Source Code!!), 99% if the time you made a mistake yourself, and that 1% that remains is surely a borderline situation that you found and must be fixed, instead of falsely advertised as the new norm! Again, if you can confirm this misbehaviour in your tests, you found a bug and we should be investigating it and fixing it instead you telling people that a borderline bug is the new norm!! ========= POST EDIT =========== And, in fact, you found a misbehaviour on MM. I tried your weirdpatch thingy, and found: Mod DLLs found: Name Assembly Version Assembly File Version KSPAssembly Version SHA256 Assembly-CSharp 0.0.0.0 0.0.0.0 1.12 8a20892953fc14c02f352b393eb6712c66 ModuleManager 4.2.3.0 4.2.3.0 2.5 95847827ab293b9e82a19b7efb97ffea3e KSPSteamCtrlr 0.0.1.35 0.0.1.35 1675fa4fcb61d014eb1babe7eed703e7f7 Non-DLL mods added (:FOR[xxx]): ThisModDoesntExist Mods by directory (sub directories of GameData): Squad SquadExpansion weirdpatch Mods added by assemblies: [LOG 15:28:33.728] Loading Physics.cfg [LOG 15:28:33.733] Extracting patches [LOG 15:28:33.898] Deleting root node in file weirdpatch/weirdpatch node: @KOPERNICUS:FOR[ThisModDoesntExist]:NEEDS[AnotherModThatDoesntExist] as it ca [LOG 15:28:33.899] Applying patches [LOG 15:28:33.901] :INSERT (initial) pass [LOG 15:28:33.988] :FIRST pass [LOG 15:28:33.988] :LEGACY (default) pass [LOG 15:28:33.992] Applying delete weirdpatch/weirdpatch/!PART[mk1pod_v2]:NEEDS[ThisModDoesntExist] to Squad/Parts/Command/mk1pod_v2/mk1Pod_v2.cfg/PART WE FOUND A BUG, this is not how MM is supposed to work accordingly the documentation. ================= POST POST EDIT ============== The ModList is being extracted before the NEEDS removal, unsurprisingly on the ModListGenerator: https://github.com/sarbian/ModuleManager/blob/c4561925f983e7ae81d9dfd4d11356a35cb6b9b6/ModuleManager/ModListGenerator.cs#L95 That's just so great. I have 3 years of posts to revise now. =============== POST POST POST EDIT ============ Given the ages in which :FOR behaves this way, it's obvious that it should be considered a feature by now and, so, the bug is on documentation. Fixed. https://github.com/sarbian/ModuleManager/wiki/Patch-Ordering/_compare/b97501810baf9625d33f66515fd85b4a00f17564 And the fix fixed: https://github.com/sarbian/ModuleManager/wiki/Patch-Ordering/_compare/04c496d7a2cd11a88df7ef9e39d6384c0e9a578d Now I literally have years of posts to review and update (done!), as well some repositories of mine(WiP). My job now is trying to prevent people from falling in the same booby trap I felt. Edited Monday at 10:37 PM by Lisias We found a bug, Safer to consider a bug in the documentation. Quote Link to comment Share on other sites More sharing options...
JonnyOThan Posted January 25 Share Posted January 25 1 hour ago, Lisias said: WE FOUND A BUG Well, not really. Or just shoddy documentation (no surprise there). It’s not hard to see that “fixing” this is untenable. You can’t evaluate NEEDS until you know what mods are installed, therefore FOR clauses must be evaluated first. Otherwise you could end in a cyclical dependency. So…I guess you didn’t read the source code before you offered to help me read it? Quote Link to comment Share on other sites More sharing options...
Lisias Posted January 25 Share Posted January 25 (edited) 1 hour ago, JonnyOThan said: Well, not really. Or just shoddy documentation (no surprise there). So it's a bug on the documentation. I fixed it first, as it is the canonical source of information. Now I'm fixing everything else I ever wrote about. 1 hour ago, JonnyOThan said: So…I guess you didn’t read the source code before you offered to help me read it? Worst. I did it, but failed to detect the problem due being biased on trusting too much the documentation and the community's willingness on maintaining it... Well, these are fixed by now too. Spoiler yet more embarrassing, I took 45 seconds - FORTY FIVE SECONDS - to detect the code of interest, once I knew what I needed to look. Edited January 25 by Lisias Spoiler Quote Link to comment Share on other sites More sharing options...
Fizzlebop Smith Posted January 25 Share Posted January 25 On 1/6/2025 at 5:06 PM, Lisias said: Well... There's no other option but to dig into the mess. Post the full KSP.log and the ModuleManager.ConfigCache when the problem happens. With a bit of luck, we will be able to find the problem. Where do I find the MM config cache? Is this the logs within MM that are compressed? I'm not really sure what the confic cache looks like, sorry. Quote Link to comment Share on other sites More sharing options...
Lisias Posted January 25 Share Posted January 25 1 minute ago, Fizzlebop Smith said: Where do I find the MM config cache? Is this the logs within MM that are compressed? I'm not really sure what the confic cache looks like, sorry. The ConfigCache can be found in your GameData directory (since we are on Forum, I'm assuming - and advising - you are using ModuleManager.4.2.3.dll that can be downloaded from the OP). If you don't have a ModuleManager.ConfigCache in your GameData directory by the time you reach the Main Menu, then some patch utterly failed and you probably shouldn't be risking your precious savegames on this rig until the problem could be detected and fixed. The Module Manager logs that I mentioned, you will find them on <KSP>/Logs/ModuleManager/. They are named "ModuleManager.log" and "MMPatch.log". The later is a subset of the former, some people prefer this way. You will find a (pretty "small" ) ConfigCache on this link. This file is essentially a snapshot of the GameDatabase after being patched successfully by MM, so in the next boot MM just loads it instead of redoing all the patching from scratch, saving a lot of time in the process (MM does some checks to detect if the GameData had changed, removing the cache if positive so the patches can happen again). Quote Link to comment Share on other sites More sharing options...
Fizzlebop Smith Posted January 25 Share Posted January 25 @Lisias I am going to apologize for the log spam before you ever even open it. Im sure those skill in developmental tools can overcome some degree of log bloat... When CKAN started prompting me to allow older mods into the mix... i got a little carried away. https://drive.google.com/drive/folders/1zPjuVp-UPcE8An9Wf6PHaOAenDSOsvS_?usp=drive_link help is greatly appreciated. Quote Link to comment Share on other sites More sharing options...
Lisias Posted January 26 Share Posted January 26 4 hours ago, Fizzlebop Smith said: I am going to apologize for the log spam before you ever even open it. Logspam is less than a problem when we have a UNIX box around with sed, grep and Perl on the toolset. 4 hours ago, Fizzlebop Smith said: When CKAN started prompting me to allow older mods into the mix... i got a little carried away. Not exactly a bad thing, a reasonably amount of 1.7 and 1.6 era mods (mainly the ones without new Assemblies) will work fine. Some from 1.5 also, and even 1.4 and 1.3 is not impossible (but start to get unlikely). So... Just to sync into the same page, we are talking about the problem from this post, right? Quote Link to comment Share on other sites More sharing options...
OrbitalManeuvers Posted January 26 Share Posted January 26 14 hours ago, Fizzlebop Smith said: https://drive.google.com/drive/folders/1zPjuVp-UPcE8An9Wf6PHaOAenDSOsvS_?usp=drive_link pardon my intrusion, but I know for sure you'll want to get rid of this (MiniAVC). Some older mods bundled this and these days it's broken and causes issues for people. See the mod "ZeroMiniAVC" for more information. This probably won't directly affect whatever issue you're pursuing, but it's a step towards a more healthy install for sure. Loading assembly at C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Mod v2.0\GameData\EditorTime\MiniAVC.dll This one I'm not quite as confident about, but personally I would get rid of both. Loading assembly at C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Mod v2.0\GameData\KIS\Plugins\MiniAVC-V2.dll Quote Link to comment Share on other sites More sharing options...
Fizzlebop Smith Posted Sunday at 06:39 PM Share Posted Sunday at 06:39 PM (edited) 4 hours ago, OrbitalManeuvers said: Spoiler pardon my intrusion, but I know for sure you'll want to get rid of this (MiniAVC). Some older mods bundled this and these days it's broken and causes issues for people. See the mod "ZeroMiniAVC" for more information. This probably won't directly affect whatever issue you're pursuing, but it's a step towards a more healthy install for sure. Loading assembly at C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Mod v2.0\GameData\EditorTime\MiniAVC.dll This one I'm not quite as confident about, but personally I would get rid of both. Loading assembly at C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Mod v2.0\GameData\KIS\Plugins\MiniAVC-V2.dll Could have swore I had run NoMiniAvc at some point with this install. Thanks for the heads up, I know its unrelated to the NRE but probably adds alot to the mess and will be much cleaner. Whats bad, is i know better. 14 hours ago, Lisias said: [snip] So... Just to sync into the same page, we are talking about the problem from this post, right? Correct. That is indeed the one. Also updated Kourageous Tourists and included the new logs in a new folder with (updated) to mark the difference. https://drive.google.com/drive/folders/1zPjuVp-UPcE8An9Wf6PHaOAenDSOsvS_?usp=drive_link Ignoring the exception will reproduce the same message next time i load up the game. If i just select "ok" we play the endless dance with closing the window. I know there was some confusion why i would venture into the MM thread with Scan Sat Errors .. thank for the patience and guidance folks This is the message i am given, and i feel stupid for not reading it closer. I am wondering now at the RO. I do not use real solar systems is this because something is flagging RO as present? Edited Sunday at 06:40 PM by Fizzlebop Smith Quote Link to comment Share on other sites More sharing options...
Lisias Posted Sunday at 07:58 PM Share Posted Sunday at 07:58 PM (edited) 1 hour ago, Fizzlebop Smith said: Could have swore I had run NoMiniAvc at some point with this install. And I completely missed it... Damn... I lost the count of how many times older MiniAVCs had bitten my cheeks, and still I fail to check it now and then. 1 hour ago, Fizzlebop Smith said: I know there was some confusion why i would venture into the MM thread with Scan Sat Errors .. thank for the patience and guidance folks <....> This is the message i am given, and i feel stupid for not reading it closer. Welcome to the club. Confusion and Feeling Stupid are the themes of this weekend, as it appears... 1 hour ago, Fizzlebop Smith said: I am wondering now at the RO. I do not use real solar systems is this because something is flagging RO as present? I finished doing my homework on Forum, and now I'm looking into your case again. I will update this post as I find things. For starters, I found this related ti TourismExpanded (what is it?): [LOG 10:44:14.465] [UIMasterController]: ShowUI [ERR 10:44:15.614] Error calling custom SetDifficultyPreset method in type [TourismExpanded.TourismExpandedSettings, TourismExpanded.TourismExpandedSettings]: [EXC 10:44:15.617] NotImplementedException: The method or operation is not implemented. GameParameters+CustomParameterNode.SetDifficultyPreset (GameParameters+Preset preset) (at <4b449f2841f84227adfaad3149c8fdba>:0) GameParameters.GetDefaultParameters (Game+Modes mode, GameParameters+Preset p) (at <4b449f2841f84227adfaad3149c8fdba>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:LogException(Exception) GameParameters:GetDefaultParameters(Modes, Preset) MainMenu:Start() And also: [LOG 10:44:42.327] [ScienceParamModifier],1/26/2025 10:44:42 AM,Error while loading celestial body default container list; possibly a duplicate entry: System.Nu llReferenceException: Object reference not set to an instance of an object at ScienceParamModifier.ScienceConfigValuesNode+<>c.<OnDecodeFromConfigNode>b__2_0 (ScienceParamModifier.bodyParamsContainer a) [0x00006] in <48c3521c5ab245bb a451b56640a533c3>:0 at System.Linq.Enumerable.ToDictionary[TSource,TKey,TElement] (System.Collections.Generic.List`1[T] source, System.Func`2[T,TResult] keySelector, System.Func` 2[T,TResult] elementSelector, System.Collections.Generic.IEqualityComparer`1[T] comparer) [0x0001e] in <351e49e2a5bf4fd6beabb458ce2255f3>:0 at System.Linq.Enumerable.ToDictionary[TSource,TKey,TElement] (System.Collections.Generic.IEnumerable`1[T] source, System.Func`2[T,TResult] keySelector, Syste m.Func`2[T,TResult] elementSelector, System.Collections.Generic.IEqualityComparer`1[T] comparer) [0x00066] in <351e49e2a5bf4fd6beabb458ce2255f3>:0 at System.Linq.Enumerable.ToDictionary[TSource,TKey,TElement] (System.Collections.Generic.IEnumerable`1[T] source, System.Func`2[T,TResult] keySelector, Syste m.Func`2[T,TResult] elementSelector) [0x00000] in <351e49e2a5bf4fd6beabb458ce2255f3>:0 at ScienceParamModifier.ScienceConfigValuesNode.OnDecodeFromConfigNode () [0x00000] in <48c3521c5ab245bba451b56640a533c3>:0 What suggests, indeed, a CrapPatchFest in your log. There's also: [ERR 10:44:50.643] ContractConfigurator.ContractType: CONTRACT_TYPE 'KerbalAcademyAdvancedPiloting': Error parsing rewardFunds [EXC 10:44:50.651] MissingMethodException: Cannot find function 'max' for class 'Single'. ContractConfigurator.ExpressionParser.ExpressionParser`1[T].GetCalledFunction (System.String functionName, ContractConfigurator.ExpressionParser.Function& s electedMethod, System.Boolean isFunction) (at <50aaafcd0dae43489715b7c388f819df>:0) ContractConfigurator.ExpressionParser.ExpressionParser`1[T].ParseMethod[TResult] (ContractConfigurator.ExpressionParser.BaseParser+Token token, T obj, Syste m.Boolean isFunction) (at <50aaafcd0dae43489715b7c388f819df>:0) ContractConfigurator.ExpressionParser.ExpressionParser`1[T].ParseFunction (ContractConfigurator.ExpressionParser.BaseParser+Token token) (at <50aaafcd0dae43 489715b7c388f819df>:0) ContractConfigurator.ExpressionParser.ExpressionParser`1[T].ParseSimpleStatement[TResult] () (at <50aaafcd0dae43489715b7c388f819df>:0) ContractConfigurator.ExpressionParser.ExpressionParser`1[T].ParseStatementInner[TResult] () (at <50aaafcd0dae43489715b7c388f819df>:0) ContractConfigurator.ExpressionParser.ExpressionParser`1[T].ParseStatement[TResult] () (at <50aaafcd0dae43489715b7c388f819df>:0) ContractConfigurator.ExpressionParser.ExpressionParser`1[T].ParseExpression (System.String key, System.String expression, ContractConfigurator.ExpressionPar ser.DataNode dataNode) (at <50aaafcd0dae43489715b7c388f819df>:0) Rethrow as Exception: Error parsing statement. Error occurred near '*': max(0, @/rewardFunds) ....* <-- HERE Are you using the correct Contract Configurator? This looks as a too old binary to me. Or perhaps a too new? Someone messed up the dotnet target while compiling the Assembly? KSP2 is Unity 2019, still on Mono 4.6... From this point, I don't know if we can trust the rest of the log, as these kind of errors are known to trigger the Assembly Loader/Resolver bug. I will check the patching now, will edit this post Soon™. 1 hour ago, Fizzlebop Smith said: I am wondering now at the RO. I do not use real solar systems is this because something is flagging RO as present? Apparently, nope. It appears to be related to Assemblies or, at very least, mishaps on code. Non-DLL mods added (:FOR[xxx]): 000_ShineFix CommunityPartsTitles zzCommunityPartsTitles zAvalanche zzzzzz-B9PartSwitch BetterKerbol CEP_Laythe CommNetRelays Tourism Hotels CrewRandR CargoBays ExtraplanetaryLaunchpads HeatControl Komplexity Kopernicus_Version OPM ParallaxStock NearFutureLaunchVehicles ProbesBeforeCrew zRationalResources RationalResources 000_ReStock zzReStockPlus ReStockPlus RestockWaterfallExpansion RestockWaterfallExpension StockWaterfallEffects StationPartsExpansionRedux zzzzStationParts StationScience AES HERP PackRat WaterfallRestock zzzzzz_RemoteTech Edited Sunday at 08:34 PM by Lisias Soon™ enough! :) Quote Link to comment Share on other sites More sharing options...
4x4cheesecake Posted Sunday at 09:20 PM Share Posted Sunday at 09:20 PM 2 hours ago, Fizzlebop Smith said: Ignoring the exception will reproduce the same message next time i load up the game. If i just select "ok" we play the endless dance with closing the window. I know there was some confusion why i would venture into the MM thread with Scan Sat Errors .. thank for the patience and guidance folks wild guess: you got "research bodies" installed which hides celestial bodies... I dont know how it does the hiding part under the hood but it kinda looks like it hides them well enough for contract configurator not being able to find them either. Should be easy to try: backup your savegame, uninstall research bodies, and check if the error persists. Don't know how the game reacts to removing the mod, that's what the backup is for. The "RO" part probably just appears there in the box because the latest version is hosted on the KSP-RO repo 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.