SC2Mapster

Below is the official documentation and an example guide for the new custom observer user interfaces, from Blizzard.

Note: To use the custom UI, create a folder called "Interfaces" within your SC2 user documents folder:

%USERPROFILE%\Documents\StarCraft II\Interfaces

Custom Observer Interfaces

The overall goal of the interface was to increase the visibility of the most important information while removing any extraneous and unnecessary visual clutter that is preventing the viewer/observer from having the most optimal experience. We found that the bottom 1/3 of the screen was more or less “wasted space” that, for the most part, is basically covered up by tournaments or streamers anyway. By allowing the bottom 1/3 of the screen to only display information when there’s something to be displayed in the first-place, we allow a much more unobstructed viewing experience. Additionally, we felt that by allowing a number of elements to be toggled on and off, the viewer/observer can tailor the viewing experience to best-suit their own needs. We also wanted to help smaller, grass-roots tournaments which might not be able to afford external overlay software the ability to display information such as the win-loss count in a best-of series, team logos/player images, player bios and information, or even the logo of their tournament built completely into the interface. While this is only the first push for a more fully-integrated approach, we will be working on additional exciting features to help push the custom observer interface system to the next level.

Finally, we know that for many of you, your primary mode of watching tournaments is through tablets or mobile devices where the resolution may not be the greatest. With this in mind we’ve made sure to make all text and all values much bigger throughout all of our different interface options. We believe that this will allow you to obtain all of the necessary information that you could ever need even on lower stream quality settings.

Interface Choices:

With the release of HoTS, we have created three different choices of Interfaces to choose from based on your own individual needs.

HoTS Launch Event 1v1 Interface (1v1_Launch.sc2interface):

For the HoTS launch event interface, we wanted to try a new approach for displaying what is happening in the game to the viewer/observer. With this in mind we decided to break up the interface to have each player essentially “own” a side of the screen. By allowing this split we feel as though there’s an extremely clear delineation and separation between who is doing what. We feel as though this is an interesting way of presenting the information to the viewer and encourage you to try it out and let us know how you feel about it.

Re-skinned Interface (ReSkin.sc2interface):

While we’re excited to give the community a different way of displaying the information, we understand that it may not be for everyone. The re-skinned interface is the interface which is closest to the normal, default interface. The only changes we have made beyond removing the un-necessary interface elements, has been to re-skin the existing interface and make text larger and easier to read.

Minimal Interface (1v1_Minimal.sc2interface):

Finally, we have a third direction we’re pursuing for our custom observer interface setup. This is what we’re calling our “Super Minimal” interface. A number of changes from the traditional interface are present within this version, and we’d like to explain the decisions that were made with this interface.

• No Minerals or Gas: After viewing countless tournaments, we feel as though there really isn’t any actual need to have the minerals and gas constantly displayed. It may seem very weird at first, but if you think about it, very rarely do the vast majority of players actually look at the minerals and gas. Most of the time we only actually notice it when a caster points it out. Resources can still be brought up by pressing “R” which will bring up the default resources leader panel. We feel as though Supply is the most important information here, which is why we have displayed prominently next to each player’s name.
• No Multiple Select: We feel as though the main time that this is important is when a caster or observer has multiple units selected and we can see that a number of the selected units are very low on health. With unit health bars we feel as though this negates needing to display this information.
• Upgrades not shown: We feel that with the availability of the new Upgrades Panel (G), that displaying this information all of the time is unnecessary and potentially redundant. By removing this information, we are also allowing for the UnitInfoPanel to occupy less screen real-estate and provide a more optimal viewing experience.
• Queued Units not shown: Beside being a bad way to play in general and reinforcing negative habits, we felt as though this provided no benefit to the viewer beyond knowing that a person has additional queued units that won’t be available for use for quite some time. This also helps to save the amount of space that is required for the UnitInfoPanel. We have however displayed both active queues if a production facility with a reactor is producing two units at the same time.
• Leader panels along the bottom-middle: After looking at a number of professional sports casts and analyzing their use of screen real-estate, we noticed that many of these organizations were utilizing the very bottom of the screen to display additional information. While it is still displayed on the screen, we feel that this is a more optimal location which keeps the primary view of the battlefield un-obscured.
• Score “numbers” rather than “pips”: While the score pips present the number of wins in a new and cool way, in order to best utilize space while adhering to the “minimal” theme of this interface, we felt that numbers denoting wins would be the most appropriate for the scores.
• Removing the portrait and abilities command card: We have noticed that the vast majority of tournaments obscure both the portrait panel and unit command card with advertisements or player cameras. With this being the case, we found that there was no need to display this information as it would most likely be covered up.

