prideslayer

I'm with Loogie on this one.

The attitude that 25% is somehow worse than 0%, or worse than the 0.001% that the professional DLC developers receive, is idiotic. The split is between the modder and Valve, and nobody elses business or concern. People getting bent out of shape that some mods are "worthless" because they're so "simple" are obviously wrong -- somebody paid for them. People getting bent out of shape that somebody, somewhere, might make money by doing a hobby they already enjoy are best called out as the jealous twits they apparently are.

If a mod is sold on the workshop and it relies on some external mod to work (like FNIS), or used some help or documentation provided by the community, tough luck. Every piece of commercial software in the world does exactly the same thing. MS does not get a cut of every piece of software using the windows SDK, nor does the wikipedia foundation get a cut of everything written that uses the information found there.

Your public library doesn't get a kickback from the commercial endeavors that use knowledge gained from the books they loan out, either.

If you're so small-minded and jealous that you just can't stand the thought of someone making a little money, doing something they enjoy, because others are doing similar things for free -- you're part of the problem. A world where every modder could quit their day job to work full time on their mods sounds like a great place to me.

By and large I don't expect players/users to understand or agree with most of what I've said. However, in this case, their opinions don't matter to me even slightly. This is about mods, utilities, and those that create them. All of them deserve compensation for their efforts, and few if any actually get it.

Modders SHOULD understand though. We all work countless hours on this hobby and our reward is generally a few "thank yous", and endless bug reports and feature requests to sift through. If one of "us" decides "hey, it would be nice to make a couple bucks off this if I can" then I fully support that decision. Christ I don't even work on my friends computers or cars for free -- I at least expect dinner and some beer out of the deal.

I won't be responding to replies or reading this thread any further. As I've already said in "private", my active projects (SexoutNG, NX, FOMM, Bodyslide) are on indefinite hiatus because of the immature and childish "community" responses to modders who chose to participate in this system. The system isn't perfect, but it's the first of it's kind, and it deserves time to get the kinks worked out.

Maybe my own project licenses may be changing as a result, at least for three of them -- I don't own the copyrights for FOMM so have no authority to change the license there. Maybe I'm completely done modding or writing modding community software for free. I haven't decided yet.

Thanks "community."

Me too

 

 

Yep, they are there. But could you post your original animations anyway. I would still like to use them the way they were

The way they were will not work with the current (beta) version of sexout, or any future version.

 

Bummer. With all of Amras animations on top of the originals there are like 40 or 50 now. I prefer to keep the number lower. 1 or 2 solo, an oral, and 6 to 10 anal/vaginal. Oh well. Love your stuff none the less.

If your patient and paying attention, you'll see that Sexout is getting a new MCM menu that will let you enable/disable animations on a per-source (e.g. builtin, zaz, amra, etc) basis before too long.

If you're replacing the bighorner animation (1911) when testing, then you're also testing the offsets within sexout for that animation. You need to test with a new # (it can even be 1) in your own ESP, which won't have any offsets applied unless you supply them in the plugin.

At least you followed instructions. errr wait.

Me too

 

 

Yep, they are there. But could you post your original animations anyway. I would still like to use them the way they were

The way they were will not work with the current (beta) version of sexout, or any future version.

Cast SexoutNGPause on one of the involved actors. This will stop the sexout timer and continue indefinitely until you cast SexoutNGResume or SexoutNGFinishNow. Doesn't matter which actor in the act you cast it on, it figures out the original target.

Note: Don't do this unless your code is bulletproof. It can leave the player in a situation where sex can't easily be stopped if your script crashes and never lets the act finish.

Odessa is keeping an eye on this thread, I'm sure, so here is fine for now. Errors that still allow sex to work are... well that's weird. I'll be digging into all this more this weekend.

Oh bugger an empty if for an else? Who does that.

No, they actually say exactly the opposite of each other.

The first one says "return if the result is equal to 1"

The second one says "return if the result is NOT equal to 1"

FOMM has a BSA creator but the best way to do this is to setup the files outside of the FONV data dir entirely, something like c:\mymod\ with 'meshes' and the esp and whatever. You can then manage it on its own, zip it up, and use FOMM or whatever to install it.

When you create a new animation, put it there, zip it up, install it with FOMM again to test.

But I do the same - I compare call fnSexoutActorInuse Myself to 1.

I don't think you quite read what I said there. You're calling two functions, their return value meanings aren't the same.

