cakepie

[1.7.x ~ 1.3.x] Community Trait Icons - icon library for kerbal crew types [ v1.1.1 @ 2019-04-10 ]

Recommended Posts

opheader.png
Community Trait Icons
v1.1.1 @ 2019-04-10

GitHub All Releases  KSP 1.3.x thru 1.7.x

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.

BSYKJFn.png

 

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.

traiticon.png

 

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.

FP1PtYq.png

 

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.

5hnZfC5.png

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.

MoLjkqp.png

 

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

 

~ ~ ~ ~ ~

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

 

Edited by cakepie
v1.1.1 General Release

Share this post


Link to post
Share on other sites

I assume this is for 1.3 only?

regardless, great job

Share this post


Link to post
Share on other sites
1 hour ago, linuxgurugamer said:

for 1.3 only?

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)

Edited by cakepie

Share this post


Link to post
Share on other sites

@cakepie, are there any restrictions on icon size, format, etc?

Also, can you please elaborate for me on the color selection?  I'm assuming the numbers that are comma-separated are RGB, but I'm not used to seeing them in a decimal format instead of a 0-255.  

Edited by Cetera

Share this post


Link to post
Share on other sites

@Cetera are you looking to support additional crew types or just want to make/use your own customized icons/colors?

Icons can be any format that Unity supports, but dds is preferred. Icons should be square dimensions in order to avoid distortion, and in grayscale with transparency, so that they can be tinted according to the color specified in the config file. It should be fine if you vary the size, but there is really no need to go big -- the existing bundled icons are 28x28px which is quite adequate for purpose; higher resolution is pointless since the detail will be lost at the sizes that the icons are used. You can take a closer look at the bundled icons as an example.

Color is in Unity's RGBA; just divide your RGB by 255 and set the alpha to 1 (fully opaque).

HTH

Share this post


Link to post
Share on other sites
7 hours ago, cakepie said:

@Cetera are you looking to support additional crew types or just want to make/use your own customized icons/colors?

I'm working on finishing my suit pack for the TextureReplacerReplaced, and I'm doing a suit for each class in MKS.  The icons i'm putting on the suits aren't the same as what Portrait Stats/CTI uses.  I wanted to have a custom option to make them match with what I'm putting on the suits, and that necessitates futzing about and making my own icons, too.  I'm not certain that all of mine will work very well, but I'll give it a try.  I am also not using the same colors selected for the icons, so I need to modify those too.

Share this post


Link to post
Share on other sites

I'm having issues with my module manager patch to change the icons and colors in coordination with my suit pack.  When I use the MM patch, I inevitably get a blank black square in-game wherever the icons are supposed to appear.  However, if I overwrite my icons over the default icons, and then update the CTI config to correspond with the colors I'm using, everything seems to work fine.

Can you see any issues with the MM patch I'm using?

// Modifying existing config node named CommunityTraitIcons
// :NEEDS is there to stop an error in the log if CTI is not installed
// :AFTER will make sure the patch's changes occur after CTI has set up the node 
//     if there are multiple mods all using the same :AFTER clause then they will be
//     applied in alphabetic order with last one winning