Again, as was mentioned earlier, this is the first version of a very new way of displaying Starcraft, and may be very different from what you are currently used to. After a number of times watching replays and live games with this interface though, it felt as though this was the correct direction to head. While we may push this direction further, by possibly eliminating more elements and further streamlining the experience, we feel as though this is a great first step towards an optimal viewing experience. We really hope that you try this interface out and let us know what you think about it.

New Features:

Here we have a full breakdown of all of the new features that have been included within the new HoTS Observer Interfaces:

• A: Custom Team Logo toggle (Ctrl + 8/9, Shift + 8/9)
• B: Custom Score toggle (Shift + S. Ctrl + Shift + 5/7 – Best Of 5 or 7. Ctrl + 1-4, Shift + 1-4)
• C: Minerals/Gas toggle (Shift + R)
• D: Observer Shortcuts + Menu + Replay Frame (Shift + O)
• E: Player Bio Frame (Ctrl + Shift + 8/Ctrl + Shift + 9)
• F: Unit Abilities Frame toggle (Ctrl + Shift + A)

Not Pictured:

• Chat Frame Toggle (Ctrl + Shift + C)
• New Units Lost Toggle (Shift + L)

One additional feature that we are adding to all three of the custom observer interfaces is a new “Units Lost” panel. We believe that the current “Units Lost” panel doesn’t provide anywhere near the amount of information that one would need in order to understand what has occurred in the game. If a zerg player has lost 37 units and 3750 resources worth of units…what does that actually mean? Up until now there has been no way to understand exactly what each player has lost, and will look something like this:

As you can see from the image above, we can clearly see every individual unit type that each player has lost, and exactly how many of those units have been lost. As is mentioned above, this is brought up via Shift + L and can be toggled on and off at any point. Moving forward we will be working on additional improvements that should help improve the entire eSports experience for everyone.

Interface Features Breakdown:

*Note: Please note that the 1v1_Launch and 1v1_Minimal interfaces only support 1 person versus 1 other person. If you attempt to load a replay or observe a live game with another configuration, the interface will not function optimally.

**Note: Please note that this feature will function starting with one of our future patches. Currently if you bring it up, it will display the units that each player has rather than those they have lost.

Guide to new Observer Features in Patch 2.0

CORE GAME FEATURES FOR ALL OBSERVERS

Leader Panel

• Structures Tab – (hotkey T): This panel shows the structures owned by each player.
• Upgrades Tab – (hotkey G): This panel shows the upgrades researched by each player. For upgrades that contain more than one level, only the highest level upgrade will be shown.
• Mouse Click Support for Units\Structures\Production Tabs: Clicking on an icon will select and move the camera to that unit. If multiple units of the same type exist, continued clicks will cycle through all units of that type.

Minimap

• Attacked units flash white for Observers: This change makes it easier to notice combat on the minimap and should help observers detect Drops or simultaneous base attacks.
• Nuclear Launches and Nydus Canals create pings for Observers viewing Everyone: This change makes it easier to detect and locate these events when they occur.

Options

• Show Unit Status Bars Option: The pulldown in Gameplay Options Panel has a new entry that only shows Damaged Units (Not at full health, energy, or shields). This helps remove UI clutter when lots of units are on screen and ensures only important information is being displayed.
• Team Colored Life Status Bars Option: A checkbox has been added in the Gamplay Options Panel that will make health bars render using the player’s color. This helps visually identify health bars when lots of units are on screen.
• Observer Interface Option: A pulldown has been added in the Gameplay Options Tab under the User Interface section for selecting which SC2Interface file to use. A SC2Interface file is a mod that will be loaded whenever observing a game or replay. Its primary purpose is to modify layout\asset\gamestrings files in order to make a custom User Interface for observing games. This option will scan the Interfaces folder and let you select which one to use when observing a game.
• Versus Mode Side Toggle: Added a hotkey (Control + X) to flip sides that players appear in various pieces of UI when watching a Versus Mode game (1v1). By default the player with the left most start location will appear on the left in the User Interface. This toggle will affect the Player Name Panel, any Player Stat Panel, the Resource Panel, or any Frame that derives from PlayerFrame

CUSTOM OBSERVER SUPPORT – SC2INTERFACES

