SexoutNG - Beta (2.10.93b10) release thread

[BruceWayne]

 

 

As for the eventual inclusion of pregnancy related items: For the SexoutWillow mod I need to have an exclusion formlist which has the diaphragm in it. The way the original Willow mod handles item removal for the striptease before the sex scene, caused freezes in conjunction with pregnancy, if that particular item was to be removed. Since it is only one item I guess I could do a workaround with getismodloaded and buildref, but that would kind of defeat the purpose of that little, one script altering, override mod.

 

Hmm this is the first I've heard or can recall about this issue with the Diaphram and Willow, if I understand it properly it should just be a matter of adding the diaphram to the SexoutClothesSafe for Sex lists, which now my memory has been prodded, I not sure I've done.

 

 

http://www.loverslab.com/topic/9494-sexoutwillow/page-3?do=findComment&comment=240902 and the following posts. It has been quite a while.

 

The willow sex scene removes all of her items by default before the sex scene starts, which caused the problems. After excluding the diaphragm, the crashes stopped.

[prideslayer]

Individual mods should be adding things to the Sexout safe for sex lists, not the SCR ones -- or, at least, to both. I know SCR adds everything in its lists to sexout when it starts up, but it doesn't know if a mod adds something to it's list later. If it only gets added to the SCR list, it won't have any effect on sexout.

1. sexout starts, safe for sex list empty.

2. scr starts, adds items from it's safe-for-sex lists to sexouts lists

3. othermod starts up, adds something to the scr list from step 2.

4. sex starts with character wearing item from step 3. sexout does not know this item is safe for sex, because it was only added to SCRs list -- after SCR pushed that list to sexout.

IMHO, when it comes to all those lists in SCR that are used to populate the sexout safe-for-sex lists, they should only be filled in the GECK.

 

Other mods should be adding their items to the sexout list, and whatever scr 'appearance' lists and so on that mod author thinks are appropriate.

[BruceWayne]

That wasn't the problem here. The items, including those on the safe list were removed by the original mod (independently from mine and sexout) for her to do a little strip dance. After the dancing is concluded, the fade to black scene starts (this is where I come in) and after that is done, all the items are moved back to her inventory, which caused the game to crash. All I did was changing the removetypeditems command to factor in a private list that only includes the diaphragm, which was the cause of the crash. This also happened with the main mod, even without SOWillow, if you gave her that item.

[ChancellorKremlin]

Regarding the concerns raised, I want to clarify some things in a more general way, and if that leaves specifics unanswered, then we can address those.

 

2. Unscripted armor items. Sextoys, clothing, armor, etc. Unenchanted, unscripted, and only if the model and texture are included as well. The pregnant and ripped versions do not need to be in SCR itself I don't think.

 

Is SSR aiming at removing the clothing and clothing replacer aspects of SCR? Because as DS said above, clothing is one of the big things other mods use SCR for, and as far as common resources go, I agree that SCR is the best place to have it.

Yes. The clothing itself can be in SSR if it needs to be for some reason, but the actual swapping needs to be handled by a standalone mod responsible for that. Pregnancy should be swapping pregnant bodies itself, not relying on SCR to do it. A 'damaged clothes' mod likewise should probably be doing it's swapping itself.

 

