DoctaSax

It's quite probably more likely the xp than the enjoy system that causes that contrast between PC & NPCs in your case. The PC accrues a lot more xp than your average generic NPC, so sex just gets better for them than it is for you, which is why the enjoy system is there, to balance it out. I'll look at it more closely tomorrow.

R.I.P. thread What I've seen going on here had better not pop up in other ones either. So what if you have doubts - when last I told people to show a little more tact about all this, it meant: realize that this ain't about you, your mad detective skills or your preferred way of expressing yourselves. That's what tact means. Enough already.

Not the same job, apparently.

  Let's hope not "Oh, I see you're wearing an amulet. Let's get married, play house, and raise kids we weren't allowed to make the old-fashioned way."  

I just do               set iNVSE to ((100 * GetNVSEVersion) + (10 * GetNVSERevision) + GetNVSEBeta)             if 501 <= iNVSE                     ; good to go   and pass that var directly to the messagebox if any of the reqs don't check out, otherwise I have to break it down again

So how did your game not get shut down considering you have an older version of NG than what Spunk requires?

make sure your .nvse co-saves are where they're supposed to be

moving to sexlab tech

  Excellent idea. We could have some kind of moderator exchange program.  

I'd seriously advise against using the quest variables, using that to grab or set intel for sexout acts hasn't been done in a couple of years now. Instead, just go with the fnSexoutActorInUse UDF, which you can buildref as well and then call.   let rUDF := buildref whatever the converted formid is let HavingSex := call rUDF playerref  

  It's not the number of posts that's praised, but what was in them. A nice guy at best? If you're saying you can do better I'm not seeing it. How about a little tact, eh?

  But... but... FOSE? Personally, I never saw a need for a scanner frequency as high as 10. 1 should be enough for all your scanner needs, imo.

I like how there's no real menumode anymore. I think that'll prove to be very handy for UI modding.

A UDE is probably the best way of signalling the change, yeah. Ideally, that stringmap could be populated with the more useful intel.

Like it or not, thou shalt be educated.

It's not all that difficult. The game automatically picks idle anims for any character to play. Calling pickidle just forces that to happen. The system then traverses the entire anim hierarchy structure, checking condition functions (like you have in dialog conditions). If the actor is sitting on furniture, that's picked up by a condition, so a 'sitting' anim will play. If nothing in particular is going on, the system will check all conditions and eventually settle on one of the generic 'just standing around breathing' anims under "GeneralIdles". It'll never automatically go below that. When an anim mod adds an anim it usually does that at the top of the hierarchy, with a new condition, expecting that anim to be the first to be picked when the condition returns true. The problem is that A) often a vanilla anim is flagged as changed that wasn't, one of those many geckities that create a wild edit. Another anim mod doing the same will run into problems because of that, hence the advice to remove KnockDownIdles from the groovatron, which is a wild edit. B ) you can never entirely guarantee that your anim will be picked if other anim mods with a similar method could also be returning true on their conditions. Even without wild edits, when the various anim structures are merged on game load, who knows who 'really' is at the top. C) for a huge system like NG having conditions on all the anims is a pain, even more so before NX_GetQVEVFL made it possible to use nx vars in conditions, because then that meant adding x amount of tokens to an actor, with x being the anim number. So in the earlier days, NG could easily dump over 5000 tokens in an actor's inventory for 3P anims, for instance. Tokens can get stuck, and people can grab them from dead actors' inventories with "take all" too, leading to more weirdness. If there are many, GetItemCount also not always reliably counts them in one go in a script. None of that is actually needed. Switching to playidle means you can park all your new anims underneath "generalidles" where they'll never be picked automatically, shouldn't cause conflicts with other mods no matter what system they happen to use, and where you call them directly with playidle by specifying the idle's editorID. Part of the prep work pride did for switching to playidle was renaming some idles' editorIDs so they're all named the same. With string variables becoming available, those can be constructed dynamically: you just create the string based on the anim number and the A/B/C of the actor like let idlestring := "SNG" + $anim + "b" & call it like: playidle $idlestring That playidle takes the editorID string as parameter at all is incredibly weird, but a huge windfall for NG.

