Designating positions in animations

[PaulGreen]

 

   Again, before dig too far:

 

   How are 'positions' determined in sexlab animation definitions? Is it just convention that the 'receiving' actors are listed first  (Actor1, Actor2, ...)  and the 'giving' characters are listed second (Actor2, Actor3, ..) or is there a method within sexlab to determine this?

 

 

[MadMansGun]

2 hours ago, PaulGreen said:

Is it just convention that the 'receiving' actors are listed first  (Actor1, Actor2, ...)  and the 'giving' characters are listed second (Actor2, Actor3, ..) or is there a method within sexlab to determine this?

most of the time this is the case but not always: human actor/s must always be before creatures, and animators can setup actor1 to be the one doing the fucking if they want to but it can sometimes mess with other mods that try to call on them, Eg: it can put the wrong actor on top.

[PaulGreen]

22 hours ago, MadMansGun said:

 

 

A quick skimming show that there doesn't seem to be a built-in method of identifying positions in sexlab. I've also noticed that most animations keep the convention of receiver first, giver second, though I suppose some cases it is difficult to subjectively identify which is which, heh. Without a convention, it is not possible to have a 100% operating, generic system of animation-playing that makes assumptions about this, like the 'defeat' things or similar.

 

As you mention, for defining the animation actor order, it looks like sexlab expects the creatures to be specified last. It enforces this, by that during a setup of a thread to start, sexlab will re-order the actors to accomplish this. So, even if a thread is defined with a given actor order, that order will actually be re-ordered during the 'startthread' function to put player-races after creature, non-player races.

 

 

So, basically nothing to do other than assume animations follow the convetion, which is answer I was looking for! Did not want to miss an easy understanding for an answer.

 

As a side note! I notice in hcos, the "wildlife" version, the following have this convention reversed in the current animations (not comprehensive):

 

Spoiler

 

    id="dragononmammoth",
    name="Dragon on Mammoth",

    id="dragononhorse",
    name="Dragon on Horse",

 

    id="horsedockingdragon",          <---  probably debateable, heh
    name="Horse Docking Dragon",

 

    id="wolfonwerewolf",
    name="Canine on Werewolf",

 

    id="foxonchicken",
    name="Fox on Chicken",

 

    id="horseonwolf",
    name="Horse on Canine",

 

    id="giantonmammoth",
    name="Giant on Mammoth",

 

 

 

[MadMansGun]

On 10/3/2018 at 9:57 PM, PaulGreen said:

As a side note! I notice in hcos, the "wildlife" version, the following have this convention reversed in the current animations (not comprehensive):

creature on creature animations are a bit tricky because SexLab was not made to handle them.

when working with mixed creature races actor1 must always be activated first before actor2 or else the right animation/s wont be considered valid, therefor making the order match the name helps people to get it right. (but i do need to fix some of them)
 

Spoiler

 

    id="bearonelk",
    name="Bear on Elk",

 

    id="catonrat",
    name="Cat on Rat",

 

    id="wolfonbunny",
    name="Canine on Bunny",

 

 

but however there is a problem with werewolves: the SL Werewolves mod forces the player's Werewolf form to always be actor2, therefor my ordering had to match that limitation (but it causes problems for female werewolf players in "werewolf on werewolf" animations)

[PaulGreen]

2 hours ago, MadMansGun said:

 

 

In trying to understand how it works currently:

When selecting an animation where both of the races involve multiple possible animations (say  'horse and werewolf') is there a problem that it becomes impossible to get sexlab to automatically select the correct animation?

 

I suspect how it is happening is that sexlab considers the 'creaturerace' of the animation to be whatever the last actor selected's race is. So, if using the matchmaker spell to select dog, cat, dragon, horse,  the "creature race" that sexlab will look for is "horses". The SLAL python script that compiles the animations does the same, is appears. When specifying the animations, it will apply the attribute "creature_race" as the specified race of the last actor:

 

 

For instance:

 

Spoiler

Animation(
    id="dragononhorse",
    name="Dragon on Horse",
    tags="Creature,Interspecies,A1,Dragon,A2,Horse,Forced,Anal,Snuff",
    sound="Squishing",
    actor1=CreatureMale(race="dragons"),
    actor2=CreatureFemale(race="horses", add_cum=VaginalOralAnal),
    stage_params = [
        Stage(1, timer=8.0, sound=NoSound),
        Stage(4, timer=21.5, sound=NoSound),
    ]
)

 

 

 

 

Produces:

 