Well, the reason I'm asking is because I do like SCR's function as a repository of certain clothing items (not all necessarily pregnant related) like say the merc courier, or some of Jonas_Opines sexy clothing, tomb raider, nidia, among a list of other stuff that can be found in SCR's exhaustive clothing requirement mods. These can be accessed easily through Zippy's SexoutStore (which doesn't hold any of the items itself) and I use both SCR and store to basically get those outfits without having to have a ton of different esp's activated to find them randomly scattered throughout the wastes.

 

So I just wanted to know if SSR will maintain such apparel or if it intends to purge it?

[DoctaSax]

First, there is no need or requirement for any other mod to switch to SSR. SCR can live on, doing whatever it likes to do, with Hal in the drivers seat, and mods can continue to use it.

If SSR means to be the clean, lean replacement of SCR & Hal speaks of moving stuff from old SCR out to different plugins, then it does sound like most of us are gonna have to make the switch to SSR, eventually. Just the way I think it'll play out. Which is fine by me; I wanna be with it.

 

So with the origins of SSR in mind, there are some specific things I want to avoid, if it is to live on.

I can agree with everything you list there.

 

I'll stop now.. before the hulkrage overtakes me again.. So, the question remains, what belongs there?

1. A bunch of non-filled lists should be the minimum a library mod can find space for. The ones I mentioned (SLCLothAppear+) are used in four mods. Let's assume they have their uses, or I'll feel bad for having my entire output so far depend on them

 

2. Unscripted armor: a selection of T3 outfits - raw, unscripted, etc - isn't out of place since we're still suggesting T3 as the standard nude body. Agreed, not everybody uses everything - whether as a modder or a player - but I can say the same for those tentacle strapons you keep around. There's a balance there between need to have and nice to have. Doesn't really matter to my mods though. Just think it's nice to have something of a comp, and avoid an extra 'clothing resources' esm or something.

 

If you want to axe all swapping, and the preg and torn outfits themselves, I can work around that if you add 2 formlists (for tearable & torn) that Hal could fill, and a quest var as notification that the functionality's on. I can disable that part of those 2 scenes until it's all set up again pretty easily.

 

3. Consolidating all quest variables in one quest: Meh. For the lust vars, that's a lot of result scripts I'd have to go in and change just so you don't have to keep 2 quest variables (player lust & doc m lust) where they already are, having next to no impact on anyone's game. I don't need all those other vars, although SOSoundReplacer may need the player's fArousal var. Keeping them as is may not be as perfectly tidy as you like but throw me a bone here - it's only been two weeks since I managed to permanently sidestep lust's npc approaches.

[iron_jack]

Completely unrelated to all of the above, but I recall trying to do something during your absence, Pride, when I noticed getSelf and such don't work with your NX calls.

 

As in,

getself.NX_SetEVFl "Sexout:Start::CallVer" 1
getself.NX_SetEVFo "Sexout:Start::ActorA" getself
getself.NX_SetEVFo "Sexout:Start::ActorB" player
getself.CIOS SexoutBegin

Doesn't work.

 

I'm sure you already knew that, but it makes things a bit awkward when trying to use dialog result scripts that don't pertain to just one NPC.

 

 

 

edit: I remember, I was trying to NXify the Tryout plugins. Your NX stuff only accepts actual object references, not functions like getself. That's what it was. I also tried defining a variable, then setting that variable to the value of getself within the dialog result script itself, then using your NX system with that variable... but if I recall, that didn't really work either. I think the set variable to getself didn't crank through in time to beat the rest of the result script and ended up borking the whole thing.

 

Kinda fuzzy on the details. If it sounds like I'm talking nonsense, I'll take another look at it so I can give a less hurrdurr description. It's not really a "problem" probably, but it does make things more complicated.

[BruceWayne]

Completely unrelated to all of the above, but I recall trying to do something during your absence, Pride, when I noticed getSelf and such don't work with your NX calls.

 

As in,

getself.NX_SetEVFl "Sexout:Start::CallVer" 1
getself.NX_SetEVFo "Sexout:Start::ActorA" getself
getself.NX_SetEVFo "Sexout:Start::ActorB" player
getself.CIOS SexoutBegin

Doesn't work.

 

I'm sure you already knew that, but it makes things a bit awkward when trying to use dialog result scripts that don't pertain to just one NPC.

 

 

 

edit: I remember, I was trying to NXify the Tryout plugins. Your NX stuff only accepts actual object references, not functions like getself. That's what it was. I also tried defining a variable, then setting that variable to the value of getself within the dialog result script itself, then using your NX system with that variable... but if I recall, that didn't really work either. I think the set variable to getself didn't crank through in time to beat the rest of the result script and ended up borking the whole thing.

 

Kinda fuzzy on the details. If it sounds like I'm talking nonsense, I'll take another look at it so I can give a less hurrdurr description. It's not really a "problem" probably, but it does make things more complicated.

 

 

In that case you could do something like:

 

 
ref somebody
int do
 
if do==0
 set somebody to getself
 set do to 1
endif

somebody.NX_SetEVFl "Sexout:Start::CallVer" 1
somebody.NX_SetEVFo "Sexout:Start::ActorA" somebody
somebody.NX_SetEVFo "Sexout:Start::ActorB" player
somebody.CIOS SexoutBegin
 

[prideslayer]

Lists

SSR can hold the clothing items, even the torn and pregnant versions, and the lists. What we need it seems is yet another list, ItemsThatExist. It would start off with all the vanilla armors, clothes, and other 'things' that you could have in your inventory. Pregnancy would add all its own pregnant meshes to that list, and any other lists that are appropriate for them, like the sexout safe-for-sex lists. Any items that "exist" in SSR, but actually aren't playable because the user might not have the meshes/textures, will not by default go into the ItemsThatExist list.

 

We would need new standalone ESPs for those add-ons, that isntead of adding those armors to some random chest in the middle of the wilderness, add them to the proper lists in SSR, including ItemsThatExist.

 

Mods for dialog would still only have to check what the character is wearing vs. what is in the Sexy or Slutty or whatever list(s). The store would check whatever lists it already checks to fill out inventory, plus the ItemsThatExist list, before adding those items to its inventory on startup.

 

What I'm trying to avoid there is having items in SSR that appear functional, but aren't unless you have some random obscure 3rd party clothing mod installed, from being actively *used* in mods, npcs, etc. This problem has already surfaced at least once with that NPC companion Hal was working on that is unfinished but in SCR, and the world, right now. I do not know what clothes she's supposed to be wearing, but I don't have it installed, so in westside there is an NPC that's just a floating head and a chastity belt. There might have been boots/shoes too, I don't remember.

 

Other people, especially those new to modding for sexout, are not going to know that there are armor and other items in the mod that they *can't actually use* without making that clothing/item mod a requirement for their mod.

 

The appearance lists are 'meh' to me. I find it questionable that any mod author knows what clothing mods I have installed myself, or what I find sexy, so I'm against them being prefilled with anything, but they can stay. The vanilla leather armor is not sexy or whorish. The Bouncing Type3 replacement for it, I find sexy but not whorish. The BNB replacement I find whorish, and not sexy.

 

Other opinions differ. Do you see my concern? Which list(s) does it belong in, by default? I'm more than willing to have the lists stay in SSR, and would accept prepopulating them with what I believe obsidian thought each one should be, but addon armors need added to the list via SCES, a standalone esp, or... something. Hell if you like them perfectly the way they are in SCR -- copy them to your own mod, and it's a simple task to loop through each one and copy its contents to the same list in SSR at runtime. I would just make it clear to your players that this is what you're doing.

 

body

I would consider T6M the standard body, not T3. Not because more people have it installed or it's more popular, but because it's the body that ships built in to sexout. That said, I don't really want to include any armor or clothing *replacements* in SSR. At least, if they are there, they need to be in a BSA, not as loose files. I will include replacements in a BSA so long as we have permission to redistribute the files, and they are T6M so they 'match' with the default nude included.

 

If you're talking about new armors, not vanilla replacements, I'm not sure it matters which ones are included or not or what their body type is. If I'm missing something here, enlighten me!

 

swapping

I am not "axing" swapping, I'm axing SSR *doing* the swapping, at least until we come up with a better system to do it that doesn't cause conflicts among mods, and is easy to extend. The torn and pregnant swapping lives in its own little universe right now, and will not play nice with any other mod that adds similar functionality, because it's all hand coded, and hard coded, to only know about torn meshes, pregnant meshes, and combinations of those two where they've been made. If somebody wants to add 'dirty' variations and a laundrymat mod, unless hal codes for that in the existin SCR and puts all *that* support scaffolding in as well, it will never play nice with pregnancy/tearing.

 

So what I'm in favor of to handle that from SSRs perspective is a way for mods to register with it and say "Hey, I do armor swapping!" Then perhaps an MCM setting that just lets you pick which *one* of those swapping mods you want to be 'active'. Hal could carry over the existing functionality from SCR to handle what's already there, and others could write their own to replace or extend. At least until we figure out a way (likely through new NX functions to combine textures) to combine an arbitrary number of such effects at runtime.

 

quest vars

Set SomeQuest.nDocMLust to 3.4 is a lot less desireable than DocMRef.NX_SetEVFl "lust" 3.4 for several reasons. I'll leave them in if you promise to switch to NX as soon as you can, provided they are in one of the normal SCR quests and not the SomeNpcNameHereQV ones. I can't keep those ones around. Doing so just opens a door for more people writing mods to start using them, without knowing that they are deprecated.

 

Once more...

I am not asking anyone to switch to SSR. I'm not suggesting that they do. I'm not even volunteering to keep it maintained or up to date, not yet anyway, though I'm being volunteered for that and will do what must be done. I'm simply asking people to beta-test SSR as it stands now and make sure that the mods I've uploaded that *have* been switched to use it continue work fine standalone *and* with SCR and SCR-mods loaded alongside.

 

SOME things will "break" from a players perspective, I'm sure. There are no pregnant versions of the outfits (NCR prostitution, PG slave, Marissa, etc) in SSR, so if somebody wearing one gets pregnant, they will have to deal with whatever those consequences are. That is, if there *were* pregnant versions in SCR to begin with. Again, I did not look.

 

If there are any other 'whoring' mods in the works, they *might* not play nice with workinggirl, since the iWhoreMode or whatever it's called quest variable that workinggirl sets, is now being set in an SSR quest and not an SCR quest. I don't know of any other mods that look at or care about that flag.

 

Anything that SCR or SCR mods do related to Marissa or other tryouts modified NPCs, Marissas Wrath, etc -- may behave differently. Obviously any changes to them in SCR will not affect Tryouts or Sewerslave. Tryouts are using the SSR version, and Hindlick is standalone in the uploaded sewersalve ESP (though I forgot to remove SSR as a master) -- he's a ghoul, so the head/body color issue is, I believe, not an issue.

 

Otherwise, I cannot honestly think of any reason why the two cannot coexist -- but there might be some. Hence the reason for the beta release of all of them together. SexoutSlavery is a no-brainer. That one is ready to be moved over to the real release thread. It was not modified to replace SCR with SSR, but simply to remove SCR as a master. Same will happen to sewerslave, I just forgot to do it in this upload.

 

So if switching to SSR just looks all too daunting -- don't! Just wait patiently for Hal to fix up SCR, or better, volunteer to help him. Or if you're completely satisfied with how it works now, just kick back and call me crazy.

 

But why then.. (probably a bit more ranting in here)

 

 

I was the 'unofficial' caretaker of sewerslave for a while, so I don't feel bad about taking it in the direction I feel it should go in here. Loogie is no longer maintaining Tryouts, but I have his blessing to remove SCR as a master from it, and I'm pretty sure he wanted to do the same thing himself for similar reasons. I asked Chase if I could remove it from SexoutSlavery so that sewerslave and tryouts could continue to use that as a slavery framework, and he said that would be fine as well as long as it didn't break anything pregnancy etc. related, and it doesn't.

 

These are the mods that I most like to play. I am so irritated with SCR right now that I refuse to play FNV with it loaded, or with any mods that require it. That may sound harsh, but it's the truth, and I'm working as closely with everyone, incluing Hal, as I can to help fix SCR. I'm not just throwing my hands in the air and saying "fuck it, I'm doing things my way." I'm not asking anyone else to switch to SSR, though I do hope that others will understand what I'm trying to do, why, and get on board.

 

If nobody here is interested in making the switch, or some are but don't have the time or drive to put the effort into it, that's fine. If that is the case, I will simply factor even SSR out of these mods, and ditch it entirely. This won't cause any 'issues' between SCR and SSR, and will allow myself and others who want to play without the 'bloat' SCR currently has, or the effects it has on gameplay.

 

 

[prideslayer]

Yeah, but that's the same with everything, not just NX. You can't call any NVSE function with 'getself' as a parameter, or any other function as a parameter. The engine is just too stupid to understan what you mean.

 

What Bruce said is more or less right, here:

 

 
ref somebody
int do
 
if do==0
 set somebody to getself
 set do to 1
endif

somebody.NX_SetEVFl "Sexout:Start::CallVer" 1
somebody.NX_SetEVFo "Sexout:Start::ActorA" somebody
somebody.NX_SetEVFo "Sexout:Start::ActorB" player
somebody.CIOS SexoutBegin

 

Except for the over-zealouts use of somebody, and the 'do' bit. Reference functions always know who 'self' is so I'd replace that with this:

 
ref somebody
set somebody to getself

NX_SetEVFl "Sexout:Start::CallVer" 1
NX_SetEVFo "Sexout:Start::ActorA" somebody
NX_SetEVFo "Sexout:Start::ActorB" player
CIOS SexoutBegin

Should work just fine, but try it out in a test dialog script if you like.

 

Also, sexout has 'helper' spells when you are trying to just have straight up sex with the player and an npc.

CIOS SexoutNGDoPlayerVaginal

Will do exactly what you're trying to do, and that's all you need. Internally it just runs this script:

scn SexoutNGDoPlayerVaginalSCRIPT

int bInit
ref self

Begin ScriptEffectStart
  if 0 == bInit
    set bInit to 1
    set self to GetSelf
    
    self.NX_SetEVFl "Sexout:Start::CallVer" 1
    self.NX_SetEVFl "Sexout:Start::isVaginal" 1
    self.NX_SetEVFo "Sexout:Start::actorA" self
    self.NX_SetEVFo "Sexout:Start::actorB" playerREF
    CIOS SexoutBegin
  endif
End

You can see I, too, got carried away with the 'self's. All of them preceeding NX should be axed.

[prideslayer]

There are corresponding Anal and Oral versions of that spell, as well.

[prideslayer]

Tell y'all what. I'll make one more SSR release with most of the stuff left in. All the quests and scripts will remain, with their variables, but without any running code. All the effects, drugs, worldspace edits, cell edits, STDs, races, NPCs, vanilla edits, etc. will be removed. Formlists and their contents will stay. This will have a lot more stuff left in it than I personally want, but it will be the most compatible with other mods.

 

Will only take me an hour or so, I'm getting to be an old hand at this. When it's done, more candidates for removal can be found, and you can all test it with your own mods. Some things in it WILL get removed eventually, but we can look them over and see. That's as accomodating a starting point as I can produce for those that have a desire to switch their mods to SSR but are wincing at the work involved..

 

Edit: By all scripts I mean all QUEST scripts will remain, but without any running code segments. All the other scripts (object, effect, etc) will be removed.

[iron_jack]

Except for the over-zealouts use of somebody, and the 'do' bit. Reference functions always know who 'self' is so I'd replace that with this:

 
ref somebody
set somebody to getself

NX_SetEVFl "Sexout:Start::CallVer" 1
NX_SetEVFo "Sexout:Start::ActorA" somebody
NX_SetEVFo "Sexout:Start::ActorB" player
CIOS SexoutBegin

Should work just fine, but try it out in a test dialog script if you like.

 

I think that was the next thing I tried (next logical step it seems like), but for some reason it wasn't working like it should've. It's possible I did something stupid though, I don't remember enough to tell for sure.

Also, sexout has 'helper' spells when you are trying to just have straight up sex with the player and an npc.

CIOS SexoutNGDoPlayerVaginal

Will do exactly what you're trying to do, and that's all you need. Internally it just runs this script:

scn SexoutNGDoPlayerVaginalSCRIPT

int bInit
ref self

Begin ScriptEffectStart
  if 0 == bInit
    set bInit to 1
    set self to GetSelf
    
    self.NX_SetEVFl "Sexout:Start::CallVer" 1
    self.NX_SetEVFl "Sexout:Start::isVaginal" 1
    self.NX_SetEVFo "Sexout:Start::actorA" self
    self.NX_SetEVFo "Sexout:Start::actorB" playerREF
    CIOS SexoutBegin
  endif
End

You can see I, too, got carried away with the 'self's. All of them preceeding NX should be axed.

 

That's handy and easy though. Thanks!

[Halstrom]

I'll just say I fully support Prideslayers SSR, some people may either prefer to run a "Lite" resource, or be forced into it by their systems ability to handle SCR in conjuction with other numerous, large or heavy mods. And I am working with Prideslayer as I don't want this to cause divisions in the community, SCR isn't being dumped, it's going to go on a weight loss program, but I fully intend all the current functionality to remain but probably in 3-4 mods instead of 1. It will take time though, I'm testing a release for today with some trash removed and things like the Jentai companion removed, Some Pregnancy stuff moved to Pregnancy and some more minor bugs fixed and conditions put in for recipes etc. Some of the things raised haven't been brought to my attention by users for me to know they were an issue, and I have happily added facilities to turn off things as asked. It is bloated and I intend to carefully fix it, but it's not going to happen overnight and I don't intend to cause sudden mass breakages in the process. And unless other people want to take up ball I doubt I will get much more than Drugs & Diseases moved out by Xmas. But from what I've seen that reduces SCR a lot in size alone and creates the least breakage trauma.

 

Outfit swapping is currently in 2 different systems, the Pregnancy system is primitive and near it's limit for further expansion of more outfits. I set up tthe Outfit damage systemin SCR for the damaged outfit meshes Evilrunner has been working on, but no ones stepped up to help him there so it's fizzled a bit. I put a lot of effort into that system to make it pretty quick lag friendly and solid, a better system than Pregnancy and expandable just by copying the scripts & running a rename through the script for a new outfit, by the time I allowed for the pregnant variations of the damaged outfits, it was only a few steps from doing the Pregnant swapping as well, and I was experiencing the 2 swapping systems clashing with each other, so it makes sense to have one swapping system does all and eventually as it's own mod. I'm more than happy if someone want to take that ball and run with it or improve the way I've done it, unfortunately it does require GECK editing of either the vanilla outfits involved or their effects, I don't like that but it was the most robust way I could workout how to do it for any actor wearing the outfit.

 

This is all prompted by the reports of CTD & Stuttering with my recent upgrade of SCR & Pregnancy, both which were in beta for near 2 months ahead of the stable version without any reports I can recall of those issues, it was only when it went to Stable it seems some people systems & mod combinations just can't handle it, my XP 5yo system seems to perform fine so it's damn hard for me to narrow down any issue with my stuff, and I am running near my limit for mods with a lot of the big mods and every Non conflicting Sexout Plugin I can so I can spot conflicts between mine and other peoples mods. It seems that for some people to run SCR has become impossible, so I need to make changes to fix that.

[prideslayer]

I'm more than happy if someone want to take that ball and run with it or improve the way I've done it, unfortunately it does require GECK editing of either the vanilla outfits involved or their effects, I don't like that but it was the most robust way I could workout how to do it for any actor wearing the outfit.

Out of curiosity, why does it require editing base outfits or their enchantments? The outfits are just being swapped out as their condition deteriorates, right? This doesn't even sound to me like a sexout thing, let alone an SCR thing. It should probably be in its own standalone mod that doesn't require either one.

 

Pregnancy could then use that mod as a master, or they could communicate via some other mechanism. A callback/notification system similar to what Sexout does seems like it would work in conjunction with a quest or NX var.

 

Pregnancy "plugs in" to the damaged-clothes mod and requests it be notified when clothing needs to be changed due to condition. The mod suspends swapping on its own pending the results of the notification via the NX/quest var. Pregnancy can then swap to a pregnant+damaged version if it has one, the regular pregnant version if not (if the user says they want pregnancy to supercede damage, visually), or do nothing and let the clothing mod handle it itself.

 

Basically this would be something like the damage mod setting the var to 1 and then casting the spell. Pregnancy does its thing and then sets it to either 2 ("ok, I changed it") or 3 ("I did not change it, you can.") and perhaps other values like 4 ("I could not change it but you should not either") for instances where say a P4 damage-level1 degraded to P4 damage-level2, and you want to keep showing the P4+damage1 mesh rather than a P0+damage2 mesh.

 

disclaimer: It's 1am and I'm still jacking around in the geck and fnvedit on the 'bigger' SSR. What I typed above may make no sense.

[Halstrom]

LOL, well there was reasoning behind my lunacy to my thoughts anyway, I was near the script limits in the clunky Pregnancy system, and it had some issues, it also needed a scripted token running on the actor whether they were wearing swappable clothing or not, and you had to get the swap script token onto an actor for it to work and know it was wanted on an actor.

 

To have any NPC wearing a swapable outfit, I had to add the script to the outfit as either an object script or an effect script, I wanted a script that ran when an outfit was worn it check it's own health for changes, so when it detected a change it needed to swap and do so without losing it's current health, so I got it to add a self removing one shot token with the swapping script that could remove the old outfit and replace it with the new then update the health to the correct number. I tried it as an object script but found through a quirk of the game engine an object script can add a token fine to the Player, but causes a freeze up or CTD if you try it on an NPC. Also outfits inworld or inventory would be running idling scripts. So I had to add an effect spell to the swappable outfits or an extra base effect to those outfits already with Effect Spells, we've only done this on half a dozen outfits so far as there aren't any more damaged meshes, the sytem can have as many stages of damage as there are variations and also work for male versions too if someone creates the meshes. It shouldn't cause load because it only runs when worn running a check every few seconds or so rather than every scan. It does bloat because it requires 2 scripts for every item, but those scripts are reused in all the swappable mesh variations of that outfit. The main hiccup I have seen in functionality so far is it's not going to work as easily for nude bodies, no nude body outfit means no script.

 

I also did try to use the GECK Destructible object system to swap meshes but besides also requiring editing of vanilla resources, it also caused game freezing or CTD when used on clothing, can't remember which.

 

As you say it could be a seperate plugin and Pregnancy would require it as a master, as well as requiring the Drugs&Disease for the Fertility Drugs if desired.

 

Now I'm thinking using NX I could use a quest script instead of a token and have the actors ref and outfit type & health sent to the quest script to do the swapping, saving a token. But I still need a health / belly size checking script, You probably have a better idea for this, I wish you'd been around when we poked with this idea

[Nverjos]

Now I'm thinking using NX I could use a quest script instead of a token and have the actors ref and outfit type & health sent to the quest script to do the swapping, saving a token. But I still need a health / belly size checking script, You probably have a better idea for this, I wish you'd been around when we poked with this idea

 

I know I'm new to the whole Geck system but couldn't you do all that with one quest and a couple stages. Send the actor, outfit, and all that, have the main script of the quest perform the checks and then switch to a different stage to trigger a result set to do the swap and then switch back, or vice versa?

[Halstrom]

 

Now I'm thinking using NX I could use a quest script instead of a token and have the actors ref and outfit type & health sent to the quest script to do the swapping, saving a token. But I still need a health / belly size checking script, You probably have a better idea for this, I wish you'd been around when we poked with this idea

 

I know I'm new to the whole Geck system but couldn't you do all that with one quest and a couple stages. Send the actor, outfit, and all that, have the main script of the quest perform the checks and then switch to a different stage to trigger a result set to do the swap and then switch back, or vice versa?

 

The quest bit is the easy bit, detecting the change of health or preg belly size that a swap is possible & required is the hard bit unless you run a scanner based on the player that checks all the surrounding NPC's outfits to see if they are swapable and require swapping.

[Nverjos]

 

The quest bit is the easy bit, detecting the change of health or preg belly size that a swap is possible & required is the hard bit unless you run a scanner based on the player that checks all the surrounding NPC's outfits to see if they are swapable and require swapping.

 

 

Ahh, yeah, I wasn't even thinking about NPC's when I responded. I personally always have them disabled and forgot they could get pregnant too.

 

[prideslayer]

As you say it could be a seperate plugin and Pregnancy would require it as a master, as well as requiring the Drugs&Disease for the Fertility Drugs if desired.

Two things; I think drugs and deseases should be separate not just from everything else, but from each other. Pregnancy can add its own drugs (bunaway, fertx, etc) in the pregnancy master, but I don't think that master should add them to leveled lists or add dialog, etc. That could be done in an ESP that uses pregnancy as a master. This would make it easier to keep pregnancy functionality, but change how the pregnancy related drugs work, where they can be found, etc.

 

Second, I don't think the general drugs (date rape, etc) and STDs (with their own cures) need to be masters at all, but maybe I'm missing something. I don't understand why pregnancy would need a drug or disease mod as it's master.

Now I'm thinking using NX I could use a quest script instead of a token and have the actors ref and outfit type & health sent to the quest script to do the swapping, saving a token. But I still need a health / belly size checking script, You probably have a better idea for this, I wish you'd been around when we poked with this idea

I'm not against modifying vanilla resources "ever", I've tried to clarify that. I don't think SCR or any other "core" master, required by the bulk of the playable sexout mods, should do so. An STD mod, as a master or not, could certainly modify vanilla records. I'm hesitant to make it a master if it does so, because we run into the same problem eventually -- playable sexout mods that want to 'use' STDs will set that STD mod as their master, which will mean to use that mod you need to use a *specific* STD mod that may have vanilla resource edits that you, as a player, do not want.

 

So, an outfit swapping master that can support damaged outfits, pregnancy, etc., without modifying vanilla resources sounds fine to me. The outfits themselves can be in the swapping-master, as long as there's a way (and the default is) to not do any auto-swapping based on anything.

 

This would allow modders to use that as a master if they want access to a particular damaged version for a specific NPC in their mod, without requiring end users to turn 'on' the damage swapping or pregnancy or.. whatever else. The idea, as with SCR/SSR, is that it's a resource for other mods/modders to use -- not, by itself, something that affects gameplay.

 

That said, here's a wall of text about perhaps another way to implement the swapping. It may not work. No method will be perfect though, and I explain why.

 

 

 

If you make damage-level-0 armor and clothing items that are just copies of the vanilla item, for every item you have damage level meshes for, I think you can do what you want with a scanner and some clever scripting.

 

The scanners job is to look for anyone (including the player) wearing a vanilla item that you have damage meshes for. When it finds one, it just needs to swap it out for the (enchanted with your script or whatever) no-damage version, and from there, what you've done already would work just fine.

 

The question is how can you easily find the right BaseID of the damage-level-0 version, given the BaseID of the vanilla version that the scanner found. If you have an ESP or ESM that holds the damaged base forms, and *nothing* else, this is actually pretty easy. Get the baseID and then bitwise-and it by 0x00FFFFFF. Get the mod index of the esp holding the damaged items, and then use buildref with that and the result of the bitwise-and. This is the new FormID of the damage-level-0 armor that you'll use with additem.

 

If you copy the items in fnvedit and leave their FormIDs intact, you'll end up with something like this:

 

In FalloutNV.ESM, the Vault 101 jumpsuit is 0x0000431E. If you copy that into the armor mod which is loaded at say slot 14 in your load order, the identical armor but enchanted/whatever (the damage-level-0 version) will be 0x0E00431E -- the first two digits are the mod index / load order.

 

This may be a bit complicated to explain, and there might be something goofy about buildref that would make it not work, but at a glance it seems solid.

 

---------------------

 

I know it's all kinda complicated, and I may be overthinking things. My "problem" is that neither this outfit swapper, nor pregnancy, know what base meshes I have installed for clothing that have overridden the vanilla *meshes*. There are dozens, if not hundreds, of clothing swapping mods. Bouncing and not bouncing, sexy and not sexy, for every different body type and subtype. Enough that even if you covered every variation in BBR, you wouldn't even be halfway done.

 

Anything that tries to swap my clothing out for some modified version is likely going to completely change the look of the clothes, since my installed base mesh is probably not the one damage or pregnancy meshes are based on.

 

There is no easy way to solve this problem. What I've been hoping for is a flash of insight (or someone else that's smarter than I am) to find a way to scale bones from within a script. This could be done either via morph targets like the FAFF facial ones and the breast-resizing ones, or perhaps via new NX calls that can dig down into the NIF details of the actor's current mesh and scale the bones. I spent some time hunting for the skeleton nif data within NX to add something like "refActor.NX_SetBoneScale 1.3" or something like that and didn't find it, but there's so much to search through I may have just missed it.

 

 

