Hi there! You are currently browsing as a guest. Why not create an account? Then you get less ads, can thank creators, post feedback, keep a list of your favourites, and more!
Lab Assistant
Original Poster
#1 Old 18th Sep 2014 at 5:42 PM Last edited by plasticbox : 21st Oct 2014 at 1:28 AM. Reason: Yay categories!
Default Proper working genetics for non default eyes - how to
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:
  1. Open any non default eye color in s4pe.
  2. Select the CASP file and with it selected, click the grid-button at the bottom.
  3. Once the data grid opens, click on the "expand all" button at the bottom
  4. 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.
  5. 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
  6. 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)


Values I used for non default eyes so far


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
Screenshots
2 users say thanks for this. (Who?)
Advertisement
Inventor
#2 Old 18th Sep 2014 at 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:


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
Attached files:
File Type: zip  categories_and_tags.zip (16.3 KB, 56 downloads) - View custom content
Description: List of name and value for categories and tags extracted from the data files
Lab Assistant
Original Poster
#3 Old 18th Sep 2014 at 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
Inventor
#4 Old 18th Sep 2014 at 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.
Lab Assistant
Original Poster
#5 Old 19th Sep 2014 at 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.
Field Researcher
#6 Old 15th May 2016 at 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?
Back to top