cakepie

Update Auto Actions - [Russian] [Spanish] [Chinese] [Japanese] Auto Actions - 17 Lines; ~26 Words - Needs Chinese, Japanese

For now, yes. In dev builds at the moment, want to focus on catching and ironing out any kinks (1.3) and work toward general public release. If there's a mod that wants to use this, and really needs to continue supporting 1.2.2, let me know and I'll look at it when this reaches stable (with any luck, it'd be a straightforward recompile)

0.0.9 new approach for checking if crew hatch dialog is ready for hijack add support for Community Trait Icons (CTI required) show crew type icons next to names when alighting (CTI required) add crew type icons to stock crew hatch dialog perfectionistic layout tweaking

Community Trait Icons v1.1.1 @ 2019-04-10 Community Trait Icons provides a configurable set of icons for displaying each of the kerbal crew types (aka "experience trait") as a simple icon. It comes with a lightweight plugin, through which other mods can fetch these icons and utilize them to serve up a common and consistent user interface for players. Icon settings for each crew type are defined in a config file, customizable by the user and patchable using Module Manager. Besides the stock crew types (pilot, engineer, scientist, and tourist), icons are also included for mod crew types defined by Modular Kolonization System and Colonists! mods. Support for additional crew types can be added by creating the corresponding definitions, specifying a custom icon and color. ~ ~ ~ ~ ~ For Players Community Trait Icons doesn't do anything by itself, you will also need to install one or more of the following mods that makes use of the icons for them to show up in the game. If you wish to customize the icons or colors used by Community Trait Icons, please refer to this guide. Portrait Stats Displays the type and level of each vessel crew member using icons in each crew portrait in the lower-right corner during flight. Also includes additional options for showing the information without needing to hover over the portrait, extra info in the tooltip, highlighting the current part when hovering over the portrait, and adding a crew transfer button to the portrait. AirlockPlus Provides enhancements to airlock behavior, allowing the use of any airlock to board into / alight from any part of the vessel without the need for crew transfers. Displays the crew type of each kerbal using an icon beside their name when choosing which kerbal to take on EVA. Also augments the stock crew hatch dialog with icons. IndicatorLights Adds small colored "LED indicators" to many parts to convey their status and other information. On crewable modules, LEDs are color-coded according to types of crew on board. Kerbal Construction Time Makes vessels take time to build rather than being able to constantly launch new vessels one after another. Icons used to display crew type in crew selection screen. TRP-Hire Allows you to specify the gender, stats, crew type and experience level of kerbals that you wish to hire, rather than having to picking from a pool of applicants. Icons help to indicate the crew type to be hired in the astronaut complex. Others Watch this space! * If your mod uses Community Trait Icons, do let me know so that it can be added to this list! ~ ~ ~ ~ ~ For Modders Making a mod that uses CTI icons Obtaining a Kerbal's specialization class type ⚠️ details gotchas arising from bugs in the KSP API Adding icons for custom crew types defined by your mod ~ ~ ~ ~ ~ Acknowledgements Community Trait Icons is a spinoff of Portrait Stats by @DMagic, including contributions from @PhantomC3PO and @Aelfhe1m. ~ ~ ~ ~ ~ License The Community Trait Icons plugin is released under the MIT License. Stock trait type icons are from the IonIcons library, licensed under the MIT License. Additional icons by @PhantomC3PO are licensed under CC BY-NC-SA 4.0. ~ ~ ~ ~ ~ Download Community Trait Icons v1.1.1 for KSP 1.7.x (backward compatible with KSP 1.6.x - 1.3.x) Installation: Delete older version, if any. Place contents of GameData into your installation's GameData folder. Source: GitHub Changelog: v1.1.1 ~ 2019-04-10 ~ KSP 1.7.x - 1.3.x General Release - Recompiled for KSP 1.7.x; backward compatibility tested for 1.6.x thru 1.3.x v1.1.0 ~ 2019-04-07 ~ KSP 1.6.x - 1.3.x General Release - Add handling for GameDatabase reloading; other internal refactoring. - Functionality unchanged, contract with downstream mods unaffected. - Compiled for KSP 1.6.x; backward compatibility tested for 1.5.x thru 1.3.x v1.0.2 ~ 2019-02-02 ~ KSP 1.6.x - 1.3.x General Release - Recompiled for KSP 1.6.x; backward compatibility tested for 1.5.x thru 1.3.x v1.0.1 ~ 2018-10-20 ~ KSP 1.5.x / 1.4.x / 1.3.x General Release - Recompiled for KSP 1.5.x; backward compatibility tested for 1.4.x and 1.3.x v1.0 ~ 2018-03-14 ~ KSP 1.4.x / 1.3.x General Release v0.1.9 ~ 2018-02-15 ~ KSP 1.3.x Release Candidate - Tint icon textures upon loading: All downstream mods will now receive tinted icons, instead of only those that permit KSP's DialogGUIBase.tint or Unity's Image.color v0.1.2 ~ 2017-06-25 ~ KSP 1.3 Dev Build - new icon generation option: UI.Image component v0.1.1 ~ 2017-06-23 ~ KSP 1.3 Dev Build - new icon generation option: GameObject v0.1.0 ~ 2017-06-22 ~ KSP 1.3 Initial Dev Build

Teaser for next version.

https://github.com/ihsoft/KAS/releases/tag/0.6.3

@Physics Student It's not the first time this has been requested / attempted, so you could look into what has been done before. Here is discussion about another mod that implemented it similar to what you did. Here is another discussion, that leads to... Here is the dev thread of an abandoned mod that managed to get quite far with the concept. Some implementation pitfalls discussed here by the mod author. The github is here, but unfortunately the license (as per dev thread) is ARR, which means you can't reuse or derive from it. You'll likely need custom code to get the "correct" behavior. Edit: there's also another approach for "I want a customizable amount of solid fuel but I don't like using tweakables because of wasted empty space in the tank" -- procedurally generated parts. Lineage: StretchySRB -> Procedural Parts (swamp_ig) -> Procedural Parts (OtherBarry) -> Procedural Parts (Starwaster)

You might want to be really careful with changing flow modes here. Suppose I take that craft in your picture, and insert another part (not a fuel tank, but crossfeed capable) between that T-200 and the Flea SRB. - Does the Flea SRB still draw fuel from the T-200? - Is that what you want?

That's most likely just the stock window taking much longer than expected to set itself up. The process doesn't seem to be consistent, so I have AirlockPlus set up to wait five frames before attempting to overwrite the stock window. This was based on some trial-and-error plus some extra buffer, and worked well before, but yours is sometimes taking even longer than that, for whatever reason (OS, system spec, settings, etc...). When that happens, you'd actually end up with the stock window overwriting AirlockPlus instead. Try this patch (link removed). It doubles the wait time to ten frames -- this means that when you rightshift+click on a crew hatch, there will likely be a noticeable delay before the AirlockPlus interface shows up (you may see the stock window in the meantime). Let me know if this fixes the alighting issue. Also, there's some additional debug+instrumentation code in there to measure how long your stock window is taking to set up, so if you could do the rightshift+click a few times and get me the debug log from that would be informative toward trying to find a more permanent solution. I've also included in the patch a different version of CLSInterfaces.dll (CRC-32: CAEF1E65) than is packaged with the v.0.0.8 download (CRC-32: E4A14243). That should hopefully take care of the problems you reported with boarding in your modded install a couple of posts up. Let me know how it goes.

AirlockPlus solves this by letting you take kerbals on EVA using any airlock on the craft, without requiring that the kerbal be in the airlock part itself. Conversely, from EVA, you can board directly into any crewable part of the craft, not just the airlock part. Transfer crew not needed!

ping @Teilnehmer -- two PRs in github: besides @fitiales work with Spanish I've also taken a shot at ja and zh-cn.

Yeah, looks like either a linux-specific issue or possible mod interaction, or possibly a mix of both. There seems to be a lot going on here, with each AirlockPlus feature working in some situations and broken at other times. So, I'm going to need your help to try to isolate and troubleshoot each case individually. Let's start with pure stock + AirlockPlus, and isolate any OS-specific issue without any other mods interfering. For boarding, you mentioned: It does sound like you initially had the two boarding modes confused. To make sure everything is working as it should, in a controlled environment, can you please re-confirm following the steps given below. This test case is engineered so that stock boarding cannot succeed -- and thus will not be mistaken for AirlockPlus functionality. For alighting, you said: This indicates to me that AirlockPlus has correctly obtained the keymapping from your game settings. So, yes, since you are using linux and this is in your logfile, then you should be using RightShift+click (not LeftAlt+click) for alighting features. You also mentioned But it's not clear what happened in with only stock+AirlockPlus. Was it working, or did it not work because you didn't use right shift the first time, or did it not work for some other reason? It would be incredibly peculiar if it was working with other mods installed, but not in a stock-only situation. Continuing with the test craft as above, please try the following: Let me know how each test goes. Please provide the whole log if anything isn't working correctly. I'm not only looking for error messages -- the presence/absence of certain expected messages can be informative as well. We'll look further into mod interactions after sorting the basics out. One quick thing, though -- were you using CLS, and if yes, which specific version?

1. Ensure you're making the correct keyboard inputs: For shift+B, you need to hold down left shift while pressing B. Do not release shift until after releasing B. Likewise for ctrl+B: hold down left shift until after releasing B. 2. You reported that boarding doesn't work; it would be useful to know if alighting is working or not. Try clicking on a crew hatch (same as when you normally do a crew transfer) but while holding down the left alt button (if you're using windows) 3a. Does it work if it is the only mod installed, or do you still encounter this issue 3b. I would need to know what other mods you are using in order to investigate if this is a case of interaction with another mod. 4. logs, please.

Well, Nertea's stuff just updated, so there you go. Even if you don't update now, AirlockPlus will still be here whenever you're ready to make the move to 1.3. Unless there's a very good reason / high demand for it, I'm not really keen to backport AirlockPlus for 1.2.2 compatibility -- it adds logistical and support overhead, plus I'd actually have to go back into the code and remove features: localization requires KSP 1.3, and CLS support requires CLS 1.2.5.2+ (KSP 1.3). That's time and effort which I would rather spend on building new features. I made AirlockPlus primarily for Hawkspeed Airstairs -- because not having to transfer kerbals one by one in order to use the stairs makes a really huge difference there. I believe MKS has some airlock parts for bases which would also benefit from the convenience provided by AirlockPlus. Dedicated airlock parts are rather rare since it's somewhat of a convention for all crewable parts to have their own airlocks -- it's a sort of holdover from way back when KSP didn't even have crew transfer. So in the current state of gameplay, it's common to have many airlocks all over the place on one craft / base, even if that's not exactly reasonable or realistic. With AirlockPlus, I'm hoping to enable a shift away from this paradigm, toward separation of crew capacity and airlock functionality.

@IgorZ We've discussed conditional stackability for KIS before, but if it's not looking likely that it'll be implemented in the short term, then I'd like to make some progress on fixing the collapsible cardboard box part of Surface Experiment Pack with whatever means are currently available. The intended behavior of the cardboard box is as follows: It starts "deployed"/"assembled", which means that it has ModuleKISInventory (so other parts can be put into it) and ModuleKISItem (to make it carriable like the KIS SC-62). In this state, ModuleKISItem will specify that it is not stackable, and give a volumeOverride that corresponds to a solid box. If the inventory is empty (and has no custom name), then it can be "flattened"/"collapsed" by a EVA kerbal. ModuleKISInventory will be disabled on the part, and ModuleKISItem will be modified to specify that the part is stackable. volumeOverride will changed to correspond to a flat piece of cardboard (to save space when stored in inventory). This can be reversed, i.e. a flattened box can be "deployed"/"assembled" back into a usable container by a EVA kerbal. Currently, the plan is to implement "flatten" and "assemble" as KSPEvent in a separate PartModule (ModuleSEPBox): include some safety checks: ensure KIS is installed -- SEP already has KIS as a dependency, should not be a problem the part must also have ModuleKISInventory and ModuleKISItem -- already in the part config enable/disable ModuleKISInventory using part.Modules.GetModule<ModuleKISInventory>().enabled ModuleKISItem.stackable and ModuleKISItem.volumeOverride are public, can be accessed/modified via part.Modules.GetModule<ModuleKISItem>() But it appears that some changes in KIS code would also be needed in order to support the desired functionality. Presently, KIS seems to operate on the premise that ModuleKISItem fields do not change at runtime. When creating a KIS_Item (from scene, from save, or by splitting a stack) these all ultimately result in a call to KIS_Item.InitConfig(), which actually obtains the ModuleKISItem fields (e.g. stackability) from the part prefab. Likewise, part volume calculation uses the volumeOverride value from the part prefab if it is present. Hence, the main set of changes needed is to make it such that KIS will instead uses the runtime values in ModuleKISItem: when creating KIS_Item from scene, try to obtain ModuleKISItem from the part instance itself first, before fall back on the part prefab if that fails when creating KIS_Item from save, either: ("hard" way) check if ITEM node has a PART node with MODULE node for ModuleKISItem, try to parse that first, before fall back on the part prefab, OR ("lazy" way) serialize KIS_Item.stackable, KIS_Item.volume, etc in KIS_Item.OnSave; load those instead of getting from scratch from prefab when creating KIS_Item due to stack splitting, copy existing KIS_Item fields instead of building new KIS_Item from scratch from prefab A secondary change is needed when attempting to stack, so that *both* the existing item in inventory slot and the item/part being dropped into the slot are checked to ensure that they are stackable -- this is needed to prevent a "deployed" box from being added to a stack of "flattened" boxes. Does this plan look correct / reasonable? Let me know if I've missed something. If it all looks fine, then with your permission, I can proceed to make the changes and submit a PR for your perusal.

This list is for modder tools and WIP / in-development mods, not dead mods. I think what you're trying to get at is that Maritime Pack (new thread) is already on the Release list and the outdated link to old dev thread should therefore be removed from here.

@ruiluth I used to continue providing a download for AirlockPlus 0.0.5 (the last version made for 1.2.2), but I've taken it down because it contains a major bug that's been fixed in 0.0.8. What mods are you playing with that haven't been updated -- that holds you back from upgrading to KSP 1.3?

I'm wondering if makes sense to selectively load localized strings depending on whether another mod is installed or not. Or would that be pointless/unnecessary? Something like this: // stock sciencedefs localization Localization { tag = mymod_sciencedefs_loc en-us { // lots of localized strings -- science definitions for stock celestial bodies } } // support OPM if installed, otherwise don't load these @Localization[*,mymod_sciencedefs_loc]:NEEDS[OPM] { @en-us { // lots of localized strings -- science definitions for OPM celestial bodies } }

I've had some success generating the dictionary file by: Pull the key = value pairs of interest out of cfg files using regexes. I use notepad++, but grep should work as well. It's a good idea to extract the part name as well, so you can generate locIDs from it. Plonk into a spreadsheet (column A). Using spreadsheet formulae, split into key (col B) and value (col D). Generate localization IDs (colC) -- I like #LOC_modname_partname_key and #LOC_modname_partname_partmodule_key Copying cols C+D to a text file gives the meat of dictionary file. Cols B+C gives the mappings that need to go back into the part cfgs <-- I don't have a clever solution for this, though.

Not tested to verify, but I believe this will work, albeit you will always get the "default" messages only.

Russian localization is now complete thanks to @KerbOrbiter AirlockPlus.localization.0.0.8.zip updated without bumping version number.

Updated localization status for AirlockPlus: complete Spanish, Chinese and Japanese; partial Russian. New link to localization resources now that project is on github. Airlock Plus - [Russian] [Spanish] [Chinese] [Japanese] Airlock Plus - 8 lines; ~25-30 words - all stock-supported languages done! Other languages welcome. Edit: Russian done, thanks to @KerbOrbiter

0.0.8 Fixed spurious "hatch obstructed" bug Japanese localization fixes (thanks @EBOSHI!) Russian typo fix (thanks @Teilnehmer)

Here you go: 1 #autoLOC_217936 = <b>Thruster Power: </b><<1>>\n #autoLOC_217937 = <b>Thruster Isp: </b><<1>> (ASL) - <<2>> (Vac)\n #autoLOC_217939 = \n<color=#99ff00ff><b>Requires:</b></color>\n Label for fuel consumption; probably ModuleEngines.GetInfo() Translations: ES: requires JA: fuel consumption RU: consumption ZH: consumption 2/3 #autoLOC_244332 = Requires: #autoLOC_244333 = Outputs: #autoLOC_244335 = Requires: #autoLOC_244339 = Outputs: Input (consumption) rates, probably BaseConverter and ModuleResourceConverter Translations: ES: requires JA: requirements (lit: necessary conditions) RU: requires ZH: consumption 4 #autoLOC_469075 = Requires Any: #autoLOC_469079 = Requires All: #autoLOC_469084 = Requires: #autoLOC_469091 = Requires Nothing: #autoLOC_469120 = Research [<<1>>] #autoLOC_469953 = Researched Probably the tech tree GUI? Translations: ES: requires JA: requirements (lit: necessary conditions) RU: requires study [ 469075: Requires study of one technology ] ZH: requirements General tips for future: - inspect surrounding context in the dictionary file, look at what other nearby strings are - look at other language dictionary files, even if you don't read that language, it helps to try running the strings through google translate

- open the destination container's inventory window - make sure your kerbal has tool equipped to detach the part (if necessary) - hold down G button on keyboard, cursor should be hand, with tooltip "Grab" - click on the part you want to store, do not release mouse button (you can release G button on keyboard) - as long as you are holding down the mouse button, part should show as an icon, not a hologram - while continuing to hold down the mouse button, drag the part icon into the container inventory window - release mouse button when over empty slot to store the part