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

[NathanKell]

Read my post above. They do it by, y'know, writing the code in C# and then compiling it.

confignodes are only data storage for code. If the code doesn't support a value, adding it to a cfg does nothing.

[Mecripp]

I knew it was possible because MechJeb and RT2 use it, but I don't know how they do it. I would like to apply this at parts. It will also be usefull by other mods.

Can someone help me with this?

What in RT2 do you think is doing what you think ? and if you look at MJ Part you see

MODULE

{

name = MechJebCore

MechJebLocalSettings {

MechJebModuleCustomWindowEditor { unlockTechs = flightControl }

MechJebModuleSmartASS { unlockTechs = flightControl }

MechJebModuleManeuverPlanner { unlockTechs = advFlightControl }

MechJebModuleNodeEditor { unlockTechs = advFlightControl }

MechJebModuleTranslatron { unlockTechs = advFlightControl }

MechJebModuleWarpHelper { unlockTechs = advFlightControl }

MechJebModuleAttitudeAdjustment { unlockTechs = advFlightControl }

MechJebModuleThrustWindow { unlockTechs = advFlightControl }

MechJebModuleRCSBalancerWindow { unlockTechs = advFlightControl }

MechJebModuleRoverWindow { unlockTechs = fieldScience }

MechJebModuleAscentGuidance { unlockTechs = unmannedTech }

MechJebModuleLandingGuidance { unlockTechs = unmannedTech }

MechJebModuleSpaceplaneGuidance { unlockTechs = unmannedTech }

MechJebModuleDockingGuidance { unlockTechs = advUnmanned }

MechJebModuleRendezvousAutopilotWindow { unlockTechs = advUnmanned }

MechJebModuleRendezvousGuidance { unlockTechs = advUnmanned }

}

}

not sure if you would have to have a plugin or not.

[Olympic1]

and if you look at MJ Part you see

MODULE
{
    name = MechJebCore
    MechJebLocalSettings
    {
        MechJebModuleCustomWindowEditor { unlockTechs = flightControl }
        MechJebModuleSmartASS { unlockTechs = flightControl }
        MechJebModuleManeuverPlanner { unlockTechs = advFlightControl }
        MechJebModuleNodeEditor { unlockTechs = advFlightControl }
        MechJebModuleTranslatron { unlockTechs = advFlightControl }
        MechJebModuleWarpHelper { unlockTechs = advFlightControl }
        MechJebModuleAttitudeAdjustment { unlockTechs = advFlightControl }
        MechJebModuleThrustWindow { unlockTechs = advFlightControl }
        MechJebModuleRCSBalancerWindow { unlockTechs = advFlightControl }
        MechJebModuleRoverWindow { unlockTechs = fieldScience }
        MechJebModuleAscentGuidance { unlockTechs = unmannedTech }
        MechJebModuleLandingGuidance { unlockTechs = unmannedTech }
        MechJebModuleSpaceplaneGuidance { unlockTechs = unmannedTech }
        MechJebModuleDockingGuidance { unlockTechs = advUnmanned }
        MechJebModuleRendezvousAutopilotWindow { unlockTechs = advUnmanned }
        MechJebModuleRendezvousGuidance { unlockTechs = advUnmanned }
    }
}

not sure if you would have to have a plugin or not.

yes, it's that function I want to use for my mod.

[rynak]

rynak: PART is a node like any other node. Therefore delete it with !PART {}

However, there's nor reason to, since you don't gain any performance or memory savings from doing so, and making its category -1 serves the same purpose of removing it from the part list.

But according to the docs, - and ! are synonymous, so i should already have tried that with a squad part, and it didn't work - unless you're saying that "!PART {}" does work, but "!PART[Partname] {}" doesnt.

Personally, i find the syntax of MM to be a bit unintuitive. In theory, plain operations like insert, delete, replace etc should be trivial to understand. Yet, despite of me having used various highlevel programming language, i keep writing MM code by trial and error, because i've given up trying to predict what works and what doesn't work. Maybe that behavior has more to do with loadorder, as opposed to the language, i'm not sure.

[Starwaster]

What in RT2 do you think is doing what you think ? and if you look at MJ Part you see not sure if you would have to have a plugin or not.

Of course that has to be done in a plugin. All of that tech unlocking you see in the MechJebCore is due to underlying C# code supporting it. That MJ2 config node is a configuration for MJ...

[Olympic1]

yes, it's that function I want to use for my mod.

Of course that has to be done in a plugin. All of that tech unlocking you see in the MechJebCore is due to underlying C# code supporting it. That MJ2 config node is a configuration for MJ...

