Deleting hud [fixed]

ID:158702
 
Jul 13 2009, 1:57 pm (Edited on Jul 14 2009, 8:47 am)
ok what i need help with is deleting huds, i've made a proc that makes the huds if a usrs varible is approprate
for example:
proc
        hud_up1(mob/M as mob)
            var/A = new/obj/HUD/Stats/Strength/Button
            var/B = new/obj/HUD/Stats/Defense/Button
            var/C = new/obj/HUD/Stats/Health/Button
            if(hud_up == 1)
                src.client.screen += A
                src.client.screen += B
                src.client.screen += C
            if(hud_up == 0)
                                // Problem starts here... i dont know how to delete the current hud that i had added earlier...
                del(A)
                del(B)
                del(C)


what i want it to do is to delete the huds after i'm done with them so thats why i made the var "hud_up", i've searched everywhere and i couldn't find a way how to do this.. the only things that i found were ways how to make huds not delete them.
Jul 13 2009, 2:39 pm
You would want to save the HUD as a mob var. However, that's a bad design practice, anyway, it should be global (if it's static; if it changes based on traits individual to each client, then never mind, it should be local).

Dynamic HUDs
HUD
     parent_type = /obj //make it act like an obj, but not be located under /obj in the object tree, it makes things cleaner
     New(client/C) //when we're created
          C.screen += src
          C.HUDs    += src //add us to the client's screen and HUD lists

client
     var/list/HUDs //initialize it when you need it

mob/player/Login()
     HUDs = new //initialize the HUDs list
     new /HUD(client) //create a new HUD object with our client as its arg
     ..() //you can't forget the parent
Jul 14 2009, 2:38 am
@Jeff: Not sure what's your point there, since all HUD objects are added to the screen list you can already access them from there, which is how you'd do this.

Xxdragonslxx wrote:
ok what i need help with is deleting huds [...]

What you have in your proc there for removing the HUD, is creating new objs, then deleting them immediately. Of course, that's not going to do much other than waste processing... What you need to remove are the existing objs that were actually previously added to screen. You can either delete them or remove them from the screen list (which would probably cause them to get deleted by the garbage collector anyway in your case) to remove them from display. As I've said above, as they're in that list, you can obviously access them by looping through it. You can use a for() loop through the base HUD type (/obj/HUD or /obj/HUD/Stats) objects in it to catch all the objects and then remove them.
Jul 14 2009, 8:46 am
In response to Jeff8500
thank you very much, i've finally fixed this problem that has been bothering me for weeks.
Jul 14 2009, 2:29 pm
In response to Kaioken
Yeah, but what if some parts of the HUD are necessary? A minimap in another control would be an example.
Jul 14 2009, 11:46 pm (Edited on Jul 15 2009, 3:36 am)
In response to Jeff8500
(Supposedly they'll be in your HUD list as well, seeing as they're part of the HUD? Of course, this list is superfluous either way as I've said. But anyway-)

Jeff8500 wrote:
Yeah, but what if some parts of the HUD are necessary?

Then you'd skip deleting them in your loop, but of course. You could clear only the main map control by checking the screen_loc to see if they're in a different control, though obviously you can skip them with for()'s built-in object filter, since I'd expect only parts of the stats HUD to be under /obj/HUD/Stats, so if you loop through that you won't actually be touching any /obj/HUD/Minimap - or whatever.
EDIT: "typo"
Jul 15 2009, 3:31 am
In response to Kaioken
Eh, I guess this is mostly a matter of extra overhead vs. extra lists. He should probably use whatever suits the game better.
Jul 15 2009, 3:38 am
In response to Jeff8500
Eh, I doubt there's notable incentive to have an extraneous list just so that you don't use the built-in object filter - moreover, most people consistently use the object filter even when they don't need it, for that matter.
Then with keeping an extra list, there's also the matter of extra overhead with creating and maintaining it anyway.