Apart from those issues sounding a bit contradictory, I'd also need logs with both spunk and lust's debugmode on to even confirm your issue happens, let alone why. For one thing, I do not know whether the NPCs are even supposed to do anything because I don't know their lust value. I believe there's also some randomness to the whole approach thing, and that NPCs don't have their lust value calculated if they're not around the player.

Since everybody seems to be in agreement this was sort of a self-inclicted thing, maybe there's not much point discussing it further. Nexus and loli mods in the same thread - those who've been around long enough know that it's only a matter of time before we have to close this down anyway.

I think there's also an issue with crashing when picking a custom hair and then custom eyes, which should be the other way around. Or vice versa, can't remember.

Bah, people make private mods all the time. You merge a couple of clothing mods into a compilation of your own, for instance. Pick & choose from a variety of body mods in a beauty comp of your own. Things like that. You can download mods that only change a single game setting, so why would you have those individually in your game: merge that shit. Of course they're private... not enough reason for me to want to release my own compilations, be responsible for them, deal with people reporting bugs that can't possibly be mine, let alone going through the trouble of obtaining permissions for using the assets. Then there's stuff you're simply still working on, wouldn't want people to bug you with 'suggestions' and what not. Or stuff you just make for yourself using things you're not allowed to re-release. All of them very valid reasons to keep it private. Of course you have a certain subset of downloaders who get so upset that there's stuff out there they just can't have, that they make a big stink out of that, making it out to be an anti-social decision, so they feel justified in nagging about it.

  Not completely. As you say, the dripping one would/should disappear once the shader's own duration times out, but I need to track time anyway to replace a dripping one with a permanent one. Because I'm already starting the perm one, I stop the dripping one, just to be sure.   Mind you, this miscalculation I found probably doesn't explain the flashing, and I need to correct myself in saying the only thing changed was the timing var. I added something at the end of SpunkQuShaderTracking:   elseif 0 == rActor.HasEffectShader rShader     DebugPrint "SpunkQuShaderTracking: playing %i on %n, %i" rShader rActor rActor     rActor.pms rShader   Like many things around shaders are mystic juju, HasEffectShader sometimes returns true when there's a shader playing as it should, sometimes not. So I stopped relying on it making sure one is playing for one thing, but didn't wonder if checking if one wasn't playing for another would produce similar results. There's a chance that's what causes your flashing: the shader being reapplied when it doesn't need to be. Try commenting that part out, see what gives. I'm neck deep in overhauling other systems now, making it so that new anims being added to NG no longer requires spunk updates.  

  The only thing the last update changed about the shaders is switching the drip timeout in the script from a fixed duration to a variable one that can be set in MCM.  I encountered a flaw in the handling of that, which seems to have been around since I switched from monitoring that timeout in spells to doing it in a quest, so that's a few versions at least. In spells you can simply add up the seconds passed since the spell was cast with scripteffectelapsedseconds, but in continuous quests you need to apply a bit more math to convert between time articulated in 'real seconds' and articulated in 'game days passed', which his how I store the time of ejaculation.   Time passed expressed in GDP between 'now' and ejaculation is: GameDaysPassed - ar_shader["Left"] (because under "Left" is the moment of ejaculation in GDP)   1 real day = TimeScale * 1 GDP or: 1 real day expressed in GDP = TimeScale so: 1 real second expressed in GDP = TimeScale / (24 * 60 * 60) = TimeScale / 86400   so how I originally expressed 35 real seconds as 7 * TimeScale / 14400... I can't explain because it should obviously be 35 * TimeScale / 86400 or 7 * TimeScale / 17280   Fuckin' math. I probably got confused adapting some formula from semen or sperm tracking, which are really meant to express time in terms of 5-second intervals passed rather than single seconds.   So converting that flawed fixed duration formula to a variable one was bound to make it equally flawed, except I added some more of that by doing this: SpunkVARZ.iShaderSecs * TimeScale / 72000 instead of SpunkVARZ.iShaderSecs * TimeScale / (14400 / 7) or 7 * SpunkVARZ.iShaderSecs * TimeScale / 14400   but of course should've done SpunkVARZ.iShaderSecs * TimeScale / 86400 all along !   At least, I think so...

Here goes another one.

So far.

Yes, don't merge mods that have MCM menus, or are referred to by other mods with the buildref and IsModLoaded functions. That means mods like spunk, pregnancy etc.