IsharaMeradin

I had to dig into an archived copy of SKSE (as the game is not installed), and you are correct. It is on the ObjectReference script. I guess the wiki needs to be updated to include its presence. Unsure how that works with the backup copy on UESP.

GetName is provided by SKSE and would be an option if SKSE were already being used. GetDisplayName is provided by F4SE and is not an option at all for Skyrim. Hence, its failure.

#1 depends upon the object in question. Some use the actual model, and others use a separate ground or world model. Positioning is handled via an inventory node within the mesh file being used. #2 I have no idea. It has always been suggested to take an existing item that is similar to what you want, duplicate its record, and modify it for your needs.

There is Familiar Faces for LE (32-bit Skyrim). As for SE (64-bit Skyrim), there is an alpha/beta version available for free download on Patreon. I have not used either and so cannot speak to its functionality within either environment.

Backporting of plugins (ESM & ESP) is not supported by Bethesda. Here is a breakdown of the common file types found in SSE in regard to "backporting": 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. Not sure why you want to backport to LE from SE. You would be better off looking for LE mods that do what you want rather than trying to port something designed for a newer release of the same game on an "updated" game engine.

Official support forum for Mod Organizer. Perhaps there are some guides and other forms of assistance that may be of use to you there.

Bethesda added wide screen support. As such any mods prior that utilized their own or other widescreen implementations either need to be updated or utilize a mod that removes Bethesda's wide screen support. Here is one such mod, please note that I have not tested whether it works with SkyUI SAS. But I did find it mentioned within the SkyUI SAS comments as a workable solution. https://www.nexusmods.com/skyrimspecialedition/mods/136793

Look in your Creation Kit ini file and see what folder the CK is set to use for the PSC files. Make sure your PSC files (all of them) are in that folder. That is all I can think of at this point. If all the PSC files are in the correct place and you still cannot compile, I do not know what the issue could be.

For your information I have a mod for both LE and SE that allows one to continuously chop until reaching the character's maximum carry weigh capacity. You're free to look at how the stock script was edited to achieve this result. For LE: https://www.nexusmods.com/skyrim/mods/21132 For SE: https://www.nexusmods.com/skyrimspecialedition/mods/4443

If you run WB as a tool in Vortex, you can still add the bash tags there. You should also be able to look at any plugin with bash tags in the description field and edit the description field of your plugin to be the same way (with relevant tags of course). If you are manually editing the bashed patch to include other records, those plugins will need to be added as master files, but they won't need to have a bash tag added to them. Only reason to add bash tags is to ensure that certain data is carried over into the bashed patch. And if you do add bash tags, the bashed patch will need to be rebuilt to ensure that the tags work correctly and that will wipe any manual edits already done. Consider doing a separate patch for your eight mods and putting bash tags on that patch only. At least this way if the bashed patch doesn't pull it over correctly, you can remove the override records from the bashed patch and let your patch handle the records instead.

The numbers are not random. The first ones that you mention refer to the line number and character position where the 'error' can be located on the mentioned script. The second one, is a record ID number that is incorporated into the topic info script name. Since ReferenceAlias is a stock script, I suspect that you may need to extract the scripts.zip or scripts.rar file (depending on game version). The scripts archive is provided by the Creation Kit rather than the game as PSC files are not used by the game. Without seeing the code being compiled and the actual error result, replies can only be vague at best.

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.