Jump to content


  • Content Count

  • Joined

  • Last visited

About lordescobar666

  • Rank
    Senior Member

Recent Profile Visitors

9,383 profile views
  1. Ah, I also had this problem once. As far as I remember I was starting the new scene from the scene end hook of the currently running scene. The problem was that an actor participating in the old scene was also part of the new scene, and the old scene was still considered running until AFTER the scene hook has finished execution. An actor can only be part of at most one active scene so the new scene didn't start. I solved the problem by starting the new scene using a separate thread. This way the script hook could finish execution and the state of the old activity was set to stopped before the new scene was started. You can start a new thread by utilizing Papyrus' event mechanism (each event is started in a new thread). Just replace the code line that starts the new scene with a call to RegisterForSingleUpdate(0.1), and in the OnUpdate() event function you then start the new scene.
  2. Sounds very much like a deadlock situation. It is caused by the way multi-threading is implemented in Papyrus. See here for more background information, the most important thing for you to know are the Rules 1-3 are most probably the reason for your problem. Rule 5 is the reason why it works with logging turned on. Read the rules carefully, and I also advice you to read the full page I linked above. Then try to find the places in your code where above rules apply, and refactor your code at that places to avoid deadlock situations (a deadlock happens when e.g. thread A waits for thread B, and thread B waits for thread A). If you find no way to avoid a deadlock, you can also insert Utility.Wait(0.1) at strategic places (is a good alternative to logging when you want to keep the log file clean) to force rule 5.
  3. Sexlab 1.63 is currently not compatible to Skyrim VR and sksevr. The reason is that it contains two skse plugins (SexlabUtils.dll and PapyrusUtil.dll) that need to be recompiled for sksevr (hoping that they don't add new hooks into the game engine, because then recompiling is not enough). Also Sexlab's version check probably needs to be patched because Skyrim VR reports a different version number than normal Skyrim SE. As others have already said mixing two different skse versions is bound to cause problems. Fetch the newest development snapshot of LOOT which supports Skyrim VR. @Ashal: Where can I get the source code for SexlabUtil and PapyrusUtil so that I can recompile them for Skyrim VR?
  4. Mod Organizer 2.1 was released yesterday, and 2.1.1 just 2 hours ago, it's now way stabler than previous versions so far, but still no Fallout 4 VR support. So took matters in my own hands and implemented a FO4VR plugin for it. I have attached it if you wanna try it. The game_fallout4vr.dll needs to go into the plugins directory, and the loot* files into the loot directory. It works great so far. It automatically updates the correct plugins list, the ini editor has the correct ini files, loot correctly sorts the plugin list, and local saves for profiles are also working. But it's the very first version, so there may be still some bugs (but no severe ones). Also it cannot automatically detect your FO4VR installation, so you need to select "Browse" and go to your FO4VR installation folder. And MO expects a Fallout4VRLauncher.exe in that folder (that's unfortunately hardcoded in MO). So make a copy of your Fallout4VR.exe and name it Fallout4VRLauncher.exe. game_fallout4vr.dll loot_api.dll lootcli.exe
  5. My bad, I got the name wrong. It's called OnItemUnequipped(). It's an event handler offered by the Actor script and the ActiveMagicEffect script.
  6. But whenever an item is unequipped an OnUnequippedItem() Event should be emitted which gives you exactly this information.
  7. I use my Vive with glasses and as long as the frame of your glasses is not too wide it works perfectly. There is no blurriness and also no pressure on the glasses. You only need to be careful when putting the hmd on to not scratch the lenses.
  8. Have I understand it correctly that the only thing F4SE is needed for in Four Play is stripping the involved actors? It should be easy to implement another stripping method that does not require F4SE by using a combination of Actor.UnequipItemSlot() and listening to unequip events to learn what got unequipped. Why is the normal version of Four Play not using this method, is there anything that speaks against it?
  9. It definitely is an ideal that is nearly impossible to achieve with current tools. But we need ideals because they act as goalposts pointing us in the right direction. In retrospect, I should have made it clearer that it is currently an unachievable ideal. If we want to get something going right now, then yes, we need to tread the player as a passive entity. But we should also strive to find ways to allow a more active role over time. i don't like this comparison, but I think this is mostly a matter of personal taste. I am not a fan of VR video porn (or VR videos in general, in my opinion they are not really VR but more of something in-between). They work as long as you have only the role of a voyeur watching other people performing acts, but as soon as there is someone supposedly performing an act on you then the immersion is broken (for me at least). Having someone performing a pre-recorded (or stati cally scripted) act that is supposed to involve two actors and you are supposed to imagine yourself performing the other part just does not work. I suppose a workable way to implement a first VR version of 4play is to spawn an NPC and involve it in the animations on your behalf. That is basically how all ported-from-2d-monitor sex simulations work right now, it's not ideal but kinda works for now and is better than having an NPC that dry humps thin air.
  10. I also wanted to chime in and talk about my experiences. First of all performance is good on my system (HTC Vive, Geforce 980Ti, i7 -4770k) and graphic fidelity is ok for Fallout standards (could be better, but it is only a minor nuisance). The game itself is only a port from a 2d monitor game, which is quite noticeable. There are not much natural interactions like you usually find in made-for-VR games (e.g. in made-for-VR games you usually open a door by pressing down on the door handle and pulling on it like you would in real life, in FO4VR you simply click on the door), a lot of interactions happen in menus (which are mostly the same as in vanilla Fallout) that are projected onto overlays in front of you. But they seem to have spend a lot of time to optimize the placement of the menus, they are easily readable and easy to interact with. It could be more natural but it's not a deal breaker and easy to overlook. There are also some things that are currently simply not working at all like e.g. scopes (playing a sniper in VR is currently impossible, but they promised to fix it at a later time), or need massive improvements like e.g. the DLCs. But nevertheless, I am having a blast playing FO4VR. I would recommend it for anyone who doesn't mind tinkering around and tweaking things. It's a completely different experience which can be hardly described or be shown in a video but needs to be experienced in person. It feels like I AM RIGHT IN THE MIDDLE OF THE FUCKING GAME, and not watching it through a window aka monitor. Now to the very important topic of mods. The game assets, the mod loading mechanism and the related configuration settings are basically identical to vanilla Fallout. This means that mods that simply replace assets, add new assets or scripts, or simply tweak some values should mostly work out-of-the-box (and the ones I tried all did). Mods that tweak the GUI may only partially work or not work at all. Mods that require F4SE are also not working since there is no F4SE for FO4VR yet (And I have the feeling that it will take some time to get it if we get it at all). Mods that interact with the player in form of (third-person) scenes do not work well in VR not only because there is no third-person view but mostly because there is a fundamental difference between how you as the player interact with the game. In vanilla Fallout you are watching the player character from a distance through a window (aka monitor) and controlling it indirectly, and when a scene takes over control you are reduced to a passive viewer role but that's just means you cannot control the player character anymore but continue to watch it from a distance like before. In VR you ARE the player character and you directly control yourself, e.g. when you raise your hand in real life, you are also raising it in game. Someone taking over control does not really work, because they cannot control your real life movements and you get a strange disassociation with your player character (which also can make you sick). As a consequence mods like 4play would require a complete overhaul to make them VR ready. Instead of being a passive observer watching an animation you have limited control over, you need to have an active part in the scene, and the scene needs to dynamically react to your actions. This is also quite noticeable when you compare traditional sex simulations with VR mods (e.g. Illusion games) with made-for-VR sex simulations (like e.g. Virt-a-mate). The first one only lets you watch sex scenes as an observer and you have only indirect control (e.g. to spread the legs of your sexual partner, you press a button and an animation plays) which gets boring fast. The second one gives you an active role and direct control (e.g. to spread the legs you touch them with your hands and simply spread them like in real life) which can make a very intensive and believable experience. Any VR version of 4play needs to acknowledge that you, the player, are a direct participant in the scene (and not via a proxy as in the vanilla game), and needs to dynamically react to your actions and adjust the pace of the scene to your pace. The alternative is to simply reduce the role of the player to a voyeur who can only watch other people/NPCs but never take any active role.
  11. It's not invisible. I suppose that your character's tits are larger than the default CBBE body's, and the piercing is inside them. It's silder set is empty for some reason. I have attached a corrected slider set file as a hotfix, will upload a updated version some time later. LE666 Piercings.7z
  12. Disable Textures (by default by pressing "T") in Bodyslide to see the piercings. In Nifskope just select the piercing shapes and they will be highlighted with a green outline. Try with the newest version (which is currently 3.5). My mod only works with Bodyslide 3.4+. Since we currently don't know how exactly physics work in FO4, it's very difficult.
  13. My mod does not override anything, very unlikely that it is the cause for this. It seems something broke your game, I suggest that you reinstall it.
  14. You need to select a left and a right nipple ring piercing first, then there should be more options.
  15. Did you set some materials for the piercings when you upgraded them? Btw, if you want to make them visible in Bodyslide/Outfitstudio you have to disable textures by clicking into the render window and pressing "t" (sometimes you have to press several times).
  • Create New...