Problem description:
None yet. I just figured before I go spend a week struggling, I'd come to my fellow byond-ers to get some advice preemptively.

Err, what I'm trying to do is make a HUD that constantly changes on each tic. To simulate on-screen changes, such as time. Of course, since I despise the map-text system, I made my own graphics to be used via screen_loc.

So. . anyone can give me an example to lead me towards the right direction? One thing I've thought of is just having the icon_state's name be effected by a proc. Since my 'numbers' letters all have numerical names for their icon_state, that could work.

Anywho. . Help? I'll post my own failed attempt as it comes. Though I don't even know how to begin, just got an idea of how to take it once Im on the right path.
So, if I'm reading this right, you want to know how other people are handling HUD configurations without using map-text?

I'm working on a non-interface grid system to handle anything I need for that, since map-text still doesn't support clicks yet, plus I can use other things besides letters, as in custom bars, labels, etc.

So far, an earlier version of the code before I had to re-do my computer due to a virus my girlfriend downloaded looks a little like this:

I've been slowly rewritting the whole thing to include pre-caching the images and working on the mathmatics of it all so it's more dynamic and not pre-set as far as height, width, etc. Also been working on the ability to "group" some of the grid or make additional grids on top to create groups that would be specific for things like health bars, labels, etc.

Other than that, I'm mostly using labels, grids, outputs, and the occasional buttons and child panes.
Have you looked at the Stat() proc? If you're looking for a per-tick update to anything player-related, it's best to keep the loops down. Don't want 10 loops running on a player to update something simple. I would honestly just update the hud on a as-needed basis. ie: only update a health bar when health changes. You can make a Damage() and Heal()(or combine the two, allowing negetive values) proc to handle health and then update health bars at the end, based on the player's health.

I'm still raw, would be nice if you could add comments to help me follow along.
The Stat() proc isn't what I'm looking for since it's for the stat panel.

Basically, I'm trying to mimic: Classic GBA side scrollers. Where there's a set time limit, and the time left is displayed on the top right.

I've made level datums to store attributes that denote how much time is left. The plan was to use those vars to affect some like 'HUD Proc' that constantly changes the time until it reaches 0.
In response to Meme01
Unfortunately, I don't have a lot of expendable time to really polish up a library with comments for the grids. Like I said, it's older code and I've been trying to re-write it.

For now, I would suggest working with interface objects like labels, grids, buttons, outputs, etc.
With your current issue for the time limit, just use winset() to display the time limit to a label.
Haven't touched Stat() in a long time, but I'm pretty sure it's not limited to just statpanel commands.
I shall test this theory then.


And no problemo, Maximus.I'll just dissect what you've given me. Ty.
Theoretically you could use Stat() to update different interface objects like grids, labels, etc. but a sufficient loop proc would work enough.
Stat() is pretty much a loop that goes by world.tick_lag to update a stat panel. statpanel() will create the different "tabs" (inventory, stats, commands, etc.)
In response to Maximus_Alex2003
Stat() is a loop based per world.tick_lag. stat() displays a new tab. statpanel() displays things in the most recent stat panel.
Stat() is just a loop and will handle any code within it, but be aware if you want something to happen every tick, Stat() may not do it especially if you have a lot happening in Stat()

This is because the next call to Stat() doesn't happen until the previous call to Stat() finishes, but I'm pretty sure it's limited to AT MOST once per tick, so it shouldn't call any more often than that.