TRR Config Structure Discussion

[Sigma88]

before I start working on the config structure I'd like to get a feel of what developers and users need / want

so let's discuss here

my current idea is a config structure like this:

TextureReplacerReplaced
{
    Folders
    {
        Default = 
        EnvMap = 
        Heads = 
        Suits = 
    }
    ReplaceByName
    {
        Texture
        {
            name = 
            newTexture = 
        }
    }
}

the idea is that, the "Folders" node will contains a list of folders from which TRR loads the textures.

so if your mod used to put head textures in the "TextureReplacer/Heads" folder, now you just need to move them into a custom folder (let's say KSPINSTALL/GameData/MyMod/MyTextures)

and add a cfg with the following content:

TextureReplacerReplaced
{
    Folders
    {
        Heads = MyMod/MyTextures
    }
}

[HaArLiNsH]

sounds great !

My goal for the folder structure itself would be something like this : http://i.imgur.com/2QZOOc5.png

So this looks like you propose. If a mod use head textures, it will goes like this : KSPINSTALL/Gamedata/MyMod/Textures/Heads/

and inside this we put the head textures and the MM.cfg

This way, if we have a mod with already different folders and stuff, they just have to make a folder called Textures and put in this folder the subfolders for the kind of texture he want to use and the MM.cfg needed for it. (so the legacy ones from TR and a new one called CustomTextures for all the texture that don't goes in the old categories, basically your idea to replace others textures)

I have no experience on MM setting itself, so I let more used developer say what they want for this :)

[Sigma88]

ok, so...

I managed to implement the new syntax for Default, EnvMap, Heads, and KeepLoaded

what remains is "Suits"

this is a more complicated situation since I would like to define suits so that TRR can automatically assign them to the selected classes

What makes the most sense to me is to use a config structure like this:

(I'm still optimizing it but this is the general idea)

TextureReplacerReplaced
{
    Suits
    {
        Suit
        {
            name = StandardEngineer1
            class = Engineer
            gender = Unisex
            veteran = False
            badSS = False
            level = 0
            folder = MyMod/MySuits/White/
        }
        Suit
        {
            name = VeteranFemalePilot4
            class = Pilot
            gender = Female
            veteran = True
            badSS = False
            level = 3
            folder = MyMod/MySuits/Orange/
        }
        Suit
        {
            name = BadassMaleScientist5
            class = Scientist
            gender = Male
            veteran = False
            badSS = True
            level = 4
            folder = MyMod/MySuits/Blue/
        }
    }
}

[HaArLiNsH]

I think the veteran and badSS are the same thing so we only need the veteran state. (Or the badSS is just the fearless status witch don't matter for the suits)

The suits don't really need a lvl config because the level is made with the name of the textures itself (kerbalMainGrey, kerbalMainGrey1, kerbalMainGrey2 , ...).

I also wanted to drop the actual female suit system. I mean for now a suit pack is designed to be male or female, so if I want a pilot suit I need to make 2 suit packs with a lot of textures files in double (and no female suit pack were ever made) My idea for the female is to create 3 new suits files (IVA, EVA ground & EVA space) for the female in the same folder than the male and just make a check to see if the kerbal is a female and use these textures. If the kerbal is a male or there is no specific female texture, it will use the male texture.
This should only affect the suits and not the helmet, jetpack and visor so we can save memory. The female suit is a bit warped in comparison of the male but not the others textures.

I just have a question about defining the class of the suit pack in the config file : What happen if we have multiple suits pack configured on the same class? Will it use the first or last loaded ?

We also need a config to specify the use of a suit pack for only one kerbal and not the others. This way if we have for example a Santa Claus suit, we can assign it to only our Santa Claus kerbal.

Anyway great work so far ! :)

[Sigma88]

I think the veteran and badSS are the same thing so we only need the veteran state. (Or the badSS is just the fearless status witch don't matter for the suits)

veteran and badSS are not the same

Jeb, Bill, Bob and Val are all veterans

but only Jeb and Val are basSS

The suits don't really need a lvl config because the level is made with the name of the textures itself (kerbalMainGrey, kerbalMainGrey1, kerbalMainGrey2 , ...).

using the name could be fine, but not using the name would allow for extra compatibility which is something I always like :)

I also wanted to drop the actual female suit system. I mean for now a suit pack is designed to be male or female, so if I want a pilot suit I need to make 2 suit packs with a lot of textures files in double (and no female suit pack were ever made) My idea for the female is to create 3 new suits files (IVA, EVA ground & EVA space) for the female in the same folder than the male and just make a check to see if the kerbal is a female and use these textures. If the kerbal is a male or there is no specific female texture, it will use the male texture.

That's why I added the "gender = Unisex" tag. I expect most suit packs to use that, but again.. having more options is always welcome :)

I just have a question about defining the class of the suit pack in the config file : What happen if we have multiple suits pack configured on the same class? Will it use the first or last loaded ?

I have still to define that part, I was thinking... load all suits and assign one at random (like the heads) maybe. Or "load the first" could be an option as well. Depending on what we decide suit packs will adapt using MM patches to get the desired result

We also need a config to specify the use of a suit pack for only one kerbal and not the others. This way if we have for example a Santa Claus suit, we can assign it to only our Santa Claus kerbal.

I will add that as well

[HaArLiNsH]

Ok so the badSS = fearless :) We could have a option for this but the problem is that kerbal can have it with or without the veteran status and I don't know (yet) how we could see that difference on the suits . I'm not sure about making a veteran suit pack+ a veteran fearless suit pack+ a normal suit pack + a normal fearless suit pack :) My suggestion is to ignore the fearless (badSS) status because it only change the behaviour of the kerbal head expressions while in flight.

I'm ok for the level option if we can have the forced suit level by configuration file and the classic level suit by texture name coexist together (so for example if no option in the cfg file, goes for the classic level by name of the texture)

For the gender suit, we could have a male, female and unisex , but "unisex" is not a good term because it don't tell "use both male and female", unisex suit is what we have now, I mean one suit for both sex :) Maybe something like "multiSex" or "genderChosen" So we could have male, female, unisex, multisex :)

[Sigma88]

I'm not sure about making a veteran suit pack+ a veteran fearless suit pack+ a normal suit pack + a normal fearless suit pack :) My suggestion is to ignore the fearless (badSS) status because it only change the behaviour of the kerbal head expressions while in flight.

you don't necessarily need to use it, we add a "Suit" class in TRR right?

we can make it so that at loading a database of suits is created, each with parameters set (like badSS, vetera, gender, etc...)

then when we assign a suit to a certain kerbal, we just pick the one with most attributes in common with the kerbal

of course we will need to set up some priorities, like "a non-Veteran will never get acces to suits that have veteran = true"

I think kerbals with badSS = true are always veterans... but we can decide how to set up the priorities how it works best for us.

the point is that if someone crazy wants to have a gazillion suits one for every combination possible, he should be able to do so.

most people probably won't, but this system would not harm those :)

[Sigma88]

For the gender suit, we could have a male, female and unisex , but "unisex" is not a good term because it don't tell "use both male and female", unisex suit is what we have now, I mean one suit for both sex :) Maybe something like "multiSex" or "genderChosen" So we could have male, female, unisex, multisex :)

Unisex literally means \<\> xD

so what I have in mind would be to have a database of textures

when we want to assign a certain suit to a certain kerbal, we first read the parameters of the kerbal, then we filter the suit database using those parameters and we get a list of textures that are suitable (pun intended) for that specific kerbal.

finally, we pick one at random from that list and assign that specific suit to that specific kerbal, like we do for the heads

