IsharaMeradin

#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.