IsharaMeradin

I would recommend using the story manager and use the location change event to trigger your quest when the player changes location after completing the desired quest. However, if you want it to start right away or at the very least when the player leaves the general area, you can use either a single large trigger volume box that covers a large portion of the room where the other quest ends save an edge near the exit, or you can use multiple smaller trigger volume boxes in front of each exit to the room. With the large box, the script would use the OnTriggerLeave event with a condition that it is the player and the desired quest is at the correct stage. With the smaller boxes, the script would use the OnTriggerEnter event with a condition that it is the player and the desired quest is at the correct stage. And in case the area is one that the player can revisit, disable the trigger volume boxes once they have done their thing or use a bool condition alongside the other conditions to cut processing short when the player goes through the trigger volume box additional times. OnActivate is an event on the ObjectReference script as such quests will not receive that event. For a list of events that quests will receive, see the Quest script. Sample script and brief instructions for using OnTriggerEnter: https://ck.uesp.net/wiki/Complete_Example_Scripts#A_Trigger_That_Detects_When_The_Player_Enters

I don't have the game installed any more to look into it. I just figured that once the quest record was open in xEdit that one could edit the script field and delete the entry.

Might be able to use xEdit to remove references to the missing script. That should at least get you to where you could create and compile a brand-new script for the affected record(s).

If you have a quest that handles background stuff and runs for the entire duration of your mod (which may be the entirety of the game), placing the function on a script attached to the quest will allow both the spell's effect and the ability's effect to remotely access the same function. It is easier to go from a specific level (a spell) to a broader level (a quest) than the other way around.

Let's break down the common file types: script files (PSC / PEX): As long as they do not use SSE specific code, could potentially be back ported as-is. texture files (DDS): These would need to be re-compressed into older formats acceptable by the LE game if using a newer compression type. mesh files (NIF): Depending upon the type of mesh in use, there may need to be modifications made to prevent crashing. Thorough testing would be needed to verify whether a particular SSE mesh works properly in LE Plugins (ESM, ESP & ESP flagged as ESM): The 32-bit Creation Kit was not updated to properly support the loading, modification and saving of 64-bit plugins. Nor was the LE game updated to properly support the loading and usage of 64-bit plugins. As such some "conversions" may appear to work. But it is unknown what could have been stripped out during the "conversion" from 64-bit to 32-bit and how it may affect usage of the plugin throughout gameplay. Plugins (ESL): LE has no capacity to load these. The 32-bit Creation Kit has no idea what to do with them. Any such plugin would have to be re-built from scratch as an ESP. Plugins (SKSE DLL): These are dependent upon the version of SKSE they were built with. The LE SKSE and SSE SKSE have different hooks into the game, as such, DLL plugins would need to be re-done with the LE SKSE. The mod you are looking at backporting DAc0da is unable to show a preview of the file contents for some reason. As such, I can only speculate based on its requirements and other described features that attempting to back port would most likely fail. Do note that asset files (meshes, textures, scripts) could potentially be backported with some effort and testing. Plugins, on the other hand, would be better off done as a rebuild from scratch rather than attempting to backport.

Going backwards via "porting" is not recommended. Re-doing the mod from scratch would be the best approach as there are features present in SSE that are not present in LE. Furthermore, an SSE mod might utilize third party utilities that either do not exist for LE or do not have the same functionality as the SSE version.

SKSE provides OnKeyUp and OnKeyDown events on the form script as well as several other key press related functions on the input script. OnKeyUp has a hold time parameter which can be used to achieve long presses. OnKeyDown along with IsKeyPressed can handle modifiers such as shift + e. Such that when shift is pressed and held first, e will do something different when pressed. It's not that these types of things cannot exist, it is more that someone needs to decide that there is a reason for them to exist and develop the scripting to handle it. One should also consider that having papyrus handle the game's input can become problematic. Papyrus processing has its limits. It can easily get delayed or interrupted by something that the game engine believes should be handled first.

The rule of thumb is as follows: Once you've stabilized your mods and established their load order, do not update a single thing. Finish out your playthrough. And only when you are wanting to start a brand-new game, look into updating and changing what mods you use. There are always caveats where certain file types shouldn't affect things. But generally following that "rule", will keep you playing the game more often than playing with mod stability.

My guess is that they deleted the hair meshes that they would never use and now want to remove references to them in the plugin so that they do not attempt to show up in the racemenu. If that is the case, I'd thought that KS hairdo had included the hair name in the NIF and TRI files as well as in the associated plugin records. If that is indeed the case, then deleting those records from the plugin should work (do it in the CK as it will remove any references to the record being deleted from within other records as well.) But if the meshes are gone and now do not have access to those names to get the correct records.... Only way I know is to open each record, see what mesh is being referenced, and checking if it exists or not. None of that is quick.

It depends on what aspect you want to edit. Creation Kit / xEdit would be needed for editing any records within the plugin. NifSkope, possibly Blender or other robust 3D software, and, if lucky, BodySlide would be needed for reshaping any meshes. GIMP or other DDS editing software that uses the correct compression ratios for editing the textures. a surgical overwrite of the mod's provided files with something else. <-- this would need to happen regardless of file source (direct edit or taken from another mod). There is no in-game menu that I am aware of that can edit individual aspects of an NPC. But I also haven't kept up to date on everything made available over the years. So... perhaps more explanation on what you want to do would allow for better detailed responses.

Could you elaborate on what you are asking? There might be a language barrier here. It reads like you are wanting to know if one could use the Creation Kit and other Skyrim specific utilities to modify games that are not Skyrim. If this is what you are asking, some utilities designed for Skyrim can work with other Bethesda titles that use the same underlying game engine. But none of the utilities designed for Skyrim can work with non-Bethesda titles.

Check your keyboard language settings in the OS. Some keyboard languages redefine what the keys do, and the keypress would, in that case, send a different value than expected by the game. Have you tried testing the game by disabling your mod list and trying the game without mods active? That would at least determine if a mod might be the cause or not. If your game is on Steam, you could try verifying the game cache. You are using Vortex so if mod files get changed due to verification, you can always tell Vortex to use the staging file rather than the one in the Data folder. But most mod files shouldn't be touched by the verification process. And you wouldn't need to uninstall Vortex and the mods. Just uninstalling the game and reinstalling it to the same location should work. Just don't open Vortex during that process so it doesn't wipe out any game related file paths. Afterwards, just redeploy the mods in Vortex. There may be other solutions too. Feel free to wait for others to chime in as well.

Of course, it has no issues if you follow the instructions. The INI instructions are littered with "Using too low or too high values may crash the game. Handle them with caution."

Not sure of Bethesda's purpose in selecting 100 as the cap. However, if I recall correctly, the author of the original LE Uncapper mod stated that while they unlocked the ability to have skills go higher than 100 there could be issues arise in game due to the higher values. So... perhaps Bethesda capped the skills at 100 because they knew that the system couldn't handle much higher.

As far as I know, there is no "safe" way to remove information from a save file.