Search the Community

(new member) I've been tearing my hair out over this for the past 2-3 days. I'm currently making a simple mod that calculates if a flight is possible given current delta-v's. However, I cannot figure out how to get the delta-v's of a ship in an editor, nor able to even get any sign of a ship being detected. I think it has to do with ShipConstruct, but I can't figure out how to get current vessel as a Ship. It could also be Vessel that handles editor, but I found nothing suggesting that to be the case. I've skimmed through the class index on the API site, and found nothing. Does anyone know about this? I'm very new to C# modding.

I've been following the UI Creation Tutorial here on the forum and I'm stuck on the "Exporting the Asset Bundle" section. I really do not understand what they are talking about. Are there any video tutorials for this? I'm a very visual learner and this section literally makes no sense to me. I do not know where the Asset Compiler Window is, I do not know what they mean by prefabs, and I don't have any clue what they mean by the second bullet point. Any help is appreciated, please help!

So, I have decided to master a programming language. However, I can't decide: Python or C# or C... Which is the hot commodity in the market? There are lots of programming genii here, so I will be glad if someone helps me out on this one...

I'm currently looking for a way to read information from KSP (ingame) on my main pc and use a Raspberry Pi 3 to display the information. My main pc will play the game and I want to use my raspberry pi with 7-Segment display. I just need a way to transfer data from my pc to the pi or even simpler just aquire the data, from there I can code the Pi 3 & 7-Segment Display by myself. So how can I read information like the height, velocity etc...? I have a good portion of programming expierence in Python, C++ & Web but some to none expierence with C# which is needed for KSP.

EDIT: Plugin help fullfilled I have decided to create a plugin that hooks into your Discord via RPC which allows KSP to send status updates for Rich Presence on Discord. The idea being, if you are orbiting the muun, or crashing spectacularly, or boosting at a certain altitude or joining a Multiplayer KSP with DMP, then people on discord will know. The idea being RP will update with images of what moon/planet you are nearest too or what server, if you are using MP then a connection can appear on discord client. [Info on Rich Presence] https://discordapp.com/developers/docs/rich-presence/how-to Credit is given to nostrenz for base idea, standalone RPC version here: https://github.com/nostrenz/cshap-discord-rpc-demo It seems for RPC to work I need to have a compiled RPC client in the GameData/<mymod/plugins/ folder with my mod for it to function, I have used DLLImport and the compile works flawlessly, unfortunately, nothing posts to the console log when using Debug.Log and my plugin does not update my status with the vanity statuses set in MainCord.cs https://imgur.com/RJdYE07 I've made my project publically accessible if you are feeling up for helping out a noob: https://github.com/4669842/KSPCord-1.3.1 You will need to add this DLL for RPC Discord to your compiled version: https://github.com/nostrenz/cshap-discord-rpc-demo/releases (hope to merge into one) IDE is set to framework 3.5, VS says there are no compile issues. For now, I hardcoded the ClientID as I only need a single app to access discord but once I learn how to create nodes and assign key value pairs I can allow others to host their own apps on discord if needed (Once this actually works)

Can anyone reply with example source on how to write a resource consumer code ? I need it in form of custom code that will both consume a resource under specific conditions and manage loading/saving to/from persistence and vessel cfg (i already know how to handle load/save, i just mentioned it so it may be known in advance what my code needs to do). And if resource generation is also not so much different from consumption code, an example for that too would be appreciated.

My animation plugin development has reached another phase : adding sound effect support to animations. More precisely, is sound fx really needed in KSP plugin ? Is absence of it a minor annoyance or game-immersion-breaking bug ? Note that my plugin is intended for animating various parts that are (at least for now) used as structural or aerodynamics parts (resource capacity/usage support may be added later, its on a backburner for now). Also note that due to nature of my plugin, i can't use normal EFFECTS node setup for audio.

One last ditch effort. I can add and remove actions groups in runtime in my PartModule plugin, but they can't persist from editor to flight (probably also on vessel load/spawn), so i gave up on that front. To elaborate : i've tried with Action Groups Extended by @Diazo to have a look into mechanics of action groups in flight scene, and while i can add actions on the fly and use them, KSP "forgets" them from SPH/VAB to vessel launch. Next, i've discovered by "type - compile - run - duck and cover" testing i can add multiple [KSPAction("somename"]) above a single function and have fully working multiple actions that persist from editor to flight scenes ! What bugs me is that i can't find out WHICH KSPAction attribute fired the function, there is no apparent link to trace back to corresponding action. Sigh... Example: [KSPAction("action one")] [KSPAction("action two")] [KSPAction("action three")] public void DoSomething(KSPAction param) { // ...stuff.. note that received "param" has only [float] Cooldown, [KSPActionGroup] group and [KSPActiontype] type, no backtracking from this } If there is a way to determine a calling action, this could save some space and simplify code. As one can guess from the above, i really would like to save up on repeating the same blocks of code (i need a lot of them for my plugin). This is me more sharing this discovery rather than me following up on this, i'll take the usual one-attribute-one-function route until this is resolved either as a failure or a success.

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.

Is BackgroundWorker safe to use in KSP mods? I'm using it to offload intensive calculations, but I need it to trigger a UI update when done, and whenever I do this by any means other than setting a bool that I check later in the main thread's Update(), the whole game crashes. Including via the RunWorkerCompleted event. https://msdn.microsoft.com/en-us/library/hybbz6ke(v=vs.110).aspx https://msdn.microsoft.com/en-us/library/system.componentmodel.backgroundworker(v=vs.110).aspx I tried logging Thread.CurrentThread.ManagedThreadId, and that seemed to confirm what I suspected, that it's running the RunWorkerCompleted handler on a background thread, sometimes the worker thread, sometimes a completely new thread: I expected each of those bold red thread IDs to be 1, since that's the thread that kicked off the worker. Are there any known tricks that will make this work the way the C# documentation says it does? People on stackoverflow are talking about SynchronizationContext.Current, which is null the very first time but non-null after that, but setting it to a new instance of SynchronizationContext doesn't change the above output at all.