prideslayer

FNIS itself does not have any sexual poses at all. It's just something that allows poses and animations from other sources to be incorporated into skyrim. Sexlab uses it, as do many other things.

Yep I like the idea of using them for the global hooks. That system is a massive hack right now. Don't go peeking into how it works, it's embarrassing but the best I could do at the time. It predates NX and all this fancy NVSE stuff. Also I know Hal has a bunch of timers in SCR that wait for things to be ready that take an indeterminate amount of time. He could use the events and/or the ready UDF as well.

Nobody is suggesting this any more than they're suggesting that MAX or blender restrict creating or animating children. We are (or were) talking about sexually explicit framework mods like sexout and sexlab. FNIS needs to stay compatible with children. Sexout and Sexlab do not.

It's best if you turn on the console log at the start of the game, before you load your save. Make the save first somewhere that you can somewhat quickly reproduce the problem, but before it happens. Turn on sexout debug mode (in MISC -- just normal debug, not scanner) before making the save. Quit. Start. Open the console while at the main menu and enter scof "debug.txt"Load the game, play to the error, and quit. Upload "debug.txt" from your game directory. Delete debug.txt, or else next time you go to capture a log, it will append to that file instead of creating a new one.

I want to give everyone some time to test the current beta and make sure it's fixing their issues with Tryout/WG before updating, but as a heads up for any modders not watching the scripting 101 thread, beta2 will have this as reflected by the OP: - fnSexoutGetReady UDF. Returns 1 if sexout is ready, 0 if not. - SexoutNG.bSexoutReady is now ALWAYS 0. This will stop plugins that use it from working until they are updated. Any modders who want an early version of beta2, PM me and I'll send it to you. This will let you update your code for it before any users can download it, if this change will cause your mod to stop functioning.

How would my "target audience" be "locked out" by stronger anti-pedo protection? I don't understand what you're trying to say.

I'll gladly do that, if it'll work. Seems like I could support both no problem (the notification and the polling), but think about this: How is your own mod going to know sexout has actually sent the notification -- or that you just think it has, because you recorded that it was sent in a quest var or something that got loaded in a save? That var that you set to 0 in your gameloaded/restarted block and then don't set to 1 until you get the event will still itself be 1 if the user saves after the event. Even if you set it to 0 again, that's not proof against your own scripts in spells and such in the save running before you've set it back to 0 on a game load. Calling the UDF in sexout everywhere you need it will ensure it's actually ready. You can even check it in the gamemode or scripteffectupdate blocks of your spells and quests that may also be present in the save game, so they 'pause' when a game is loaded until sexout is ready.

I'm in full agreement with this sentiment, the sidetrack was unintentional. That topic just sets my blood boiling.

Practical example, this is what I'm actually doing in sexout now (unreleased 93b2). In the quest script restarted/loaded block: ; this is no longer used; set bSexoutReady to 1let rIsReady := TempCloneForm 00SexoutActorAnd the UDF y'all will be calling scn fnSexoutGetReadyint bReadyBegin GameMode let bReady := 0 if SexoutNG.rIsReady let bReady := 1 endif SetFunctionValue bReadyEndThat's all there is to it.

Because I detest the idea that much, and enjoy the challenge. The analogy doesn't really fit either, it's really more like DRM (evil as that may sound) and engineers do sit around all day thinking about it.

Dammit I just said screencaps do nothing for me. I don't need them at all. I can't recognize the hundreds of animations by sight, and many look identical when frozen anyway since they're just running at different speeds. I need to know three things to fix alignment issues and things like that. 1. What version of sexout you're on. If you're not on the latest one (beta if there is one, release otherwise) then update and test again before reporting. 2. If you've installed any 3rd party animation plugins. If so, disable them and test again before reporting. 3. If you get to this step (latest sexout, no animation plugins), open the console, click one of the actors, and type 'inv'. Look for the "SexoutNGAnimCounter" in the inventory list. There will be anywhere from a few hundred of them, to several thousand. I need to know how many -- that is the anim # of the playing anim. Alternatively you can do one of two things. 1. Capture a sexout debug log the normal way. The animation that is being played is logged there. 2. (I really do not like this, but.. shit..) Save the game during the animation and then send me the NX save file. The CSV. Not the actual save ending in .sav, not the nvse file ending in .nvse, the NX file. It's in data/nvse/plugins/extender/saves/ and will otherwise be named the same thing as the save.

I had a eureka moment a bit earlier to solve a puzzle that's been digging at me for quite a while but I've never really spent the time to investigate. Tested and it works fine. The puzzle is "How can you have a quest var, or something similar, that other mods can check to see if your mod is ready to proceed -- WITHOUT any potential race conditions." An example of one that doesn't work is in the current version of sexout, called "SexoutNG.bSexoutReady". This is a quest var I initially created in the hopes that other mods would check it before making sexout calls or accessing other sexout quest vars. The main quest sets it to 0 on gameloaded/restarted and then back to 1 after everything is ready. It doesn't work reliably because in a savegame, it's 1, and if a mod checks it when the game is loaded in a script that runs before sexout has a chance to set it back to 0, they erroneously think sexout is ready. This however is simple, and works reliably: let rIsReady := TempCloneForm 00SexoutActorTempCloneForms are not saved in savegames, and automatically reset to 0 whenever a game is loaded or a new game is started. So beta2 of the next sexout (v93) will have a new method to determine if sexout is ready. Instead of checking that quest var, there will be a UDF (in case I must change this AGAIN) called "fnSexoutGetReady". If it returns 1, sexout is ready. If not, it's not. For now this will be accomplished by it checking the status of that ref var. Simple, and it works! Use something similar in your own mods and put this nightmare to rest once and for all.

