Diazo

Members
  • Content count

    2064
  • Joined

  • Last visited

Community Reputation

900 Excellent

About Diazo

  • Rank
    ALL the Actions!

Recent Profile Visitors

4689 profile views
  1. @Kerbital Not in the current version, it still uses the old GUI system that doesn't offer that flexibility. I do not know exactly how the new GUI will work once I get everything moved over to it, but space concerns are certainly something I am thinking about. D.
  2. It comes back to not being sure about the order of operations thing. Way back when (KSP 0.90 days), I ran into this issue myself where the different methods were running out of order, or at least in a different order then I expected. The conclusion I came to at the time was that in the editor they ran OnStart then OnLoad, while in flight they ran OnLoad then OnStart, so I decoupled my methods so that it doesn't matter which one ran first. However, that doesn't make any logical sense but as I still decouple my methods to this day I've never actually tested what the order the methods run in on the current version of KSP. So yes, it is quite easy to get things out of order. Stick Debug.Log lines everywhere so you know exactly what is happening when is the best advice I have for you right now. D.
  3. I would add a Debug.Log line to your OnLoad() method so you can tell when it running first. I've had issues in the past where the order that Start and Load run in does not seem to be set so my guess is that things are working fine, it's just that OnStartFinished() is running before OnLoad() does so at that time the list is in fact empty. D.
  4. @Kerbital Unfortunately the stock action group system is completely blocked in, there is no simpler way to add more action groups then completely replacing the action group management system as I've done in this mod. What you want to do is possible with this mod, it's just not apparent because I didn't include modifier keys in the quick-start in the first post. I don't have any pictures to go with those text instructions at the moment, I'll see about doing that part of the full manual tonight so hopefully things make sense. D.
  5. Slapped together a quick start in the first post real quick. I'm going to actually make a full manual (probably in Google Docs) to correctly document everything, but that's going to take me a bit. D.
  6. It's a bit clunky because it uses the Action Group system rather then a dedicated interface, but ModActions allows you to control auto-strutting on a part with the action/action group keys. This is all manual though, on larger vessels it can get impractical as it gets assigned per part. D.
  7. Yikes, that's a lot of text that I can't fully parse. Unfortunately, you are way beyond where I am with fonts and so can't actually help on the issue. However I want to cast my vote as a modder who will not be including any font files. I have not looked at it yet personally, but my assumption is that by using the default GUI skin, that inherits whatever font is needed to correctly display the currently selected language is simply available for me to use without having to mess around with my own font (or font files). I would imagine most mods are going to deal with it this way as well, without kOS's terminal window that has prompted all this, it is worth the developer's time to mess around with fonts? I would expect the answer to be no for most mods, but there might be some that answer yes. (Which causes this whole issue.) My only though is somehow hooking into Font.CreateDynamicFontFromOSFont() somehow so you can render the previously loaded fonts in the same font family as a work-around, but I don't think you can do that? (Although you've shown me some pretty clever tricks before so I'm still tossing the idea out.) D.
  8. For the issue with "stock buttons separately on/off", I'm going to need more details. And I was going to link the pictures in the first post and they are all gone, what? Going to have to do something about that. Anyways, you were seeing this in a lvl 2 building where only the named action groups are available. So, on the right in the "List of actions", those are the actions that will be activated when you activate that group (highlight in green). If both the deploy/stow actions are listed, they both will try to activate. If only one is, then only that action should activate. Now, as for your second question, that is relevant here: The window with the "Group1" and "Keyset1" you are referring to is displayed by clicking the "KeySet1" button, underneath the "Alpha1" button. Note the text on it may be different as you can rename this. What those are are 5 Visibility Groups where you can show/hide action groups on vessels with a lot of actions based on phase of flight to reduce screen clutter. The 5 KeySets are different key assignments so you can setup vessels that dock together can avoid conflicts with their actions. So a mothership activates groups 1-10 on keys 1-10, while a lander that docks to it can activate groups 11-20 with keys 1-10 so that when they are docked, key1 only activates the mothership's actions. Now, for renaming an action group, you are looking for the Group Name text box, that is where you can enter what will be displayed in flight for that action group. Hope that helps, it's going to take me a few days to fix the first post which will hopefully help also. D.
  9. While it's not generic as you are asking for, this is pretty much the reason for my AGX and ModActions mods. It is in fact the reasons AGX offers 250 action groups, a couple of the larger SimPits that people talk about have several switches in them. Add in the fact that due to how KSP works, you need an action group for every switch position (even On-Off switches need two groups) you very quickly find yourself using dozens of action groups. AGX is even supposed to recognize all your HOTAS buttons so those can be used as well. Then ModActions is where I hook into the actions controlled via mouse-clicks and assign them an action that can be put into an action group. (Both stock actions such as the throttle limiter, and actions in other mods.) Ideally this allows you to control everything you want via your control board without having to ever touch the mouse. D.
  10. Ah, you're talking about the on-screen font having issues rendering characters in the Localization.Format() text string, that makes sense. I am intending to move to all TextMeshPro objects when I convert my mods over to the new GUI, but I don't have a firm timeline on that so I guess I'll find out how OnGUI handles localization. D. @HebaruSan My assumption (having not seen the code) is that Localization.Format("textString"); is the familiar ConfigNode.GetValue("textString");, just wrapped up so that it searches in the currently selected language and applies any formatting required by special characters that may be in the string. I fully expect that: string strObj = "textString" Debug.Log(Localization.Format(strObj)); To be fully valid code. And I hope there is a default as well, even something as simple as defaulting to en-us would probably be sufficient (since that is the current langauge in-game), but more options would be nice.
  11. Wait, Localization.Format() isn't returning just a basic text object of C# type string? As for the OnGUI() thing, I am moving my mods over to the new UI, but it won't be in time for the next KSP version so I'm going to have to make OnGUI and Localization work somehow to get my mods updated in a reasonable time frame. I'm specifically trying to avoid multiple languages in one file for ease of use. I want to take language A from person A and language B from person B in their own separate files and not have to worry about it. D.
  12. So, for a very basic translation: 1) Make a MyEn-US.cfg file in my mod directory. 2) Populate this file with: Localization //locked in, tells KSP localization module to process this file { en-us //locked in, tells KSP to add the below strings to the en-us localization { MyModName = Action Groups Extended //assume this will fail, no number sign as first character #autoLOCMyModName = Action Groups Extended //probably also fails? I'm assuming up to the underscore is required. #autoLOC_MyModName = Action Groups Extended //this should work, barring all the conflicts the generic name would cause. #autoLOC_AGXMyModName = Action Groups Extended //a better idea, codes this string to my mod with an AGX prefix to avoid conflicts } } Then, in code (with the using Localization; line applied): SelPartsWin = GUI.Window(673467794, SelPartsWin, SelParts, Localization.Format("#autoLOC_AGXMyModName"), AGXWinStyle); //this is a GUI Window command using the legacy GUI where I want my mod name to display That sound about right? D. edit: @nightingale For the "any format" working in the language config file, was that just for pulling the strings or for getting the Localization Auto Formatting to apply also?
  13. But how is the data stored on the disk? One thing I wanted to provide was a separate file per language so different people can do different languages without having to worry about consolidating them into one file. D.
  14. I was assuming this was the way things had to go. My basic thought was to provide an ENGLISH.lang, CHINESE.lang, etc. files in the typical configNode structure and then just load the correct string at run-time as per whatever has been set. I can't actually look at the pre-release (my KSP computer is moving houses right now), but I'm waiting until I see how to interface with Squads's localisation code before I actually proceed. D.
  15. I'm already pretty sure how I'm going to do (at lest the initial implementation) of translations in my mods. However, I'm not sure how it will handle right-to-left languages. I'm hoping Unity is smart enough that if the computers system language is set to a right-to-left language, it will also display in that format but some testing is going to be required. (I think Chinese is right-to-left?) D.