PDA

View Full Version : Proper working genetics for non default eyes - how to


Helianthea
18th Sep 2014, 5:42 PM
Hi everybody,

since I haven't seen any mention of this so far, I thought I might share.
I'll keep this short: thanks to a user asking me how the genetics of non default eye colors work and me noticing I wasn't quite sure (apart from „they don't work like the defaults do, everything gets scrambled up“), I did some testing in the game, noticed a pattern in how the inheritance worked and started some research in s4pe. After changing quite a few parameters – with no luck – I eventually found what I think is the solution for non defaults being inherited in exactly the same way the default eye colors are inherited.

Here's how it works:
Open any non default eye color in s4pe.
Select the CASP file and with it selected, click the grid-button at the bottom.
Once the data grid opens, click on the "expand all" button at the bottom
Search the CASFlagList entries for the entry where the Flag Category is listed as "0x0048 (EyeMakeupColor)". Its location appears to not have a fixed position, so you might have to scroll a little.
Directly below the Flag Category you'll find the FlagValue, listed as "0x0077" (for example). This is the Value you want to change! The "0x" as far as I know shouldn't be changed, only the last four digits. I've only tried with the last two digits so far, which worked (below's a list of the values I've used and which worked for me), therefore I can only safely confirm those
Click confirm, save your package, done.
(Screenshots with step-by-step instructions provided below)

EDIT October 3rd 2014: put the values in spoilers for easier navigation & because the post looked bloated and ugly :)
The default eye colors have the following values (EDIT: now listed alphabetically + new eyecolors that came with 01/10/13 included)

amber: 0x0072
aqua: 0x0073
black: 0x0074
blue: 0x0075
brown: 0x0076
:new: darkblue: 0x0078
darkbrown: 0x0077
gray: 0x0078
green: 0x0079
hazelblue: 0x007A
:new: hazelbluedark: 0x007A
:new: hazelgraybrown: 0x007D
hazelgreen: 0x007B
:new: hazelolivegreen: 0x007E
lightblue: 0x007C
lightbrown: 0x007D
lightgreen: 0x007E
:new: purple: 0x0072
And yes, that means the new eyecolors don't inherit properly. You can try this yourself if you want to: create two sims with purple eyes both, make genetic experiments in CAS and marvel at the 50% chance of your offspring to inherit the amber eyecolor :)

Values I used for non default eyes so far

0x0081, 0x0082, 0x0083, 0x0084, 0x0085, 0x0086, 0x0091, 0x0092, 0x0093, 0x0094, 0x00A1, 0x00A2, 0x00A3, 0x00A4, 0x00A5, 0x00A6, 0x00A7, 0x00A8, 0x00A9, 0x00B1, 0x00B2, 0x00C1, 0x00C2, 0x00C3, 0x00C4, 0x00C5, 0x00C6, 0x00C7, 0x00C8, 0x00C9, 0x00CA, 0x00CB, 0x00CC, 0x00CD, 0x00CE, 0x00CF, 0x00D1, 0x00D2, 0x00D3,0x00D4,0x00D5, 0x00D66, 0x00D7, 0x00D8, 0x00D9, 0x00DA, 0x00DB, 0x00DC, 0x00DD, 0x00DE, 0x00DF, 0x00E0, 0x00E1, 0x00E2, 0x00E3, 0x00E4, 0x00E5

0x00E1 and 0x00E3 did NOT work with eyecolors! was an unrelated issue! They do work.

:alarm: 0x008A, 0x008B, 0x008E, 0x008F, 0x0090, 0x0093, 0x0119, 0x011C and 0x0122 should NOT be used according to velocitygrass' ZIP which you can find below. I used 0x0093, 0x008A and 0x008B without problems so far (still changed them, though), but I strongly advise against it, you'll never know what could happen in the future. Better not push your luck.

EDIT October 3rd 2014:With the new patch arrived a new, fancy problem: the new default eye colors inherit in a messed up way. By DEFAULT. This is not due to CC, or messing with the flagvalues or anything. They still do it if you remove all CC from your mod-folder.
As I have written above: e.g. purple and amber share the same flagvalue. Hence, 2 simparents with purple eyecolor both = kids gets either amber or purple.
That's the theory.
The problem is: It will only be the case if the offspring is female. If it's a male, however, he will only and exclusively inherit the amber eyecolor. Bottom line: male offspring doesn't inherit the new eyecolors AT ALL.
Why is that? Because the value set for agegender (found in s4pe in the CASP file in the datagrid) is listed as 0x0000207C for the new eye colors. It should be 0x0000307C, though (which is the default for all other eyecolors)
The solution is easy: replace the value in the datagrid. Tadaa - all's well again. Boys can have fancy new eyecolors now, too