we might want to trigger the code to reassign the suit in specific occasions, like level changes, important milestones or stuff like that

we could also save the textures in an array ( Texture2D[6] ) rather than in a single object ( Texture2D ) so that we can have all the levels stored in the same "Suit" object

[HaArLiNsH]

Alright, so the good term for my idea would be "monosex" (I just had a big argue with my wife on this subject while searching for a good term) :)

I'll rewrite my answer from the forum here, its for the conversation :

In Personaliser.cs, if you look in the section :

/* ============================================================

• personal suit options
• used for each suit texture pack
• ========================================================= */

You will find a lot of options I'm actually working on to add to the suit sets. My aim is to have 2 type of options, one general for TRR like we have now and one for each suit set. Before my comment frenzy for a better understanding of the mod, I was looking at how do we make a window in ksp/unity :) .

The idea is that the TRR_EvaModule.toggleEvaSuit() and TRR_EvaModule.Update() handle the different suit states like the general option indicate (so usually the basic IVA without helmet -> EVA ground with helmet -> EVA space with helmet) and then we personalize the output with the option for the suit set.

The aim was to put these options in the same .cfg as we use to move the folder from TRR and if there is nothing use the default ones that you can find in the code. I think this goes in the same direction of your proposal.

I've added these options for the gender,exclusiveness, veterans and badass (and you will also find a shit load of others option I want to implement) :

/// <summary>
    /// Do the suit set is made to be used by the Veteran kerbals?
    /// </summary>
    public bool isMadeforveteran = false;

    /// <summary>
    /// Do the suit set include the veteran version for the suit ?
    /// </summary>
    public bool includeVeteran = false;

    /// <summary>
    /// Do the suit set is made to be used by the Badass(fearless) kerbals  ?
    /// </summary>
    public bool isMadeForBadass = false;

    /// <summary>
    /// Do the suit set include the Badass version for the suit ?
    /// </summary>
    public bool includeBadass = false;

    /// <summary>
    /// Do the suit set include the veteran badass version for the suit ?
    /// </summary>
    public bool includeVeteranBadass = false;

    /// <summary>
    /// Do the suit set use the male version of the suits ? 
    /// </summary>
    public bool UseMaleSuitenabled = true;

    /// <summary>
    /// Do the suit set use the female version of the suits ? 
    /// </summary>
    public bool UseFemaleSuitenabled = true;

    /// <summary>
    /// Is this suit set exclusive to his configured class? 
    /// </summary>
    public bool isSuitExclusive_Class = true;

    /// <summary>
    /// Is this suit set exclusive to his configured kerbal? 
    /// </summary>
    public bool isSuitExclusive_Kerbal = false;

This way the full suit set should include the male & female IVA, EVAground, EVAspace suits and their respective normal, veteran, badass(fearless), veteran+badass version of the suits.

Or we can force it by configuration :)

Now, the textures are saved in both a single object and in a array. I think this was made at first because the method "setTexture()" only loaded non levelled texture and then the level was added after. Setting textures in a single array could indeed simplify the system. I was actually looking at that while adding the missing textures (the visorsNRM and some others)

One thing to note about using only array of texture2D, for now only the visors and helmets use level normal map texture (mostly for memory saving), we should make a level version for all the NRM if we want to make a real full option suit set but this will require a shit load of new texures, like you can seet in the TRR_guide that it need already 55 files, expect that this number will double.. damn now I want this off course.. I will never finish my suit pack :)

You can see this on the "new_suit_texture" branch

[HaArLiNsH]

When I see the huge amount of options possible/needed for each suit set, I think we need a new filter class or something like that :)

[HaArLiNsH]

I will make the new textures that we will need (females suits, NRM, and so on) tomorrow (or asap) so we can test the system. We can always rename or move them if the functions/system changes. I'll also make a .dds version of them.

[Sigma88]

I think you made it overly complicated, there are so many options that many are redundant

I am starting to laying down the code for my idea, you can take a look, compare it with yours and from there decide what you like and want to keep.

I have a question about IVA and EVA suits...

are they basically the same suit but with different inner workings, or are they completely different (like, IVA could be blue and EVA could be white) ?

[HaArLiNsH]

Yeah I know there is maybe a bit too much options and some could be merged in a 3 state check like: "Do we use the male/female suit?" -auto -only male -only female

This is just the layout of my idea.

Do your stuff and we'll combine our ideas and this will be good :)

For the IVA, EVA states question (sry wall of text) :

They are not the same suit in term of Texture2D saved in memory/database (the Suit class) and textures files (the .dds or .png). All the suit, helmet, jetpack, visor and their normal map are a different file. And we load/apply the right one for the scene in something that is basically the "this is the actual suit set". The default suits (the basic ones from squad) are the one with the unpractical names like "kerbalMain" for what I've called "ivaSuit_Veteran_Male". You can see the full list in the setTexture() Method (or function, I don't know how to call it), they are the textures with a double "case" choice. We need to use these default names when we use them in the default folder.

I changed the name of the states when I added the new one, so now they are like this : -IVA (no change) -EVA ground (the new state) -EVA space (the old EVA state)

Each suit state need his helmet, visor, jetpack and their normal map. (exept the IVA don't have the jetpack) And this is also the case for the level, so each suit states need also all the level state (basically, all these files X 6 ). This could lead us to a little more than a hundred file for a full suit set now with a NRM at each level.

The system makes a database of all the textures files in each suit set (the Suit class) and we call the right one at each update() of the game , or when we enter/get out of a vehicle, or when we push the "toggle suit" button. If there is no texture for the asked configuration, like if our kerbal is level 4 but we only have a level 3 texture saved in the database, it load the last used , in this case the level 3 suit. This way modder aren't obliged to make all the suit textures if they don't want.

I never saw a full suit pack and that was the first idea why I started my suit pack :)

The old suit packs had to make a suit pack for the veteran classes (so one normal pilot, one veteran pilot) and one for the female (never happened). The female suit don't have the same texture mapping than the male and the female kerbal has also others problems like no tong or teeth so they fixed it by applying the eyeball texture on them (so yes for now the teeth texture is broken for all the kerball, you can see that with my head texture in the TRR_guide. The badass and veteran badass sates didn't existed until now. I'm not sure about them but they are a configuration that exist so we should consider them.

My aim is to merge the veteran & female in the same suit set, this way you only have to configure it once for the class independently of the gender or the veteran status (witch is what you propose with the class option in the .cfg). And merging the female allow us to re-use the texture for the helmet,visor and jetpack from the male, we spare 16 textures files in total :)

With the options, you can use a classical suit set (without the female or male and without the veteran) and assign it to only veteran for male and use another to only veteran female or other "out of the box" combinations.

All the option have a purpose if you think of them at particular situations that were impossible to do until now, like using a suit set for another race of kerbal. for example they could need to use helmet on atmospheric planets and be without helmet in space. This could open possibilities to others modders. I'm thinking at the armory mod for example. Off course it would need a suit set made for it. These option could be also useful when you create the suit set (to force certain state when you are in a "debug mode") or to make unique kerbal. Or use the same suit set but configure it to use different settings for variety. You got the idea, a shit load of option in a little window that you open with a option button on the main GUI So you can use the suit sets as you like.

Sorry for the wall of text, I tried to explain the best I could :)

[Sigma88]

I had time to look at your setup and I think you are trying to have too much stuff in the same place.

from what I can see you are trying to make a "Suit Set" that includes everything from IVA to EVA, both veteran and non-veteran etc...

I'm not sure why this would be helpful here, but it's totally possible I am missing something.

anyways, since I couldn't wrap my head around all that stuff I started laying out a simpler basic system that can be improved later on depending on the needs.

