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

[Pirsig]

Hey, so I'm having some trouble with the author value in :HAS. I have the following MM config:

//Moves the .75m Life Support HexCans to Precision Engineering
@PART[HexCan*Small]:HAS[#author[Greys, Taranis Elsu]]:FOR[KSAEA]:NEEDS[TacLifeSupport]
{
	@TechRequired = precisionEngineering
}

//Moves the 1.5m Life Support HexCans to Specialized Construction
@PART[HexCan*]:HAS[~name[HexCan*Large],~name[HexCan*Small],#author[Greys, Taranis Elsu]]:FOR[KSAEA]:NEEDS[TacLifeSupport]
{
	@TechRequired = specializedConstruction
}

//Moves the 3m Life Support HexCans to Meta-Materials
@PART[HexCan*Large]:HAS[#author[Greys, Taranis Elsu]]:FOR[KSAEA]:NEEDS[TacLifeSupport]
{
	@TechRequired = metaMaterials
}

Trying to target parts that all have configs like the following, only with the resource name changing:

PART
{
    MODEL
    {
        model = ThunderAerospace/TacLifeSupportHexCans/Models/HexCan
        position = 0.0, 0.0, 0.0
        scale    = 1.0, 1.0, 1.0
        rotation = 0.0, 0.0, 0.0
        texture = HexCan000, ThunderAerospace/TacLifeSupportHexCans/HexCanBreathingOxygen/Texture
    }
    // --- general parameters ---
    name = HexCanOxygen
    module = Part
    author = Greys, Taranis Elsu

    // --- asset parameters ---
    scale = 1
    rescaleFactor = 1
    specPower = 0.3
    rimFalloff = 3
    alphaCutoff = 0

    // --- general parameters ---
    node_attach =       0.0, 0.0, -0.2,   0.0, 0.0, 1.0, 2
    node_stack_top_01=  0.0, 0.0,  0.166, 0.0, 1.0, 0.0, 1
    node_stack_top =    0.0, 0.75, 0.0,   0.0, 1.0, 0.0, 1
    node_stack_bottom = 0.0,-0.75, 0.0,   0.0,-1.0, 0.0, 1

    attachRules = 1,1,1,1,1

    // --- editor parameters ---
	TechRequired = survivability
	entryCost = 2800
    cost = 176.7
    category = Utility
    subcategory = 0
    title = HexCan-Oxygen
    manufacturer = PanSpace Manufacturing Inc. Ltd. LLC. Co. in cooperation with Thunder Aerospace Corporation
    //              small= 0.75m, normal= 1.5m large= 3m
    description = A 1.5m long resource canister containing Oxygen supplies.

    // --- general parameters ---
    mass = 0.12
    dragModelType = default
    maximum_drag = 0.2
    minimum_drag = 0.3
    angularDrag = 2
    crashTolerance = 12
    breakingForce = 400
    breakingTorque = 400
    maxTemp = 2900

    // --- resource parameters ---
    // 2x the container size = 8x the volume
    RESOURCE
    {
        name = Oxygen
        amount = 28747.5
        maxAmount = 28747.5
    }
}

The changes all worked fine without the :HAS[...#author[...]] but when I tried to add that part to assure that it wouldn't change any other HexCan parts using the same naming scheme, the patches no longer target any of the parts and are not applied. I have tried as #author[*Taranis Elsu], #author[G*Taranis] as well as finally just being explicit thinking there was an issue with using wildcards, none of which seemed to work. Have I missed something here or is this a bug?

EDIT: Completely forgot to mention this is with 2.4.5 of MM

Edited October 7, 2014 by Pirsig
forgot to add version

[sarbian]

Pirsig : looks like a bug, but I would not recommand selecting part by author name for a patch anyway. You can use more than 1 part name in the search, use that.

MM 2.5.0 is now available for KSP 0.25. See the first post

Edited October 7, 2014 by sarbian

[Thourion]

Thanks Sarbian!

[Pirsig]

Pirsig : looks like a bug, but I would not recomand selecting part by author name for a patch anyway. You can use more than 1 part name in the search, use that.

I'm aware I can do that and for now it is that way, but the way above is cleaner than 5 or 6 parts explicitly stated in my opinion. What is the reasoning not to use author if it was working correctly?

[John FX]

Since "hidden" parts must still load textures etc. to keep old ships from breaking they are still using memory. what I am looking for is if MM can somehow interrupt the loading of these hidden parts and get them to just not load at all. something that checks for the hidden flag and then maybe deletes all lines from the .cfg. or maybe just the "PART" line... I do not know what or how it would work, so hoping someone here may have an idea.

You might want to have a look at this...

http://forum.kerbalspaceprogram.com/threads/73236-WIP-Loading-textures-only-as-required

It replaces every texture in the game with a tiny low res placeholder and loads them up on demand (and replaces them with the tiny placeholder if they are not in the current scene)

EDIT : Appears not to work yet in 0.25

Edited October 7, 2014 by John FX

[Motokid600]

Whats the status of 2.4.5 in x64? "Win64 must die edition" Im guessing means bad things?

[RedAV8R]

Whats the status of 2.4.5 in x64? "Win64 must die edition" Im guessing means bad things?

If you even cared to read any of the Squads own notes, you'll see that Win64 is massively unstable still, and will remain so for the foreseeable future. Read before you speak.

[sarbian]

The titles comes for an exchange with other modders on IRC.

Support for KSP x64 on windows since .24 got out had been quite annoying to handle since users keeps reporting that our mods crash the game while in fact it's the stock game that crash (and mods make it a bit more common since they generate the crash condition more easily). The 0.25 Win64 build seems to be even less stable so some of us decided to include warnings or disable our mod when running the x64 build os KSP on windows.

The MM build for 0.25 includes such message.

[Motokid600]

If you even cared to read any of the Squads own notes, you'll see that Win64 is massively unstable still, and will remain so for the foreseeable future. Read before you speak.

No, I'm sorry. I was not looking for a "status of .25 x64" I'll reword my question.

... So I take it MM 2.4.5 does NOT work at all in x64? ( in .24 ) Because I'm not playing .25. But I want to update RSS. Which uses 2.4.5... So I take it I cannot do that in x64?

Edited October 7, 2014 by Motokid600

[NathanKell]

2.4.5 is fine in .24.

However, sarbian and I and many others don't support .24.2 Win x64 either, so please don't post issues with it, since we can't do anything.

[Motokid600]

Thanks again Nathan! I do appreciate it and.. for what it counts x64 .24 with ALL the mods for Realism Overhaul ( ie heavily modded ) runs with flying colors. A darn shame others aren't experiencing the same.

[NoPersona]

Just because I feel like being annoying and picky here. It shouldn't be named Win64 must die edition, because that can imply to some that the problem is with Windows x64. I propose Unity x64 must die edition, that is more accurate \o/.

[NathanKell]

Motokid600: Wow. You're super lucky then!

[BudgetHedgehog]

Just because I feel like being annoying and picky here. It shouldn't be named Win64 must die edition, because that can imply to some that the problem is with Windows x64. I propose Unity x64 must die edition, that is more accurate \o/.

Well, Unity x64 on Linux works pretty damn well and I don't know if there's even a OSX Unity x64 available - the majority of x64 reports/bugs/crashes come from the Windows version, so that is the one that must die.

[NoPersona]

Well, Unity x64 on Linux works pretty damn well and I don't know if there's even a OSX Unity x64 available - the majority of x64 reports/bugs/crashes come from the Windows version, so that is the one that must die.

Well, I did say "more" accurate not "completely" accurate. :3

Since "Unity for Windows x64 must die" is a bit too long, how about "Winity x64 must die"?

Motokid600: Wow. You're super lucky then!

The game has known to be more stable when using OpenGL not Direct3D. So the Unity player may have defaulted to that allowing it to seem more stable.

[NathanKell]

NoPersona: that's because OpenGL (in Windows) uses way less memory, so you're under the 32bit limit. .24.2 Win x64 is decently stable when under 4GB memory usage; but if it won't let you use more memory than 32bit, and has other bugs (clickbug etc) then why use it?

And .25 has issues even under the 4GB limit.

[NoPersona]

NoPersona: that's because OpenGL (in Windows) uses way less memory, so you're under the 32bit limit. .24.2 Win x64 is decently stable when under 4GB memory usage; but if it won't let you use more memory than 32bit, and has other bugs (clickbug etc) then why use it?

And .25 has issues even under the 4GB limit.

.24.2 had issues under the 4GB limit too. Just adding two part packs guaranteed that it would crash for me.

Oh, and the OpenGL version for .24.2 actually crashed at ~10GB address space usage, so it wasn't anything to do with the process address space usage.

Edited October 7, 2014 by NoPersona

[Lilleman]

I get the warning, but was the nyan cat necessary? It's not very KSP-like (well, it's a cat in space, but still).

[TaranisElsu]

I get the warning, but was the nyan cat necessary? It's not very KSP-like (well, it's a cat in space, but still).

It got your attention, right? So many people have a tendency to ignore warnings so something more was necessary.

[NoMrBond]

It got your attention, right? So many people have a tendency to ignore warnings so something more was necessary.

It would be nice if there was a way to acknowledge said warning (that wasn't vulnerable to user auto-click disease) and not have the loading screen perpetually afflicted by the rainbow flatulating quasi-poptart though.

Something along the lines of 'I solemnly declare that I will not afflict upon Sarbian any error reports or complaints of any kind because I am using x64 on Windows which has more bugs than the 1974 Kansas skyline' would be fine.

[BudgetHedgehog]

It would be nice if there was a way to acknowledge said warning (that wasn't vulnerable to user auto-click disease) and not have the loading screen perpetually afflicted by the rainbow flatulating quasi-poptart though.

There's a way to completely remove that warning, if you're interested. It's to use x86. You want x64, warts and all? Deal with the Nyancat. It's not exactly the worst thing about x64, after all.

[AetherGoddess]

There's a way to completely remove that warning, if you're interested. It's to use x86. You want x64, warts and all? Deal with the Nyancat. It's not exactly the worst thing about x64, after all.

OMG that is the cutest thing. i'm thinking i need to start using x64, warts and all, just for the Nyancat. your warning has failed due to high Delta-Cute.

[Lilleman]

There's a way to completely remove that warning, if you're interested. It's to use x86. You want x64, warts and all? Deal with the Nyancat. It's not exactly the worst thing about x64, after all.

That's some very childish behaviour right here...

Another way could be to recompile the dll without it. I'm trying to do so, and I already know wich part of the code has to go, but a file is missing from the source. I'll take a closer look at it tomorrow, but I'll have my ModuleManager without nyan cat.

[LaydeeDem]

It would be nice if there was a way to acknowledge said warning (that wasn't vulnerable to user auto-click disease) and not have the loading screen perpetually afflicted by the rainbow flatulating quasi-poptart though.

Something along the lines of 'I solemnly declare that I will not afflict upon Sarbian any error reports or complaints of any kind because I am using x64 on Windows which has more bugs than the 1974 Kansas skyline' would be fine.

Because people totally will read some text when it's easier to close out the warning and play.

Right?

s/

Edited October 8, 2014 by Nutt007

[nli2work]

Thanks for updating MM so quickly.

ALT-F11 won't bring up MM menu when first starting KSP; reload database with ALT-F12; then ALT-F11 will work until next time KSP is restarted. tested both with mods/no mods installed

and small usage question, to remove specific modules from a PART/PROP config I do the following correct? It seems to work for config with 1 PROP defined; but not config file with multiple PROPs defined.

@PROP[*]
{
	!MODULE[JSIVariableLabel]{}
}


@PROP[*]
{
	!MODULE[JSISwitchableVariableLabel]{}
}