TamagoClub 1.15c / HiyokoClub1.10a stuff ENG

[mem4ob4]

sorry, edited above post while you were posting varenne.

I will strip the scripts and see if any are odd.

Mem

[varenne]

sorry, edited above post while you were posting varenne.

I will strip the scripts and see if any are odd.

Mem

 

I know for sure that for Hiyoko Generator (Justinof) I will on rare occasion get a mohawked Hiyoko. Not sure if others consider that a male hair or not.

 

EDIT: and in my list above 1 thru 3 are MBP/117.

[mem4ob4]

all the SetHiyokoHair functions are the same so same code structure 'should' work in any of them.

As I said above though, the MBP etc may want to be added in the checks with the same format, otherwise it will be just like original code (pick random from list of all hairs for that race).

 

I will go swimming later this eve and see how a birth goes. They are born at 0.8 scale for noMBP version.

Feels so wicked drowning hiyos for science...

 

Mem

[varenne]

all the SetHiyokoHair functions are the same so same code structure 'should' work in any of them.

As I said above though, the MBP etc may want to be added in the checks with the same format, otherwise it will be just like original code (pick random from list of all hairs for that race).

 

I will go swimming later this eve and see how a birth goes. They are born at 0.8 scale for noMBP version.

Feels so wicked drowning hiyos for science...

 

Mem

 

LOL!

 

Confirmed, Agonoids have this ability at the race level, just like Argonians so they won't need the ability added. (I did notice it would not 'easily' follow my PC into the water. I had to use a MCS call to get it where I wanted it. I may need to look into Hiyoko AI behaviors for water too.)

 

I only discovered this issue with Hiyokos about a week ago, while play testing Amazones_Nest.esp. Not recommending as it has other issues and I've since disabled it. When a certain group of 3 Amazons had Hiyokos I witnessed one drowning as it would follow it's parent Amazon into the water, run out of mana and not be able to heal and eventual died from drowning. So sad...

 

Plus as mentioned, I'm expanding the Sirens and Tritons CM Partners-19247 MOD so they have new swim AI cycles that take them along the coast and up the rivers of Tamriel. Very much like the CM Partners set of MODs, and From 2ch Lives! NPCs that have walk cycles that move them about Tamriel.

 

Chances are the Sirens will eventual have Hiyokos themselves and I want them to be able to survive. Still have to figure out if I need to specify them getting mermaid tails and abilities...

 

Fun stuff.

 

[varenne]

I did a quick review of a few NPCs, City Swimmer in particular, and none of their AI includes a Wander cycle that involves Allow Swimming checked, which I find very interesting yet perplexing.

 

I may run a new test with a new AI package for just Allow Swimming checked just to see if it has an affect on Hiyoko behavior to follow a PC into the water.

 

EDIT: I did another review of one of the more sophisticated companion MODs, Vilja plus the companions added by Sirens and Tritons CM Partners-19247 and they do have an AI package for Wander that includes Allow Swimming, among others.

 

Definitely going to edit my HiyokoGenerator 'core' NPCs so that future generated Hiyokos will have a bit more advanced AI than what currently exists.

[badbat111]

how long does it take for a new born baby to reach adult ? or increase in size

[fejeena]

 Have not found the HiyokoClub  values but if you use Hiyoko Generator Brood Mother children reach full size in 14 days.

[movomo]

Human kids don't grow.

[tetigistus]

I'm using HiyokoClub110a Rev1 and the generator included in it (the MBP one), and finding hiyos of two human parents are often those lop-eared elves or whatever they're called.  It's a bit odd.  Is this normal with that generator?

[movomo]

Because there aren't too many x117 races. Lop eared elves roughly look like human, so it is possible. If not you'll get mitza, champon etc.

Other x117 races such as argonoid/ tabaxi are for beast races.

[varenne]

For the existing 'core' HiyokoGenerators I don't recall there ever being a growth cycle, they are born full size of the race they are based off of.

[varenne]

I'm using HiyokoClub110a Rev1 and the generator included in it (the MBP one), and finding hiyos of two human parents are often those lop-eared elves or whatever they're called.  It's a bit odd.  Is this normal with that generator?

 