this is more or less a scheme of what I was thinking:

1) KSP starts, loads the assets, then TRR starts

this part is already working, no need to discuss

2) TRR creates a database of "Suit" objects reading the configuration files provided by users

      2.a) Suits

in my idea "Suit" objects are simpler that your Personaliser.Suit A Suit object contains these informations:

• name (the name of the suit)
• type (the type of suit, IVA or EVA)
• gender (which genders can wear the suit, male, female or both)
• veteran (has to match the kerbal's veteran status)
• BadSS (has to match the kerbal's BadSS status)
• texture (array of up to 6 Texture2D, one for each level (0-5 stars))
• normal (array of up to 6 Texture2D, one for each level (0-5 stars))

I decided to start laying out the foundation of the system and for now I will be ignoring Helmet, Visor and Jetpack. Decisions have to be made about those objects, do we want each suit to have a predefined combination of Helmet, Visor and Jetpack? or do we want to allow customizeable combinations of Suit/Helmet/Visor/Jetpack ? (I will just skip all this for now and focus on the suits themselves)

      2.a) Suits Database

for each suit defined in the cfgs TRR will create a Suit object and add it to a List\

3) when necessary, TRR assigns a suit to the Kerbal

whenever a kerbal needs a suit, TRR will look through the suits database for a suit that fits that kerbal and assigns that suit to that kerbal. if there is more than one suit available, TRR will pick one at random (like we do for the faces) if there is no suit available, TRR will broaden the search to include more suits (rules on how to broaden the search will need to be defined)

---

As I said before I don't see the usefulness of storing both EVA/IVA in the same object, plus male and female, veteran and non-veteran. it's not like there is any link between those suits. you can consider them completely different suits as far as I know.

I wanted to finish this yesterday but it took me too much to understand what was going on in the Personaliser.cs and I didn't manage to write the code for all this.

I should be able to have a rough version ready tonight (CEST)

[HaArLiNsH]

I agree that the Personaliser class is a bit long, I did not write it, this was like this since a long time in TR. I've just added the new EVA ground state and the changed the logic in the to switch the 3 states. (there is still 2 functions called personaliseEvaLegacy and personaliseKerbalLegacy that are the old functions and they should disappear)

We NEED to include the helmet, jetpack and visor (and their NRM + level) for each state in the Suit class. As I said, all of them are really important, you can't skip them. I know this lead to a lot of texture files but we can't avoid it. Its not like we have a pbr system where we could just change the color of certain zone in the model. This is "old" tech :)

We also need to include the 3 states (IVA,EVAground,EVAspace) in the suit set, otherwise how will you do when you change the suit when you go on EVA (or you click the "switch suit" button) ?

The veteran could go out of the suit set, like it was before, but this mean that we need to pick another suit set when the kerbal is a veteran witch I wanted to change.

The female version of the suit should also be included, as I said, doing this spare us the helmet, visor, jetpack and their NRM +level. We spare 16 textures X6 levels so a total of 96 texture files per suit class (multiply this by the number of class we need, 4 in normal KSP + 3 veteran or 14 + 3 veteran for MKS)

The badass statut is the more useless for me. I'm not sure we need this for the suits as it only change the reaction of your kerbal when under pressure on flight (smile or fear).

There is a link between all these IVA, EVAground, EVAspace suits and they are related to the KerbalData of your kerbal. In this kerbalData you store the suit set and the other informations of a particular kerbal.

Anyway, I know that this Personaliser need attention but don't throw the baby with the bathwater, we don't need to rewrite all the system :)

Did you looked at the TRR_guide to see an example of a (nearly) full suit set ? https://github.com/HaArLiNsH/TRR_Guide/releases

[HaArLiNsH]

I'll update the TRR_guide today to include the missing texture, so you can see what what I'm talking about :) We have nearly the same idea, we just need to find the good spot between the 2 ideas.

[Sigma88]

I'll reply point per point while I'm reading your post, so bear with me if the comment gets edited multiple time :D

We NEED to include the helmet, jetpack and visor (and their NRM + level) for each state in the Suit class. As I said, all of them are really important, you can't skip them. I know this lead to a lot of texture files but we can't avoid it. Its not like we have a pbr system where we could just change the color of certain zone in the model. This is "old" tech :)

it's not a matter excluding Helmets/Visors/Jetpacks

it's a matter of how we want to approach the "Suit assignation to each kerbal"

I think it would be worth trying to keep Suitbodies/Helmets/Visors/Jetpacks stored in different lists, and when a kerbal needs to be "dressed" instead of picking the suit which has everything inside, you pick 4 elements (SuitBody/Helmet/Visor/Jetpack)

this way, if you have multiple colors of each element, you can mix and match them to build your favourite suit.

and to avoid going through all those databases everytime, we could have a simple "Wardrobe" class that has a reference to a specific combination of SuitBody/Helmet/Visor/Jetpack

this "Wardrobe" class could be saved just like the "Head" class so that we always assign a specific suit combination to each kerbal on a per-save basis.

We also need to include the 3 states (IVA,EVAground,EVAspace) in the suit set, otherwise how will you do when you change the suit when you go on EVA (or you click the "switch suit" button) ?

ok, now I see where the confusion came from, the purpose of a "Personaliser.Suit" is basically the same of my "Wardrobe".

so, I'd say let's make everything a bit more modular introducing new classes, this is what I have in mind:

• Suit = contains textures for the body
• Helmet = contains textures for the helmet
• Visor = contains textures for the visor
• Jetpack = contains textures for the jetpack
• EVASuit = contains a set of Suit+Helmet+Visor+Jetpack to be used on EVA
• IVASuit = contains a set of Suit+Helmet+Visor+Jetpack to be used on IVA
• Wardrobe = contains one EVASuit and one IVASuit (replaces the current Personaliser.Suit)

Higher modularity means that the code will be easier to understand, edit and adapt to future needs.

Right now the code is a nightmare and I feel like I would need a lemon helmet just to look at it xD

The female version of the suit should also be included, as I said, doing this spare us the helmet, visor, jetpack and their NRM +level. We spare 16 textures X6 levels so a total of 96 texture files per suit class (multiply this by the number of class we need, 4 in normal KSP + 3 veteran or 14 + 3 veteran for MKS)

don't worry about memory, the textures are only referenced in the class, the texture itself is stored once and all suits that use the same texture will load that file, think of it like links on the desktop.

The badass statut is the more useless for me. I'm not sure we need this for the suits as it only change the reaction of your kerbal when under pressure on flight (smile or fear).

I agree that it doesn't seem of much use, but anyways it's just a boolean check which doesn't really take up much of anything (RAM/processing power) so I think it's worth adding it just in case someone wants to do something with it (like painting flames on the jetpack or stuff like that)

There is a link between all these IVA, EVAground, EVAspace suits and they are related to the KerbalData of your kerbal. In this kerbalData you store the suit set and the other informations of a particular kerbal.

this is what I meant, KerbalData stores the Head as well if I'm not mistaken, which means we can store the "Wardrobe" in here as well so that every kerbal has his own set of stuff to wear

we could also skip the Wardrobe and just store an EVASuit and an IVAsuit directly in the kerbalData.

the difference is minimal

[HaArLiNsH]

We start to get closer to understanding, just don't forget that there is 3 sates for the suits, IVA, EVA ground, EVA space :)

I totally agree on the code visibility part, this is TR's Legacy and Personaliser.cs was the first thing I tried to understand and modify. Hence my comment frenzy :)

