Diazo

Work went sideways earlier on me today, going to be offline for the next week to 10 days. If someone wants to post their recompiled version I have no problem with it, looking at 2 weeks before I can get the official update out. D.

Version 1.6 -KSP !.3 compatibility update. Github download. Now on Spacedock also. This release gets the mod working with KSP 1.3 only, it is still on the old GUI system and does not yet support localization. As it is on the old GUI, the first time any mod (not just this one) displays a window using the old GUI, KSP will stall for 5-10 seconds. It will only do this once per session. This issue will be resolved once I can get this mod onto the new GUI system but I have no timeline for that beyond 'soon'. Also, I only spot tested actions in order to make sure the mod worked, if another mod updating broke something let me know and I'll push a fix out. Happy KSPing all. D.

To go all out and create your own GUI in the unity editor: Use the more limited built-in system similar to the older OnGUI system: I'm planning to make my own GUIs from scratch, the complexity of AGX requires it so I'm going to do it the same for all my mods. D.

KSP 1.3 Compatibiliy: No update required. Current version of this mod (3.2) works find in KSP 1.3 in my tests with no changes required. CKAN is updated and the Github download is here. This mod has also been added to Spacedock. Note that in KSP 1.3 the old GUI system still used by this mod will stall KSP for 5 to 10 seconds the first time any mod draws a window using the old GUI system KSP has to load that functionality into memory. This will no longer be an issue once I update this mod to the new GUI system. Happy KSPing all. D.

While it looks like things work on the recompile, note that I have to rework the mod to use the new ExtendedKeyCode class before I can push the official release so it will still be a day or two before that update. D.

I've run into this also as my mods are still using the old GUI system and as far as I can tell the delay is caused by the fact that the old GUI system is no longer pre-loaded in KSP, rather it is loaded the first time an OnGUI call is made and so stalls for a few seconds while everything loads from disk into memory. I am seeing the same behavior where it happens once per KSP run and behaves normally afterwards. Note that which mod displays first doesn't matter, the first use of OnGUI causes the stall and once the stall is out of the way, all mods are fine. As I intend to update to the new GUI system at some point soon, I've just posted a warning in my release notes that it happens and left it at that. D.

Version 1.32 -KSP 1.3 Compatibility update. Download from Github. Now also added to Spacedock. Still on the old GUI and localization is not implemented yet due to lack of time to work on them due to real life. There is also an issue where because this mod is still using the old GUI system, some computers freeze for several seconds the first time a window using the old GUI is made visible in the game. This should only happen once per game session the first time an old style window (from any mod) is shown on screen by KSP. Moving to the new GUI in the next version (barring any bugfix releases that come first) will resolve this so I am not going to spend any more time on it right now. Localization will also be included when the mod moves to the new GUI, but I can't offer any sort of time-line right now. Happy KSPing all. D.

CKAN updated. D.

Version 2.1 appears to be KSP Version 1.3 compatible without requiring an update/recompile. Let me know if you have any issues but I'm leaving it at that for now. Have also now uploaded this mod to Spacedock. D.

@Frank Einstein I'm not sure what is happening there. Every action is assigned to an action group, so when two vessels dock if both vessels have an action assigned to Group 3, both those actions should show in Group 3 after docking. Then after undocking each vessel should have one action in Group 3 again. This is saved on a per-part basis so I'm not sure how one of these actions could overwrite another action as you describe. However, do you mean the extra information this mod adds such as Group Name, Toggle State, Visibility, etc.? In that case it sounds like the system for saving docked sub-vessels is not behaving as expected. If you click the Next SubVessel button (the arrows in the top right corner of the main AGX window that lists selected parts) does that change anything? Also, if there are any errors in the console (Alt-F12), that would be helpful as well. D.

@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.

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.

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.

@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.

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.

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.

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.

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.

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.

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.

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.

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?

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.

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.

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.