User:Thingy Person

A Technical History of Beyond Skyrim (WIP)

This article outlines some technical aspects of Beyond Skyrim in order to preserve a correct history and debunk some myths.

Heightmap

Beyond Skyrim grew out of a forum thread some weeks after Skyrim's release, urging beginning province mods to avoid some of the mistakes seen in the modding scene for Oblivion. One such alleged mistake was that province mod projects did not collaborate, using custom heightmaps that did not fit together, rendering the mods incompatible. When Tamriel Heightmaps, a common heightmap resource for Oblivion, eventually did appear, it was too late and too unattractive for existing mod teams to consider using it.

Although there is visible land beyond Skyrim's borders, it is only LOD, i.e. low-resolution versions of the land that is visible from a distance but cannot be interacted with; furthermore, it cuts out roughly half of the way into the neighboring provinces and is not accurate to the scale of Tamriel implied by Skyrim's landmass. And thus, the All-Tamriel Heightmap project was started to create lore-friendly and correctly scaled heightmaps for the other provinces that are compatible with Skyrim and with each other. The heightmaps were modeled in World Machine and imported into Skyrim with TESAnnwyn. Eventually these heightmaps would become the collective heightmap for the Beyond Skyrim heightmap, contained in BSTamriel.esm, a master which each project depended on alongside BSAssets.esm.

The original plan was that the heightmaps would be placed into the vanilla worldspace, meaning one could travel out of Skyrim with no load screen. Several issues changed this plan.

• A problem with LOD, caused by difficulties with creating a custom lodsettings/Tamriel.lod file and having it be loaded by the game, jeopardized the prospects of being able to display LOD beyond the limits specified for the vanilla worldspace. Since there were no such difficulties involved with a lodsettings file for a custom worldspace, it was eventually decided to put all the custom provinces into one custom worldspace, separate from the vanilla one.
• The first "worldspace bug", where collision issues occur for actors that are too far east and west of the world origin. Actors - such as NPCs, enemies, and a horse the player is riding - will appear to sink into and pop out of the ground repeatedly. The problem occurs in cells beyond 64 and -64 along the X axis; it does not affect cells far to the north or the south that are within this east-west limit. Because of this, one proposed solution was to divide Tamriel into three world spaces, one of which would have included Morrowind and Black Marsh.
  • Then an ini tweak was found that works around the issue, along with a conjectured technical explanation. With this tweak, the plan for a unified heightmap was back on the table.
• The second "worldspace bug". If the player is beyond 64 or -64 cells, on either axis this time, and is facing away from the world origin, then all gameplay interactions break. Harvestables cannot be picked, doors cannot be opened, attacks will not hit enemies, and so on. This bug was discovered late because it took until someone placed an interactible object outside the safe limit - specifically, a level designer from the Northpoint project placing a flower. There is no known workaround for this one, and as such this bug definitively killed the idea of a large Tamriel worldspace.

Master Limit

This section details how the merging process evolved, and its impact on which master files a project could have as its dependencies.

Before the Creation Kit's release, many small mods were already being made, mostly using a utility called SkyEdit, which was developed by reverse engineering part of the plugin data format used by the engine, and did not allow for any level design. (Contrary to popular belief, Moonpath to Elsweyr is not one of these mods, as it was made using the Creation Kit. See here from the author himself. The first and perhaps only mod that managed to implement new, albeit very crude, level design before the Creation Kit is called Wounded Knee Gulch.)

For the Beyond Skyrim heightmap's development, not even the Creation Kit's release was enough to satisfy all requirements; a worldspace plugin produced by TESAnnwyn cannot be converted to an .esm with the Creation Kit, so the esm flag would have to be set using unofficial tools. In addition, plugin cleaning and merging, essential functionalities in modding including Beyond Skyrim, are tricky to do with the Creation Kit, if not poorly understood at the time.

For these functionalities, another utility called TESVSnip was widely used. However, TESVSnip had a huge problem, in that it used an incorrect compression library and irreversibly damaged many plugins it edited (see e.g. this forum thread). When this came to light, an initiative was mounted to obtain the source code for TES4Edit and update it for Skyrim, resulting in TES5Edit, which finally allowed these operations to be done safely. Another utility called TESVGecko had been in development with many of the same goals, but it was put on hold.

