Levionte

Thanks, but that's a little different. It's not necessarily going to take place directly in front of the player, at least when the script first fires. So, if they were facing the opposite direction and then turned around, the actor would be flying backwards. I need a method to make Actor A face Actor B, regardless of any other factors besides where they are in relation to each other. Also, It's == 1, and I would also suggest IsPlayerTeammate() == True.

Is anyone good at math scripts? I'm having an actor approach the player via a TranslateTo script, but I'm not sure what to put in the Z rotation to make sure they're facing the player as they're coming towards them. I read online that I can calculate it based on their (x,y) positions and finding the tangents, but I haven't done any trigonometry since middle school. This is my best attempt based on random math forums, but there's at least one quadrant off.

First thing is to save the game with the follower installed and immediate reload the save you just made, and see if they talk then. If that works, you need to create a SEQ file in Tes5Edit. If that's not it, the next easiest fix would be to make sure the quest with their dialogue started - either immediately or through whatever means you've setup. Otherwise, it's all about dialogue conditions. The conditions you set need to be fulfilled in order for the dialogue to show up. If you created a new voice type, the actor needs to have it. If they need to be in a faction or not in a faction, make sure they are/aren't. Etc. When I get a line that's not showing up, I just delete the conditions until it shows up, then add them back to isolate the problem.

Yes that's the option. Regarding the head being so far from the rest, it depends. Vanilla assets go down to the bottom and are moved up above when attached to the skeleton. Most mod creators just put the head where it's supposed to be, which causes the type of effect you're seeing when compared to vanilla assets, but looks normal in game. If that's the vanilla head mesh, it probably shouldn't be there. You know, that makes me think this could be a bone-weighting issue. I'm not that familiar with the argonian head, but it also looks like the parts that are missing are the parts that are weighted to the Spine2 bone, while the parts skinned to the head bone are still there. You can't really check nor fix that in Nifskope. If I were you, I'd get export the FaceGeometry from the CK again (ctrl + f4), check in game to make sure there aren't any pieces missing, and then try NifMerge again. If the unedited face has missing pieces too, there's something wrong with the Argonian head mesh and you should replace it (meshes\actors\character\character assets\MaleHeadArgonian.Nif).

That's strange. Assuming you didn't delete part of the mesh, about the only thing I can think of is that some of the faces are backwards. I'm not sure you can fix that outside of a 3d editor. You could try opening the mesh in Nifskope and, under the head mesh, click on the BSLightingShaderProperty. In the block details, scroll down to Shader Flags 2 and check "Double Sided." I don't know if it will look exactly as it's supposed to, but it shouldn't be missing. If that's true then at least you know what the problem is.

