Jump to content

Recommended Posts

WORKING BETA 0.90 available for download.

http://www.loverslab.com/topic/44290-hiyoko-generator-dev/?p=1137422

 

 

Guys,
I've been messing around some hiyoko stuff for past few weeks.
I made several size variants of existing head meshes - meaning x100, x110, x117, x125 versions of a few of known heads. Vanilla potatoe head, khajiit and argonian heads, ren head, lop-eared elf head, evy head, orky head.
So what are those heads for... I wanted to make a kind of growable/breedable hiyoko generator mod. Using blockhead. So, we can simply swap their head mesh whenever they grow up to a certain height.

Being able to replace the head assets on the fly with blockhead gives you an another possibility. You practically don't need to rely on any fixed in-plugin race record. That means arbitrary combinations of genetic characters is possible.
For example...
When you screw a khajiit, as a human character, you'd expect a cute nekomimi daughter. (This is not exactly lore-friendly as the khajiit's apparence solely depends on the moon at the moment they are born, but who cares that) Should this girl come to have a baby in the future, your granddaughter may either be a bit more like human or a bit furrier, depending on who's her husband.
If you have sex with an elf, you'd expect a half elf. The ones that have relatively handsome face and a-bit-elvish ears.
If an elf marries with an orc... perhaps a green skin baby with pointy ears. or, maybe orc face with pink skin.
This is possible, although in practice we can't make every single resource compatible to each other. But still possible.

That was the good story, but actually I'm kind of stuck, because I need to make npcs. As many npcs as possible needed for a convincing hiyoko mod. (preferably the ones that look beautiful too, I know y'all want cute kids)
And I hate doing facial plastic surgery for hundred of hours. So far I made a grand total of 13 facial variants. I would appreciate if you provide me a save file of your character (or any others' you've happened to collect, for that matter), if you have a save file of any of the races below. (Mostly from MBP)
 

- lop-ears elf family (lop-ear06, lop chocolate, argonoid, but NOT lop-ears elf II) from x117.esm or MBP
- ren head family (including ren mystic elf family, tabaxi family)
- unmodified vanilla races
- evy race


Plus, as each race has 4 different head variants, hair meshes are going to be a problem. There are a lot of hairs out their and I may have to include x4 of them. I've been pondering if instead 'borrowing' rigged wig meshes from other plugin (like my x110/x117 wig mod) would be a good idea or not. In this way it's very easy to swap their hair as it's just an item, and wigs are rigged that's definitely better, but in this way hiyoko generator will require some external wig mod(s). I want to have your opinion about this, and other matters.
 
*Edit*
 
Fully grown up faces. Some races may look different when young because I made some of the younger version head meshes more round-shaped than grown-up counterparts.
 
post-39899-0-20227100-1426248022_thumb.jpg
Beast faces, exclusively used for each race
 
post-39899-0-78294200-1426248050_thumb.jpg
Orc faces, exclusively used only for the Orcs.
 
post-39899-0-26847900-1426248055_thumb.jpg
Redguard faces, exclusives used only for the Redguards.
 
post-39899-0-58957100-1426248038_thumb.jpg
Human faces, shared among man races that use the stock head mesh.
 
post-39899-0-70417400-1426248044_thumb.jpg
Elf faces, shared among mer races that use the stock head mesh.
 
post-39899-0-73352300-1426248026_thumb.jpg
Chocolate lop faces, exclusively used for the Chocolate elves.
 
post-39899-0-17255400-1426248059_thumb.jpg
Ren faces, shared among Tabaxi family that use Ren head.
 
post-39899-0-09636100-1426248032_thumb.jpg
Lop faces, shared among lop-ears elf family.

Link to comment

Reads as promising, I like the crowd sourcing approach too.  ;)

 

I may have some in the lop-ears elf and ren head families to contribute. I have to check if I can still load them okay with current MODs active or disable a bunch of crap first, so maybe a couple to few days on that. I could also maybe do some other quick variants of those too, especially in the lop chocolate area.

 

What do you mean by unmodified vanilla?

 

All of my Evy are fairly generic so no help there.

 

Concerning hairs/wigs I have always felt that an ESP-as-database approach as an improvement, if that is the direction you are going in.

Link to comment

