Messages

I have noticed that the external unity plugin TexMeshPro is used for geo-names. In your particular case looks like the mesh drowns under the planet surface.
In addition, this TexMeshPro doesn't seem to cope with non-latin unicode symbols, and there is a post about it in this forum.
For me the standard Unity Projector looks like a good alternative for that, but I may be wrong.

[Defs/RulePackDefs/RulePacks_Global.xml]

I understand your idea but there are some points that would be nice to take into consideration

For example there is a rule in Defs/RulePackDefs/RulePacks_Global.xml:

Code Select Expand

<li Class="Rule_File">
  <keyword>AdjectiveAngsty</keyword>
  <path>Words/Adjectives/Angsty</path>
</li>
Some translator added custom file that contains the same adjectives, but for plural form:

Code Select Expand

<li>AdjectiveAngsty_plural->Words/Adjectives/Angsty_plural</li>
When this (or another) translator works on some rulepack, they have to seek for global keywords (AdjectiveAngsty or AdjectiveAngsty_plural) in two places (Defs/RulePackDefs/RulePacks_Global.xml and DefInjections/RulePackDefs/RulePacks_Global.xml) instead of one. Moreover, RulePacks_Global.xml is not the only context where file rules exist. A lot of things should be kept just in mind. This is a bit confusing and not very convenient.

If you choose to move all file rules from rulesRaw to rulesFiles this issue can is easily avoided, because all important things are in a single place (in Defs or in DefInjected):

Code Select Expand

<li>AdjectiveAngsty->Words/Adjectives/Angsty</li>
<li>AdjectiveAngsty_plural->Words/Adjectives/Angsty_plural</li>

The other point is that if a translator decides to make a full-list replacement of rulesFiles in DefInjections, they must know what they do and won't make foolish mistakes (e.g. replacaing all "default" file rules by one single useless line). If the way how this mechanism works is properly documented (for instance, in xml-comments in Def files) the risk of such mistakes will be minimal.

Well, anyway, with such a powerful tool as full-list translation of file rules it will be possible to achieve much better translation results than now.

I think the best solution here would be to add a new field to rule packs: List<string> rulesFiles; and allow full-list translation.

The mechanism you've just described might be exactly the thing that will cover all the issues connected to file rules.
Let me check if I understand you correctly. The "Rule_File" rules will be moved to the specific section.

For example, file RulePacks_Global.xml like this:

Code Select Expand

<Defs>
  <RulePackDef>
    <defName>GlobalUtility</defName>
    <rulePack>
      <rulesStrings>
        <!-- ... -->
      </rulesStrings>
      <rulesRaw>
        <!-- ... -->
       
        <li Class="Rule_File" ListIndex="24">
          <keyword>mechanoid</keyword>
          <path>Words/Nouns/Mechanoid</path>
        </li>
        <li Class="Rule_File" ListIndex="25">
          <keyword>concept</keyword>
          <pathList>
            <li ListIndex="0">Words/Nouns/Concepts_Badass</li>
            <li ListIndex="1">Words/Nouns/Concepts_Positive</li>
            <li ListIndex="2">Words/Nouns/Concepts_Angsty</li>
          </pathList>
        </li>

        <!-- ... -->
      </rulesRaw>
    </rulePack>
  </RulePackDef>
</Defs>
will turn into something like this:

Code Select Expand

<Defs>
  <RulePackDef>
    <defName>GlobalUtility</defName>
    <rulePack>
      <rulesStrings>
        <!-- ... -->
      </rulesStrings>
      <rulesFiles>
        <!-- ... -->
       
        <!-- Single-file rule -->
        <li>mechanoid->Words/Nouns/Mechanoid</li>

        <!-- Multiple-file rule -->
        <li>concept->Words/Nouns/Concepts_Badass</li>
        <li>concept->Words/Nouns/Concepts_Positive</li>
        <li>concept->Words/Nouns/Concepts_Angsty</li>
       
        <!-- ... -->
      </rulesFiles>
      <rulesRaw>
        <!-- ... -->
      </rulesRaw>
    </rulePack>
  </RulePackDef>
