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

[sarbian]

A rainny cold day

No log show up yet again

Silence today

[The Beaver]

This probably isn't the right place to post this... but I dunno.

So I used this to fix the transmit bug in x64 last patch, will this work with the newest version of this and 0.25 KSP? Never really programmed this, and the post it's from seems to be gone :-(

// ../Squad/Parts/Utility/commDish/part.cfg

@PART[commDish]:Final

{

@MODULE[ModuleDataTransmitter]

{

@packetSize *= 1000

}

}

// ../Squad/Parts/Utility/longAntenna/part.cfg

@PART[longAntenna]:Final

{

@MODULE[ModuleDataTransmitter]

{

@packetSize *= 1000

}

}

// ../Squad/Parts/Utility/mediumDishAntenna/part.cfg

@PART[mediumDishAntenna]:Final

{

@MODULE[ModuleDataTransmitter]

{

@packetSize *= 1000

}

}

Thanks!

Beaver

[Stavell]

Ok trying to make a patch that applies to all pods with a CrewCapacity tag and a value > 0

Tried this but doesn't work:

@PART[*]:HAS[!CrewCapacity[0],@CrewCapacity[*],!MODULE[IFILifeSupport]]
{
 	MODULE
{
	name = IFILifeSupport
}

}

I want to add the module IFILifeSupport to any module with a CrewCapacity greater than zero that doesn't have the module already loaded

[undercoveryankee]

Ok trying to make a patch that applies to all pods with a CrewCapacity tag and a value > 0

Tried this but doesn't work:

@PART[*]:HAS[!CrewCapacity[0],@CrewCapacity[*],!MODULE[IFILifeSupport]]
{
 	MODULE
{
	name = IFILifeSupport
}

}

I want to add the module IFILifeSupport to any module with a CrewCapacity greater than zero that doesn't have the module already loaded

The ! and @ operators select on child nodes with a specified name attribute. Since CrewCapacity is an attribute, you want the #/~ operator pair, e.g. HAS[~CrewCapacity[0],#CrewCapacity[*]].

[undercoveryankee]

This probably isn't the right place to post this... but I dunno.

So I used this to fix the transmit bug in x64 last patch, will this work with the newest version of this and 0.25 KSP? Never really programmed this, and the post it's from seems to be gone :-(

Thanks!

Beaver

ModuleManager's syntax hasn't changed, so it will parse the file. Some of those parts are included in the general part renaming that took place in 0.25, so you'll have to check their config files for their new names. Also check the RemoteTech changelog. RT 1.5 includes a fix for that bug.

[The Beaver]

Thank you!

[edit] all I can see they've done in RemoteTech is change all the packet intervals to 0.3... I don't really want the limitations of RemoteTech just to fix that bug lol. I'll test if just changing the intervals fixes it or if they've done something in their DLL, thanks again!

[edit2] so far it's working with temp scans and EVA reports at 0.3 on the starter antenna in case anyone is interested... I guess I should make a new post about this instead of editting here lol...

Edited October 9, 2014 by The Beaver

[NathanKell]

It works fine on x64. As the message on the screen says, x64 bugs are x64's problem.

[sarbian]

And once more because some people jump to conclusion : this version of module manager works perfectly fine on x64. The only difference is that you get a warning and an animation. And if that gets me an insult for my work...

And many thanks to the others

Edited October 9, 2014 by Vanamonde
Let's not be hasty.

[Vanamonde]

With regard to some removed posts, express your points without insults, demands, or threats, please. And rather than argue with each other, hit the report button on problem posts and let the moderation staff deal with it. That way, nobody else has to read through the argument to get to the point of the thread.

[INSULINt]

Personally I don't use x64 on windows because of it's instability. I instead keep it simple and torture the heck out of my linux install of ksp

I might just boot up x64 win just to see nyan cat tho. Thanks sarbian!

[NoPersona]

And once more because some people jump to conclusion : this version of module manager works perfectly fine on x64. The only difference is that you get a warning and an animation. And if that gets me an insult for my work...

And many thanks to the others

Well, I'm on the other side of this fence. I think something warning users that there are some issues with the x64 version of Unity is a good thing. Besides the other opinion that I expressed, the only thing that I think would be required is for sarbian to keep up with the releases of KSP, so that if/when there comes a time when the x64 version becomes stable, the message goes away.

[Stavell]

Thank you for the clarification works as expected now.

The ! and @ operators select on child nodes with a specified name attribute. Since CrewCapacity is an attribute, you want the #/~ operator pair, e.g. HAS[~CrewCapacity[0],#CrewCapacity[*]].

[seanth]

I sort of wish I ran 64bit so I could see nyan cat.

Keep up the excellent work!

[prophet_01]