Spoiler

 

     ..................

              "id": "mmg_dragononhorse_A2_S4"
            }
          ],
          "type": "CreatureFemale"
        }
      ],
      "creature_race": "horses",
      "id": "mmg_dragononhorse",
      "name": "HCoS Dragon on Horse",
      "sound": "Squishing",
      "stages": [
        {
          "number": 1,
          "sound": "none",

......................
 

 

 

 

 

 

Whereas, this this:

 

Spoiler

Animation(
    id="dragononhorse",
    name="Dragon on Horse",
    tags="Creature,Interspecies,A1,Dragon,A2,Horse,Forced,Anal,Snuff",
    sound="Squishing",
    actor1=CreatureFemale(race="horses", add_cum=VaginalOralAnal),
    actor2=CreatureMale(race="dragons"),
    stage_params = [
        Stage(1, timer=8.0, sound=NoSound),
        Stage(4, timer=21.5, sound=NoSound),
    ]
)

 

 

 

Produces:

 

Spoiler

     ....................................

              "id": "mmg_dragononhorse_A2_S4"
            }
          ],
          "type": "CreatureMale"
        }
      ],
      "creature_race": "dragons",
      "id": "mmg_dragononhorse",
      "name": "HCoS Dragon on Horse",
      "sound": "Squishing",
      "stages": [
        {
          "number": 1,
          "sound": "none",

 

    ........................

 

 

 

 

   In doing some testing and looking at sexlab source, among the creature actors, sexlab will  not  re-order the actors as specified when creating the thread, so final creature actor sepcified determines the "creature race" of the animation that will be sought, and the order that the actors are specified will not be altered when applying that animation to the actors.

 

So, if one selects a Dragon and a Horse,  I believe it is the case that sexlab will select any "horses" animation at all and try to play that. There's a very, very good chance that the animation that plays ends up being a 'dragon on human' animation, or after that chance,  any other animation that is listed as  "horses" creature race,  so the dragon actor then appears to do nothing (returns to default idle animation, not completely still) since an invalid havok behavior tried to be applied to it.

 

I think... heh.

 

 

 

[PaulGreen]

 

My goal is to create a tagging system that hacks another "convention" on top of sexlab to allow things like this to be selected with intentional work by a mod to get the correct animations and creature positions working.

 

For instance:

 

Spoiler

 

              "id": "mmg_dragononhorse_A2_S4"
            }
          ],
          "type": "CreatureMale"
        }
      ],
      "creature_race": "dragons",
      "id": "mmg_dragononhorse",
      "name": "HCoS Dragon on Horse",
      "sound": "Squishing",
      "stages": [
        {
          "number": 1,
          "sound": "none",
          "timer": 8.0
        },
        {
          "number": 4,
          "sound": "none",
          "timer": 21.5
        }
      ],
      "tags": "HCoS,Creature,Interspecies,A1,Dragon,A2,Horse,Forced,Anal,Snuff,Creature_horses,Creature_Pos1_horses,Creature_dragons,Creature_Pos2_dragons"
    },

 

 

 

 

 

  I did get it successfully working via Aroused Creatures just today, after lots of mistake problems. Aroused creatures it turns out is a little difficult to do with, because the author can keep the greater possible setting combinations in mind better than I can..

 

I don't know if this is really practical to do, however.. it would require SLAL to change it's script slightly and for all mod author's to accept a convention like this. I'm not a good community organizer, heh.

 

 

The chance to SLAL is very easy I think.. I haven't though of any unintended consequnces:

 

Spoiler

 

551a552,555
>
>                 # MY EDIT - add a tag per creature
>                 creatureTagAdd = "Creature_" + actor_info.creature_race + ",Creature_Pos" + str(n) + "_" + actor_info.creature_race
>                 self.tags.extend(self._parse_tags(creatureTagAdd))

 

 

 

 

 

[MadMansGun]

On 10/4/2018 at 6:57 AM, PaulGreen said:

So, if one selects a Dragon and a Horse,  I believe it is the case that sexlab will select any "horses" animation at all and try to play that. There's a very, very good chance that the animation that plays ends up being a 'dragon on human' animation, or after that chance,  any other animation that is listed as  "horses" creature race,  so the dragon actor then appears to do nothing (returns to default idle animation, not completely still) since an invalid havok behavior tried to be applied to it.

 

I think... heh.

