sarbian

[1.3.0] Module Manager 2.8.0 (May 26th 2017) - Better late than never

5125 posts in this topic

@Merkov thanks

updated sigma, reverted KSP to 1.2.2, no change :(

but regarding mods being for 1.2.2 - individual mods work alone and the game starts. its when they are together (lets say - pick any 3 from my list) the crash occurs

Share this post


Link to post
Share on other sites
5 minutes ago, Mein_Gott said:

@Merkov thanks

updated sigma, reverted KSP to 1.2.2, no change :(

but regarding mods being for 1.2.2 - individual mods work alone and the game starts. its when they are together (lets say - pick any 3 from my list) the crash occurs

You have a mix of mods for 1.2.2 and 1.3.  You need to make sure all the versions are consistent.  1.2.2 mods will crash 1.3 and the reverse.

Share this post


Link to post
Share on other sites

@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

1 person likes this

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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 by Starwaster

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites

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

1 person likes this

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 by Mystique

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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 by Mystique

Share this post


Link to post
Share on other sites

The stuff on the kerbals backs is from KIS

Share this post


Link to post
Share on other sites
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`.

 

Share this post


Link to post
Share on other sites

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.

 

 

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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

1 person likes this

Share this post


Link to post
Share on other sites
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 by Aelfhe1m
Added a response to TheRagingIrishman's comment
2 people like this

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now