The only thing I want is a load order independent hiyoko Generator without extra installations ( MBP or other race Mods). A "all in one" Mod .

And children of vanilla NPCs should look like (a little bit ) as vanilla races, so no Wood elf, high Elf and Dark Elf children with "lop ear" ears.

And if the Generator does not use the unique Player race data a Option to select the children race for your Player.

Head mesh...i don't care. My favorite Player race use Digital head , so my head textures fit for no other heads. But my children must not look like my Player ... born with all my Body and faceTattoos is very unrealistic.

 

At the Moment I play without a hiyoko Generator.esp  , only with the Hiyoko Generator Brood Mother esp and 100% creature children.

Link to comment

Reads as promising, I like the crowd sourcing approach too. wink.png

 

I may have some in the lop-ears elf and ren head families to contribute. I have to check if I can still load them okay with current MODs active or disable a bunch of crap first, so maybe a couple to few days on that. I could also maybe do some other quick variants of those too, especially in the lop chocolate area.

 

What do you mean by unmodified vanilla?

 

All of my Evy are fairly generic so no help there.

 

Concerning hairs/wigs I have always felt that an ESP-as-database approach as an improvement, if that is the direction you are going in.

Awesome. I could use Evy's too, by the way.

 

'unmodified vanilla' refers to the vanilla races without too much radical changes. More specifically, races that use unmodified or only subtly modified stock head mesh and that are not from nuska's oco mod.

Actually, this doesn't matter much, facegen is accepted no matter what head was used when making it up. But I'd prefer the same kind of head mesh. A once-beautiful face could look totally retarted if transfered into a radically different head mesh..

 

And I don't think you have to re-save the game before sending to me. As we had figured out before, later bash should be able to handle that. Just be clear about what master file I have to use when porting the face into plugin.

 

And if the Generator does not use the unique Player race data a Option to select the children race for your Player.

That should be handled properly.

So.. probably, dunmer + dunmer, imperial + imperial, or any other couple of the same race would result the same race. What I can't guarantee is the case when the child is half-blooded. I'll probably make blue skin lop-ear when dunmer + imperial or something like that.

Because, lopies have many ear variants. 3 lenth variants and 3 angular variants. I'm not certain. That's kinda unpredictable as i'm planning to make this process almost arbitrary. If possible, of course.

Link to comment

I wouldn't mind contributing, or at least helping you within the limits of my current modding abilities, but I would have the same request/preoccupations as Fejeena :

 

The only thing I want is a load order independent hiyoko Generator without extra installations ( MBP or other race Mods). A "all in one" Mod .

And children of vanilla NPCs should look like (a little bit ) as vanilla races, so no Wood elf, high Elf and Dark Elf children with "lop ear" ears.

And if the Generator does not use the unique Player race data a Option to select the children race for your Player.

 

