Calling all subwindow logic experts

[Thinkcrown]

I've been crafting an extension for a boss bar (think, video game-like large, long boss health bar and name at the bottom of map record windows (windowclass "imagewindow" and "imagepanelwindow")). The main two features is that:

1) The bar and frame both shrink width-wise in response to the window being resized smaller past a certain threshold (I've succeeded at this).

2) The bar drains from the right-to-left proportionally in response to the wound percentage (aka, like a token health bar, but horizontal instead of vertical) (I've also succeeded at this).

Here's a screenshot of the actual working bar:
66548

My problem is that I've only been able to achieve this by faking the bar via individual 1px wide by 18 px tall widgets, with math logic to bring them together (for #1) and to mimic draining (#2) on both the Host side and the Client side--but I fear that if having over 776 (the full width of the bar in pixels if the window is wide enough) individual widgets, if not thrice that much when having three boss bars on screen (for fights involving three bosses instead of just one) will tank performance—something we're all extremely aware of I' sure.

MY QUESTION TO SUBWINDOW XML STRUCTURE LOGIC EXPERTS
Prior to the 776 individual bar slice widgets method (which basically just uses lua, with only a <script> within <windowclass> tags in xml), I had succeeded in using a subwindow xml method to clamp the health bar for the drain via shifting/shrinking the viewport (#2) and shrinking the width by using 776 different FULL health bar bitmaps (so, it swaps bitmaps to the correct width bitmap only when resizing the overall window, meaning performance is only affected during map record resizing) (#1), BUT I FOUND OUT I COULD ONLY GET IT TO WORK ON THE HOST'S SIDE. The bar just wouldn't render on the Client's side.

Am I wrong, and is it therefore actually possible to have a subwindow xml structure function like this for both Host and Client? If not, just how bad is the performance hit for having an additional 776 1px-by-18px widgets on a map record? I'm unsure if the new v5.1.1 damage numbers beside tokens is buggy on its own, or if having all these widgets has been forcing it to not work, because I haven't been seeing damage number animations anymore during tests.

Code for my current (Host-and-client-working, but uses 776 individual widgets present on screen at one time to fake a 776px-wide horizontal health bar) xml code (very simple):

<?xml version="1.0" encoding="iso-8859-1"?>
<root>

<!-- Standard Map -->
<windowclass name="imagewindow" merge="join">
<script file="scripts/widget_center.lua" />
</windowclass>

<!-- Maximized Map -->
<windowclass name="imagepanelwindow" merge="join">
<script file="scripts/widget_center.lua" />
</windowclass>

</root>

My older, but only uses one bitmap at a time for the bar, yet only works on Host-side, subwindow-style xml code (is there a way to get it to work for clients?):

<?xml version="1.0" encoding="iso-8859-1"?>
<root>

<!-- Standard Map -->
<windowclass name="imagewindow" merge="join">
<script file="scripts/widget_center.lua" />
</windowclass>

<!-- Maximized Map -->
<windowclass name="imagepanelwindow" merge="join">
<script file="scripts/widget_center.lua" />
</windowclass>

<!-- Standard Map -->
<windowclass name="imagewindow" merge="join">
<sheetdata>
<subwindow name="boss_bar_viewport">
<!-- <subwindow name="boss_bar_viewport" insertafter="image">-->
<anchored>
<bottom /><left /><width>776</width><height>18</height>
</anchored>
<class>boss_bar_content</class>
<script file="scripts/sibling_control.lua" />
<activate />
<fastinit />
</subwindow>
</sheetdata>
</windowclass>

<windowclass name="boss_bar_content">
<sheetdata>
<genericcontrol name="full_bar_asset">
<anchored>
<top /><left /><width>776</width><height>18</height>
</anchored>
<icon>standard_776</icon>
</genericcontrol>
</sheetdata>
</windowclass>


<!-- Maximized Map -->
<windowclass name="imagepanelwindow" merge="join">
<sheetdata>
<subwindow name="boss_bar_viewport" insertafter="image">
<anchored>
<bottom /><left /><width>776</width><height>18</height>
</anchored>
<class>boss_bar_content</class>
<script file="scripts/sibling_control.lua" />
<activate />
<fastinit />
</subwindow>
</sheetdata>
</windowclass>

</root>

If you have any clarifying questions, please ask. Thank you for your time.

[superteddy57]

You might get better mileage out of the health bar system that we already have and just changing the graphics. 776 is huge and would cause performance impact.

[Thinkcrown]

I agree! Not for lack of trying, I just kept failing to wrap my head around how the normal token version works; kept failing to reproduce it in a way that actually functioned in testing.

At one point I did think, "maybe I could create an invisible token, strapped to -60px above the bottom window edge, and that way I could tether a larger, horizontal version of the token health bar to it". Do you imagine it would be something like that? This line of thinking comes from reading posts that suggested the issues I was having was because what I was trying to accomplish (#1 and #2) couldn't use the built in health bar system because it "only works with tokens" or something like that; that or some API specific-ness.

[Thinkcrown]

Mm, the standard (working) health bar system uses setClip, right? I imagine all my previous attempts to use setClip were being squandered by the xml windowclass—and that I need to ditch windowclasses altogether and somehow attach an … imagecontrol(?) to imagewindows and imagepanelwindows statically, completely programmatically in lua, like…: [something].imagecontrol.addbitmapwidget(“standard_776”); ?