[prideslayer]

SSRv1b2.7z is up in the OP.

 

This one is much 'larger' than the last diet version. Much more stuff was left behind *almost* unmolested, to ease the transition. Pregnancy will not work with this version, since every script except the one that adds items to the Sexout formlists has been gutted. All the non-quest scripts have been removed along with all vanilla resource edits, ammo, ammo effects, etc. The quest scripts remain but other than the list-adding one, only contain variables -- the GameMode (or whateverMode) blocks are gone from all of them.

 

Weapons, armors (except vanilla edits), textures, statics, and formlists should all be present and mostly unmolested.

 

Creatures, NPCs, races, hair, and all such things have been removed.

 

I also fixed an oversight with the GREETING dialog topic and fixed tryouts Kings and Khans which were not fixed (or present) in the last upload. I don't use those two tryouts and forgot that I hadn't even installed them. They were using no SCR resources and needed no change except to change the master from SCR to SSR -- having it as a master is still required, since they use Legion as a master, which itself uses SSR.

 

If you (yes, YOU!) are a modder that has used SCR in a mod and you want to test or convert to SSR, you need to:

 

1. Open your mod in fnvedit with whatever requirements it has + SSR. Likely, at least, FalloutNV.esm, Sexout.ESM, SexoutCommonResources.esm, SexoutSharedResources.esm.

 

