Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
TRR Config Structure Discussion #14
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:
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:
sounds great !
My goal for the folder structure itself would be something like this :
So this looks like you propose. If a mod use head textures, it will goes like this :
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 :)
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)
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)
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 ! :)
veteran and badSS are not the same
Jeb, Bill, Bob and Val are all veterans
but only Jeb and Val are basSS
using the name could be fine, but not using the name would allow for extra compatibility which is something I always like :)
That's why I added the "gender = Unisex" tag.
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
I will add that as well
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"
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 :)
Unisex literally means <<Designed to be suitable for any sex or gender.>> 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 ) rather than in a single object ( Texture2D ) so that we can have all the levels stored in the same "Suit" object
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 :
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) :
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
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) ?
Yeah I know there is maybe a bit too much options and some could be merged in a 3 state check like:
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.
I changed the name of the states when I added the new one, so now they are like this :
Each suit state need his helmet, visor, jetpack and their normal map. (exept the IVA don't have the jetpack)
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.
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).
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.
Sorry for the wall of text, I tried to explain the best I could :)
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
in my idea "Suit" objects are simpler that your Personaliser.Suit
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<Suit>
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.
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)
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 ?
I'll reply point per point while I'm reading your post, so bear with me if the comment gets edited multiple time :D
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.
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:
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
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.
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)
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
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 :
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 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 :)
I'll stop writing here and finish the TRR_guide so we have all the possibles files we need to handle :)
While exporting textures like a robot, something came to my mind and I note it here :
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
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?
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.
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) ?
yeah I missed it sry, a bit tired :)
So yes they are completely different suits (include visors,helmet,jetpack).
here's a WIP of the IVA veteran multiclasses
So how the system goes ?
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 :)
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
regarding assigning a Suit, Helmet, Visor, JetPack to a Kerbal
this is the flowchart I am following now:
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
The weird thing is that the .png version weight between 140Ko and 500Ko and the .dds weight 10.6Mo !
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 have also changed the name formatting here some examples :
and for the NRM :
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 :
or for the levels:
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?
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:
@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 :)
Yesterday was a really bad day and I couldn't work. So I'll try to have the suit pack today :)
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) :
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 :)
I have no idea about that sorry
ok perfect, I wasn't sure about how turists worked
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?
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.
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.
this is a bad idea, since there could be potentially two textures competing for the same job
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
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.
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.
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 :
There is a logic in the colours too, so you can see the differences from afar :
Just for reference, here is the weight of each size for the full set in .dds :
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
The guide is here :)
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.
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.
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)
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 :)
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:
in the second set:
in the third set:
instead of having all the textures in the same folder, you make 7 different folders:
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)
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
and if (before the number) the name has a
Your idea is no bad but you don't account the difficulties for the suit pack maker :)
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
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 :) :
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)
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.)
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 :
I can use the texture2D that is !null and witch is up the the tree in the naming structure
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.
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
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
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.
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 :
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 :
What do you think of that ?
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 :)