Yes, I found it was quite common with the way those scripts were written in that particular generator.

 

There was a discussion a while back to expand on that, in either this thread or in the prior versions thread, I forget which. I recall testing one suggested implementation and it did work. But to really see the affect of it, it needs more x117 Hiyokos created, added to the HiyokoGenerator.esp and then added as options to the scripts. That was where I last left off with it, well over a year ago.

 

I have recently been revisiting this, to see how hard it would be to create more types of Hiyokos, and it doesn't seem all that hard, just a bit tedious.

 

[tetigistus]

If you wanted to do it, varenne, it would definitely be an improvement to what exists now.  It'd be nice not to see elves generating all over the place, with everybody, including argonians.

[movomo]

If you wanted to do it, varenne, it would definitely be an improvement to what exists now.  It'd be nice not to see elves generating all over the place, with everybody, including argonians.

Indeed, it would be good to have new hiyoko generator.

- capability to use various race assets such as common x117 and other mini races, while NOT explicitly requiring any of them

- diverse faces

- growing children, use blockhead!

I'm willing to help, except for the facial works

[varenne]

 

If you wanted to do it, varenne, it would definitely be an improvement to what exists now.  It'd be nice not to see elves generating all over the place, with everybody, including argonians.

Indeed, it would be good to have new hiyoko generator.

- capability to use various race assets such as common x117 and other mini races, while NOT explicitly requiring any of them

- diverse faces

- growing children, use blockhead!

I'm willing to help, except for the facial works

 

 

I just took on a small but tedious task to help out with updating LoversIdleAnimsPriority.esp for Lovers Creatures animations. I can take a more detailed and in depth look at what I'd need to do after that is done.

 

@ movomo specifically - I have zero knowledge about blockhead, so my current approach would be old school.

 

1. Use existing x117 head mesh, etc. and create new race using alternate textures.

 

Example: Using x117Human (uses Imperial texture currently) create additional x117Human races for Redguard, Breton, etc.

Current x117Race & head mesh used list:

 

 

117Argonoid                L-eE_Head003.nif

117Beast                     Ren_Head001.nif

117ChanponxAL1        x117headchanpon.nif

117Human                   headhuman.nif

117HumanLopEar        headhuman.nif

117LeE05                     L-eE_Head003.nif

117LeE06                     L-eE_Head003.nif

117RenMElf                  Ren_Head001.nif

117RenMElfLopEar       Lop_Head001.nif

117SlimD105                 headSlimX105D.nif

117SlimE105                 headSlimX105E.nif

117SlimF105                 headSlimX105F.nif

117SlimF110                 headSlimX110F.nif

117SnowTabaxi             Ren_Head001.nif

117Tabaxi                     Ren_Head001.nif

117WhiteTabaxi            Ren_Head001.nif

117WildTabaxiWH         Ren_Head001.nif

 

 

 

This would simplify things as I would not need to muck with eyes and ears and proper sizing and placement. That IS the single biggest challenge with creating new x117 races; heads are different sizes vs. adult NPCs, eyes/ears are placed or positioned differently to adjust for sizing differences too. This is why some (most?) of them look funky when viewing the head models in CS/CSE, but not if you view the full body.

 

2. I would also opt to minimize facial work and reuse existing face textures...

The 'core' new race could be tweaked via CS/CSE, so it's not the core generic ones you see all over the place. I was reviewing this today; which face textures do I currently have, what are the best to use, etc. I have a preference for mid to high resolution.

 

This is an alternative to trying to understand and implement PerfectionCat's Child database, but there too you still need to create individual child races too (as separate ESPs), so it's pretty much an alternate path to achieve the same result.

 

I'm already working on one for producing Siren & Triton Hiyokos, so that is where my initial efforts and testing would be. (I'm creating my own expansion for the Siren & Triton set of MODs.)

 

