ID:1704299
 
BYOND Version:507
Operating System:Windows 7 Home Basic
Web Browser:Chrome 38.0.2125.104
Applies to:Webclient
Status: Open

Issue hasn't been assigned a status value.
You can't disable the webclient d-pad. I strongly dislike it. If users want to add mobile support, they should do it on their own with on-screen objects that read the mouse input.

1. The d-pad is ugly.

2. The d-pad doesn't go away.

3. The d-pad covers a part of your game's screen, and because it is impossible to hide, makes many games more difficult to play.

4. The d-pad will show up even when the user isn't playing on mobile, which completely ruins its purpose and just makes it get in the way of comfortable play.

5. In games using something like forum_account's keyboard libary, the d-pad doesn't even show any accurate macros and as far as I know, the developer has no control over what keys are displayed.

6. The d-pad locks the developer's game down into being a "BYOND" game. No other game development engine has a required and immutable part of the interface. A required and immutable part of the interface that doesn't even serve any utility.

Personally, I'd like the feature to be removed entirely. If that's not an option, then I'd like it to be disabled via a checkbox in the hub settings. I don't have the source to games like footrace.
But tell us what you don't like about the d-pad!
The D-pad is always present because there's no way to detect whether a user has no native keyboard. The goal was to provide something that would make most games playable out of the box on mobile. I'm really wide open to suggestions though.
but the d-pad is classic
To expand a little further, my thinking with the D-pad was to provide some kind of easily accessible control that could replace the keyboard for users who don't have them. So many games rely on keyboard movement and have no recourse.

The dpad is easily possible to leave out if you use a custom .dms skin. It only inserts itself when the default skin is used, or if the game has a translated skin. (Also I should note, Yut Put, I actually plan to give it a WASD-friendly mode.) One thing I can do that would also help mitigate any issues would be to give it an is-visible setting that can simply hide the d-pad but keep its internal child container intact, although that won't help with games you don't have the source for.

FA's macro library has been a consideration, one I haven't figured out how I want to tackle yet. In those cases, the control's reading of the macros is going to be entirely useless because they're all up/down commands. It seems like the only way for the D-pad to be of use there would be for the game to provide it some kind of list of options, or for the user to be able to configure it and have that configuration stick across sessions with the same game.

As I said, I really welcome any suggestions that would make this control work better across the board. Right now it makes some games playable that were not before, and IMO the screen real estate it uses for others it doesn't help is fairly small.
In response to Lummox JR
Lummox JR wrote:
FA's macro library has been a consideration, one I haven't figured out how I want to tackle yet. In those cases, the control's reading of the macros is going to be entirely useless because they're all up/down commands.
Just a quick thought: what if macros could be set for key combinations? If the goal is to achieve diagonal movement when holding down two movement keys, I think it could make sense:

To move northeast:
1. Press the right arrow key -> "east" macro fired continuously -> you move east
2. Press the north arrow key -> "north+east" macro fired, "east" macro ends -> you move northeast
3. If you release the right arrow key, now only the "north" macro should be firing -> you move north.
macro
north+rep return ".north"
east+rep return ".east"
north+east+rep return ".northeast"
In response to Kaiochao
Our macro setup really doesn't understand the notion of multiple keys very well, but combining multiple commands into a single button probably has more applicability. For example, a lot of games use up/down macros on the cardinal directions and expect users to hold down two keys at once for diagonal movement.

I played with this concept a little and got it partially working, but it didn't always respond to releases correctly.
Handling this via a hub setting might be problematic but could be doable. I just kind of hate to foist more options onto the site that ought to be handled by the game itself.
Would it be possible to just add a 'hide' button to the d-pad itself? Not ideal, but it would allow people to get rid of it on games where sources aren't available. Something that would shrink it down to a small little tab on the side, allowing players to bring it back if they want. I haven't really had time to do much in the last week or two, so I haven't even seen the d-pad yet.
It starts out fairly minimal when collapsed, but I could probably shrink that further.
IMO probably the best thing would be to have a header or something equally unobtrusive and have the ability to minimize the option there.
Well, this is just part of the standard skin, but also keep in mind that most of the time this will be trivial to disable-- it's just that your case is kind of weird since you don't have the source. I guess one option would be to have it off by default in the default skin and let people add it in if they want. But I'm sure there's also a way to keep it completely out of the way by default. Maybe it should be a movable popup?
Instead of having the D-Pad a part of the webclient's interface(as it just appears to act like a child control and moves the splitter over when you expand/contract); couldn't you make it a separate part of the webclient, like a control panel at the bottom, that extends out of the main webclient window?

[EDIT:]