I want to use the 'unlocking tech', like in MJCore, to use it in a part.cfg. But I can't find out how to make that work.

[sarbian]

Personally, i find the syntax of MM to be a bit unintuitive. In theory, plain operations like insert, delete, replace etc should be trivial to understand. Yet, despite of me having used various highlevel programming language, i keep writing MM code by trial and error, because i've given up trying to predict what works and what doesn't work. Maybe that behavior has more to do with loadorder, as opposed to the language, i'm not sure.

Yes, it's not the clearer syntax there is but it works . MM is limited a lot by the fact we use the KSP cfg loader to parse the patch before we process them. A nicer syntax could be done with a different approach, but it would require a lot of work and it's not really on the top of my list atm.

The other problem is that the doc are lacking. And that one is on me ...

Olympic1 : a mod unlocking its functions with tech has nothing to do with MM. As NathanKell said it is done in the plugin code. In MJ it's done here (and in MechJebCore.cs, but I won't explain the whole MJ code on the forum).

[NathanKell]

Sorry, I meant !PART[name]

{

}

To be extra sure, have those {} each on separate lines from the main command.

If *that* doesn't work, then it's probably a root node issue. I thought swamp_ig had fixed it so you could delete root nodes, but maybe there's been backsliding?

[sarbian]

Here is a build for 0.24.

Since 0.24 changed how module are loaded I disabled the Save Game Fixed for that one. It should not be required now.

If you want to keep it you can still use the previous version, it woks fine with 0.24.

ModuleManager.2.2.0.dll

ModuleManager-2.2.0.zip

[Agathorn]

Woah time travel!

[sarbian]

Real modders release their mods from the CEST time zone ! We are the future !

[dewin]

Edit: Not a MM bug. Apparently a MM configuration file ended up in the Squad folder and broke lots of things when I removed its respective addon post-0.24

Original post:

Bug report:

1. Module Manager 2.2 is searching outside of GameData for patches to apply, apparently through folders in the top-level KSP. At the very least, it's applying 4 patches with an otherwise fully stock KSP, aside from mods I've disabled. GameData consists of NASAmission, Squad, ModuleManager.2.2.0.dll and toolbar-settings.dat, nothing else.

2. Something about this is breaking parachutes in 0.24 -- they don't appear on staging and can't be triggered by any means.

Edited July 18, 2014 by dewin

[Preliator]

The game and all the mods works perfectly. I just get this error during the loading.

[sarbian]

Yes, because there is an error in that file (a space in a part name if I remember it right)

[Preliator]

Yes second line in cfg file... now it works... thanks

[Starwaster]

Argh! stop with the spaces in names!!!

[FlowerChild]

Just wanted to check if there's currently any way to disable the loading-screen module manager text.

While it's a useful debugging tool, I'm finding it looks rather unprofessional and would rather not release to the public with it enabled if possible. Or perhaps an option to set it to only display if a problem is encountered?

Edited July 18, 2014 by FlowerChild

[erendrake]

Just wanted to check if there's currently any way to disable the loading-screen module manager text.

While it's a useful debugging tool, I'm finding it looks rather unprofessional and would rather not release to the public with it enabled if possible. Or perhaps an option to set it to only display if a problem is encountered?

Where would such a setting go? in the *.cfg file? as a MM setting file in the root?

I hope if such a setting is implemented we cannot get into a state where some updates are listed on the splash and others arent. The easiest way to enforce this would be a global user setting, outside an individual mod's control.

Also i dont find it unprofessional to announce that cfg mangling is going on.

[FlowerChild]

Where would such a setting go? in the *.cfg file? as a MM setting file in the root?

I'd say a .cfg file param to only display the text when an error occurs would be useful. I'm not really sure what use it serves when there is no error, so I'm not sure why it's being displayed at all in that case, but if others find it helpful, I certainly have no issue just including such a param in one of my config files.

Also i dont find it unprofessional to announce that cfg mangling is going on.

Well, like I said, I don't really mind errors being displayed this way when they do occur. However, when they don't, having a ModuleManager text being displayed in the loading screen just screams "I AM PLAYING A MOD!!!!" at the user IMO.

Personally, I try to keep the mods I create as transparent as possible so that the player is largely unaware they are playing a mod rather than a professionally developed game. It may seem like a small thing, but having such a message always display whether there is a problem or not thus really gets under my skin.

[BigD145]

Just wanted to check if there's currently any way to disable the loading-screen module manager text.

While it's a useful debugging tool, I'm finding it looks rather unprofessional and would rather not release to the public with it enabled if possible. Or perhaps an option to set it to only display if a problem is encountered?

