Development Design Notes

With the Workshop Framework, I followed a few general guidelines when making decisions.

• Never alter property names or function signatures when altering vanilla scripts.

• • The aim is to make this instantly compatible with all existing mods.

• Prioritize speed over memory usage.

• • You’ll find there are many places I have repeated properties, while this is less memory efficient as you end up with multiple references to the same Form IDs, due to the way Papyrus works, it allows for much faster code and reduces the likelihood of introducing threading issues. See the explanation of Papyrus threading for more details: https://www.creationkit.com/fallout4/index.php?title=Threading_Notes_(Papyrus)
• • Aside from original Xbox players, and minor save file size increase, memory is not a huge issue, and the small sacrifice is necessary in my opinion for a good framework, as you don’t want the framework to be slowing down your code more than is necessary.

• Prefer events and variable modification to script hooks.

• • Because the workshop system is so heavily focused in the WorkshopParent quest, there wasn’t really a sensible way to add hooks for altering the behavior. So instead, I tried to introduce globals to stop existing behavior. This way, your mod can handle that behavior in whatever way it deems appropriate.

• Override Events: The idea is that when certain behavior is stopped in the base game scripts due to settings, a custom event will fire indicating that behavior was overridden. This will give your code an opportunity to introduce alternate behavior for those circumstances.

• • At the time of this writing, there is only one instance of this, but it is likely a system I will expand on. See Assignment Rule Overrides.

• Expose simple functionality via an API, but also allow people who know what they are doing more direct access.

• • The API methods will provide simple streamlined access to commonly needed functions when designing workshop mods. These are done as global functions that can be called without needing any editor properties configured. This will be expanded over time as feedback is received on the framework.
• • For more advanced coders who want more control, the expectation is that you will likely want to bypass the API and call functions directly. The plan is to always support this by never altering signatures or property names once the Framework is live. Instead, if something needs to be altered, a new function or property name will be created and the old one will be pointed to the new. This will not only ensure your code continues to function through changes, but will avoid player saves using the stored version of the functions.