Jump to content

More Nasty Critters Legendary Edition


Recommended Posts

I'm curious how all the races are grouped.

 

I have the 'valid names for SLAnimGenerateForMNC' file in the SLAL folder for reference.

 

But, I'd like to know a bit more specifically, for instance, there's the 'Canines' race, I get that it covers both dogs and wolves, but does it also cover:

  • MG07DogRace 
  • DLC1HuskyArmoredCompanionRace
  • DLC1HuskyArmoredRace
  • DLC1HuskyBareCompanionRace
  • DLC1HuskyBareRace
  • DogCompanionRace

I'd like to know at this level of detail for every Race in MNC if possible, is there any kind of a database or list that has all this stuff lined out so I could see exactly what is and isn't covered?

(This is for a Mod).

 

Thx.

Link to comment
16 minutes ago, Hugh Reckum said:

I'd like to know at this level of detail for every Race in MNC if possible, is there any kind of a database or list that has all this stuff lined out so I could see exactly what is and isn't covered?

MoreNastyCrittersFactory.psc is what you need to look at:
 

Spoiler



	;Canines = Actors\Canine\DogProject.hkx AND Actors\Canine\WolfProject.hkx
		ClearRaceKey("Canines")
		AddRaceID("Canines", "CaninesFailSafe")
		AddRaceID("Canines", "DogRace")
		AddRaceID("Canines", "DogCompanionRace")
		AddRaceID("Canines", "MG07DogRace")
		AddRaceID("Canines", "DA03BarbasDogRace")
		AddRaceID("Canines", "DLC1HuskyArmoredCompanionRace")
		AddRaceID("Canines", "DLC1HuskyArmoredRace")
		AddRaceID("Canines", "DLC1HuskyBareCompanionRace")
		AddRaceID("Canines", "DLC1HuskyBareRace")
		AddRaceID("Canines", "WolfRace")
		AddRaceID("Canines", "DLC1DeathHoundCompanionRace")
		AddRaceID("Canines", "DLC1DeathHoundRace")
		;end of stock races
		AddRaceID("Canines", "DwemmydograceIris")
		AddRaceID("Canines", "AKDogDraugrRace")
		AddRaceID("Canines", "_00AspectRace")
		AddRaceID("Canines", "00HyenaRace")
		AddRaceID("Canines", "00DracoRace")
		AddRaceID("Canines", "I5KDraugrDogRace")
		AddRaceID("Canines", "00drakerace")
		AddRaceID("Canines", "mihailpoisondograce")
		AddRaceID("Canines", "SalamanderRACE")
		AddRaceID("Canines", "EQ145_Bonehound_attacks")
		AddRaceID("Canines", "BoTHellhoundRace")
		AddRaceID("Canines", "CYRWolfRace")
		AddRaceID("Canines", "YautjaHoundRace")
		AddRaceID("Canines", "YautjaHoundRaceFollower")
		AddRaceID("Canines", "DLC1HuskyArmoredCompanionRaceGARM")
		AddRaceID("Canines", "_AmaterasuRace")
		AddRaceID("Canines", "00dhellhoundrace")
		AddRaceID("Canines", "HorseFluteWolfMountRace")
		AddRaceID("Canines", "HorseFluteLizardMountRace")
		AddRaceID("Canines", "0_GermanShepherdRaceFollower")
		AddRaceID("Canines", "0_HuskyArmoredRace")
		AddRaceID("Canines", "0_DogWildRace")
		AddRaceID("Canines", "0_DogFollowerRace")
		AddRaceID("Canines", "mihaildog")
		AddRaceID("Canines", "mihailkagoutirace")
		AddRaceID("Canines", "mihaildawnhorserace")
		AddRaceID("Canines", "mihailmoropusrace")
		AddRaceID("Canines", "mihailnixhoundrace")
		AddRaceID("Canines", "mihailleshenwolfrace")
		AddRaceID("Canines", "mihailcyrodiilwolfrace")
		AddRaceID("Canines", "zzzLrhGhoulDoggyRace")
		AddRaceID("Canines", "mihailskinnedhoundrace")
		AddRaceID("Canines", "mihailzombiedograce")
		AddRaceID("Canines", "mihailcheetahrace")
		AddRaceID("Canines", "WolfRideRaces")
		AddRaceID("Canines", "aaxDogCompanionRace")
		AddRaceID("Canines", "aaxWolfRace")
		AddRaceID("Canines", "HyenaRaceSlice")
		AddRaceID("Canines", "zzClannfearRace")
		AddRaceID("Canines", "RusheedaRace")
		AddRaceID("Canines", "mihaildraugulfrace")
		AddRaceID("Canines", "mihailnordmastiffrace")
		AddRaceID("Canines", "mihailnordmastiffraceRABID")
		AddRaceID("Canines", "mihailpedlarguarrace")
		AddRaceID("Canines", "mihailshepherddograce")


 

 