Well, two things. 1) If you put important things in a script along with the checks, you can delete the script source from the plugin with FNVEdit. This makes it impossible to modify and must be reconstructed, as I don't believe there is a script decompiler that works for FO3/FONV like there is for Skyrim. 2) I'm the author of NX as well. I'll put fucking strong crypto in there if I have to, and take it closed source, if it comes to that. I have some experience in this field. If a determined person wants to get around it, they'll be able to, but it's not something your average (or above average) modder will be capable of doing.

2.10.93Beta1 in OP Changes: - Unified fnSexoutActRun and fnSexoutActRunFull. The first one now calls the second. - Both use preemptive locking on the actors. (lock race fix 1/2). - The indefinite wait for unlock in the quest interface is gone, will now fail with a SAN error as before. (lock race fix 2/2). - Vibrator key lust check override removed, vibrator key again working. - The scanner no longer includes actors with the 'ghost' flag set. - fnSexoutActRunFull (and thus fnSexoutActPrep/Set/Run) will abort on actors with the 'ghost' flag set. - A system for 3rd party plugins to register animations is now in place, though incomplete. I intended to hold off on releasing this beta until the animation registration system was complete, but given the nature of the bugs fixed (again) with regard to locking and the impact those bugs and fixes can have on players, I decided to get the first beta out early. FOR PLAYERS This release should eliminate many of the "stuck actor" issues some of you have been experiencing in Tryout and Working Girl. I've tested it myself in a standalone test ESP, and sent it to Loogie for further testing. He reports a-ok. FOR MODDERS In the wake of the v92 release an the "Amra Plugin" debacle, Odessa and I began some long overdue work to add support to sexout for mods to provide and register their own animations, without requiring any intervention on my part such as assigning animation ranges and so on. The first half of this work is complete, and in this beta. This is why the ESM size has grown so much. I am NOT documenting it here because it's not yet finished, Odessa and I are still testing. I don't expect any "big" changes, but just in case, I'd prefer people refrain from using it. In the mean time, familiarize yourself with NX_GetQVEVFl as you'll need it, in addition to a UDF call and some arrays to make use of this functionality. Animators can still send me their KF files for inclusion directly into sexout, but if you intend to make many of them, you can create a plugin and release your own "pack" and not wait on me for fixes or updates. Still TBD: - Register the ZAZ animations. - Rewrite the random picker to use the system. - Create MCM menus to enable/disable animations. - Write actual usage documentation. - Update IDLEs to use NX_GetQVEVFl. - Things I forgot to put on this list.

Just set it. myArray[9.5] = SunnyRef

You can use ar_append for normal arrays. What's your use case?

I don't know how many times I can repeat this. Without knowing the actual animation #, I can do fuckall about issues like that. You get it by checking the inventory in the console. I also need to know that you are up to date with the current release, and that you haven't installed Amras animations or any other mods that overwrite sexout files or override records in the ESM.

Let me make this clear: I cannot be held responsible by others, but that does not mean that I feel no responsibility. I put these protections in place not because I'm worried that other people will blame me if I don't -- but because I personally want them there.

I am aware. Some of them are aligned, but most of them aren't. I'm working on it when I have time but it's a lot of animations to go through.

OVERRULED.

Oh no full on reverts, lawdy no. I just finished rewriting the entire Run and RunFull UDFs to get rid of this horribly nasty bug that is contributing to some of the problems reported in Tryouts, and then came across this one, contributing as well. Really I can't think of any mods intentionally using this, and the act 'queue'/FIFO idea I had I now recognize was... a bad one. Terrible in fact. Let us never speak of it again.

  This is true and trying to ban mods on either side of the "if combined, evil" divide is impossible. I was speaking from the point of view of a modder working on something on one side of that divide, not suggesting rules. Is sexout compatible with any of those? I don't know. I hope not. When I have a little more time I'll check, and if it is, I'll fix it.

"would not be" I assume you mean, I haven't left. I'm aware of the Donkey fiasco, he created a lot of the animations that I added to Sexout and we worked together pretty closely. I was sorry to see him go, though I understand why he did.

Kendo what virus is turning everyones name into TWE in your quotes, or is that some joke I'm not getting?

A while back I introduced some functionality into the quest interface that allows an act to be initiated, and sexout will wait indefinitely until all the actors in the act are unlocked (available) before proceeding. This change introduced some subtle issues that haven't come to light until now, and I'm of a mind to remove this functionality, reverting back to the old behavior of the act simply failing if any of the actors are locked. Fixing it so that it works correctly is possible, but it's a lot of work, and when all is said and done it will still cause strange behavior for players even when working properly -- for example an act could be delayed several minutes (or hours) and then suddenly detect the actors are all available, and execute. This could result in actors being teleported across the world and other undesirable things. I will cover this in more detail in the beta thread when I put it out but I want to give a heads up here to get wider coverage, early. Objections will be noted, but rejected. Objections after the beta are out may be considered if they also include code (based on the beta code -- a lot is changing) to permanently and correctly fix the issue. https://www.youtube.com/watch?v=bOnRHAyXqYY