When two mods change the same plugin record, that's what's referred to as a "conflict." They'll overwrite each other's changes. Whichever one is loaded last will "win" the conflict and the other will be broken. So, there's a general rule of thumb that you should always try to make as few changes to vanilla assets as you can to avoid these conflicts. It's a little bit different, in this case, because you're making new entries into the quest instead of modifying existing ones. But it's still extremely easy to break things. (Side note: you should run your plugin through Tes5Edit and check for dirty edits.) The follower quest, in particular, is a very popular one to modify. Aside from other custom followers, there's still possible conflicts from follower overhauls like EFF/AFT, and the random "Followers can (eat, get cold, ride horses, etc.)." I know scripting can be a little intimidating at first, but it's pretty easy to copy and paste the scripts from that tutorial. As a middle ground, you could also make your own quest entry but still use the vanilla framework. To still use the vanilla framework, you'd just need to write your scripts exactly as the recruit script, referencing the pDialogueFollower. You'd mostly just need to copy the vanilla scripts. If any of them used GetOwningQuest() (i.e. (GetOwningQuest() as DialogueFollowerScript.SetFollower(akSpeaker)) then you'd need to replace it with pDialogueFollower, just like the recruit script, and add the quest property or it won't compile. Using your own quest should prevent conflicts, even if your scripts still reference the vanilla framework. The only downside is that you don't have control over the follower once they're recruited. You can't change their behavior or replace/modify their AI packages without causing a bunch of conflicts again.

I would typically recommend creating you own quest and scripts. Using the vanilla one can be done, but is likely to cause compatibility issues with other mods. A decent tutorial can be found here. I don't know why your scripts broke, but you should make sure you've extracted the Scripts.rar file, if you haven't. However, to answer your actual question, which dialogue is available is typically determined by conditions. You can't trade with npcs unless they're following you, so the trade dialogue has a condition for (GetInFaction(CurrentFollowerFaction) == 1). When you say that only "Follow me" shows up, I'm going to assume you're talking about the recruit and not follow (as opposed to wait). In which case, it sounds like the option to recruit is showing up as it should, it's just not successfully recruiting them and enabling the other dialogue. As I've previously stated, I recommend making your own quest and scripts as opposed to using the vanilla ones. But if you'd prefer to use the vanilla quest, the recruit script should say: That's the line that goes in the "End:" box. You type it in and click "Compile," or you can edit source (right-click the script) and type it there. If you do edit source, you should see a quest property at the bottom for pDialogueFollower, as you've noted. That property needs to be filled, which can be done by clicking on the "Properties" button and clicking Auto-Fill. If you've copied it, it might be filled already.

Make sure the race it's using is allowed to have dialogue. I don't believe the chicken race is allowed to, by default.

There's no rule that says there can't be mod packs. People combine mods all the time. When I wanted my follower mod to have certain outfits available to them, I asked the people who made those outfits if I could include them. Many of them said yes, some of them didn't, and I respected their decision. I learned how to script in part by downloading mods that did what I wanted to do and recreated their techniques and code. A lot of modders make their source files available so others can see how it works. When I didn't understand something I could just message that person and ask them, and a lot of them would help. And most of the time all they ask in return is that you put their name in your credits section and follow their distribution rules. I would argue the majority of the mods available on the nexus are derivatives of existing work. The key difference is that everyone asked permission. The modding community is built on a foundation of collaboration and respect. Once in awhile you're using a mod created by some video game creator or programmer that's been trained in a thousand languages, I'm sure. But a lot of the time you're using a mod from a guy that lifts boxes in a warehouse for 12 hours a day and watches Gopher's youtube tutorials during his breaks. Once in awhile you'll get an outfit someone actually made from scratch, but most of the time it's just existing pieces that someone mashed together and tweaked - and they can do that because they asked permission. Collaboration and respect. And the moment you break those rules and you steal their work instead of asking for it, you break the foundation of that system and it crumbles. There's no rule that says there can't be mod packs. They're not common because it would quickly turn into an unstable, game-breaking mess. But if you assembled your mods and asked permission from every single person who contributed to that pack, and they all said yes, no one would give you any trouble. But that's not what Mod drop is. Mod drop is specifically designed for people who are not the mod authors to upload other people's work without even asking them, and with no understanding of why that is wrong. Mod drop is designed specifically to exploit the Nexus' inconveniences like copyright and proper crediting to make things more convenient for the user base. And the only way for a mod author to defend their work is to download Mod drop, sign up for their service and sign a EULA forfeiting their rights in hopes of asking them to remove the mod, which they are historically reluctant to do. But where Mod drop is really going to hurt modding is not in the theft of existing mods - you already have those. Even if Elianora takes her mods down, you can still find them on piracy sites, torrent sites, and Mod drop. You don't need to worry about Mod drop destroying the present, but you should be terrified it'll destroy the future. People seem to imply that just because mod authors don't charge money for something that it doesn't have value. They think giving endorsements is meaningless. Even the most popular mods get about a 5% endorsement to unique download rate. You get even less nice comments, suggestions, and bug reports because there's no value in it unless it puts money in someone's pocket. Who cares if no one visits your page, so long as they put a little link in the pile of links on the Mod drop description? What they don't understand is that is all mod authors get in return. For the weeks and months they spent developing their skills during their lunch breaks, the countless hours they spend responding to the same questions that get asked over and over because no one reads the description, to the death threats to them and their family members they get because some Anonymous has different politics than them, all they ask is that you respect their terms. For all the bulls*** that comes along with releasing mods anything to the public, all they ask is the illusion of control over that project which they are letting you use for free. It may be nothing to you, but to them it is literally everything they get in return. And Mod drop takes that away. If Mod drop asked me to make my mods available on their site, I might have said yes. But they didn't. Instead, they asked (paid) Youtubers to upload their favorite mods without permission and with no regard of the implications that has. Personally, I'll keep making mods as long as I enjoy it. But if Mod drop becomes common presence as it's currently constructed, I don't know why I'd release them to the public.

I'd probably use a say script. I believe the vanilla healing spell has a line at the end with a say script you could use as an example if you wanted to see how it's setup. It's how vanilla npcs react to healing spells being cast on them. As far as getting it to trigger, I don't recommend making changes to the healing script or the dialogue branch it refers to for compatibility reasons, but that would be one way to do it. If it were me, I'd probably add some lines to either the actor or the reference alias, like OnItemAdded or OnMagicEffectApply. Another approach might be to create a perk that reacts to spells being cast on them, with a magic effect with a similar script.

They're probably using the same texture set. Change one of them to use its own. If you click on BSLightingShaderProperty and scroll down the block list, you should see which texture set is assigned and be able to change it.

In response to post #56081996. #56082276, #56082736, #56082851, #56104651, #56106911, #56107726, #56108276, #56109611, #56109726, #56109881, #56110486, #56111056, #56112401, #56113291, #56113516 are all replies on the same post. I did not mean my statement as a personal attack, nor was it my intention to offend you. But I stand firmly by my points. And, again, this is something that should be negotiated between the original creator and anyone else who wants to use their assets for whatever reason. I have no interest in trying to dictate the terms anyone else agrees to. If you're permitted to receive donations that's great. But it's at the discretion of everyone who's work you used, just like the rest of us. If they tip you for who you are and what you do, great. That's not what this thread is about. In regards to your personal challenges, I would flip the same question onto you. How long would it take you to build one of those mods from nothing? If you asked the creators how long they worked on those mods, I guarantee they would give you a number much larger than three days. But that's really not the point, either. I never said porting mods isn't a valuable skill. We all have our roles to play and they're all important. But using someone else's assets does not give one ownership of them or their copyright. Once money is involved, that becomes an important distinction.

In response to post #56110791. It is a shame there isn't a more perfect system that would allow the quality of the mod a competitive balance to keep up with those that are more mass-produced. But I can't think of one. I have to agree with Dark0ne's logic that keeping personal preference out of it is probably for the best. Quality is subjective and quantity isn't. For all of its flaws, that makes quantity the more dependable choice of measurement.

In response to post #56081996. #56082276, #56082736, #56082851, #56104651, #56106911, #56107726, #56108276, #56109611, #56109726, #56109881, #56110486 are all replies on the same post. I don't think this is really a problem with the policy. Before you can use someone else's assets or upload their mod in its entirety, you need their permission. If the mod author specifies, during that "transaction" of permissions, a preference regarding donations of any kind, then that preference needs to be honored otherwise you don't have permission. I don't see that anything has changed in that regard. Except, perhaps we all need to review our collaborations when the changes take place to make sure we're all on the same page. However, and with all due respect, porting a mod is "supereasy" compared to making one from scratch. I'm not saying it doesn't take time and some amount of competence to do it, because it does. And I would not necessarily have a problem with someone who ported my mods receiving a profit for their time and energy- which I assume would be negotiated and agreed upon in advance. But, in my experience, porting a mod is absolutely trivial compared to developing one from nothing. And if some creators think that fact is salient to this conversation, I have no issue with that. But, again, that's more relevant to private discussions between collaborators than it is general policy.

The user base is pretty split. If you release a mod for one, you get flooded with requests to release it to the other. The available modding tools, from user-made to the creation kit itself, are all designed to convert from Classic Skyrim to Special Edition but don't support going the other way around. So, if you have even the slightest inclination that you may want to support both at some point or just want to leave the possibility open, you essentially need to make it for the old game and port it across. That is, unless you want to make the mod from scratch twice. RaceMenu not being available for Special Edition is also a big hit. A good chunk of the mods being released lately are simpler mods like character presets and simple followers; both of which historically rely on RaceMenu and Nifmerge - which also isn't available for SE.

(Data\textures\actors\character\FaceGenData\FaceTint\PluginName.ESP\) Replace the one that's in there that was generated when you exported the face geometry (ctrl + f4).

If the mod used assets from any of the Tomb Raider games, then distributing them to people who have not necessarily bought the game is a breach of copyright. For for-profit websites like the Nexus, hosting mods like that is especially bad because they're directly profiting from the "theft." That's one reason why they're so strict on taking them down. In general, though, mod creators take their mods down for all kinds of reasons. In my experience, there are a number of positives to releasing mods: You can't take shortcuts when you release things for others and still expect it to work in a variety of setups. It keeps you in check, and motivates you to make your projects better and more organized. When something is wrong, you get feedback and sometimes useful advice on how to improve things. But the quality of good interactions is matched by the quantity of bad ones. There are a number of downsides to releasing your work in a public space. It's tragically common for the negatives to outweigh the positives, or at least the workload to outweigh the benefits - which are almost entirely sentimental. And the vast majority of people don't acknowledge you at all; just download the mod, disappear, and make you think your mod sucks because only 5% of downloaders endorsed it.

Assuming it is a beard and you don't have some crazy outfit mod that has a beard attached to it, the problem would be in the face geometry mesh. Easiest solution would be to re-export it from the creation kit. Load any mod you have that alters his appearance (if there's multiple pick the one with the highest priority, if there's none just open Skyrim.esm), find the Esbern actor entry and hit ctrl + f4. If that doesn't fix it, we're either back to the crazy-outfit theory, or you have a problem with the skeleton (unlikely) or the beard mesh has a weight-painting issue. It's the same solution for resolving the infamous grey-face bug if you want to look for a more in-depth tutorial, but it's really easy to do. You could also delete the loose, face-geometry file if you can find it. The game would revert to using the one packed in the BSA, which shouldn't be messed up. If either of these options gives you the infamous grey-face bug, then you didn't pick the mod with the highest priority that alters his appearance.

In response to post #54943263. #54946513, #54952193, #54952693, #54954443, #54955813 are all replies on the same post. Speculation aside, I never suggested mod authors "needed" anything from their mod manager. I even listed a few work-arounds I've been using to make things work. And it does work. I never even suggested mod users technically "needed" anything from their mod manager. Modding existed before mod managers and it worked. That doesn't mean the experience isn't objectively better because of it. I'm not saying mod author's won't manage without it. I'm saying that things could be a lot better for the experience of mod creation, and I haven't seen any evidence to suggest that's even been a consideration. And even if the user's experience is all you cared about, given how the line between use and creation has been blurred with people cleaning their own plugins with xEdit, bodyslide mesh creation, etc., I think it deserves at least a little consideration.

As a relatively competent mod user, I have been pretty indifferent towards the NMM vs MO debate. I recognize MO has more features built in, plus it's definitely faster and more responsive. But it wasn't enough to make me switch from NMM until I was in a position of needing to reinstall Skyrim anyway. I did make the switch a few months ago and, having used MO since then, I stand by my original assessment. It's an upgrade, but doesn't offer anything I couldn't do myself with my previous NMM setup and good modding practices. However, as a mod creator, I've found the difference to be gigantic. When I'm making mods, I'm not following good modding practices; it's not practical. I'm dropping things into my data folder manually, then I'm constantly adding, removing, or otherwise tweaking things throughout development. When I am finally in a position to create a mod package, I have to dig through my data folder for things I've put there. And while I try my best to keep things organized, assets are required to be separated by type. My meshes folder has base assets, face geometry stuff, and outfit stuff someone else made that I'm using. Textures are in a similar situation. Animation files, behavior files, FNIS stuff go somewhere else. Sound is split into voice, effects and music files. And don't get me started on the scripts being lumped into the same folder as every other script for the game. There's a lot of stuff to keep track of, sometimes weeks and months after putting them there. Heaven forbid I work on more than one mod at a time. I know not all mods are so encompassing, but for some of us, having everything thrown into one folder I can change on the fly like MO does is a tremendous time-saver when it comes to development. Not to mention trying to create an environment suitable for testing the mod. With NMM, I end up having multiple "mod installations" of a release build and loose files I can still modify. Then I am constantly on the verge of forgetting a file and then having NMM uninstall it and erasing all of my changes for the old version still in the archive. I make this long, and somewhat dramatic, rant because all I hear about is how the new mod manager can serve the average mod user. And that's fair; they're the majority. But mod creators are pretty important to the community, so it'd be nice to make some features for us, too. It's not like MO is the perfect solution. It really is inconvenient to get lip files to generate, scripts to compile, preview things in nifskope, etc.. Can we borrow just a thought or two from the "which data folder is cleanest" debate and spend it on the mod creator's experience?

I'm admittedly a novice when it comes to making player homes, but in my cell I have a small pond that I need to be disabled/enabled when the player pulls/pushes a lever. I can pull the lever and it gets disabled and everything works great. I can pull the lever again and it gets enabled again, no problems. I can leave the cell, but when I try to immediately re-enter it I get a crash 9/10 times. There are quite a few things going on in the cell, but I've narrowed the issue down to the pond water being disabled. If I wait a few minutes before re-entering, it only crashes maybe 1/5 times. If I save the game and reload I can re-enter the cell with the water disabled no problem. And enabling the water doesn't seem to have this issue; it's just the disabling. Has anyone experience anything similar? Are there any work-arounds? Am I just missing something? Any insight would be appreciated.

You set it up just like you would any piece of armor. You made an Armor Addon for each of the pieces (torso, hands, feet), and you assign them to the "armor." SkinNaked is a perfect example of what you want to do. If you're getting armor pieces stacking when they're supposed to replace each other, make sure you're assigning the appropriate Biped Object slots. You'll notice SkinNaked is using the hands and feet slots because it has hands and feet; whereas most armors don't because they're modular.

You could test it by adding them to the faction via console command in game, or changing/removing the condition to see if it shows up. The script would be something like, "FollowerActor.AddToFaction(CurrentFollowerFaction)." Personally, my recruit scripts add the actor to my reference alias, and I assign the alias all the factions I want them to be in in the CK. I believe that's also how the vanilla quest does it.

Your follower is using a custom voice type, right? If you were using a vanilla voice you could just use the vanilla scripts, so I'm assuming that's the case. You shouldn't need to worry about "Double Dialogue Options" as they won't meet the voice type condition from other follower systems, including vanilla. First of all, it doesn't sound like a script issue. If the dialogue appeared and when selected the actor spoke the line but nothing actually happens, then I would suspect the scripts. If you click on the "Recruit" line, she speaks but doesn't actually get recruited, I would suspect the scripts. If the line doesn't show up at all, then it's most likely a problem with the conditions on the dialogue line(s). That's where I'd start. All the faction stuff is nice to be as compatible as possible with other mods that affect followers, but none of it is required in order to work. You set your own conditions on the dialogue to only appear during the circumstances you assign, then you make a recruit script that meets those circumstances so the rest of the commands show up after it runs. The vanilla quest uses factions as a condition, but you could use anything you want. Your recruit script could include a line to set Lydia on fire and only have the trade, follower, etc. lines be available while she runs around screaming, with your dismiss line putting her out and making those lines unavailable again. It'd be weird, but it would work perfectly fine. I personally add custom followers to CurrentFollowerFaction for compatibility reasons. I don't know of any mods that check for the PotentialFollowerFaction, so I don't bother with it.