The class Suit is kind of your idea of the wardrobe, same goes for the Head class (I was going to rename them Suit-set and Head_set). We can consider that the Head and Suit class function in the same way, just with different parameter. And FYI, in the (near) future I would like to add levels to the head, just like the suits.

We already store the different elements in of each suit set and I don't think we need to separate them. I mean, on the suit maker's point of view, this is easier to just have to make a folder for, lets say the pilot class, and put all the texture for all the states in and make a single .cfg with some parameter.

After this, the player has 3 ways to personalize his use of the Suit set :

• configure the general TRR setting
• configure each suit set individually with the "lot of options" menu (that are the parameters we found in the .cfg file of the suit set)
• move manually the files he wants to use for his suit set (thus making a new one but this is on the player side , not the maker side)

My idea with the "lot of options" menu (lets call it the Filter class), is that you have already a lot of possibilities, for example if I want to use the EVAground helmet when on IVA because the IVA texture don't exist, well you can without having to duplicate the textures files and texture2D.

The spare memory part is a huge, I mean a HUGE thing to care of. There is a great number of states and kerbal parameters and we as a suit pack maker, I want to be able to make a texture for each case but this lead us to hundreds of files with means Go on memory, a single complex 4k texture like I do for my suit pack weight 10.6Mo and a NRM 21.3Mo and they are .dds. We can't avoid them unless we skip some levels (like only using 1 NRM for each state and showing the level only by colour change) But we need also to be able to make a different NRM for lets say the level 5 :) All this by keeping it simple for the suit pack maker :)

We don't need a new wardrobe , there is already one (well 2 with Head). We need to merge the single and array Texture2D. If you look in the dev branch, I made the list of the different textures we need, we just need to put them in array and make the function to call them like the one s that already exist.

All I need for now is to be able to make a folder MyMod/Suits/MySuitSet and use this folder like in TRR (for the compatibility and use of the texture pack makers) and put a .cfg in this folder with the parameter needed. And also be able to just drop an old TR suit pack in the Suits folder without any .cfg in TRR like the players are used to if they don't find an updated version of the pack.

I will finish the reformatting in Array of the Texture2D tonight or tomorrow (I've got the logic) and I'm finishing the updated TRR_guide suit set witch will include all the textures we can possibly do to make a full suit set. This way we will see more clearly what we need to optimise if needed

Having a complex system like "I pick on a gui the jetpack I want to use like in diablo" is way to much crazy to do (well, at least for the first step of TRR)

(I started typing this some hours ago now, so new ideas/understandings comes along)

What we can do that could really improve the modularity, is to change the structure of the "MySuitSet" folder !

Now it hold hundreds of files and maybe we should split theses in categories and use the name of these categorie/sub-categories to do what you propose(if I understand correctly :p ), individual elements that the players can assign has he wish (or the maker of the suit of course with a "set" setting).

Here is the full structure of the possibilities, the female suit is the only mandatory, the helmet,visor and jetpack can be the same than the male because they use the same meshes. But this could be nice to add the possibility to personalise it too.

GameData/MyMod/Suits/MySuitSet/  : 
           - Suits/ 
                       - IVA/                                 
                                - Male/
                                               - Normal/
                                               - Badass/
                                               - Veteran/
                                               - Veteran Badass/
                                - Female/
                                               - Normal/
                                               - Badass/
                                               - Veteran/
                                               - Veteran Badass/
                       - EVA ground/                               
                                - Male/
                                               - Normal/
                                               - Badass/
                                               - Veteran/
                                               - Veteran Badass/
                                - Female/
                                               - Normal/
                                               - Badass/
                                               - Veteran/
                                               - Veteran Badass/
                       - EVA space/                               
                                - Male/
                                               - Normal/
                                               - Badass/
                                               - Veteran/
                                               - Veteran Badass/
                                - Female/
                                               - Normal/
                                               - Badass/
                                               - Veteran/
                                               - Veteran Badass/
           - Helmet/   
                       - IVA/                                 
                                - Male/
                                               - Normal/
                                               - Badass/
                                               - Veteran/
                                               - Veteran Badass/
                                - Female/   (not mandatory)
                                               - Normal/
                                               - Badass/
                                               - Veteran/
                                               - Veteran Badass/
                       - EVA ground/                               
                                - Male/
                                               - Normal/
                                               - Badass/
                                               - Veteran/
                                               - Veteran Badass/
                                - Female/   (not mandatory)
                                               - Normal/
                                               - Badass/
                                               - Veteran/
                                               - Veteran Badass/
                       - EVA space/                               
                                - Male/
                                               - Normal/
                                               - Badass/
                                               - Veteran/
                                               - Veteran Badass/
                                - Female/   (not mandatory)
                                               - Normal/
                                               - Badass/
                                               - Veteran/
                                               - Veteran Badass/
           - Visor/   
                       - IVA/                                 
                                - Male/
                                               - Normal/
                                               - Badass/
                                               - Veteran/
                                               - Veteran Badass/
                                - Female/   (not mandatory)
                                               - Normal/
                                               - Badass/
                                               - Veteran/
                                               - Veteran Badass/
                       - EVA ground/                               
                                - Male/
                                               - Normal/
                                               - Badass/
                                               - Veteran/
                                               - Veteran Badass/
                                - Female/   (not mandatory)
                                               - Normal/
                                               - Badass/
                                               - Veteran/
                                               - Veteran Badass/
                       - EVA space/                               
                                - Male/
                                               - Normal/
                                               - Badass/
                                               - Veteran/
                                               - Veteran Badass/
                                - Female/   (not mandatory)
                                               - Normal/
                                               - Badass/
                                               - Veteran/
                                               - Veteran Badass/
           - Jetpack/                         
                       - EVA ground/                               
                                - Male/
                                               - Normal/
                                               - Badass/
                                               - Veteran/
                                               - Veteran Badass/
                                - Female/   (not mandatory)
                                               - Normal/
                                               - Badass/
                                               - Veteran/
                                               - Veteran Badass/
                       - EVA space/                               
                                - Male/
                                               - Normal/
                                               - Badass/
                                               - Veteran/
                                               - Veteran Badass/
                                - Female/   (not mandatory)
                                               - Normal/
                                               - Badass/
                                               - Veteran/
                                               - Veteran Badass/

each subfolder finish by 12 files : the 6 levelled textures and their normal map

As you can see, there is a shit load of possibilities. We need a system that is modular but also easy to use for the makers. I don't want to have to create and use all these folders when I'm making a suit set. Having to put 600 files in one folder is enough :) We need a system that handle that alone (this is what our actual system does) if we don't make a .cfg with all the sub names or we don't create the folders.

I'll stop writing here and finish the TRR_guide so we have all the possibles files we need to handle :)

[HaArLiNsH]

While exporting textures like a robot, something came to my mind and I note it here : We need a way to be able to "easily" use the same texture as another part (visor,helmet,jetpack) in a different suit set. Like for example if I use the same EVA space jetpack in all my kerbal classes, I only need it once (texture files and texture2D) and I can use it on the other classes.

This is the case of what you are talking about if I'm not wrong. We need to be able to do this and also be able to make a full suit set while trying to keep maximum compatibility with the old TR legacy suit packs.

A GUI where we could see all the different textures like an inventory would be a great thing. KIS already use a kind of inventory like this.

I'll finish what could be a full suit set with all the possibles configuration of each element tonight and we'll see how to sort this out. already 433 files and this will go up. :p

[Sigma88]

Like for example if I use the same EVA space jetpack in all my kerbal classes, I only need it once (texture files and texture2D) and I can use it on the other classes. This is the case of what you are talking about if I'm not wrong. We need to be able to do this and also be able to make a full suit set while trying to keep maximum compatibility with the old TR legacy suit packs.

