Search the Community

For some reason, the font in my KSP has changed from the standard colors to a blue color. Also, the colors on my maps (trajectories, planets, etc.) changed to different colors. This happened after I used CKAN to install these mods all at once: scatterer scatterer - default config scatterer - sunflare Environmental Visual Enhancements Environmental Visual Enhancements - Stock Planet Config files Before this I had mechjeb and kerbal engineer installed with no issues. For troubleshooting I have tried uninstalling all mods and deleting all my files and re-installing via steam. Nothing has worked, the text is still blue. Does anyone have any advice on what could cause this, or how to do complete clean reset of KSP to resolve it?

Hey guys. Quick question. What font did they use for the big red "USA" on the S-IC and S-IVB and "United States" on the S-II stages of the Saturn V? Google searches turn up the possibility of Armadillo and Helvetica fonts being used on the S-II stage, but nothing on the other stages. I'm just curious so I can do a quick texture edit for the FASA Saturn V parts and replace the KSP and Kerbal States with their real-life conterparts.

I'm coming across what I think is a bug in Unity's font system that makes it hard for me to "be nice" to other mods and not break them. This problem is weird and what I've learned so far is from a few weeks of on/off trial and error and experimentation. I could be wrong about the cause, but I've barked up a lot of wrong trees already trying to find other possible causes before settling on what I'm about to describe below as what I think is the cause of it. So what's the problem? These two Unity methods Font.GetOSInstalledFontNames Font.CreateDynamicFontFromOSFont can break fonts that are also in a Resource/Asset file if these steps happen in this order: 1: Unity loads a font from Resource or Asset files, but hasn't had any occasion to draw anything in that font yet. 2: Using Font.CreateDynamicFontFromOSFont(), You create another Font instance that is for a font the same font family as the one from step 1 above (i.e. loading "Arial bold" when "Arial" was loaded in step 1.) 3: The font from step 2 (DynamicFontFromOSFont) gets rendered into some text. 4: The font from step 1 (From the Resources or Asset file) gets rendered into some text. When you do the steps in that order, then Unity gets confused and seems to wipe out all the glyphs of BOTH instances of that font from then on (i.e both the one from the Resources and the one from the OS). From now on it will render all text in that font as blank, (and it now claims that all text drawn in that font is 0 pixels wide and 0 pixels high, so things like GUILayout buttons get shrunken to minimum size in addition to not being able to show the labels on things because the font is blank.) Note that if you swap steps 3 and 4 so the Resources font gets exercised in some way before the DynamicFontFromOSFont does, the bug does not happen! It only happens when the first attempt to draw something in the font instance that was built from the OS font call happens prior to the first attempt to draw something in the Resources instance of that font. Note that it's the order in which the fonts get USED to draw something that matters here, not the order in which they first get loaded. (i.e. you can swap steps 1 and 2 and it doesn't change the outcome). As you can tell from the fact that I used "Arial" as my example case above, this means when we do this in kOS, I have the chance to break every other mod that uses Unity's default GUI.skin for something. Oh, and this isn't just about using the legacy IMGUI. I noticed that the act of using the font *anywhere* in Unity is affected, even when I draw 3D hovering text in Arial in the game scene - if the Arial font has had this bug trigger, then that 3D text won't show up. I can trigger the bug by choosing to render font text into a Texture2D in memory that I don't even show on screen anywhere. Even rendering it that way triggers the same problem so long as I do it in the order shown above. Why did I want to do this?: At this point, the person reading this might be thinking, "Well then just don't do it! Stop using the OS fonts and instead ship with one and hardcode it.") So I feel I have to defend my desire to support doing this: I'm trying to let the user use any font on their OS as the kOS terminal font, and move away from our current technique of cutting and pasting regions from a texture file that contains images of the 128 ASCII chars. (For 2 reasons: Using a real font scales a lot better than stretching a bitmap image for those users who prefer the terminal to use a bigger font, and more importantly it would let you print to the terminal in your preferred language, for which you probably already have a font you like installed on your computer that's better for that purpose than whatever we might ship with. But wait, isn't it only a conflict when you actually try to RENDER the font? Isn't the user just picking one font, not every font on the OS? True, but Unity does not expose any of the metadata about a font until after you load it, and even then you still have to actually render a few characters with it before all that you need to know manifests itself. If you haven't loaded a font from the OS yet, then the font's string name is literally the only thing you know about it. You don't know if it's bold, italic, etc (except from making a heuristic guess from looking for substrings in the font's name like "this font's name has the word 'bold' in it. I guess it must be a bold font then.". Most importantly for my case - you can't tell if it's monospace or proportional until after you load it and try rendering a few characters with it. The font metadata isn't available through Unity. So I was doing a quick dummy render of a short string containing some wide and some narrow characters, and counting the pixels Unity reported it took to do so to find out if it's monospaced or not. This is relevant since I use the font to paint a terminal very fast by drawing each line of the terminal as a single string - I need to restrict the picks the user is allowed to the monospace fonts only. It's that test for monospace that mandates that I actually give each font an experimental test render, and it's doing that which caused me to trigger the bug this post is talking about. I thought this would be really slow at first (test render every font) but it turns out that even on a computer with a few thousand fonts installed it only takes a couple of seconds, and I only have to do it once and then never again (and I can throw away the font after I tested it so it's not eating up memory once I learned it's proportional). So why not just avoid it by forcing the order to come out the "safe" way? An obvious fix presents itself: Before trying to use any Font that comes from CreateDynamicFontFromOSFont, kOS could just make sure to iterate over every Font object that ii finds in the Resources and perform a dummy rendering with each of them. (i.e. Tell it to render "Hello" into a Texture2D, then throw away the Texture2D, just to exercise the font a bit first which seems to prevent the bug.) I have tried that and it does work.... but... read on: I'm not in control of the order that OTHER mods do things in, nor am I in control of what order Unity chooses to call the Awake() and Start() methods of all the Monobehaviours from all the mods, nor am I in control of whether or not other mods might try to wait and lazy-load a font dynamically from an asset bundle later on during the game. This means there is no point in time when I can reliably answer "yes" to the question: "At this point have all the fonts that will ever get loaded, during the life of this process, from any Resource/Asset, been loaded and we know there will be no more?" In order to reliably use this workaround to fix the problem, I have to do so at a point in time when that is true, otherwise there will be a Resources/Asset font I missed when I performed the "foreach Resource font, render something small with it" code. So now to the questions for other modders: (1) How many mods actually bother trying to ship with their own font? Then again, with SQUAD doing localizations in the next release, who knows if maybe even THEY might wait to load a font later on after game initialization so I can't rely on knowing if they will do so. Could it be so few mods that the solution is to simply see if we happen to break another mod and if so then react to that and work with the other modder to come up with a scheme to force a known loading order between the fonts used by our two mods? (2) Do I need to consider splitting this work off into a standalone font manager mod and then make kOS require it as a dependency? Then any modder that wants to load fonts should have to work through it instead of doing it on their own? (i.e. similar to other library-mods like the CommunityResourcePack, the goal of such a mod would be to make sure all font loading happens in one place where the order can be enforced to prevent the bug.) (3) Any suggestions for a workaround that I might not have tried? I'm really not a Unity expert at all. The only things I know about it I know from doing kOS dev work. Yes, I am aware of the fact that Unity lazy-loads font glyphs (I found that out when trying to implement other parts of this system) and therefore the need to use Font.RequestCharactersInTexture() before attempting a test render to look at character size. But I suspect the bug above is somehow related to this lazy-loading feature misfiring in some way so the two different instances of the same-named font are stepping on each other's toes, or maybe Unity is getting fooled into thinking it already performed all the lazy-load work for both versions of the similarly named font when it really only did so for one of them. (Thus the font's data never gets populated because it thought it already did so?) (4) As KSP gets more international users, will more mods start considering using their own fonts so that even though this might not be a problem today it will become one soon so I still have to worry about it? (5) Is this a known Unity bug that was already fixed in a release of Unity but we don't have it yet because KSP is a few revisions behind? If so might the problem magically fix itself in the next KSP release? I tried searching Unity's issue tracker for font-related bugs and spent a long time walking through them and not finding anything that seemed related, before I gave up on trying to do that.