2. Check for errors on your mod.

 

3. In the "file header" section of your mod, change SCR to SSR in the masters list.

 

4. Check for errors again. You will hopefully not get any that weren't in step 2. One you may get, if your mod changes GREETING dialog, is some error about that. It looks like this:

[00:00] Checking for Errors in [1C] SexoutSS.esp

[00:00] QSTI - Quest -> [02000AE0] <Error: Could not be resolved>

[00:00] Above errors were found in :Added Quest

[00:00] Above errors were found in :Added Quests

[00:00] Above errors were found in :GREETING "GREETING" [DIAL:000000C8]

[00:00] Above errors were found in :GRUP Top "DIAL"

To fix this:

 

4a. select the greeting dialog (In the tree: yourmod -> Dialog Topic -> GREETING)

 

4b. Scroll down until you find a yellow line of type QSTI (added quest) that says something about a missing reference to the number from the error (02000AE0) -- the '02' may be different depending on where SCR was in your mods master list. It will be three lines, two or three will be yellow, and instead of a quest name it will have that error about ...AE0.

 

4c. Right click the ROW that says "Added Quest" on the left over the error, and the COLUMN corresponding to your mod, and select delete.

 

5d. Check for errors again on your mod. Make sure no other mod was modified by you click/deleting the wrong thing in 4c!

 