yes, this is why I am insinsting to have separate objects for those things.

let's say you don't care about JetPacks and are ok with having just one, TRR will load that one, and put it into a database. then when it assigns a SuitSet to a KerbalData it looks through all Suits available and picks one, all the helmets and visors and picks those as well, and finally through all JetPacks, find only one and so assign that one.

this system doesn't generate new textures, each texture file is loaded only once and all the classes have only the "url" of the texture

---

question, what's the difference between SpaceEVA and GroundEVA?

[Sigma88]

I'm also adding level-able heads since you mentioned it

[HaArLiNsH]

It already does that in a way, as it try to load the good texture (for the level for example) and if it fail it stay at the last texture know witch can be the default texture from squad if it find nothing.

But we can't interchange texture from other suit pack except if we put one in the default folder. :)

Anyway, I need to go back to the suit pack guide, I'll make subfolders, there is just too many files. Keep going, we'll see how it goes and thx for the help :)

[Sigma88]

you probably missed my question earlier,

what's the difference between SpaceEVA and GroundEVA?

specifically, do we want them to look the same, except maybe for some details? or could they be completely different? like one red and the other yellow?

what happens if a kerbal goes EVA in space and then lands? will the suit automatically switch? will it remain the spaceEVA suit untill you go IVA > EVA (at which point it will be a groundIVA rather than a spaceEVA) ?

[HaArLiNsH]

yeah I missed it sry, a bit tired :)

So yes they are completely different suits (include visors,helmet,jetpack).
Basicaly, the idea came from my suit pack based on the movie "the martian", you know the orange one. I was making the first suit then I realized that we don't have a state for this suit. Because they use a white one in space. So my version of it is :

• IVA = the iconic suit but without the chest that is attached to the lifepack/jetpack (it could have been also the blue shirt but the suit is nice to kerbalise it ) http://static1.businessinsider.com/image/5602c4c1dd08952b148b46ad-2902-1526/the-martian%20.jpg
• EVA ground = the iconic suit made to explore Mars (so ground exploration, good for MKS) http://pbs.twimg.com/media/C-g7DGmVoAAY8wW.jpg
• EVA space = the big white suit made for space (this is the "old" EVA suit) https://s-media-cache-ak0.pinimg.com/originals/0d/1b/13/0d1b13a237d66290992a4e0438ea2240.jpg

here's a WIP of the IVA veteran multiclasses http://i.imgur.com/aZPNT2a.gif

So how the system goes ?

• When you kerbal goes out of the vehicle, we make a check if we use the IVA suit with isSituationSafe() and isAtmBreathable()
• if not, we check if the vessel.situation of the kerbal is under suborbital with isUnderSubOrbit(). If yes we use the EVA ground
• if all of this is false , we use the EVA space suit.

You can also switch the state by pushing the button 'toggle suit" on the gui when you right click on your kerbal. My last saved iteration kind of broke the toggle button because the update() applies the logic at each update. I made an option to desactive the automatic suit switcher but I kind of screwed my branches at one time and lost it :)

So far this logic seems to work but I never tried to land a kerbal on EVA from a vessel in orbit (like on an asteroid or a crazy jump EVA land on the Mun). Normally, if your kerbal survive the landing, it should change the state automatically at the update() to EVA ground when its state comes to one of the isUnderSubOrbit() situation check.

I also made a option to don't use the EVA ground suit (isNewSuitStateEnabled) that goes in the same way of the older (isAtmSuitEnabled)

There is also all the thing with the helmet removal on updateHelmets() and the general options like (isHelmetRemovalEnabled). The IVA suit does have a helmet and visor texture (and when you see squad's ingame picture of the veterans in IVA in a vessel, they use the default white EVA helmet with orange vet suits :p )

I hope I made myself clear, its late :)

Ok so far I made all the (with gender, vet, badass, vetbadass) suits and their NRM , the jetpacks and helmets (still need their NRM) and still need the visors and their NRM. This make a crazy amount of 528 files so far , we are going to something close to 600 files for a full suit set. Of course nobody will make another full set (well surely me by the time..) but this is a debug suit set and we need to be able to test the thing and give a guide for the other modders :) Still need to convert all of this in .dds , expect the TRR_guide tomorrow somewhere in the day

[Sigma88]

ok, I just needed to know if I needed to add some kind of link between the space and ground suit or if they can be considered completely unrelated

which is much simpler :D

I'm slowly progressing, it will take a while to have a working prototype of my idea, but once it gets going it should be much easier to understand than the current system

[HaArLiNsH]

Sry for the wall of text, I tried to give all the informations I had , maybe a bit too much :) Take your time, we are not in a hurry :)

[Sigma88]

don't worry, I keep coming back to this page so I can definitely use all the info you can give me :)

[Sigma88]

regarding assigning a Suit, Helmet, Visor, JetPack to a Kerbal

this is the flowchart I am following now:

NOTES:

• Suit means the body, the same flowchart works for Helmet, Visor and JetPack
• type can be IVA, EVA, GROUND
• gender matches when the gender is the same, if the suit has gender = Unisex it matches both male and female
• "Default Suit" are stock suits, (different for veterans)
• The code will chose the suit with the higher "BestFit" value
• If multiple suits have the same BestFit, it will pick one at random

[HaArLiNsH]

I don't get how do you handle the standard and veteran suit here, but continue this will come clear when you have finished :)

I've nearly done the TRR_guide_SuitSet_Full. You may be pleased to know that we have 528 textures and 528 NRMs to make the full set :p
I have them all in .png but you can't just give 1056 .png to the loading of ksp, it will take ages :) They all are in 4096x4096 (versus the 1024x1024 of the default texture). This is to try to push the system and honestly you see the difference on detailed textures :)

The weird thing is that the .png version weight between 140Ko and 500Ko and the .dds weight 10.6Mo ! and the NRM weight something like 20Mo ... I think we can't make a full set in 4k... it would weight something like 16Go !! (per class..). Of course, nobody will ever make a full suit set with different normal maps, we use generally only one NRM per level, maybe 2 with the level 5. This leads us to something more like 4-6Go per suit class. Witch is still too much with MKS :)

I'm trying to find a way to batch convert them in .dds and also to make a half and also a quarter size to help for the loading. I'm trying to decode the batch commands of gimps :) I hope it got it for tomorrow :)

I have also changed the name formatting here some examples :

Visor_Iva_Badass_Female0.png Helmet_EvaGround_Veteran_Male4.png Suit_EvaSpace_standard_Female2.png Jetpack_EvaSpace_VetBad_Male5.png

and for the NRM :

Visor_Iva_Badass_FemaleNRM0.png Helmet_EvaGround_Veteran_MaleNRM4.png Suit_EvaSpace_standard_FemaleNRM2.png Jetpack_EvaSpace_VetBad_MaleNRM5.png

You can clearly see the structure with the name and, maybe, it could be useful if we want to make a more general element, for example if I want to make an helmet for all the IVA I could make :

Helmet_Iva.png

or for the levels:

Helmet_Iva0.png Helmet_Iva1.png .. or we could just make a

Helmet.png for all helmets

For now I've put all the textures files in one folder, this is much much easier to batch manipulate them this way

This also came to my mind and I think this could save the day of the HD textures :

Do you know if there is a way to apply a decal on certain part? I mean, if you look at my textures (you can't see the news yet but the actual TRR_guide use the same technique), you will see that the base texture don't move and only the text change when levelling. If we could just apply a decal for certain part we could save a lot of memory. Like for example a decal on the back of the helmet. And if we combine it with the full texture method we use now, we could have different level on the same texture and also the ability to change the texture for certain level (like change the colour for level 5) while preserving A LOT of memory and mental sanity for the suit makers :)