I use OCOv2, and would want my hiyokos as either OCO cross-breed (altered Nuska's races), or maybe extrapolations of Emma's children (if and only if her permission can be obtained). I don't really care about support of custom races, since even if my PC is a MS elf, I (and modded my game to) consider her to be a Bosmer.

 

Does this remain within your plan, or do you aim only for more/better MBP hiyokos ?

Link to comment
And I don't think you have to re-save the game before sending to me. As we had figured out before, later bash should be able to handle that. Just be clear about what master file I have to use when porting the face into plugin.

 

Understood. It's more a matter of if those very old save games (a couple to a few years) will open with my current Oblivion config.

 

I'll try to add in some AIRrace Evy Fenbo (my preferred version) then too. The head to body textures although improved are IMO still going to be a bit wack for them. 

 

And just a quick note. There is a MOD, I forget the name again that acts as a sort of ESP-as-database for hairs. I know you already have the wig MOD, but this may be something that could be quickly re-engineered/re-purposed for what you are trying to accomplish. If useful I'll try and locate it.

Link to comment

I've never said it will require mbp. Actually I want to, but I won't. I know some of you outright hate mbp.

I may separate each race's asset folder so you can replace them yourself (if you can make size variant), but other than that I have zero plan to support oco any further. I won't benefit from doing that and I don't like oco anyway.

 

As to moonshadow race, they won't be suppored as they are head06 and not compatible with others. I may even remove evy too if it turns out to be too problematic as evy alone is not compatible with everything else.

 

Some other races.. I wanted to include ff race too, but unfortunately ff head is not editable. And ff head uv is not compatible just like evy. that's a problem. Nuska's khajiit head is not editable too, by the way. There are a few head variants that are not editable once ever exported by creator.

 

Are there any important vanilla-oriented heads (that have exactly 1275 verts) that I have to take a look?

 

*edit*

I forgot to mention. Emma's coc are just resized vanilla dudes. I just don't understand why she had to include separate head assets.

Link to comment

I am glad and grateful that you allow for most people to take advantage of your mod(s).

 

About Emma's children, as I understand it, she has done quite some research. Here is one recent link :

 

http://forums.nexusmods.com/index.php?/topic/2635069-children-of-cyrodiil/page-8&do=findComment&comment=23144389

 

but I recall reading more than this source where she talks how she proceeded to create her mod.

 

I am fairly sure there is more to her meshes than just resizing vanilla ones.

 

Given some time, I may look for these extra sources, and complete the above.

 

Once again, thank you, Movomo (EDIT : for taking this approach).

Link to comment

Nah, if you read that post, and examine Emma's coc resources, you'd realize that even a famed modder can't be good at everything. Modeling is not one of what she excels at.

 

First, just open the head meshes in there and take a look. For head (and hair, eyes... for that matter) meshes, if it looks the same and has the same vert count as the stock one, it's unmodified. There are very few ways to actually modify the head mesh other than sclupting it. Remove one vertex, you'll end up remaking dozens of facial expression morph (as head06 and digital girl did). Add one vertex, you don't technically need to rework morphs but that very vertex will become a defect because it won't move. If you apply skin transform, like x117s do, you'll immediately notice the change because the head has to be sculpted anyway. And they are not x117... actually they are not even resized vanilla ones. They are just vanilla ones.

 

Then look at those children's body texture like footfemaley.dds thingy. and examine clothing meshes. I don't know who thought that would be a good idea, and I kinda understand 'why' they tried such thing, but whoever did that it's a bad idea. And those 'fake skin' parts in some of the clothings... Seemingly she intentionally did not enable skin shader on some of them to apply different skin texture than what's defined in the race record. It's a bad idea, too.

 

That, and the fact that she's being extra careful at applying x117 resources (mostly because children faces may look radically different on x117 heads; It's a legit concern if she didn't know exactly what's x117), make me think that the only reason she included the unmodified dupes of stock head assets is to prevent the kids' faces from looking different in case the user is already using some other stock head replacers.

 

Well, if so that's understandable I think, because many folks today apparently use oco things. I'm not here to diminish Emma's CoC despite what I've said above. That was just random technical murmurs. My point is I don't quite certain what does 'extrapolating' CoC mean.

If you meant making it compatible with CoC, there's no point in that because CoC already uses stock heads like this mod. If importing their dialogs and voices is what you intended, well that would be cool, to be sure, but difficult. It means copying entire dialog and related things into hiyokoclub system from there. Furthermore... the 'hiyokoclub' we're talking about is a part of 'sex mod' and it's somehow related to 'children'. Terrible terrible combination to seem innocent to non-believers.

Link to comment

I'm not really into any of the pregnancy plugins, but I'm offering to help out of sheer respect for your contribution with Setbody.

 

I can send you an esp with a couple of characters an... Acquaintance of mine has very generously provided me to do with as I please.

However, the characters are exclusively of either the Xenius Race Compilation, Lattamer v3 or Moonshadow Elves race mods.

 

I'm not much good at identifying head models; so if you think they match, let me know and I'll send you the esp via PM. If not - then I'm afraid I can't help you.

Regardless, good luck,

-V

Link to comment

Cool!!

.. or so I meant to say. Turns out that they are head06, all of them.

 

That's shame, incompatible UV map makes the scripts much more complicated.

Maybe pretty much everyone these days almost never bother using stock head races anymore and I'm too oldschool.

But thanks very much for your offer, regardless.

Link to comment
  • 2 weeks later...

BAD. NEWS.

 

I've found a rather embarrassing bug in HiyokoClub.

