Jump to content

Modders Notes for 1.3


Recommended Posts

Hi folks,
here are the modders notes for KSP 1.2.9/1.3 as they stand for the latest prerelease. Any updates and changes will be posted in this thread.


Localisation

  • Localisation is done using a system of tags. The format of these tags is #autoLOC_xxxxxxx. It is suggested you use a similar format so you can easily detect if a tag is not loaded in the system.

  • Tags are used as keys in a dictionary so they should be unique over all .cfg files in a single language, otherwise the first one found will override any other duplicated keys.

  • You will find these tags throughout the cfg files in the Localization folder. The game has a database of tags that it loads on startup from config files.

  • There are two ways these get formatted into the currently selected language.

    • Either via a call to the Localizer class (good idea to do regardless and especially before joining or manipulating strings).

    • The UI TMPro plugin will also call the Localizer format method before displaying text to the screen.

  • In a lot of cases either strings have been converted to use these tags, or additional display versions of strings have been added to modules, etc. (Listed below, but there are probably others we have missed).

  • All fonts are loaded regardless of language selected which allows display of names, etc in different languages where saves are used across different language settings.

Lingoona Guidelines

  • When using a tag that includes the characters “{” and “}”, the characters “「” and “」”  should be used instead.

  • Lingoona and TMPro support utf-16 and utf-32. So if you need a leading or trailing space in your tag you should use the unicode symbol “\u0020” as <spaces> will be automatically trimmed by the cfg loader.

Format of the tag cfg files.

  • You can create as many .cfg files as you like anywhere in GameData and they will be loaded automatically.

  • The Config node name is “Localization” followed by language data inside the first block and then the tags and their values in the second block.

  • Format is:

Localization
{
   es-es
      {
          #autoLOC_600040 = <b>¡PODEMOS CONSTRUIRLO!</b>
    }
}

 

How to add a language to KSP.

Currently there is only one safe way to add a language to KSP.

This method allows you to add additional languages to KSP with just a few lines of code.

 

Method Steps:

  1. Create a duplicate of all the files located in the folder “GameData/Squad/Localization” to any other folder under the “GameData” folder.
  2. Open those files with a text editor.
  3. Edit the language tag on each of those files for example you are translating from English to German the file language tag should change from “en-us” to “de”.
  4. This is important as this game tag tells the game which translations correspond to which language and if you forget to edit this value you may end up with a mix of languages at the same time. Then edit all the #autoLoc_xxxx entries with the appropriate translated text, preserving the special format strings like <<1>> parameters or style tags <color=orange> untranslated. This special tags are used to give format to the text or inject variable values to dynamic texts.
  5. Create a simple mod, that Starts instantly and changes the language settings like in the following code example.

3UCFyiMM_7LAl2y3Cw4fP3fB8AHI5DYqm3MXziXM

The first method in the example updates the localization table to the desired language. The cfg url’s are stored in the game database and using the Localizer.SwitchToLanguage will switch the Localizer to use the appropriate values for that language.

The second method in the example changes the font setting for the main menu to a set of characters supported by the stock font sets, keep in mind that if your language is not supported in the stock font set you may need to include a font set mod.

Localizer class.

The Localizer class is used to format the strings for localization. It reads the localization tags from the cfg files and replaces them with the appropriate translated texts and parses them through the Lingoona Grammar engine as necessary.
 

Public members

  • Instance - This the singleton instance reference allowing static access to non-static class methods and variables.

  • Tags - This is a reference to the internal tags dictionary that is currently loaded.

  • TagsLength - Returns the tags dictionary size.

  • CurrentLanguage - Returns the current language code.

Public methods

  • string Format(string, params object) - This method receives a text template that can be either a localization tag or a Lingoona format string and a list of optional parameters of any type that can also be tags or Lingoona format strings, the method returns the processed string by the Lingoona Grammar engine replacing the tags with the appropriate value if found.

  • string GetStringByTag(string) - This method receives a localization tag, the method returns the tag value if found, if the tag value is not found it will throw a KeyNotFoundException.

  • bool TryGetStringByTag(string, out string) - This receives a localization tag and tries to get the value and save it on the out parameter, returns whatever value was found or flalse/null.

  • void TranslateBranch(ConfigNode) - This method translates the config node values that contains either a Lingoona string or a localization tag.

  • string GetLanguageIdFromFile - This method returns the language code from the game build settings, this value is managed by steam or downloaded language.

  • bool SwitchToLanguage(string) - This method receives a language code and reloads the tags dictionary with the appropriate values for the specified language, returns whatever the language switch was performed.