yea...something like that (i'm not a scripter), if a dragon is the first creature activated with matchmaker then it will try to load any other animations that has a dragon creature listed first, Eg:

it will load

    id="dragononhorse",
    name="Dragon on Horse",
    actor1=CreatureMale(race="dragons"),
    actor2=CreatureFemale(race="horses"),

 

it will also load

    id="dragononmammoth",
    name="Dragon on Mammoth",
    actor1=CreatureMale(race="dragons"),
    actor2=CreatureMale(race="mammoths"),

 

    id="docking",
    name="Docking with the Dragon",
    actor1=Male,
    actor2=CreatureMale(race="dragons"),

 

    (and  more)

 

but it will NOT load

    id="horsedockingdragon",
    name="Horse Docking Dragon",
    actor1=CreatureMale(race="horses"),
    actor2=CreatureMale(race="dragons"),

because it sees a Horse creature first.

 

On 10/4/2018 at 7:03 AM, PaulGreen said:

My goal is to create a tagging system that hacks another "convention" on top of sexlab to allow things like this to be selected with intentional work by a mod to get the correct animations and creature positions working.

your tags are a bit too complicated for practical usage, "A1_Dragon,A2_Horse" would be easier (and is sort of already there)

 

[PaulGreen]

21 hours ago, MadMansGun said:

 

 

   Strangely, for me, it is the other way around. The second creature selected is what sexlab will consider the "creature_race" of the animation. If I tag dragon -> horse  sexlab will search for an animatio where the SLAL json indicates creature_race="horses". I'm using Skyrim SE with latest versio of beta sexlab, maybe different versions do different things ?

 

   I was thinking tags should be clear that they are the programmatic tags added automatically by SLAL, so a definite prefix was useful. The race tag should probably match the racekey string used in sexlab (horses, dragons, canines, mammoths, ..) and was going to need a way to associate which creature race was what position. Probably this can be done by using one tag, or if sub-string search should be minimized, then it could assume a tag order, like  ... ,aggressive,oral,CRace_Tags,human_A1,dragons_A2,horses_A3,horses_A4   then assume that tag index position indicates correct information. One would scan the tag array until the key-tag is found, then assume each array position after that has information in order. I don't think it can just be "horses" or "dragons" because sexlab appears to strip duplicate tags in a number of places and this information would be lost. Additionally, if the tag is too simple, there is a decent chance someone puts that tag manuall for the animation and then the automated tags are stripped when loaded.

 

 

 

   Attached is a first attempt at this if you want to try...  I can do scripting/programming, but it is a hobby, so works will work, not be good, heh.

 

   There is a copy of some parts of the hcos, not entire thing. Just overrite existing with this, put back original when done. When trying aroused creatures edit, I needed that conventional order, so when creating the tagged version of the SLAL, I used a re-ordered version of the animations, sorry ..

   After putting this in place, re-run FNIS for users, and if this is is later removed, run it again on original hcos files.

   Also, SLAL registry needs to be re-registered to pick up new tags. This seems to be very particular:  Go to SLAL MCM,  disable all animations, rebuild Sexlab registry (watch console for when entries stop), reload JSON, save game, quit to main menu, reload game, in SLAL menu re-read json data again to be safe, enable all animations, Regsiter animations (watch console again, can take awhile), then rebuild sexlab registry (SLAL register and sexlab rebuild are not the same) (watch console again). Save and reload..

 

The matchmaker files, can just overwrite current matchmaker files and it should work. This completely ignores creature genders for now..

 

The effect should be that, appropriate animations and positions are chosen for >= 2 creature animations. It prefers them in the order which they are select from Actor 1 through Actor 5,  but will attempt to find any animation if that order doesn't exist. If multiple applicable animations exist, it should randomly select one.

 

This was built in skyrim SE.  I don't think any files involved care, except esp's were saved out as SE headers.

 

TempHCoS.7z

TempMM.7z

[WaxenFigure]

49 minutes ago, PaulGreen said:

 

   Strangely, for me, it is the other way around. The second creature selected is what sexlab will consider the "creature_race" of the animation. If I tag dragon -> horse  sexlab will search for an animatio where the SLAL json indicates creature_race="horses". I'm using Skyrim SE with latest versio of beta sexlab, maybe different versions do different things ?

 

   I was thinking tags should be clear that they are the programmatic tags added automatically by SLAL, so a definite prefix was useful. The race tag should probably match the racekey string used in sexlab (horses, dragons, canines, mammoths, ..) and was going to need a way to associate which creature race was what position. Probably this can be done by using one tag, or if sub-string search should be minimized, then it could assume a tag order, like  ... ,aggressive,oral,CRace_Tags,human_A1,dragons_A2,horses_A3,horses_A4   then assume that tag index position indicates correct information. One would scan the tag array until the key-tag is found, then assume each array position after that has information in order. I don't think it can just be "horses" or "dragons" because sexlab appears to strip duplicate tags in a number of places and this information would be lost. Additionally, if the tag is too simple, there is a decent chance someone puts that tag manuall for the animation and then the automated tags are stripped when loaded.

 

 

 

   Attached is a first attempt at this if you want to try...  I can do scripting/programming, but it is a hobby, so works will work, not be good, heh.

 

   There is a copy of some parts of the hcos, not entire thing. Just overrite existing with this, put back original when done. When trying aroused creatures edit, I needed that conventional order, so when creating the tagged version of the SLAL, I used a re-ordered version of the animations, sorry ..

   After putting this in place, re-run FNIS for users, and if this is is later removed, run it again on original hcos files.

   Also, SLAL registry needs to be re-registered to pick up new tags. This seems to be very particular:  Go to SLAL MCM,  disable all animations, rebuild Sexlab registry (watch console for when entries stop), reload JSON, save game, quit to main menu, reload game, in SLAL menu re-read json data again to be safe, enable all animations, Regsiter animations (watch console again, can take awhile), then rebuild sexlab registry (SLAL register and sexlab rebuild are not the same) (watch console again). Save and reload..

 

The matchmaker files, can just overwrite current matchmaker files and it should work. This completely ignores creature genders for now..

 

The effect should be that, appropriate animations and positions are chosen for >= 2 creature animations. It prefers them in the order which they are select from Actor 1 through Actor 5,  but will attempt to find any animation if that order doesn't exist. If multiple applicable animations exist, it should randomly select one.

 

This was built in skyrim SE.  I don't think any files involved care, except esp's were saved out as SE headers.

 

TempHCoS.7z

TempMM.7z

 

You know that while SLAL has all the action the Sexlab Framework ALSO has a built in equivalent to SLAL which includes options that SLAL doesn't, before you get too carried away developing a third system you may want to look into that and make sure you aren't reinventing the wheel here.  Perhaps all we need is a tool to convert SLAL packs to the Sexlab form so the additional specifications can be added to them.

[PaulGreen]

On 10/5/2018 at 10:56 AM, WaxenFigure said:

 

 

 

Wall of text!  I admit upfront that I'm an obsessive weirdo.. that's part of the fun, heh.

 

 

   From what I can see, the options available when registering with SLAL vs. the json registering with sexlab are the same. SLAL offers all of the options that sexlab offers when registering an animation,  unless I am not seeing somewhere that SLAL has not implemented saving all of the data in it's json files.

   The difference I see is that the 'quest registration' method for sexlab has the ability to call arbitrary code in the callback event when registering. That is more powerful if one wants to do more actions that just adding the normal set of data to a registering animation.

   In this context, that difference doesn't help, I think,  since it would still mean getting all animation packs to stop using SLAL or the sexlab json and use quest registration instead

 

   I re-reviewed the sexlab system to make sure I was not missing key points..  I still see that these two items I mentioned in another thread are the case: Sexlab does not currently provide a way of retrieving the per-position racekey for each animation  (sslBaseAnimation) nor does it have a way of specifying all races used in an animation when filtering the animation slots for valid animations.

 

 

For the point about getting each animation's race-per-position:

 

Spoiler

 

Finding each position's racekey is close, but not quite. Sexlab does, actually store this information in the animation object, but provides no way of retrieving the information. There are also are no functions to get at the information, other than checking individually if a position is a particular racekey.

 

In sslBaseAnimation:

scriptname sslBaseAnimation extends sslBaseObject

; import sslUtility
; import PapyrusUtil
; import Utility

; Config
int Actors
int Stages

string[] Animations
string[] RaceTypes   <---  not a property                         
string[] LastKeys
string LastKeyReg

 

One could just go through each position and test if it's a creature, then test it against every racekey string currently registered using  sslBaseAnimation.IsPositionRace  but that's alot of work on every call.

 

This could be made more practical if code were added in sslBaseAnimation like:

string[] RaceTypes
String[] function getPositionRaceKeys()
      return RaceTypes
endfunction

 

 

 

 

 

 

The second idea is that every animation stores only one racetype for filtering and searching.  For that:
 

Spoiler

 

The relavent code is here:

 

In sslBaseAnimation (near the end):

; ------------------------------------------------------- ;
; --- Properties                                      --- ;
; ------------------------------------------------------- ;

; Creature Use
string property RaceType auto hidden   <----
Form[] property CreatureRaces hidden

 

and also in sslBaseAnimation

int function AddCreaturePosition(string RaceKey, int Gender = 2, int AddCum = -1)
    if Actors >= 5
        return -1
    elseIf Gender <= 0 || Gender > 3
        Gender = 2
    elseIf Gender == 1
        Gender = 3
    endIf
    
    int pid = AddPosition(Gender, AddCum)
    if pid != -1 && RaceKey != ""
        if !RaceTypes || RaceTypes.Length < 1
            RaceTypes = new string[5]
        endIf
        RaceType       = RaceKey   <---------
        RaceTypes[pid] = RaceKey
    endIf

    return pid
endFunction

 

Basically, the last creture position added is what sets the racekey for that animation.

 

So, when searching the creature animations for particular races in mult-race animations, only one race will be searchable on that animation. To allow this within sexlab, the racetype would be an array of races and the filtering by racetype would check each index of that array for all the creature animations.

 

 

 

 

 

Am I wrong about any of the above?

 

 

Outside of sexlab, I can think of two ways of doing it, by using sexlab's tagging system to add tags with the information,  or by creating a separate quest script which maintains a list of this infromation with it's own filtering functions. It seems like abusing sexlab's tagging system is the easiest approach, so then one needs a method of adding the tags.. either it's done by the animation pack creator, or at the time of registering (requires using a sexlab quest registration, not sexlab json nor SLAL), or by creating a quest script which watches for animation registration, walks the slots and adds tags (this would be really inefficient since every racekey has to be checked against every animation position in every animation).

 

Any method outside sexlab still requires a convention that will be used.. Alot of animations already have tags like  Troll   Draugr   Dragon   and so forth, but these aren't the actual 'racekey' strings used by sexlab and are not universal. Using the actual sexlab raceykey strings seems the easiest, since then these are directly serachable insead of having to have some mapping from "common user tags" to actual racekeys.

 

The idea I was going with was,  since it seems like most animation packs are SLAL these days,  to see if SLAL's  "compilation" script simply could be adjusted to add tags to animations using the actual racekey strings for each race,  and with information about each animation position's racekey. It seems easy enough... the drawback is the annoying tags that end up on all the creature animations.

 

 

 

 

 

[MadMansGun]

10 hours ago, PaulGreen said:

Am I wrong about any of the above?

dammit Paul, i'm a Dragon Fucker Animator, not a Scripter.

 

and my biggest complaints with SLAL are:

1. it does not make valid FNIS lists for dogs and wolves/foxes, it just makes one called "canine" that needs to be copied and renamed.

2. it does not have a way to add AnimObjects per stage, the FNIS lists need to be fixed by hand.

i wish this:

Spoiler

Animation(
    id="dragonbodyjob",
    name="Dragon Bodyjob",
    tags="Bestiality,Dragon,HandJob",
    sound="SexMix",
    actor1=Female(add_cum=VaginalOralAnal),
    actor2=CreatureMale(race="dragons", object="HCOSDragonBodyJobS3 HCOSDragonBodyJobS5 HCOSDragonBodyJobS6 HCOSDragonBodyJobS7"),
    a1_stage_params= [
        Stage(7, open_mouth=True),
    ],
    stage_params = [
        Stage(1, timer=3.0, sound=NoSound),
        Stage(4, timer=11.5, sound=NoSound),
        Stage(7, timer=35.0, sound=NoSound),
    ]
)

was like this:

Spoiler

Animation(
    id="dragonbodyjob",
    name="Dragon Bodyjob",
    tags="Bestiality,Dragon,HandJob",
    sound="SexMix",
    actor1=Female(add_cum=VaginalOralAnal),
    actor2=CreatureMale(race="dragons"),
    a1_stage_params= [
        Stage(7, open_mouth=True),
    ],
    a2_stage_params= [
        Stage(3, object="HCOSDragonBodyJobS3"),
        Stage(5, object="HCOSDragonBodyJobS5"),
        Stage(6, object="HCOSDragonBodyJobS6"),
        Stage(7, object="HCOSDragonBodyJobS7"),
    ],
    stage_params = [
        Stage(1, timer=3.0, sound=NoSound),
        Stage(4, timer=11.5, sound=NoSound),
        Stage(7, timer=35.0, sound=NoSound),
    ]
)

to make this:

Spoiler

' mmg_dragonbodyjob
s mmg_dragonbodyjob_A2_S1 mmg_dragonbodyjob_a2_s1.HKX
+ mmg_dragonbodyjob_A2_S2 mmg_dragonbodyjob_a2_s2.HKX
+ -o mmg_dragonbodyjob_A2_S3 mmg_dragonbodyjob_a2_s3.HKX HCOSDragonBodyJobS3
+ mmg_dragonbodyjob_A2_S4 mmg_dragonbodyjob_a2_s4.HKX
+ -o mmg_dragonbodyjob_A2_S5 mmg_dragonbodyjob_a2_s5.HKX HCOSDragonBodyJobS5
+ -o mmg_dragonbodyjob_A2_S6 mmg_dragonbodyjob_a2_s6.HKX HCOSDragonBodyJobS6
+ -o mmg_dragonbodyjob_A2_S7 mmg_dragonbodyjob_a2_s7.HKX HCOSDragonBodyJobS7

and NOT this:

Spoiler

' mmg_dragonbodyjob
s -o mmg_dragonbodyjob_A2_S1 mmg_dragonbodyjob_a2_s1.HKX HCOSDragonBodyJobS3 HCOSDragonBodyJobS5 HCOSDragonBodyJobS6 HCOSDragonBodyJobS7
+ -o mmg_dragonbodyjob_A2_S2 mmg_dragonbodyjob_a2_s2.HKX HCOSDragonBodyJobS3 HCOSDragonBodyJobS5 HCOSDragonBodyJobS6 HCOSDragonBodyJobS7
+ -o mmg_dragonbodyjob_A2_S3 mmg_dragonbodyjob_a2_s3.HKX HCOSDragonBodyJobS3 HCOSDragonBodyJobS5 HCOSDragonBodyJobS6 HCOSDragonBodyJobS7
+ -o mmg_dragonbodyjob_A2_S4 mmg_dragonbodyjob_a2_s4.HKX HCOSDragonBodyJobS3 HCOSDragonBodyJobS5 HCOSDragonBodyJobS6 HCOSDragonBodyJobS7
+ -o mmg_dragonbodyjob_A2_S5 mmg_dragonbodyjob_a2_s5.HKX HCOSDragonBodyJobS3 HCOSDragonBodyJobS5 HCOSDragonBodyJobS6 HCOSDragonBodyJobS7
+ -o mmg_dragonbodyjob_A2_S6 mmg_dragonbodyjob_a2_s6.HKX HCOSDragonBodyJobS3 HCOSDragonBodyJobS5 HCOSDragonBodyJobS6 HCOSDragonBodyJobS7
+ -o mmg_dragonbodyjob_A2_S7 mmg_dragonbodyjob_a2_s7.HKX HCOSDragonBodyJobS3 HCOSDragonBodyJobS5 HCOSDragonBodyJobS6 HCOSDragonBodyJobS7

 

the most up to date pyw file:

SLAnimGenerateForMNCv11.pyw

 

edit:

3: it would be nice to have a way to add "AVbHumanoidFootIKDisable" automatically to human animations as well.

https://www.loverslab.com/blogs/entry/3873-disabling-footik-for-fnis-animations-the-easy-way/

 

[PaulGreen]

6 hours ago, MadMansGun said:

 

 

I understand, the difference in capability regarding SLAL is not between sexlab vs SLAL json animation specification, it is that the FNIS text file output is very (very) limited compared to the full range of options available for that file. This is true. If one wants more control over, not the sexlab options of an animation, but the actual working of the animation outside of sexlab, then SLAL's FNIS output is not ideal.

 

   I think that, practically, it's not really that limited since sexlab's animations will tend to be of very limited style compared to everything possible with FNIS. They will always be sequence animations with a few options like objects or some animvars.

 

 

   I think the problem with Dogs and Wolves is not really solvable generically. The problem is that wolves and dogs share the same animation folder, but then do not share the same behavior folders. This is unique to them, no other creature does this.

   SLAL will output the FNIS text file according to that list at the start. So

           "Wolves": "canine",

will mean to output all animation actor data for this race ( Wolves ) into the folder ./data/meshes/actor/canine  , Any racename that shares a folder name specification will go into the same text files. So

    "Dogs": "canine",

    "Wolves": "canine",

    "Canines": "canine",

    "Foxes": "canine",

will all end up in the same text file. There's still the problem that, for the ANIMATIONs you DO want them to look for and go to the same folder since Dogs and Wolves DO share the same animation folder,  but you DON'T want the behavior files to go together since they don't share the behaviors.  Strictly speaking, I think this is also incorrect when the behavior files end up being merged since wolves and dogs do not share behavior files, but it works out in the end since sexlab's animation filtering just happens to be set up by it and modders to never try to play the "dog" animations on "wolves" or vice versa.

   Additionally, that text string name like "Foxes" and "Wolves" is how SLAL will end up entering the RACEKEY name for the creature into sexlab. In other words, that string is the actual name that sexlab will use when searching for actors for the animations.

   Sexlab itself doens't recognize "Foxes" or even "Canines",  it is MoreNastyCritters that wipes out Sexlabs default race categories and rebuilds them in a different way with these extra racekeys,  and specifying the actual racenames to be attached to those keys.

 

 

 

   For the script and doing extra per-stage options, it looks like SLAL just never had the abilty to do that. Try this attached script and see if it works. I honestly don't know, you'll have to test  :3 .

   Format an animation like this to do it. There is NO CHECK on whether animation variables are actually real variables. Just don't get it wrong, heh.

Animation(
    id="foxonchicken",
    name="Fox on Chicken",
    tags="Creature,Interspecies,A1,Vulpes,Fox,A2,chicken,Missionary,Vaginal",
    sound="Squishing",
    actor1=CreatureMale(race="Foxes"),
    a1_stage_params = [
        Stage(1, object="HCOSFoxOnChicken"),
        Stage(2, animvars="AVbHumanoidFootIKDisable", object="HCOSFoxOnChicken"),
        Stage(4, animvars="AVbHumanoidFootIKDisable"),
        Stage(5, object="HCOSFoxOnChicken", animvars="AVbHumanoidFootIKDisable"),
    ],
    actor2=CreatureFemale(race="Chickens"),
    stage_params = [
        Stage(1, timer=3.3, sound=NoSound),
        Stage(4, timer=5.3, sound=NoSound),
        Stage(5, sound=Sucking),
    ]
)

   Also note that you can still put "object" and the new "animvars" parameter into the  actorX=   line. These "golbal actor" variables will override any per-stage actor variables that try to exist. So

 

    actor1=CreatureMale(race="Foxes", animvars="AVbHumanoidFootIKDisable"),

   would override any "animvars" parameters in the a1_stage_params stages. All stages for that actor "Foxes" will have those animvars.

 

 

 

   Realize that I'm editing someone else's work here.. I haven't talked to them at all, probably don't want to spread this around. If you think it works, I guess I can see if the SLAL person wants to actually put this in or not. I'd like confirmation that it works before doing it.

 

 

SLAnimGenerateForMNCv11-MyEdit.pyw

[PaulGreen]

12 hours ago, MadMansGun said:

 

Nope!  Wrong.  Correct thing is a few posts down.

Spoiler

 

   On an unrelated note, I figured out why some creatures get stuck after animations finish.. it looks like a bug in FNIS.

   In ./Data/tools/GenerateFNIS_for_Users/BehavioredObjects.txt   There's just some capitalization problems.. every place there there is ReturnDefaultState  it should be returnDefaultState

   I guess people just need to fix that on their own in their own setups.

 

 

 

[MadMansGun]

2 hours ago, PaulGreen said:

 I think the problem with Dogs and Wolves is not really solvable generically. The problem is that wolves and dogs share the same animation folder, but then do not share the same behavior folders. This is unique to them, no other creature does this.

   SLAL will output the FNIS text file according to that list at the start. So

           "Wolves": "canine",

will mean to output all animation actor data for this race ( Wolves ) into the folder ./data/meshes/actor/canine  , Any racename that shares a folder name specification will go into the same text files. So

    "Dogs": "canine",

    "Wolves": "canine",

    "Canines": "canine",

    "Foxes": "canine",

will all end up in the same text file. There's still the problem that, for the ANIMATIONs you DO want them to look for and go to the same folder since Dogs and Wolves DO share the same animation folder,  but you DON'T want the behavior files to go together since they don't share the behaviors.  Strictly speaking, I think this is also incorrect when the behavior files end up being merged since wolves and dogs do not share behavior files, but it works out in the end since sexlab's animation filtering just happens to be set up by it and modders to never try to play the "dog" animations on "wolves" or vice versa.

   Additionally, that text string name like "Foxes" and "Wolves" is how SLAL will end up entering the RACEKEY name for the creature into sexlab. In other words, that string is the actual name that sexlab will use when searching for actors for the animations.

   Sexlab itself doens't recognize "Foxes" or even "Canines",  it is MoreNastyCritters that wipes out Sexlabs default race categories and rebuilds them in a different way with these extra racekeys,  and specifying the actual racenames to be attached to those keys.

yes surprisingly i actually know and understand all about that already, i am the one that added the Canines and Foxes (and some other race entrys that actually work as intended)

and i am the one that edited MNC to "wipeout Sexlabs default race categories" (i had some help with that, and it was mostly done to fix the insect races)

 

2 hours ago, PaulGreen said:

For the script and doing extra per-stage options, it looks like SLAL just never had the abilty to do that. Try this attached script and see if it works. I honestly don't know, you'll have to test  :3 .

   Format an animation like this to do it. There is NO CHECK on whether animation variables are actually real variables. Just don't get it wrong, heh.

well first of all "AVbHumanoidFootIKDisable" is not for creatures, it's for Humanoids ?

secondly " open_mouth=True" is now causing stray minus signs to show up in the human fnis lists and it's causing generatefnisformodders to fail

(it seems to be fine if the actor has a AnimObject or is using FootIKDisable on the same stage...or all stages)

 

2 hours ago, PaulGreen said:

Realize that I'm editing someone else's work here.. I haven't talked to them at all, probably don't want to spread this around. If you think it works, I guess I can see if the SLAL person wants to actually put this in or not. I'd like confirmation that it works before doing it. 

don't worry too much, i already fucked with it before you did, that version of the pyw file was one i edited to have more races and i included it with MNCv11.

 

1 hour ago, PaulGreen said:

 

   On an unrelated note, I figured out why some creatures get stuck after animations finish.. it looks like a bug in FNIS.

 

   In ./Data/tools/GenerateFNIS_for_Users/BehavioredObjects.txt   There's just some capitalization problems.. every place there there is ReturnDefaultState  it should be returnDefaultState

 

   I guess people just need to fix that on their own in their own setups.

 

i tried that (and reran fnis), they are still broken (as far as i can tell)

[WaxenFigure]

If you need a function added to the Sexlab Framework I suggest you let Ashal know, he's never been reticent to add functions that cover things he didn't think of.

[MadMansGun]

4 hours ago, PaulGreen said:

.

shit, it's adding a unnecessary "-" to anything that has the "rotate=" command as well. (for MNC's stock animations that would be the benthiclurker, falmer, hagraven and troll fnis lists)

