Jump to content

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


sarbian

Recommended Posts

It actually works with the spaces.

Will remove them anyway. :)

It may have at one point because of code to try to bypass the white space problem but its bad practice to use spaces for reasons discussed previously, does not work now and you want to get out of the habit :)

Link to comment
Share on other sites

Starwaster: see above.

Unless node parsing was totally rewritten, when you delete a node KSP needs to parse it as a node, not a value.

I'm talking about !NODE{} vs !NODE {} btw.

Not !NODE[blah] {} vs !NODE[blah ] {} (there, the whitespace in the nodename is bad, yes.)

Link to comment
Share on other sites

Just NEVER complain to any mod dev after you removed PhysicsSignificance from your parts. It's not here just to annoy you.

OrbitalDebris

One hint : five [ and six ]

I should add a test that count braces and spit error messages ^^

swamp_ig :

fell free do contribute. It's how mods evolve faster :)

D'oh! It's always the last thing one thinks of. Thanks! :)

Link to comment
Share on other sites

So, :NEEDS[...] gets applied to a :BEFORE or :AFTER in the same way that :HAS gets applied to the part name filter.

i.e., it's not just

@PART[...]:NEEDS[OtherMod]

it's actually

@PART[...]:BEFORE[OtherMod]:NEEDS[AnotherMod, !YetAnotherMod]

which says "Apply this node before the :FOR[OtherMod] pass, but ONLY if AnotherMod is also installed AND YetAnotherMod ISN'T installed."

Just doing @PART[...]:NEEDS[OtherMod] is identical to doing @PART[...]:FIRST:NEEDS[OtherMod] in the same way that @PART[...] is identical to @PART[...]:FIRST; if you want it to happen in the FINAL pass, do @PART[...]:FINAL:NEEDS[OtherMod]

So, in your example, rather than:

@PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[MechJebCore]]]:NEEDS[MechJeb2]:FINAL

You need to do:

@PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[MechJebCore]]]:FINAL:NEEDS[MechJeb2]

You can't do :NEEDS[MechJeb2]:FINAL or :NEEDS[MechJeb2]:BEFORE[blah] any more than you could do @HAS[@MODULE[ModuleCommand],!MODULE[MechJebCore]]]:PART[*]

The order MUST be:

*NODE:HAS[FilterOptions]:PASS:NEEDS[NeedOptions]

Where:

- '*' can be one of '@', '!', '%'

- NODE can be PART, RESOURCE_DEFINITION, or any other root-level node, and can optionally include [nodeNameFilter] and/or ,index

- HAS[FilterOptions] is optional

- PASS can be FIRST, BEFORE[modname], FOR[modname], AFTER[modname], or FINAL. BEFORE[modname] and AFTER[modname] only get called if the FOR[modname] pass will be called. If PASS is not specified, it defaults to FIRST.

- NEEDS[NeedOptions] is optional.

Does that make sense?

Yes, your example of "Apply this node before the :FOR[OtherMod] pass, but ONLY if AnotherMod is also installed AND YetAnotherMod ISN'T installed" made it all clear. My mental model of how the patching takes place was backwards. Thanks!

Link to comment
Share on other sites

Is there any way to have a module manager file recognise if a tech node has been researched?

With the new maths functions that would open up some AMAZING part improvement opportunities.

Things like reduced weight of parts at later tech levels or improved ISP and thrust.

Link to comment
Share on other sites

Is there any way to have a module manager file recognise if a tech node has been researched?

With the new maths functions that would open up some AMAZING part improvement opportunities.

Things like reduced weight of parts at later tech levels or improved ISP and thrust.

Something like this ?

MODULE

