-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding Drag & Drop Support via Draggables & Slots #55
Open
Kulltero
wants to merge
17
commits into
Facepunch:master
Choose a base branch
from
Kulltero:DragnDrop
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Added the JSON API required to setup & update Draggables & Slots. Also added the ability to reparent & order a transform if called via an update call, this is needed to allow reparenting a Draggable
Fix a potential illegal swap when a panel inside a restricted slot was swapped with a non-slotted panel. Changed DragRPC to not send when a swap/attach operation fails & the panel will reset to its last position, the change was made because in those situations, a player didnt intend to drag the panel, they intended to attach it.
fixed attachement fail sending a DragRPC, also properly sets the position of panels that can be dropped anywhere
4 tasks
the previous approach used offsets, only modifying the position if the new position would be within bounds. this caused awkward behaviour where the dragged object would stop long before its actual bounds. this was also framerate dependant as it would make bigger leaps on lower framerates, making it more likely that the new position would have been out of bounds and increasing the apparent distance from its bounds after actually testing the PR in game i've realized it is safe to just use the absolute position (anchor + offset) and to constrain that to the rect with respect to the padding.
adding default sprites and changed some images to use Image instead
the draggable now consider's both the parent's position and scale instead of just its scale when determining if its bounds need to be recached - this solves an issue with animated elements having cached old bounds the anchor now also gets parented based on the parentLimitIndex, previously it was parented to the draggable's initial parent which brought with it unwanted behaviour when that parent was moving
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Implementing Drag & Drop into our UIs
The Breakdown
this PR adds 2 components, a
Draggable
component and aSlot
component. the Draggable Component is responsible for the dragging interaction, sending RPCs to the server, & keeping itself within the constraints. the Slot Component's purpose is to allow draggables to be attached to the panel, with an optional primitive string filter to only allow draggables with a matching filter in.Demo:
Drag-n-Drop.mp4
Receiving RPCs
Draggable's will send 1 of 2 RPC calls on the CommunityEntity depending on which action is performed:
the position Type
the Draggable Component comes with 4 seperate position send types, you might prefer one over the other depending on your scenario:
the JSON Implementation - Draggable
* Depending on other settings the default value for the positionRPC field may change.
RelativeAnchor
NormalizedParent
the JSON Implementation - Slot
Slots & Filtering
Slots come with a built in filter system that allows you to specify what draggables can be attached.
this is how the filtering is evaluated:
if the slot has no filter, any draggable can be inserted. if the slot has a filter it only allows Draggables with a matching filter property. in the demo video this is shown with the green Draggable & Slots, the gray slots will accept any draggable while the green slot will only accept the matching Draggable. this is accomplished by setting the filter string
when building a system arround slots & the swapping of Draggables, its reccomended to set the
dropAnywhere
setting to false to make Draggables return to their last position if a