For a long time, however, TES5Edit still did not support editing or merging one kind of data: the VMAD subrecord, which contains information on scripts attached to objects, and their properties. This meant that plugins implementing quest content could not be merged into the master file using TES5Edit, which is a limitation that the Cyrodiil project ran into. At the time, only the Creation Kit's own Version Control system (which had been sufficiently documented by this point) allowed for merging script content, so the Cyrodiil project switched to using this for merging.

However, using Version Control introduced two new issues:

• Version control has a hard-coded limit of two master files. This means that the Creation Kit will refuse to merge plugins into master files that have more than two .esm files as dependencies. This was likely implemented to avoid a situation where a Bethesda employee accidentally loads two DLCs at the same time, which would make one dependent on the other; the two allowed masters would thus be Skyrim.esm and Update.esm.
  • Since this issue more or less coincided with the discovery of the second worldspace bug discussed earlier, it was decided to cut up Tamriel and store the worldspaces into the separate project esm files. This meant that BSTamriel.esm could be left out, and if Update.esm is similarly left out, then the only remaining dependencies are Skyrim.esm and BSAssets.esm, thus staying within the master limit. It is not known what tools were used to do this cutting up, but the process has been redeveloped more recently and is documented here.
  • A knock-on effect was that projects occupying the same worldspace henceforth also needed to have the same master file, as a worldspace cannot be introduced from two masters at the same time. Thus, the BSCyrodiil.esm and BSElsweyr.esm master files, which both used the BSHeartland worldspace contained in BSTamriel.esm, merged into BSHeartland.esm. Similarly, the High Rock and Hammerfell projects merged their masters into BSIliacBay.esm.
  • Another knock-on effect relates to using DLC assets in Beyond Skyrim projects. Since a DLC master file could not be used directly, any desired object forms had to be re-implemented into BSAssets.esm. BSAssets would only include the forms and not the models and textures themselves, so the DLCs were still requirements for running the mod, just not by having the DLC master file as a dependency.
  • In order to avoid a DLC item and its re-implementation showing up as two different kinds of items in the player's inventory, Beyond Skyrim: Bruma ships with a DLC patch .esp that edits instances of re-implemented DLC objects and switches them back to being instances of the originals. Any future Beyond Skyrim release would have needed such a plugin that the end user would then have to add to their load order.
  • Many years later, SSE Creation Kit Fixes implemented a patch that removes the two master limit, and since April 2022, Beyond Skyrim has had DLCs as masters, removing the need for re-implementing DLC records and greatly simplifying this aspect of the project.
• The Creation Kit automatically renames fragments scripts (such as Topic Info Fragments) on merge. Fragment scripts are a special kind of script which is named automatically by the CK, incorporating the FormID of the object it is attached to. Since the FormID changes on merge, the CK will rename the fragment script accordingly. It will do this for the record data in the .esm file, but doesn't take care of renaming the loose .psc script source file, changing its header, and recompiling it. This means that the scripting is broken on merge, as the game will look for a renamed script file that doesn't exist, as the script file still has its old name.
  • The functionality for handling the external files can be restored by installing Perforce (now called Perforce Helix Core), a professional version control software, and hooking it up with the Creation Kit. During the game's development, Bethesda used Perforce for version control, including checking out forms so that only one employee could edit any given form at a time, avoiding conflicts. In Beyond Skyrim, perforce is only used for its specific functionality of renaming and recompiling fragment script files. The process of setting this up is complicated and is documented here. See also this forum thread from when this was discovered.
  • Later on, TES5Edit came to support the VMAD subrecord, making it a viable merging tool for script content. It does not rename the scripts in either the .esm or in the loose script files, meaning the scripts will function, but be "misnamed" with regards to the FormID. This is only a problem in the very unlikely but theoretically possible case where a Topic Info Fragment script from a newer plugin ends up being created with the same name as an existing one from a previous plugin, causing a nasty conflict.
  • Merge Plugins also supported automatic rename and recompile of fragment scripts and was used by one of the projects for merging (see Masterfile Merging with MergePlugins) but this functionality was removed in a later version.

Legendary Edition and Special Edition

When Skyrim Special Edition (abbreviated as SE) released in 2016, it was initially treated as another platform to release on, but development continued on the old version of Skyrim, known as Legendary Edition (LE). This is because converting a mod from LE to SE was a known process, while converting from SE to LE was not, so developing on LE meant that releases could be done on both platforms.