{

name = MechJebCore

MechJebLocalSettings {

MechJebModuleCustomWindowEditor { unlockTechs = flightControl }

MechJebModuleSmartASS { unlockTechs = flightControl }

MechJebModuleManeuverPlanner { unlockTechs = advFlightControl }

MechJebModuleNodeEditor { unlockTechs = advFlightControl }

MechJebModuleTranslatron { unlockTechs = advFlightControl }

MechJebModuleWarpHelper { unlockTechs = advFlightControl }

MechJebModuleAttitudeAdjustment { unlockTechs = advFlightControl }

MechJebModuleThrustWindow { unlockTechs = advFlightControl }

MechJebModuleRCSBalancerWindow { unlockTechs = advFlightControl }

MechJebModuleRoverWindow { unlockTechs = fieldScience }

MechJebModuleAscentGuidance { unlockTechs = unmannedTech }

MechJebModuleLandingGuidance { unlockTechs = unmannedTech }

MechJebModuleSpaceplaneGuidance { unlockTechs = unmannedTech }

MechJebModuleDockingGuidance { unlockTechs = advUnmanned }

MechJebModuleRendezvousAutopilotWindow { unlockTechs = advUnmanned }

MechJebModuleRendezvousGuidance { unlockTechs = advUnmanned }

}

}

Link to comment
Share on other sites

All of MM work is done in the first second of KSP start. It does not runs when you load a game, so no you can't have that.

It more something for a partmodule that you would add to all parts.

MeCripp : the way MJ unlock its function is totaly unrelated to MM.

Link to comment
Share on other sites

If I try and download Module Manager it says " This file does not have a program associated with it for performing this action." I'm not sure what this means, do I need a certain program to download this. Please help.

Link to comment
Share on other sites

Err, i want to reduce the amount of fuel of my tank via MM, so i have:


@PART[NP_lft_500m_15m]

{
@RESOURCE[LiquidFuel]
{
@amount -= 7000
@maxAmount -= 7000
}


@RESOURCE[Oxidizer]
{
@amount -= 7000
@maxAmount -= 7000
}
}

and after reload db, i check the info of "MM moded" part, the fuel amount is unchanged...

so i go to ksp_log, and find:


[LOG 12:46:45.733] [ModuleManager] Applying node 1_MyPatch/NP_lft_500m_15m/@PART[NP_lft_500m_15m] to 1_MyParts/NP_LFT_5_0mx15_0m/part/NP_lft_500m_15m
[LOG 12:46:45.735] [ModuleManager] modding values
[LOG 12:46:45.736] [ModuleManager] modding values
[COLOR="#FF8C00"] @amount -= 7000: 27648 -> -20648
@maxAmount -= 7000: 27648 -> -20648[/COLOR]
[LOG 12:46:45.738] Applying subnode @RESOURCE[LiquidFuel]

[LOG 12:46:45.739] [ModuleManager] modding values
[COLOR="#FFA07A"] @amount -= 7000: 33792 -> -26792
@maxAmount -= 7000: 33792 -> -26792[/COLOR]
[LOG 12:46:45.740] Applying subnode @RESOURCE[Oxidizer]

Is my syntax not correct or could this be possible bug?? :D

Link to comment
Share on other sites

Err, i want to reduce the amount of fuel of my tank via MM, so i have:


@PART[NP_lft_500m_15m]

{
@RESOURCE[LiquidFuel]
{
@amount -= 7000
@maxAmount -= 7000
}


@RESOURCE[Oxidizer]
{
@amount -= 7000
@maxAmount -= 7000
}
}

and after reload db, i check the info of "MM moded" part, the fuel amount is unchanged...

so i go to ksp_log, and find:


[LOG 12:46:45.733] [ModuleManager] Applying node 1_MyPatch/NP_lft_500m_15m/@PART[NP_lft_500m_15m] to 1_MyParts/NP_LFT_5_0mx15_0m/part/NP_lft_500m_15m
[LOG 12:46:45.735] [ModuleManager] modding values
[LOG 12:46:45.736] [ModuleManager] modding values
[COLOR="#FF8C00"] @amount -= 7000: 27648 -> -20648
@maxAmount -= 7000: 27648 -> -20648[/COLOR]
[LOG 12:46:45.738] Applying subnode @RESOURCE[LiquidFuel]

[LOG 12:46:45.739] [ModuleManager] modding values
[COLOR="#FFA07A"] @amount -= 7000: 33792 -> -26792
@maxAmount -= 7000: 33792 -> -26792[/COLOR]
[LOG 12:46:45.740] Applying subnode @RESOURCE[Oxidizer]