In theory, hiyokoclub is supposed to work with multiple(3 or more) hiyoko generators. In reality, it doesn't.

In fact many of you are already running two generators, "hiyokogenerator.esp" (which is default hiyokoclub bundle) and Wappy's HGBM. In this case hiyokogenerator.esp is the default generator (that could handle every possible case) and HGBM or hiyokogeneratorCreature.esp overrides the default generator whenever the creature birth is involved.

So if HGBM fails to generate any hiyoko, then the default generator kicks in. Default generator begins its job only if none of the other generators came up with a meaningful result.

 

The problem is, hiyokoclub goes postal when it merges the hiyoko "nominees" arrays into one. You pass a couple of dudes through your event handler, that's no problem. But someone else passes an empty array at the same situation, things go chaos. HiyokoClub doesn't know how to handle that and the data get corrupted.

 

Like this.

 

; Working case
[hiyo1, hiyo2]      ; you return a valid array
[hiyo1, hiyo2]      ; HiyokoClub merges it into an empty array, no problem.
[hiyo4, hiyo5]      ; the other mod returns a valid array.
[hiyo4, hiyo5, hiyo1, hiyo2]    ; Yep, no problem.


; Not working case
[hiyo1, hiyo2]      ; you return a valid array
[hiyo1, hiyo2]      ; HiyokoClub merges it into an empty array, no problem.
[]                  ; the other mod returns an empty array.
[corrupt_data1, corrupt_data2]  ; Yep, you're doomed.
This is a very very simple mistake to fix (I don't even know why it doesn't work, it's kind of OBSE bug)

But I can't, as this is HiyokoClub main plugin's bug.

 

So now, I have two choices.

- Release a modified version of HiyokoClub and tell folks to use that instead.

- Or, give up making an add-on type generator, and simply make it a default generator, then it will replace the bundle hiyoko generator you have.

Link to comment

thanks movomo    

 

i  had an impossible crash .   i was sure it was hyokoclub  (say it is intuition) .  but could not follow the scripts  (too complicate for me)

 

if  you decide not to release a modified version .  please can you specify  where and how to fix

 

thanks

Link to comment

Err... nobody has sent me any save file, I guess I'm on my own.

 

Anyways, I updated the OP with pictures of the faces. So far I have 84 faces in total. Except Evy race.

 

Only because I am super super busy. That and I do want to review stuff before posting/sending it your way is all. I'll get to it, eventually. I'll work on Evy ones first.

 

 

 

So now, I have two choices.

- Release a modified version of HiyokoClub and tell folks to use that instead.

- Or, give up making an add-on type generator, and simply make it a default generator, then it will replace the bundle hiyoko generator you have.

 

Choice 1 and I'm assuming you mean the ESM, IF and ONLY IF it remains backward compatible to everything else.

Choice 2, With all of my edits to my current generator, I'd never replace it with something else. And correct me if I'm wrong, but are you planning to provide a "default" replacement for the 'core' Justinof's, Purveyor's AND non-MBP generators?!!!

Link to comment

thanks movomo    

 

i  had an impossible crash .   i was sure it was hyokoclub  (say it is intuition) .  but could not follow the scripts  (too complicate for me)

 

if  you decide not to release a modified version .  please can you specify  where and how to fix

 

thanks

In HiyokoClub.esm, there is a script named "a4hcfGenerate", and it calls an other one named "a4hcfDispatchEventA". These two are the direct causes of this problem.

There you will find several lines that read something like

ar_InsertRange ahiyo 0 Call a4hcfDispatchEventA "Generator" 0 argv
This ar_InsertRange function is dangerous, if the inserted array (Call a4hcfDispatchEventA "Generator" 0 argv) is empty then the target's (ahiyo) contents get corrupted. If ahiyo is already empty that's ok (apparently), as there is no data to be corrupted.

One of the solutions would be to correct them like this.

Let some_new_array := Call a4hcfDispatchEventA "Generator" 0 argv
if 0 < ar_Size some_new_array
    ar_InsertRange ahiyo, some_new_array
endif
Well, I haven't tested. But this should work.

I'm not sure if this is the cause of your ctd, though. This does cause ctd once the corrupted hiyoko is chosen, but otherwise it's fine. This only happens when you have more than one non-default generators.

 

Choice 1 and I'm assuming you mean the ESM, IF and ONLY IF it remains backward compatible to everything else.

Choice 2, With all of my edits to my current generator, I'd never replace it with something else. And correct me if I'm wrong, but are you planning to provide a "default" replacement for the 'core' Justinof's, Purveyor's AND non-MBP generators?!!!

Ok, a bit more explanation.

The non-default generators "override" the default one. In this case, (if I make mine non-default), default generator is no good as it won't do anything.

 

Firstly, HiyokoClub calls (dispatches) its registered non-default generators. (this is where HiyokoClub screw things up attempting to merge the results)

Next, if the above's result is completely empty, then it finally calls the default generator. Default generator is there as a fail-safe, the last resort, when everything else fails and all hope is lost. Therefore the default generator must be malleable and must return at least one hiyoko under any circumstances. (HGBM ignores npcs, mine ignores creatures, but a default generator shouldn't ignore anything.)