The KSP stock loading screen lists every part it's loading. What makes the module manager text any different? It shows what's active and what's not. With how fast mods move and how often they use modulemanager it is quite useful to have a number or two changing so you know something happened when you changed your mod mix. For a game that's still in active development it is quite useful to have the game scream "you're using mods so stop sending bug reports to Squad, you moron".

[Melfice]

Personally, I try to keep the mods I create as transparent as possible so that the player is largely unaware they are playing a mod rather than a professionally developed game.

Whose professionally developed game?

You are not the developer of the game, FC.

Installing a mod is not something that can be done without understanding you are changing the game somebody else made, therefor making it impossible to forget your game is modded.

I think it is a glorious display of hubris that you think your mod has such an effect on people that you would think they are forgetting they are playing modded KSP.

EDIT: At any rate, this is not your mod either. You are using somebody else's tool to help your own mod along. I am well aware that playing nice with others is not a thing you list in your resumé, as you never have, but it is the vision of sarbian to have the information visible, for whatever reason they thought it necessary.

Edited July 19, 2014 by Melfice

[FlowerChild]

The KSP stock loading screen lists every part it's loading. What makes the module manager text any different?

It's big, it's white, depending on resolution it can directly overlay the loading-bar, it clearly identifies itself as a non-standard part of the game at a glance, and aesthetically it's basically the visually dominant aspect of the screen. It does not feel like it fits in with the rest of the UI.

Installing a mod is not something that can be done without understanding you are changing the game somebody else made, therefor making it impossible to forget your game is modded.

And it's also impossible to not know you're playing a game when you first install it. However, the best games will cause you to be lost in their reality and forget you're playing one, which is referred to as suspension of disbelief.

That's something which is important to me, and which I constantly aspire towards, or at least try to avoid interfering with when I'm working on a mod. Now, it's arguable whether a loading screen plays a role in that, but I personally believe that it does and that's why game studios invest time and money into their design as it's the first thing you see when you boot up a game and thus can go a long way in establishing the player's mood. The KSP loading screen is visually pleasant, establishes a mood through the images displayed, and has obviously been designed to be that way. I personally find the ModuleManager text detracts from that, and if possible, would prefer to turn it off if there is no error found.

I came here to ask a question as to whether a feature was already present and to imply that it might be worthwhile if not, not to start an argument about it. If this isn't something anyone else cares about (and it doesn't appear to be), that's fine.

[sarbian]

Personally, I try to keep the mods I create as transparent as possible so that the player is largely unaware they are playing a mod rather than a professionally developed game. It may seem like a small thing, but having such a message always display whether there is a problem or not thus really gets under my skin.

The player installed the mod, so he his kinda aware that he is playing one. I'd agree with your argument if it was spamming message inflight but on the loading screen ? come on.

Anyway the message will most likely go since swamp_ig found a way to better integrate with the stock loading process. But since you asked nicely I'll add a poney on the screen.

[FlowerChild]

The player installed the mod, so he his kinda aware that he is playing one. I'd agree with your argument if it was spamming message inflight but on the loading screen ? come on.

Well, like I said in my message above: it's arguable, so I really don't expect everyone to agree with me there. However, as I said, game companies spend a lot of time and money on refining loading screens, so I'm obviously not the only person that believes it is important.

Anyway the message will most likely go since swamp_ig found a way to better integrate with the stock loading process.

Cool, thanks for the info. Couldn't be happier with that outcome.

[toril]

I have seen several problems with modulemanager in .24 that didn't exist in .23.5 mostly concerning matching functions and example being active texture managers boulderco folder config.

ACTIVE_TEXTURE_MANAGER_CONFIG
{
	folder = BoulderCo
	enabled  = true
	OVERRIDES
	{
		BoulderCo/Clouds/.*
		{
			compress = true
			mipmaps = true
			scale = 1
			max_size = 0
			make_not_readable = false
		}
	}
	{
		BoulderCo/Atmosphere/.*
		{
			compress = true
			mipmaps = true
			scale = 1
			max_size = 0
			make_not_readable = false
		}
	}
}

works where as the stock version

ACTIVE_TEXTURE_MANAGER_CONFIG
{
	folder = BoulderCo
	enabled  = true
	OVERRIDES
	{
		BoulderCo/(Clouds|Atmosphere)/.*
		{
			compress = true
			mipmaps = true
			scale = 1
			max_size = 0
			make_not_readable = false
		}
	}
}

doesn't work as the folders are compressed but also made unreadable

there was another example where checking if an item was tagged then leaving it alone while changing untagged versions changed everything.