Is my syntax not correct or could this be possible bug?? :D

I'm actually trying to completely remove some fuel from parts. How would you go about that?

Link to comment
Share on other sites

I'm actually trying to completely remove some fuel from parts. How would you go about that?

Depends on if you want to remove its resource capacity entirely or just empty it.

Remove the resources:

Replace <fueltank> with the part name of the fuel tank you want to remove resources from!


@PART[<fueltank>]
{
!RESOURCE[LiquidFuel]{}
!RESOURCE[Oxidizer]{}
}

or to just set them to zero.

Replace <fueltank> with the part name of the fuel tank you want to empty!


@RESOURCE[LiquidFuel]
{
@amount = 0
}
@RESOURCE[Oxidizer]
{
@amount = 0
}

If it uses another resource besides LiquidFuel or Oxidizer then you'd replace the resource name with that.

Link to comment
Share on other sites

Depends on if you want to remove its resource capacity entirely or just empty it.

Remove the resources:

Replace <fueltank> with the part name of the fuel tank you want to remove resources from!


@PART[<fueltank>]
{
!RESOURCE[LiquidFuel]{}
!RESOURCE[Oxidizer]{}
}

or to just set them to zero.

Replace <fueltank> with the part name of the fuel tank you want to empty!


@RESOURCE[LiquidFuel]
{
@amount = 0
}
@RESOURCE[Oxidizer]
{
@amount = 0
}

Much appreciated! :)

Link to comment
Share on other sites

Hi. I'm totally new to making overriding MM configs. Thought this could be a place to ask for help, since searching the forums hasn't helped yet.

Anyway, I started working on a rescale for FusTek that one day may become a proper RO/RSS config. This ofc includes resizing parts. I was asked to not use "rescaleFactor = X", but instead scale = x, y, z.

The problem is I can't get it to work with the multi model parts.

Here's an example where everything works except the actual resizing:


@PART[FusTekKuestAirlock]:Final
{
@MODEL,0
{
%scale = 1.76, 1.76, 1.76
}
@MODEL,1
{
%scale = 1.76, 1.76, 1.76
%position = 0.0, 1.925, 0.0 //was 1.09375
}
@MODEL,2
{
%scale = 1.76, 1.76, 1.76
%position = 0.0, -1.925, 0.0 //was -1.09375
}

// Top Hatch
@MODEL,3
{
%scale = 1.76, 1.76, 1.76
%position = 0.0, 1.76, 0.0
}
//Bottom Hatch
@MODEL,4
{
%scale = 1.76, 1.76, 1.76
%position = 0.0, -1.76, 0.0
}


@node_stack_bottom = 0.0, -1.76, 0.0, 0.0, -1.0, 0.0, 4
@node_stack_top = 0.0, 1.76, 0.0, 0.0, 1.0, 0.0, 4

@mass = 6.0 //6064kg from wikipedia, may change if including TAC
@maxTemp = 1300
@breakingForce = 1280
@breakingTorque = 1280


}

Does anybody know how to resize multi model parts like these? Why is this not working?

Thanks.

Edited by ThorBeorn
spelling: "multi model" not "multi module"
Link to comment
Share on other sites

@Thor: What version of the FusTek pack are you using? The one I have (latest dev release linked in the thread, which is the one I thought you were talking about over in the RO thread) has the part named "KuestAirlock" and not "FusTekKuestAirlock". Double check that you have the part name correct. As for the original config, here is the relevant portion of the original for reference:



MODEL
{
model = FusTek/Station Parts Expansion/Parts/model_KuestAirlock
scale = 1.0, 1.0, 1.0
}

MODEL
{
model = FusTek/Station Parts Expansion/Parts/model_KarmonyEndRing
position = 0.0, 1.09375, 0.0
scale = 1.0, 1.0, 1.0
}

MODEL
{
model = FusTek/Station Parts Expansion/Parts/model_KarmonyEndRing
position = 0.0, -1.09375, 0.0
rotation = 0.0, 0.0, 180
scale = 1.0, 1.0, 1.0
}