This is due to mods that modify GREETING inheriting the (now missing) GREETING modification from SCR.

[iron_jack]

One thing I do want to point out - to the community of modders as a whole - is the issue of user-friendly installs.

 

 

SCR is a massive hambeast in its current state, for sure, and I definitely support trimming the fat. That being said, if you guys are going to branch each current master down into a trimmed master and 5-6 additional optional ESPs, you're going to get people befuddled. Modularity is a double-edged sword.

 

 

The best way (IMO) to avoid this is to start making use of FOMOD scripting. It's fine if Pregnancy, for instance, has half a dozen child ESPs... if all a user has to to is check off what they want when they're installing it in a nice pretty little box.

 

If users have to go trekking all over the place, gathering up masters and child plugins to get the same functionality they're used to getting from 1-2 plugins... you guys are gonna have lots of "tech support" (I use the term loosely) to do.

 

A "fullish" Sexout install already easily has a couple dozen plugins and half a dozen masters (which also need to be ordered correctly). With all this splitting off, that number could double or triple.

 

And that's not to mention the (apparent) redundancy here - SexoutSharedResources? SexoutCommonResources? Same thing, right? Oh, it isn't? Which one do I need? Why do I need both? What do they even do? I just want to get my depths plumbed by geckos and have an army of gecko babies, WHY IS IT SO HARD?

 

 

 