• Note: Legendary Edition was actually a re-release of Skyrim from 2013 with all the DLCs included, but it is nowadays used to refer to that version of Skyrim as a whole. There is no technical difference between having bought Skyrim and its DLCs separately, or having bought Legendary Edition.

Over time, some projects came to have so much content that they ran into memory limitations inherent in LE. While LE's game executable is 32-bit, SE's executable is 64-bit, allowing it to use vastly more memory. Even Beyond Skyrim: Bruma requires the use of SKSE plugins on LE in order to expand the memory limit somewhat and allow the mod to run. The SE version does not require this. Eventually, these projects switched their development to SE, forgoing the possibility of making releases available for LE, while other projects continued on LE.

With some projects on LE and others on SE, this meant that two different versions of BSAssets had to be maintained in parallel. This was a source of much complexity and regularly led to problems where, for example, some assets were not in both repositories, or one of them contained only outdated versions; or a tree mesh was developed for SE, would be back-converted to LE (which is an imperfect process) and then forward-converted to SE again instead of just using the original version, while its tree animation data would also somehow not make it into the .esm.

Eventually, by January 2022, all projects switched their development to SE, even those that had no pressing need to do so. Reasons included a shrinking playerbase on LE; a dearth of new devs who own LE, which had become difficult and extremely expensive to purchase; being able to use SSE CK Fixes, which was developed to address the regressions found in SE's version of the creation kit, but had become significantly better than even the original LE creation kit; and the prospect of being able to deprecate the LE version of BSAssets, as well as developers not having to have LE and SE installed in parallel anymore if they worked on different projects. This step greatly simplified the maintenance of the project.

Stripped Master

The Creation Kit has a limit on how many object references (i.e. in-game placed objects) it can load simultaneously, known as the refr handle limit. Unlike the game itself, the Creation Kit needs every single reference from every loaded file loaded and indexed all at once. At some point, the combined reference counts from BSHeartland.esm as well as Skyrim.esm reached this limit. This meant that level designers would place objects in the CK but these would end up not being saved.

To work around this, developers used a stripped version of Skyrim.esm, where almost the entirety of the vanilla worldspace was removed, thereby bringing the number of loaded references back down.

In 2020, SSE CK Fixes implemented a patch that raises the refr handle limit to double its usual number, meaning the stripped Skyrim.esm was no longer needed. To date, it has not been necessary to go back to the stripped master.

SKSE

SKSE is a resource that expands the capabilities of Skyrim, not only by adding new Papyrus functions that can be used in scripting, but also allowing the loading of .dll files that can apply various engine-level changes that aren't possible with conventional modding.

Beyond Skyrim projects are free to use SKSE, both for development and as an end-user requirement. This section will describe examples of both.

Examples where SKSE is or has been used as an end-user requirement:

• Beyond Skryim: Bruma for LE needs the user to run SKSE for its memory patch, increasing the memory limit from 2GB to 4GB. Otherwise, the player will face an infinite loading screen upon entering Cyrodiil. The SE version does not need SKSE.
  • When it became apparent that SKSE was required to run the mod, developers started using SKSE papyrus script functions for convenience. These instances all ended up being refactored in order to remove the SKSE dependency, in order to be able to release Bruma on Xbox. This is because SKSE cannot be run on Xbox, and it is not strictly needed, since the moddable version of Skryim on Xbox is SE. To date, the Cyrodiil project still avoids end-user dependencies on SKSE.