I assume these new races would be part of an expanded HiyokoGenerator. Separate ESPs, such as Child Database would be too much (which is why I didn't pursue that path), and limit those who could use them too; already too many ESMs/ESPs.

 

Thoughts, input movomo?

 

[movomo]

That was a much more detailed plan than I thought.. I only had a vague imagination of what it would be.

 

Blockhead's body asset swapping is very very simple, as simple as adding an item to your inventory or that sort of thing. (though I'm not sure if there is a bug in head swapping - see the blockhead thread in LL)

My plan was to copy as many as existing mini races to this plugin, so it won't require any other race mod such as MBP. Copy races, copy racial abilities, etc. I don't know how exactly lovers child database works. I haven't even tried it to be honest. But anyway I want to replace both the hiyoko generator and the LCDB with this single plugin.

 

So.. firstly you'll need some logic to determine which child race will be born from which adult race. Once that is done, you'll create an array and build a very similar database as Perfectioncat's LCDB there. Then, after several game days passed, you swap their head assets and re-scale, according to the pre-set data.

 

After the whole system is built, you can import all the facegen data from your save files. You only need the smallest size npc(x117 or x125 if you really feel ambitious) for starting hiyoko's. Need a new size head mesh like x110 or x105? Leave it to me.

 

By the way, one troublesome thing I've found is that, x117 races *look* like very similar and sharing the same eyes/mouth position each other, but some of them aren't. I had discovered that crap while working on x110 races before.

[varenne]

Like I mention above, I've thought about and through this quite a bit. The limited races of hiyokos has always been somewhat bothersome as it could and should be much more robust, IMO.

 

I know there are very specific ears for some x117 heads, eyes, eyelashes, and most definitely hair models too. Not sure about mouth/teeth assets yet, some I know are based on vanilla assets. The blockhead route would I think allow for collecting and using all assets, where before you had to chose one or the other for the mini Lop ear elves. So this could go even further than current MBP++ x117. Some combos of assets would need to be avoided, just like what feejena was asking about making some hairs male only in another thread.

 

As far as logic to determine parentage vs. hiyoko there is a basic script previously built in one of the threads. Not fully fleshed out mind you, but a good start and idea of what would need to be written, dependent on the number of races to be covered. Personally since you're aiming to get away from MBP flavored hiyokos (it make others happy I'm sure) I'd target vanilla races first. Then build out the 'core' elvish ones next, followed by Tabaxi.

 

That alone will be a few weeks work, IMO, focusing on two parameters. If both parents are same race, 100% hiyoko same. If a 50/50 parent mix, then a random chance of either.

 

I think from your description and my very very basic understanding of Blockhead, where it would shine is producing hybrids maybe. This could be something like an inherited mix form both parents. Very complex logic that...

 

 

[varenne]

I wanted to see just how long it would take me to create two new hiyokos for my expansion of Sirens & Tritons.

 