If at least one of the non-default generators has yielded any hiyoko, then the default generator does precisely nothing.

 

My point here is your default generator becomes practically inactive regardless the new one is an add-on or a default generator replacement.

One solution is, you can modify those default generators again and change them to non-default. Then they can get along.

Link to comment

Thanks movomo  

 

i will try this  when  i will have time  (next week i think)  .

 

i am sure it is that as i am using no mbp generator and hgbm    with mbp.esm modified  from where it can get data  but will be corrupted to generate default.

 

and from what i understood hgbm revealed the probleme but do not cause it.

 

thank again  i will give feed back shortly.

Link to comment

Yep, HGBM is not the cause of any problem (so far, at least). HiykoClub itself is unintentionally being the problem.

 

More on generator types.

They are separate kind of event handlers. "DefaultGenerator" for the default ones, and "Generator" for the non-default ones.

 

Here's how does a default generator look like:

Call a4hccSetEventHandler "DefaultGenerator" a3hgDefaultGenerator
Hiyokoclub bundle version, non-MBP version, Justinof's, Purveyor's, they are default generators. Probably.

 

And here's how does HGBM's look like:

Call a4hccSetEventHandler "Generator" a3hgbmGenerator
Functionally, they are identical. One can switch their type anytime very easily. But internally they are treated differently.

Well, the only difference is, default generators are ignored if 1. a non-default generator is present, 2. and it successfully generated at least one hiyoko at the given situation.

 

So, the basic idea of the original creator is presumably something like this.

 

- Seems like I have to make a generator, but it's surprisingly labor-intensive and I'm too lazy.

- Then let's make it very very simple, like simply copying one of the parents' reference (which is essentially what the non-MBP default generator does)

- but some may want to have more sophisticated thing that works under more specific circumstances, like when the parents are a creature or custom race.

- Let them do their job, but in case they give up working we still need a basic, guaranteed-to-work one.

 

And so are the two types of generators here.

And I think it's a good idea. Except, it's not working.

Link to comment

Ah, that is beginning to make much more sense now. So is the only non-default generator in existence today HGBM?

 

Some of this explanation (your last 2 posts), makes me wonder if this is why some Hiyoko races seem to occur more often than others, i.e. this is contributing to that.

Link to comment

Plus, the old hiyokogeneratorcreature.esp, which is obsolete at this point, but it's non-default too.

 

I assume you are using only one default generator (though technically you can use multiple default generators at the same time), then it's totally up to how its logic of selecting hiyoko is set up.

 

On the other hand, when multiple generators are working together, it also depends on how many nominees each generator nominates.

- generator 1 attempts to nominate an appropriate type of hiyoko, and always nominates only one.

- the maker of generator 2 was a khajiit lover, and it always nominates 9 khajiit hiyokos no matter what.

- then by 90% chance you will see khajiit hiyoko, no matter what their parents' races were.

Link to comment

i do not know if i did wrong  .    i do not have any save to load (it means i need to wait pregnancies and deliveries ! )

 

i have added your line like this

Begin Function { argv }
	let ahiyo := ar_Construct Array
	let i := ar_Size ahiyo
	if 0 < i
		ar_InsertRange ahiyo 0 Call a4hcfDispatchEventA "Generator" 0 argv
	endif

i radder  be riddiculous than die stupid !!!

 

