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

[Lisias]

Some of the most interesting Add'Ons are made by non-professionals. They essentially made KSP popular. I don't thing it's the best interest of this Community to alienate them by promoting only "informed responsible modder thow writes patches intelligently" to publish Add'Ons.

There's the learning curve, people will bork a lot until getting in. We need tools that help them.

[Jognt]

On 1/31/2020 at 6:18 PM, FreeThinker said:

Thanks, that helps. If only there was a way to target all partmodules that inherited from the same class.

With a bit of creativity there’s always a way to get done what you want to get done. Though I admit it won’t look as sleek as it would have with an OR clause.  

Have you managed to work it out or would you still like some input?

7 hours ago, Starwaster said:

Yeah, there is. It’s called being an informed responsible modded who writes patches intelligently. Module Manager is already suffering from feature creep and bloat. Regression has been getting introduced which doesn’t get caught for several versions down the line and then it’s ‘well gee I don’t think MM ever supported that in the first place’

What is this mythical creature you speak of?  

[jpkerman]

9 hours ago, Starwaster said:

"...Module Manager is already suffering from feature creep and bloat. Regression has been getting introduced which doesn’t get caught for several versions down the line...

  Next update MM will become self-aware and implement 'Skynet' in our games.

[blowfish]

On 1/31/2020 at 9:18 AM, FreeThinker said:

Thanks, that helps. If only there was a way to target all partmodules that inherited from the same class.

As convenient as it might make things, this goes strongly against the current design philosophy of ModuleManager.  MM currently has no concept of what a PartModule, Part, etc are or how they are used.  All it sees are nodes and patches, it modifies arbitrary data and then lets KSP parse useful information out of that data.

It might be more worth your time to look at the structure of these modules, to me this points to them violating the principle of composition over inheritance.  If there's a shared concern between all these modules maybe it should go in its own module.  Or maybe there's jus one module and the specifics of it are plugged in dynamically based on the data.

[FreeThinker]

12 hours ago, blowfish said:

As convenient as it might make things, this goes strongly against the current design philosophy of ModuleManager.  MM currently has no concept of what a PartModule, Part, etc are or how they are used.  All it sees are nodes and patches, it modifies arbitrary data and then lets KSP parse useful information out of that data.

It might be more worth your time to look at the structure of these modules, to me this points to them violating the principle of composition over inheritance.  If there's a shared concern between all these modules maybe it should go in its own module.  Or maybe there's jus one module and the specifics of it are plugged in dynamically based on the data.

In the Ideal world where have everything under control I would agree with you, but we do not live in a ideal world and are dependent on third party code the get inherited. For example, for the stock partmodule ModuleEngine  there are many classes that inherit from it (both stock and non stock) where you might want to add behavior or properties with a MM script.

[blowfish]

10 hours ago, FreeThinker said:

In the Ideal world where have everything under control I would agree with you, but we do not live in a ideal world and are dependent on third party code the get inherited. For example, for the stock partmodule ModuleEngine  there are many classes that inherit from it (both stock and non stock) where you might want to add behavior or properties with a MM script.

Sure, but there's an established pattern there where everything is called ModuleEngines* which makes it patchable

[Outsoldier]

I'm sorry I'm a big noob I don't understand any of this and i just need help because it wont work in 1.2.2 and i look the forum where it said how to fix but i did all of those and it doesn't work.

[Miguelsgamingch]

1.9 is here.

[James Kerman]

Hello @miguelsgamingch. While it is not against the rules to request an update, so long as it is polite and non repetitive, it's best just to wait patiently for updates to our favorite mods because our fantastic content creating community sometimes have real life pressures and responsibilities that override the excellent free work they perform for the KSP community.

[micha]

Further to that, the current version of Module Manager appears to work perfectly fine under 1.9...   99% of the time mods do NOT need to be updated just because KSP is updated.  There are a few mods and a few updates (eg, 1.7 -> 1.8) which are an exception to this rule, but in general, just try it (make a backup of your save first) and by all means raise bug reports if anything is broken.

[sarbian]

22 minutes ago, James Kerman said:

sometimes have real life pressures and responsibilities

Amen to that. The pressure at work sure is there recently

As other already said the current release works fine for 1.9. CKAN should already reflect that and I just edited the thread tittle.

[Warezcrawler]

I get 1 warning from module manager when loading the game - while the rest 10000 changes loads just fine. How can I identify the cfg file, which has the problem?

There are so many lines in the log, so finding the correct note when not knowing what is would say is kind of hard.