Link to comment
43 minutes ago, MadMansGun said:

MoreNastyCrittersFactory.psc is what you need to look at:

Ok, perfect, thanks!

 

One more quick question if you don't mind.

 

In your script you have the following for Bears:

 

		AddRaceID("Bears", "CYRBearMaskedRace")
		AddRaceID("Bears", "CYRBearBrownRace")
		AddRaceID("Bears", "TheDovaBearRace")
		AddRaceID("Bears", "HorseFluteBearMountRace")
		AddRaceID("Bears", "mihailleshenbearrace")

These are all non-vanilla external mod integrated bears, which is cool, but what I don't see are the 3 vanilla races:

 

BearBlackRace

BearBrownRace

BearSnowRace

 

So is the script not inclusive of all Vanilla stuff?

 

AFAIK all 3 of the above seem to work fine in animations though...

 

Edit: Nevermind, I see that the ones not covered in your script are added in through RegisterRaces() in sslCreatureAnimationSlots...

 

Now to add it all to a spreadsheet. :cool:

Link to comment
54 minutes ago, Hugh Reckum said:

Ok, perfect, thanks!

 

One more quick question if you don't mind.

 

In your script you have the following for Bears

you misread it or have a older script file installed:

	;Bears = Actors\Bear\BearProject.hkx
		ClearRaceKey("Bears")
		AddRaceID("Bears", "BearsFailSafe")
		AddRaceID("Bears", "BearBlackRace")
		AddRaceID("Bears", "BearBrownRace")
		AddRaceID("Bears", "BearSnowRace")
		;end of stock races
		AddRaceID("Bears", "CYRBearMaskedRace")
		AddRaceID("Bears", "CYRBearBrownRace")
		AddRaceID("Bears", "TheDovaBearRace")
		AddRaceID("Bears", "HorseFluteBearMountRace")
		AddRaceID("Bears", "mihailleshenbearrace")
		AddRaceID("Bears", "mihailgiantslothrace")
		AddRaceID("Bears", "aaxBearBrownRace")

 

Link to comment

Ok, so ClearRaceKey clears any existing races before adding the race back into SexLab, if I understand that right. So if there's a duplication between MNC and SexLab for the same race, SexLab basically takes precedence and clears the race out then applies the final race assignment, and for non-duplicate entries, the race will persist from MNC and then play accordingly based on available animations.

 

Am I getting that right?

 

 

Link to comment
1 hour ago, Hugh Reckum said:

Ok, so ClearRaceKey clears any existing races before adding the race back into SexLab, if I understand that right. So if there's a duplication between MNC and SexLab for the same race, SexLab basically takes precedence and clears the race out then applies the final race assignment, and for non-duplicate entries, the race will persist from MNC and then play accordingly based on available animations.

 

Am I getting that right?

i guess? i'm not a scripter, i only know that it makes things work the way i want them to (giant spiders use giant spider animations, and large spiders use large spider animation)

Link to comment
11 hours ago, Hugh Reckum said:

Ok, so ClearRaceKey clears any existing races before adding the race back into SexLab, if I understand that right. So if there's a duplication between MNC and SexLab for the same race, SexLab basically takes precedence and clears the race out then applies the final race assignment, and for non-duplicate entries, the race will persist from MNC and then play accordingly based on available animations.

 

Am I getting that right?

 

 

 

The terms can get a little confusing if you're looking at the sexlab code:

 

RaceID =  String name of a race like "ArmoredHusky"  or some such

