Feature request: Alternative to screen_loc var

ID:135640
 
May 6 2004, 4:20 am
When trying to trim excess atoms from a project, sometimes it would be useful for more than one person to share a single item in their client screens, but in different locations. Currently the only option is to have it in a fixed location or to create duplicate atoms, which is a waste of resources.

How difficult would it be to make client.screen an associated list. The index would be the atom in the screen, so that existing code would require no modification. The associated value would be the custom screen_loc for that particular client. If the associated value is null, the atom's screen_loc will be used. (Again, so that existing code will continue to work without modification.) An associated value of "" would remove the atom from view, overriding the atom's normal screen_loc, but leave it in client.screen for accessibility (like adding an atom with no screen_loc value.)

Example: Each client can add particular actions from a global action list to a shortcut bar in their HUD. The action's position on the shortcut bar determines which function key will activate the action, so each player will likely have different actions in different locations.

The mob/character var "shortcut" is a list of text strings used to reference the action in the global action list.
 
mob/character
    var/list/shortcut[12]
    Login()
        ..()
        for(var/loop = 1 to 12)
            if(shortcut[loop])
                var/atom/movable/action/A = GlobalActionList[shortcut[loop]]
                if(istype(A)) client.screen[A] = "[loop],NORTH+1"
May 6 2004, 6:00 am
Just thought I'd give a bit of support to this request by adding a second oppinion, since it really is a great request. That would be a great feature which would allow for the application of many more code designs which currently are not used because of the heavy computing needed when every player has their own version of an object.
May 6 2004, 7:45 am
Can't you make one atom, and add it to multiple screens?
var/obj/global_screen = new()
client
    New()
        ..()
        screen += global_screen
<dm>


Of course, if you need the object to appear in different locations, then I completely agree as that would require seperate objects.
May 6 2004, 8:21 am
In response to sapphiremagus
sapphiremagus wrote:
Can't you make one atom, and add it to multiple screens?

Yes you can.

Of course, if you need the object to appear in different locations, then I completely agree as that would require seperate objects.

That is what he meant. There are many times when numerous people need the same object in their screens, and some of those times require the objects to be in different places and force us to create many duplicates of the same object.
May 6 2004, 10:07 am
In response to Loduwijk
can't you delete it and make a new one at the new place you want it?
May 6 2004, 10:17 am
In response to DarkCampainger
Creating new ones at new locations, or even moving one, is not the problem. The problem is displaying one atom to two separate people at different screen locations. My original post contains an example illustrating why this feature would be useful.
May 6 2004, 9:05 pm
Shadowdarke wrote:
How difficult would it be to make client.screen an associated list.

At the moment: Somewhat. However I like this idea enough to use it later, so when it's possible to change it, I'll have it in mind.

The index would be the atom in the screen, so that existing code would require no modification. The associated value would be the custom screen_loc for that particular client. If the associated value is null, the atom's screen_loc will be used. (Again, so that existing code will continue to work without modification.) An associated value of "" would remove the atom from view, overriding the atom's normal screen_loc, but leave it in client.screen for accessibility (like adding an atom with no screen_loc value.)

I'd prefer null as the associated value, but really any false value should do.

Lummox JR