ID:160276
 
Now, I have always wondered why people preffer to use screen.loc rather than using the BYOND skin interface, since the skin offers the end user a full customisation via an easy drag and drop interface.
For that to work however, it would require grids that do not display the objects name automatically (and best to be put single like a button, without a scrollbar).
I have seen a similar attempt in a game, but never really managed to figure how they suppressed the text output.
The click/drag and drop functionality has to remain fully though.

Advice and help would be most welcome.
Thank you in advance.
Yes, this is a feature I would like as well.

It could be one of many implementations, including a grid without text as suggested in the original post. Were it possible to disable the scroll bar and text display on the grids, we would already have this. I've been unable to do so and suspect that this is a limitation of the current implementation.

My personal preference would be a simple "icon" or "object" control which is actually a screen object represented by its icon (32x32 by default). This would update dynamically and have full verb functionality of any client.screen object.

Either would make it much easier to create highly functional buttons in the 4X skin.

Work involved to bring screen objects into the 4X skin would also help promote another highly sought after control, that being the addition of a second map display.
The way people can accomplish this is by using dummy objects that have no name.
obj
dummy
var/obj/my_parent // This will be a reference to the actual object
name = ""
Click()
if(my_parent)
usr.Click(my_parent) // Translate clicks to the parent.


You'd have to properly set my_parent and define the other mouse operations you want done, but it should be easy enough to make the dummy object identical to the parent in every way except the name value.
In response to Nadrew
Sure, but it's still a dirty inefficient workaround. >_> A parameter for info and grid controls to toggle displaying icons/text would be nice.
In response to Nadrew
Ah, good thinking.

Though I could certainly code this and test it myself, could you answer if doing it that makes it so you can shrink the grid component down to just the size of the icon and not be given a scrollbar?
In response to Geldonyetich
(Yes, it should)
In response to Kaioken
Finally getting around to testing this, the dummy function (or simply setting the object name to "") does indeed work to get an object displayed on a grid all by itself.

Unfortunately, right-click verb functionality is disabled because the verb panel requires a name be set on the object. This is a definite limitation compared to a screen object. Neither would you have any other functionality relying on the name variable, such as the BYOND client describing what your mouse is over.

Some kind of 4.0x skin control that better emulated a screen object would be a nice feature. In the meanwhile, we can at least create grid-based object "buttons" that have (non-verb related) mouse function support. So, while we can't right click them to pull up verb menus, and the user won't have any clues as to what they do other than the icon, we can still Click, DblClick, Click-Drag, ect.
In response to Geldonyetich
Geldonyetich wrote:
Unfortunately, right-click verb functionality is disabled because the verb panel requires a name be set on the object.

Yes, because there is no name to specify to identify the object in the command-line, you can't use it in verbs' arguments and as such.
You can set the atom's name to a non-false/empty value such as " " which will allow it to be used again.

This is a definite limitation compared to a screen object.

You've quite a misconception here. This has nothing to do with screen objects compared to grids, or what not. Atoms work this way anywhere; if you give any atom an empty name, whether you're accessing it from the map, statpanel, or a screen object, you're unable to use it in verbs.

The limitation you could pinpoint would be the fact you have no way to hide atoms' name when they are displayed in statpanels or grids, which is sometimes undesirable.
In response to Kaioken
Kaioken wrote:
Geldonyetich wrote:
This is a definite limitation compared to a screen object.

You've quite a misconception here. This has nothing to do with screen objects compared to grids, or what not. Atoms work this way anywhere; if you give any atom an empty name, whether you're accessing it from the map, statpanel, or a screen object, you're unable to use it in verbs.

The limitation you could pinpoint would be the fact you have no way to hide atoms' name when they are displayed in statpanels or grids, which is sometimes undesirable.

Misconceptions are a part of life, aren't they?

To take what I was saying fully in context, the whole thing that the original poster is pushing for (something we were discussing prior to the post) was some way we could take a fully functional screen object - including right-click functionality - off of the Map where it obscures vision of potential game elements and onto a skin control. Therefore, this is very much a limitation.

The only reason why a name is even involved is because only the complete removal of a name permits an icon to be displayed within a 32x32 pixel grid control properly.

Would some kind of grid control flag that hides the atom's name be enough? Possibly. So also would have a grid control flag that only shows the icon when enabled. It's arguing the other side of the same coin.

This being a game-development suite, it might even be justified to have a robustly-implemented control that only displays an interactive object. However, I leave the details about the preferred solution to those doing the actual work.
In response to Geldonyetich
Geldonyetich wrote:
To take what I was saying fully in context, the whole thing that the original poster is pushing for (at my original encouragement) was some way we could take a fully functional screen object - including right-click functionality - off of the Map where it obscures vision of potential game elements and into another control.
[...]

Hmm? But we can already do this, and the OP is aware of this. He was just looking for a way to hide the name, which Nadrew has provided (although the code will need to be fixed), or am I missing something?
In response to Kaioken
Well, there is the issue that many aspects of functionality, including right-click verb panel functionality, is gone if you hide the name. So the "fully functional screen object" goal of preserving the functionality of a text-less screen object via a grid is not entirely accomplished [via the "dummy object" workaround Nadrew suggested].

Can you design around this? Yes, but this doesn't prevent one from wishing.
In response to Geldonyetich
Geldonyetich wrote:
Well, there is the issue that many aspects of functionality, including right-click verb panel functionality, is gone if you hide the name.

As I've said previously, it isn't gone if you set the name to an invisible character (such as a space) instead, which allows you both perks.
In response to Kaioken
Kaioken wrote:
As I've said previously, it isn't gone if you set the name to an invisible character (such as a space) instead, which allows you both perks.

Ah ha, I must have missed that detail. [Ah, here it is. Mayhap being accused of misconception caused my eye to skip that important detail? ;) ] I'll give it a try.

It seems we're in complete agreement that it's not an ideal workaround, but if an invisible character works this way then at least we're not without recourse [if] our design could absolutely use verb panels.
In response to Geldonyetich
Indeed, we've both agreed a built-in parameter to control this behavior would be most desirable. The dummy blank name atom is just a workaround for what we can presently do.