RaceRef = the Race Object ("form alias" I think),  the 'editor' race object.

Racekey = String name of a category of creatures, nominally sharing a skeleton and behavior, so all share compatible animations

 

So,  a collection of  RaceID  are assigned to a  Racekey  category via the  "AddRaceID"  native SKSE function (code compiled into .dll) in sslCreatureAnimationSlots. When using the sexlab filter functions on a a creature actor, RaceRef, or RaceID to find a valid animation, the other native functions are called to search the racekey -> RaceID mapping to see which RaceKey that Actor/RaceRef/RaceID belongs,  the searches the sslCreatureAnimationSlots for sslBaseAnimation 's  (the list of creature animations for a particular animation object) which are registered as being for that racekey.

 

When you call "ClearRaceKey", it just deletes the racekey -> RaceID mapping completely for that Racekey.  If it isn't re-created somehow, then it no longer exists. The current code appears to be set up so that Sexlab's default registration of the racekey's only happens during initial setup, and never at any other point. Re-building the animation registry does NOT recreate the default racekeys. This makes sense, since a mod may want to adjust the racekey mappings, and sexlab shouldn't fight with that.

   If a mod calls ClearRaceKey itself, then it's up to the mod to build the mapping again.

 

   There will never be a "duplication" of a racekey.  If a mod calls  "AddRaceID"  on an already-existing racekey, then the RaceID's are just added to the current list. If a mod calls "ClearRaceKey", then that racekey is gone and will never be rebuilt unless sexlab is reset and re-initialized, or the mod rebuilds it.

   As far as I know,  MNC clears  (WIPES OUT, ANNIHILATES, MUTILATES, SPINDLES, AND FOLDS) a range of racekeys,  then rebuilds them with a new set of RaceID's (I think 100% including the same ones sexlab uses, just adds more from other mods and such).

 

 

Link to comment

@PaulGreen Thanks, that helps to connect the dots on that.

 

Ok, so here's a different issue that I'm running into:

Male Female Creature

Female Female Creature

