SexoutNG '98 BETA 8

[Machiavelique]

1 hour ago, nopse0 said:

What I don't understand is, that  fnSexoutEndedEventCheck looked like this:

	foreach entry <- SexoutNG.animsSexoutEndToAddList
		Ar_Append SexoutNG.animsSexoutEndList, *entry
	loop
	SexoutNG.animsSexoutEndToAddList = Ar_Construct "array"        

So, I should have got the "uninitialized array" error only once, because after the loop it gets reinitialized. But this error repeated endlessly,

 

Probably fnSexoutEndedEventCheck stop running when failing to execute 'foreach entry <- SexoutNG.animsSexoutEndToAddList', so it closes the UDF and can't execute 'SexoutNG.animsSexoutEndToAddList = Ar_Construct "array" ' that could have solved the issue. And this error repeats in loops, fnSexoutEndedEventCheck being called from SexoutNGMAIN

 

 

I hadn't noticed, but you also have all these errors that are not related to fnSexoutEndedEventCheck:

12 hours ago, nopse0 said:

[06:40:25.0975] [25000B5F] talking effect starting
[06:40:25.0983] [230D0E47] Positioning Active. Robbi B selected
[06:41:29.0317] [23082D04] Error in script 23082D04 (SexoutNGCleanupEffectSCRIPT) in mod Sexout.esm
Invalid array access - the array was not initialized. 0
Operator [ failed to evaluate to a valid result
Script line approximation: Let ##SexoutNGConvCBQuest.arTodoAdd[iTmp]## := ar_Construct "stringmap" (error wrapped in ##'s)
	Where SexoutNGConvCBQuest.arTodoAdd=uninitialized array, iTmp=-1
    File: Sexout.esm Offset: 0x0DE2 Command: Let
[06:41:29.0318] [23082D04] Error in script 23082D04 (SexoutNGCleanupEffectSCRIPT) in mod Sexout.esm
Invalid array access - the array was not initialized. 0
Operator [ failed to evaluate to a valid result
Script line approximation: Let ##SexoutNGConvCBQuest.arTodoAdd[iTmp]##["actor"] := (cbActor.RefToString) (error wrapped in ##'s)
	Where SexoutNGConvCBQuest.arTodoAdd=uninitialized array, iTmp=-1, cbActor=[id: 13D5BF, edid: "VStripNCRTrooperBREF", name: "NCR Trooper"]
    File: Sexout.esm Offset: 0x0E0B Command: Let
[06:41:29.0318] [23082D04] Error in script 23082D04 (SexoutNGCleanupEffectSCRIPT) in mod Sexout.esm
Invalid array access - the array was not initialized. 0
Operator [ failed to evaluate to a valid result
Script line approximation: Let ##SexoutNGConvCBQuest.arTodoAdd[iTmp]##["topic"] := (RefToString CBDialog) (error wrapped in ##'s)
	Where SexoutNGConvCBQuest.arTodoAdd=uninitialized array, iTmp=-1
    File: Sexout.esm Offset: 0x0E32 Command: Let
[06:41:29.0318] [23082D04] Error in script 23082D04 (SexoutNGCleanupEffectSCRIPT) in mod Sexout.esm
Invalid array access - the array was not initialized. 0
Operator [ failed to evaluate to a valid result
Script line approximation: Let ##SexoutNGConvCBQuest.arTodoAdd[iTmp]##["actid"] := nActId (error wrapped in ##'s)
	Where SexoutNGConvCBQuest.arTodoAdd=uninitialized array, iTmp=-1, nActId=0
    File: Sexout.esm Offset: 0x0E5C Command: Let
[06:41:52.0749] [2700220D] NGreets: NCR Military Police : Timer expired (120.004)

 

These errors suggest that the upgrade did not proceed correctly. All these arrays (including SexoutNG.animsSexoutEndToAddList) should have been initialized in fnSexoutUpgrade2x11. So, it's very interessing cause the new SexoutNG version will not preserve you (and any user of 2.10 version)  from this kind of error.

Problem is here:

    elseif SexoutNG.nVerMaj == 2 && SexoutNG.nVerMin == 11 && (SexoutNG.nVerRelN > SexoutNG.nVerRel || (SexoutNG.nVerRelN == SexoutNG.nVerRel && iBetaTrans))
      Call fnSexoutUpgrade2x11 SexoutNG.nVerRel SexoutNG.iBeta
    endif

 

This line handles upgrades from 2.11 to higher 2.11 versions, but not from 2.10 to 2.11.

I made the same mistake just above as well as other types of errors. so It would be best if I reviewed the entire script.

I don't think I'll release version 2.11.3 beta 6 since 2.11.4 is coming soon.
I will include this fix in 2.11.4, then I can send you a fixed sexout.esm 2.11.3 beta 5 to test if you wish.
 

[Machiavelique]

 I jumped to conclusions a little too quickly in my analysis. I thought I had swapped the new version and the current version in the checks, but I was wrong.
In the end, fnSexoutUpgrade just has a tiny error that causes upgrade problems for some versions from 2.10 to 2.11.

 

    if SexoutNG.nVerMaj + SexoutNG.nVerMin + SexoutNG.nVerRel + SexoutNG.iBeta == 0
      Call fnSexoutUpgrade2x10 0 0
      Call fnSexoutUpgrade2x11 0 0
    elseif SexoutNG.nVerMaj == 2 && SexoutNG.nVerMin == 10 && (SexoutNG.nVerRel < 98 || SexoutNG.nVerRel == 98 && SexoutNG.iBetaN <= 2)
      Call fnSexoutUpgrade2x10 SexoutNG.nVerRel SexoutNG.iBeta
      Call fnSexoutUpgrade2x11 0 0
    elseif SexoutNG.nVerMaj == 2 && SexoutNG.nVerMin == 11 && (SexoutNG.nVerRelN > SexoutNG.nVerRel || (SexoutNG.nVerRelN == SexoutNG.nVerRel && iBetaTrans))
      Call fnSexoutUpgrade2x11 SexoutNG.nVerRel SexoutNG.iBeta

    endif

 

Here the 2.11.3 beta 5 fixed, but be aware that this version contains other issues. However, upgrade should now proceed correctly.

Spoiler

Sexout.esm

 

 

(Please note that the upgrade will not start if you have saved your game with the bugged 2.11.3 beta 5. You will need to load a game saved with a Sexout version lower than 2.11.3 beta 5)

Edited November 10, 2025 by Machiavelique

[nopse0]

5 hours ago, Machiavelique said:

 I jumped to conclusions a little too quickly in my analysis. I thought I had swapped the new version and the current version in the checks, but I was wrong.
In the end, fnSexoutUpgrade just has a tiny error that causes upgrade problems for some versions from 2.10 to 2.11.

 

    if SexoutNG.nVerMaj + SexoutNG.nVerMin + SexoutNG.nVerRel + SexoutNG.iBeta == 0
      Call fnSexoutUpgrade2x10 0 0
      Call fnSexoutUpgrade2x11 0 0
    elseif SexoutNG.nVerMaj == 2 && SexoutNG.nVerMin == 10 && (SexoutNG.nVerRel < 98 || SexoutNG.nVerRel == 98 && SexoutNG.iBetaN <= 2)
      Call fnSexoutUpgrade2x10 SexoutNG.nVerRel SexoutNG.iBeta
      Call fnSexoutUpgrade2x11 0 0
    elseif SexoutNG.nVerMaj == 2 && SexoutNG.nVerMin == 11 && (SexoutNG.nVerRelN > SexoutNG.nVerRel || (SexoutNG.nVerRelN == SexoutNG.nVerRel && iBetaTrans))
      Call fnSexoutUpgrade2x11 SexoutNG.nVerRel SexoutNG.iBeta

    endif

 

Here the 2.11.3 beta 5 fixed, but be aware that this version contains other issues. However, upgrade should now proceed correctly.

  Hide contents

Sexout.esm 1.24 MB · 0 downloads

 

 

(Please note that the upgrade will not start if you have saved your game with the bugged 2.11.3 beta 5. You will need to load a game saved with a Sexout version lower than 2.11.3 beta 5)

 

Perfect, no problems now. I updated, saved, quit, restarted and reloaded, whored myself out with NaughtyDeeds, had sex with a King, and got my payment afterwards (before, I didn't get paid, because the after sex hooks weren't called because of the bugs), and this is the log I got:ConsoleOut.txt, no errors, everything perfect.

 

Furthermore, the 3rd person camera origin was unchanged after the sex scene, that's the main reason, why I want to upgrade. Because otherwise, when the camera position is screwed up, this not only looks bad, but it also makes it almost impossible to hit anything with your gun in 3rd person afterwards.  Would it perhaps be possible, to integrate  the camera fix (and other bug fixes) into the stable branch ?

 

 

 

[Machiavelique]

Glad it works !

 

But in your log file, the following entries are strange:

Spoiler

[05:18:13.0355] [00000000] [10_10.0440_23E3E69C]
[05:18:13.0356] [00000000] [10_10.0440_23E3E69C][11_10.9502_40929BD8]
[05:18:13.0356] [00000000] [10_10.0440_23E3E69C][11_10.9502_40929BD8][11_17.2204_14622B34]
[05:18:13.0356] [00000000] [10_10.0440_23E3E69C][11_10.9502_40929BD8][11_17.2204_14622B34][12_22.5263_6FFBFFE0]
[05:18:13.0356] [00000000] [10_10.0440_23E3E69C][11_10.9502_40929BD8][11_17.2204_14622B34][12_22.5263_6FFBFFE0][13_20.5146_1F617B24]
[05:18:13.0356] [00000000] [10_10.0440_23E3E69C][11_10.9502_40929BD8][11_17.2204_14622B34][12_22.5263_6FFBFFE0][13_20.5146_1F617B24][13_21.8287_1AEB6126]
[05:18:13.0357] [00000000] [10_10.0440_23E3E69C][11_10.9502_40929BD8][11_17.2204_14622B34][12_22.5263_6FFBFFE0][13_20.5146_1F617B24][13_21.8287_1AEB6126][14_0.4947_2CA88B0B]
[05:18:13.0357] [00000000] [10_10.0440_23E3E69C][11_10.9502_40929BD8][11_17.2204_14622B34][12_22.5263_6FFBFFE0][13_20.5146_1F617B24][13_21.8287_1AEB6126][14_0.4947_2CA88B0B][14_12.4807_3B59B190]
[05:18:13.0357] [00000000] [10_10.0440_23E3E69C][11_10.9502_40929BD8][11_17.2204_14622B34][12_22.5263_6FFBFFE0][13_20.5146_1F617B24][13_21.8287_1AEB6126][14_0.4947_2CA88B0B][14_12.4807_3B59B190][14_13.7421_222CB6E5]
[05:18:13.0357] [00000000] [10_10.0440_23E3E69C][11_10.9502_40929BD8][11_17.2204_14622B34][12_22.5263_6FFBFFE0][13_20.5146_1F617B24][13_21.8287_1AEB6126][14_0.4947_2CA88B0B][14_12.4807_3B59B190][14_13.7421_222CB6E5][14_15.5275_0EE0F12D]

 

TBH, I don't know what it corresponds to, it looks like arrays that cannot be displayed correctly, but if they are arrays, I don't see what mod could make arrays with such a large dimension. I don't know what to think about these entries.

You also have mods that attempt to output strings longer than 512 characters in the console, and this is rejected by the engine. But it's not really an issue.

 

 

 

 

5 hours ago, nopse0 said:

Would it perhaps be possible, to integrate  the camera fix (and other bug fixes) into the stable branch ?

In fact, the goal is for SexoutNG 2.11 to one day become the stable branch. The camera fix could be added in 2.10.98 because it does not require any major modifications.

However, if this fix had been included in 2.10.98, you would not have tested 2.11.3 beta 5, and I would not have been aware of this upgrade issue. At least until the release of a possible 2.11.4 beta 3, assuming that a user attempts an upgrade from version 2.10 and reports the problem (which they do not always do).

Note that the update from 2.10 to 2.11.4 beta 1 would have worked fine with the old code because SexoutNG.iBetaN will be set to ‘1’ so SexoutNG.iBetaN <= 2 will work.

 

So I am counting on the new version, hoping that its features will encourage users to test it and report any issues they encounter. The only thing I cannot guarantee is compatibility with mods that overwrite Sexout scripts. This can be managed with authors who are still active when only a few scripts are overwritten, but not when there are many.

I also couldn't make the new versions of Sexout compatible with the German version of FalloutNV (No Gore version). At least not until NVSE supports this version again (which doesn't seem to be their intention).

[Machiavelique]

Updated installation guide with new SOFA version (2025-11-11 1.6)

Removed SexoutNG 2.10.98 beta 7 - SOFA Pack since SOFA now includes all the necessary files

[Allnarta]

So, I updated my animations pack and now it will require WIP SNG 2.11+ for all new versions (Legacy version is navaible to download but will not be maintained anymore).

It includes all furniture animations I have at the moment; I aded base ID's for all vanilla furn meshes that fit animations I made (naval chair, couch and dumpster atm).

I'll wait for WIP SNG update that will include furniture support to see how it works.

Adding mod furniture is still a question though, as I understand at this moment it has to go straight to main .ini record to furn= list? It's not very handy when I want to take in account, dozens of mods that add potentially relevant baseIDs  to be honest.

Edited November 26, 2025 by Allnarta

[justanotherpassingby]

6 hours ago, Allnarta said:

Adding mod furniture is still a question though, as I understand at this moment it has to go straight to main .ini record to furn= list? It's not very handy when I want to take in account, dozens of mods that add potentially relevant baseIDs  to be honest.

i'm not big into modding by any means but have you checked this?

maybe there is a way to tag some furniture at least by it's displayed name

[Allnarta]

???

It was a question to SNG developers about how exactly furniture support will work and maybe suggestion to improve some of it's aspects.

[tardwranglerjohn]

Hello, first of all youre a legend for reviving Sexout. I have a couple of issues tho and things I'm confused about.

First of all, to use the beta 2.11, do we first install the 2.10 full pack, then just load the 2.11 beta after? 

When using the 2.11 beta, it says to disable sexoutposnew. But the issue is, adjusting animation positions with the sexoutng keybinds does not work for me. The keybinds seem to do nothing and i cant adjust animations. 

And with Allnarta's newest animation pack update which uses an ini instead of an esp, does this mean we no longer need the patch for his animations? will his animations still show up?

Thank you in advance  

[Machiavelique]

On 11/26/2025 at 11:30 AM, Allnarta said:

Adding mod furniture is still a question though, as I understand at this moment it has to go straight to main .ini record to furn= list? It's not very handy when I want to take in account, dozens of mods that add potentially relevant baseIDs  to be honest.

 

I'm not sure if that's your question, but yes, you can add lists of furniture Editor IDs from other mods.  NG will simply ignore EditorIDs that it is unable to rebuild as refs, so whether or not the user has installed these mods will have no impact.

I was expecting questions about the new NG, so I added specific documentation about AnimDef.ini files and updated the SexoutNG API to make it compliant with SexoutNG 2.11

 

 

 

 

7 hours ago, tardwranglerjohn said:

Hello, first of all youre a legend for reviving Sexout. I have a couple of issues tho and things I'm confused about.

It's normal for things to be confusing; it wasn't easy before, and we're currently in the middle of a transition period. I think I will release the update later today and things should become easier.

 

 

8 hours ago, tardwranglerjohn said:

First of all, to use the beta 2.11, do we first install the 2.10 full pack, then just load the 2.11 beta after?

Yes for 2.11.3 beta 5 and LOWER, indeed you first need to install any 2.10 version (even 2.10.97 or just SOFA) then install 2.11.3 beta 5 et load it after the 2.10 versions

No with 2.11.4 beta 1 and HIGHER.  You will need to  unistall any previous SexoutNG versions then install 'SexoutNG 2.11.4 beta 1 - Full Pack' if you don't use SOFA or 'SexoutNG 2.11.4 beta 1 - SOFA Pack' if you use SOFA (but will require SOFA 2025-11-11 1.6 or HIGHER).  To put it more simply, the installation procedure for SexoutNG 2.11.4 will be the same as for SexoutNG 2.10.98 beta 7, except for SOFA users, who will need to install SOFA Pack instead of Full Pack. 

 

 

9 hours ago, tardwranglerjohn said:

But the issue is, adjusting animation positions with the sexoutng keybinds does not work for me. The keybinds seem to do nothing and i cant adjust animations. 

It's a bug in 2.11.3 beta 5 and LOWER, you first need to increase speed (NumPAD 5 key by default). Have been fixed in 2.11.4

 

 

9 hours ago, tardwranglerjohn said:

And with Allnarta's newest animation pack update which uses an ini instead of an esp, does this mean we no longer need the patch for his animations? will his animations still show up?

Indeed the AllnartaSexoutAnimations-testsngfix.esp is required for 2.11.3 beta 5 and LOWER

But no relevant when using 2.11.4 beta 1 and HIGHER and shiould be deleted.

[tardwranglerjohn]

Thank you for the reply. That clears up all my issues actually. Is the 2.11.4 beta 1 out yet, or is it the next planned released? 

[Machiavelique]

Not yet released, but it seems that a problem on Loverlab is currently blocking me from releasing files larger than 100 MB (It fails every time I reach 100 MB uploaded, regardless of the file). Probably Loverlab is overloaded at the moment, I'll try again later.

[Machiavelique]

Released SexoutNG 2.11.4 Beta 1

Updated installation guide for SexoutNG 2.11

 

Documentations for SexoutNG 2.11 are available in DATA\Docs\SexoutNG

(I will probably try to merge AnimDef_Doc with SexoutNG 2.11 API in the future , but not sure how I will be able to structure it properly)

[Allnarta]

On 11/29/2025 at 3:53 PM, Machiavelique said:

I'm not sure if that's your question, but yes, you can add lists of furniture Editor IDs from other mods.  NG will simply ignore EditorIDs that it is unable to rebuild as refs, so whether or not the user has installed these mods will have no impact.

 

Is there a way to add them externally, aka with separate .ini files? Having all editorIDs from all potential mods (thousands) in main animations .ini does not sound very good, tbh. Separate patches for mods sounds a lot better to me.

[Machiavelique]

I assumed taht this structure would be sufficiently clear and practical.

TagDef.ini

[Furn]
FurnFromModAlpha=BedAlpha01, BedAlpha02, BedAlpha03, CouchAlpha01
BedFromModAlpha=BedAlpha01, BedAlpha02
FurnFromModBeta=BedBeta01, CouchBeta01, ChairBeta01
FurnFromModZeta=CouchZeta05, TableZeta03, BedZeta13
CustomBeds01=HotelBedQueenBothSides, HotelBedQueenLeft, HotelBedQueenRight, BedAlpha01, BedAlpha02, BedBeta01, BedZeta13

 

 

Do you would like something as:

 

TagDef.ini

; Defautl TagDef.ini
[Furn]
MyBeds01=SubQueenBed01BothSides, SubQueenBed01DirtyBothSides, SubQueenBed01DirtyR, SubQueenBed01R

 

TagDef_Patch1.ini

; Furn for Mod Apha
[Furn]
FurnFromModAlpha=BedAlpha01, BedAlpha02, BedAlpha03, CouchAlpha01
BedFromModAlpha=BedAlpha01, BedAlpha02

 

TagDef_Patch2.ini

; Furn for Mod Beta
[Furn]
FurnFromModBeta=BedBeta01, CouchBeta01, ChairBeta01

 

TagDef_Patch3.ini

; Furn for Mod Zeta
[Furn]
FurnFromModZeta=CouchZeta05, TableZeta03, BedZeta13

 

[Allnarta]

I like separate .ini files structure more, as I think it's a lot more modular.

[Allnarta]

So, trying to test latest WIP version, I stumbled into several issues:

-If player is bottom (ActorB) in called act, he stands in normal idle for a few seconds when sex already started before actually start playing animation (does not happen to NPC). Looks like it does not happen when act is rape, only with normal sex.

-If player is top (ActorA) - sex does not start at all. I tried this one with both male and female NPC. It also does not matter if act is marked as rape.

-With creatures, animationProp stucks on creature forever after sex.

-Some creatures don't work (for example supermutant random animation just does not run at all).

-When I try to call furniture animation, it works partially: NPC does not teleport to player and does not play animation at all, just standing where it was. On the other side, player properly plays his part (few seconds of just standing before starting to play animation is still relevant issue here), and animations switch does work correctly according to chosen furniture (aka, anal animation on the couch properly cycle couch animations).

Also, important thing:

-As I understand, now, if furniture is set incorrectly, animation fails. It will break a lot of already existing SNG mods (ones that use bed ref for example) and may cause unexpected issues with a lot of situations with vanilla furniture replacers, for example. I think failing to find furniture should not fail act, it should just start it on the floor as ususal, kust like it does when it does not find animation number (it just starts random sex act).

Edited December 1, 2025 by Allnarta
added few things

[Allnarta]

Here's some screenshots of console/errors that pup-up:
 

 

 

 

 



 



 



 



 



 

 

 

 

 

Edited December 1, 2025 by Allnarta

[Darkflip95]

Hey there, I've been asking around, but are there any resources or tools for making custom animations for Sexout? I know how to import and export models and make them, but I've been interested in getting into animation and wanted to try making some for the mod.

[Allnarta]

I mean, I gave you a link to fully working humans rig intended and designed to make and export animations for Sexout. That is perfect start for that.

I really don't want my last posts to be lost somewhere, as at this moment latest SNG WIP is legitimately broken and non-playable.

[Machiavelique]

On 12/1/2025 at 3:32 PM, Allnarta said:

So, trying to test latest WIP version, I stumbled into several issues:

-If player is bottom (ActorB) in called act, he stands in normal idle for a few seconds when sex already started before actually start playing animation (does not happen to NPC). Looks like it does not happen when act is rape, only with normal sex.

-If player is top (ActorA) - sex does not start at all. I tried this one with both male and female NPC. It also does not matter if act is marked as rape.

-With creatures, animationProp stucks on creature forever after sex.

-Some creatures don't work (for example supermutant random animation just does not run at all).

 

 

I tried Player Male/Female as well as Player ActorA/ActorB with and without raper. I tried all combinations and did not observe any of the problems mentioned above (player remaining standing for a few seconds while the NPC animation has already started, no player animation when Player is ActorA, animationProp stucks on creature forever after sex, supermutant random animation not workining).

It's strange that you have so many problems on your side and I don't experience any of them. So it seems more logical to me to think that you have something that triggers all these problems.

 

 

Here are the mods loaded for my tests:

 

I tested with Ringo/Player and Sunny/Player, switching between ActorA/ActorB, and also with Player Male/Female. 

I also tested with different KO values as well as without KO because the errors on your screens occur when KO is applied. What's more, you don't experience some issues between rape and consensual sex, and one difference between rape and consensual sex is that KO does not apply to consensual sex. So it seemed like a good lead to me, but I wasn't able to identify any problems. 

I would therefore suggest reducing your list of mods to the ones above and trying ActRunFull with Ringo/Player or Sunny/Player to see if you still experience these problems. I suspect there are mods that we haven't identified yet that are rewriting SexoutNGEffectBaseScriptF and/or SexoutNGCleanupEffectSCRIPT (these spells are now inhibited but still cast for Legacy support). 

Your problems are very strange, it's as if the quest script that manages the animations is running slowly. In console, can you also try:

Print "" + $(GetQuestDelay SexoutNGAM)

and tell me the returned value? (0.01 is the expected value)

 

Regarding the tests with creature props and random supermutant animations, I tested with CrFeralGhoul1A and JacobstownMarcus using

Player.PlaceAtMe CrFeralGhoul1A 1 50

Player.PlaceAtMe JacobstownMarcus 1 50

 

 

 

On 12/1/2025 at 3:32 PM, Allnarta said:

-When I try to call furniture animation, it works partially: NPC does not teleport to player and does not play animation at all, just standing where it was. On the other side, player properly plays his part (few seconds of just standing before starting to play animation is still relevant issue here), and animations switch does work correctly according to chosen furniture (aka, anal animation on the couch properly cycle couch animations).

 

The behavior you describe is exactly what I'm seeing. It seems that I inadvertently broke the furniture system during the last modifications, because it was working fine before. I'll look into what's wrong.

 

 

 

On 12/1/2025 at 3:32 PM, Allnarta said:

Also, important thing:

-As I understand, now, if furniture is set incorrectly, animation fails. It will break a lot of already existing SNG mods (ones that use bed ref for example) and may cause unexpected issues with a lot of situations with vanilla furniture replacers, for example. I think failing to find furniture should not fail act, it should just start it on the floor as ususal, kust like it does when it does not find animation number (it just starts random sex act).

 

You're right about that. I'll reconsider those restrictions, even though I don't like returning ‘true’ to indicate that the requested parameters have been validated when they haven't, and that I'm going to modify what was requested so that the animation can be started.

[Allnarta]

11 hours ago, Machiavelique said:

You're right about that. I'll reconsider those restrictions, even though I don't like returning ‘true’ to indicate that the requested parameters have been validated when they haven't, and that I'm going to modify what was requested so that the animation can be started.

 

I am absolutely convinced that if any mod calls sexout, under any circumstances,, it should always, in 100% of cases run at least some act even if it does not fit original call intention. Refusing ActRunFull call completely is absolute disaster in 100% of cases and will just break things in 99% of cases (DialogueAfter, Started/Ended events, hella lot of things will go wrong). This is why Beta 98 never refuse ActRunFull call and just run random act if it didn't meet conditions.
 

Edited December 6, 2025 by Allnarta

[Allnarta]

Important UPD: looks like I found what is going on with invalid actor reference.

 

Some of dialogues I used for tests used "call fnSexoutActRunFull (Ar_Map "ActorA"::0, "ActorB"::PlayerREF)" syntax instead of "call fnSexoutActRunFull (Ar_Map "ActorA"::GetSelf, "ActorB"::PlayerREF)". I do know that using 0 is a bad practice here, and I never use it in my actual release mods, but a lot of older Sexout mods use exactly 0 and not GetSelf (before latest update it only screwed up "raper" string so potential rapes were not treated as ones, but sex itself still worked).

So, failed act start is kinda issue for many old SNG mods as it will completely screw them up (like sewer slave etc.), but generally it's not an error, but vice versa, as now it works more like you can expect it to (because it logically returns 0). I assume older SNG got some king of failsafe for this cases and replaced 0 with getself of lates dialogue or something.

 

I still get very slow sex start though; and every time after sex ends I get this error:

 

Here's full video of what's going on, with periodically showing off console spam (actors are not undressed so video is SFW for youtube; you can see at the very end of it that eror pops-up some time after):
 

 

 

Edited December 6, 2025 by Allnarta

[Allnarta]

A little bit of offtop here - I begun to make wall-leaning animations for sexout.

 

Spoiler

 

 

 

 

After some investigating, my conclusion is that best option for that is separate wall-related invisible static object (aka marker) to use and not actual wall static refs because:

-A lot of them can have different native transform which means anims may be wrong positioned for a lot of them).

-Adding thousands of wall static editorID's to furn list sounds very bloated.

 

With single wall marker all you need to do is add it in GECK (or even by Plugins+/Scriptrunner script to not take plugin spot) and it will work.

 

Spoiler

 

So other modmakers can use it to add markers to worldpace or make animations based on it (if there's someone who will want to).

 

So, if it's possible, I'd like to ask you to add this mesh as static object to Sexout.esm itself (prob call it easy as that, SexoutWall?).

 

SexoutWall.7z

 

Edited December 6, 2025 by Allnarta

[Machiavelique]

13 hours ago, Allnarta said:

I am absolutely convinced that if any mod calls sexout, under any circumstances,, it should always, in 100% of cases run at least some act even if it does not fit original call intention. Refusing ActRunFull call completely is absolute disaster in 100% of cases and will just break things in 99% of cases (DialogueAfter, Started/Ended events, hella lot of things will go wrong). This is why Beta 98 never refuse ActRunFull call and just run random act if it didn't meet conditions.

 

I don't really agree. Sexout must ensure that what is requested is carried out or inform the mod that it is unable to process the request. I can understand that this may cause problems for very old mods where the Sexout interface did not provide any means of communication (in native Sexout versions, it's hit or miss, and if it misses, the user's progress may be ruined).

Since I have to ensure that Sexout can continue to work with older mods, what I am trying to implement is to reject the request if it is likely to ruin the mod's progress. The user therefore immediately sees that something is wrong, rather than thinking that everything is okay because the animation worked. Mods using the new ActRunFull interface will be able to see that their request has been denied and can act appropriately. The best way to offer Sexout a future is to not repeat the mistakes of the past.

 

I can therefore remove restrictions on secondary elements such as animations, plugins, refSurfaces... but if a CBSpell, CBpackage, or CBDialogue is invalid, I cannot ignore it and accept the request as if everything were fine.

 

 

3 hours ago, Allnarta said:

Some of dialogues I used for tests used "call fnSexoutActRunFull (Ar_Map "ActorA"::0, "ActorB"::PlayerREF)" syntax instead of "call fnSexoutActRunFull (Ar_Map "ActorA"::GetSelf, "ActorB"::PlayerREF)". 

 

Same here, I decided to stop replacing null actors with GetSelf for fear of using the wrong actor. I don't really understand the point of trying to replace “NULL” actors with GetSelf in Sexout when the calling mod could easily do it itself.

Call fnSexoutActRunFull (Ar_Map "ActorA"::GetSelf, "ActorB"::PlayerREF) ; Putting this in a 'Script Result' section in a NPC Dialogue works very well

 

 

 

 

3 hours ago, Allnarta said:

I do know that using 0 is a bad practice here, and I never use it in my actual release mods, but a lot of older Sexout mods use exactly 0 and not GetSelf (before latest update it only screwed up "raper" string so potential rapes were not treated as ones, but sex itself still worked).

 

It's not bad practice since it was initially supported. I would say it's more a good practice resulting from a bad development choice.

I don't really have a choice but to reimplement this feature, but I would prefer that mods use 'GetSelf' directly themselves in the future.

 

 

 

Regarding your video, I think my intuition was correct about the SexoutNGAM quest delay. At each stage, your tElapsed is 1 second, sometimes 2 seconds, which seems to indicate that the SexoutNGAM Quest Delay is set to 1 second.
SexoutNGAM was previously used for SexoutNG Anim Monitoring and used a Quest Delay of 1 second. In 2.11.4, SexoutNGAM has been preserved but is used for SexoutNG Anim Manager, and its Quest Delay has been set to 0.01 seconds.
I therefore carried out the following test:
- Installation of SexoutNG Beta 2.10.98 Beta 7
- Installation of WIP SexoutNG 2.11.3 Beta 5
- Loading a save file using 2.10.97
- Waiting for the update from Sexout 2.10.97 to 2.11.3 Beta 5
- Checking the Quest Delay of SexoutNGAM -> 1 second
- Saving
- Deactivating WIP SexoutNG 2.11.3 Beta 5
- Deactivating SexoutNG Beta 2.10.98 Beta 7
- Installing WIP SexoutNG 2.11.4 Beta 1 - Full Pack
- Loading backup
- Waiting for update from Sexout 2.11.3 Beta 5 to 2.11.4 Beta 1
- Checking SexoutNGAM Quest Delay -> 0.01 seconds

 

So I don't understand why you seem to have a Quest Delay of 1 second on your side.

If you can't get this iteration delay of 0.01, I can force it in a future update or change the refID of SexoutNGAM.

 

 

In conclusion:

- I will revert back to certain restrictions (such as null actors not using GetSelf, and switch to random picker when the anim/plugin/refSurface do not match together).

- I'll make sure the Quest Delay is 0.01 seconds (because I still don't understand why yours seems to be 1 second).

- Checking why refSurfaces are no longer working and fixing it.

 

 

 

 

 

 

3 hours ago, Allnarta said:

After some investigating, my conclusion is that best option for that is separate wall-related invisible static object (aka marker) to use and not actual wall static refs because:

-A lot of them can have different native transform which means anims may be wrong positioned for a lot of them).

-Adding thousands of wall static editorID's to furn list sounds very bloated.

 

That seems like the best solution to me too. Indeed It should work. 

If I understand correctly, you will need a reference to stick it to the wall where you want the animation to take place. So this reference cannot be unique cause if two animations are running and both using walls, they will not be able to share this reference.

So mods either will need to create multiple unique references or just instantiate them since the SexoutWall BaseForm (I'm not a big fan of instantiated references because if the user saves in the middle of an animation and reloads, the dynamic references will be deleted).