[Sigma88]

The weird thing is that the .png version weight between 140Ko and 500Ko and the .dds weight 10.6Mo ! and the NRM weight something like 20Mo ... I think we can't make a full set in 4k... it would weight something like 16Go !! (per class..). Of course, nobody will ever make a full suit set with different normal maps, we use generally only one NRM per level, maybe 2 with the level 5. This leads us to something more like 4-6Go per suit class. Witch is still too much with MKS :)

png files are compressed and so they occupy less space on the hard drive, KSP has to decompress them when loading tho, so the final RAM space required for a 512x512 png texture is the same as a 512x512 dds texture

with the difference that the png takes up less disk space, and when loading the texture KSP will take more time if the texture is a png (and that's why using dds is better, because they take less time during the loading screen)

---

on a side note, I've completed everything about the syntax I wanted to do.

everything gets loaded and assigned to kerbals using the system I came up with

but, I have yet to tie my code with TRR, for now it's completely separated.

I'll see if I can make the suit assignment automatic and then try to use the examples to load the textures

here's a scheme that shows the hierarchy of objects I've created:

[Sigma88]

@HaArLiNsH could you please tell me the names of the default (Stock) textures for Suit, Helmet, Visor, JetPack for all types of suit (IVA, EVAspace, EVAground), for both normal kerbals and veterans

also, I think we should add the option of changing the tourist "suit" if that's possible :)

[HaArLiNsH]

Yesterday was a really bad day and I couldn't work. So I'll try to have the suit pack today :)
Your hierarchy seems good so far.

One question about the loading/unloading. I don't get something on how it works now. Do we load/convert all the textures and then unload the unused in a single action or do we load/convert and unload each texture one after one? I ask this because if this is the second case, the size of the texture pack should not be a problem.

For the tourist suit set, now the tourist use the default suit set ( a custom one we put in default/ or the default one if there is no custom default suit set). I think we should make a tourist setup window like for the other classes. That's why when I talk about the number of classes we need to make for the basic one I talk about 4 classes (pilot,engineer,scientific and tourist). With the difference that the tourist class don't need the level,veteran and badass textures.

Here is the default names ("old" states, so EVA = EVA space, there is no EVA ground default) : What is not in this list, is not default :) (this list comes from the TR's readme)

  Default/kerbalHead                  // teeth and male head
  Default/kerbalHeadNRM               // teeth and male head normal map
  Default/kerbalGirl_06_BaseColor     // female head
  Default/kerbalGirl_06_BaseColorNRM  // female head normal map
  Default/kerbalMain                  // IVA suit (veteran/orange)
  Default/kerbalMainGrey              // IVA suit (standard/grey)
  Default/kerbalMainNRM               // IVA suit normal map
  Default/kerbalHelmetGrey            // IVA helmet
  Default/kerbalHelmetNRM             // IVA & EVA helmet normal map
  Default/kerbalVisor                 // IVA helmet visor
  Default/EVAtexture                  // EVA suit
  Default/EVAtextureNRM               // EVA suit normal map
  Default/EVAhelmet                   // EVA helmet
  Default/EVAvisor                    // EVA helmet visor
  Default/EVAjetpack                  // EVA jetpack
  Default/EVAjetpackNRM               // EVA jetpack normal map

We need to support theses default names and the new ones for the same texture. For example, now if we want to use a default female kerbal head, it has to be named "kerbalGirl_06_BaseColor", witch is bad :)

All right lets go for the converting of these 1K textures :)

[Sigma88]

One question about the loading/unloading. I don't get something on how it works now. Do we load/convert all the textures and then unload the unused in a single action or do we load/convert and unload each texture one after one? I ask this because if this is the second case, the size of the texture pack should not be a problem.

I have no idea about that sorry

For the tourist suit set, now the tourist use the default suit set ( a custom one we put in default/ or the default one if there is no custom default suit set). I think we should make a tourist setup window like for the other classes. That's why when I talk about the number of classes we need to make for the basic one I talk about 4 classes (pilot,engineer,scientific and tourist). With the difference that the tourist class don't need the level,veteran and badass textures.

ok perfect, I wasn't sure about how turists worked

We need to support theses default names and the new ones for the same texture. For example, now if we want to use a default female kerbal head, it has to be named "kerbalGirl_06_BaseColor", witch is bad :)

it's not necessarily bad, that's the name of the stock file so it's the obvious name to use, where exactly would you want to change that name?

I mean, for which feature?

[HaArLiNsH]

I mean, to use a suit set (or head set) as default texture, it would be easier to just have to use the texture we want with his new normalised name than having to rename it. For the last example, the real name of the female head texture was "TRR_Guide_Female_Head.dds" and it work (as intended) normally when we put it in the Heads/ folder, but if we put it in the Default/ folder, we have to rename it "kerbalGirl_06_BaseColor.dds". Same goes for all the textures you have in the default list posted before.

It would be great if we could use both names in the default/ (for compatibility).

This make me think that we should have a default class (in fact this is the tourist class), so we can configure the suit/head set we want as default ingame. We should use the files in the default folder first (if none use the squads default) and have a Gui ingame just like for the other class to set it up as we like.

[Sigma88]

It would be great if we could use both names in the default/ (for compatibility).

this is a bad idea, since there could be potentially two textures competing for the same job

This make me think that we should have a default class (in fact this is the tourist class), so we can configure the suit/head set we want as default ingame. We should use the files in the default folder first (if none use the squads default) and have a Gui ingame just like for the other class to set it up as we like.

this is a great idea, just add an extra class called "Default" (but keep Tourist separated, so it can be customized)

so basically, the Default class will load all the stock textures using the hardcoded names (those used by squad)

TRR will replace the stock texture only if the texture provided in the Default/ folder has the same name

BUT

you can define a custom look for the "Default" class, just like you can define custom groups for all other classes

the default class will never match any kerbals of course, but if TRR can't find a good suit to assign to a specific kerbal, it will assign the default one.

[HaArLiNsH]

Exactly this :)

The conversion goes well, the full suit set of 1056 files in 4096 weight 18Go :p

I'm doing the 2048 , 1024 and also a minimal set of each (one with default names and one with the new format) composed of the level 0 and level 5 + 1 NRM)

The upload will take some times... :))

I will certainly make a mixed size suit set. With the suits in 4096 , the helmet and jetpack in 2048 and the visor in 1024. I think this will be a good compromise.

[HaArLiNsH]

Alright, the conversions are done !

The NRM are " flat" and are all the same for each element (jetpack,helmet,suit) except the visors that have a lvl 0 to lvl 5 writen on them to normally see the bump of the NRM (there is no squad default visor NRM)

All the texture images are different with all their informations readable on them like :

Lvl 2 EVA space Female Veteran

There is a logic in the colours too, so you can see the differences from afar :

• the 3 states have differents colors,
• the male & female version only change with the name male&female,
• the visor is at 100% transparency at lvl 0 and goes down to 0% transparency at lvl 5
• the veteran version have a orange line,
• the badass version have 2 red lines,
• the veteran+ badass have the orange and red line.

Just for reference, here is the weight of each size for the full set in .dds :

• 4096 full : 18Go
• 4096: minimal set (the 3 states,no female, no veteran, no badass, no VetBad, with only the level 0&5 and 1 NRM ) : 533Mo
• 2048 full : 4.5Go
• 1024 full : 1.12Go
• Mixed (suit:4096, helmet&jetpack:2048, visor:1024) : 6.75Go
• Mixed : minimal set : 193Mo

