sarbian

[1.8.x] Module Manager 4.1.0 (October 16th 2019) - Right To Ludicrous Speed

Recommended Posts

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 by Pirsig
forgot to add version

Share this post


Link to post
Share on other sites

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 by sarbian

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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 by John FX

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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 by Motokid600

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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 by NoPersona

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 by Nutt007

Share this post


Link to post
Share on other sites

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]{}
}

Share this post


Link to post
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.