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

[SFJackBauer]

Ah bummer. That's ok though, back to plan A.

[prioronion]

could anyone recommend me some code that would do the same as this, all parts without a tech allocation to be set to composites

@PART[*]:HAS[~TechRequired[]]:Final

{

TechRequired=composites

}

as this doesn't work

[prioronion]

also just to be clear

the dll in gamedata

the config in any directory in gamedata

[sarbian]

Mine looks like your and works fine

@PART[*]:HAS[~TechRequired[]]:Final
{
	TechRequired=advScienceTech
}

[prioronion]

did you use version of mm 1.5.5?

[prioronion]

also does your file say the type is a .cfg because mine won't change to one so just to be sure there's a original file i had and i had to get a config file from smoewhere else

[sarbian]

Yes, and yes

[prioronion]

thx ill try it now

[therealcrow999]

I am liking the new features in 1.5

[SFJackBauer]

It seems the % (create-or-change) operator is not working on nodes?

My code is:

@PART[foo]
{
    %MODULE[ModuleGimbal]
    {
        %gimbalTransformName  = thrustTransform
        %gimbalRange = 0.5
    }
}

But the engine still shows up having no vectoring range in VAB. It works if I add it directly to the part cfg.

[ialdabaoth]

Suggestion on syntax:

When modifying, @NODE[blah] {...} affects a node, while !NODE[blah] removes a node; likewise, @PROPERTY=... affects a property, while !PROPERTY removes a property.

For consistency's sake, when searching, :HAS[@NODE[blah]] should match on having a node, while :HAS[!NODE[blah]] should match on not having a node. Likewise, :HAS[@PROPERTY] should match on having a property, while :HAS[!PROPERTY] should match on not having that property (note the lack of [] if it's a property).

So this:

@PART[*]:HAS[~TechRequired[]]:Final

should really look like this:

@PART[*]:HAS[!TechRequired]:Final

if we want a tight, consistent language.

That said, it's of course your baby right now - but I'd strongly advise considering my recommendation; I know a thing or two about language and script design.

One thing you need to be very mindful of, is that eventually Squad will catch up with you - and on that day, you want them to be able to implement their own version of your parser from scratch, without your help, so that mod authors everywhere won't have to redo everything in their cfg files. Every change you make to ModuleManager's CFG syntax is a change that needs to make absolute intuitive sense, AND be easy to write a parser for, or you open the temptation for Squad to just do their own thing and throw your design out the window.

Edited December 7, 2013 by ialdabaoth

[sarbian]

Fair points. I have no idea to why I used ~

You are right that as I add new feature the need for a true parser is rising. It just seems going overboard for such a simple addon. If you have an advice on a tool/method I should use I would welcome it.

I would be glad if squad catched up, since right now some feature are impossible with the public API.

[Starwaster]

Fair points. I have no idea to why I used ~

You are right that as I add new feature the need for a true parser is rising. It just seems going overboard for such a simple addon. If you have an advice on a tool/method I should use I would welcome it.

I would be glad if squad catched up, since right now some feature are impossible with the public API.

I assume you used ~ because that's how I did it when I submitted my code fragment and I did it that way because it was a quick way for me to work around the bracket issue with properties while staying within the confines of how the parser worked at the time. (back when it was 1.3 + Sarbian's MM Extensions)

Consistifying the syntax is definitely a good thing. (yeah I know, that's not really a word...)

[jrandom]

I'm trying to alter the energy usage of the command and I can't seem to get it to work. The following appears to have no effect:

@PART[*]:HAS[@MODULE[ModuleCommand],#CrewCapacity[3]]:Final
{
    @MODULE[ModuleCommand]
    {
        @RESOURCE[ElectricCharge]
        {
            @rate = 1 // 0.5 for coms, 0.1666666 for operation per kerbal
        }
    }
}

[NathanKell]

Because there is no RESOURCE block to change. They exist only for the unmanned pods where command modules cost EC; manned pods' command modules don't.

% was created for just this reason (create-or-change) but above SFJackBauer mentions issues with creating subnodes.

[jrandom]

Because there is no RESOURCE block to change. They exist only for the unmanned pods where command modules cost EC; manned pods' command modules don't.

% was created for just this reason (create-or-change) but above SFJackBauer mentions issues with creating subnodes.

Huh. Okay. So where does a manned pod's default electrical usage come from? I need to change it!

[NathanKell]

There isn't any, stock.

Instead do:

@PART[*]:HAS[@MODULE[ModuleCommand],#CrewCapacity[3]]:Final
{
    @MODULE[ModuleCommand]
    {
        RESOURCE
        {
            name = ElectricCharge
            rate = 1 // 0.5 for avionics, 0.1666666 for operation per kerbal
        }
    }
}

(Also I changed it to avionics, since the command module is avionics, and RT2 antenna module would represent comms. Plus, where's the extra 1kW coming from? It should be ~2EC/sec usage for a 3-person pod, IMO.)

[jrandom]

(Also I changed it to avionics, since the command module is avionics, and RT2 antenna module would represent comms. Plus, where's the extra 1kW coming from? It should be ~2EC/sec usage for a 3-person pod, IMO.)

I'm trying to make the other 1kW come from IonCross but at present I've not been able to successfully get its power consumption to change. I think it might be because I'm adding IonCross support to all pods in another .cfg file and this other one might be loading first. I'll try and combine them and see if that works.

[sarbian]

I missed the % post. I'll try to fix the current bug before .23 so we can have a stable release.

[jrandom]

Is there a way to prioritize :Final blocks? I have a patch I want to apply but it's being overridden by RealismOverhaul. I thought I saw somewhere there was a way to do this, but I've digging through forum posts to no avail.

[jrandom]

Another question. The following block should, as far as I can tell, only apply to parts that do not have a LifeSupportModule module, and that do have a crew capacity of 1:

@PART[*]:HAS[!MODULE[LifeSupportModule], #CrewCapacity[1]]:Final
{
    MODULE
	{
		name = LifeSupportModule
	}
}

However, this gets applied to every part. What did I miss?

[sarbian]

Remove the space after the coma

RealismOverhaul hsuld not use :Fianl, but they may have the need to. If you want a patch to be applied last you should try to put it in a directory named zzz_something

Edited December 11, 2013 by sarbian

[jrandom]

Remove the space after the coma

Whoa, really? Does nobody trim their tokens anymore?...

... I'm a grumpy old coder, stop laughing at me.

RealismOverhaul hsuld not use :Fianl, but they may have the need to. If you want a patch to be applied last you should try to put it in a directory named zzz_something

I'll give it a shot. Thank you!

[NathanKell]

Final is used since RO modifies heatshields of pods that already have heatshields added via DeadlyReentry.

[Starwaster]

Whoa, really? Does nobody trim their tokens anymore?...

... I'm a grumpy old coder, stop laughing at me.

I'll give it a shot. Thank you!

He does trim them, but for some reason it doesn't stop the spaces from breaking things....