Jump to content

Seijin8

Supporter
  • Content Count

    1,771
  • Joined

  • Last visited

1 Follower

About Seijin8

  • Rank
    Mega Poster
  • Birthday 08/02/1974

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Not strictly relevant to tags, but people might not know: When Sexlab is told to use a bed it consults a set of formlists. One is a list of all known bed types (so it doesn't mistake a poorly modded chair for a bed). If it finds an object on this list, it then checks against the other two formlists. One is a list of "bedroll" style beds (meaning basically on the ground), and the other is a list of double beds. It then makes a height adjustment based on the subtype of bed to try to get actors properly aligned to it. Point being that Sexlab innately differentiates between these (when it has the bed in the bed list; modded beds need to be added to it), but doesn't do so based on tags. Sadly, in the last test I did with it, the bed search doesn't seem to check if the bed is enabled or not, so you may get some oddities with Hearthfire homes and movable/toggleable furniture. In short, it still "sees" a disabled bed.
  2. If it is about the extra scars and such, those are from BI Phenotypes. https://www.nexusmods.com/skyrim/mods/31954
  3. Assuming you are asking about the textures, they are Leyenda skin.
  4. Those are all missing reference scripts. You need to put those into the Data\Scripts\Source directory as well. Looks like SKSE and PapyrusUtil scripts at minimum. The game likely runs fine because it has all of the pex files.
  5. Number of "mods" in the sense of plugins doesn't really matter. 250 armor mods won't crash your game. The issue is that you have very many scripted mods. Whatever BDDIGI is, it seems to be busy right before the stack dumps start. That doesn't mean BDDIGI is at fault, though. You could try running a save game script cleaner (like Fallrim tools) to clean it out and see if that helps.
  6. The UVs are misaligned. EDIT: I should specify: the textures you are using on the feet are made for a different set of UVs.
  7. There are lots of those. You will need to be more specific. Nightasy has a few, Arsenic has a few (I think). Can you give any specifics?
  8. Fix what? The textures on the feet? If it isn't that, then what end result are you looking for?
  9. Negative - this is coming from your install, not your saves. In the case of MO2, this would be things on the left pane that are activated while their corresponding esps in the right pane are not. Either that or a patch of some type being activated in left pane while the mod it is meant to patch is no longer present.
  10. Are you using SKSE memory patch? What about ENBoost? Then you have the wrong scripts loaded for the game you are running (maybe leftovers or something loading through virtual that should be removed?)
  11. In a lot of cases, if a mod is generating issues it is due to a bad interaction, and not because it is a bad mod. The important piece of data here is that if you install a bunch of mods all at once, you can have no idea what is interacting badly. When you uninstall a mod, you have to clean the scripts properly to get it back into a working state, and in many cases must remove/reset the objects that carried the scripts if they are still present. A lot of what is in your papyrus logs indicates script instances that no longer fit the game conditions and cannot operate correctly in that state. The mental image here is putting out a fire and expecting everything that was burning to return to pre-burnt condition. Negative. You will need to reset/restart most things, and doing that with a save that is already having disastrous issues behind the scenes is asking too much. The logs show literal hundreds of objects in your save state that are no longer carrying valid script data and are failing.
  12. Fact: You aren't going to get users or animators to reliably create the tags that trigger your mod correctly. Suggest whatever you want to, but if you need these to be set up correctly, then do it yourself. Create a script that adds the needed tags to the animations. If it is simplified enough, it could do so before calling the sex animation to start. If that is too much workload for the situation, then it could be done through an MCM button or whenever the Sexlab registry resets. If you can convince all the animators to do that, then you're a miracle worker. Sexlab adds nothing by default. It does not create or auto-assign tags. If you create a system that adds the tags you need, you could have it draw from an outside json (same system that SLATE uses) so that you wouldn't even have to do much work to fill the list. Let your users do it and collate the results. FGew of them will mess with scripting, no matter how easily it is laid out, but anyone can edit a json file. Hell, you could even make a json read system that draws from a bunch of folders, so you wouldn't even have to open the jsons yourself, just script the system to look them up and find the first instance of the animation you need, checking through sub-folders (\User1, \User2, \User3, etc) until success or failure. When a user says "hey I did a few of these", just dump their json into a subfolder and you're basically done. You could make an in-game spell that then collates all subfolder sets into a single full list and do weekly/daily/whatever updates of that one file.
  13. An animator or user can add whatever tags they like and basically make them up on the spot. Creating new tags is trivial. You can add a tag directly to the SLAL json to get it into the system or use SLATE in a similar way. I think what MMG is trying to do is figure out which tags actually matter to mods/Sexlab/scripting and then refine the use cases for those in the hopes that animators will choose sensible tags to smooth the whole process. Sadly, most animators don't tag their animations very well, and the lack of standardization makes it challenging to do so without knowing that you might be messing up another mod's use of it. Great example: "Kissing" is a tag that some foreplay events reach for. Animators tend to use the "kissing" tag on any animation that includes kissing of any kind. Many of those are not appropriate foreplay animations at all. So the lack of consensus on what "kissing" should mean (just a chaste kiss which makes sense fully clothed and in public, vs a gangbang animation that starts with some kissing) makes mods that use that tag highly unpredictable in their behaviors. Neither the mod-maker nor the animator are at fault for the odd results, but nobody agreed on what "Kissing" should mean as a tag. (Best use case for that example: a mod looking for a kissing foreplay event should be searching for "Foreplay, LeadIn, Kissing", and have an explicit animation in mind as a fallback if the search returns none. Sadly, lots of people might make such animations, but tag them only as kissing, or only as foreplay, and not use LeadIn at all for what it was designed for.)
  14. The tag usefulness then depends on whether the animation has its own animobject or is expected to be "placed" on specifc furniture. This gets complicated as there are a few completely incompatible ways to handle it. For instance: with Billyy's Invisible Furniture animations, his intent was that you walk up to the furniture, then trigger the animation and it should be close to the correct alignment. If it is a chair animation however, you now have an issue as the "correct" chair positioning if using a placement method (Sexlab's "CenterOn" using the chair) now has the animation rotated 180°. Basically, very very few of the chair animations will work with one another - you need a specific triggering mechanism for animations that have their own furniture (so that they don't create odd overlaps and collission issues with actual in-game furniture), those that have no animobject but are expected to be on something (Sexlab's CenterOn placement), and those where the author intended freeform use (Billyy's "walk-up" method). Depends on how the animation was tagged and how the foreplay animations was triggered. Without LeadIn, some animations will still produce cum effects. Really, that who subsystem is half-baked. The way it is intended to work needs to be triggered *as* foreplay, with the "foreplay" tag and then the "LeadIn" tag tells it to ignore vaginal/anal/oral for tag delivery. SLAL setups do bypass this, but when the system was set up, SLAL wasn't a thing. Not that I am recalling, but I'm far from an expert on that. EDIT: Scratch that... "Furniture" is used by SL to exclude "Bed" and "BedOnly" tags. I'm pretty sure if you make a bed animation that has the "furniture" tag, SL will commit seppuku.
×
×
  • Create New...