</Defs>

If I get it right, that looks really elegant.
In some localizations projects (English, German) translators will not have to override <rulesFiles> section in DefInjections. In this case the original file paths will be used.
But for some other languages (like Russian, Ukranian and Polish) the translator may decide to override this section and achieve the great flexibility.
The hacky solution that I described in the OP (it is currently implemented in Russian translation) will no longer be needed, and can be safely processed by a script to fit new requrements.
So, the solution you proposed sounds very reasonable.

I wonder if it would make sense to have a [MayTranslate] attribute

That looks good. If you decide that the other approach (with full-list injection of file rules) is hard or impossible to implement, this [MayTranslate] solution will at least save the work done so far.

Anyway, if you want to discuss the full-list approach, feel free to contact me. As a developer, I'm able to help you with some technical issues if it's necessary.

[Way to reproduce:]

The issue https://ludeon.com/forums/index.php?topic=37049.0 is not fixed

Way to reproduce:

• Choose any language except English, for example Russian
• Go to Mods\Core\Languages\Russian\DefInjected\RulePackDef folder
• Replace file RulePacks_Namers_WorldFeatures.xml with RulePacks_Namers_WorldFeatures_Cyrillic.xml (see attachments)
• Start new game and create the world map

Actual result: no geographical names are shown (see first image). Multiple errors are displayed (see second image).
Expected result: geographical names are shown properly (see third image). For similar file RulePacks_Namers_WorldFeatures_Latin.xml (see attachments) everything works fine. No errors displayed. These files differ only in language, they have no references to any other rulepack.

Error text:

Code Select Expand

Root level exception in Update(): System.IndexOutOfRangeException: Array index is out of range.
  at RimWorld.Planet.WorldFeatureTextMesh_TextMeshPro.WrapAroundPlanetSurface () [0x000c7] in C:\Dev\RimWorld\Assets\Scripts\RimWorld\Planet\Features\WorldFeatureTextMesh\WorldFeatureTextMesh_TextMeshPro.cs:105
  at RimWorld.Planet.WorldFeatures.UpdateAlpha (RimWorld.Planet.WorldFeatureTextMesh text, RimWorld.Planet.WorldFeature feature) [0x0003f] in C:\Dev\RimWorld\Assets\Scripts\RimWorld\Planet\Features\WorldFeatures.cs:96
  at RimWorld.Planet.WorldFeatures.UpdateFeatures () [0x000a9] in C:\Dev\RimWorld\Assets\Scripts\RimWorld\Planet\Features\WorldFeatures.cs:75
  at RimWorld.Planet.World.WorldUpdate () [0x00071] in C:\Dev\RimWorld\Assets\Scripts\RimWorld\Planet\World.cs:238
  at Verse.Root_Entry.Update () [0x0003c] in C:\Dev\RimWorld\Assets\Scripts\Verse\Global\Root\Root_Entry.cs:48
Verse.Log:Error(String, Boolean) (at C:\Dev\RimWorld\Assets\Scripts\Verse\Utility\Debug\Log\Log.cs:78)
Verse.Root_Entry:Update() (at C:\Dev\RimWorld\Assets\Scripts\Verse\Global\Root\Root_Entry.cs:55)

[attachment deleted due to age]

[[NoTranslate]]

Thank you for your reply.
I've just noticed the commit by Isonil. This full-list translation feature is very helpful for translation of generators.
The other important thing I appreciate in the new version is the reworked translation report generator. That's really great feature, thank you and your team very much!

The third thing I've noticed confused me a lot. The report contained tons of errors looking like:

Code Select Expand

Translated untranslatable field keyword ...
I've decompiled the dll and noticed the [NoTranslate] attrubute for "keyword" field in class Verse.Grammar.Rule.
All the keywords are connected to the Rule_File's (with keyword and text file path) I've overriden in DefInjections for B18. That's exactly what I mentioned in the OP.
As I mentioned, unfortunalety it's almost impossible to use current file rules in their initial state to achieve good quality of generated stories. I relied so much on the feature of overriding keywords and paths to make them work better. I spent quiet a lot of time trying to improve the quality of generated stories by making references to new text files (with plurals forms, differents genders and so on). I regret to imform that this new attribute just multiplied all this work by zero. Moth of the Russian generators are broken down now. We need your help!