Male Male Creature (not sure if they exist but I imagine they'd have same issue).

 

So if there's 2 Male Canines and a sex scene starts with a Female actor, one animation that may come up is: LeitoCanineMFC.

 

But the M in MFC is for non-creature male, yet one of the male dogs tries to fill the slot and fails so instead just stands around like a lump on a log because a 2nd creature is not a valid actor in that animation.

 

How to prevent MFC animations from getting called when the actor configuration is actually CFC?

 

 

Link to comment
2 hours ago, Hugh Reckum said:

But the M in MFC is for non-creature male, yet one of the male dogs tries to fill the slot and fails so instead just stands around like a lump on a log because a 2nd creature is not a valid actor in that animation.

 

How to prevent MFC animations from getting called when the actor configuration is actually CFC?

i think he was talking about that over here:

https://www.loverslab.com/topic/108599-designating-positions-in-animations/

 

Link to comment
7 hours ago, MadMansGun said:

i think he was talking about that over here:

https://www.loverslab.com/topic/108599-designating-positions-in-animations/

 

Yeah, that's pretty much it...

 

So SexLab grabs the Race and runs with it, pulling from any available animation. Seems like one more layer of bool logic could solve it, to check each aliases Race rather than assume they're all the same based on how one returns...

 

Anyway, a fairly clean way around it imo would be to just add one extra tag to these types of animations eg:

 

Animation(
    id="leitoCaninemfc1",
    name="(Canine) LeitoCanineMFC",
    tags="Leito,Bestiality,Wolf,Dog,Canine,Threeway,Vaginal,MFC",
    sound="Squishing",
    actor1=Male(add_cum=Vaginal),
    actor2=Female(add_cum=VaginalOralAnal),
    actor3=CreatureMale(race="Canines", add_cum=VaginalOralAnal),
)

Animation(
    id="leitoCaninemfc2",
    name="(Canine) LeitoCanineMFC2",
    tags="Leito,Bestiality,Wolf,Dog,Canine,Threeway,Vaginal,MFC",
    sound="Squishing",
    actor1=Male(add_cum=Vaginal),
    actor2=Female(add_cum=VaginalOralAnal),
    actor3=CreatureMale(race="Canines", add_cum=VaginalOralAnal),
)
 

 

And then maybe an FFC tag and MMC tag wherever appropriate. - With tags like those it would be pretty easy to filter down the animations correctly (as a modder) so it'd be possible to avoid the broken scenario of a Creature trying to fill the actor slot 1 that should be a Male...

 

 

Link to comment
8 hours ago, Hugh Reckum said:

 

 

 

 I think these kind of tags are already added automatically when registering the animations in sexlab. There is a standard convention internally for specifying position gender, just not position race (for creatures) or position acting (giving, receiving).

 

   The problem here might be more subtle.. I think it is that sexlab automatically sorts animation actors while compiling a search.. one way it sorts is that it places genders in a specific order when doing a search:  F then M  then C.  So, if an animation tags itself as  MFC ,  a default search may never find it because the search will always be for FMC  even if the initial actor list handed to the search function is  MFC.

   Sexlab does this sorting independently of the way any animations tag or order their actors, so animations that are generated with position genders not in the way sexlab is expecting might have unintended results. If no results are found for a search,  it is up to the mod to decide what to do. For instance, I think matchamaker does, for creature animations:

       "okay, no results,  so just choose a random animation with  X  number of actors that is for the 'canines' racekey" and if that still fails then  "okay, no results, so just choose any random 'canines' animation". Other mods may just say "no animation, fail" with flavor text like "the spell fizzled" or "not interested".

 

   There are actually methods in the filter functions to tell sexlab to not do this sorting while compiling a search, so that a mod has greater control over the search parameters for particular animations.  A mod has to call these functions with those function parameters, however. This also requires a mod to have much more work done in it when selecting an animation, since it now has to understand and perform all the selection logic itself instead of leaving it up to sexlab.

   If they just call the quick-start functions or don't explicitly tell it not to sort, you'll see the problem as above.

 

   It could be that other mods do this selection logic and others don't. I dunno..   In that thread, the modifications I was making to matchmaker and SLAL tagging included adding a bunch of crap to the matchmaker logic to attempt a greater quantity of tests for intended order. I didn't add something for gender order since I was focusing on creature-actor-number and position-racekey,  but that's the type of thing that would have to be done.

 

 

Link to comment
40 minutes ago, PaulGreen said:

 

 

 

Your positions issue may be broader than what I am running into.

 

All I want to do for my Mod SexLab Pheromones is omit certain animations that are invalid becuase of MFC, FFC, or MMC configuration where a C is inappropriately filling a slot of an M or an F.

 

That makes it very simple to solve, all I need to know is if the animation is an MFC, FFC, or MMC type, which is why I suggest a tag because I can run a small amount of bool logic before the animation ever gets sent to SexLab. Tags are also easy to add, I've made SLAL packs before, change the source .txt and rerun Python JSON generator, could probably do it in ~ 5 minutes.

 

The reason it would help is, let's say I have 3 actively filled aliases that will be used in a SexLab scene, all I need is a quick bool logic ahead of time to figure out if my filled aliases are FCC or MFC, I have my own Quest filled aliases so I already know the exact alias fill order and it wouldn't be hard to build a little bool function to figure out what kind of scene needs to be run.

 

If they don't come back as FFC, MFC, or MMC based on the alias checks, then they must be either FCC or MCC (probably FCC, not sure if animations for the other exists).

 

So I'd call the scene like this to suppress those tags and play an appropriate FCC animation (in my Mod's case).

 

Function StartCreatureSex(Actor akActor1, Actor akActor2)
    actor[] sexActors = new actor[2]
    sexactors[0] = Playerref
    sexactors[1] = akActor2
    sslBaseAnimation[] anims
    anims = SexLab.GetAnimationsByTags(2, "", "FFC,MFC,MMC",True) ;Invalid Tags Suppresed
    SexLab.StartSex(sexActors, anims, victim = PlayerRef, AllowBed = false, Hook = "SingleCreature")

EndFunction

 

Otherwise I use the tags FCC, MFC, or MMC animation. Just keep track of alias genders when the actors are passed in and it should work fine.

 

