Always Visible Images in Feature Requests

ID:115239
 
Jun 30 2011, 1:56 pm
Applies to:DM Language
Status: Open
Issue hasn't been assigned a status value.
A way to give images a variable that makes them visible to everybody without having to add or remove visibility would be nice.

Images are good to use as a substitute for overlays that change a lot.

Something like a health bar has to either use overlays and be removed and added when it changes, or use an image that has to be shown to certain players and/or removed when required.
#1 Jun 30 2011, 3:13 pm
Maybe you can keep a list of clients and just output the image to them? You can also output the image to every client that logs in if they weren't in the list.
#2 Jun 30 2011, 6:07 pm
ExPixel wrote:
Maybe you can keep a list of clients and just output the image to them? You can also output the image to every client that logs in if they weren't in the list.

That is a solution. The current solution I use is create (if it's not already created) and display the image when you select a mob.

The problem with keeping a list, though, is we're talking hundreds and hundreds of static mobs and probably thousands of non-static mobs.
#3 Jun 30 2011, 6:09 pm
Aaiko wrote:
ExPixel wrote:
Maybe you can keep a list of clients and just output the image to them? You can also output the image to every client that logs in if they weren't in the list.
That is a solution. The current solution I use is create (if it's not already created) and display the image when you select a mob.
The problem with keeping a list, though, is we're talking hundreds and hundreds of static mobs and probably thousands of non-static mobs.

Then I suggest you just use overlays to do the job...work with what you got.
#4 Jun 30 2011, 6:13 pm
ExPixel wrote:
Then I suggest you just use overlays to do the job...work with what you got.

Overlays have to be removed and re-added when the image/icon changes. So images are more useful with something like a health bar, since you can just change the icon_state and be done with it.

I'm not looking for a solution. I have plenty of solutions and ways to work with what there already is. Just making a feature request of something that would be nice to have.
#5 Jun 30 2011, 6:14 pm
Aaiko wrote:
ExPixel wrote:
Then I suggest you just use overlays to do the job...work with what you got.
Overlays have to be removed and re-added when the image/icon changes. So images are more useful with something like a health bar, since you can just change the icon_state and be done with it.
I'm not looking for a solution. I have plenty of solutions and ways to work with what there already is. Just making a feature request of something that would be nice to have.


I doubt this is gonna happen very quickly though...
#6 Jun 30 2011, 6:16 pm
ExPixel wrote:
I doubt this is gonna happen very quickly though...

I doubt it as well, but there's no harm in making the feature request. It wont be done at all if nobody requests it.
#7 Jul 12 2011, 2:27 am
I'd be perfectly okay with the over/underlays system being completely replaced by visible-to-all /image objects. However, backwards-compatibility is an issue, as well as whatever reason anyone else can provide.
#8 Jul 15 2011, 12:58 pm
Aaiko wrote:
I'm not looking for a solution. I have plenty of solutions and ways to work with what there already is. Just making a feature request of something that would be nice to have.

The problem is that people may read this feature request and not have a solution. Listing solutions for each feature request can be very helpful, especially when you consider the likelihood of all requested features being implemented.

My Handy Stuff library has an /Overlay object that makes it easier to manipulate overlays. You can do stuff like this:

mob
    var
        Overlay/armor_overlay
    
    New()
        ..()
        armor_overlay = new(src, 'armor.dmi')
    
    proc
        equip_armor(obj/o)
            // updates the overlay to match the armor you're equipping
            armor_overlay.IconState(o.icon_state)


What would seem to make the most sense is to allow overlays to be modified (and have the changes take effect) even after the overlay has been attached to an object. I figure there's some complication that makes this hard to implement, otherwise they'd have made it work that way initially (or so I'd hope).