I can see several ways to solve this situation.
That full-list injection feature looks quiet good. It will be perfect if you implement the same mechanism for File Rules. It will give us full freedom and flexibility! This is the best solution I could ever imagine.
Or al least, if it's possible, could you please just remove this [NoTranslate] attribute from keyword field? I don't think this operation will consume a lot of your time, but at least it will save the translation (generator programming) work that is already done. Moreover, if you copy-paste some (or a lot of) extra <rulesRaw> into the Mods\Core\Defs\RulePackDefs\RulePacks_Global.xml and other rulepacks you will save the tranlator's time and nerves in future as well .

Thank you in advance.

If the player chooses "Lost tribe" scenario, while choosing a place for the first settlement, the game says "Select landing site".
The problem is that a neolithic tribe initially cannot "land" anywhere as it doesn't have anything to fly on.
The UI should be corrected for this page.

Sorry for the replying to the old topic. I just do not want to create another similar topic here.
So what about adding more keywords and file rules to be overriden in DefInjected? This is really important stuff for translation of story and name generators. This question concerns me as a translator very much.
It would be great if any deleloper posted their comment on it.

[widely!]

In-game story generators take some words from textfiles. References to these text files are given in Defs\RulePackDefs\RulePacks_Global.xml.
The rules look like this:

Code Select Expand

  <RulePackDef>
    <defName>GlobalUtility</defName>
    <rulePack>
      <rulesStrings>
      ...
      </rulesStrings>
      <rulesRaw>
        ...
        <li Class="Rule_File">
          <keyword>color</keyword>
          <path>Words/Nouns/Colors</path>
        </li>
        <li Class="Rule_File">
          <keyword>animal</keyword>
          <path>Words/Nouns/Animals</path>
        </li>
        <li Class="Rule_File">
          <keyword>animalgroup</keyword>
          <path>Words/Nouns/AnimalGroups</path>
        </li>
        <li Class="Rule_File">
          <keyword>weapon</keyword>
          <path>Words/Nouns/Weapons</path>
        </li>
        ...
    </rulesRaw>
  </rulePack>
</RulePackDef>

However, some languages require more than one form of such words. E.g. animal words are used in different contexts in several cases (nominative, genitive, accusative) in both plural and singular forms.
Luckily, these text file references are allowed to be overriden in localizations (via DefInjections):

Code Select Expand


<GlobalUtility.rulePack.rulesRaw.7.keyword>animal</GlobalUtility.rulePack.rulesRaw.7.keyword>
<GlobalUtility.rulePack.rulesRaw.7.path>Words/Nouns/Animals</GlobalUtility.rulePack.rulesRaw.7.path>

<GlobalUtility.rulePack.rulesRaw.8.keyword>animal_accusative</GlobalUtility.rulePack.rulesRaw.8.keyword>
<GlobalUtility.rulePack.rulesRaw.8.path>Words/Nouns/Animals_accusative</GlobalUtility.rulePack.rulesRaw.8.path>

<GlobalUtility.rulePack.rulesRaw.9.keyword>animal_plural</GlobalUtility.rulePack.rulesRaw.9.keyword>
<GlobalUtility.rulePack.rulesRaw.9.path>Words/Nouns/Animals_plural</GlobalUtility.rulePack.rulesRaw.9.path>


We use this technique widely! It gives a lot of flexibility and make generated stories expressive and rich! Without it generated text were poor, incoherent and unreadable.
Unfotunately this technique has a major drawback: the number of overridable keywords is very limited and insufficient. I work on the Russian localization and we really need more file-ref-rules to override.

I believe that's easy to implement by just adding to RulePacks_Global.xml lines like:

Code Select Expand

 
        <li Class="Rule_File">
          <keyword>dummy</keyword>
          <path>Words/Empty_file</path>
        </li>
        <li Class="Rule_File">
          <keyword>dummy</keyword>
          <path>Words/Empty_file</path>
        </li>
        <li Class="Rule_File">
          <keyword>dummy</keyword>
          <path>Words/Empty_file</path>
        </li>
        <li Class="Rule_File">
          <keyword>dummy</keyword>
          <path>Words/Empty_file</path>
        </li>
        <li Class="Rule_File">
          <keyword>dummy</keyword>
          <path>Words/Empty_file</path>
        </li>
        <li Class="Rule_File">
          <keyword>dummy</keyword>
          <path>Words/Empty_file</path>
        </li>
 

It will be a convenient and easy way to improve quality of translations for all languages! Thank you in advance!

[much]

I just want to duplicate my ideas here. I believe they are cheap enough.

1. Brief description for diseases would help new players a lot.
https://ludeon.com/forums/index.php?topic=39253.0

2. Extra word file references at "Mods\Core\Defs\RulePackDefsRulePacks_Global.xml" will make generated texts much reacher, better and easier to read in different languages (if someone overrides them in DefInjected).
https://ludeon.com/forums/index.php?topic=37216.0

To make the idea clearer I have created a more detailed image of what I am suggesting.
If it is still not clear enough please let me know.

[attachment deleted due to age]

I think the learning helper could cover this, because the answers for all conditions are sort of the same.

- All diseases kill you at 100%
- How long it lasts varies a lot, a heart attack will kill in a few hours, sleeping sickness can drag on for weeks. So it doesn't really help your planning; just look at how fast the disease is progressing to decide if you're going to use your best medicine or beds/doctors or not.

Well, actually, by "diseases" I meant ones from this list: http://rimworldwiki.com/wiki/Disease. Not all of them are deadly, and the duration of treatment differs heavily. The information is vital for colony survival and for the player.

Regarding UI, my original idea was to place the description inside a hediff tooltip (see the first attachment), but the idea of giving this text as a letter looks even better (see the second attachment).

[attachment deleted due to age]

It would be great if some in-game descriptions for diseases were added.
This information may appear, for instance, in the "health" tab as part of the tooltip for a hediff.
The description may cover such points as:

• does this disease kill patient or not
• how long it may last
• how it should be treated

I believe this information will help new players very much.
Thank you in advance.

[rules]

Defs also code. External code.

Really? Maybe you'll say that backstories file is a piece of "external code" too )? Reading of the file is also required on start and this data is also placed to memory.

More, all this external code load in memory (and save in memory) on start. All this external code parse on start. This both strong (quick access) and weak (memory usage) side Unity engine.

Ah, yeah, you are absolutely right! Several milliseconds on load and few kilobytes of memory is a really big deal (sarcasm)!

How much empty files you need in each RulePack

Only one empty file is needed. In original Defs, new "reserved" rulesRaws may just reference this one single file. Just in order to be overriden (or not) in DefInjections for different languages.

How much need for other language, more than you or less?

I cannot say for every language of the world, but for Russian it would be great if number of "Rule_File" entries in Global was doubled, and several "Rule_File" entries were added to some rule packs (e.g. faction name generators requre at least 10 such file references to achive the best result)

It would be much better if number of file references and rules for specific languages was not limited by the fixed number of original Def entries. I would suggest that it could be achived by placing rules to text files just lile it is done for separate words in Strings folder. For example in some folder, e.g. "Strings/Rules", there will be a file, e.g. "NamerFactionBasePirate.txt", with lines like:

Code Select Expand

name->[badassanimal] [geography]
name->[badassconcept] [geography]
name->[badassanimal]'s [geography]
name->[badassperson]'s [geography]
geography->[terrainfeature]
geography->[community]

In this case number of Def data for rulepacks and tales will dercrease significantly and a great flexibility will be the result.
What would RimWorld developers say about this approach?

And fixing via "give me lot rawRules" very bad idea: grow code, less stability and performance, and more memory usage (each empty file must be load).

What exactly are you talking about? Adding new rawRules to defs cannot lead to any decrease in stability or performance because it doesn't require any code modification. As weel as loading empty files (or the same empty file) doesn't reqiure any extra usage of memory as there is no data in them.