Click drag functionality

[PrPleGoo]

Some interactions in SS13 that are behind click drag functionality:

• buckling a mob to a chair;
• opening another mob's inventory pane;
• moving things into a bin/gibber/meathook;
• emptying inventories on tables;
• climbing onto tables;

The interaction system needs to support these cases and click drag should be a good way to go about it.
I propose we add an IDroppable interface for components to implement.
When a client's click key is pressed we should store the click's information and permit a small time window before assuming a drag.
We can immediately look up the entity that's being dragged as locations can be different once the timeframe is up.
Once it is established that an interaction is a drag all visible entities should be checked for IDroppable implementations.
Entities that allow the dragged entity to be dropped unto them should be highlighted.
For this, IDroppable should force some method that tests an Entity as well as the actual behavior.

[chairbender]

Well I did this for unitystation so why not do it again...Taking this on.

[RemieRichards]

Click-dragging isn't very discover-able.
Since we have a right-click menu that doesn't take a century to open, we can probably use that instead.

i.e: just remember, we're not limited by SS13's constraints. Things don't have to be click-drags just because they needed to be to circumvent byond lag.

[ComicIronic]

We could make it more discoverable - and click-dragging is the sensible choice for interactions, like moving stuff that's too big to carry. I agree that it's not so good for buckling or opening other peoples inventory - but pulling a human into a gibber is a natural drag action.

The only question is how to make it discoverable. I think highlighting any IDroppable entities is a good idea, but we could also make the cursor change into a sprite copy of the thing being dragged. That way it's clear what you're using to interact with stuff.

[ShadowCommander]

If a click turns into a drag, it'd be nice to have a small icon of whatever you're dragging show up next to the cursor.

[PJB3005]

The only question is how to make it discoverable. I think highlighting any IDroppable entities is a good idea, but we could also make the cursor change into a sprite copy of the thing being dragged. That way it's clear what you're using to interact with stuff.

Both of these are good yeah.

[chairbender]

Need some feedback...

With current interaction system, we pretty much send every mouse click to the server and leave it up to server to tell us what happens next. For drag and drop interaction, in the presence of lag I worry this leads to an unsmooth experience.

For example, with the current "pattern" for interactions, the flow would be like:

• Server side component has IDroppable
• Client mousedown, message goes to server
• server checks if there's a draggable entity, tells client that a drag is initiated (spawning a drop shadow of the object being dragged and the entities that can be dropped on)
• client gets this info and can proceed to drop the entity
• server gets the mouseup and the drop happens

The part where client has to wait for server to tell it if a drag can be initiated is what concerns me, coupled with the need for a slight delay before initiating the drag and drop.

Does this approach sound okay instead?

• Client side component has IDraggable, marking that it can be dragged (could have a "Draggable" marker component that just returns true if it's in range).
• Client mousedown
• Client checks if any entity has IDraggable, and if so creates the clientside drag shadow while telling the server that it wants to start a drag (bypassing the normal clientside click behavior where it sends the mousedown cmd to the server)
• Server validates the dragged object is in range and sends client list of entities that can be dropped on (if any)
• Client gets the entities and highlights them (if any)
• Client drops it on one of the entities and then server validates + performs the drop logic (via some new interaction interface like IDragDrop)

My suggested approach means that client will get the drag shadow instantly (assuming they held click for long enough), but it may not immediately see the "candidates" for dropping...even so the client can still go ahead and drop it before they know what are valid candidates if they already have a good knowledge of what can be dropped on. IMO this leads to a more responsive interaction.

Does anyone see potential issues with that approach? The issue I can potentially see is the client not knowing if an object is really in a "draggable" state if there are entities which are only draggable in certain situations, but IMO if an entity is ever draggable it should always be draggable, the server will just tell client there's no candidates to drop on. That way it would avoid frustrating "why can't I drag this?", and repeated attempts to get the drag shadow to show up, thinking maybe they didn't hold long enough or click on it precisely.

I'm not concerned ATM about conflicting with other kinds of interactions as I already have a pretty good idea how that should work.

[chairbender]

Thinking about it more...I think we don't even need to bother asking the server for possible drop targets...the client should be able to know what the valid drop targets are just looking at visible entities that have particular components or are a certain prototype.

[ComicIronic]

Sounds like a good design. Making it smooth and client-based is definitely desirable.

[PJB3005]

Sounds good to me.

[Hugal31]

Not sure if it is the same feature, but inventory click-drag would finally allow to open the backpack/belt by clicking on it, instead of taking it in hands before, and only unequip it with a click drag.

[chairbender]

Running into some limitations with the current binding system because you can't register multiple InputCmdHandlers to a given BoundKeyFunction, and the constructor system already is bound to Use on clientside but I also need to bind to Use for the drag and drop stuff. It's inspiring me to add support for this to the binding system. Right now I think we're kind of lucky that all key functions are only bound by one system / manager.

Gonna focus on that first - support for adding multiple bindings to a given key function while being able to explicitly define the order in which the handlers should be resolved. Unless someone thinks that's a really bad idea.

I will do that as a separate PR and get a draft up to get someone to take a look at my proposed design before I do the drag and drop changes, otherwise the PR for both will be too big (and I expect I might need to make significant changes to the new binding approach depending on feedback)

I think I can come up with a good approach for solving that, but feel free to tell me if I shouldn't even bother with the binding stuff though and just come up with a temporary hack to get the drag and drop + constructor system to work together.