reikiri

Good to know it's working. I'm not aware of any up-to-date lists, as a rule of thumb if it overwrites any files on SL it's iffish at best, and if it overwrites any files on VR patch it's not going to work. Other than that I've tried to keep it reasonably compatible with things that use SL 'normally', e.g. a mod that simply calls for SL to start an animation. Even so, there's some things that just won't work in VR - like f.ex. VR doesn't have a real 3rd person mode (VRIK does a lot of hacks to make it possible to view things from 3rd person perspective), and the anim objects do not work on player character (basically all sorts of objects that appear for animation and are tied to player.. e.g. a broom or handcuffs). There's also limits based on compatibility of other mods with VR - f.ex. racemenu and nioverride, which for a long time prevented inflation type mods working with VR (although now many of them might work). Right now the best resource may be to check on this thread what people have said (with caveat that things are advancing all the time.. so something that didn't work 6 months ago might work now.. and something that used to work might not work with newer version). I know there was also a big list somewhere about mods that work with special edition, and I think it may have had some mentions about VR compatibility as well. I don't remember where it was, and don't know if it's been kept up to date. I think though, that VR gear is getting more and more common, and with that there's chance that compatibility will improve as well - if there's still enough modders around interested in working with Skyrim.

Are you using MO2, or vortex, or just installing manually? Flower girls itself shouldn't mess things up, certainly not on VR patch MCM page. No wait... you said you have flower girls installed - what are you using to actually start the animation? Flower girls shouldn't mess up sexlab per se, but it has nothing to do with sexlab either. If you start animation with something that's intended for flower girls, then you're actually seeing the flower girls clone, and sexlab isn't even running (and VR patch is a patch for sexlab, so if flower girls is running the animation, VR patch isn't affecting it either). That would explain all the issues you are seeing - except the presets not working, I don't know about that one. The presets should work by moving the focus to the 'click' word, and then using the same button you use to toggle the checkbox options. For running an animation, you could try starting a scene with the sexlab debug spells, the instructions should be... I think on the original post. Or try using matchmaker if you have that installed.

That's really curious. You're able to open the MCM menu and navigate through the menus, so at least your controllers must be working. However if selecting the 'click' options doesn't alter the other values on that page, and those settings showing on the screenshot won't start the scenes in 1st person, then something is wrong. (Default 3rd person unchecked, like you have in the picture, should make the scenes start in 1st person. I do recommend checking the 'lock view to body' to let the animation deal with aligning your body correctly, while your viewpoint gets locked into head position of the body). 1) If you close the MCM and then re-open it, do the settings look as you left them? If you change something (f.ex. disable fadein at start or enable lock view to body) and then close and reopen the MCM, do those changes remain? I'm asking this to make sure the changes you do on the MCM are actually registered and saved into settings.. because the 'click' options not working does suggest the whole sexlab MCM might be broken for you. 2) Check the.. I think it might have been the 'cleanup and debug' page of the Sexlab MCM - the page that shows the status of the SL installation. Check if it shows 'OK' on all of the installed parts. Even if it does, it's still not a 100% guarantee that everything's working properly, but it's a pretty good indication. 3) Make sure you have VR compatible papyrus utils jcontainers installed, and the papyrus utils is installed after sexlab (so that it overwrites the papyrus that comes bundled with sexlab). Also make sure that VR patch overwrites files from Sexlab, and NOTHING overwrites files from VR patch. For JContainers, it may be safer to use JContainersVR-v4.1.12 - the later version (4.1.13) was reported earlier to have problems.

It's worked for me, probably didn't test it right on the latest version, but I don't remember changing things that would affect it. Pretty sure you can activate it only when you are in 3rd person mode already.

I didn't see any issues with skseVR 2.0.12 - which is what I used on compiling the latest VR patch.

