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

[blowfish]

9 hours ago, Mein_Gott said:

@Merkov @blowfish thank you for help, everything works now, every single mod had to be exactly for current kps version, or else it crashed. might sound obvious, but Its suprising to me, since it never was a case, from my previous ksp experience, when mixing versions was a common practice

It really depends.  I'd say only try it if you really know what you're doing and when things break assume it's the reason.  KSP 1.3 included some changes that broke plugins badly, and in general plugins are very likely to break between versions (except maybe patch versions).  You might have better luck with part-only mods, but then again there was 1.0.5

[Starwaster]

2 hours ago, blowfish said:

It really depends.  I'd say only try it if you really know what you're doing and when things break assume it's the reason.  KSP 1.3 included some changes that broke plugins badly, and in general plugins are very likely to break between versions (except maybe patch versions).  You might have better luck with part-only mods, but then again there was 1.0.5

Yes but this is the first time that outdated plugins crash KSP as expected behavior. Previously, the worst that would happen would be an older plugin throwing exceptions because classes or methods it depended on changed or vanished. 

As things are now, plugins that aren't recompiled for KSP 1.3.0 and have parts with modules from that plugin crash KSP every time.

Edited June 26, 2017 by Starwaster

[Mystique]

On 6/24/2017 at 5:07 PM, Mein_Gott said:

KSP: 1.3.0 Windows 64bit (32bit also tried)

Problem: Crash to desktop after MM loading

Got similar issue: after updating to 1.3 I've updated all mods that were updated, game crashes at ~75% of loading, while KSP.log is spammed with "[something] has no database record.Creating" entries.

Tried disabling ALL mods, done steam file verification to be sure - game launches normally. 

Reinstalled mods and started disabling them by several at once, starting from those for 1.2.x - found out that only disabling MM and mods that are using it (done automatically via CKAN) makes game launch.