[PaulGreen]

1 hour ago, MadMansGun said:

 

 

   Ja, a programming error.  Try this one instead.

 

 

   And you're right about the FNIS.. too many things going on at once. That didn't fix it.. that was one observation I thought had fixed it. It's that a few creatures have a different call in sexlab required to return them to default state.

 

In sslActorAlias:

    if IsCreature
        ; Reset creature idle
        Debug.SendAnimationEvent(ActorRef, "Reset")
        Debug.SendAnimationEvent(ActorRef, "ReturnToDefault")
        Debug.SendAnimationEvent(ActorRef, "FNISDefault")
        Debug.SendAnimationEvent(ActorRef, "IdleReturnToDefault")
        Debug.SendAnimationEvent(ActorRef, "ForceFurnExit")
        Debug.SendAnimationEvent(ActorRef, "ReturnDefaultState")   <----- Need to add this
        if ResetAnim != "IdleForceDefaultState" && ResetAnim != ""
            ActorRef.Moveto(ActorRef)
            ActorRef.PushActorAway(ActorRef, 0.75)
        endIf
    else

   The  "ReturnDefaultState"  event is what a few creatures use to return, instead of the ReturnToDefault event.

 

NOTE!  I have no idea if this has unintended consequences. I just noticed that it works. It seems like the only creatures that have that event are the ones that didn't return correctly from sexlab, so I think it's okay:

 