Function StartMFCSex(Actor akActor1, Actor akActor2)
    actor[] sexActors = new actor[2]
    sexactors[0] = Playerref
    sexactors[1] = akActor2
    sslBaseAnimation[] anims
    anims = SexLab.GetAnimationsByTags(2, "MFC", "",True) ;Tags Used
    SexLab.StartSex(sexActors, anims, victim = PlayerRef, AllowBed = false, Hook = "SingleCreature")

EndFunction

 

Or for FFC:

 

Function StartMFCSex(Actor akActor1, Actor akActor2)
    actor[] sexActors = new actor[2]
    sexactors[0] = Playerref
    sexactors[1] = akActor2
    sslBaseAnimation[] anims
    anims = SexLab.GetAnimationsByTags(2, "FFC", "",True) ;Tags Used
    SexLab.StartSex(sexActors, anims, victim = PlayerRef, AllowBed = false, Hook = "SingleCreature")

EndFunction

 

Without a tag system like this, then yes, I'd probably have to mess with SexLab innards, which would be a pain in the ass...

 

As I said, your overall issue may be bigger than this, but having these tags available would give enough information so these types of animations could be easily categorized and that would make it so some logic could be thrown in a script to route the right type of SexLab animation before the scene ever gets called in SexLab.

Link to comment
9 hours ago, Hugh Reckum said:

 

 

 

   If this is the case, then as I mentioned, the data is already there. Sexlab adds these tags automatically as the animations are registered to the array of animations.


   You're correct that what I was trying to do is more.. I discovered that, unlike this, the data is not accseeible, so either sexlab needs new code, or some method like this taggin has to be done. Adding the tags through SLAL is easy, but the hard part is getting everyone else who every makes animations to follow the convention you want them to follow.


   The tags, though, will be in the sorted order I mentioned. An animation that is  "MFC"  in the regsitration will not be tagged  "MFC", instead it will be tagged  "FMC". It is  always  F  then  M   then C. I did forget, though, that sexlab always adds a reverse tag as well.. I'm not really sure why but it does.   So an animation with  MFC  positions will get the tags   FMC  and  CMF.


   Here's the trick though...  Since the tags are added in this sorted order, but the actual actor positions might be different, you lose information on the ORDER in which to place the actors. Take that MFC animation again.  In it,  Actor1  is male,  Actor2 is Female,  and Actor3 is creature.   If you want to search for this animation by tag, you would serac for  FMC  or  CMF and you would get it returned in the serach by tag.

 

   However,  when you create the list of actors,  in what order do you create the list?   Do you put the Male actor first,  the Female actor second, and Creature third?

Actor[] humpinthings = new Actor[3]

humpinthings[0] = MaleActor

humpinthings[1] = FemaleActor

humpinthings[2] = fluffykitty

 

   Or do you create the actor as Female,  then Male,  then Creature?

Actor[] humpinthings = new Actor[3]

humpinthings[0] = FemalActor

humpinthings[1] = MaleActor

humpinthings[2] = fluffykitty

 

   Does it matter what the order is?

 

   It turns out that it does..  the actors are added to the A1,  A2,  and A3  slots in the animation exactly in the order handed to the SexLab.StartSex  function.  So, the tag you search for like  FMC will return  all animations that have any order of:    a male, a female,  a creature    regardless of the order of actors,   BUT  if you start those animations with an array that isn't in the right order,  then you get the actors in the wrong positions.

 

   For that  MFC  animation,  you'll get it by searching for  FMC   or  CMF  but you will have to know to create the actor array as

humpinthings[0] = MaleActor

humpinthings[1] = FemaleActor

humpinthings[2] = fluffykitty

 

   to get the animation to play with the actors in the correct gender positions. The only way you can determine that is by searching the position array of each individual animation to find the actual orders the positions are in.

 

 

   What I was choosing to do in my work was select an array of animations with any order of the required genders (and creatures), select a random animation from that list,  then, ordering the actor array as require for that randomly selected animation.

 

 

   There' STILL another problem if you want to get it perfect..  Say that you know that you want one of the particular actors in a 'dominant position.  how do you know,  of the animations found by tag or other search,  which one is the  'giver'  and which is the 'receiver'  or which one is the aggressor and which is the 'victim' ?  By convention, it seems that the FIRST actor position in an animation is considered the 'victim'.  That means that, if you actually want that Male actor  to be the 'victim'  you would want to find animations that have the Male in the first position... which means you do indeed need to walk the array returned by the search and find ones with the male in the first position and then select a random one from that new list.

 

 

 

 