I am curious, with the discussion on new fonts/font rendering in the upcoming KSP v1.2, is it possible to drop in an alternate font into the game? The reason I ask, is I happen to have the font "Futura" on my system. Thanks to the research I've done for my custom Kerbal game controller, I've learned that NASA used the Futura typeface on their instrument panels in the Apollo program (and I believe on the Shuttle also). Anyway, I got the font, knowing I'll need it for my controller build. It'll be a desk mounted instrument panel, with real meters, indicators, joysticks, toggle switches, and even a real navball! I wanted it to feel as authentically "spacey" as possible, hence the reason I'm using the font NASA themselves used. Now, I know the font used in most of KSP's text is a san-serif font, much like Futura. What I'd like to know, is whether or not there's a way to get KSP to display it's text using a different font. Whether this can be done by replacing a font file somewhere into the KSP files, altering some file to reference a different system font, or whether a mod can be used to alter the default font, I'd love to know. I just REALLY wanna see what KSP looks like with it's primary font rendered in Futura (and matching my "cockpit" styled controller!

I haven't played KSP for almost a year, but recently decided to blow a couple of kerbals once more After updating the game to latest version and starting it i've faced with some problems. Well, actually there was only one problem - the size of Navball and other UI elements in the game. UI size seems quite normal in menu and Space center, but I remember that when controlling vessels things were smaller than now. Of course, there is 'UI Scaling' in the game settings. After setting it to a minimum value - 80%, I was quite satisfied with the resulting size of Navball and other details, but text in menus and other places became unreadable. Just look at these letters. Look at letter 'a' in 'Reaction wheels'. Doesn't look right, isn't it ? And it's not so blurry because i have JPEG-ed the screenshots too much (actually they are in PNG), it really looks like this in the game. So, my question is: Is it possible to change size of Navball, time-acceleration-scale, altitude-meter and other things back to their pre-patch states, without making text elements unreadable? Even mods are acceptable, if there is no other option. I really want to play this game without having Navball occupying half of my screen. And with readable text. Like it was about a year ago, before the patch I'm using latest Windows version with 1366x768 monitor (the same monitor as I used before the patch).

First of all, I have to say great work! I've been playing KSP since 2012, and I love having it on the console. The game is so complex, I'm impressed with how well you've condensed it down for the xBox controller. But... I'm having trouble reading the text in the map view. The font for my Apoapsis/Periapsis for example is so small I can't read them from 5 feet away on my 32" HD TV. Is there/could there be an adjustment for this in the future?

I've found reading nodes incredibly hard, if not impossible when using Scatterer, or other visual enhancement mods like EVE or SVE. It would help very much to have a font outline in game to add contrast between the font color and a planet's surface. Here is an image of Kerbin using Scatterer and SVE. The font is virtually unreadable. I simply can't use Scatterer anymore because of this issue. And a mock-up of what it would look like if an outline was applied to the font: I looked into this for several weeks, but I am no programmer, so I can't execute this myself. Heck, I don't even know if it's possible in the Unity 5 engine. I just thought I would post a request here as a last ditch effort to work towards getting something that I think everyone would use, though no one has realized the need yet. Thanks for reading.