prideslayer

2.6.86b7 in OP - New UDF : fnSexoutCopyListItems list:From list:To int:Mode (0 = 1:1, 1 = deep copy, 2 = ignore sublists) - Removed errant restricted cell check, oops! - Additional debugging to actor lock UDF. I left beta5 in place as well since it's hardly been tested yet, and this TFC thing has potential to break stuff. It was ok in my testing but I didn't spend long. The new udf works as described above. It copies formlists from FROM to TO according to MODE. The mode can be one of: 0: Sublists are copied as-is. 1: Sublists (infinite recursion warning!) are iterated and their contents copied. 2: Sublists are entirely ignored.

Odessa, does that scene with doc work ok with Beta5?

Oh they should also change any buildrefs to ZAZ items to the matching ones in NG in that case. If they are referencing them by name, with ZAZ as an ESP 'master', they only need to recompile the scripts -- I left all the names alone.

No. I'm including a blank ZAZ ESP to give modders who look for the ESP a chance to check for that *or* the NG version. NG versions >= 86 will all have ZAZ, even if the ESP isn't present.

Oh that's interesting.. a situation where the delay hurts! I can reduce that to one frame if it's consistent. I was concerned, when I wrote it, that 1 frame may not be enough time to transition to 3rd.

Did you install the SexoutNG beta? The zip file has an empty ZAZ esp, since in the beta, ZAZ has been included (finally) in the NG ESM. If you download this one, it has all the idle anims in it and so on.

Odessa, the telephoto option in MCM does basically what you describe; I couldn't think of a better name back when I wrote it. It will hold down the 'backup' key to zoom out for however long the MCM setting says. It's not enabled by default though. As for ActorA issue, for some reason the log says that the doc wasn't locked.. I wonder why the system continued on at all. Might be related to that restricted actor/cell stuff. Is this bug consistent with Doc, in that location?

We aren't going to be able to help you unless you're more specific. List exactly the steps you're performing to do the install, with filenames, etc. Make sure that after the install the files actually exist in data/nvse/plugins/

That message only comes up when NX is *not* installed. Period. So if you did install NX, you didn't install it correctly ... 20 times in a row?! Explain exactly *how* you are installing it.

2.6.86b6 in OP - Smarter TFC handling. Sex initiated when already in TFC should work. Savegames made during sex in TFC should also load fine. (beta6) I left beta5 in place as well since it's hardly been tested yet, and this TFC thing has potential to break stuff. It was ok in my testing but I didn't spend long.

Wow.. well in general it's not happening to me in testing, with the console or with tryouts. I'm not using/testing any of the 3rd party animations or anything like that. My general/testing load order export:

I've seen it on occasion, it's not a sexout specific issue, just a general game glitch. Try to track down where it's happening, and if it's just a specific subset of animations or completely random ones, if you can. There may be some animations that could cause it to happen more frequently if they're vertically adjusting the positions. If so I can add some positive vertical offset to them.

2.6.86b5 in OP - Blanked out unused camera spell. - Actors not unrestrained until end of unlock. Issue #21. - ActorB copy/paste fix. Issue #19. - Version update script ordering fixed. - Actor readiness UDF implemented.

It might be related to a quest var? I remember a similar issue a while back.

Hah.. chalk up another "win" for the stunning team over there. If it was all language typos and not so many engine bugs, we'd all be better off. Too bad they can't get *anything* right.

I think it would be pretty simple to fix this with NVSE by just editing that table. Would fix that function and the controls menu both I believe.

Ah balls, I have to retract that a bit. It IS in the engine, somewhat. GetKeyName is calling an internal function that looks in some game data structure that has two unknown fields. It's doing this (I think) because of key 'names' for different languages, on non-alphanumeric keys, like 'enter' and 'shift'. It would be really easy to change this function to use the built in windows function. If jaam is still watching, he can handle that, or I can take a crack at it.

It's possible that two things are going on.. both GetKeyPress and GetKeyName are in NVSE and might be broken in different ways. I'm peeking at NVSE src for a minute. Neither one has anything to do with the game itself, so we don't have to blame beth/obsidian.

I'm sure they are using scancodes basically as you say, because there's no other way to communicate with the hardware. The keyboard itself sends scancodes -- not 'letters' or 'characters'. The code to convert a scancode to a character is terribly easy, and the same no matter the game region -- it's built in to windows. I find it hard to believe they coded their own version of that. GetKeyNameText() is a built in windows function. You give it the scancode and a buffer, and it puts the ascii value for that scancode (according to current windows keyboard setting) into the buffer. There should literally not be any code in the game engine to 'handle' this. 1. You plug in your keyboard of choice, any format. 2. You tell windows the layout, if it can't learn it via USB query. 3. Key < -- > Scancode map is now complete. So as you say, maybe they did something insane. I'd seriously wonder WHY... if I didn't know better. No matter what language you speak, or what language windows is set to, if you plug in an AZERTY keyboard, that first character is still 'A'. It's 'A' no matter if you're speaking English, Italian, French, or Russian. Understand what I mean?

Sorry, yes, I meant 16 (not 30). That's the right scancode for that key. And... wow.. way to go Beth/Obs/etc. That's pretty messed up, but I assume that now you have it straightened out, and no longer double-Z?

So, you have a QWERTY keyboard, but you have windows (or some game INI setting) set to AZERTY? Why does it think your keyboard is AZERTY when it's QWERTY? It sounds like it's mixed up two different keyboard types. AZERTY and QWERTZ. That would explain why both of those positions give you a Z.

AJ, try this: http://www.softpedia.com/progDownload/KeyTweak-Download-10487.html Just install it and run, then select "half teach mode" at the bottom. A new window will pop up, click "scan a single key" and press your 'Q' or 'Y' or whatever keys are popping up as Z's, make sure it's actually getting different scancodes. The program will also show any active remapping. The first row for all keyboards should be: Q W E R T Y (querty)A Z E R T Y (azerty)Q W E R T Z (qwertz)17 18 19 20 21 22 (scancode)

I have no real idea why you'd be seeing two Z's. Are you sure that is what's happening? The scancodes are identical? I don't know how you came up with your list of what you pressed vs. what you expected. On an AZERTY keyboard those keys should produce exactly the same scancodes as pressing QWERTY on a QWERTY keyboard. As for Jaam, different keyboards or regional settings maybe, or different drivers. It's the keyboard that generates the actual scancode. Windows can be configured to interpret this and modify it, based on regional settings. Your keyboard layout doesn't matter; the key in that position ('Q' on QWERTY and QWERTZ, 'A' on AZERTY, "'" on DVORAK) does not matter. Pressing that key will always generate scancode 16 from the keyboard. The character that then appears on the screen depends on the windows locale and keyboard settings, the game region settings, etc. Also, USB keyboards can generate different (USB HID) specific scancodes. So if one of you is using USB and the other one PS/2, the scancodes may be different for the same key.

Yes. The receiver is always the one being penetrated, no matter the orifice. I know it's a bit counter intuitive, one day, I'll have a better system.

Well, that'll do the trick.