About 3 hours, just to create, add and edit the script. (Which already had an error in it and wouldn't compile till I fixed it, hopefully... Good thing I use CSE...)

 

View of 2 new hiyokos in hiyokohouse, viewed in CSE . For those not familiar with HiyokoGenerator mechanics this is where they are 'stored' and pulled from upon birth. You drop one of your 117 races in here and create a Ref to it for the script.

 

The two in the very front are the new x117 Dark Sirens

 

Mind you, I did NOT get fancy and went with the DarkSiren meshes for head, ears, etc. and same for textures. Copied both eyes and hairs from DarkSiren race to new 117DarkSiren race, we'll see soon enough how it all works out in-game.

 

For something more complex I could have used one of the x117 sets of meshes, but I have no idea yet if the textures and UV mapping for Sirens et al, will be compatible with x117 meshes. Needs to be investigated further. For now I will just make miniature versions of adult Sirens. Better to build this up slowly over time.

[movomo]

It would be good if you create a new folder below the characters folder, and include all the head assets in them (cons: you can't include all the different body textures)

Or, you could include no asset at all, just detect if the end-user has a certain plugin installed. For example, lop-eared elf child is born only when IsModLoaded x117.esm = true. Then you could create a copy of the lop-eared elf kid... if not, replace the kid with some other human-ish race.

 

But I seriously recommend building the base system first, see if it works, and then add the races and individual npc's.

[varenne]

For most races there are already sub folders for meshes and textures, unless you mean for the new hiyokos I'm creating.

 

 

... Then you could create a copy of the lop-eared elf kid... if not, replace the kid with some other human-ish race.

 

The current HiyokoGenerator scripts do now that, I forget exactly which race(s) they default to and it's randomly selected, but I believe it is human and elf. Defaults could be made to be more expansive. I think the randomness parameter also needs a review.

[mem4ob4]

In regards to the Hiyokogenerator NoMBP version.

Anyone feel it is needed to check for hair if hiyo IsCreature ? In case I am missing some reasoning.

 

Mem

[varenne]

I don't think so.

[varenne]

A little more discovery and feedback tonight on my creating x117Sirens. In-game of a 1st born using the original Siren head mesh, it looks unusually small compared to the rest of the body. This must be why the other x117 races use these special head nifs. Live and learn...

 

Experimenting with using the x117 human head nif, ears and eyes proved to be a better path. Downside is I'll need to totally recreate my first, the dark siren as I used Copy Hairs from race and Siren hairs do not line up correctly with the x117 human head. Bummer. Upside is I didn't go full bore and create all the Siren versions so it's just one to rework.

 

Testing of the script that auto-activates the Siren tail (and bra) worked well enough, but I think it too needs to be resized to be for a smaller body. Some experimentation via NifSkope for that next...

[rynak777]

Just a small trivial proposal:

 

Add the kokumarumilk setting to the ini file. I've already done so on my local copy, but it's a popular setting, so its a bit weird for it to be absent from the ini.

 

That reminds me - something i always wondered about: When exactly does tamago read its ini file? Only on first launch? On any reset? On any game load? Asking because there is no "reread ini settings" command.

 

EDIT:

Also, the last non-"alpha/debug" version has some easy to fix obvious translation issues. Mainly affected is gettextsituation and getselectiondesc (or similiar called). For gettextsituation, the most obvious issues are easy to fix:

 

- very often, the string args for location and offender are mixed up (you only need to swap the args around). IIRC, the vars are sp and splace. The error usually follows this pattern:

 

"... was injected by %s%s and..." splace sp spos

 

Ingame, the resulting output will read like "...was injected by exteriorcommonerat and..."

 

This is easily fixed - change all the relevant codelines to:

 

"... was injected by %s at %s..." sp splace spos

 

There will then still be a wrong "at" added to the string. It is added further down in the code, which for no reason checks the string length, and if it is above 0 (?!?) appends "at" to the string. Just comment out that if-block.

[rghost]

Just a small trivial proposal:

 

Add the kokumarumilk setting to the ini file. I've already done so on my local copy, but it's a popular setting, so its a bit weird for it to be absent from the ini.

 

That reminds me - something i always wondered about: When exactly does tamago read its ini file? Only on first launch? On any reset? On any game load? Asking because there is no "reread ini settings" command.

 

 

Kokumarumilk is in LoversTamagoClub.esp not TamagoClub.

 

ini file is read after saved game was loaded or a new game was started.

 

Just a small trivial proposal:

 

 

EDIT:

Also, the last non-"alpha/debug" version has some easy to fix obvious translation issues. Mainly affected is gettextsituation and getselectiondesc (or similiar called). For gettextsituation, the most obvious issues are easy to fix:

 

- very often, the string args for location and offender are mixed up (you only need to swap the args around). IIRC, the vars are sp and splace. The error usually follows this pattern:

 

"... was injected by %s%s and..." splace sp spos

 

Ingame, the resulting output will read like "...was injected by exteriorcommonerat and..."

 

This is easily fixed - change all the relevant codelines to:

 

"... was injected by %s at %s..." sp splace spos

 

There will then still be a wrong "at" added to the string. It is added further down in the code, which for no reason checks the string length, and if it is above 0 (?!?) appends "at" to the string. Just comment out that if-block.

 

Which version did you use? My version or movomo's version of HiyokoClub and TamagoClub.