does this line would result in anything good or is it meanigless ?

Link to comment

It matters where exactly you check the size of the array.

ar_Construct function constructs an array. That means the ahiyo array is empty (size of 0) right after it is created. And checking the size of an array that was just created doesn't do much useful. The point here is to ensure that the array you will insert into the ahiyo array is not empty.

 

Call a4hcfDispatchEventA function returns an array, so what you have to here is to ensure this array is not empty before inserting into other array.

 

Actually, a4hcfGenerate is fine (because it will not attempt to insert an empty arrya into a 'filled' array anyway), a4hcfDispatchEventA is the one that is not fine.

	while i > 0
		let i -= 1
		let rFunc := a[ i ]
		if GetSourceModIndex rFunc != -1
			Let temps := Call rFunc, 0, argv
			if 0 < ar_Size temps
				ar_InsertRange ret, 0, temps
			endif
		endif
	loop

This is the loop part of the hiyokoclub event dispatcher. That rFunc variable refers to the event handlers the clients had registered, and they may or may not return an empty array. So better make sure they are not empty, before inserting them into something else.
Link to comment

Anyways, seems like I'll have to include the real hair resources instead of fancy rigged wigs.

I wanted to resize my wig mod and make x100 & x125 versions of them, but when I opened that wig folder I got overwhelmed. Hey, it was 197MB!! No I can't do that again.

 

So now I have to find a free-permission, decent, and not overly-huge hair collection that preferably share textures so that I can reduce the download size.

Link to comment

Ok, now I at last have a working beta version.

I'll go about a play test from now on, before I upload this on the LL download system. So far it's been stable under 'fabricated' situations - very short pregnancy length, 100% chance of getting pregnant and high twins ratio, incredible growth rate, etc. I've resolved a couple of ctd/typo issues or two and I think it's fine now.

So, it's ready to be tested.

http://www.mediafire.com/download/aj7c0ic9xk8wwgo/HiyokoGeneratorGeneForge_v090_BETA.7z

Now some explanations...

You MUST read the README.txt before installing this. I don't include a readme in my mod very often, I generally prefer a forum thread but this is a special case.

REQUIREMENTS

Oblivion (I'm not kidding, I'm assuming you have Oblivion.esm and some of the stock assets.)
OBSE v21
HiyokoClub 1.10a (and naturally TamagoClub 1.15c and LAPF as well)
Blockhead v8.1 or higher.

+ HiyokoGenerator.esp (explained below)
+ Preferably Conscribe because this is a beta version, without it this mod won't tell you much information.

DESCRIPTION

This is NOT a replacement plugin. This is meant to be an ADD-ON type mod. The reason is because this plugin does not care about creatures.
This mod borrows some misc functions (like name database) from the original HiyokoGenerator.esp. So you need it. Don't disable it, the existing one will be practically suppressed once you install this mod but you still need it. It is by design.

What does this mod do?
Well, this mod generates hiyoko. That's the most basic functionality, but this mod goes a bit further than that.

1. HiyokoGenerator GeneForge allows you to 'breed' people.
If two people from different races meet and make love... well, you'd expect a half-blood child. Now that actually happens with this mod.
I do not know whether he/she will be a romantic fruit of love, or an abomination, that depends, but I worked hard to prevent abominations. Thinks like khajiit body texture with human head texture won't happen.

2. HiyokoGenerator GeneForge make hiyokos 'grow up'.
They grow over time. by default it takes 40 days for them to be fully grown up, but it can be configured by a .ini file.
At first they are 0.60 scale (x125), and as they grow up, their head-body proportion also changes (x125 -> x117 -> x110 -> x100).
Once they all grow up, they might look different than when they were young. Younger heads are usually more round shaped, while older heads look sharper.

3. A lot of hiyokos
There are a total of 100 face presets in the mod. These produce much more combinations because the same face can look different if the head mesh is changed.
They aren't necessarily pretty, just diverse. Basically I tried to conform them to the game world.

I suck at facial work to be honest. So if you want to improve their lookings, it's certainly welcomed. A couple of other people kindly gave me their save files but I haven't incorporated them yet. It will be updated later.

Link to comment
Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. For more information, see our Privacy Policy & Terms of Use