@CommunityTraitIcons:NEEDS[CommunityTraitIcons]:AFTER[CommunityTraitIcons]  
{

//--- Stock --------------------------------------------------------------------

	@Trait[Pilot]  // edit the node "Trait" with content "name = Pilot"
	{
		@color = 0.588235294,0.070588235,0.031372549,1  // modify color value with new value
		@icon = Cetera/Icons/pilotIcon 					// modify path to icon with new path
	}

	@Trait[Engineer]
	{
		@color = 0.937254901,0.737254901,0.108392156,1
		@icon = Cetera/Icons/engineerIcon
	}

	@Trait[Scientist]
	{
		@color = 0.039215686,0.419607843,0.905882352,1
		@icon = Cetera/Icons/scientistIcon
	}

	
//--- Colonists! ---------------------------------------------------------------
// http://forum.kerbalspaceprogram.com/index.php?showtopic=149488

	@Trait[Colonist]
	{
		@color = 0.498039215,0.415686274,0,1
		@icon = Cetera/Icons/KolonistIcon
	}

//--- Modular Kolonization System ----------------------------------------------
// http://forum.kerbalspaceprogram.com/index.php?showtopic=154587

	@Trait[Geologist]
	{
		@color = 0.972549019,0.560784313,0.607843137,1
		@icon = Cetera/Icons/GeologistIcon
	}

	@Trait[Miner]
	{
		@color = 0.231372549,0.231372549,0.231372549,1
		@icon = Cetera/Icons/MinerIcon
	}

	@Trait[Mechanic]
	{
		@color = 0.847058823,0.521568627,0.321568627,1
		@icon = Cetera/Icons/MechanicIcon
	}

	@Trait[Technician]
	{
		@color = 0.196078431,0.690196078,1,1
		@icon = Cetera/Icons/TechnicianIcon
	}

	@Trait[Biologist]
	{
		@color = 0.149019607,0.364705882,0.137254901,1
		@icon = Cetera/Icons/BiologistIcon
	}

	@Trait[Farmer]
	{
		@color = 0.886274509,0.690196078,0.541176470,1
		@icon = Cetera/Icons/FarmerIcon
	}
	
	@Trait[Medic]
	{
		@color = 1,0,0,1
	}

	@Trait[Quartermaster]
	{
		@color = 0.129411764,0,0.498039215,1
		@icon = Cetera/Icons/QuarterIcon
	}

	@Trait[Kolonist]
	{
		@color = 0.498039215,0.415686274,0,1
		@icon = Cetera/Icons/KolonistIcon
	}

	@Trait[Scout]
	{
		@color = 0.568627450,0.317647058,0.858823529,1
		@icon = Cetera/Icons/ScoutIcon
	}
}

 

Share this post


Link to post
Share on other sites

@Cetera

MM patch looks fine. I successfully tested using a similar patch

@CommunityTraitIcons:NEEDS[CommunityTraitIcons]:AFTER[CommunityTraitIcons]
{
@Trait[Pilot]
{
@color = 0.9,0.7,0,1
@icon = CTImodTest/Icons/screwdriver
}
}

GameData/CTImodTest/Icons/screwdriver.dds is a copy of the icon normally used for the MKS technician
This replaced the usual pilot icon with another texture -- from a different mod folder, for good measure. Color change works fine too.

It's worth noting that CTI will use its own built-in error icon (and put a message in the log file) if the icon you specify in the MM patch can't be found.
Since you're reporting a black image, that would seem to suggest that KSP was able to find your texture file, but it didn't load correctly.
Maybe double check the encoding? Not sure what else would cause this behavior.

Share this post


Link to post
Share on other sites
On 11/6/2017 at 11:09 PM, cakepie said:

@Cetera

MM patch looks fine. I successfully tested using a similar patch


@CommunityTraitIcons:NEEDS[CommunityTraitIcons]:AFTER[CommunityTraitIcons]
{
@Trait[Pilot]
{
@color = 0.9,0.7,0,1
@icon = CTImodTest/Icons/screwdriver
}
}

GameData/CTImodTest/Icons/screwdriver.dds is a copy of the icon normally used for the MKS technician
This replaced the usual pilot icon with another texture -- from a different mod folder, for good measure. Color change works fine too.

It's worth noting that CTI will use its own built-in error icon (and put a message in the log file) if the icon you specify in the MM patch can't be found.
Since you're reporting a black image, that would seem to suggest that KSP was able to find your texture file, but it didn't load correctly.
Maybe double check the encoding? Not sure what else would cause this behavior.

Interesting.  The icon files as .DDS file types didn't work.  Putting in .PNG has them coming through just fine.  Did I do something wrong in the DDS conversion (not the first time) or should they always be .png?

Share this post


Link to post
Share on other sites

Most likely an issue with DDS conversion / encoding. CTI doesn't handle any texture loading/decoding by itself, it simply obtains the requested icon textures through the KSP API. So you can use whatever is supported by the base game -- CTI does not impose any requirements of its own vis-a-vis image format.