That's not the right way to use the ActorValid UDF, it does not only return 1/0 like inuse, it returns the reason the actor is invalid.

It can return values from -8 to +1. Only a return value of 1 means "yes the actor is valid" so you want to change that to something like:

if eval (1 != call fnSexoutActorValid Myself)  returnendif

I need to see the call.

Also please update to beta10 just in case.

You shouldn't be using any of the "amra" files or patches now -- just Odessa's mod for Amra's animations. Just FYI.

I've been getting an issue with non-healing limb damage after rape with version 8 and 9;

this happened while I was in god mode, with limb damage disabled in Sexout. Possibly

the mcm control is reversed or disabled for limb damage? I'm at work, so I can't try

reverting to an earlier version of Sexout for a while.

 

(non healing means Doctors Bag and stimpaks don't heal, even out of god mode)

It's not sexout.

That limbdamage thing hasn't done anything in a year or two, still doesn't. It's one of several MCM things I need to address but I'm in the process of rewriting all the MCM stuff to make it more dynamic and easily integrate the animation selector.

Well I don't understand the invisible body aspect, but it was in the wrong place. There shouldn't be invisible bodies since the body is still in the correct location in the sexout bodies BSA.

 

 

Interesting. I have saved the extracted beta 2, 3, 4, 5 and 7 and its in the wrong place in all of those also. I never downloaded 8 or 9.

I imagine it's wrong in all of them since I included it, dunno why I put it there. Just wasn't thinking. That DOES mean that nobody has actually been testing it as I wanted though

It's in the right place in beta10.

Well I don't understand the invisible body aspect, but it was in the wrong place. There shouldn't be invisible bodies since the body is still in the correct location in the sexout bodies BSA.

2.10.93Beta10 in OP

Changes:

- Fixed erect bodysuit mesh location, thanks packprof.

This is a fomod-ready 7z, just install it as a package with fomm/nmm/whatever.

What the.. really? How did that happen.

2.10.93Beta9 in OP

Changes:

- fnSexoutActorValid returns -8 for unsupported creatures.

- Misaligned 3ways disabled for now (5001, 5102, 5305, 5401, 5602, 5603)

- Bighorner animation (1911) realigned.

- All non-zaz anim offsets moved into animation registry.

This is a fomod-ready 7z, just install it as a package with fomm/nmm/whatever.

Sexout will rescale them to 1.0 (well maybe not ants yet, but it does this for bighorners -- ants are no problem) so size isn't an issue. Adding them into sexout is now done with a plugin like the one Odessa made for Amra, it's pretty easy. Send me the KFs and I'll make a first version of the ESP if you can't figure it out, and then you can add future animations to it.

siskin you can use the sexout clothing eval system plugin for that. It lets you add armor/clothing items to sexouts do not remove lists from inside the game. I believe that particular plugin came up once before, and I or someone contacted the author and asked that he make the items into normal inventory tokens rather than wearable items. I can't remember his response though. It's probably in this thread somewhere.

You'll have to look for yourself. 0x24 is the mod it's coming from, whichever one is 24 (hex) in your load order.

That's something I think I can do, yessir.

No. Odessa's mod is fine and that's the right one, but the only one, you should install for that. Not any of the "official" downloads from Amra.

Huh? There's a popup? It's not in sexout heh. I think ants and scorpions "have" animations though -- somebody gave me some vanilla alert idles or something that they said looked ok with the player in some position or other, but that was a long time ago, and not something I want to go through again.

Especially right now.. I think the trig in sexout is off somehow and that's why the 3p animations are screwed up, but I'm not sure. Been a pain in the neck trying to track it down.

It's unfortunately not that simple. I would have to create such an animation in the GECK for every creature, that's just how the engine requires them to be set up. That's a couple dozen new records in the ESM just to support creatures we don't actually have animations for.

I'm willing to entertain non-animation ideas though, if anyone has any good ones.

I'm can provide a UDF that can return a go/nogo for a given list of actors based strictly on their type and count. It could work with the existing runfull UDF parameter array format without issues, though Tomm seems to be using run rather than runfull in submit at the moment. That means either he has to make an additional call first, or I have to change run to return a result -- and I'm not sure if modifying it in that way will break existing mods that use the UDF the way changing parameters does.

It might not though, easy enough to test.

Generally I don't like changing the interface contract though so tomm, would you be OK with calling another UDF first? I could integrate it with the prep/set/run you're already using easy enough with another step, say prep/set/check/run, as well as making a standlone that takes an array param itself?