SC2Interfaces are an entirely new feature that enables observers to watch the game using a completely custom User Interface. They exist within the Interfaces folder within the respective Documents folder for the logged in player (Next To Saves and Replays). These archives function as a lightweight type of mod capable of adjusting the User Interface for the local player. They don’t modify or change the game in any way for other players.

Creating SC2Interface mods

Here’s a summary of how to access SC2Interface functionality through the Editor:

• Mod documents now have a “type” associated with them (EModType in code), which can be either Interface or Gameplay (i.e. a normal mod). This type is determined automatically by the editor as data is changed, analogous to the melee/custom type for maps.
• The mod type and reasons for it being that type can be seen in the new Mod > Mod Status window (again, similar to Map > Map Status).
• When saving a mod file, if the mod is classified as Interface, then you can optionally choose the SC2Interface extension in the file dialog. You can always use the SC2Mod extension regardless of classification (We don’t want to require SC2Mod files to have actual gameplay data, they could just have assets for example).
• SC2Interface files can be loaded and saved exactly like SC2Mod files.
• If you load an existing SC2Interface file, then add data which causes it to be classified as Gameplay, the next time you save you’ll see a confirmation dialog indicating that the file extension must be changed to SC2Mod, and then a “Save As” dialog (which will only allow SC2Mod).

So if you wanted to make a custom interface from scratch, the steps would be:

1. Use File > New and choose the Mod document type.
2. Add custom layouts, text, and assets as desired, making sure not to change any gameplay data
3. Save the document and choose the SC2Interface extension from the type menu in the file dialog.

Breakdown of SC2Interface mod archives

SC2Interface mods can contain the following files:

• Assets.txt: A file that contains key/value pairs representing paths to asset files included in the SC2Interface archive. This can also be used to override existing entries in currently loaded mods. Any types of custom assets, such as .dds files can be included in the archive and referenced in this file.
• GameStrings.txt: A file that contains key/value pairs for English readable text. This can also be used to override existing entries in currently loaded mods.
• GameStrings_%.txt: A localized text file where % represents any locale that needs localized text support. For example, GameStrings_deDE.txt would be loaded by the German client. This support is included for players who want to make mods that can be distributed to players speaking different languages.
• ObserverVariables.txt:A variables file that can be used to forcibly overwrite any player variables for the duration of the map. These variables will be discarded once the map ends and their values will revert back to the player’s variables. For example this can be used to turn off the “gametooltips” variable while the SC2Interface is loaded so that even a player with their Display Game Tooltips Option turned on will not see game tooltips. Note that there are many variables which don’t support elegantly changing their value at map load time in this way, such as many graphics options. The primary use of this file should be changing various gameplay or User Interface options. It’s also not recommended to change options in the Options Panel while observing a game using a SC2Interface.
• FontStyles.SC2Style:A file that contains entries representing font style data. This can be used to override existing font styles or create new ones to use in the SC2Interface.
• DescIndex.SC2Layout: A file that contains the names of all the various SC2Layout files to load.

Many SC2Layout files can be added to the SC2Interface archive and used to either override existing UI or create entirely new UI.

Putting it all together – HelloWorld.SC2Interface

Assets.txt

I created a few new dds files that I wanted to use to represent workers for each race and dropped them into my SC2Interface archive. This file points to those new dds files.

How it works:

As is mentioned above, in order to use custom artwork within our interface file, we have to do two things. First, we add a line within our Assets.txt file which specifies the name of the asset and how we will be referring to it from within our XML code.

If I have a custom image that I want to use for the “VS” portion of our header, and its file name is “ui_observer_custom_vs.dds”, but I want to refer to it as “header_vs_image”, I would add the following line to the Assets.txt file:

header_vs_image=ui_observer_custom_vs.dds

Second, we then have to import both the assets.txt, and ui_observer_custom_vs.dds files into our interface which is done through the importer module. In order to have the game correctly reference and use the assets.txt file, we must place it into the correct folder structure. After we have imported the Assets.txt file into our interface module, we simply right click on the assets.txt file and choose “Move files”. When the new dialog appears, simply choose “New Path” and enter the following: "Base.SC2Data/GameData"

By adding this line and importing the appropriate files, I can then create an image frame within the interface’s XML referencing the newly added image file:

<Frame type="Image" name="VsPanelBackground">
<Texture val="@header_vs_image"/>
<RenderPriority val="410"/>
<Anchor relative="$parent"/>
</Frame>

By having the “@header_vs_image” value in the tag, we are telling the game to find a value that is referenced within the assets.txt file.

GameStrings.txt