Rolled back MM to 2.7.6 - game launched, but kerbonauts in main menu got some strange parts on their backs instead of normal EVA backpacks and at least 1 ship fails to load due to missing part (it's modded, but mode is up-to-date and part is in same place and unchanged since before 1.3).

[sarbian]

MM is not the one making the game crash. The game does not crash without MM because when the part are not patched the outdated module are not loaded. 

TLDR: make sure all your mod are updated for 1.3

[DStaal]

1 hour ago, Mystique said:

Got similar issue: after updating to 1.3 I've updated all mods that were updated, game crashes at ~75% of loading, while KSP.log is spammed with "[something] has no database record.Creating" entries.

Those are useful.  They're normal as the game loads all the parts you have - so the *next* one after the final entry is the part that's causing an issue.  Parts are loaded in filename-alphabetic order, so the next file in the same mod or the first file in the next mod is where you should be looking.

[Mystique]

1 hour ago, DStaal said:

Those are useful.  They're normal as the game loads all the parts you have - so the *next* one after the final entry is the part that's causing an issue.  Parts are loaded in filename-alphabetic order, so the next file in the same mod or the first file in the next mod is where you should be looking.

It was usually crashing at loading of textures for procedural parts (not always the same one, which is strange), not parts themselves, so I tried disabling those first (both texture mods and procedural parts themselves) - no effect, unfortunately. 

I didn't try only disabling all dependent mods while leaving MM itself enabled to see what will happen, good idea came too late, will test that too.

 

1 hour ago, sarbian said:

MM is not the one making the game crash. The game does not crash without MM because when the part are not patched the outdated module are not loaded. 

TLDR: make sure all your mod are updated for 1.3

That was one of first ideas, so I disables everyting that wasn't updated for 1.3 - didn't help. Intuitively I feel that MM shouldn't cause crash on its own, so, perhaps, it's some specific mod+MM, got to spend some time testing

Edited June 26, 2017 by Mystique

[blowfish]

@Mystique Even if it is MM causing the crash (and I highly doubt that) no one will be able to help you without logs.

[Mystique]

16 minutes ago, blowfish said:

@Mystique Even if it is MM causing the crash (and I highly doubt that) no one will be able to help you without logs.

Err, my bad, reinstalled mods again (including MM 2.8.9), removed everyting that doesn't have 1.3 on it and it started. So sorry about thinking bad of MM

Though I still have to find out what the heck is causing this:

UPD: It's KIS/KAS, really weird

Edited June 26, 2017 by Mystique

[TheRagingIrishman]

The stuff on the kerbals backs is from KIS

[Aelfhe1m]

10 minutes ago, Mystique said:

Though I still have to find out what the heck is causing this:

It's KIS - from the changelog:

Quote

1.4.4 (May 1st, 2017)

• [Enhancement] Equip kerbal models on the start screen with sample KIS items. Can be adjusted/disabled via `settings.cfg`.

 

[azander]

Feature request:

  It would be nice if MM could handle installing language packs for mods/stock.  I have no idea if this is even possible, but it would be a handy feature with the recent language system.  We wouldn't have to re-download/install mods just for language translations.

 

 

[Sigma88]

15 minutes ago, azander said:

Feature request:

  It would be nice if MM could handle installing language packs for mods/stock.  I have no idea if this is even possible, but it would be a handy feature with the recent language system.  We wouldn't have to re-download/install mods just for language translations.

 

 

with the current system, if the mod supports multiple languanges, ksp should load the correct language regardless of MM

but the mod needs to support multiple-languages

[azander]

Yes, but having to re-download them for each language update would be solved with a way for MM to add just language packs for a mod.

[Sigma88]

5 hours ago, azander said:

Yes, but having to re-download them for each language update would be solved with a way for MM to add just language packs for a mod.

There's no reason as far as I can tell for a mod to provide "language packs" the text for the translations has negligeable file size.

And even if you want to use mm, what kind of changes would you want to apply?

As far as I know the only instance where mm would be required is if a mod doesn't provide any language support but someone else releases a language pack for that mod. In which case I think mm should be able to handle the substitutions, but I haven't tried

[Aelfhe1m]

39 minutes ago, Sigma88 said:

There's no reason as far as I can tell for a mod to provide "language packs" the text for the translations has negligeable file size.

And even if you want to use mm, what kind of changes would you want to apply?

As far as I know the only instance where mm would be required is if a mod doesn't provide any language support but someone else releases a language pack for that mod. In which case I think mm should be able to handle the substitutions, but I haven't tried

Not for text as far as I can see but you might need some sort of special support if you were going whole hog and also localising image textures (post it notes in interiors, warning messages or signage on part exteriors etc.). Also Squad localise their KSPedia pages by swapping in separate files with the same names. Maybe some MM clause like :LANG[es-es] that would be equivalent to a :NEEDS[] but filters by installed language rather than available mod. With this you could conceivably write a patch to replace the part texture with one of several alternatives depending on which language the player was running. But this seems like a very limited need at the moment as I doubt there will be many mods localised to that degree.

Language packs for text in mods with localisation support doesn't even need MM. You can just drop a config file with a Localisation node and inner language id node and then a list of all the key/value pairs defined for that mod. You'd only need MM if you were wanting to overwrite one or more existing translations from another mod and the existing MM syntax works fine for that.

[Sigma88]

26 minutes ago, Aelfhe1m said:

Language packs for text in mods with localisation support doesn't even need MM. You can just drop a config file with a Localisation node and inner language id node and then a list of all the key/value pairs defined for that mod.

couldn't this method be applied to textures as well?

I assume you can put file paths behind localization ids, if not then I could see the need of having mm detecting the language for packs that have small textures and don't want to bother with different language packs.

for large textures tho it will still be better to have separate language packs so that you don't fill the RAM with unused assets (I would suppose)

[Aelfhe1m]

5 minutes ago, Sigma88 said:

couldn't this method be applied to textures as well?

I assume you can put file paths behind localization ids, if not then I could see the need of having mm detecting the language for packs that have small textures and don't want to bother with different language packs.

for large textures tho it will still be better to have separate language packs so that you don't fill the RAM with unused assets (I would suppose)

File paths accepting localization ids would need to be written into the various modules that consumed those paths.  AFAIK the stock MODEL {} node doesn't have that support for its textures. Until that support is widely available an extension to MM might fill the gap (not sure whether the demand would be worth the development effort though)

I completely agree that packs are best for large/many textures both from a RAM and download size perspective.

[sarbian]

The way loc was done (outside of text) feels rushed (to stay polite). Overwriting file is a cheap trick that should not have been used for a game that had its own asset loading pipeline for years. 

A new mod, or a new module in MM, could help but I would have to hook even more deeply in KSP loading and it gets messy fast. I may have a look later... 

And ":LANG[xx-xx]" may be a good idea.

 

[Sigma88]

I thought that the text was replaced at loading time

so if the game finds something like this:

 

description = #autoLOC12345    (or whatever the syntax is)

 

KSP loads the text which is linked to that ID

 

so I always assumed that if you have a filepath saved under

 

mainTexture = MyMod/mytext

 

you could use 

 

mainTexture = #autoLOC12345

 

and then have various textures stored in different folders for different languages

 

would this not work?

[TheRagingIrishman]

@Sigma88 I never thought of doing that. I don't know if textures or localizations are loaded first so not certain if it would work.

[Sigma88]

1 minute ago, TheRagingIrishman said:

@Sigma88 I never thought of doing that. I don't know if textures or localizations are loaded first so not certain if it would work.

all I know is that I have a mod that changes science definitions, and when I check the content of said definitions (at MainMenu.Start) they already contain the final localized text

from what I've read the localization is the first thing that happens, so by the time the text get to MM it should be already localized

 

but I havent checked this to be honest

[Aelfhe1m]

8 hours ago, Aelfhe1m said:

AFAIK the stock MODEL {} node doesn't have that support for its textures.

Apparently I was wrong about this. I just tried an actual test by creating a dummy part with:

PART
{
	name = loctest
	title = Localization Test
	category = none

	MODEL
	{
		model = #PARTTEST_modelname
		texture = #PARTTEST_texturename
	}
}

Localization
{
	en-us
	{
		#PARTTEST_modelname = Squad/Parts/FuelTank/fuelTankT400/model
		#PARTTEST_texturename = Squad/Parts/FuelTank/fuelTankT400/model000
	}
}

After running the game looking in the ModuleManager.ConfigCache showed that the MODEL node had been completed with the localised values.

A couple more tests showed that config values were automatically localised provided the #localisation_key was the only thing in the value. If it was mixed in with any other text then it was passed through unchanged.

6 hours ago, TheRagingIrishman said:

I don't know if textures or localizations are loaded first so not certain if it would work.

I think this method would still result in both the default and localised version of the texture being loaded into RAM but more testing would be needed.

TL:DR; Textures can be switched in parts using just localisation files provided localisation value contains the full path to the texture

Edited June 27, 2017 by Aelfhe1m
Added a response to TheRagingIrishman's comment

[Maxsimal]

On 6/22/2017 at 2:07 PM, Maxsimal said:

@sarbian

Cool that dump was very useful.  I did it from the main menu and the game is now purple-screened and stuck on 'database reloading 100%' for the last 10 minutes, but that's not a big deal, of course, I'll just restart.

@sarbian Btw, this seems to only dump out part of the DB.  Mine got to "RealismOverhaul.TestFlightRnD.TFRNDSETTINGS.cfg" - I have the RO and RP0 suite of modes installed - and no further.  It's clearly doing them alphabetically, and I know I have several mods, like Taerobee, with configs and parts that occur past this point.

When I tried it in the space center, the game continued to work, got to the same point in the DB, but left 'reloading database 101%' up on the UI after it finished

Edited June 29, 2017 by Maxsimal

[sarbian]

20 minutes ago, Maxsimal said:

@sarbian Btw, this seems to only dump out part of the DB.  Mine got to "RealismOverhaul.TestFlightRnD.TFRNDSETTINGS.cfg" - I have the RO and RP0 suite of modes installed - and no further.  It's clearly doing them alphabetically, and I know I have several mods, like Taerobee, with configs and parts that occur past this point.

When I tried it in the space center, the game continued to work, got to the same point in the DB, but left 'reloading database 101%' up on the UI after it finished

It would help if you had some log because it most likely crashed if it did not finish.

[Maxsimal]

1 hour ago, sarbian said:

It would help if you had some log because it most likely crashed if it did not finish.

https://drive.google.com/open?id=0B7nRgtUVNfGrUGxqZndwTWJkem8 

Hi sorry, didn't realize it would generate something useful without a CTD.   Here you go.