The red box marking where(ideally, for me anyway), where the d-pad expand button should move to and the blue box marking the expansion. This way the d-pad doesn't interfere at all with the game, but I am rather tired now and could have made this entire post out of that.
Making the D-pad itself work outside of the iframe really wouldn't be practical; unlike the maximize button which is fairly simple, the D-pad needs to be able to communicate with the webclient on a deeper level. Making the expand/collapse part work outside of the iframe would be more feasible.

All things considered, one thing I don't like about my initial D-pad design is its reliance on the child control; I'd prefer to simply let it handle everything itself, and maybe even do split controls and possibly translucent hovering as has been suggested. Some kind of persistent options for it would be nice.
We are going to need to have a header bar with some client-specific options (such as popout to fullscreen, icon size, and rendering mode), so I think the logical thing to do would be to simply put the d-pad popout in there. This will still be a part of the webclient frame.
In response to Lummox JR
Lummox JR wrote:
The D-pad is always present because there's no way to detect whether a user has no native keyboard.

Aren't you using HTML5? Plently of ways to detect a mobile device.

That said you can't detect a "keyboard" or not, you could try watching for keyDown or Up I suppose.. not full proof..

I haven't touched the client so I have absolutely no idea, I was under the assumption devs can inject JS anyway?
I've been looking around quite a lot, but there is no foolproof way to detect a device's primary method of interaction. The way devices have marched on, even the ways that were considered relatively good are no longer considered so.

There are a number of complicating factors. For one, just being on a mobile device doesn't preclude having a keyboard--even a full one. The presence of touch events doesn't mean that the device runs primarily on touch. There doesn't appear to be any spec in place for quickly detecting a device's components including keyboard, mouse, touch, and (importantly from a UI developer's perspective) knowing which of these is dominant.

Watching for keydown/up, mouse events, or touch events means a player has to go through an additional layer of interaction before entering a game. That's something I want to avoid.
In response to Lummox JR
Lummox JR wrote:
Watching for keydown/up, mouse events, or touch events means a player has to go through an additional layer of interaction before entering a game. That's something I want to avoid.

As I thought, but it seems to be one of the only ways to get around it for now.

Unless you want a pop up asking what type of device they have or if they want to use a keyboard/touch. For any device every game...

You can't even target screen sizes, as you mentioned a mobile device could have a keyboard..

Gah, would hate to be you right now haha :) !
The D-pad controls have been moved to the hotbar. But if you want to disable fully, I suggest just making a custom .dms skin that's much like your .dmf, and leaving the D-pad, hotbar, etc. out.
The webclient doc should spell it all out for you. But In a nutshell, basically you want something like this in your .dms:
<body>

<div id=map byondclass=map></div>
<div byondclass=child skinparams="left=info;right=output;is-vertical=false">
  <div id=info byondclass=info></div>
  <div id=output byondclass=output</div>
</div>
<div id=input byondclass=input></div>

</body>
That's vastly simplified; you'd of course want styling, either inline or via a stylesheet, to position the elements. Translated skins effectively do this:

1) The default window is identified and given a byondclass of "pane" (as are all windows and panes), with attribute isdefault=1. Its position and size info is ignored.

2) In the default window and in each pane, first the window/pane itself is output as a div. Then within that div, all controls that are part of it will be added as more divs. Any control marked as a default should have isdefault=1 in the div's attributes. The byondclass attribute specifies what kind of control it is ("pane" always used for windows and panes).

3) All skin params for a control that are not defaults are added to the "skinparams" attribute and put in a typical URI encoded format: e.g., "text=Hello%20there". The controls will read any of these params that they care about and winset themselves.

4) Position, size, and anchor information are included in skinparams (but are not winset at load time); they are applied directly via an inline style, with position:absolute. E.g., style="position:absolute; left:0; top:0; width:50%; height:100%;". Additionally, any window/pane other than the default is given "display:none" in its inline style, so it won't be shown until the pane is adopted into a control, which happens in load or post-load.

5) Any control IDs are sanitized. Characters other than alphanumerics, underscores, and periods are removed. A "fullid" attribute specifies the fully qualified window.control ID form used for backwards compatibility. If an ID alone is not unique, then the id attribute will be removed for any control that shares it with another, except for the default control of that type. So if you have several controls named "output", the default will remain "output" but the others will not; their fullid however will remain intact, as "chat.output" or what have you.

In translated skins, the addition of status, dpad, and hotbar controls is handled in pane.dms. The default pane does this in postLoad(). If you want to avoid adding these things, do not set the isdefault attribute for your main pane; or better still, don't include it at all, only its controls. You don't actually need panes for anything other than placeholders in the webclient.

As far as skin positioning, etc. the main skin really doesn't care if there's a default pane or not. (The status control could then be added separately as its own div, if you still wanted it. In that case it will popup a little tooltip-like box in the lower left corner when you hover over something. When the hotbar is in use, the status control sends its info to the hotbar instead.)
Page: 1 2