Jump to content

[Minimum KSP version 1.11] KSPDev: LogConsole (v2.1) | Utils (v2.7) | ReleaseTools (v1.2) | LocalizationTool (v1.9)

IgorZ

By IgorZ
in KSP1 Mod Releases

 Share

Recommended Posts

IgorZ

IgorZ

Posted
  • Author
Posted (edited)

KSPDev_Utils v0.30

0.30 (December 14th, 2017):

Edited by IgorZ
Link to comment
Share on other sites
IgorZ

IgorZ

Posted
  • Author
Posted
On 11/9/2017 at 11:00 AM, westamastaflash said:

Does KSPDev_Utils solve the problem that we had a few years ago with many different KSPAPIExtensions versions cluttering up things? 

I apologize for missing this post (the forum sometimes just doesn't send the notifications). So, the Utils library is not fixing (or breaking) anything. It's just a collection of many typical things that people do when writing the KSP mods. I'm not aware of the exact problem that you've referred, so I cannot say if my library is affected by it or not. Could you, please, give more context?

Link to comment
Share on other sites
westamastaflash

westamastaflash

Posted
Posted
6 hours ago, IgorZ said:

I apologize for missing this post (the forum sometimes just doesn't send the notifications). So, the Utils library is not fixing (or breaking) anything. It's just a collection of many typical things that people do when writing the KSP mods. I'm not aware of the exact problem that you've referred, so I cannot say if my library is affected by it or not. Could you, please, give more context?

A few years back, there was a similar library that was a collection of useful shared functions compiled as a separate DLL and used in several mods. The problem was that when multiple versions of this library was installed, KSP would load the first one it found, and if other mods used a later (or earlier) version, things would break because of changes to the library. I believe there is some example code in ModuleManager (search for AssemblyLoader in ModuleManager.cs) on how to ensure that only the latest assembly is loaded when there are multiple copies of a DLL.

Link to comment
Share on other sites
IgorZ

IgorZ

Posted
  • Author
Posted
10 hours ago, westamastaflash said:

A few years back, there was a similar library that was a collection of useful shared functions compiled as a separate DLL and used in several mods. The problem was that when multiple versions of this library was installed, KSP would load the first one it found, and if other mods used a later (or earlier) version, things would break because of changes to the library. I believe there is some example code in ModuleManager (search for AssemblyLoader in ModuleManager.cs) on how to ensure that only the latest assembly is loaded when there are multiple copies of a DLL.

Ah, got it. Indeed, the "versions hell" problem applies to any C# assembly. I've been hit by it in the earlier versions of the KSPDev Utils as well. As of now it's solved this way:

  • The library is not a mod, so the KSP versioning system doesn't kick in here. Hence, it cannot break anything.
  • Every library DLL has the version in the name. This way you may have any number of different versions in the system without a risk to break a mod: every mod links to the specific library name, and the name is bound to the version.
  • The library has to be supplied with the distribution that uses it. It makes the releases a bit bigger but guarantees that the right version of the library is used.

All my mods are using this library, and so far there were no problems with versions.

Link to comment
Share on other sites
westamastaflash

westamastaflash

Posted
Posted
1 hour ago, IgorZ said:

Ah, got it. Indeed, the "versions hell" problem applies to any C# assembly. I've been hit by it in the earlier versions of the KSPDev Utils as well. As of now it's solved this way:

  • The library is not a mod, so the KSP versioning system doesn't kick in here. Hence, it cannot break anything.
  • Every library DLL has the version in the name. This way you may have any number of different versions in the system without a risk to break a mod: every mod links to the specific library name, and the name is bound to the version.
  • The library has to be supplied with the distribution that uses it. It makes the releases a bit bigger but guarantees that the right version of the library is used.

All my mods are using this library, and so far there were no problems with versions.

Excellent, thank you for your work on this!

Link to comment
Share on other sites
  • 2 months later...
IgorZ

IgorZ

Posted
  • Author
Posted

KSPDev_LogConsole v0.17

  • [Change] KSP 1.4.0 compatibility.
  • [Change] Use KSPDev_Utils KSPDev Utils v0.31.

KSPDev_Utils v0.31

Link to comment
Share on other sites
  • 2 weeks later...
linuxgurugamer

linuxgurugamer

Posted
Posted

Can I assume that the Localizationtool will work in 1.4.1 as well as 1.4.0?

Great tool, have been putting off localization for a long time.

Not sure if you are interested in UI bugs.

I just exported EditorExtensionsredux, and the dialog box saying that the strings were exported and the file saved had the file Saved string overwritten by the Close button.

I've put a screenshot of it here on my dropbox:

https://www.dropbox.com/s/w775mr4rzxvivsy/localizationtoolError.png?dl=0

 

Link to comment
Share on other sites
linuxgurugamer

linuxgurugamer

Posted
Posted

Sad to say, it didn't find and export ANY strings from EEX.

Steps I did in a 1.4.1 game:

  1. install it into GameData/KSPDev
  2. Run the game
  3. At the main menu, hit alt-F8
  4. Entered the Prefix
  5. clicked "Show assemblies with no modules"
  6. EEX showed up, so I selected it
  7. Clicked "Export strings from 0 parts and 1 assemblies into exported cfg:

That's when I got the overwritten dialog

I found the exported file in LocalizationTool/PluginData/Lang/EditorExtensionsRedux_strings.cfg

and the total output: 

// Auto generated by KSPDev Localization tool at: 3/23/2018 8:00:17 AM
// Total strings: 0
// Total words: 0

Localization
{
	en-us
	{
	}
}

I tried the same thing with another mod.  It was able to do the parts, but totally missed the DLL (ie:  didn't export any strings)

Link to comment
Share on other sites
LeLeon

LeLeon

Posted
Posted (edited)

1. The Localization Tool relocate part files lines on export part files option.

I don't think, it should do that.

2. It also delete empty lines between MODULE or RESSOURCE. These lines are used to keep part files sections better readable. Or it adds lines as you see on screenshot at mach curve

Spoiler

ZytuPMl.jpg

3. The exported strings file sorting could be improved to keep the part files logic, not alphabetical sort order.

title -> manufacturer -> description -> tags

NOT: description -> manufacturer -> tags -> title

High part count mods need much time to translate the strings itself. It would be fine to reduce the manual work with sorting lines to keep original structure of part files, if the tool just touches lines, where #LOC will be added. So i can copy+paste the complete file content without any relocating of lines. Reduces Github changelog chaos and helps to find errors there more easy.

4. A option for the #LOC name would be cool. I always kill the "_Part" of the LOCstrings and give it a #LOC.ModShortName_-Prefix manually. But i don't know if #LOCstrings in mods have to be uniqe across all mods. I try to prevent string errors with that step.

5. Thanks for your helpful tool!

Edit:

6. Actually i'm working on SXT mod localization. Here i found two parts where no modified part .cfg were created. In strings file these parts and strings exist. Common problem? Any idea why they have modified no .cfg? KE-111 and Goose were involved. Both are cockpits.

7. This tool cannot handle more than one part in a original .cfg file. In my case it created two correct part named configs, but both contains the same = only the first parts strings were generated. Same situation in strings file = both parts are listed, but with same string content of the first part.

Edited by LeLeon
Link to comment
Share on other sites
  • 1 month later...
IgorZ

IgorZ

Posted
  • Author
Posted

Guys, I apologies for the silence.  For the reason unknown the forum simply haven't sent any updates to me on this thread :( Not to mention I was on vacation for almost a half of a month...

On 3/23/2018 at 4:56 AM, linuxgurugamer said:

I just exported EditorExtensionsredux, and the dialog box saying that the strings were exported and the file saved had the file Saved string overwritten by the Close button.

Wow! This is not good. I'm using a stock game dialog to present the string. It probably has some issues when formatting long strings. Thank you for letting me know. I'll consider using my own dialog. Created a bug.

On 3/23/2018 at 5:17 AM, linuxgurugamer said:

I tried the same thing with another mod.  It was able to do the parts, but totally missed the DLL (ie:  didn't export any strings)

The localization tool cannot do magic (no matter how much I'd like it to be). It can extract the strings if the developer has used KSPDev_Utils localization classes (this is how the strings can be extracted from the modules). If it's not the case, then the tool can only gather the generic strings from the part configs. Basing on your message ("Export strings from 0 parts and 1 assemblies") there were no part configs selected, and the only assembly selected was not using the KSPDev classes. The option "Show assemblies with no modules" was designed to show the assemblies that don't contain the part modules. However, if the assembly doesn't have the strings, which the tool can recognize, then nothing will be made. Alas, in your case the tool is useless :(

On 3/31/2018 at 2:03 AM, LeLeon said:

1. The Localization Tool relocate part files lines on export part files option.

Man, you won't believe how much troubles I had with it. I had to make my own parser (sic!) to handle the configs, and it has a lot of limitations. This is one of them. I understand the inconvenience. Believe me, I do - I've translated KIS  :) However, when I imagined how much efforts it would cost me to fix the ordering issues vs how easy it to simply get used to it, I've gave up. Bring in a couple of friends who were hit by the same issue, and I promise, I will fix it for you three :)

On 3/31/2018 at 2:03 AM, LeLeon said:

2. It also delete empty lines between MODULE or RESSOURCE

It does. Handling of the empty lines was the place where I've saved some time. Sorry :( 

On 3/31/2018 at 2:03 AM, LeLeon said:

3. The exported strings file sorting could be improved to keep the part files logic, not alphabetical sort order.

title -> manufacturer -> description -> tags

NOT: description -> manufacturer -> tags -> title

High part count mods need much time to translate the strings itself. It would be fine to reduce the manual work with sorting lines to keep original structure of part files, if the tool just touches lines, where #LOC will be added. So i can copy+paste the complete file content without any relocating of lines. Reduces Github changelog chaos and helps to find errors there more easy.

Well, it's kind of subjective. Sorry, I don't see a big deal here. It doesn't matter where the "title" string is located, what does matter is that it always located at the same place relative to the other elements. You may expect the title to be the first string in the list, and I may expect it be a second or third (it's subjective). If you deal with the translations, it's not what important. What is important, is that the string doesn't "jump" in the file as you re-generate the localization file. The alphabet sorting works just fine here.

On 3/31/2018 at 2:03 AM, LeLeon said:

4. A option for the #LOC name would be cool. I always kill the "_Part" of the LOCstrings and give it a #LOC.ModShortName_-Prefix manually. But i don't know if #LOCstrings in mods have to be uniqe across all mods. I try to prevent string errors with that step.

That's another subjective thing. E.g. I prefer to keep the name, generated by the tool :) Making a flexible system of generating the standard names looks an overkill to me. Nobody would value these efforts anyways. The end users need the localized strings, they don't care about the tags. FIY: the tool is "public domain"  - you can branch and make your own naming scheme ;) 

On 3/31/2018 at 2:03 AM, LeLeon said:

5. Thanks for your helpful tool!

You are welcome! I'm glad to see this very detailed report on a tool, which I thought I'll be using on my own :) 

On 3/31/2018 at 2:03 AM, LeLeon said:

6. Actually i'm working on SXT mod localization. Here i found two parts where no modified part .cfg were created. In strings file these parts and strings exist. Common problem? Any idea why they have modified no .cfg? KE-111 and Goose were involved. Both are cockpits.

Could you, please, send me the samples (it's ok to send via PM)? As I said above, I had to make my own very simple parser. It may fail in many cases.

On 3/31/2018 at 2:03 AM, LeLeon said:

7. This tool cannot handle more than one part in a original .cfg file. In my case it created two correct part named configs, but both contains the same = only the first parts strings were generated. Same situation in strings file = both parts are listed, but with same string content of the first part.

Good point. Created an issue.

Link to comment
Share on other sites
IgorZ

IgorZ

Posted
  • Author
Posted

0.32 (May 5th, 2018):

Link to comment
Share on other sites
IgorZ

IgorZ

Posted
  • Author
Posted (edited)

KSPDev_Utils v0.33

0.33 (May 6th, 2018):

  • [Fix] Fix the search in Hierarchy.FindPartModelByPath. It supposed to do the "breadth-first" search, but in fact was implementing the "depth-first" one. Now it's true BFS.
  • [Fix] Fix reading of the initialized compound and collection fields: don't complain about the readonly fields.
Edited by IgorZ
Link to comment
Share on other sites
  • 1 month later...
IgorZ

IgorZ

Posted
  • Author
Posted

0.35.0 (June 25th, 2018):

  • [Fix] Make a value copy of the persistent fields when copying config from the prefab: ConfigAccessor.CopyPartConfigFromPrefab.
  • [Change] Move specification tag constant from LocalizationManager into a specialized class GUIUtils.StdSpecTags.
  • [Enhancement] Expose the localization tags from the type formatters (e.g. GUIUtils.MassType).
  • [Enhancement] On language version change, reload the part config fields in all the prefabs and the active parts in the scene.

1.2 (June 25th, 2018):

  • Support tags extraction from non-standard part fields.
  • Support structured fields extraction.
  • Reload localizable strings in the prefab configs.
  • Migrate to Utils 0.35.

0.18 (June 25th, 2018):

  • [Change] Use KSPDev_Utils KSPDev Utils v0.35.
Link to comment
Share on other sites
  • 2 weeks later...
IgorZ

IgorZ

Posted
  • Author
Posted

0.36.0 (July 7th, 2018):

1.3 (July 7th, 2018):

  • Improve the strings refresh algorythm to cover cases when the part info depends on the config.
  • Invalidate menus to have UI_Control fields updated.
  • Support more markup cases in the config node parser.
  • Improve handling multi-part configs and MM patches in the part configs.
  • Migrate to Utils 0.36.
  • [Fix] Use unique ID for the GUI dialog to not conflict with the other game dialogs.
  • [Fix #6] Make the rules on how the part fields get sorted.

@LeLeon, you now can sort the parts fields as you wish :) 

Link to comment
Share on other sites
  • 2 weeks later...
  • 2 months later...
IgorZ

IgorZ

Posted
  • Author
Posted (edited)

1.5 (September 27th, 2018):

  • [Fix #7] Empty one-liner node declaration absorbs all nodes downstream.
  • [Enhancement #9] Expand localization tags to the default syntax on patched export.
  • [Enhancement] Report an error if a config file cannot be properly parsed.
Edited by IgorZ
Link to comment
Share on other sites
  • 3 weeks later...
IgorZ

IgorZ

Posted
  • Author
Posted
5 minutes ago, therealcrow999 said:

@IgorZSome reason CKAN is only showing KSPDev: LogConsole 0.19 instead of 0.21. When I click on the github over there is shows this:

Link

Good catch! Created a bug. LogConsole has moved into own repository, but it seems I ether forgot to change netkan config or did it wrong. Thanks for letting me know. I'll get it fixed as soon as Github fully recovered from the recent crash.

Link to comment
Share on other sites
therealcrow999

therealcrow999

Posted
Posted
1 hour ago, IgorZ said:

Good catch! Created a bug. LogConsole has moved into own repository, but it seems I ether forgot to change netkan config or did it wrong. Thanks for letting me know. I'll get it fixed as soon as Github fully recovered from the recent crash.

I only saw it when I was switching from manually downloading the mod to CKAN. I was giving it a test drive. I really like it a lot. I love the split of warnings and what not and a easy in-game log. I tend to do some mod testing. Thanks for the mod.

Link to comment
Share on other sites
IgorZ

IgorZ

Posted
  • Author
Posted
  • [Enhancement] Add --github argument to have the GitHub CHANGELOG links resolved.
  • [Fix] Properly handle the Curse versions with no third component (e.g. "1.5").
  • [Change] Rename argument SpaceDock's --tag_extarct to --version_extract.
  • [Change] Introduce a package to handle the CHANGELOG markup.
  • [Change] Major folder refactoring of the repo.
Link to comment
Share on other sites
This thread is quite old. Please consider starting a new thread rather than reviving this one.

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.

×
 Share
Go to topic listing
×
×
  • Create New...