grep -Ri "ReturnDefaultState" *
actors/ambient/chicken/behaviors/chickenbehavior_TEMPLATE.txt:            <hkcstring>ReturnDefaultState</hkcstring>
actors/ambient/hare/behaviors/harebehavior_TEMPLATE.txt:            <hkcstring>ReturnDefaultState</hkcstring>
actors/slaughterfish/behaviors/slaughterfishbehavior_TEMPLATE.txt:        <hkcstring>ReturnDefaultState</hkcstring>

 

 

 

SLAnimGenerateForMNCv11-MyEdit.pyw

[MadMansGun]

1 hour ago, PaulGreen said:

Ja, a programming error.  Try this one instead.

SLAnimGenerateForMNCv11-MyEdit.pyw

new problem: it added commas to my creature fnis lists (dragon and mammoth lists)

source.7z

' mmg_dragonbodyjob
s mmg_dragonbodyjob_A2_S1 mmg_dragonbodyjob_a2_s1.HKX
+ mmg_dragonbodyjob_A2_S2 mmg_dragonbodyjob_a2_s2.HKX
+ -,o mmg_dragonbodyjob_A2_S3 mmg_dragonbodyjob_a2_s3.HKX HCOSDragonBodyJobS3
+ mmg_dragonbodyjob_A2_S4 mmg_dragonbodyjob_a2_s4.HKX
+ -,o mmg_dragonbodyjob_A2_S5 mmg_dragonbodyjob_a2_s5.HKX HCOSDragonBodyJobS5
+ -,o mmg_dragonbodyjob_A2_S6 mmg_dragonbodyjob_a2_s6.HKX HCOSDragonBodyJobS6
+ -,o mmg_dragonbodyjob_A2_S7 mmg_dragonbodyjob_a2_s7.HKX HCOSDragonBodyJobS7

 