// Top (Forward) Hatch
MODEL
{
model = FusTek/Station Parts Expansion/Parts/model_KarmonyHatchEVA
position = 0.0, 1, 0.0
scale = 1.0, 1.0, 1.0
}

// Bottom (Aft) Hatch
MODEL
{
model = FusTek/Station Parts Expansion/Parts/model_KarmonyHatch
position = 0.0, -1, 0.0
rotation = 0.0, 0.0, 180
scale = 1.0, 1.0, 1.0
}

rescaleFactor = 1

node_stack_bottom = 0.0, -1, 0.0, 0.0, -1.0, 0.0, 2
node_stack_top = 0.0, 1, 0.0, 0.0, 1.0, 0.0, 2

Link to comment
Share on other sites

RaccoonTOF: Thanks for your reply. I'm using the latest "X0.04-3 DEV BUILD" which was released two days ago in the FusTek blog. Looking at the config you just posted it seems as you've missed the latest dev release. I see some differences in there compared to mine.

Sarbian: Here is the original cfg which I'm trying to edit:


PART {
name = FusTekKuestAirlock
module = Part
author = sumghai

MODEL
{
model = FusTek/Station Parts Expansion/Parts/modelKuestAirlock
scale = 1.0, 1.0, 1.0
}

MODEL
{
model = FusTek/Station Parts Expansion/Parts/modelKarmonyEndRing
position = 0.0, 1.09375, 0.0
scale = 1.0, 1.0, 1.0
}

MODEL
{
model = FusTek/Station Parts Expansion/Parts/modelKarmonyEndRing
position = 0.0, -1.09375, 0.0
rotation = 0.0, 0.0, 180
scale = 1.0, 1.0, 1.0
}

// Top (Forward) Hatch
MODEL
{
model = FusTek/Station Parts Expansion/Parts/modelKarmonyHatchEVA
position = 0.0, 1, 0.0
scale = 1.0, 1.0, 1.0
}

// Bottom (Aft) Hatch
MODEL
{
model = FusTek/Station Parts Expansion/Parts/modelKarmonyHatch
position = 0.0, -1, 0.0
rotation = 0.0, 0.0, 180
scale = 1.0, 1.0, 1.0
}

rescaleFactor = 1

node_stack_bottom = 0.0, -1, 0.0, 0.0, -1.0, 0.0, 2
node_stack_top = 0.0, 1, 0.0, 0.0, 1.0, 0.0, 2

TechRequired = composites
entryCost = 12500
cost = 2500
category = Utility
subcategory = 0
title = Kuest Airlock
manufacturer = Sum Dum Heavy Industries Co., Ltd (under licence from FusTek Aerospace)

vesselType = Station

description = As an independent airlock module that can be added to any compatible docking port, the Kuest features a separate lockout chamber with a patent-pending system capable of cleaning and decontaminating Kerbals returning from spacewalks or planetary excursions. EVA suits and single-use filter cartridges sold separately.

attachRules = 1,0,1,1,0

mass = 3.25
dragModelType = default
maximum_drag = 0.25
minimum_drag = 0.25
angularDrag = 0.5
crashTolerance = 10
maxTemp = 2900
breakingForce = 280
breakingTorque = 280

CrewCapacity = 1

INTERNAL
{
name = GenericSpace1
}

RESOURCE
{
name = ElectricCharge
amount = 50
maxAmount = 50
}
}

And as I wrote earlier, all changes regarding mass, maxtemp, node_stack positions etc, do occur. It's just the rescale and the reposition which is not happening.

Thanks!

Edited by ThorBeorn
Link to comment
Share on other sites

Yup, looks like I missed it indeed (odd, I didn't get a notification like I usually do either) The config I posted was from X0.04-2 rather than -3. I'm still just as baffled by why the @MODEL,x{} syntax isn't working too though. Assuming you actually have the 2.03 MM installed, and no other versions of the MM DLL anywhere? (1.5.6 and 1.5.7 seem to coexist alright with each other in most cases, but any of the 2.x versions seem to be back to the old system of only one allowed, period, anywhere in gamedata)

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