• Atmora has required SKSE in the past for some purposes that have since been made obsolete.
  • Some kinds of music tracks are pulled from lists which are hard-coded, and as such, multiple mods adding such music are incompatible without a patch. This incompatibility is also true for Beyond Skyrim projects. Atmora had its own way of dealing with this for certain music types, such as combat music, which are specified by the Default Object Manager; using SKSE, the Default Object Manager can be modified, so that it can be made to point to Atmora combat music when the player travels to Atmora, and be reset to its default when the player travels back. However, this does not work for map marker discovery jingles which are hardcoded directly in the game executable and not in the Default Object Manager.
    • The problem of incompatible music has since been solved by basing the edits in BSAssets (see Compatible Implementation of Hard Coded Music Types), and this for all kinds of music, making the SKSE solution obsolete. Since Atmora initially did not use BSAssets, this solution only became possible when it adopted the use of BSAssets in late 2021.
  • In February 2019, Atmora added custom map markers (which are notoriously hard-coded inside the UI files which are in Flash format) by patching them into SkyUI files, and requiring the user to have SkyUI installed, as the build would crash without it. SkyUI in turn requires SKSE. Later on, an alternative approach was developed (documented in Custom Map Marker Implementation where map markers are patched into vanilla interface files instead and hosted in BSAssets, obviating the dependency on SkyUI. That said, BSAssets includes some SkyUI files with permission so that it is automatically compatible with SkyUI.
  • Atmora also anticipated on some features which would be developed later on and which were thought to require SKSE, like spears or Frostfall compatibility, but these also become obsolete due to changing plans or alternative solutions.
• Beyond Skyrim might incorporate changes that trigger extra functionality if SKSE used, but cause no issues otherwise. For example, there is integration with Constructible Object Custom Keyword System and CoMAP.

Examples where SKSE is used for development:

• Fuz Ro D'oh, an SKSE plugin, is indispensable for testing quests. Without it, dialogue which has not yet been voice acted will either go by too fast or too slowly with no way to skip it, and scenes will even stall forever, rending quests unplayable. Since voice lines are presumably voiced for the release, Fuz Ro D'oh will not be an end-user requirement (and silent voice files can still be used for any exceptions).
• Console Command Extender has a Beta Comments functionality that allows a user to point at an object in-game, write a comment about it and export it to a text file. Members who do QA are asked to learn to use this tool.
• More Informative Console gives more information about in-game objects, such as model file path and current AI package.
• Skyrim Ingame Editor allows editing various kinds of data in-game to see the result immediately and save it to a plugin, most notably weathers, which otherwise requires a tedious cycle of adjusting some numbers in the CK or TES5Edit and launching the game to see the result.

Animations

Custom animations have long been possible in Skyrim modding, but under various compromises and degrees of complexity. The greatest source of problems was behaviors; a behavior graph is a file that contains information on which bones (that is, movable parts) a creature has, how they relate to each other, what animations the creature can have, sometimes even the sounds a creature makes, and much more. The file format for behaviors is proprietary and part of the Havok middleware, and there are no official tools available for Skyrim to work with them, meaning it has fallen on the community to try and reverse engineer this very complex kind of data. While editing behaviors has been possible for many years to some extent, creating entirely new ones generally hasn't been until recently.

To add new animations for humanoids, such as new idle animations for the player, mods have generally been able to edit the behavior graph to add these animations and allow for some way to trigger them in-game. If only one mod in a player's load order edits a given behavior, then everything is fine; if multiple mods do this, then the player can run FNIS or Nemesis to automatically generate patched behavior files for compatibility. If Beyond Skyrim were to have custom animations, then FNIS or Nemesis would therefore not be an external dependency unless the player has other mods installed that edit behaviors (in which case they'd likely already be using such tools), and assuming the Beyond Skyrim projects have a way to ensure compatibility between each other.

For a new creature with entirely custom animations, modders have generally edited the behavior of an existing creature and added all the animations of their custom creature to it, while ensuring that the pre-existing creature only uses its own animations and the modded creature uses the custom ones. Conflicts between mods can likewise be patched with FNIS or Nemesis. This approach would be perfectly possible for Beyond Skyrim, but it seems the projects were unwilling to take on the jank of stitching new creatures onto existing ones, and preferred waiting for a solution that involved proper new behaviors.

Note that the problem of custom animations has exceedingly little to do with SKSE, and the ability to have custom animations does not depend on choosing to require SKSE or not. Dynamic Animation Replacer, which released in 2020, uses SKSE to inject animations in-game depending on user-defined conditions, but it functions in a very different way than behaviors do, so a more native solution was still preferred.

Finally, in 2022, bugfixes to ck-cmd and a personal fork of Skyrim Behavior Editor allowed the creation of fully custom behaviors, documented in Implementation of Custom Animations. Besides allowing one to add new creatures natively, it supports implementing new idle animations as new idle markers which level designers are accustomed to work with, including with new AnimObjects (items which NPCs hold in their hands during an animation) which are otherwise hard-coded. Compatibility between Beyond Skyrim projects is ensured by hosting all custom and modified behaviors in BSAssets, as well as the text files animationdatasinglefile.txt and animationsetdatasinglefile.txt which need to contain information on every animation used in the game. Compatibility with external mods can still be ensured on the user's side by running FNIS or Nemesis.