I see. Thanks for clearing that up.
As far as assigning new official tags and categories is involved: I don't even begin to have a knowledge on how, or if, this could work, so I can't say anything about that. I do agree though that with future content being put up (especially from EA) this could very well pose problems.
The truth is I hadn't dabbled with these things at all until I found out about the value-thing, and back then, I was just excited that when I changed some numbers, stuff would miraculously work in a way I hoped it would. Didn't even understand what exactly it was I had done. It was magic, period.
Now, with every passing day I collect more information (thanks to people like you!), which is at the same time very exciting – because it's new and interesting and makes me want to get a better, deeper understanding on how the game works –, yet frightening too – because I start to see that it was really just dumb luck that made the changes I've applied actually work and that the probability of things going seriously wrong was way higher than I could've anticipated at the time.
Because that's the thing: it does work. In my game, on my system, mind you (I feel I should add that. Nobody has given me any feedback so far so I can only talk about my own experience). But the game runs the same way it would without thoses nondefaults (or without any CC at all, period), so it appears the changes don't bother it. It also doesn't seem to give a damn about a flagvalue of a non default eye color being the same as the flagvalue of a haircolor.
As an example, 0x0(...)0083 is the value of the haircolor_black tag, and one of my nondef eyes uses the same value, yet the game doesn't do anything weird like forcing a sim with those nondef eyes to have black hair or something like that.
-> Could it be possible that the individual tags are somehow "linked" to their respective categories, and that's why there is no (visible) conflict / weirdness going on? Like: - to stay with the earlier example - while 0x0083 is assigned to haircolor_black in the hair-category, it isn't assigned in the eyecolor category and therefore the game considers it a "free value", which is why this works?
Don't get me wrong here, please: I'm not gonna rule out the possibility that there's an inner conflict going on that somebody with my limited knowledge couldn't possibly be aware of (or find, for that matter). But if there is, I sure as hell don't have a way to find it, so searching for it on my own would be futile (I wouldn't even know where to start tbh)
Unrelated to the above, but perhaps this is interesting / helpful / mildly amusing:
- I assigned a couple of nondefs with values that weren't listed in your file – the last one on the list was 0x0(...)0499 so I took 0x049A, 0x049B & 0x049C. Those nondefs worked in the game, too.
(Though I don't know what happens when I save a sim with them and then delete them: whether that will "only" cause the conflict that occurs with any non default eye color, changed value or not (tldr: they're replaced by some sort of safety placeholder) or whether a more severe and destructive problem will occur. I'll test that later.) - I also tried to get those hazel, honey and golden eye colors to show up by assigning their values to some other nondefaults*. They didn't appear in the game, unfortunately, so I'm guessing they either 1) existed at some point and were scrapped, 2) are placeholders and those eyecolors are planned for the future, or c) are linked to a different category (under the assumption my theory of the values being linked to categories holds true).
Aaand that's it from my side so far.
I hope this is all understandeable. I'm having real difficulty explaining this in english (not my native language), hope the wording is okay and gets the point across anyway. If there's some gibberish somewhere, feel free to point it out, then I'll try and rephrase.
–
* Elaborating on this because it might seem unclear:
The initial observation I made was that when a sim would have a non default eye color that was cloned from a default color like e.g. eyecolor_black, (and thus has the same flagvalue as this default color by default, though I didn't know about that at this point), the child would inherit either the non default eyecolor or the black default eyecolor, hence „genetics are scrambled“ (from a user perspective) because the game would apparently recognize them as „the same“ and „group them up“. The more non default eye colors are cloned from eyecolor_black, the bigger the pool of potential colors (e.g. if it's 5 nondefs, that makes 6 possible eyecolors for the child if the parent sim has either of these 6 colors).
By that reasoning, I figured if I assigned the value of hazel, honey and golden and made some offspring in CAS, I might have the original eye colors show up because as I said, the game does appear to perceive them as belonging together in some way.