There's three checkboxes that affect scaling, I think. On animation settings page there's "Even actor heights" or something like that.. and there's "Disable scaling (possible crash fix)" or - again - something like that. If you turn on the "Disable scaling", it will also disable and gray out the "even heights", so if you just turn on that one from animation settings it's enough from that page. The third one is on VR settings page, I think called "reset VRIK scales" - I'm going by memory here. That one controls negating some VRIK settings to player actor specifically, turn that one off if you want to leave whatever changes you've done in VRIK settings into effect during animations (turning it off will most likely mess up alignment in most animations, because even VRIK default settings are not the proportions the animations expect - but that's an option).

Technically yes, I thought about that earlier.. but the dummy npc would have to essentially be an invisible copy of the PC, placed at exactly same spot, perfectly synced to animate exactly the same animations at exactly same time - because the whole idea of animobjects is that they animated synced to the actor (f.ex. broom used to sweep the floor, or shackles placed on wrists). This would be further complicated by the fact that the position can keep changing, and some animation can be controlled real time (f.ex. taking control of your arms and moving them around). In practice this would be overly complicated, and basically "last resort" if even that. Early versions of VR patch used a cloned npc to replace the PC, which does show the anim objects (because as far as game is concerned that clone is an npc), and worked perfectly fine if you only want the 3rd person view. Back when I moved to fully use vrik, I cleaned up the final "clone version", and posted it up - and prinyo made a separate topic out of it (to keep it from being mixed up with later versions of vrpatch). That version works independently of vrik, shows the anim objects, and misses any features added since then (including the 1st person view).. but it's probably still functional. I've tried a few other things - setting visibility on anim objects, changing their position, changing their scaling, manipulating them in different ways with nioverride when it became available.. but so far nothing I tried has worked, so my current assumption is the game engine loop is at some point simply hacked to ignore animobjects on player controlled actor. I suppose I should at some point try switching the player control into a different object just to see if that changes anything (I don't think that would be an actually feasible solution - even if it didn't immediately crash the game).

I'm using Creature Framework 1.1.0-pre2A-SE and MoreNastyCritters v12RC10SE, they work fine for me.

... Here.. try extracting this, and replacing the sslActorAliax.pex on the VRpatch Beta8 38 with this file (under scripts subfolder). You may want to first copy the original somewhere safe so you can replace it, although I don't expect anything to break by using this. I have no idea if it fixes things either, though, since I can't test it. sslActorAlias.7z -- edit -- ..at least in theory, if it fixes things, it should fix them in an older save as well if you finish an animation with an npc that has stopped working with SMP collision - on the other hand just switching the NPC to CBPC and back to SMP should do the same thing (I think), so maybe this wasn't the issue to begin with. Either way this should be a fix for potential issues in the code, though.

I don't think I ever actually used SMP mode on NPCs beyond maybe testing it once or twice. I know the smp code took a lot of iterations before it became somewhat stable in VR, so it's possible it's some bug left in SMP itself. VR patch does have one place where it interacts with SMP object directly - if you have not disabled actor scaling in SL settings, then at the start of animation where actors are scaled to match player scale, the SMP item is temporarily removed from npc (because scaling while having that item equiped caused SMP physics to explode). It should be re-equiped after scaling. ... now that I think about it... I didn't do the same when restoring the original scale, which could possibly cause some issues. It's a long shot.. and unfortunately I don't have any way to currently test things, my graphics card stopped working, and I had to put in the old one which isn't powerful enough to even run the VR room, much less Skyrim itself, and it'll be some time before I can get my hands on a new 3080 - I'd intended to upgrade to one of them, but not quite on this kind of schedule. It might make sense though.. if the SMP item ends up wrongly sized for the NPC after running an animation, it's possible it no longer works - although removing and reapplying it should fix the issue in that case. If that doesn't work, then I'm not sure. I can try to throw together a kind of a hotpatch, and you can try if it works for you.

I'm not really sure about it. Maybe it would be possible - like, perhaps using nioverride to transform position of some node, or something similar to that. It really depends on how the viewpoint is actually attached.. and whether it's 'player attached to viewpoint' (in which case moving the interaction point would be difficult) or 'viewpoint attached to player' (in which case it would be more feasible). But as far as I remember, VRIK uses both 1st and 3rd person bodies, I think it might have been by mirroring the 1st person arm position into 3rd person body (the latter being the visible one), I don't think it ever actually alters the 1st person arm positions, and I would think the interaction with objects would be based on that same position - which means even if your body would be racing down the cliff, you would still grab objects based on your viewpoint position. In other words, the body you are seeing, wouldn't be able to f.ex. interact with a door. Also not sure where a drawn weapon would be attached - I would guess on the 1st person arms because those are what vanilla skyrim uses, in which case your weapon wouldn't display at the body's position either. Overall I see a lot of potential issues trying to do it outside VRIK, and implementing it into VRIK would probably be too complicated when it doesn't really match with it's original intent (basically projecting player's body into the VR) - although that's of course up to prog, I'm really just trying to guess/anticipate the response.

That's currently not possible on VRIK and there isn't a simple way I could think of to achieve it with external mod. I'm thinking a lot of people would find the experience to be comparable to 'motion sickness simulator' - turning your head around would cause your viewpoint to swing around behind the actual turning point (which would be attached to avatar's head). It wouldn't feel very natural - although personally I'm almost immune to motion sickness from VR, so it might work fine for me (and anyone else who isn't sensitive to it). In practice though, it would need to be done within VRIK code itself, and I think prog isn't very interested in putting in a '3rd person mode' into VRIK (and before anyone points at the 'selfie mode', that one works differently, and wouldn't help with this). -- edit -- the '3rd person mode' of SLVR is handled purely by VRIK, and took - I think - months to polish into it's current form. It works basically opposite to what you're suggesting here though. SLVR 3rd person mode 'unattaches' the body from player's actual position, and places it where the animation is happening. When player moves around, it constantly recalculates the distance and angle the body needs to be moved and rotated to keep it 'locked in place' relative to world. Doing a 3rd person mode for movement and combat though, would instead require the body to be shown where the player actually is (because you need to be able to interact with objects, and be affected by wall/door collision etc), while casting your viewpoint away from that position. I'm not sure if that's technically possible within the game engine, or if the viewpoint and the location where game thinks the player is, are locked together (and perhaps more importantly, whether the interaction point is locked to match where game engine thinks the controllers are positioned).

Yes, basically what I meant by 'activate' not equaling 'E' key. For the key emulation to work, you need to have the skyrim window active on the PC, even when you play on VR, so that may be the difference (if you jump into steam overlay, you're activating the skyrim window when you do that). Either way, glad to hear it's working, hopefully it'll continue to do so.

; Target actor StatRef = PlayerRef TargetRef = Config.TargetRef EmptyStatToggle = false if (!TargetRef || !TargetRef.Is3DLoaded()) && Config.HasSelectNPC NSMQuestScript nsm = NSMQuestScript.GetInstance() if nsm TargetRef = nsm.NSMActor endIf if TargetRef Config.OnCrossHairRefChange(TargetRef as ObjectReference) Config.SetTargetActor() endIf endIf if TargetRef && TargetRef.Is3DLoaded() TargetName = TargetRef.GetLeveledActorBase().GetName() TargetFlag = OPTION_FLAG_NONE else TargetRef = none TargetName = "$SSL_NoTarget" TargetFlag = OPTION_FLAG_DISABLED Config.TargetRef = none endIf MCM target is selected: - if target has been previously selected, and is still valid, keep that target - if no target, or target is valid, select target held by npc selector - if that target is not valid, clear selected target Based on that, I'd assume if you f.ex. use the NPC selector to select a valid target, it should clear the situation. I'm still not entirely sure what exactly causes the issue in the first place though, there shouldn't be anything wrong in having selected an actor that isn't part of an active scene - for example you should be able to pick any valid NPC in order to change the voice they will be using. -- edit -- Tested, and yes - I can replicate the issue, this is not what is supposed to happen. Also the workaround I suggested earlier seems to work, namely using NPC selector spell to pick one of the actors in active scene seems to fix the issue. It happens in very early stage of loading up the MCM menu, so my guess would be there's some part of the code that assumes (incorrectly) that the selected target must be involved in a scene if a scene is active. If that's the case, it shouldn't be too hard to fix it. -- edit -- Looks like it was kind of a silly problem. When setting up the MCM menu, the code above calls Config.SetTargetActor() which in turn sets the selected target for use with the MCM. One of the side effects of the call is to use the selected-spell on the target to briefly flash it with an effect. However you can't cast that spell while in a menu, so the whole thing hangs and waits for you to exit the menu before going on with the casting. Duh. I set a condition to skip that spell when in menu mode, and it seems to work fine now. I'll just add a hotfix patch to the OP because this isn't enough of a change to warrant a whole new version, but I don't want to make everyone wait until such time when a new version would come out. and, ping - @therick84 ?

E is used to activate things I think, but I don't think that means 'activate' equals 'E' key for purposes of MCM or mods. Rather I think you'd need to specifically be able to emulate press of 'E' key. I assumed VRIK gestures could do that, but I'm not sure - were they limited to just emulating actions rather than keypresses? That sounds curious. I'll see if I have some time this weekend to have a look at that. How is the scene in this example actually started? Matchmaker? Debug spells? Activated by some other mod (f.ex. defeat)? Or does it not make any difference?