Jump to content

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


sarbian

Recommended Posts

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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[*]].

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by The Beaver
Link to comment
Share on other sites

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 by Vanamonde
Let's not be hasty.
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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[*]].
Link to comment
Share on other sites

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 by Commander Zoom
Link to comment
Share on other sites

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 by Cerebrate
Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

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