Changing a datums icon_state from "inside" a datum.

ID:1074641
 
Dec 3 2012, 9:56 pm (Edited on Dec 3 2012, 10:03 pm)
(See the best response by Jemai1.)
Code:
combat_obj
    antelope
        shield
            icon = 'ant_shield.dmi'
            icon_state = "4"
            step_size = 16

            New(player/p)
                ..()
                owner.overlays += src
                owner.shield = src

            Del()
                owner.overlays -= src
                owner.shield = null
                world << "delete is being called"
                ..()

            Move()
                ..()

            proc
                refresh_shield()
                    world << "refreshing"
                    icon_state = "[owner.shield_life]" //or shield
                    world << "icon_state = [owner.shield_life]"

                activate()
                    world << "icon_state = [owner.shield_life]"
                    owner.shield_life--
                    refresh_shield()

http://pastebin.com/DaGeiHhN (How new shield is called, if needed...)

Problem description:
How do you change a datums icon_state from INSIDE a datum? My refresh_shield() proc only "flicks" the icon_state for a second, then it goes back to the original default icon_state("4").

Debugging of "icon_state" is outputting correctly. o.O.



Dec 3 2012, 11:16 pm
I fixed the issue with this.

combat_obj
    antelope
        shield
            icon = 'ant_shield.dmi'

            New(player/p)
                ..()
                new_icon_state()

            proc
                new_icon_state()
                    icon_state = "[owner.shield_life]" //or shield

I feel kinda cheap though, it was somewhat of an educated last resort guess. I may delete this thread in the morning. Though I wouldn't mind an explanation as to why setting a datum's icon_state at compile_time would cause this type of behavior.
Dec 4 2012, 1:30 am
Best response
When you put an object as an overlay, you are not placing the actual object but merely a snapshot of it. You cannot modify overlays directly. What you can do is remove the snapshot, update the object, then attach the object's new snapshot in the overlays.

In short, even if you change the object, the snapshot stored in the overlays won't be affected.
Dec 4 2012, 5:47 am
 
            proc
                refresh_shield()
                    world << "refreshing"
                    owner.overlays += src
                    icon_state = "[owner.shield_life]" //or shield
                    owner.overlays -=src
                    world << "icon_state = [owner.shield_life]"


But even that on the original version made no difference.
1.removes the image. -> 2. updates object. -> 3. attachs new image.
Dec 4 2012, 5:56 am
Don't overlays match the icon state of the object they are attached to, and/or their direction?

It would be a little hacky/crazy but if I remember this correctly, you could have icon states in the player's icon that correspond to shield health.

So what I mean is, imagine your shield's life can be a value from 1 to 4. You would have four identical player icon states with the state names "shield1" through "shield4". The shield itself would have the same state names, but of course different graphics to show how broken it is.

Like I said this is a total hack, and it would basically require that you either have only one player icon state, or you multiply for every state per object. If you needed a player icon with 3 different states, a shield icon with 4, an armor icon with 4, and a weapon icon with 4, each object would need 192 icon states with stupid names like "player1shield1armor1weapon1." At that point you might as well just re-create the overlays as needed :D
Dec 4 2012, 5:58 am
In response to Hulio-G
Hulio-G wrote:
>           proc
>               refresh_shield()
>                   world << "refreshing"
>                   owner.overlays += src
>                   icon_state = "[owner.shield_life]" //or shield
>                   owner.overlays -=src
>                   world << "icon_state = [owner.shield_life]"
>


You reversed the order here. First you remove src from the overlays, then change icon state, then add it back.
Dec 4 2012, 9:16 am
My fault with the bad order, typo. I'll update/edit that. Same result though. ;/

I honestly just wanted an explanation for why my original method didn't work. For now I'm left to conclude that you cant permanently change built-in datum var attributes at run time. Or something similar to that feeling. I don't like doing things with just pure intuition, but i guess that's how you've got to get the job done sometimes, heh.
Dec 4 2012, 9:27 am
In response to Hulio-G
Your topic's title makes no sense, by the way. There's no "inside" of datums. There's only src and any object you have a reference to.
Dec 4 2012, 9:42 am
In response to Hulio-G
Hulio-G wrote:

For now I'm left to conclude that you cant permanently change built-in datum var attributes at run time.

What makes you think that? Most (all?) built-in variables can be changed during run-time... as you said yourself, the icon_state variable appeared to be correct when you put in those debug messages.

The problem is that your overlay isn't a copy of the object itself, nor is it a reference to the object. It is a snapshot of the object - basically just the image that it was displaying at the time you added it to the overlays list.

So, you corrected the order and it still didn't work? My guess is that perhaps the original overlay isn't being removed? Try sleeping the refresh proc after the overlays-=src line, to make sure that the shield actually disappears...