While I did add some new text entries, the primary purpose of this file was to demonstrate and use the newly added data tag support. The Data Tag (<d) can now include any Score value (found in ScoreValue.xml) such as APM, or MineralsCurrent, or UnitsKilledCount. This allows me to dynamically reference any of these values that I want to display to the observer.

There are also a few miscellaneous pieces of data that the Data Tag supports that are wrapped into an attribute called GameValue. The currently supported values are PlayerName, PlayerRace, and MapName.

Any Score attribute (as well as PlayerName and PlayerRace) also needs the Player attribute to let it know which player it’s referencing. This can either be the Id of the player, typically 1 to 15, or the values used to identify them in Versus Mode, called Left or Right.

So the following entry is going to display the APM of the Left player by looking up the APM value from the Score system: UI/Observer/LeftPlayerAPM=APM: <d Player="Left" Score="APM"/>

ObserverVariables.txt

I just threw a few entries in this file for variables that seem to make a better user experience when observing games.

FontStyles.SC2Style

In here I needed to override a few existing styles in order to make them larger. My goal was to make the styles I’m using display well on low quality streams, so I wanted nice big letters.

I also made a few new styles that I’m using in my layout files for new pieces of UI that don’t exist in the normal game.

DescIndex.SC2Layout

I made a bunch of different SC2Layout files to organize things primarily as a convenience so I didn’t have to wade through a single massive file. There aren’t any real syntax restrictions to this, the files can be named and organized in whatever way makes sense to the person making them.

In general for any piece of UI that I was heavily modifying I gave it its own layout file, and then used Observer_GameUI.SC2Layout as a dumping ground for all the miscellaneous pieces that only had a line or two.

Most of the layout files are to move/hide/resize existing pieces of UI. I’m hiding the console, moving the leader panel, enlarging the minimap. Sometimes finding the correct way to do this can be tricky because while the layout file acts as the blueprint for the frame, the code can sometimes dynamically change these values. Sometimes it’s necessary to change the anchoring of a frame if you really don’t’ want it to show up because even if you set it as invisible the code will set it back to visible. It’s not a transparent process and can take a little bit of trial and error to get things correct.

Observer_VersusBarPanel.SC2Layout

This is one of the layout files where I’m adding in brand new UI. One of the new types of frames is called PlayerRaceIconFrame and can be used to show a player specific version of the specified BaseTexture using the player’s race. So by using the dds files I added into my archive, and the entries into the Assets.txt file I can create a frame which shows a custom icon for each player’s worker

<Frame type="PlayerRaceIconFrame" name="RightPlayerWorkerIconFrame">
            <Anchor side="Top" relative="$parent" pos="Min" offset="0"/>
            <Anchor side="Left" relative="$parent" pos="Mid" offset="700"/>
            <Height val="48"/>
            <Width val="48"/>
            <VersusModePlayerSide val="Right"/>
            <BaseTexture val="@UI/Observer/Worker"/>

            <Frame type="Image" name="RaceImage">
                <Anchor relative="$parent"/>
                <IgnoreParentColor val="true"/>
                <TextureType val="Normal"/>
            </Frame>
        </Frame>

Also, while my main bar displays the player’s name, race icon, supply, and worker count, I created an extended bar which shows their APM and resources. This frame can be toggled on or off via Alt+Shift+E and uses the new frame type called ToggleControl. Any time this type of frame receives its shortcut, it will toggle its visibility. This functionality can be used to initially hide a lot of information and bring it up via shortcut key combinations when it’s relevant.

<Frame type="ToggleControl" name="VersusBarPanelExtendedToggleControl">
            <Anchor side="Top" relative="$parent/LeftPlayerRaceIconFrame" pos="Max" offset="0"/>
            <Anchor side="Left" relative="$parent" pos="Min" offset="0"/>
            <Anchor side="Right" relative="$parent" pos="Max" offset="0"/>
            <Height val="28"/>
            <CollapseLayout val="true"/>
            <Shortcut val="Alt+Shift+E"/>
            <AcceptsMouse val="false"/>
            <Visible val="false"/>
        </Frame>

Observer_CustomLeaderPanel

This is another layout where I’m adding in new UI. In this case I’m using new types of frames that allow me to simulate the behavior of the leader panel by using PlayerOwnedUnitsFrame, PlayerProductionFrame, and PlayerUpgradesFrame. I’m also burying each one within a ToggleControl so I can show and hide them when I want.

Overriding existing layouts

Sometimes we’ll want to go ahead and specifically override a piece of the existing UI rather than create brand new frames and brand new UI content. In order to do this we must specifically override the existing UI by including the file=”” parameter at the end of a frame declaration:

<Frame type="Image" name="LeaderPanelPlayerImageTemplate" file="LeaderPanel">

What this is doing is specifying that I want to modify the contents within LeaderPanelPlayerImageTemplate. In order to correctly find the template, we need to specify which layout file the content exists in, and we do this through setting a value within file=”LAYOUTNAME”. Please note that this is only required for modifying the default layouts which are part of the Starcraft 2 interface, and will not be required for modifying your own created layouts.

Templates

One thing that we do regularly is create templates, or, sets of frames that we can efficiently re-use throughout our many interfaces. A template can be anything from a small image, to an entire frame with nested sub-frames contained within it. An example of a template could be the following example used from our launch event interface:

<Frame type="Image" name="ScoreEnabledBackgroundValueTemplate_R">
<Height val="39"/>
<Width val="61"/>
<Unclipped val="true"/>
<RenderPriority val="550"/>
<Texture val="@ui_observer_custom_win_fill_r"/>
<Frame type="Image" name="ScoreEnabledBackgroundValueInnerColor">
<Texture val="@ui_observer_custom_win_overlay_r"/>
<RenderPriority val="555"/>
<Anchor side="Bottom" relative="$parent" pos="Max" offset="1"/>
<Anchor side="Left" relative="$parent" pos="Min" offset="-4"/>
<Unclipped val="true"/>
<IgnoreParentColor val="true"/>
</Frame>
</Frame>

What we are doing here is setting up an element that we will be re-using over and over again – those of you familiar with CSS, think of these like class declarations. The way that they are used is simple – we add a template value to the end of our frame declaration like so:

<Frame type="ToggleControl" name="ScorePanelLeft1">
<CollapseLayout val="true"/>
 <Shortcut val="Control+1"/>
 <Visible val="false"/>
 <Anchor relative="$parent"/>
 <Frame type="PlayerFrame" name="ScoreLeft">
<Anchor side="Top" relative="$parent" pos="Min" offset="-24"/>
<Anchor side="Right" relative="$parent" pos="Mid" offset="-103"/>
<Height val="20"/>
<Width val="450"/>
<VersusModePlayerSide val="Left"/>
<Frame type="Image" name="Score01" template="Observer_Toggle_ScorePanel/ScoreEnabledBackgroundValueTemplate_L">
<Anchor side="Top" relative="$parent" pos="Min" offset="0"/>
<Anchor side="Right" relative="$parent" pos="Max" offset="-7"/>
</Frame>
</Frame>
</Frame>

By adding this to a frame and having the anchor values within it, the only things that we’re modifying in this case is the position of the copy of the template. You can modify all sorts of values and establish all sorts of templates using this type of system effectively.

Anchoring

All of our UI elements are anchored to other UI elements. If you are at all familiar with CSS, this is very similar to relative positioning, where an element (or frame in this case) is relatively positioned based on the position of another element. You have probably seen tags such as this mentioned numerous times throughout this guide:

<Anchor side="Top" relative="$parent" pos="Min" offset="-24"/>

The breakdown of the anchor tag is as follows:

• Side refers to the side of the element that you are anchoring to another element.
• Relative refers to the element that you are basing your anchor off of.
• Pos refers to whether the element being positioned is at the minimum, middle, or maximum of that side. When working with the pos value, the easiest way to think of it is as follows: When working horizontally, min = left-most side and max = right-most side. When working vertically, min = top-most side and max = bottom-most side.
• Offset refers to how far away from that point it is being positioned.

The easiest way to understand this is with a bit more explanation:

In the above example, we have three elements contained as children within a $parent frame – Icon, Icon2, and BackgroundImage – with both Icon and Icon2 being anchored off of BackgroundImage, and BackgroundImage being anchored off of the $parent frame. The anchoring setup for this example would be as follows:

<Frame type=”Image” name=”BackgroundImage”>
	<Anchor side=”Top” relative=”$parent” pos=”Mid” offset=”0”>
	<Anchor side=”Bottom” relative=”$parent” pos=”Mid” offset=”0”>
	<Anchor side=”Left” relative=”$parent” pos=”Mid” offset=”0”>
	<Anchor side=”Right” relative=”$parent” pos=”Mid” offset=”0”>
</Frame>

<Frame type=”Image” name=”Icon”>
	<Anchor side=”Top” relative=”$parent/BackgroundImage” pos=”Max” offset=”0”>
