Monniasza Posted August 2, 2020 Share Posted August 2, 2020 (edited) This patch generates 3 errors per part. How I can fix it? Here is the patch: //New, improved LPG code //Set up existing LPG module RESOURCE_DEFINITION{ name = LPG displayName = LPG abbreviation = LPG density = 0.00054 //540 g/l unitCost = 0.256 //Calculated based on American prices for LPG - 0.4 $/l and RP-1 -125$/kg hsp = 2010 flowMode = STACK_PRIORITY_SEARCH transfer = PUMP isTweakable = true volume = 1 } // vvv MFT COMPATIBILITY @TANK_DEFINITION[Default,Fuselage,Structural,ServiceModule,Balloon]{ TANK{ name = LPG amount = 0.0 maxAmount = 0.0 utilization = 5 note = (pressurized) } } TANK_DEFINITION{ name = LPG basemass = 0.000050 * volume TANK{ name = LPG amount = full maxAmount = 100% utilization = 5 note = (pressurized) } TANK{ name = Oxidizer amount = 0.0 maxAmount = 0.0 } } TANK_DEFINITION{ name = LPGox basemass = 0.000050 * volume TANK{ name = LPG amount = full maxAmount = 25.9259259259259259259259259259259259259259259259259259259259259259259259259259259259259259259259259259259259259259259259259259259259259259% utilization = 5 note = (pressurized) } TANK{ name = Oxidizer amount = full maxAmount = 74.0740740740740740740740740740740740740740740740740740740740740740740740740740740740740740740740740740740740740740740740740740740740740740% } } //Generate ModuleLPG for known parts @PART[*]:HAS[!MODULE[ModuleLPG]]:FINAL{ MODULE{ name = ModuleLPG } } @PART[*]:FINAL{ lf = 0 ox = 0 @MODULE[ModuleLPG]{ err_a = false err_t = false err_i = false err_c = false err_r = false err_fs = false } } // Handle LPG +PART[*]:FINAL{ fuel = 0 @title = #$title$ (LPG) @name = #$name$_LPG } //Test amount @PART[*_LPG]:HAS[@MODULE[ModuleLPG]:HAS[~amount]]:FINAL{ @MODULE[ModuleLPG]{ @err_a = true } } @PART[*_LPG]:HAS[@MODULE[ModuleLPG]:HAS[#amount]]:FINAL{ @MODULE[ModuleLPG]{ tmp = 0 @tmp += #$amount$ @err_a = false } @MODULE[ModuleLPG]:HAS[#ąmount[-*]|#tmp[0]|#amount[]|#tmp[NaN]|#tmp[*Infinity]]{ @err_a = true } } //Test Isp mutiplier @PART[*_LPG]:HAS[@MODULE[ModuleLPG]:HAS[~isp]]:FINAL{ @MODULE[ModuleLPG]{ @err_i = true } } @PART[*_LPG]:HAS[@MODULE[ModuleLPG]:HAS[#isp]]:FINAL{ @MODULE[ModuleLPG]{ @tmp = 0 @tmp += #$amount$ @err_i = false } @MODULE[ModuleLPG]:HAS[#isp[-*]|#tmp[0]|#isp[]|#tmp[NaN]|#tmp[*Infinity]]{ @err_i = true } } //Test fuel ratio @PART[*_LPG]:HAS[@MODULE[ModuleLPG]:HAS[~ratio]]:FINAL{ @MODULE[ModuleLPG]{ @err_r = true } } @PART[*_LPG]:HAS[@MODULE[ModuleLPG]:HAS[#ratio]]:FINAL{ @MODULE[ModuleLPG]{ @tmp = 0 @tmp += #$amount$ @err_r = false } @MODULE[ModuleLPG]:HAS[#ratio[-*]|#tmp[0]|#ratio[]|#tmp[NaN]|#tmp[*Infinity]]{ @err_r = true } } @PART[*_LPG]:FINAL{ lf = 0 ox = 0 //Test type @MODULE[ModuleLPG]{ %err_t = true } @MODULE[ModuleLPG]:HAS[#type[stock]|#type[fs]|#type[mfs]]{ @err_t = false } //Test tankage @MODULE[ModuleLPG]{ %err_c = true } @MODULE[ModuleLPG]:HAS[#contents[lpg]|#contents[lpgo]|#contents[none]]{ @err_c = false } //Calculate the fuel ratio @MODULE[ModuleLPG]:HAS[#err_r[true]]{ %ratio = 8 } @MODULE[ModuleLPG]:HAS[#err_r[true]]:NEEDS[SMURFF]{ @ratio /= #$@SMURFFCONFIG/lfofactor$ } } //If fuel switchers are present, take fuel from them instead @PART[*_LPG]:HAS[@MODULE[ModuleFuelTanks]:HAS[#type[Default]|#type[Structural]|#typeServiceModule]|#type[Balloon]]:FINAL{ @fuel += #$MODULE[ModuleFuelTanks]/volume$ !MODULE[ModuleFuelTanks] {} @MODULE[ModuleLPG]{ @err_a = false @err_c = false @amount = #$../fuel$ @contents = lpgo @amount = #$../fuel$ } } @PART[*_LPG]:HAS[@MODULE[ModuleFuelTanks]:HAS[#type[Fuselage]]]:FINAL{ @fuel += #$MODULE[ModuleFuelTanks]/volume$ !MODULE[ModuleFuelTanks] {} @MODULE[ModuleLPG]{ @err_a = false @err_c = false @amount = #$../fuel$ @contents = lpg @amount = #$../fuel$ } } @PART[*_LPG]:HAS[@MODULE[ModuleB9PartSwitch]]:FINAL{ @fuel += #$MODULE[ModuleB9PartSwitch]/baseVolume$ !MODULE[ModuleB9PartSwitch] {} @MODULE[ModuleLPG]{ @err_a = false @err_c = false @amount = #$../fuel$ } } @PART[*_LPG]:HAS[@RESOURCE[LiquidFuel]]:FINAL{ @lf += #$RESOURCE[LiquidFuel]/maxAmount$ @fuel += #$lf$ } @PART[*_LPG]:HAS[@RESOURCE[Oxidizer]]:FINAL{ @ox += #$RESOURCE[Oxidizer]/maxAmount$ @fuel += #$ox$ } //@PART[*_LPG]:HAS[!MODULE[ModuleFuelTanks]]:FINAL{ // //Count resources and decompute the mass // @MODULE[ModuleLPG]:HAS[~amount]{ // amount = 0 // lf = 0 // ox = 0 // lf = #$../lf$ // ox = #$../ox$ // @amount = #$lf$ // @amount += #$ox$ // } // @MODULE[ModuleLPG]:HAS[#ox[0]&#lf[0]]{ // %contents = none // } // @MODULE[ModuleLPG]:HAS[#ox[0]&~lf[0]]{ // %contents = lpg // } // @MODULE[ModuleLPG]:HAS[~ox[0]&~lf[0]]{ // %contents = lpgo // } //} @PART[*_LPG]:HAS[MODULE[ModuleFuelTanks]]:FINAL{ //Count resources and decompute the mass @MODULE[ModuleLPG]:HAS[~amount]{ amount = 0 @amount = #$../MODULE[ModularFuelTanks]/volume$ } @MODULE[ModuleLPG]:HAS[#ox[0]&#lf[0]]{ %contents = none } @MODULE[ModuleLPG]:HAS[#ox[0]&~lf[0]]{ %contents = lpg } @MODULE[ModuleLPG]:HAS[~ox[0]&~lf[0]]{ %contents = lpgo } } @PART[*_LPG]:FINAL{ //Create fuel switchers @MODULE[ModuleLPG]{ newMass = #$../mass$ fs = false mfs = false @fs:NEEDS[Firespitter] = true @mfs:NEEDS[RealFuels|ModularFuelTanks] = true } @MODULE[ModuleLPG]:HAS[#err_t[true]]{ type = stock type:NEEDS[Firespitter] = fs type:NEEDS[RealFuels|ModularFuelTanks] = mfs } //If requested fuel switcher is absent, choose other one @MODULE[ModuleLPG]:HAS[#type[mfs]]:NEEDS[!RealFuels&!ModularFuelTanks]{ @type = stock @type:NEEDS[Firespitter] = fs } @MODULE[ModuleLPG]:HAS[#type[fs]]:NEEDS[!Firespitter]{ @type = stock @type:NEEDS[RealFuels|ModularFuelTanks] = mfs } @MODULE[ModuleLPG]{ massFuel = 0 massRemain = 0 @massFuel = #$amount$ @massFuel *= 5 @massFuel /= #$ratio$ @massRemain = #$../mass$ @massRemain -= #$massFuel$ @newMass = #$amount$ @newMass *= 0.05 @newMass += #$massRemain$ } @mass = #$MODULE[ModuleLPG]/newMass$ SSTOLPG = 1.06 } @PART[bluedog_*_LPG]:FINAL{ //Increased LPG improvement - BDB engines have inferior Isp, so increase by 20% @SSTOLPG = 1.22 } @PART[B9_*_LPG]:FINAL{ //Intermediate LPG improvement -both normal and high efficiency engines @SSTOLPG = 1.05 } @PART[RSB*_LPG]:FINAL{ //Realistic LPG improvement @SSTOLPG = 1.04 } @PART[BAEengine*_LPG]:FINAL{ //Increased LPG improvement - BAE engines have inferior Isp, so increase by 20% @SSTOLPG = 1.15 } @PART[*_LPG]:HAS[#manufacturer[Alcentar]]:FINAL{ //RealEngines or LCA @SSTOLPG = 1.06 //Determine if using LCA pack or RealEngines - the second should improve 4% SSTOTMP = #$MODEL/model$ @SSTOTMP ^= "R(.*?)k" //LCA won't match } @PART[*_LPG]:HAS[#SSTOTMP[ealEnginesPac]]:FINAL{ //Realistic improvement - 4% @SSTOLPG = 1.04 } @PART[*_LPG]:FINAL{//Apply the changes for engine - Rockets and jets, no nukes @MODULE[ModuleEngines*]{ @eligible = false } @MODULE[ModuleEngines*]:HAS[@PROPELLANT[LiquidFuel],@PROPELLANT[Oxidizer]]{ //Rockets //3.5:1 mass OX/LPG eligible = true @PROPELLANT[Oxidizer]{ @ratio = 0.7 //3.5 volumetric } @PROPELLANT[LiquidFuel]{ @name = LPG @ratio = 2 //2 volumetric } @atmosphereCurve { k0 = #$key,0[1, ]$ @k0 *= #$../../SSTOLPG$ @key,0 = #0 $k0$ k1 = #$key,1[1, ]$ @k1 *= #$../../SSTOLPG$ @key,1 = #1 $k1$ } } @MODULE[ModuleEngines*]:HAS[@PROPELLANT[LiquidFuel],@PROPELLANT[IntakeAir]]{ //Jets //3.5:1 mass OX/LPG eligible = true @PROPELLANT[IntakeAir]{ @ratio *= 0.15 } @PROPELLANT[LiquidFuel]{ @name = LPG } @atmosphereCurve { k0 = #$key,0[1, ]$ @k0 *= 1.2 @key,0 = #0 $k0$ } } keep = false !RESOURCE[LiquidFuel|Oxidizer] {} } @PART[*_LPG]:HAS[@MODULE[ModuleEngines*]:HAS[#eligible[true]]]:FINAL{ @keep = true } @PART[*_LPG]:HAS[@MODULE[ModuleLPG]:HAS[!contents[none]]]:FINAL{ @keep = true } //Remove unnecessary parts !PART[*_LPG]:HAS[#keep[false]]:FINAL {} //Apply tanks @PART[*_LPG]:HAS[@MODULE[ModuleLPG]:HAS[#type[stock]&contents[lpg]]]:FINAL{ RESOURCE{ name = LPG amount = #$../MODULE[ModuleLPG]/amount$ @amount *= 5 maxAmount = #$amount$ } } @PART[*_LPG]:HAS[@MODULE[ModuleLPG]:HAS[#type[stock]&contents[lpgo]]]:FINAL{ x = 0.7 @x /= 1.35 y = 2 @y /= 1.35 RESOURCE{ name = LPG amount = #$../MODULE[ModuleLPG]/amount$ @amount *= #$../y$ maxAmount = #$amount$ } RESOURCE{ name = Oxidizer amount = #$../MODULE[ModuleLPG]/amount$ @amount *= #$../x$ maxAmount = #$amount$ } } //TODO Firespitter Fuel Switch @PART[*_LPG]:HAS[@MODULE[ModuleLPG]:HAS[#type[mfs]&contents[lpg]]]:FINAL{ MODULE{ name = ModuleFuelTanks type = LPG basemass = #$../mass$ volume = #$../MODULE[ModuleLPG]/amount$ } } @PART[*_LPG]:HAS[@MODULE[ModuleLPG]:HAS[#type[mfs]&contents[lpgo]]]:FINAL{ MODULE{ name = ModuleFuelTanks type = LPGox basemass = #$../mass$ volume = #$../MODULE[ModuleLPG]/amount$ } } And error pattern ('xxx' stands for any part) [LOG] Applying update SSTOProject/LPG new/@PART[*_LPG]:FINAL to xxx [WRN] Cannot find key newMass in MODULE [ERR] Error - Cannot parse variable search when editing key mass = #$MODULE[ModuleLPG]/newMass$ [WRN] Cannot find key amount in MODULE [ERR] Error - Cannot parse variable search when editing key massFuel = #$amount$ [WRN] Cannot find key amount in MODULE [ERR] Error - Cannot parse variable search when editing key newMass = #$amount$ Mods used: Procedural Parts, SMURFF, Modular Fuel Tanks, both DLC Edited August 2, 2020 by Monniasza mods Quote Link to comment Share on other sites More sharing options...
TranceaddicT Posted August 2, 2020 Share Posted August 2, 2020 (edited) @Monniasza So, there are a few issues that I can see. First thing is you are using '@' where you should be using '%'. Example: Spoiler This ... +PART[*]:FINAL { fuel = 0 @title = #$title$ (LPG) @name = #$name$_LPG } Should be ... +PART[*]:FINAL { fuel = 0 %title = #$title$ (LPG) %name = #$name$_LPG } Also, you can rollup the creation of and key assignment to ModuleLPG. Spoiler @PART[*]:HAS[!MODULE[ModuleLPG]]:FINAL { lf = 0 ox = 0 MODULE { name = ModuleLPG err_a = false err_t = false err_i = false err_c = false err_r = false err_fs = false } } Sidenote: the 'lf' and 'lo' keys are not used anywhere that I know of or I can see. In this patch this pairing is one (1) of three (3) references. I think you can drop them. Finally, (to actually address your concern) It's because you create ModuleLPG and assign it keys (err_*) but that is all. So you have a ModuleLPG with a bunch of error codes that looks like this ... MODULE { name = ModuleLPG lf = 0 ox = 0 { err_a = false err_t = false err_i = false err_c = false err_r = false err_fs = false } } These messages ... Cannot parse variable search when editing key mass = #$MODULE[ModuleLPG]/newMass$ Cannot parse variable search when editing key massFuel = #$amount$ Cannot parse variable search when editing key newMass = #$amount$ ... are telling you when MM goes to make its calculations using its internal keys for 'massFuel '& 'newMass', it can't do the calculations ... because the initial key they are parsed from, 'mass', isn't present. Edited August 2, 2020 by TranceaddicT Quote Link to comment Share on other sites More sharing options...
blowfish Posted August 2, 2020 Share Posted August 2, 2020 13 hours ago, Monniasza said: [LOG] Applying update SSTOProject/LPG new/@PART[*_LPG]:FINAL to xxx [WRN] Cannot find key newMass in MODULE [ERR] Error - Cannot parse variable search when editing key mass = #$MODULE[ModuleLPG]/newMass$ [WRN] Cannot find key amount in MODULE [ERR] Error - Cannot parse variable search when editing key massFuel = #$amount$ [WRN] Cannot find key amount in MODULE [ERR] Error - Cannot parse variable search when editing key newMass = #$amount$ All values are processed before all nodes. It's a limitation of KSP's parser. So for instance @mass = #$MODULE[ModuleLPG]/newMass$ will be processes before you have added the newMass. The workaround is to put that in a separate patch. 6 hours ago, TranceaddicT said: First thing is you are using '@' where you should be using '%'. Example: Spoiler This ... +PART[*]:FINAL { fuel = 0 @title = #$title$ (LPG) @name = #$name$_LPG } Should be ... +PART[*]:FINAL { fuel = 0 %title = #$title$ (LPG) %name = #$name$_LPG } @ should work fine in general here. When will there be a part without name or title? Quote Link to comment Share on other sites More sharing options...
TranceaddicT Posted August 3, 2020 Share Posted August 3, 2020 19 hours ago, blowfish said: @ should work fine in general here. When will there be a part without name or title? Okay, I was under the impression @ was used as a pointer ("go here"). While +/% were create/edit this value. Quote Link to comment Share on other sites More sharing options...
blowfish Posted August 3, 2020 Share Posted August 3, 2020 36 minutes ago, TranceaddicT said: Okay, I was under the impression @ was used as a pointer ("go here"). While +/% were create/edit this value. In this context, @ means edit the existing value and % means "edit the value or create it if it doesn't already exist. Quote Link to comment Share on other sites More sharing options...
JDCollie Posted August 4, 2020 Share Posted August 4, 2020 I'm having trouble reassigning the Tech Required for the stock command parts. @PART[mk1pod|mk2LanderCabin]:NEEDS[CommunityTechTree] { @TechRequired = simpleCommandModules } @PART[probeCoreSphere]:NEEDS[CommunityTechTree] { @TechRequired = start } @PART[longAntenna]:NEEDS[CommunityTechTree]:FINAL { @TechRequired = survivability } I've tried with the :FINAL tag to no avail. I've also tried this running only Module Manager, Community Tech Tree, and my config mod. I am able to reassign other parts without issue (the Communotron 16 moves to survivability just like expected), but command parts refuse to budge. What am I doing wrong? Quote Link to comment Share on other sites More sharing options...
DStaal Posted August 4, 2020 Share Posted August 4, 2020 8 minutes ago, JDCollie said: I'm having trouble reassigning the Tech Required for the stock command parts. @PART[mk1pod|mk2LanderCabin]:NEEDS[CommunityTechTree] { @TechRequired = simpleCommandModules } @PART[probeCoreSphere]:NEEDS[CommunityTechTree] { @TechRequired = start } @PART[longAntenna]:NEEDS[CommunityTechTree]:FINAL { @TechRequired = survivability } I've tried with the :FINAL tag to no avail. I've also tried this running only Module Manager, Community Tech Tree, and my config mod. I am able to reassign other parts without issue (the Communotron 16 moves to survivability just like expected), but command parts refuse to budge. What am I doing wrong? Do you have your MM logs someplace? Quote Link to comment Share on other sites More sharing options...
JDCollie Posted August 4, 2020 Share Posted August 4, 2020 (edited) 1 hour ago, DStaal said: Do you have your MM logs someplace? [LOG 12:53:59.281] Log started at 2020-08-04 12:53:59.281 [LOG 12:54:00.392] Checking Cache [LOG 12:54:00.581] SHA generated in 0.186s [LOG 12:54:00.581] SHA = C8-B0-87-4B-B5-CD-E2-74-ED-E7-7D-17-D1-C2-C7-43-7C-73-A4-57-AA-37-B2-1E-48-3F-F7-1D-E5-40-AA-A0 [LOG 12:54:00.596] Changes : Changed : JDTechTree/Tree/JDTechTree.cfg.cfg [LOG 12:54:00.596] Cache SHA = 74-5B-DE-0A-EC-3C-2D-52-2E-84-97-BB-2D-EF-12-76-BE-37-12-B6-95-F7-B6-3E-A1-19-10-32-38-D0-52-28 [LOG 12:54:00.596] useCache = False [LOG 12:54:00.599] Pre patch init [LOG 12:54:00.799] 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.10 535f53fe218e045b57a9d56b78878c944261cf2a4a20b975b19ea8f58c423ec6 ModuleManager 4.1.4.0 4.1.4.0 2.5 c3a771f61e578ac9e9d69ac642ddd98dde19de8e26635266876748c86b829d81 KSPSteamCtrlr 0.0.1.35 0.0.1.35 1675fa4fcb61d014eb1babe7eed703e7f76a1008537ee57ca7cec65cd9ff94ac Non-DLL mods added (:FOR[xxx]): Mods by directory (sub directories of GameData): CommunityTechTree JDTechTree Squad Mods added by assemblies: [LOG 12:54:00.801] Loading Physics.cfg [LOG 12:54:00.804] Extracting patches [LOG 12:54:00.896] Applying patches [LOG 12:54:00.898] :INSERT (initial) pass [LOG 12:54:00.976] :FIRST pass [LOG 12:54:00.976] :LEGACY (default) pass [LOG 12:54:00.978] Applying update CommunityTechTree/Tree/CommunityTechTree/@TechTree to Squad/Resources/TechTree.cfg/TechTree [LOG 12:54:01.023] Applying update JDTechTree/Tree/JDTechTree/@TechTree to Squad/Resources/TechTree.cfg/TechTree [LOG 12:54:01.089] Applying update JDTechTree/Tree/JDTechTree/@PART[mk1pod|mk2LanderCabin]:NEEDS[CommunityTechTree] to Squad/Parts/Command/mk1pod/mk1Pod.cfg/PART[mk1pod] [LOG 12:54:01.090] Applying update JDTechTree/Tree/JDTechTree/@PART[mk1pod|mk2LanderCabin]:NEEDS[CommunityTechTree] to Squad/Parts/Command/mk2LanderCan/mk2LanderCan.cfg/PART[mk2LanderCabin] [LOG 12:54:01.090] Applying update JDTechTree/Tree/JDTechTree/@PART[probeCoreSphere]:NEEDS[CommunityTechTree] to Squad/Parts/Command/probeStackSphere/probeStackSphere.cfg/PART[probeCoreSphere] [LOG 12:54:01.094] Applying update JDTechTree/Tree/JDTechTree/@PART[longAntenna]:NEEDS[CommunityTechTree] to Squad/Parts/Utility/commsDish16/commsAntenna16.cfg/PART[longAntenna] [LOG 12:54:01.096] :BEFORE[ASSEMBLY-CSHARP] pass [LOG 12:54:01.096] :FOR[ASSEMBLY-CSHARP] pass [LOG 12:54:01.096] :AFTER[ASSEMBLY-CSHARP] pass [LOG 12:54:01.096] :BEFORE[COMMUNITYTECHTREE] pass [LOG 12:54:01.096] :FOR[COMMUNITYTECHTREE] pass [LOG 12:54:01.096] :AFTER[COMMUNITYTECHTREE] pass [LOG 12:54:01.096] :BEFORE[JDTECHTREE] pass [LOG 12:54:01.096] :FOR[JDTECHTREE] pass [LOG 12:54:01.096] :AFTER[JDTECHTREE] pass [LOG 12:54:01.096] :BEFORE[KSPSTEAMCTRLR] pass [LOG 12:54:01.096] :FOR[KSPSTEAMCTRLR] pass [LOG 12:54:01.096] :AFTER[KSPSTEAMCTRLR] pass [LOG 12:54:01.096] :BEFORE[MODULEMANAGER] pass [LOG 12:54:01.096] :FOR[MODULEMANAGER] pass [LOG 12:54:01.096] :AFTER[MODULEMANAGER] pass [LOG 12:54:01.096] :BEFORE[SQUAD] pass [LOG 12:54:01.096] :FOR[SQUAD] pass [LOG 12:54:01.096] :AFTER[SQUAD] pass [LOG 12:54:01.097] :FINAL pass [LOG 12:54:01.097] Done patching [LOG 12:54:01.098] Saving Cache [LOG 12:54:01.192] Saving cache [LOG 12:54:01.434] ModuleManager: 6 patches applied [LOG 12:54:01.434] Ran in 1.042s [LOG 12:54:01.470] Done! EDIT: Oh wait, am I trying to modify the wrong command pod? I have vague recollection about one of the mk1 command pods being deprecated or something? EDIT 2: That did it. I just needed to modify the V2 versions of each part. >.< Edited August 4, 2020 by JDCollie Quote Link to comment Share on other sites More sharing options...
DStaal Posted August 4, 2020 Share Posted August 4, 2020 1 hour ago, JDCollie said: Oh wait, am I trying to modify the wrong command pod? I have vague recollection about one of the mk1 command pods being deprecated or something? EDIT 2: That did it. I just needed to modify the V2 versions of each part. >.< Yep, modifying the right part helps. Glad it was so simple. Quote Link to comment Share on other sites More sharing options...
etmoonshade Posted August 5, 2020 Share Posted August 5, 2020 So I'm realizing that I need massive physics-breaking numbers of engines for a particular craft I'm working on - I want to make a couple of upscaled engines instead (not using TweakScale for Reasons(tm) in this case - that'd obviously be a WAY easier way of dealing with this otherwise.) Would the following work as I expect it to? +PART[RandomOriginalEngineFromAnotherMod] { @name = RandomOriginalEngineFromAnotherModButBigger @MODULE[ModuleEnginesFX] { @maxThrust *= 2 } } +PART[RandomOriginalEngineFromAnotherMod] { @name = RandomOriginalEngineFromAnotherModButBiggerest @MODULE[ModuleEnginesFX] { @maxThrust *= 8 } } (what I'd expect is two parts with different names, and 2x or 8x engine thrust) I'm obviously oversimplifying here - I'm mostly wondering if the + operator actually copies everything from whatever part is put in brackets, and it's not quite clear from the example provided on GitHub. I'm confident that I can work out the rest of the issues. Quote Link to comment Share on other sites More sharing options...
Corax Posted August 6, 2020 Share Posted August 6, 2020 (edited) mostly wondering There is one sure fire way to stop wondering: KSP/GameData/ModuleManager.ConfigCache has all the patches applied from the last successful game start. You should be able to find your answer if you search that file for RandomOriginalEngineFromAnotherModButBigger.I'm obviously oversimplifying here So am I, but I'm certain you get the drift. Edited August 6, 2020 by Corax _successful_ start... Quote Link to comment Share on other sites More sharing options...
etmoonshade Posted August 6, 2020 Share Posted August 6, 2020 (edited) 14 hours ago, Corax said: There is one sure fire way to stop wondering: KSP/GameData/ModuleManager.ConfigCache has all the patches applied from the last successful game start. You should be able to find your answer if you search that file for RandomOriginalEngineFromAnotherModButBigger. So am I, but I'm certain you get the drift. Huh, I never actually thought of that. For what it's worth, the point behind posting that was to avoid having to restart KSP to test it out. It takes excessively long for me to restart. :V Of course a few minutes after I posted that, KSP crashed so I just went ahead and tried it anyway. It does appear to copy everything, although I know that because I actually have a working part rather than because I specifically checked the MM cache. I was actually putting together an edit to my previous post, but I got distracted by a shiny* and must've clicked away from that page by accident. * new wifi router - I now have gigabit everywhere in my network again! Edit: also, apparently I knew this 3 years ago when I made my custom parachute config - I successfully used the copy function there. Derp. Edited August 6, 2020 by etmoonshade Quote Link to comment Share on other sites More sharing options...
TranceaddicT Posted August 6, 2020 Share Posted August 6, 2020 14 hours ago, etmoonshade said: Edit: also, apparently I knew this 3 years ago when I made my custom parachute config - I successfully used the copy function there. Derp. There is a phrase for that: getting old. Quote Link to comment Share on other sites More sharing options...
etmoonshade Posted August 6, 2020 Share Posted August 6, 2020 12 minutes ago, TranceaddicT said: There is a phrase for that: getting old. My general statement stands - this should be explicitly mentioned in the Wiki, for when other people have "old" moments. I'll see if I can do something tonight, assuming I can even edit the wiki - apparently I haven't logged into github on this machine before, so it wants me to 2FA with my e-mail account... which I can't get to right now since I'm actually AT work today. I imagine someone more familiar with MM would be able to word it better than I would anyway. Hint hint @TranceaddicT (I will totally hack something together if I have the access - just later tonight) Quote Link to comment Share on other sites More sharing options...
TranceaddicT Posted August 6, 2020 Share Posted August 6, 2020 1 hour ago, etmoonshade said: Hint hint @TranceaddicT Hint taken. In observation of KISS ... This copies the entirety of the PART{} node. (Also, in complete disregard of KISS, I did some rearranging for clarity, added code-wrappers, and performed a grammar sweep (yes, I'm a grammar-pedant (so much so I had to copy commas from above because my comma-key is now dead.)) Quote Link to comment Share on other sites More sharing options...
etmoonshade Posted August 6, 2020 Share Posted August 6, 2020 4 minutes ago, TranceaddicT said: Hint taken. In observation of KISS ... This copies the entirety of the PART{} node. (Also, in complete disregard of KISS, I did some rearranging for clarity, added code-wrappers, and performed a grammar sweep (yes, I'm a grammar-pedant (so much so I had to copy commas from above because my comma-key is now dead.)) Clarity and being explicit about "obvious" things is always valuable. At a quick scan, looks good - thanks! I literally just had a situation at work where an "obvious" step was missed in some instructions, and it would have caused a problem if I hadn't been careful and done backups first. (now I'm just waiting for stuff to build...) Quote Link to comment Share on other sites More sharing options...
etmoonshade Posted August 6, 2020 Share Posted August 6, 2020 (edited) @TranceaddicT - I've finally managed to get home and sit down to give the wiki section a good reading. I've submitted an edit for the Copy operation that I think would have been useful to me in yesterday's mental state - fleshing out the example a bit and tweaking the wording to make it entirely clear that "HEY THIS IS THE EASY WAY TO MAKE A NEW PART FROM AN OLD ONE." Very definitely NOT adhering to KISS. Edited August 6, 2020 by etmoonshade Quote Link to comment Share on other sites More sharing options...
TranceaddicT Posted August 7, 2020 Share Posted August 7, 2020 4 hours ago, etmoonshade said: @TranceaddicT - I've finally managed to get home and sit down to give the wiki section a good reading. I've submitted an edit for the Copy operation that I think would have been useful to me in yesterday's mental state - fleshing out the example a bit and tweaking the wording to make it entirely clear that "HEY THIS IS THE EASY WAY TO MAKE A NEW PART FROM AN OLD ONE." Very definitely NOT adhering to KISS. It looks good. It provides desirable info with out going over-board. Quote Link to comment Share on other sites More sharing options...
Padrone Posted August 16, 2020 Share Posted August 16, 2020 I've been trying for a while to do this, but I am missing something basic. I'm trying to remove all the default textures from Procedural Parts so that I can use my own .CFG to rename/reorder them, adding a few texture packs I've pulled together. (I.E. when I get done, all the texture names will be in a standardized format and will be in alphabetic order). This is the first part of the .CFG file from Procedural Parts, where the textures are defined. STRETCHYTANKTEXTURES { name = Default Original { //by Ancient Gammoner sides { // Snipped lines for brevity } ends { texture = ProceduralParts/Parts/ends } } // Many repeats of the above section for the different textures follow Since these aren't a part or a module, I'm flummoxed at how to get to these entries with my own .CFG file. Can someone set me on the trail for the syntax for removing all these texture entries? TIA! Quote Link to comment Share on other sites More sharing options...
blowfish Posted August 17, 2020 Share Posted August 17, 2020 20 hours ago, Padrone said: Since these aren't a part or a module, I'm flummoxed at how to get to these entries with my own .CFG file. Can someone set me on the trail for the syntax for removing all these texture entries? TIA! So, I think you're making a common mistake in how you're thinking about this. ModuleManager doesn't care about PARTs, or MODULEs, or anything else, all it sees is data. If you have WHATEVERNODE, you can patch it with @WHATEVERNODE (or delete with ! etc etc). If that WHATEVERNODE has name = blah, you can target it with @WHATEVERNODE[blah]. To check sub-nodes/values, use :HAS. Does that make sense? Quote Link to comment Share on other sites More sharing options...
Jognt Posted August 22, 2020 Share Posted August 22, 2020 Discussion about LAST versus FINAL for use in Kopernicus: GO! As far as I know LAST exists to ensure patching compatible with BEFORE, FOR, and AFTER passes without having to resort to FINAL. This in order to prevent another 'race to FINAL' occuring. Quote Link to comment Share on other sites More sharing options...
R-T-B Posted August 22, 2020 Share Posted August 22, 2020 (edited) Quote LAST probably didn’t exist when FINAL was chosen. It was chosen in last release for 1.8. https://github.com/Kopernicus/Kopernicus/commit/c0b092e35eda0c83d3081ed5131c4c0503c3b4a9 Anyways, if this is a big deal I am not opposed to changing next release. The first CKAN already shipped this way though and that's unlikely to change because I don't have a time machine, heh. I was really just defering to "past authors wisdom" (or maybe lack thereof?) here. However, at the moment, I feel I am swayed by this argument: 5 hours ago, Lisias said: On a rule of thumb, don't use :LAST[Kopernicus]. It will not work for you, you need to replace every single Solar Panel on the game by Kopernicus ones, and not only the ones from AddOns those name is less than "Ko". (MM applies patches on alphabetical order on each phase). And you really need to replace every single Solar Panel on the game to use Kopernicus, because since you are extending the stock Solar Panels class, the ModuleDeployableSolarPanel will be ignored on all parts and any part not patched will simply not work anymore (and Kopernicus will end up taking the heat, because by uninstalling it that parts will work again). If in doubt, stick with :FINAL . it's safer for now. Change my view, I suppose. Edited August 22, 2020 by R-T-B Quote Link to comment Share on other sites More sharing options...
Jognt Posted August 22, 2020 Share Posted August 22, 2020 1 hour ago, R-T-B said: It was chosen in last release for 1.8. https://github.com/Kopernicus/Kopernicus/commit/c0b092e35eda0c83d3081ed5131c4c0503c3b4a9 Anyways, if this is a big deal I am not opposed to changing next release. The first CKAN already shipped this way though and that's unlikely to change because I don't have a time machine, heh. I was really just defering to "past authors wisdom" (or maybe lack thereof?) here. However, at the moment, I feel I am swayed by this argument: Change my view, I suppose. Use whichever you wish. I would however like to point out that LAST happens once FOR and AFTER are alphabetically 100% done. Lisias’ concern could be valid if this was not the case, but even then: FINAL is also processed alphabetically. Both will work. Having said that, I’d prefer following best practices. In this case: ‘use the first pass that produces the desired result’ and ‘try and avoid FINAL.’ In this case LAST would still cover every part/module that is altered in legacy/first/before/for/after passes. To see the order of patching passes: Check your local MM log. Quote Link to comment Share on other sites More sharing options...
Lisias Posted August 23, 2020 Share Posted August 23, 2020 11 hours ago, Jognt said: Use whichever you wish Nope. He should use whatever works correctly for him. That's the whole point. 11 hours ago, Jognt said: Both will work. No. Using LAST will cause problems on complex installations where the "race for the :LAST" already begun. What you are missing is that Kopernicus Solar Panels does not need to be the last thing applied for Kopernicus. It must be the last thing applied to ModuleDeployableSolarPanel on the whole the GameData. Anything that failed to be patched will be ruled out on loading as any "legacy" ModuleDeployableSolarPanel sections on the configs will be ignored, and so default values from the Module will be injected into living savegames on loading. And this is what will really cause damage - whatever is on the prefab is being injected on living savegames on load. And so we must be pretty sure about what's on the prefab before allowing the user to load his/her savegames. 12 hours ago, Jognt said: FINAL is also processed alphabetically. But after :LAST, being that the whole point. What @R-T-B needs is something allowing him to be the last one applying patches for ModuleDeployableSolarPanel, not for Kopernicus. :LASTFOR[ModuleDeployableSolarPanel] and not :LAST[Kopernicus]. There's more than one Add'On extending the class ModuleDeployableSolarPanel by the way (do a search on github and see) - and all of them will be killed by or will kill Kopernicus. Would not be wonderful if MM could flag multiple "LASTFORs" as a problem and so we could avoid installing more than one and breaking everything on load before the user could detect something wrong? But this semantics doesn't exists on MM, so using :FINAL is the next logical (and safe) choice. Your argument about a "RACE to the :FINAL" is valid, and that's the reason everybody should avoid using it except when absolutely necessary: it's necessary for Kopernicus, because otherwise it will be a victim of the current "race for the :LAST". Alternatively, a gentlemen agreement on simulating a "add'on :FINAL" using :LAST[zzz], where zzz would be guaranteed to exist and only used when absolutely necessary would also do the trick for Kopernicus. But... If such gentlemen agreement was easily achievable, we would not have problems with :FINAL neither. Quote Link to comment Share on other sites More sharing options...
Jognt Posted August 23, 2020 Share Posted August 23, 2020 (edited) @Lisias I understand the whole "Others are already/still ignoring the best practices, so we cannot be sure we beat even them unless we also ignore the best practice." intention. However: As long as all mods are treated equal there will be no way to 100% guarantee any one mod will always be last in any pass (though LAST and FINAL are both well after FOR/AFTER). So while one achieves less annoyed users at his/her doorstep by joining the racers, the race also continues, causing more annoyed users at others' doorsteps. I can understand where you're coming from, I just don't agree with it. Good luck with what is undoubtedly little work to leave as is, and quite a bit of work to find an ideal fix for. o7 My idealistic €0,02. Edited August 23, 2020 by Jognt 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.