So far I've only tested this with my own non-defaults and in my game only. It worked perfectly there - each eye color being inherited the same way the defaults are. Not giving an absolute guarantee because I haven't received much (or any) feedback on this yet - you're gladly invited to leave a note (PM works, too) whether it worked in your game or not.

Happy Simming,
Helianthea

velocitygrass
18th Sep 2014, 7:26 PM
Hi Helianthea,

there are two data resources about tag categories and tags in the game, S4_545AC67A_006CA304_D89CB9186B79ACB7%%+DATA.data and S4_545AC67A_006CA304_DDE418AFF7A9D9AD%%+DATA.data.

They list all the tags, e.g. for eye colors, I've found:

EyeColor_Amber: 0x0000000000000072
EyeColor_Aqua: 0x0000000000000073
EyeColor_Black: 0x0000000000000074
EyeColor_Blue: 0x0000000000000075
EyeColor_Brown: 0x0000000000000076
EyeColor_DarkBrown: 0x0000000000000077
EyeColor_Gray: 0x0000000000000078
EyeColor_Green: 0x0000000000000079
EyeColor_HazelBlue: 0x000000000000007A
EyeColor_HazelGreen: 0x000000000000007B
EyeColor_LightBlue: 0x000000000000007C
EyeColor_LightBrown: 0x000000000000007D
EyeColor_LightGreen: 0x000000000000007E
EyeColor_Hazel: 0x00000000000001A5
EyeColor_Honey: 0x00000000000001A6
EyeColor_Golden: 0x00000000000001A7


I've attached a zip with the complete list of tags and categories (including the other ones you mentioned) as text file.

It might be that not all tags are actually used in game, but it should be a guideline and make it easier to identify tags and categories.

Regards,
velocitygrass

Helianthea
18th Sep 2014, 7:58 PM
Woah, this is cool :O Thanks for sharing.

I do have a question, though (I know nada about all this stuff btw, so the question might be utterly stupid):
I used, for example, the value 0x00C1 for a nondefault eye. Just stating this again: it works fine in the game, game runs no problem from what I can tell.
However, in the S4_545AC67A_006CA304_DDE418AFF7A9D9AD%%+DATA.data document you zipped, I found this:
EnumNameValuePair[130]:
Name: String at pos: String: BuyCatPA_MiscAppliance
Value: Value: 0x00000000000000C1

With the value being the same – yet me not having noticed the game doing any weird stuff – is it safe for these values (I suppose they are the "FlagValues" in s4pe?) to be the same if they are on different Valuepairs (I suppose that is the "FlagCategory" in s4pe?) or is there some inner conflict going on in the game I might not be aware of?

On a sidenote: do you know why s4pe only shows up the last four digits for the eyecolors? Because apart from your Values having a lot more zeroes, we both got the same (not counting hazel honey and golden I didn't even know existed until now).

Thanks ahead,
Helianthea

velocitygrass
18th Sep 2014, 10:17 PM
S4PE only displays the last four digits because that's how it's stored for CASP, where as in the DATA resources they stored this in longer fields (not sure why).

I'm not entirely sure what the consequences might be of re-purposing unrelated flag in a different category, so I'm afraid I can't answer that (if I understood your question correctly). Another possibility might be to add entirely new tags though I haven't tested this, and even if it works, it would bring the additional challenge that you could e.g. add 0x1001 as EyeColor_Purple, but someone else might use it as something else (and even EA could introduce new tags if expansions make them necessary). I wonder if new categories might be a solution to this, but again, I haven't looked into this at all, so I'm not sure how/if that would work and how to activate genetics taking such new categories into account.

Helianthea
19th Sep 2014, 2:22 PM
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.

Godzilla-Force
15th May 2016, 9:58 PM
I've attempted several tries to make a Alien Non-Default eyes work but no matter what I do they don't show up in game, in fact any alien non default eyes that I downloading untampered don't appear in game either?