Share this post


Link to post
Share on other sites
On 11/14/2017 at 12:11 AM, cakepie said:

Most likely an issue with DDS conversion / encoding. CTI doesn't handle any texture loading/decoding by itself, it simply obtains the requested icon textures through the KSP API. So you can use whatever is supported by the base game -- CTI does not impose any requirements of its own vis-a-vis image format.

Any chance of exposing the list of traits:  traitSettings?

I'm working on updating TRP-Hire and right now am totally duplicating your code to read the traits from the file, would be nicer if I could just access your list.

Share this post


Link to post
Share on other sites
21 minutes ago, linuxgurugamer said:

Any chance of exposing the list of traits:  traitSettings?

I'm working on updating TRP-Hire and right now am totally duplicating your code to read the traits from the file, would be nicer if I could just access your list.

Are you sure this is what you want?

Note that the traitSettings dictionary is best understood as config settings for CTI -- it merely reflects crew types for which an icon+color setting is included in CommunityTraitIcons.cfg.
It is not guaranteed to be a complete or correct list of all kerbal crew types available in the user's game (including additional crew types from mods).

Two potential failure scenarios immediately come to mind:

1. If the user has installed other modded crew types that are not included in the CTI config file, there will be no corresponding entry in traitSettings.
(CTI's failsafe behavior when asked for an icon for a crew type that it does not recognize is to substitute with a built-in "unknown" setting for icon+color.)

2. If the user mangled or misconfigured the CTI config file, all bets are off -- even stock crew types could end up missing from traitSettings if they were configured incorrectly.
(e.g. a simple harmless typo of the name would still parse, but then leads to omission of that entry when the name doesn't match any available crew type.)

If you require a list of all crew types, the safe and correct way is to obtain it from KSP API's ExperienceSystemConfig.TraitNames.
Then, if you wish to obtain an icon for each available crew type, you would iterate over TraitNames, and ask CTI to getTrait() for each one.

I'm having trouble understanding what it is you're trying to accomplish + why you'd need to read CommunityTraitIcons.cfg yourself.
Maybe if you could elaborate or point me at some code and/or gui mockups?

Share this post


Link to post
Share on other sites
4 hours ago, cakepie said:

If you require a list of all crew types, the safe and correct way is to obtain it from KSP API's ExperienceSystemConfig.TraitNames.
Then, if you wish to obtain an icon for each available crew type, you would iterate over TraitNames, and ask CTI to getTrait() for each one.

I'm having trouble understanding what it is you're trying to accomplish + why you'd need to read CommunityTraitIcons.cfg yourself.
Maybe if you could elaborate or point me at some code and/or gui mockups?

Actually, since I posted that, I ended up doing exactly what you just suggested.

Thanks

Share this post


Link to post
Share on other sites
On 6/25/2017 at 8:22 AM, cakepie said:

then test CTIWrapper.CTI.Loaded to make sure it loaded the icons successfully. You can then call the other functions in the wrapper class to access the rest of the functionality.

You need to update your documentation.  If the CTI isn't installed, the CTIWrapper.CTI is null, and the statement you referenced will create a NullRef exception.

Correct syntax is

 if (CTIWrapper.CTI != null && CTIWrapper.CTI.Loaded)

Or, you could add a static function to the wrapper which would do that for you.

You can add a new mod which now uses this (if CTI is installed): 

 

Share this post


Link to post
Share on other sites
5 hours ago, linuxgurugamer said:

If the CTI isn't installed, the CTIWrapper.CTI is null, and the statement you referenced will create a NullRef exception.

Correct syntax is


 if (CTIWrapper.CTI != null && CTIWrapper.CTI.Loaded)

Or, you could add a static function to the wrapper which would do that for you.

Oh, CTIWrapper.initCTIWrapper() already returns true/false depending on whether CTI is installed or not. So it suffices if you do

if ( CTIWrapper.initCTIWrapper() && CTIWrapper.CTI.Loaded)

I can see how that's not clearly mentioned in the documentation, will fix.

Thanks!

 

Addendum: If this is a test that you perform multiple times, it may make sense to save the boolean somewhere instead of making repeated reflection calls (sample: AirlockPlus does this):

bool useCTI = false;

...

private void init() {
    useCTI = CTIWrapper.initCTIWrapper() && CTIWrapper.CTI.Loaded;
}

...

if (useCTI) {
    // do stuff
}

 

 

Edited by cakepie
add more info

Share this post


Link to post
Share on other sites

Has anyone thought about localizing this?

I got asked about it in TRP-Hire, i'm having to do local string compares to do my own localization, would be much better if the mod could do it.

I'd be happy do to the initial work, but I don't want to do it and not get it accepted.

Share this post


Link to post
Share on other sites
9 minutes ago, cakepie said:

@linuxgurugamer Localize what? CTI doesn't have any user-facing strings.

Actually, it can.  If a mod, such as TRPHire, wants to show the name of the trait somehow (TRPHire does), it can only use the trait name.  Would be nice if there was user-facing strings available.  

Maybe have a standard way to define a string, so that a localization tag can be built from the name.  Maybe I'm overreacting here, because I just had to manually put in a whole bunch of "if" statements to do the localization manually in TRPHire. But that means if a new trait showed up, then it won't be localized.

I'm thinking like this:

Where "Name" is the trait name:

 

Localization
{
	en-us
	{
		#CTI_Name = localizedName
	}
}

 

@RoverDude has a customized version of TRPHire, but either he's already done his localizations inside his mods or they aren't localized, I just don't know.

Edited by linuxgurugamer

Share this post


Link to post
Share on other sites
34 minutes ago, linuxgurugamer said:

If a mod, such as TRPHire, wants to show the name of the trait somehow (TRPHire does), it can only use the trait name.  Would be nice if there was user-facing strings available.

For that, you want the trait title (localizable for display), as opposed to the trait name (language-independent internal identifier).
Both are defined in the EXPERIENCE_TRAIT config node -- in Squad's stock Traits.cfg, as well as respective configs in other mods (1, 2) -- and available via KSP API.

Stock traits already have localized title; it is up to respective mods that define their own crew types to provide localized strings.
If a localized string for trait title is not available in the user's language, the API will just fall back on what's available (English).

Share this post


Link to post
Share on other sites
22 minutes ago, cakepie said:

For that, you want the trait title (localizable for display), as opposed to the trait name (language-independent internal identifier).
Both are defined in the EXPERIENCE_TRAIT config node -- in Squad's stock Traits.cfg, as well as respective configs in other mods (1, 2) -- and available via KSP API.

Stock traits already have localized title; it is up to respective mods that define their own crew types to provide localized strings.
If a localized string for trait title is not available in the user's language, the API will just fall back on what's available (English).

I am already using the localized title for stock traits.

And thanks, i see what I need to do now.

 

Share this post


Link to post
Share on other sites

Current version (v0.1.9) has been tested and functional in KSP 1.4.0.
Not anticipating any issues with KSP 1.4.1 either.
Let me know if you do encounter any problems.

 

For mod developers -- release plan: (paging @DMagic, @linuxgurugamer)
If things continue to look stable and no issues arise following release of KSP 1.4.1, expect a GA release (i.e. CTI v1.0). No API changes are expected. (With any luck, it'll probably just be a version number bump.)
If possible, my intent is to continue compiling against KSP 1.3, to have a single release that is compatible with KSP 1.3.0 and up.
@linuxgurugamer, you previously asked about support for even older KSP versions -- let me know if that is still a concern.

Share this post


Link to post
Share on other sites
1 hour ago, cakepie said:

@linuxgurugamer, you previously asked about support for even older KSP versions -- let me know if that is still a concern.

I did?  I really don't remember, and don't think it's necessary

From a personal preference, I prefer to have DLLs which have been recompiled against the current codebase, especially if it's compiled against the Unity DLLs, this opinion based on experience over time.

 

Share this post


Link to post
Share on other sites
This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.