I think the mixed sizes is the mode I will recommand to use to make HD suit packs, full 4k elements is just too much. But the system should be able to load the full 4k, just in case :)

I will upload them in "source mode" and make a release version too (.rar) for the ease of downloading. There is a .png and a .dds version of each size.

Let's hope its finished uploading tomorrow :p

[HaArLiNsH]

The guide is here :) https://github.com/HaArLiNsH/TRR_Guide/releases/tag/V0.2

[HaArLiNsH]

I've just made an update of the master and a release that fix the suit state changes for the legacy suit pack and the eva ground state so at least ppl can use their old suit pack and the eva ground state is working :)

I started to change names following the new convention.

[HaArLiNsH]

You can find all the new names needed in the readme of the TRR_guide (too long to post here) : https://github.com/HaArLiNsH/TRR_Guide

[Sigma88]

are you sure about using filenames to define which kind of suit the texture belongs to?

that makes it very difficult to use the same texture for more purposes

[HaArLiNsH]

Well, I needed to name them in a way that I could put the thousand of files all in the same place and differentiate them easily. This is just a renaming of the actual default name convention.

Same goes for the texture2D [] we need to make. There are so many possibilities that we need to use a proper name convention and I made the full set just for this purpose, our new system must be able to handle all of theses and also when there is not texture for a particular state (just like it does now)

I think that, we need to have a substructure system in our Suit_set class. with a default layout that uses the files as the name convention suggest. (first step) And then having the possibility to changes this structure if we want (second step)

I could make the actual system use theses new states, in fact, I started to refactor the texture2D in name and format (removing the single and use only array of texture2D). And I could add the others configurations but the problem is that this personaliser.cs will grows in size like hell and this will be a nightmare to make it more modular after.

So I don't want to impose you any ways to handle the suit pack, I just say that the new system need to be able to handle the TRR_Guide full suit set, one way or another :)

If you talk about my idea of using different shorter names, yes this was a bad idea :)

[Sigma88]

using the names is fine for now, but it's not a very customizeable solution...

this is what I think would be best going forward:

naming conventions are only needed if you intend to put all textures in the same folder.

what I think would be the best approach, is having a folder for each object

by object I mean "Suit" (as in the body), "Helmet", "Visor" and "JetPack"

so, let's say you want to add 3 new suit sets that share the same helmet/visor/jetpack

but have different colored suits based on the kerbal level

in the first set:

• Lv0, Lv1 and Lv2 get a blue texture
• Lv3, Lv4 and Lv5 get a red texture

in the second set:

• Lv0, Lv1 and Lv2 get a blue texture
• Lv3, Lv4 and Lv5 get a yellow texture

in the third set:

• Lv0, Lv1 and Lv2 get a blue texture
• Lv3, Lv4 and Lv5 get a purple texture

instead of having all the textures in the same folder, you make 7 different folders:

1- Helmet 2- Visor 3- JetPack 4- BlueSuit 5- RedSuit 6- YellowSuit 7- PurpleSuit

then, for each set, you create a cfg telling TRR to load the textures from all the commont folders (1,2,3,4) plus one of the "specific" folders (either 5 or 6 or 7)

this way TRR will generate 3 different sets, and it will allow you to reuse the same texture for multiple purposes

otherwise you will be forced to make multiple copies of the same texture just to use a different name, or to implement in TRR a long and tedious list of priorities which ultimately will not meet everybody's needs (forcing them to use multiple identical textures)

[Sigma88]

and for the names, with this setup you can name the textures whatever you want, with the only exceptions that if the name ends in a number from 0 to 5 (or even better, -L0 to -L5, it means that the texture in question has been made for a specific level

and if (before the number) the name has a NRM, it means that it's a normal texture

[HaArLiNsH]

Your idea is no bad but you don't account the difficulties for the suit pack maker :) I first tried to make the folders and sub folders for the different parts and their state (vet, badass, male, female) and it became quickly nightmare to see with one i still needed to do or to batch convert them.

And the system don't care about it, because it search the database of all the textures and we need to filter the names and the folders

Here are the necessities we need to keep it simple (from the user and maker point of view). you will see with that why I wanted to make a configuration windows (and file) for each suit set (the filter class), independent the MM configuration that we need to make for the path of the folder

• What we call a suit set must only include ONE class (so one class colour scheme, like the red for pilot) just like before. so we will have a MySuitSet_pilot, MySuitSet_engineer, Mysuitset_scientific, ... and the system handle the different parts by their name, this must be as simple a possible for the maker and user.

• If I want to use same texture for the same element in the same suit set (like the IVA helmet and the EVA ground helmet), I have 2 ways to do it : 1 : copy paste the textures files and rename them (easier but need more memory, this is how I've done for the full suit set) 2 : Use the configuration file to modify how this particular suit set behave (this is the filter class I talked about before). Like the option "Use EVA Ground helmet for the IVA helmet" = true.

With this filter class, we can make a lot of option for the user/maker to handle how he want a particular suit set to behave. With this we can change how the 3 states functions. We can make a option that allow to remove the helmet in space and force to use it on Kerbin for example. When we will be able to properly remove the collar, we could make an option to use it or not.

Lots of possibilities down here but while typing this, an even better idea came to me :) :

• Then comes the question where I want to use the same texture file for the same element in different suit set (like using the same IVA helmet for all the classes). Well, you can be sure that this case will nearly never happen because of the colors schemes, logos and texts used for the differents classes, and this also makes us use different NRM files. This is already the case for the majority of the actual TR big suit packs.

But again we can have 2 ways to resolve this, and the second could be really nice and also solve the case for the missing textures in the same pack and bring new possibilities :

1 : copy, paste the files, and you don't even need to rename it (easiest way to do it, but has a memory impact) 2 : We make another windows GUI where we can choose which loaded Texture2D array we want to use for the part for each of the 3 states. So a bit like we have now where we can choose each suit set we want for each class. I have a " texture inventory" window that I can swap for the 3 states (IVA,EVAgr and EVAsp) where I see the texture used for helmet,visor,jeptack and suit with the name/class of the suit set.

So for example, if a want to use the same IVA helmet , I can switch the actual texture (default if none) to decide witch one I want for this part at this state. (just like we do now to switch between suit set for the kerbal/classes).

We can handle it easily with the help of the naming structure itself. In the last example, even if we use the same name in each suit set, we can still differentiate them by the name of the suit set itself. So here the real name we need to call it is MySuitSet_pilot.Helmet_Iva_Standard_Male0 (and the same goes for the NRM MySuitSet_pilot.Helmet_Iva_Standard_MaleNRM0) We could even make a subwindow for the NRM!

If we can do that, we also don't need to make certain option in the filter class (like the "Use EVA Ground helmet for the IVA helmet" = true.) We can also include a lot of the other options in this, like we could have a check option to use the helmet/visor and jetpack or not at each state in the "texture inventory" window.

here are some pictures of the menu I'm talking about :

If the texture don't exist for the particular state, we need to populate it with the texture from the upper category in the texture naming tree.

So for example, if we need the texture for this case and it don't exist :

• MysuitSet_pilot.Helmet_EvaSpace_Veteran_Female3

I can use the texture2D that is !null and witch is up the the tree in the naming structure

• MysuitSet_pilot.Helmet_EvaSpace_Veteran_Female2
• MysuitSet_pilot.Helmet_EvaSpace_Veteran_Female1
• MysuitSet_pilot.Helmet_EvaSpace_Veteran_Female0
• MysuitSet_pilot.Helmet_EvaSpace_Veteran_Male3
• MysuitSet_pilot.Helmet_EvaSpace_Veteran_Male2
• MysuitSet_pilot.Helmet_EvaSpace_Veteran_Male1
• MysuitSet_pilot.Helmet_EvaSpace_Veteran_Male0
• MysuitSet_pilot.Helmet_EvaSpace_Standard_Female3
• MysuitSet_pilot.Helmet_EvaSpace_Standard_Female2
• MysuitSet_pilot.Helmet_EvaSpace_Standard_Female1
• MysuitSet_pilot.Helmet_EvaSpace_Standard_Female0
• MysuitSet_pilot.Helmet_EvaSpace_Standard_Male3
• MysuitSet_pilot.Helmet_EvaSpace_Standard_Male2
• MysuitSet_pilot.Helmet_EvaSpace_Standard_Male1
• MysuitSet_pilot.Helmet_EvaSpace_Standard_Male0
• default Squad texture

[HaArLiNsH]

We need to make a system that basically says(for example )

case MysuitSet_pilot.Helmet_EvaSpace_Veteran_Female3 =this XXX texture

My aim for the user/modder is to only have to make the little as possible cfg file.

The only mandatory info we need is :

MySuitSet_pilot path = MySuitSet_generalFolder (so we can move this from the TRR folder)

If the modder don't povide any other cfg, we use the standard model to populate the suit set. If a modder want to use a particular texture2D for a part, he just have to put

MysuitSet_pilot.Helmet_EvaSpace_Veteran_Female3 = MysuitSet_pilot.Helmet_IVA_Standard_Male0

or this also :

MysuitSet_pilot.Helmet_EvaSpace_Veteran_Female3 = MysuitSet_Engineer.Helmet_EvaSpace_Veteran_Female3

to use the same texture from another suit set !! 👍

and the menu ingame let us do the same thing

[Sigma88]

if you want this system then we don't need a new config structure, trr will be able to read the properties from the names themselves and the current code is already able to handle everything once you add the new names in the list

I don't like it because it's not customizeable at all using MM

if you don't like a certain color scheme for a veteran and want to swap it with another color scheme you will need to manually edit the names of the files

but if you like this system more that's up to you to decide

[HaArLiNsH]

I don't like it because it's not customizeable at all using MM

if you don't like a certain color scheme for a veteran and want to swap it with another color scheme you will need to manually edit the names of the files

It will be configurable , but not by MM, by another config (like the @default.cfg we have now)

That's why I wanted to make a config window, so you can change it either by making a cfg file and do the change by typing the names OR use the config window (witch should be a lot more user friendly)

We don't need the same system as we use to have to change a single (or a few) textures, like changing the navball or the skybox or the texture for the mk3 pod. As you have seen, you can't really just change a single texture for the suit , you have to change all the structure tree witch means a lot of texture.. here the idea is more to be able to reuse some texture to spare memory

If you want another color for the veteran (like I want the veteran accent to be purple instead of orange.. ) well you have to modify the texture itself, witch means you will make your own suit pack :)