[leatherneck6017]

4 hours ago, Warezcrawler said:

I get 1 warning from module manager when loading the game - while the rest 10000 changes loads just fine. How can I identify the cfg file, which has the problem?

There are so many lines in the log, so finding the correct note when not knowing what is would say is kind of hard.

Look in the MM patch log. It's in the "Logs" folder of your KSP installation.

[kcs123]

7 hours ago, Warezcrawler said:

How can I identify the cfg file, which has the problem?

Notepad++ or similar advanced editor. First search for keyword "warning". Usually, there is not so many in log files to make it difficult to search trough. On that line or one-two lines below is most probable chance to see another keyword to search for. Mostly the part name that raised up warning message, sometimes the name of plugin.

When you find out part name that is culprit, use Notepad++ to search trough folders and within files for that next keyword. That should reveal exact config file where is part that cause error or warning message.

And last piece of debugging puzzle is to reveal exact line in config file that is wrong and rising those error/warning messages.

I would not recommend ModuleManager.ConfigCache file as starting point for searching for culprit parts. It is helpful later on when you get more familiar how MM works, though.

[Warezcrawler]

3 hours ago, leatherneck6017 said:

Look in the MM patch log. It's in the "Logs" folder of your KSP installation.

Thanks... Don't think those have always been, have they? Don't remember them from 2 years ago when I was playing last.... But thanks, they are great.

[blowfish]

29 minutes ago, Warezcrawler said:

Thanks... Don't think those have always been, have they? Don't remember them from 2 years ago when I was playing last.... But thanks, they are great.

They're relatively new.  Since MM runs parallel to model and texture loading now putting things directly in KSP's log would create an incomprehensible mess.  So it logs to a separate file and copies it into the main log later.  There's a chance we could decide to remove that final copy at some point if knowledge of the separate MM logs becomes common enough.

Also quick note about those logs, the content of MMPatch.log and ModuleManager.log are almost the same.  MMPatch contains only the result of patching, the other one contains that plus everything that happens around it (cache checking etc).  The reason is so that we can still have a record of what patches were applied even when loading from cache.

[Lisias]

44 minutes ago, blowfish said:

They're relatively new.  Since MM runs parallel to model and texture loading now putting things directly in KSP's log would create an incomprehensible mess. 

I beg to differ. It makes it easier to look for problems on interactions of different modules - as we get a log of something exactly when it happens, and it makes easier to detect when a problem happens always after something "weird".

My life would be considerably harder and I would not be able to detect a lot of misbehaviours I had detected if I would be using your way of logging things.

I consider this an anti-feature.

 

48 minutes ago, blowfish said:

The reason is so that we can still have a record of what patches were applied even when loading from cache.

Something that can be replaced by a report at the end of the loading system, informing the user about any problems it was found.

Reports are useful, but we need the source data to make it meaningful when pursuing problems that happens by unholy interactions from add'ons. (Kraken food).

[blowfish]

10 hours ago, Lisias said:

I beg to differ. It makes it easier to look for problems on interactions of different modules - as we get a log of something exactly when it happens, and it makes easier to detect when a problem happens always after something "weird".

My life would be considerably harder and I would not be able to detect a lot of misbehaviours I had detected if I would be using your way of logging things.

I consider this an anti-feature.

Trust me, you don't want patching messages intermixed with model and texture loading messages.  ModuleManager runs on a separate thread and what KSP is doing in the foreground (loading models and textures) has no bearing on what ModuleManager is doing.

10 hours ago, Lisias said:

Something that can be replaced by a report at the end of the loading system, informing the user about any problems it was found.

Reports are useful, but we need the source data to make it meaningful when pursuing problems that happens by unholy interactions from add'ons. (Kraken food).

The report is the log.  ModuleManager's log is copied to KSPs log after MM finishes, at least for now.

Edited February 15, 2020 by blowfish

[Sir Mortimer]

12 hours ago, Lisias said:

I beg to differ. It makes it easier to look for problems on interactions of different modules - as we get a log of something exactly when it happens, and it makes easier to detect when a problem happens always after something "weird".

A programmer had a problem. He thought to himself, "I know, I'll solve it with threads!". has Now problems. two he

[Warezcrawler]

15 hours ago, blowfish said:

There's a chance we could decide to remove that final copy at some point if knowledge of the separate MM logs becomes common enough.