Link to comment

These functions might be useful for all this:

 

In SexLabFramework.psc

sslBaseAnimation[] function GetAnimationsByType(int ActorCount, int Males = -1, int Females = -1, int StageCount = -1, bool Aggressive = false, bool Sexual = true)

Get a list of animations by the number of actors, the number of males,  and the number of females, plus other options

 

sslBaseAnimation[] function PickAnimationsByActors(Actor[] Positions, int Limit = 64, bool Aggressive = false)

Takes a list of actors and finds a valid animation by their qualities.  Oddly, note that this function will completely ignore genders for lists with more than 2 actors

 

 

 

In sslBaseAnimation.psc:

 

int function GetGender(int Position)
    return Positions[Position]
endFunction

 

So you could walk the positions in a particular animation object and check the gender order. Like..    if SearchResults[x].GetGender[0] == Male

 

 

 

   I don't quite understand the reason for sorting the tags when registering animations. It seems like, instead, the tags should be kept as the actual actor position order to retain that information,  and then using GetAnimationsByType to do the search by generic   F, M, and C  count.   By sorting and addind the tags in a standard order,  all one is doing is basically recreating that function in tag form and throwing away otherwise useful information.

 

    There might be a reason I don't understand or a history as to why. Or maybe I"M WRONG ABOUT ALL THIS!   But that could never happen  :3

 

Link to comment

Ok, that was the answer that I was looking for. That is easy then, I didn't realize that SexLab would create gender tags in addition to the existing tags that animators include in the animations.

 

As for the rest, I could see some value to having an automated handling of the different actor configurations, especially if the number of available animations increases. 

I guess things start getting more complicated as you get into 4-somes and 5-somes though, heh. 3 has 6 permutations, and 5 has what... 120? lol...

 

For practical purposes, as there's not that many of these kinds of animations, the simplest solution for me would probably be to use FMC, FFC, MMC as suppression tags in my main function, with a gender check that could reroute appropriate animations to specific SexLab functions that can handle the other configurations. It's mostly FFC and FMC anyway, so it may only take a couple extra functions, but even if I had to invoke 'FindAnimiationByName', there's still probably < 10 of these types of animatoins total between MNC, Billyy, and Anubs, (unless there's more somewhere that I don't know about)... - Even in the latter case it wouldn't take too much work to handle them all. But, if there was 100 of them and animators were sorting their actors in different orders, I'd be more worried about automation.

 

It's still not a bad idea though, because who knows what might happen in the future...

Link to comment

I encountered the same issue with canines not having P textures when an animations start and plays. I had just loaded MNC v11.4 last weekend. To resolve this I first reloaded Beast HDT v.064. No change and this doesn't have textures in it anyway. I resolved the issue by coping the textures from the MNC v11.2 for canines into the Data/textures/MNC/canine.  Seems like the file names for the canine textures are different between the two versions of MNC between 11.2 and 11.4. Looking at this again, I see in that directory for canine textures that several of the texture files for canine P are missing from v11.4. The new version only 1 of the normal 4 textures files for the P. There was no DogP_s.dds, color.dds, or normal.dds.

Link to comment
51 minutes ago, Stryker1177 said:

I encountered the same issue with canines not having P textures when an animations start and plays. I had just loaded MNC v11.4 last weekend. To resolve this I first reloaded Beast HDT v.064. No change and this doesn't have textures in it anyway. I resolved the issue by coping the textures from the MNC v11.2 for canines into the Data/textures/MNC/canine.  Seems like the file names for the canine textures are different between the two versions of MNC between 11.2 and 11.4. Looking at this again, I see in that directory for canine textures that several of the texture files for canine P are missing from v11.4. The new version only 1 of the normal 4 textures files for the P. There was no DogP_s.dds, color.dds, or normal.dds.

Beast HDT is your problem, you need the updated file i posted here:

https://www.loverslab.com/topic/54417-naturalistic-hdt-and-beast-hdt/?do=findComment&amp;comment=2393675

 

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • 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