DMagic

No, I'm saying the font set used by the GUILayout system is very different from the fonts used by TextMeshPro, and they aren't compatible. So it's possible that certain character sets won't render correctly when using OnGUI. Standard Unity UI Text objects might also not render correctly, or they might require that modders find usable fonts. I try to use TMP objects whenever possible, but that complicates making a UI quite a bit, so it would be nice if someone could find out if there are acceptable Unity fonts that we could use. Separate files should also be fine, I'm just saying that they can probably all be downloaded and loaded by KSP at the same time.

@Diazo Yes, except that you should be beaten over the head for suggesting its use for OnGUI. There might actually be problems using OnGUI, since I'm not sure how the fonts would work. The UISkinManager lists NotoSans-Regular SDF as the TextMeshPro Font being used for the English version. Different fonts may be used for different translations, and the TMP Font is probably not compatible with OnGUI fonts, or with standard Unity fonts. Another thing to note, since the Config Nodes use the language selection for the node with all of the text fields, I think you can include multiple translations in a single file. You would just use the same text ids for each translation and put them under different nodes, each with their respective language id. Localization { en-us { #autoLOC_7001100 = Loading... #autoLOC_7001101 = Adding K to Every Word... #autoLOC_7001102 = Adding More Boosters... } //I don't know the actual available language codes es { #autoLOC_7001100 = ... } cn { #autoLOC_7001100 = ... } }

For SCANsat, I have an existing framework in place to handle localization. It works in broadly the same manner as stock localization, but there are some differences. Text fields are read from config files on disk, each with an identifier, this time using simple names, rather than the #autoLOC ids. Some processing is required to convert the files from disk into text that works in code. Then the text fields are applied to wherever they are needed based on their identifier. The first difference is that the text identifier is usually applied to Text objects in Unity, rather than in code. So each text field that supports localization has a simple tag that tells SCANsat which string to apply to it. The other difference is in how the text is processed. It is loaded from Config Nodes in basically the same way as anything else, but it uses some Regex to match string formatters and new line breaks. /// <summary> /// Convert string fields from the Config Node on disk to a format readable in code. /// /// The first two Regex fields match the opening and closing arrows and are used to replace them with curly braces, /// the Regex is created to very specifically only match arrows found for use in string.format. /// /// The third Regex is used to create line breaks. The Config Node loader apparently strips \n characters from values /// so I'm using something simple in its place. /// /// Reflection is used to apply the Regex matches to all string fields in the object. /// </summary> public override void OnDecodeFromConfigNode() { Regex openBracket = new Regex(@"\<\<(?=\d+:?\w?\d?\>\>)"); Regex closeBraket = new Regex(@"(?<=\{\d+:?\w?\d?)\>\>"); Regex newLines = new Regex("NEWLINE"); var stringFields = this.GetType().GetFields(BindingFlags.Instance | BindingFlags.Public).Where(a => a.FieldType == typeof(string)).ToList(); for (int i = stringFields.Count - 1; i >= 0; i--) { FieldInfo f = stringFields[i]; f.SetValue(this, openBracket.Replace((string)f.GetValue(this), "{")); f.SetValue(this, closeBraket.Replace((string)f.GetValue(this), "}")); f.SetValue(this, newLines.Replace((string)f.GetValue(this), Environment.NewLine)); } } Then, when the UI is being loaded and processed the text for the appropriate translation is applied to all of the tagged Unity Text objects. /// <summary> /// This method is used to match a string id with string in this class. /// /// It is not particularly efficient and is only used once, during UI processing. /// </summary> /// <param name="title"></param> /// <returns></returns> public string GetStringWithName(string title) { var stringField = this.GetType() .GetFields(BindingFlags.Instance | BindingFlags.Public) .Where(a => a.FieldType == typeof(string)) .FirstOrDefault(f => f.Name == title); if (stringField != null) return (string)stringField.GetValue(this); return ""; } Strings that aren’t applied directly to Text objects can easily be used by storing a static reference to the active language file. Any text that uses string formatting can be used directly in a string.format. All of this code uses lots of Linq and Reflection and so probably shouldn't be used in any manner that requires it to be repeatedly called during use. For SCANsat everything is applied during UI processing in the main menu, strings that need to be accessed later are then used by referring to the active language pack. The most up-to-date version (which is still out-of-date ) of all this code can be found in the dev branch of the SCANsat GitHub repo.

I have some general notes about how stock localization works that I can put here. All of the text files are kept in the KSP/GameData/Squad/Localization folder. Each config file uses the standard KSP config node structure: Localization { en-us { #autoLOC_7001100 = Loading... #autoLOC_7001101 = Adding K to Every Word... #autoLOC_7001102 = Adding More Boosters... } } Each text entry uses an identifier: #autoLOC_ followed by in id. I believe that anything can be used for an id, alphanumerics, periods, etc., but maybe not an underscore, and definitely no curly braces. There is nothing special about the file location, you can move the files out into another folder in GameData and they will load fine. I assume they are replaced when a different language selection is made in Steam or the KSP Store (Steam refuses to let me switch languages, so I can’t be sure). For actual usage there are two different methods. One is for use in other config files, part descriptions, science results, etc.; for these you just replace the text in the existing config file with the text id. manufacturer = #autoLOC_501627 description = #autoLOC_500605 or KerbinSrfLandedLaunchpad = #autoLOC_501259 To use the text in code, everything can be found in the KSP.Localization.Localizer class. In place of hard-coded strings you can use Localizer .Format and the string id. using KSP.Localization; String text = Localizer.Format(“#autoLOC_500605”); The text fields also use something similar to the placeholders in string.format strings. Because config nodes use {} to open and close segments, they can’t be used in the text fields. Instead format positions are denoted with double arrows: <<1>>, also note these start with 1, instead of the 0-based index that string.format uses. I’m not sure, but I think standard string content formatting works, so you can use <<1:P1>> to convert 0.1257 to 12.6%, or <<2:N3>> to convert 12.245436356 to 12.245. It seems that Lingoona has many different string format converters and they don't follow the same style as the standard c# string formats. String text = Localizer.Format(“autoLOC_600605”, new string[] { 0.1256.ToString(“P1”), CelestialBody.displayName }); Or String text = Localizer.Format(“autoLOC_600605”, new object[] { 0.1256, CelestialBody.displayName }); Or just this String text = Localizer.Format("autoLOC_600605, 0.1256, CelestialBody.displayName); Some of this will need confirming to make sure that’s how it all works, but I think for the most part this is all correct. Another thing to note about the stock translations is that there are a lot of them. Depending on what your mod does you may find that the required translations already exist in the included files. The files are long, but if you know what you are searching for it can be easy to find.

Addon Localization Home This topic will serve as a database of mods that support localization, a place where people who can provide translation help can connect with mods that need said help, and as place to discuss how to implement localization in your mod and how to work with stock localization. To facilitate translation help, anyone who needs translations for their mods should do the following: Respond in this thread with a link to the primary resources in need of localization (preferably a GitHub link to the text files or folder with files) If possible provide an estimate of the number of lines and words in need of translation Post a note in any of the relevant translation discussion threads linked below, including the same resources as above Before anyone begins translating it's worth checking to see if someone else is working on a translation for that mod. Check the forum threads for that mod, the international sub-forum threads, and check for any recent forks on GitHub (on the top-right of the GitHub page, click the number icon next to the fork button to see who has copied the GitHub repo). If someone else is already working on a translation you can always provide help with editing and corrections, or split up the work for larger mods. Translation Discussion Groups: Japanese Spanish Russian Chinese Portuguese French German Stock Translations: [Portuguese] [Polish] - Work in progress Community Localization Project - [French] [Dutch] [German] - Work in progress Localization supported; translations available: Action Group Manager Continued - [Spanish] [German] Airlock Plus - [Russian] [Spanish] [Chinese] [Japanese] [Portuguese] [German] [Italian] [French] Astrogator - [Russian] [Spanish] [Chinese] [French] Auto Actions - [Russian] [Spanish] [Chinese] [Japanese] Antenna Helper - [Spanish] [Chinese] [Japanese] Cryo Engines - [Russian] [Spanish] [German] Cryo Tanks - [Russian] [Spanish] [German] CommNet Visualization - [Russian] [Spanish] [German] Community Resource Pack - [German] Community Tech Tree - [Spanish] [German] CommNet Antenna Extension - [Russian] CommNet Antenna Info - [Russian] Critical Temperature Gauge - [Russian] [Spanish] Dr Jet's Chop Shop - [Russian] [Spanish] [German] Easy Vessel Switch - [Russian] Feline Utility Rovers - [Russian] [Spanish] [Chinese] [Portuguese] [German] [Italian] Heat Control - [German] JSI Advanced Transparent Pods - [Russian] Kerbalism - [Russian] [German] Kerbal Atomics - [Spanish] [German] Kerbal Inventory System - [Russian] Kerbal Planetary Base System - [Russian] [Spanish] [Chinese] [German] KSP Interstellar Extended - [Spanish] [Chinese] Naval Artillery System - [Russian] [Spanish] [Chinese] [Japanese] Near Future Construction - [Spanish] [German] Near Future Electrical - [Spanish] [German] Near Future Launch Vehicles - [Spanish] [German] Near Future Propulsion - [Spanish] [German] Near Future Spacecraft - [Partial Russian] [Spanish] [German] Near Future Solar - [Spanish] [German] Nehemia Engineering Orbital Science Mods - [Spanish] [German] Patch Manager - [Russian] [Portuguese] [German] PicoPort - [Spanish] Rover Science Continued - [Spanish] [German] SCANsat - [Russian] [Spanish] [Chinese] [German] [Portuguese] Science Relay - [Russian] [Spanish] [Chinese] Speed Unit Annex - [Russian] [German] [Spanish] Stage Color Plugin - [Russian] [Spanish] [Chinese] Stockalike Station Parts Expansion - [Spanish] Surface Mounted Stock-Alike Lights For Self-Illumination - [Russian] Suit Refill - [Russian] [Spanish] [Chinese] Tantares Spacecraft - [Russian] Tantares Launch Vehicles - [Russian] Toolbar - [Spanish] [Chinese] [German] Vostok Continued - [Russian] Localization supported; translations needed - Links point to the primary assets in need of translating: Action Group Manager Continued - Needs Chinese, Japanese, Russian, Italian, French, Portuguese Astrogator - Needs Japanese, German, Italian, French, Portuguese Auto Actions - 17 Lines; ~26 Words - Needs German, Italian, French, Portuguese Antenna Helper - Needs Russian, German, Italian, French, Portuguese Asclepius Planet Pack - 164 Lines - Needs Spanish, Chinese, Japanese, Russian, German, Italian, French, Portuguese CommNet Antennas Extension - 10 lines - Needs Spanish, Chinese, Japanese, German, Italian, French, Portuguese CommNet Antennas Info - 6 lines - Needs Spanish, Chinese, Japanese, German, Italian, French, Portuguese CommNet Visualization - 5 words, 2 lines; Needs Chinese, Japanese, Italian, French, Portuguese Community Resource Pack - Needs Spanish, Chinese, Japanese, Russian, Italian, French, Portuguese Community Tech Tree - approx 1300 words, 153 lines; Needs Chinese, Japanese, Russian, Italian, French, Portuguese Connected Living Space - Needs Spanish, Chinese, Japanese, Russian, German, Italian, French, Portuguese Contracts Window + (Plus two associated mods One; Two) - 66 Lines; 190 Words - Needs Partial Chinese, Japanese, German, Italian, French, Portuguese Critical Temperature Gauge - 20 Lines; ~54 Words - Needs Chinese, Japanese, German, Italian, French, Portuguese Cryo Engines - approx 250 words, 25 lines; Needs Chinese, Japanese, Russian, Italian, French, Portuguese Cryo Tanks - approx 800 words, 90 lines; Needs Chinese, Japanese, Russian, Italian, French, Portuguese Deep Freeze - Needs Spanish, Chinese, Japanese, Russian, Italian, French, Portuguese Dr. Jet's Chop Shop - Needs Chinese, Japanese, Italian, French, Portuguese Easy Vessel Switch - Needs Spanish, Chinese, Japanese, German, Italian, French, Portuguese Explodium Breathing Engines - Needs Spanish, Chinese, Japanese, Russian, German, Italian, French, Portuguese Feline Utility Rovers - 1968 Words - Needs Japanese, French Filter Extensions - 24 lines - Needs Spanish, Chinese, Japanese, Russian, German, Italian, French, Portuguese Galileo's Planet Pack - 613 Lines - Needs Spanish, Chinese, Japanese, Russian, German, Italian, French, Portuguese Heat Control - approx 700 words, 59 lines; Needs Spanish, Chinese, Japanese, Russian, Italian, French, Portuguese JSI Advanced Transparent Pods - Needs Japanese, Italian, French, Portuguese Kerbal Atomics - approx 900 words, 40 lines; Needs Chinese, Japanese, Russian, Italian, French, Portuguese Kerbal Inventory System - Needs Spanish, Chinese, Japanese, German, Italian, French, Portuguese Kerbal Planetary Base Systems - 5916 Words - Needs Japanese, French, Portuguese Kerbal Sports - 16 Lines + 3 paragraphs - Needs Chinese, Japanese, Russian, German, Italian, French, Portuguese Kerbalism - Needs Chinese, Japanese, Spanish, Italian, French, Portuguese KSP Interstellar Extended - Needs Russian, Japanese, German, Italian, French, Portuguese Kronkus Planet Pack - 182 Lines - Needs Spanish, Chinese, Japanese, Russian, German, Italian, French, Portuguese Near Future Construction - approx 2200 words, 160 lines; Needs Chinese, Japanese, Russian, Italian, French, Portuguese Near Future Electrical - approx 2800 words, 170 lines; Needs Chinese, Japanese, Russian, Italian, French, Portuguese Near Future Launch Vehicles - Needs Chinese, Japanese, Russian, Italian, French, Portuguese Near Future Propulsion - approx 2500 words, 238 lines; Needs Chinese, Japanese, Russian, Italian, French, Portuguese Near Future Solar - approx 1400 words, 120 lines; Needs Chinese, Japanese, Russian, Italian, French, Portuguese Near Future Spacecraft - approx 1200 words, 144 lines; Needs Chinese, Japanese, Italian, French, Portuguese Nehemia Engineering Orbital Science Mods - Needs Chinese, Japanese, Russian, Italian, French, Portuguese Patch Manager - 131 words, 25 lines; Needs Spanish, Chinese, Japanese, Italian, French PicoPort - Needs Russian, Chinese, Japanese, German, Italian, French, Portuguese Precise Maneuver Editor - Needs Spanish, Chinese, Japanese, Russian, German, Italian, French, Portuguese Real Agencies Collection - Needs Spanish, Chinese, Japanese, Russian, German, Italian, French, Portuguese Rover Science Continued - Needs Chinese, Japanese, Russian, Italian, French, Portuguese SCANsat - 221 Lines; 3630 Words - Needs Japanese, Italian, French Science Relay - 13 Lines; 71 Words - Needs Japanese, German, Italian, French, Portuguese Ship Manifest - Needs Spanish, Chinese, Japanese, Russian, German, Italian, French, Portuguese Speed Unit Annex - 25 Lines - Needs Chinese, Japanese, Italian, French, Portuguese Stage Color Plugin - Needs Japanese, German, Italian, French, Portuguese Stockalike Station Parts Expansion - approx 1000 words, 84 lines; Needs Chinese, Japanese, Russian, German, Italian, French, Portuguese Suit Refill - 12 lines; Needs Japanese, German, Italian, French, Portuguese Surface Experiment Pack - 1398 Lines; 17549 Words; Needs Spanish, Chinese, Japanese, Russian, German, Italian, French, Portuguese Surface Mounted Stock-Alike Lights For Self-Illumination - Needs Spanish, Chinese, Japanese, German, Italian, French, Portuguese Tarsier Space Tech - Needs Spanish, Chinese, Japanese, Russian, German, Italian, French, Portuguese Tantares Launch Vehicles - Needs Spanish, Chinese, Japanese, German, Italian, French, Portuguese Tantares Spacecraft - Needs Spanish, Chinese, Japanese, German, Italian, French, Portuguese Toolbar - Needs Russian, Japanese, Italian, French, Portuguese Vostok Continued - Needs Chinese, Japanese, German, Italian, French, Portuguese Useful links: Lingoona Grammar - describes the available tags used by the grammar system Squad KSP Translations - Stock translation database; may be useful for reference and to match to the stock translation and style KSP 1.3 Modders Notes - Localization support for KSP Localization support for static files - Information on supporting localization for KSPedia, textures, and other non-text files Static File Localizer - Mod for localizing KSPedia and other static files Visual Studio Localization Helper - A VS Extension to help with replacing strings in your code and setting up the localization config file Localizer Helper - A simple mod to allow for forcing KSP to use a non-stock supported language KSPDev Localization Tool - A tool for helping with generating localization files, adding localization support to your mods, and for reloading the localization files in-game to ease the translation process

I've been planning on making a mod-localization thread at some point, with a list of mods and help on how to support translations. Sometime soon. Simplified Chinese is left-to-right (both when using characters and pinyin) as far as I know. I think traditional chinese is sometimes written top-to-bottom, but I imagine it isn't uncommon to be written left-to-right given how impractical vertical text could be in many situations. Yes. You can easily use any of the stock text by finding the right text field in the localization files and using Localization.Format("#autoloc-1010101") to get the text in-game. Though I'm not sure on how well adding in text for mods would work (what would happen if mods use duplicate ids?).

I might could rework the anomaly icon to work like the waypoint icon. The point of that icon falls at the actual location of the waypoint, whereas every other icon is just centered over the location. The anomaly icon could be changed so the dot is directly over the waypoint, maybe with the dot being changed to a circle.

@DStaal Thanks for that, now I just need Module Manager. Do you mean the colors or the question mark icon itself, or both? The colors are just those used by all icons and overlays. I like the question mark, and I wanted something similar to what you see in KerbNet. I really hated the anomaly marker selection thing the old settings menu, so I just made it a fixed thing.

I'm seeing the same problem as @dok_377, the language files won't update. I can update other games just fine, so it seems like a KSP problem, but I'm not really sure where it should be reported.

What @DStaal said, though I think the latest version is in a fairly stable state now; the BTDT anomaly window is also fixed in the dev version. An update for the pre-release should be coming soon, as well. Right now what I need is some help with the resources. Can anyone give me an up-to-date list of which CRP planetary resources (the ones that you can see in the stock resource overlay maps) MKS and Interstellar uses? I need to update the MM configs to get those fixed, and to get them working together properly. @Lunar Sea How so? The new SCANsat interface for adding in stock waypoints (it also works with MechJeb if you want) is the same as before. Using the zoom map you can set the waypoint with whatever accuracy you want by zooming in far enough.

I haven't really maintained this since 1.0; they made a lot of changes that make the test not as useful. All of the parts remain loaded for a very long time when you're in the atmosphere, so for most of the flight there are still 600 parts being calculated, and the aero-effects when you start moving faster can really bog down any GPU-limited setups. You can see how the graph from @riocrokite is basically flat for the first half of the test, since all of the parts remain loaded. But the craft from Curse should still work fine, as long as you point straight up, and you might need to turn on RCS to help keep things more stable. I was putting together a setup that could be tested in space and that would give a better indication of any multi-threaded gains in performance, but then I somehow misplaced the craft files.

Do you mean that the maneuver node handles rotate to orient themselves relative to the future orbit? It used to work like that, before 1.2, I think, but that was reported as a bug, since it didn't work as @Blaarkies suggested in this thread. So they "fixed" the bug by making the maneuver node stop rotating. Now at least it makes sense that if you pull on the normal handle it will continue adding deltaV only relative to the initial orbit. But I agree with the suggestion, even if there is the possibility of some confusion for maneuvers with very large normal or radial changes. I think this: is far more intuitive than this: And while the two existing maneuver node mods are great, I'm partial to my own, which also addresses the OP's suggestions. I think the maneuver node itself works well, it just has some drawbacks, and I don't like the standard, mod-style, window-with-buttons feel of the others.

SCANsat does this, at least to a limited extent (the next version of Contracts Window + will also do this, but it will work with all of its text; most of its text comes from the contracts in-game, but this works for everything else). It allows for replacing the text for all of its tooltips (its setting menu uses many long tooltips as a help function to explain the purpose of all the options) with text read from a config file. In its simplest form, just replacing static text on screen, this isn't too hard. The config file is just a series of repeated config nodes, each with different translations for all the strings. You just have to choose which config node to use, then use those strings in your UI in the place of hard-coded text. https://github.com/S-C-A-N/SCANsat/blob/dev/SCANsat/SCAN_UI/UI_Framework/SCANlanguagePack.cs You can run into complications when you want things like string formats, where you have a hard-coded string with some dynamic element included, like the name of a vessel or celestial body, but that file has methods for loading in curly braces from the strings in the config file (adding curly braces directly to a config node would break it, since KSP would read that as having closed the node). There are instructions for how to create new translation nodes in the SCANsat wiki; aside from the translating part it isn't that hard.

Orbital Science provides tools for other mods to interact with. If there is a problem with those tools then someone will have to tell me about it, otherwise the issue is on the other end.

Version 17.5 is out; get it on GitHub. This update implements a day/night map terminator overlay for all maps, it can be toggled on and off using the new sun and moon icon. It also implements better map fill and reset functions, with the option to choose specific data types. There are also various UI updates and fixes, including some draw order problems with the NavBall, and several UI synchronization problems. This version should be relatively stable and will likely be the last update before the KSP 1.3 pre-release. Just be aware that, as before, this is a one-way update, reverting to SCANsat version 16.x will result in a loss of scanning data. Change Log: Implement day/night map terminator overlays for all maps Toggled with a new icon showing a sun and moon Shows the sun coverage at the time of map reset Implement map fill cheat options Allow for selecting specific data types to fill in Data types apply to map reset as well Must set "CheatMapFill = True" in the settings file Fix some UI draw order problems with the NavBall Fix a potential error that would prevent the big map from closing Fix various UI update and synchronization problems Various minor UI updates The day night terminator shows the regions of the surface in darkness and in the light: It isn't actually a fully accurate representation, since that would more-or-less just be a straight line for all planets in an equatorial solar orbit (ie just about all of them). The method I'm using doesn't actually work with meridian lines, so the overlays are fudged just a little bit, though I think this looks better, too. For higher inclination planets, like Moho, the overlay will be accurate. The position of the sun is updated whenever the map is reset, which is manually done for the big map and zoom map, and is done whenever the red line resets for the small map. More fine-grained options are available for map reset and fill functions: The data type selection applies to both map reset and map fill. To activate the map fill option you have to set the CheatMapFill line to true in the settings file (found in the SCANsat/PluginData folder; the file will only be generated after KSP is started once).

@Redan The GitHub and KSPedia documentation is out of date. Instructions for creating stock waypoints can be found in some of the posts in the last few pages. @Rodger I noticed that. I'm not entirely sure why it happens, but I think I just need to move everything a different UI canvas. The one used by a lot of the stock windows (experiment results, flag panel, etc...) is probably best.

Version 17.4 is out; get it on GitHub. This version implements MechJeb integration (built against version #687), implements biome map legends and legend tooltips, offers more map generation speed options, and fixes some error related to overlay maps. Known bugs: Minor: Some UI sychronization errors Changes in some settings will require toggling a window off and on again before taking effect Not a bug: Existing settings will mostly be reset (scanning data is maintained) Reverting to SCANsat v16.x or earlier will result in loss of scanning data Change Log: Implement MechJeb landing guidance integration Set MechJeb landing target using the waypoint selection function Limited ability to load landing targets Implement biome map legend Implement map legend tooltips Shows terrain altitude or biome info for current mouse position over legend Add more map generation speed controls Three levels available Effect differs depending on map type Fix error with zoom map legend Fix bugs related to planetary overlay maps Fix bug when refreshing zoom map and locked to the current vessel Fix floating point error in resource maps Various minor fixes MechJeb integration works through the waypoint selection toolbar: This is only available if the current vessel has a MechJeb core with the right upgrades. Just push the MJ button after placing the waypoint, it will then be converted into the MechJeb landing target. This works on the big map and the zoom map. The same works in reverse; select a landing site with MechJeb and it will show up on the SCANsat maps. There is also a limited ability to load a saved landing site and set it in MechJeb. This only works when in flight and when the vessel you are loading has the MechJeb core, otherwise the landing target will be deleted. Some settings have been added: The two MechJeb settings will be available if MechJeb is installed. There is also an option for legend tooltips and more map generation speed options. When set at one all maps will update one row per frame. When set at two all maps will update two rows per frame. When set at three the small map will still update twice per frame, the big map will update three times, and the zoom map will update four times. Terrain legend tooltips: Biome legend: The tooltip shows the name of the biome that the mouse is hovering over. For the zoom map the legend does a quick scan of the area covered and only shows the biomes present.

KSP.UI.UIMasterController.ClampToScreen is the function that handles this, and there are options to use offsets so that you can partially drag off the screen. But, I don't think there is any flexibility in the Popup Dialog system there. It seems to handle dragging through a DragPanel component, so I suppose you could try to remove that and implement your own version. Unity uses interfaces to handle all of the UI interaction (see UnityEngine.EventSystems). One of them is IDragHandler, which is where you would put the clamping method. And it's not so much that the Unity UI is janky, it's more the Popup Dialog system. It probably starts to break down when you try to change it too much.

There are some cases where sizeDelta won't report the actual width and height of the rect transform. That only works when the anchors are set to specific values (which might always be the case for Popup Dialogs). If you want the actual size I think the RectTransform.rect will always give it to you; it's just a standard Rect: x, y, width, height. But to change the size of something I think you always need to use sizeDelta, since the rect is read-only. And if the component is part of a layout you'll need to get the Layout Element and change its preferred width and/or height.

I know that @Starstrider42 looked into this a while ago. I don't know if there was ever anything found, but that would be the person to ask.

Lovely... I should have known better than to waste my time with the half-assed part upgrade system they gave us. I think I can preserve the intended functionality by making the upgrade a simple flag for the three science parts and then just use that to set the attached transmitter module to the correct state. It's not that much trouble to just run through each vessel and check for the required components upon loading, though I'm not sure if it's something CommNet will accept or if it will require some kind of forced update to its network.

I would say, if your going to be doing any modding for KSP, it's worth figuring out how the GameObject system works with Unity. Basically everything in Unity is a GameObject (MonoBehaviour inherits from it, and most complex scripts inherit from that), and all of that follows certain set of rules and conventions. That's part of the reason why the new UI is so nice to work with, the old version existed in its own little universe that was entirely different from how everything else worked. The only real difference between the UI and standard GameObjects is that standard GameObjects use a Transform to define their position in space (and it isn't always needed, as many GameObjects don't represent anything physical), while UI objects use the RectTransform, which allows for more nuanced positioning. For a close button though, the simplest thing to do would be to add another button along the bottom row, next to the settings button. It would accomplish the same thing, even if it is in a slightly unorthodox position.

It's not something that the PopupDialog supports, but adding a small button anywhere in the window should be simple. You just have to manually create a UI button, the only sticking points would be figuring out the RectTransform properties to get it into the right position, and it might require a LayoutElement script, which you can just add and set IgnoreLayout to true. I think the source for GC Monitor covers everything needed for creating a button entirely through code.

@Rodger Is the BTDT on (that version has a separate on button for the SCANsat function)? Maybe try using the standard version. If it is on it should show "KSC" instead of "Unknown Anomaly" and it should show the image, even if the shaders are broken.

Version 17.3 is out; get it on GitHub. This version fixes several bugs, implements the planetary overlay map tooltips, fixes the BTDT anomaly window function of the instruments window (needs testing on non-windows platforms; see the bottom of this post for more info), and fixes a long-standing issue where scanning width did not take latitude into account. Unimplemented or Unfinished Features: Other: MechJeb integration disabled Known bugs: Major: Some odd behavior may be observed when planetary overlay maps are left on when switching vessels or scenes Always manually turn off overlay maps Toggling any overlay map on and off should fix any problems (usually text that becomes unreadable) Minor: Some UI sychronization errors Changes in some settings will require toggling a window off and on again before taking effect Not a bug: Existing settings will mostly be reset (scanning data is maintained) Reverting to SCANsat v16.x or earlier will result in loss of scanning data Change Log: Implement BTDT scanner readout Implement planetary overlay map tooltips Scan width properly accounts for latitude Add a flashing waypoint icon when selecting waypoint site Add a separate option for zoom map (and RPM map) biome borders Fix instruments window resource selection buttons Fix scanning data reset button text Fix error in big map equatorial crossing lines Fix bug in zoom map sychronization Various UI updates A long-standing issue with SCANsat is that it didn't take latitude into account when determining scanning width, this resulted in reduced scan width at high latitudes. These pictures show the difference. Here is version 16: In the rectangular map the scan width remains constant, which should not be the case. Here is version 17.3: The rectangular map scanning now looks distorted, as it should, since the map itself is distorted. And the polar map shows even scan width over the poles (you do still get some weird looking artifacts directly around the poles). This also has the side-effect of making the ground-track scanning indicators show a more accurate scanning width: The planetary map tooltips now function when the Overlay window is open, the map is on, and the mouse is over the planet: Other Unity 4.6 UI elements, as well as things like map icons, will block the tooltip. Old GUI windows will not, so if you notice the tooltips showing when the mouse is over another window feel free to pester those mod authors about fixing their UI. The BTDT scanner window has been fixed: I'll need some help testing this with non-Windows platforms. There were some changes made in Unity 5.4 that broke how some shaders work, and now they require being exported from Unity with specific instructions for each platform. So if people running on MacOS, Linux, or Windows when using OpenGL could try this out it would help. To make things easier I've disabled the need to scan for anomalies from orbit for this window to work. All that's needed is to put a BTDT on a vessel, go to the launch pad, open the Instruments window, and turn on the BTDT. If this screen shows up (use the mouse wheel when hovering over the window to change which building is shown) then it works, if everything is pink then it doesn't. @Gilph and @Rodger Don't be fooled into thinking that the slope map represents an accurate indication of terrain slope, it does not. It's more of an approximate suggestion of slope. When zoomed in very far (>100X) it can be useful, but at lower zoom levels, or on the big map, the unreliable calculation method and the scale of the pixels makes it not very valuable. The slope value indicated in the info below when the mouse is over the map (or in the instruments window) is different. It is a very local, much more accurate slope value. It takes the location at the center of the pixel and calculates the slope based on a 5m grid of terrain elevations. But when the pixels can cover a 100s of meters to a few kilometers that doesn't help much. Outside of Minmus I'm not sure that there is any good solution that doesn't involve sending a probe or rover to check out the area first.