That rainbow cat thing SRSLY confused me

[Commander Zoom]

Personally, I would like the option (via cfg file or whatever) to de-integrate Module Manager from the loading screen. Until .25, I stuck with an older version of the dll (1.5) specifically to avoid this "feature." It provides me with no useful information, gets in the way of the loading bar (or vice-versa), adds clutter, etc. I would prefer it to be as invisible as possible.

Edited October 10, 2014 by Commander Zoom

[INSULINt]

I prefer to see how many patches are applied. It helps to see that it's A) working and when I add/mess with something I can see quickly if it's applying at least.

Also bragging rights?

[Cerebrate]

And once more because some people jump to conclusion : this version of module manager works perfectly fine on x64. The only difference is that you get a warning and an animation. And if that gets me an insult for my work...

And many thanks to the others

As a known grump with regard to x64 issues, sarbian, I'd just like to take a moment to say that I laughed out loud at the Nyan cat (which I also think is a great way to get people to actually read the associated warning), thought the warning was completely appropriate, and were it seeking endorsements, would endorse this approach to the potential for x64 issues completely.

And as such, I'd like to offer you an anti-insult for your work in that area, along with many thanks for ModuleManager in general.

-c

Edited October 10, 2014 by Cerebrate

[Boomerang]

Can anyone point out to me how one would write a MM patch to prevent the actions of another patch?

Specifically, I've just gotten the .25 version of TAC LS and I'd like to prevent the standard 3 days worth of supplies being added to two very small single seat command pods added by some of RoverDude's part packs. Since the TAC LS MM patch adds those supplies to any crewed parts with the ModuleCommand module, how do I tell it to not add supplies to two specific parts?

Thanks for any help!

[NathanKell]

Either write a :FINAL patch to remove them again, or check the HAS block in the TACLS patch and see if you can add something on :FIRST that would make the HAS block fail.

[Boomerang]

Either write a :FINAL patch to remove them again, or check the HAS block in the TACLS patch and see if you can add something on :FIRST that would make the HAS block fail.

I'm really struggling to sort out this syntax from the Github wiki and from looking at the MM examples I've got for my game. I can't find any other patches that actually use the :FINAL. All I can figure is something like:

@PART[HERP_Pod]:FINAL !RESOURCE[FOOD], !RESOURCE[WATER]

Which I know isn't right and doesn't work in the game. Are there any examples out there?

[Reichtangle]

Why is this called the win64/x64 must die version

[Starwaster]

I'm really struggling to sort out this syntax from the Github wiki and from looking at the MM examples I've got for my game. I can't find any other patches that actually use the :FINAL. All I can figure is something like:

@PART[HERP_Pod]:FINAL !RESOURCE[FOOD], !RESOURCE[WATER]

Which I know isn't right and doesn't work in the game. Are there any examples out there?

@PART[HERP_Pod]:FINAL
{
    !RESOURCE[FOOD]{}
    !RESOURCE[WATER]{}
}

Why is this called the win64/x64 must die version

It's a reference to the 64bit Windows version of KSP 0.25 which was found during testing to be more unstable than it was for KSP 0.24.x and a group of modders (who are also on the experimentals testing group) feel it shouldn't have been released and some of them disable their mods if it is detected.

[AetherGoddess]

Why is this called the win64/x64 must die version

there's a fun little easter egg if you run the Win x64 executable. people were complaining at mod makers about bugs in the x64 edition, and those complaints made it impossible to get any real bug reports, so a lot of mod makers, like ferram, just shut down their plugins if they detect win x64. ModuleManager takes a slightly more.... internet libertarian approach.

[g0tchas]

there's a fun little easter egg if you run the Win x64 executable. people were complaining at mod makers about bugs in the x64 edition, and those complaints made it impossible to get any real bug reports, so a lot of mod makers, like ferram, just shut down their plugins if they detect win x64. ModuleManager takes a slightly more.... internet libertarian approach.

Unfortunately for those modders, people like me then simply don't use their mods. My KSP constantly crashed under the 32-bit version because of the memory issues. Since using the 64-bit version of KSP, I've only had problems when I used mods that weren't updated for the 64-bit version. If I take out those troublesome mods, I have no crashes at all. I may just be lucky, but I don't experience any of this so-called instability of the 64-bit version of KSP.

[AlphaAsh]

...I may just be lucky...

That's just it though. Luck. But that doesn't stop a continuous flood of support requests to modders. Because many of the problems are the instability of Win x64, in a lot of cases it's just a lot simpler to just stop the use of a mod in Win x64 in the first place. It's just the same as stating "this mod won't work 99% of the time in Win x64 because... Win x64. Sorry 1% who get lucky, but we don't want the support hassle."