[PaulGreen]

 >.>   Sorry, another dumb mistake. Just forgot to undo an old condition for an 'if'

 

Thanks for the source. This seems to check out with all those files.

 

 

SLAnimGenerateForMNCv11-MyEdit.pyw

[MadMansGun]

25 minutes ago, PaulGreen said:

 >.>   Sorry, another dumb mistake. Just forgot to undo an old condition for an 'if'

 

Thanks for the source. This seems to check out with all those files.

 

 

SLAnimGenerateForMNCv11-MyEdit.pyw

looks good so far, i'll put it to serious use in the morning.?

this upgrade will be extremely useful for us animators, we have been fighting with footik and AnimObjects for far too long.

[SirNibbles]

Would it also be possible to input an edit for a specific stage to let the actors "cum" in the assigned stage?

 

And since I'm asking anyways, same as above but then with sound effects? e.g stage 1/2/3 plays sound effect regular sex effects and stage 4/5 blowjob sound effects?

 

[MadMansGun]

20 minutes ago, SirNibbles said:

And since I'm asking anyways, same as above but then with sound effects? e.g stage 1/2/3 plays sound effect regular sex effects and stage 4/5 blowjob sound effects?

you could already do that:

Quote

Animation(
    id=
    name=
    tags=
    sound="Squishing",
    actor1=
    actor2=
    stage_params = [
        Stage(1, sound=NoSound),
        Stage(5, sound=Sucking),
        Stage(6, timer=10.0, sound=Sucking),
    ]
)