Maybe, something as simple as putting a single MM log into the KSP log pointing to these two files would enable you to remove the copy of the logs - that way people like me does not need to know beforehand / or remember it for that matter. We as players / modders would find this info, and go to the referenced files when needed. Furthermore, you could consider keeping the errors in the KSP.log so as to making them visible, while keeping everything else in these separate files. I like them, because they make it very clear that this is what MM is doing.

[Lisias]

9 hours ago, blowfish said:

Trust me, you don't want patching messages intermixed with model and texture loading messages.  ModuleManager runs on a separate thread and what KSP is doing in the foreground (loading models and textures) has no bearing on what ModuleManager is doing.

Yes I want. So I did it. Yes I found some problems. I fixed them. It is what helps me to find correlations between different problems - or cross dependent ones.

I'm not asking about a feature I couldn't managed to implement. I'm talking about a feature I had implemented myself and it's what helping me solve problems on interaction between different Add'Ons for more than a year. It's a field hardened feature.

A close and cautious inspection of the KSP.log will reveal that textures and models are not the only things happening. There're exceptions happening too, and some of them can be very interesting while diagnosing problems.

 

9 hours ago, blowfish said:

The report is the log.  ModuleManager's log is copied to KSPs log after MM finishes, at least for now.

No. The log is the source of data. A Report is a consolidation of that data, sometimes cross-referenced, sometimes punctual, tailored to a specific need. The current MM log is a report that cannot be easily used to solve more complex situations.

Copying the MM log as a blob in the middle of the log doesn't helps. we need the events being logged when it happens, so we can easily try to find correlations.

Having the MM log on a single file is not bad. What's hurting is not having that data on the KSP.log too so more complex reports can be built in a simple and straightforward way.

 

6 hours ago, Sir Mortimer said:

A programmer had a problem. He thought to himself, "I know, I'll solve it with threads!". has Now problems. two he

Threading are old news. There's no excuse for not being able to handle them 12 years after the first HT CPU, P4, hit the consumer market. Even mobiles have 4 or 8 cores nowadays, we really need to move on.

 

4 hours ago, Warezcrawler said:

 I like them, because they make it very clear that this is what MM is doing.

Another good way to make very clear what Module Manager is doing is prefix each line with "[ModuleManager]" . Check how TweakScale (and everything else I code and/or fork) and see what I mean.

Edited February 15, 2020 by Lisias
Brute force post merging

[blowfish]

@Lisias I think you're missing that what I'm describing is how ModuleManager currently works.  This is not theoretical.  And it's been this way for a while.  And I've had to read plenty of users' logs since then so I know exactly what the experience is like.

As for figuring out when things actually happened, every one of ModuleManager's log lines comes with a timestamp of when it actually happened.  If there's an exception in applying one of the patches, that's going to end up in the MM log (and eventually copied to KSP's log).  If the patching thread (or one of the logging threads) crashes (i.e. an unhandled exception), that's also monitored.

[Lisias]

5 minutes ago, blowfish said:

@Lisias I think you're missing that what I'm describing is how ModuleManager currently works. .

No, sir. You are missing that there are people in need of better diagnosing tools, and would be better than such tools could be implemented on MM.

It's perfectly OK you not willing to do so. But so someone else will step up and fulfill the need.

The current way the mainstream MM works is less than ideal, and we (I'm not the only one) are  saying it to you.

[blowfish]

7 minutes ago, Lisias said:

No, sir. You are missing that there are people in need of better diagnosing tools, and would be better than such tools could be implemented on MM.

It's perfectly OK you not willing to do so. But so someone else will step up and fulfill the need.

The current way the mainstream MM works is less than ideal, and we (I'm not the only one) are  saying it to you.

Okay, well if you're having trouble finding the information you need, maybe start with what information you're having trouble finding.  I've read plenty of logs and haven't had any issues but I also understand what MM is doing better than anyone.

[Lisias]

56 minutes ago, blowfish said:

Okay, well if you're having trouble finding the information you need, maybe start with what information you're having trouble finding.  I've read plenty of logs and haven't had any issues but I also understand what MM is doing better than anyone.

Thanks, but I don't have problems on finding the information I need. I have problems on using Stock MM for that. :)

From my duties on TweakScale, I also had read a lot of logs, and my opinions are based on my experience. Right now, I rely on TweakScale and customisations on personal forks, as the current MM is terribly awkward for troubleshooting complex interactions, where the order in which things happens leads to the diagnosis - and cross-referencing many different files is way less practical than just generating a report from a single KSP.log.

Not to mention things that MM just don't check, and some people think it should.