Jump to content

Recommended Posts

10 hours ago, Lord_Bob said:

Yea I dont think they fixed it because I can't play any animations after I play one once. Not only that but the mcm spunk menus options are mixed up like the options are missing or the text is inside another options name (that probably didnt make sense)

Seems be a common issue right now. Hopefully it gets fixed soon. The Frontier needs new xNVSE.

Link to comment
16 hours ago, SongOfTheSparrow said:

Seems be a common issue right now. Hopefully it gets fixed soon. The Frontier needs new xNVSE.

I'm sure they'll figure it out soon. Over on discord, some people are reporting with 6.0.2 they're even getting crashes from JIP, I've not had that issue but do know any mod with extensive array use, especially those used as complex structs -  gets screwed - and not in a sexout way. ;)

 

I've a question off the topic. Does anyone know of a utility for NV akin to something like https://www.nexusmods.com/skyrim/mods/52363/ ... I'd been playing Skyrim and SSE for years as you may guess. 

 

 

Link to comment
20 hours ago, eflat0 said:

This however the newer style calls did not work at all and I'm thinking must be the parameters (they're passed as an array struct of order pairs. )

Was this call done in a dialog result script too? Because declaring vars in a result script is generally not encouraged.

Link to comment

ok, I'm still trying to narrow the scope when it comes to sexout not doing more than a single act as well so I'd appreciate it if any further logs also have sexout's own debugmode enabled

 

The error code 1 returned by fnSexoutActRunFull, along with a post in the NG thread mentioning a console print about ugrids, makes me think this causes the act to abort:

   

 if 0 == (GetInGrid actor, -1)
    PrintD "SexoutActRunFull: Aborting, "+$actor+" is not the the uGrid!"
                let Abort := 1
                break

which would really only happen if either the actor is not in the vicinity of the player, or the GetInGrid function has become borked. I did, however, not see the actual console print, so there's a chance that something about the earlier validity checks, or even the way in which they loop through "ABCX" could be messed up instead.

 

I was also surprised to see in one of your previous logs that the ongoing acts were indexed at [10] and [11] in Spunk's tracked acts array. This is simply a multitier containing arrays of actors per ongoing act, so something might be off about erasing them when done. Would be quite the orgy otherwise.?

 

 

 

Link to comment
5 hours ago, DoctaSax said:

ok, I'm still trying to narrow the scope when it comes to sexout not doing more than a single act as well so I'd appreciate it if any further logs also have sexout's own debugmode enabled

 

The error code 1 returned by fnSexoutActRunFull, along with a post in the NG thread mentioning a console print about ugrids, makes me think this causes the act to abort:

   


 if 0 == (GetInGrid actor, -1)
    PrintD "SexoutActRunFull: Aborting, "+$actor+" is not the the uGrid!"
                let Abort := 1
                break

which would really only happen if either the actor is not in the vicinity of the player, or the GetInGrid function has become borked. I did, however, not see the actual console print, so there's a chance that something about the earlier validity checks, or even the way in which they loop through "ABCX" could be messed up instead.

 

I was also surprised to see in one of your previous logs that the ongoing acts were indexed at [10] and [11] in Spunk's tracked acts array. This is simply a multitier containing arrays of actors per ongoing act, so something might be off about erasing them when done. Would be quite the orgy otherwise.?

 

 

 

 

Looks like you're on the money. My log shows the same ugrid error. Latest xNVSE.

slinval.txt

Link to comment
On 1/16/2021 at 3:02 PM, DoctaSax said:

ok, I'm still trying to narrow the scope when it comes to sexout not doing more than a single act as well so I'd appreciate it if any further logs also have sexout's own debugmode enabled

 

The error code 1 returned by fnSexoutActRunFull, along with a post in the NG thread mentioning a console print about ugrids, makes me think this causes the act to abort:

   



















 if 0 == (GetInGrid actor, -1)
    PrintD "SexoutActRunFull: Aborting, "+$actor+" is not the the uGrid!"
                let Abort := 1
                break

which would really only happen if either the actor is not in the vicinity of the player, or the GetInGrid function has become borked. I did, however, not see the actual console print, so there's a chance that something about the earlier validity checks, or even the way in which they loop through "ABCX" could be messed up instead.

 

I was also surprised to see in one of your previous logs that the ongoing acts were indexed at [10] and [11] in Spunk's tracked acts array. This is simply a multitier containing arrays of actors per ongoing act, so something might be off about erasing them when done. Would be quite the orgy otherwise.?

 

 

 

 

