Skyrim Special Edition

File information

Last updated

Original upload

Created by

DaemonPrime

Uploaded by

DaemonPrime

Virus scan

Safe to use

About this mod

A standardized, widget-centric library to ease the programmatic use of Skyrim's user interface(UI) using Papyrus. Allows easy access to arbitrary text and graphics display within the UI. Provides functions to control both library and Skyrim native UI elements. Removes Adobe Flash as a requirement for effective UI modification.

Requirements
Permissions and credits
Changelogs
What?
A standardized, widget-centric library to ease the programmatic use of Skyrim's user interface(UI) using Papyrus. Allows easy access to arbitrary text and graphics display within the UI. Provides functions to control both library and Skyrim native UI elements. Removes Adobe Flash as a requirement for effective UI modification.

How?
Design philosophy
Extend the concept of SkyUI widgets to allow easier incorporation into Skyrim mods. The library is fully functional using only tools freely available to owners of Skyrim Special Edition.

In Game
By itself, the library will produce nothing. It is intended as a support library to allow modders to easily extend their capabilities by bridging some otherwise complex technical gaps.

Load Order
Plugin can be loaded anywhere.

Compatibility
No known compatibility issues.

Why?
Because Skyrim UI mods were HARD! Like really, way way too hard. For a game developer with the right tools and knowledge, they were not that hard, but they were way beyond most modder's technical and/or financial reach (as evidenced by their relative scarcity when this mod was developed). As a modder doing this as a hobby, I wanted an easy way to have fun graphics. When I found none, I set about reverse engineering those few widgets that existed, thinking I could find the pattern to allow myself and the community to easily reuse existing widgets in new projects without Flash. What looked promising at first turned into a very deep rabbit hole. Eventually I came to understand that due to the way Scaleform (Flash) works, reuse of existing SWF files with new graphics was a dead-end as they conflict with each other (I know now it's because they all live in one global namespace).

Since starting down this road, I've learned that SkyUI (and SKSE) did some great things to standardize Skyrim UI access and widgets in particular. There's a fairly robust library in SkyUI that's pretty self-documenting. Unfortunately, it's still a bit esoteric for most and, probably more importantly, dependent on commercial tools. Specifically the SkyUI model requires access to Adobe Flash creation tools which, at the time of this writing, are no longer sold by Adobe nor have been made freely available. I believe this barrier, even more than the complexity, has stunted possible mod developments in this area. You either have to be someone with access to the tool and knowledge enough to use it or engage someone who has those capabilities. This greatly elevates the level of effort to turn a simple idea into a simple mod.

As I began to develop my first public mod, iWant RND Widgets, beyond it's simple beginnings, I found that I wanted to be able to easily add widgets to other things. This seemed doable at first, not easy but doable. I spent quite a bit of time reverse engineering SWF files I'd been granted use of. I was able to change the graphics used and understood the programming well enough to extend the widget file as I saw fit (within limits). Unfortunately, once I built out a second widget mod, iWant Frostfall Widgets, based on the SWF file used in iWant RND Widgets, I hit an unexpected and particularly annoying problem. No matter what alterations I could perform with JPEXS, the two mods interacted with each other even though from all outward appearances they were unique (new filenames, new ActionScript class names, etc.) For example, having the two widgets load, broke shape changing and resizing (functions in the unique class of the widget that extended SkyUI's WidgetBase). This happened with multiple different source widgets. After much head banging, I reached the (possibly wrong) conclusion that the SWF compiling process is embedding data somewhere that JPEXS isn't altering that keeps these two distinct files using common code somewhere.

Undaunted, and now a bit annoyed that the machines were winning, I decided to see what I could do to improve the situation. I hunted down an ancient, still sealed, boxed copy of Adobe Flash Builder 4. Possibly not the best Flash creation tool for the job (it's not, keep reading) but it was available. While waiting for it to arrive I mentally mapped out what a library would need to solve this problem more easily for future modders.

I decided the Flash issue had to go. To deal with it I created 100 uniquely built and compiled SWF files each containing 10 icons with 10 colors. This package would give a future modder in my position plenty of raw material to easily modify with JPEXS. That alone would have probably been enough for a lot of modders, previously stopped in their tracks by Flash, to be able to move forward. I wrote scripts to generate thousands of unique SWFs and a library to manage 100 SkyUI widgets with N number of widgets in each. It was a messy, hacky solution but it was way better than the status quo.

Flash Builder 4 showed up, I installed it and ... promptly learned that it cannot generate half of the data needed for a useful Skyrim SWF. It turns out that it's actually a professional integrated development environment (IDE) for working with ActionScript (the code in Flash files), but it doesn't have the graphics building capabilities necessary to get a useful SWF built. Do your research before clicking "Buy It Now." Back to eBay...

I got very lucky and found a copy of Flash CS4 Professional for sale (woohoo!). This IS the right tool for the job. I then spent a solid two weeks forward and reverse engineering what was going on, eventually teaching myself Flash design and ActionScript in the process. Along the way, I reached that moment of clarity where I finally got it and (mostly) understood what was actually going on. With some actual knowledge and hard earned trial and error experience, I thought I could do better than the original idea.

With a much clearer picture of what was going on, I realized there was a much simpler and more powerful method to get modders access to these features. What I came up with is essentially a simplified and normalized API into ActionScript. You can start putting images from your hard drive on your screen in just a couple of lines of Papyrus. Another line or two and you can place programmaticly generated text. Add a few more lines and you can make some fairly complex things happen. Best of all, everything you need to pay for (Skyrim SE) you already have. Everything else is available for free, namely this mod and GIMP.

When?
The project was originally developed in May 2020.

Potential Improvements
  • Testing! I’ve done a fair amount, but I am one and you are many. Please test and log bugs you find.
  • Feedback! If you let me know what works, what doesn't, and what you wish was there that isn't, there's chance it might get fixed or added. For new features, please try to explain why what's here doesn't do the job. I'm not interested in mapping all of ActionScript to Papyrus but I'm sure there are some cool and useful things that aren't here yet.
  • More library images. These take time to find and make, mostly because I have to be very careful about the licenses involved to ensure I can appropriately distribute this mod for free (in the many senses of that word).
  • More fonts. Like images, the hard part is all the licensing and attribution.
  • Working array transfers to ActionScript. I couldn't get InvokeIntA working even though all the code matched working samples. I gave up and went to a poor man's array (a string that gets broken down in ActionScript). I haven't really profiled how long the context changes from Papyrus to ActionScript actually take, but in principle integer loads should be faster than individual string loads of the same information. As it stands, the string loads are plenty fast enough in all the library exercising I've done.