Fonts

  • Information on adding fallback fonts and updated Parttools can be found in other posts in this sub-forum.

Misc

  • Propellent.displayName = UI display of propellent.name localized. - Is looked up from Resource definition displayName field.

  • Resource definitions now have displayName field.

  • FlightGlobals.GetHomeBodyDisplayName() is the localized equivalent of FlightGlobals.GetHomeBodyName()

  • Vessel & Protovessel displaylandedAt is the localized equivalent of landedAt string.

  • Vessel.SetLandedAt() - now has two new optional input variables, the gameobject that the vessel is landed on and/or a string with the localized version of what the vessel is landed on.

  • Fix reflected KSPModule attribute on PartModule.

  • Added GameEvent onCommandSeatInteractionEnter which fires before a Kerbal enters/leaves external command seat.

  • Added a mod hook in for science values.

  • Add public accessors to MapView MapNodes for modders.

  • Event for Kerbal name change (to match with type/status change events).

  • Some object renames for clashes with Unity classes    

    • BaseEventData -> BaseEventDetails

    • BaseEventDataDelegate -> BaseEventDetailsDelegate

    • MaterialProperty -> MaterialPropertyExtensions.MaterialProperty

  • Add public accessor to instance of tutorial dialog

  • CustomParameterNode.LocalizedSection is a string containing the localized tag for the Difficulty settings section you want your mods settings to appear in.

  • Added displayseatName and displayseatIndex to InternalSeat Node. These two fields can be used in combination for the seatname that appears in game. displayseatName will be localized and if displayseatIndex is present will be passed into the localization formatter as a parameter.

  • MultiOptionDialog and PopupDialog - the methods for creating these have been changed to include new dialogName or name fields split from the window title fields. These should contain a string that will be the name of the object in Unity, which needs to be different (and not localised) from the window title string.

  • Atmospheric and Exospheric harvesters can now make use of an optional Intake Transform (this can be set via the ‘intakeTransformName’ field.

  • Fixed costs for Upgrade nodes being applied in TechTree.

  • Fixed upgraded parts to now display upgraded stats in TechTree and Parts picker in VAB/SPH.

  • Fixed upgrade modules not displaying correctly in expanded part tooltips in TechTree and Part picker.

  • Added GameEvent onFairingsDeployed when fairings deploy.

  • Abstract method DisplaySection for GameParameters.CustomParameterNode have been added and need to be implemented, this method returns the localized string while the previous method Section returns the non-localized string used for compatibility.

  • KeyBindings primary and secondary have changed from KeyCode to ExtendedKey so they cannot be used in Input.GetKey, Input.GetKeyUp, Input.GetKeyDown. instead mods should use the methods GetKeyDown, GetKeyUp & GetKey of the KeyBindings class.

  • Added IscalarModule to ModuleJettison and public Enumerator for DragCubeSystem.

  • Added an extra parameter on the GenericAppFrame method to receive a displayName separated from the logic.

  • PartModule.GetModuleDisplayName() should return localized version of PartModule Name which is used extensively in UI components.

  • IModuleInfo requires implementation of GetModuleTitle() - which is the internal/English name and GetModuleDisplayName() - which is the Localized name for UI.

  • AGENT definition nodes should include a title = xxxx field. This is the UI localized version of the name = field and can be the same or set to a localization tag.

 

Contracts

TextGen.GenerateBackStories

  • This method generates a contract backstory that consist of 3 sentences an introduction, a problem statement and a conclusion. The values are read from a list of possible predefined sentences that are located in the StoryDefs.cfg file.

  • The logic of this method was modified to be more simple, localization friendly and to generate more consistent backstories.

  • The mindset and motivation parameters have been removed and 4 new parameters have been added instead:

    • contractType: A string containing the contract type value, this is used to read a valid sentence from the config file.

    • allowGenericIntroduction: This value specifies if the contract introduction could be a generic introduction text.

    • allowGenericProblem: This value specifies if the contract problem could be a generic problem text.

    • allowGenericConclusion: This value specifies if the contract conclusion could be a generic conclusion text.

  • Each sentence is generated by the following logic:

    • It starts by looking for the contractType value in the current section (introduction, problem, conclusion) and reads all the possible sentences for that type.

    • Then it does the same for the subject value and reads all the possible sentences.

    • Then it checks if generic sentences are allowed for the current section and if so it will read all the possible generic sentences for the current section.

    • Then using a seed value it will pick a valid sentence from any of the possible values that were read before.

  • After obtaining a valid sentence for each part those are concatenated and then the placeholder values from agency and topic are replaced with the ones supplied in the method.

 

CelestialBody

  • displayName is the Celestial Body name that is used in UI displays. It includes the planets Gender tag for grammar purposes.

  • bodyName is the Celestial Body name. It will always be in English.

  • bodyDisplayName is the localized equivalent of bodyName - With Gender

  • theName is removed. It is now part of the displayName fields.

  • use_The_InName bool is removed.

  • GetDisplayName() returns the displayName.

  • GetName() returns the bodyName.

  • RevealDisplayName() returns the displayName.

  • CBAttributeMapSO contains a two new fields ; localizationTag and  displayname which is the localized equivalent of the name field.

  • CBAttributeMap for Biomes has a displayName and localizationTag

  • miniBiome array added containing MiniBiome class of minibiomes for a body.

Science

  • ResearchAndDevelopment. - GetExperimentSubject has a new optional displaybiomeID which should be localized string of the biomeID field.

  • ResearchAndDevelopment.GetBiomeTags(CelestialBody cb, bool IncludeMiniBiomes) will return a string list of BiomeTag names for body and optionally minibiomes depending on the value of IncludeMiniBiomes.

  • ResearchAndDevelopment.GetBiomeTagsLocalized(CelestialBody cb) will return a list of BiomeTag names for a body and minibiomes in localized text. (equivalent of GetBiomeTags method).

  • ResearchAndDevelopment.GetMiniBiomedisplayNameByScienceID will return either a localization tag or localized string for a minibiome where a scienceID is passed in.

  • ResearchAndDevelopment.GetMiniBiomedisplayNameByUnityTag will return either a localization tag or localized string for a minibiome where a Unity Tag is passed in.

  • ScienceData.displaytitle is the localized equivalent of ScienceData.title

  • All Science IDs for Experiments and Subjects retain the old format in English. That is why there are many new display* fields and methods. the display* fields are used in UIs and strings (such as science title) that appear in UIs.

  • All Biomes and Vessel Situations - same treatment as they are used in the Science IDs and other internal processing.

  • Science.GetBiomedisplayName returns localized string for a biome (including minibiomes).

  • Science.GetExperimentBodyName will return the BodyName from a science subjectID.

  • The Vessel.landedAt field is usually populated with either the KSC Biome name or the regular Biome names by science experiments when conducted. This still occurs, but the Vessel.displaylandedAt field will be populated with a MiniBiome localization tag field if one is found in contact with the vessel (when landed).

  • Getting the experiment biome. ScienceUtil.GetExperimentBiiome now has optional displayBiome string. You can specify null and the displayBiome will be set to the English-only biome name string. If you want to Localize then the correct process is to get both the biome name and displayBiome name (localized) strings. To do this get the vessel biome name via the Vessel.GetLandedAtString method and the display biome name via the vessel.displayLandedAt string (don’t forget to call Localizer.Format on it though!). You should always check that the landedAt string is not empty, in which case the vessel isn’t landed and you use the ScienceUtil.GetExperimentBiome and ScienceUtil.GetBiomedisplayName methods to get this information for a vessel in flight.

  • Getting the experiment subject also can have the biome name and display biome name (Localized) and it will create subject with the english biome name (which is what the game uses internally) and the subject.title will contain the localized display biome name. If you don’t supply the localized biome name the title will just contain the English biome name.
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...