Sorry it's taken so long to reply, been quite busy, but you're in the ball-park... would be nice if  actorA and actorB were.  

 

Let's see here, that ole dude in Sloan seems pretty happy lately with the bugs... though Hanna is confused as hell... confused myself even was looking all over for the dump before I realized I was in the SSE folder. 

 

To clarify the ddl env there's the FNV diagnostic. Although NVSE for some reason has a ton of unknown messages and Vortex reports none of those ddl's loaded on the previous run when I went back to it just after running 6.0.2. Just strange.

 

and of course: 

 

The steps: 

 

Used soliciting, 

1. Solicited old dude in Sloan barracks

2. States meet him at the mechanic's shed.

3. Go to Mechanic shed provide trick

4. Old dude stiffs on payment - that's because usually they stand there and force greet back giving payment but he took off down the road? 

   a.) can see soliciting script attempting to run the payment script over and over.... ex. 1

5. So, attempt to solicit the other dude who happened to be in the mechanic shed when Hanna and the old guy arrived.

6. He agrees but of course .... Hanna's not even in the  uGrid according to it. (Yet she's standing right in front of the guy she's solicited and I'm scratching my head wondering why it's checking for Hanna?)

 

ex. 1

SexoutActRunFull: Aborting, Hanna Rose is not the the uGrid!
SexoutActRunFull: Aborting, actor is invalid, code: 1
Sol: Start Trick (END1): Type: 3 Anim: 0 Town: 11  Rape: 0 Partner: Quarry Worker
** Dumping Array #1039 **
Refs: 1 Owner 0F: SexoutSoliciting.esm
[ ActorA ] : Quarry Worker (000E7624)
[ ActorB ] : Hanna Rose (00000014)
[ CBDialogA ] : zSolicitingSloanPAY (0F0010BE)
[ flags ] : (Array ID #1098)
** Dumping Array #1098 **
Refs: 2 Owner 0F: SexoutSoliciting.esm
[ 0.000000 ] : oral

 

ex. 2

SexoutActRunFull: Aborting, Hanna Rose is not the the uGrid!
SexoutActRunFull: Aborting, actor is invalid, code: 1

 

So. Is it that somehow the PC is not on the uGrid same set of cells? I'm wondering how far she'd have to run to be on a different grid of cells, then walk back to the same grid and if they'd show up on it? But, should we be checking Hanna, I thought we'd be checking the NPC? Seems to me we're off by an index, The GetInGrid function takes the npc not the pc as the reference, or I thought so? The error should say: "SexoutActRunFull: Aborting, Quarry Worker is not the the uGrid!" What is sexout using to set the value of actor?  SongOfSparrow has the same error and it too is listing the name of the PC reference and not the NPC as the reference being checked.  That should be  [0] Quarry Worker not [1] Hanna Rose, correct?

 

 

Oh yes, also Spunk keeps attempting to evaluate it's perks, even though enjoy and xp are not even on, although I do not know if that's normal? Seems to have issues there.

 

 

image.png.f5e6f783c5a620db5350064164779fe5.png

 

 

nvse_extender.log DebugSoSpunkLog.txt

Link to comment
4 hours ago, eflat0 said:

Sorry it's taken so long to reply, been quite busy, but you're in the ball-park... would be nice if  actorA and actorB were.

 

Thanks. Something still seems off about erasing elements from arrays - in that last debug log there seems to be an act going on between a quarry worker and your character. The act is identified as #12, again a far too high number for normal use. When Spunk clears up some stuff at the end of the act, it finds your PC in act #10, with 'NCR recruit' instead of quarry worker as the pc's current partner. So it attempts to clear that act from the ar_trackedacts array instead of the one that just finished. This throws a variety of things that Spunk does out of whack. Was this made on a save where previous testing with xNVSE 6.0 or 6.0.1 was done?

 

I'm also seeing rather high IDs assigned to some arrays, eg somewhere in the 10-11k range, which is fairly unusual. It might mean there's something off about the recycling of these IDs that NVSE used to do. But these are older elements in a multi-tier structure where newer elements do show some lower IDs too, so I could be wrong about that.

 

Re: the GetInGrid issue: fnSexoutActRunFull runs it against all actors involved in the act, checking that way if they're in the vicinity of the player. Presumably the player is in the vicinity of the player, at least they used to be before the update. ?

 

Toggling off the enjoyment system via the "Stats" sub in MCM should've completely cleared that system and also toggled off the perk system, clearing that up and stopping the quest that manages the related perks. Strange that it shouldn't take, perhaps toggle it on & off again, leaving some seconds in between?

 

@SongOfTheSparrow: your log shows a foreach loop completely failing in SpunkFuRacesDetect. The only thing I can attribute that to is that the stringmap being looped through just had some elements erased from it with slice notation. I previously reported a bug about erasing with slice notation from a numeric map to them, so this might be related, or a result of the fix for that.

EDIT: was this with 6.0.2 though? The log doesn't say.

Link to comment
27 minutes ago, DoctaSax said:

 

Thanks. Something still seems off about erasing elements from arrays - in that last debug log there seems to be an act going on between a quarry worker and your character. The act is identified as #12, again a far too high number for normal use. When Spunk clears up some stuff at the end of the act, it finds your PC in act #10, with 'NCR recruit' instead of quarry worker as the pc's current partner. So it attempts to clear that act from the ar_trackedacts array instead of the one that just finished. This throws a variety of things that Spunk does out of whack. Was this made on a save where previous testing with xNVSE 6.0 or 6.0.1 was done?

 

I'm also seeing rather high IDs assigned to some arrays, eg somewhere in the 10-11k range, which is fairly unusual. It might mean there's something off about the recycling of these IDs that NVSE used to do. But these are older elements in a multi-tier structure where newer elements do show some lower IDs too, so I could be wrong about that.

 

Re: the GetInGrid issue: fnSexoutActRunFull runs it against all actors involved in the act, checking that way if they're in the vicinity of the player. Presumably the player is in the vicinity of the player, at least they used to be before the update. ?

 

Toggling off the enjoyment system via the "Stats" sub in MCM should've completely cleared that system and also toggled off the perk system, clearing that up and stopping the quest that manages the related perks. Strange that it shouldn't take, perhaps toggle it on & off again, leaving some seconds in between?

 

@SongOfTheSparrow: your log shows a foreach loop completely failing in SpunkFuRacesDetect. The only thing I can attribute that to is that the stringmap being looped through just had some elements erased from it with slice notation. I previously reported a bug about erasing with slice notation from a numeric map to them, so this might be related, or a result of the fix for that.

 

That's occurs even in old xNVSE. It's otherwise pretty harmless, just an eyesore. Think it has something to do with my character and partner being a custom race or something?

Link to comment
5 minutes ago, SongOfTheSparrow said:

That's occurs even in old xNVSE. It's otherwise pretty harmless, just an eyesore. Think it has something to do with my character and partner being a custom race or something?

 

Hm. Odd, never seen that in all these years. It shouldn't have anything to do with your actual race though. It just tries to loop through a stringmap that's populated when you first install Spunk.

Link to comment
5 hours ago, DoctaSax said:

 

Hm. Odd, never seen that in all these years. It shouldn't have anything to do with your actual race though. It just tries to loop through a stringmap that's populated when you first install Spunk.

Well, I went ahead and redownloaded the files and installed them anew to make sure it wasn't good ole file corruption and those foreach errors went away. Sorry to deviate the conversation like that.

 

And yes that log was newest xNVSE though but I still need to retest now that I got that spunk foreach cleared up. But I'm certain I'll still hit the same ugrid error.

 

Spoke too soon. I'm sure it's just something off in my modlist or gamesave. I'll look into it.

 

Edit:

 

Got that solved. SpunkFu race detect went away when I uninstalled spunk completely (using the MCM option) and reinstalled it, nothing else really worked for that.

 

However, I noticed I'd still get a lot of errors in the add custom race submenu. So I tried a new save with a minimal testing modlist (just what sexout requires, NVAC and NVTF) and was still able to record many errors when you try adding custom races to a race cat. I'll be adding that log here since this one I'm not sure if it's on my end or something.

 

Edit 2: I actually fixed my spunkfu error by turning on cum tracking. I normally turn everything off except for lust tracking as it's all I really use spunk for.

 

test9.txt

Link to comment
4 hours ago, DoctaSax said:

 

Thanks. Something still seems off about erasing elements from arrays - in that last debug log there seems to be an act going on between a quarry worker and your character. The act is identified as #12, again a far too high number for normal use. When Spunk clears up some stuff at the end of the act, it finds your PC in act #10, with 'NCR recruit' instead of quarry worker as the pc's current partner. So it attempts to clear that act from the ar_trackedacts array instead of the one that just finished. This throws a variety of things that Spunk does out of whack. Was this made on a save where previous testing with xNVSE 6.0 or 6.0.1 was done?

 

I'm also seeing rather high IDs assigned to some arrays, eg somewhere in the 10-11k range, which is fairly unusual. It might mean there's something off about the recycling of these IDs that NVSE used to do. But these are older elements in a multi-tier structure where newer elements do show some lower IDs too, so I could be wrong about that.

 

Re: the GetInGrid issue: fnSexoutActRunFull runs it against all actors involved in the act, checking that way if they're in the vicinity of the player. Presumably the player is in the vicinity of the player, at least they used to be before the update. ?

 

Toggling off the enjoyment system via the "Stats" sub in MCM should've completely cleared that system and also toggled off the perk system, clearing that up and stopping the quest that manages the related perks. Strange that it shouldn't take, perhaps toggle it on & off again, leaving some seconds in between?

 

@SongOfTheSparrow: your log shows a foreach loop completely failing in SpunkFuRacesDetect. The only thing I can attribute that to is that the stringmap being looped through just had some elements erased from it with slice notation. I previously reported a bug about erasing with slice notation from a numeric map to them, so this might be related, or a result of the fix for that.

EDIT: was this with 6.0.2 though? The log doesn't say.

 

Thanks. yes this is with 6.0.2 and the env as shown in the picture, No saves have been made under 6.0.0 or higher so the states upon load were from a save made under 5.1b6.  Loading from this save and initiating these same actions under 5.1b6 produce a clean log. Thanks for clearing up that both actors are checked for presence in the current grid. Still the PC it was in the grid the act took place within unless the player somehow changed - assigned another id or the grid was refreshed incorrectly during the act? So should had returned a positive, and I would think the actor which ran off would have shown negative? Unless the check is done on perspective of the NPC? 

 

In either case I believe the actor ran off due to the check failing at that point, In soliciting typically they just stand and force greet the player in order to pay them.. but does not explain why attempts to start a quest script with another npc also results in failure from that point on the player is not on the grid they should be in.  

 

 

 

  

Link to comment
5 minutes ago, eflat0 said:

Thanks for clearing up that both actors are checked for presence in the current grid. Still the PC it was in the grid the act took place within, so should had returned a positive, and I would think the actor which ran off would have shown negative? Unless the check is done on perspective of the NPC? 

 

In either case I believe the actor ran off due to the check failing at that point in soliciting typically they just stand then and force greet the player in order to pay them.. but does not explain why attempts to start a quest script with another npc also results in failure from that point on? 

 

I'm not really following the sequence of events, but really, all these scripts happen so fast it's unlikely an actor would fail the GetInGrid check at the point an act is started, which is when it's called, even if it was an NPC. I doubt everything that sexout does at the start of a scene costs even a second. Since it was the player that was checked, it doesn't even enter into it: the player should always be within the player's grid.

 

GetInGrid does function correctly when used in a separate test mod, and the same goes for Ar_HasKey which produces the Spunk error that tries to find enjoyment perks in arrays that aren't there, so something else is going on that throws sexout mods specifically out of whack on functions that we've been using without issue for years. It could be that xNVSE changes to the plugin API have affected NX somehow, a common denominator after all and the nx log does indeed contain new notifications I haven't seen before, but I don't see how that would affect non-NX NVSE functions and functionality. That's all starting to go above my head though - I've asked jaam to check out the nx angle.

Link to comment
On 1/17/2021 at 8:50 PM, DoctaSax said:

 

I'm not really following the sequence of events, but really, all these scripts happen so fast it's unlikely an actor would fail the GetInGrid check at the point an act is started, which is when it's called, even if it was an NPC. I doubt everything that sexout does at the start of a scene costs even a second. Since it was the player that was checked, it doesn't even enter into it: the player should always be within the player's grid.

 

GetInGrid does function correctly when used in a separate test mod, and the same goes for Ar_HasKey which produces the Spunk error that tries to find enjoyment perks in arrays that aren't there, so something else is going on that throws sexout mods specifically out of whack on functions that we've been using without issue for years. It could be that xNVSE changes to the plugin API have affected NX somehow, a common denominator after all and the nx log does indeed contain new notifications I haven't seen before, but I don't see how that would affect non-NX NVSE functions and functionality. That's all starting to go above my head though - I've asked jaam to check out the nx angle.

The symptom is the initial GetInGrid on the player works, because the first sexout calls work, but after that act ends then any subsequent GetInGrid fails. 

Link to comment
On 1/14/2021 at 12:31 PM, Lord_Bob said:

Ok so you don't have any problems like not being able to do scenes after you just do one? and you don't get script errors in the console?

That's not an issue with this mod but sexout in general. 

There's a fix in this thread, but sadly it didn't help me personally.

Link to comment
16 minutes ago, Omegabrony01 said:

There's a fix in this thread, but sadly it didn't help me personally.

 

I think the bug there led to Odessa adding the GetInGrid failsafe check at the time, which is now stopping the act from starting via the later SexoutActRunFull UDF. Her guess at the root cause of that - an actor becoming null due to changing cell causing the SexoutNGEffectBaseScriptF spell script to either hang or abort early - is still bizarre to begin with given the timing of the sequences. And for such a rare bug to suddenly pop up consistently after switching to xNVSE 6 even more so.

 

Might be worth a try for a few others to test the dispel solution before starting a second act, but a lot of the code in the start spell was transferred to that UDF anyway, so it's unlikely to help entirely. Combined with the varied issues I have in Spunk, with array functions like ar_haskey or ar_erase, there's just more going on.

Link to comment
19 hours ago, DoctaSax said:

 

I think the bug there led to Odessa adding the GetInGrid failsafe check at the time, which is now stopping the act from starting via the later SexoutActRunFull UDF. Her guess at the root cause of that - an actor becoming null due to changing cell causing the SexoutNGEffectBaseScriptF spell script to either hang or abort early - is still bizarre to begin with given the timing of the sequences. And for such a rare bug to suddenly pop up consistently after switching to xNVSE 6 even more so.

 

Might be worth a try for a few others to test the dispel solution before starting a second act, but a lot of the code in the start spell was transferred to that UDF anyway, so it's unlikely to help entirely. Combined with the varied issues I have in Spunk, with array functions like ar_haskey or ar_erase, there's just more going on.

Well we knew the value the reference pointed to must had changed. After all it worked the first time. So must have been changing somehow and somewhere between. Thing is however in my mind the pointer to the player should literally never change - especially to a null. First thought in my mind as if it had to do with disabling control?

 

All the same in NVSE this class looks wrong to me... Looks like it will return false on a good reference at times, but what do I know I've been in code all day long so it all seems wrong.  :/ All the same I need to get back to work on a DB package. 

 

class RefMatcherARefr
{
    bool m_includeTaken;
    TESObjectREFR* m_refr;
public:
    RefMatcherARefr(bool includeTaken, TESObjectREFR* refr) : m_includeTaken(includeTaken), m_refr(refr)
        { }

    bool Accept(const TESObjectREFR* refr)
    {
        if (!m_includeTaken && refr->IsTaken())
            return false;

        else if (refr == m_refr)
            return true;
        else
            return false;
    }
};

 

Link to comment
On 1/22/2021 at 10:46 PM, eflat0 said:

I'll have to try out the new xnvse tommorow.  Anyone else try this revision yet?

 

6.0.3

Fix string bloat issue that haunted some mods
Fix cosave not saving mod index for strings
Fix GetInGrid for some mods
Fix some string formatting issues
 

      I'm currently using 6.0.3 and still experiencing the mcm menu glitches. Works fine the first time on a new game but then gets progressively worse, also using the phud arousal meter color assignments don't really work, it's hit and miss. I haven't had any issues or crashes with spunk other than the visual glitches in the MCM menus

Link to comment
On 1/26/2021 at 4:40 PM, Lord_Bob said:

6.0.3 fixed it but I have a bug that whenever I finish an animation the jizz on an npc just disappears. Idk if it has to do with some mcm setting I dont think it is because I haven't tweaked anything other then the amount of jizz lol. 

I still have not had a chance to test it out, been too busy. I'm actually amazed I traced back the GetInGrid problem back and was in the ballpark on what class was logically wonky. My suspicions are with jizz disappearing and of course all the other people with menu issues that it's all centered on arrays.

Link to comment
6 hours ago, leo291 said:

Guys how do i disable the "Spunk's up" message on load ? i mean the top left corner message.

I don't think you can, You have to ask DoctaSax. Is there a way to disable all messages? I don't know scripting well but the message is displayed in the initialization quest/script  at iStage >= 50 , basically if spunk makes it through initializing and now available (running) you get the message it's up. One thing I will say is DoctaSax writes eloquent code. 

    
    

Link to comment

Hi! I don't know if anybody else did mention the same problem, but I do just in case: The perk Insatiable say prerequisite that do you need is Endurance 3 but only you can take it with Endurance 5. I hope don't repeat something that other user pointed in past replies.

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