Jump to content

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


sarbian

Recommended Posts

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 by Monniasza
mods
Link to comment
Share on other sites

@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 by TranceaddicT
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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 by JDCollie
Link to comment
Share on other sites

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.  :D  Glad it was so simple.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by Corax
_successful_ start...
Link to comment
Share on other sites

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 by etmoonshade
Link to comment
Share on other sites

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

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)

Link to comment
Share on other sites

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.:/))

Link to comment
Share on other sites

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

(now I'm just waiting for stuff to build...)

Link to comment
Share on other sites

@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. :D

Edited by etmoonshade
Link to comment
Share on other sites

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

It looks good.

It provides desirable info with out going over-board.

Link to comment
Share on other sites

  • 2 weeks later...

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!

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by R-T-B
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

@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 by Jognt
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...