"Squishing" should play in stages 2 3 and 4

[SirNibbles]

31 minutes ago, MadMansGun said:

you could already do that:

"Squishing" should play in stages 2 3 and 4

I've tried this before but it returned errors.

I'll give it a shot again with these lines.

[MadMansGun]

13 minutes ago, SirNibbles said:

I've tried this before but it returned errors.

I'll give it a shot again with these lines.

watch out for commas and brackets, and some of my animations use these stage sound settings as well so look at my newest source files for working examples (scroll up the page a bit)

https://www.loverslab.com/topic/108599-designating-positions-in-animations/?do=findComment&amp;comment=2392878

 

[MadMansGun]

On 10/7/2018 at 9:44 PM, PaulGreen said:

 >.>   Sorry, another dumb mistake. Just forgot to undo an old condition for an 'if'

 

Thanks for the source. This seems to check out with all those files.

i found another problem but this time it's not a consistent one, it sometimes does not detect changes to AnimObjects settings if it's a creature on creature animation (or at least that's where i am seeing it happen), at first it detects when i add the "object=" but if i try to add/remove/rename objects (or delete the "a#_stage_params" line completely) it continues to say "all FNIS lists up-to-date" and wont update it:

 

first time object added to animation

Animation(
    id="gaywerewolffystyle",
    name="Werewolffy Style (Gay)",
    tags="Creature,werewolf,Gay,DoggyStyle,Anal",
    sound="Squishing",
    actor1=CreatureMale(race="Werewolves"),
    actor2=CreatureMale(race="Werewolves"),
    a1_stage_params= [
        Stage(4, object="HCOSGenericWerewolfCum HCOSWerewolffyStyleS4"),
    ],
    stage_params = [
        Stage(1, timer=7.3, sound=NoSound),
        Stage(4, sound=SexMix),
        Stage(5, timer=9.0, sound=NoSound),
    ]
)

fnis list updates fine

' mmg_gaywerewolffystyle
s mmg_gaywerewolffystyle_A1_S1 mmg_gaywerewolffystyle_a1_s1.HKX 
+ mmg_gaywerewolffystyle_A1_S2 mmg_gaywerewolffystyle_a1_s2.HKX 
+ mmg_gaywerewolffystyle_A1_S3 mmg_gaywerewolffystyle_a1_s3.HKX 
+ -o mmg_gaywerewolffystyle_A1_S4 mmg_gaywerewolffystyle_a1_s4.HKX HCOSGenericWerewolfCum HCOSWerewolffyStyleS4
+ mmg_gaywerewolffystyle_A1_S5 mmg_gaywerewolffystyle_a1_s5.HKX 
s mmg_gaywerewolffystyle_A2_S1 mmg_gaywerewolffystyle_a2_s1.HKX 
+ mmg_gaywerewolffystyle_A2_S2 mmg_gaywerewolffystyle_a2_s2.HKX 
+ mmg_gaywerewolffystyle_A2_S3 mmg_gaywerewolffystyle_a2_s3.HKX 
+ mmg_gaywerewolffystyle_A2_S4 mmg_gaywerewolffystyle_a2_s4.HKX 
+ mmg_gaywerewolffystyle_A2_S5 mmg_gaywerewolffystyle_a2_s5.HKX 

add/remove/change objects in any way

Animation(
    id="gaywerewolffystyle",
    name="Werewolffy Style (Gay)",
    tags="Creature,werewolf,Gay,DoggyStyle,Anal",
    sound="Squishing",
    actor1=CreatureMale(race="Werewolves"),
    actor2=CreatureMale(race="Werewolves"),
    a1_stage_params= [
        Stage(4, object="HCOSGenericWerewolfCum ABCDE12345"),
    ],
    stage_params = [
        Stage(1, timer=7.3, sound=NoSound),
        Stage(4, sound=SexMix),
        Stage(5, timer=9.0, sound=NoSound),
    ]
)

wrongfully says that it's "up-to-date" and wont update

' mmg_gaywerewolffystyle
s mmg_gaywerewolffystyle_A1_S1 mmg_gaywerewolffystyle_a1_s1.HKX 
+ mmg_gaywerewolffystyle_A1_S2 mmg_gaywerewolffystyle_a1_s2.HKX 
+ mmg_gaywerewolffystyle_A1_S3 mmg_gaywerewolffystyle_a1_s3.HKX 
+ -o mmg_gaywerewolffystyle_A1_S4 mmg_gaywerewolffystyle_a1_s4.HKX HCOSGenericWerewolfCum HCOSWerewolffyStyleS4
+ mmg_gaywerewolffystyle_A1_S5 mmg_gaywerewolffystyle_a1_s5.HKX 
s mmg_gaywerewolffystyle_A2_S1 mmg_gaywerewolffystyle_a2_s1.HKX 
+ mmg_gaywerewolffystyle_A2_S2 mmg_gaywerewolffystyle_a2_s2.HKX 
+ mmg_gaywerewolffystyle_A2_S3 mmg_gaywerewolffystyle_a2_s3.HKX 
+ mmg_gaywerewolffystyle_A2_S4 mmg_gaywerewolffystyle_a2_s4.HKX 
+ mmg_gaywerewolffystyle_A2_S5 mmg_gaywerewolffystyle_a2_s5.HKX