Or you make you own MyVersionOf_MySuitSet_pilot with the files you want to replace and you swap them by manually creating the cfg file or using the config window.

You can't just swap the veteran suit with another suit set (class), because you have the class logo and other details on the suit, so you can't use the engineer veteran for the pilot veteran.

And you still have the /default suit set, so if you want to use the same visor for all your kerbal, just put it in the default/ folder.

If the actual system can already do a lot of this, we don't need to revamp it entirely, that's why I said "don't throw the baby with the bathwater" :)

Here is what I need :

• a config to move the folders from TRR and make TRR treat these as if they where in his folder.
• an easy way for the people to change a particular texture (like you showed with the texture that swap the name in the menu)
• an example to change the skybox and navball

[Sigma88]

yes I get what you want to do

it's fine, I just liked the idea of a MM system better than the "ingame editor" system

but ultimately TRR it's your mod and you should get to choose what you enjoy doing most :D

[HaArLiNsH]

In final we will have both system , MM config style for single/low number texture swap and another .cfg system coupled with an ingame editor for the suits. I think this is the best of both world for the users and modders. New features but you don't need to relearn everything :)

All the discussion we made for the suit is also true for the future levelled heads :)

So, just to see who does what, and as you seems to master the MM config thing, could you finish the "out of TRR's folder" thing? My ultimate goal would be that the user/modder use a folder like the TRR one for his texture pack. something like

MyTextureMod/

    MyTextureMod.cfg //where we say "use this path instead of the default TTR folder"

    -Suits/
            -MySuitMod_pilot/
                                    - textures files
                                    - textures files
                                    - textures files
                                    - textures files
                                    - ...
                                    - MySuitMod_pilot.cfg  //with the config for this suit set

            - MySuitMod_engineer/
                                    - textures files
                                    - textures files
                                    - textures files
                                    - textures files
                                    - ...
                                    - MySuitMod_engineer.cfg //with the config for this suit set

            - -MySuitMod_AnySuitSetIWantToMake/...

    - Heads/ 
            -MyHeadMod_aleVersion1/
                                    - textures files
                                    - textures files
                                    - textures files
                                    - textures files
                                    - ...
                                    - MyHeadMod_maleVersion1.cfg  //with the config for this head set

            - MyHeadMod_Jebediah/
                                    - textures files
                                    - textures files
                                    - textures files
                                    - textures files
                                    - ...
                                    - MyHeadMod_Jebediah.cfg //with the config for this head set

        - -MyHeadMod_AnyHeadIWantToMake/...

    - Default/   // for the default suits and heads, we could even put it in the suits or heads folder
            -MySuitMod_Default/
                                    - textures files
                                    - textures files
                                    - textures files
                                    - textures files
                                    - ...
                                    - MySuitMod_Default //with the config for this suit set to make it the default suit set

            - MyHeadMod_DefaultMale/
                                    - textures files
                                    - textures files
                                    - textures files
                                    - textures files
                                    - ...
                                    - MyHeadMod_DefaultMale.cfg  //with the config for this head set to make it the default head set

    - CustomTextures /
                                    - MyCustomTexture file  // here you put all the single texture you want to replace with MM like the skyboxe or the navball or the MK1 cockpit
                                    - MyCustomTexture file
                                    - MyCustomTexture file
                                    - ...
                                    - MyCustomTexture.cfg  // with the config to swap the textures

The personaliser.cs needs also love , I'll list here the things, I think, we still need to do :

• add all the filenames possible and make it support also the legacy names
• refactor the single Texture2D and the Texture2D array.
• Maybe revamp how the Suit_set /head_set works so its more readable, understandable and upgradable
• make a GUI for the "Texture inventory"
  • Modify the behaviour of the suits and heads so it can work with the new features (level, badass states, etc)
• implement the class "filter" to modify the behaviour of the standard 2/3 states switcher (the IVA-EVAgr-EVAsp) with the option that we can find in the "texture inventory"
• make a "default option" database, so, for example, the MySuitMod_pilot.cfg only need the options it wants to override
• make a "Default" class in the general GUI of TRR, so we can also configure the default suit/head set.
  • makes all of this legacy compatible, so a user could use an old suit/head pack like on TR by just throwing the customsuits folders in the "suits" folder of TRR (the navball and skyboxes will need to use MM config and custom folder, I think we lost the old way don't work any more)

What do you think of that ? I know you wanted to change all the suit/head set but I think we need to find a middle ground on that point and the MM thing is still needed for all the others textures :)

[Sigma88]

don't worry it's completely fine for me if you rather go with this setup,

if nobody was asking for the features I wanted to add it's not like I lose anything from not adding them :D

plus, I have tons of other mods so it's not like I will remain with nothing to do :)