Like I say, I fully support what y'all are trying to do - it needs to be done, hell. But the old "just track down plugins x, y, and z and toss 'em in your data folder" days are over. And FOMOD-ready, to me, does not mean "a 7z archive with all possible esps in the top-level folder", because that's the same as "just toss everything in your data folder".  You, we, all of us need to start leaning on the power of FOMOD scripting, lest the beast that is Sexout start gobbling up and spitting out potential users before they have a chance to experience it.

----------

Welcome to SexoutPregnancy! Please check which options you want installed:

[x] Pregnancy (required)
[ ] Fertility Drugs
[ ] Pregancy Outfit Resizing
[ ] Mutation/miscarriage
etc.

----------
 

SexoutShenanigans has determined that you do not have the following necessary mods installed:

-SexoutSharedResources
-SexoutSlavery

Please install the above mods BEFORE attempting to install this one!
 

 

 

Just my two pence. And obviously it's not just up to you guys (Pride and Hal), but all of our modders. I just cringe when I think of what is already a pretty complicated (to the average user) install process getting even more complicated in the interests of efficiency.

 

 

 

 

...Maybe I should have started a new topic. Ahem.

[prideslayer]

I'm with you. Are you volunteering?

 

Sexout itself already uses some degree of fomod scripting to reorder the masters, warn you to install SCR if you haven't already, and so on. Install options for different things would be nice as well. SSR and SCR aren't meant *to* coexist, I just created SSR in a way that will allow them to be until either : We all give up on SSR, or SSR replaces SCR.

 