<Anchor side=”Left” relative=”$parent/BackgroundImage” pos=”Min” offset=”0”>
</Frame>

<Frame type=”Image” name=”Icon2”>
	<Anchor side=”Bottom” relative=”$parent/BackgroundImage” pos=”Min” offset=”-10”>
<Anchor side=”Right” relative=”$parent/BackgroundImage” pos=”Max” offset=”10”>
</Frame>

Tips and Tricks

Throughout the process of creating the custom observer interface file, there were a number of tips and tricks that we utilized in order to accomplish some of the things that we’ve done. One of the main tricks that we’ve utilized in the interface has been anchoring frames to collapsible frames. The main limitation with the current collapsible panels system is that you can’t place an already existing panel within a newly created toggle panel, as it would alter the path of the frame, and the game wouldn’t know where to look for it. In order to allow toggling some panels on and off, what we’ve ended up doing is anchoring the frames to a newly created frame. When that newly created frame is toggled on and off, what it’s doing is pushing the existing frame up off of the screen. When it is toggled off, the existing frame is back at its original location. An example of this is our Chat frame:

<Frame type="Frame" name="GameUI/UIContainer/FullscreenUpperContainer" file="GameUI">
<Frame type="MessageDisplay" name="ChatDisplay" template="StandardTemplates/StandardMessageDisplayTemplate">
<Style val="ChatDisplayModified"/>
<Anchor side="Bottom" relative="$parent/ChatToggle/ChatTogglePanel" pos="Min" offset="-380"/>
</Frame>

<!-- Adds a toggle for the game chat panel -->
<Frame type="ToggleControl" name="ChatToggle">
<Anchor side="Bottom" relative="$parent" pos="Max" offset="0"/>
<Height val="5000"/>
<CollapseLayout val="true"/>
<Shortcut val="Control+Shift+C"/>
<Visible val="false"/>
<Frame type="Frame" name="ChatTogglePanel">
<Anchor relative="$parent"/>
            </Frame>
</Frame>
</Frame>

What’s happening here is that we have a toggle control called ChatToggle that was created and placed at the bottom of the FullscreenUpperContainer frame. Its height is 5000px tall, but since it’s a ToggleControl and has its visibility set to “false”, and CollapseLayout val set to “true”, this means that the frame is collapsed by default. As soon as the ChatToggle is toggled, the frame expands to the full 5000px height, which brings the ChatDisplay frame (which has its bottom anchored to the top of the ChatTogglePanel frame) along with it. We used this in an enormous amount of places: Chat display toggle, Resources toggle, Top panel toggle, Bottom toggle, Observer Information toggle, Unit abilities toggle, etc.

Another trick that we used was for the game score panels. In the preliminary version that was created, we made use of the RenderPriority value to have frames displayed on top of other frames. The main idea behind this was to stack the “win amounts” on top of each other in a vertical stack:

This allows us to have one area in the interface that we use for the scores, while rendering the values on top of each other. A code example of this would be as follows:

<Frame type=”Label” name=”WinAmt00_template”>
	<Text val=”0”/>
	<Style val=”@WinTextAmt”/>
	<RenderPriority val=”555”/>
	<Frame type=”Image” name=”Win_Background”>
		<RenderPriority val=”550”/>
		<Texture val=”@Win_Amt_Bg”/>
		<Anchor relative=”$parent”/>
	</Frame>
</Frame>

<Frame type=”Label” name=”WinAmt01_template”>
	<Text val=”1”/>
	<Style val=”@WinTextAmt”/>
	<RenderPriority val=”565”/>
	<Frame type=”Image” name=”Win_Background”>
		<RenderPriority val=”560”/>
		<Texture val=”@Win_Amt_Bg”/>
		<Anchor relative=”$parent”/>
	</Frame>
</Frame>

<Frame type=”Label” name=”WinAmt02_template”>
	<Text val=”2”/>
	<Style val=”@WinTextAmt”/>
	<RenderPriority val=”575”/>
	<Frame type=”Image” name=”Win_Background”>
		<RenderPriority val=”570”/>
		<Texture val=”@Win_Amt_Bg”/>
		<Anchor relative=”$parent”/>
	</Frame>
</Frame>
Etc…

You could then call these win amounts up via a hot-key and a ToggleFrame with the higher win number always appearing over-top of the lower win number. The RenderPriority value functions much like z-index in CSS – with a higher RenderPriority value appearing “over top” of a lower RenderPriority value. Please note that RenderPriority isn’t a global number – frame elements which are part of a different parent will have its own independent RenderPriority information.