Diazo

Members
  • Content count

    2056
  • Joined

  • Last visited

Community Reputation

891 Excellent

About Diazo

  • Rank
    ALL the Actions!

Recent Profile Visitors

4403 profile views
  1. 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.
  2. 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.
  3. 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.
  4. 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?
  5. 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.
  6. 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.
  7. 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.
  8. Not something I've seen myself, but there have been other posts on the forum about mirrored control surfaces working correctly, but animating backwards. You could test with two separately (non-mirroed) attachments and see if the behavior stays the same? No clue how to go about fixing it, but that would at least confirm it's an issue other people are seeing as well. D.
  9. I'm certainly planning to look at doing it. The catch is all my mods also need updating to the new UI still and I'm actually rewriting my oldest mod from scratch as the crazy code I keep coming across in it got to me and I can't take it anymore. So any updates on this front are going to be slow, but I'm planning to. D.
  10. That is part of the solution, yes. What is boils down to is that in my current setup the data storage is baked into the KSPAddon modules so I didn't have a separate data object I could pass to the GUI, hence having to make a middle-man data object (and the associated overhead). In my current version the GUI is actually baked into the KSPAddons also, there's a reason I'm rewriting this mod from scratch. So I was trying to find a way around that. My grand realization was the fact that I could make a Data storage class and use an instance of that inside my KSPAddon modules so I can just pass my data to the GUI without having to worry about any sort of middleman data object. I still have to write separate KSPAddon's for flight and VAB, but that has to happen anyway because the scenes are so different. D.
  11. Note that in stock, there is no relation between the state of the action group and the state of the actions in the group. When you activate (or deactivate) an action group, KSP tells all actions in that group to turn on (or off), and that's it. If the action can't do so, or if the action is in multiple action groups, you can get a situation where the action group is activated but the actions (or some of the actions) in the group are not. This is what causes the first press of the Gear button to do nothing sometimes when a vessel is first launched. It sounds like that will not be an issue for what you are right now, but if you get more involved later on (or for others finding the thread), it is something to be aware of. D.
  12. Those are actually part of the Auto-Pilot/SAS system and are used to "hold heading". It uses the available reaction wheels and RCS if enabled to hold the heading. I have made a mod called ModActions that allows assigning those hold heading commands (and several others) as actions and so can be activated by the action group system. D.
  13. Oh, that should be straight forward, just have to find where that is saved on the part. No promises on time, but it's not big deal to do.
  14. @JOHNMKNIGHT While I have no suggestions on your mod itself, could I ask you to start a thread in the Plugins sub-forum about your experiences with (and how to) localize KSP? That's something I want to look at supporting in my mods, but I don't have the faintest idea where to start and I (and probably others) would appreciate any help you could give us. D.
  15. Oh, I'm using lists all over the place in code. Lists don't really work with the UI though, you have to size the UI to handle some arbitrary number of actions and hope you guess right and the user is stuck with a scroll window if they go over that number. @fatcargo On the moving groups issue, what I'm looking at doing is swapping two groups, so all actions assigned, group name, visibility, etc. would be swapped between two groups. Note that this would not include the keybind. Due to how keybinds are tied to the keyset, not to the craft, being able to move keybinds around like that would have unintended consequences once you start changing vessels that are being controlled. D.