My updated to FOMM are still on the back burner, and I'm using a custom build myself right now. One thing in particular it could do better is straight up refuse to 'launch' if it detects a master file load-order problem, or missing/deactivated master. This is something I hope to be able to add in with a minimum of fuss once I finish cleaning the code up.

 

In any case, it doesn't seem like we really have that big of an issue here. There aren't that many sexout master files. Sexout, SSR, SCR, Slavery, Legion, Pregnancy. Are there others I'm not aware of that are masters? The load order of ESPs still does not really matter for sexout mods.

[ChancellorKremlin]

 

<snip>

 

Coming from someone that has to constantly keep redirecting people to "How To Install" threads, I can't say how much I support this statement enough. Amen!

 

I loved it when FOMOD installation was added to Sexout, I just wish there was more of it to go around. That being the case, anything that makes that process easier and more appealing is something worth looking into. 

[iron_jack]

I'm with you. Are you volunteering?

You betcha. Next mod I release myself, I promise I'll make a handy-dandy installer script for it.

 

 

Like I said, not directed to you in particular, and I do appreciate that your portion of the "core" of Sexout is already nice and FOMOD-y. It's just something for everyone involved in the trimming process to bear in mind, is all.

[Halstrom]

FOMOD sounds like a good idea too, I'm just not sure with the amount on my plate I have time to learn it.