Octodemy
patreon
Inventory Drag and Drop experiments
🕑 Added 2025-07-21 01:17:57 +0000 UTCI was playing around with some prototypes to learn how to make proper UI interactions when I suddenly fell into the inventory system rabbit hole.
I made my own drag & drop system before I found out Godot already has a builtin drag&drop.
There are a few limitations, so I still think my own drag system is a valid option.
But a learned a lot about godot's system and how useful and fast it is to setup.
And I also made workarounds for the few most annoying problems I found.
What it is
It's a very simple system and extremely easy to use system.
You can override 3 functions to tell what a not will do when they start a drag or receive a drag.
It also comes with a notification signal for when the drag is canceled or started.
And a preview system.
I'll make a quick video on how to use those later as well as a few tips.
Limitations
The single most annoying thing about the builtin drag system is that you can't control the cursor icon.
It automatically changes your cursor to the forbidden one if the control node over the mouse can't accept dragins
This is extremely annoying, and this behavior is hard-coded into Godot.
So there is no proper way to remove this.
One option is to use custom cursors and just replace the forbidden cursor by the default one.
But eventually, I found a work around to keep the system default cursors.
It's definitely a hack. But it works beautifully.
Cancelling drag issue
Dealing with cancelled drags is harder than it should.
If you make your drag system "take" the slot by storing it in the drag data,
there is no "proper" way to return it back when the click is cancelled.
The drop data callback is only called when you drop it on a control node.
You get global notifications for DRAG_BEGIN and DRAG_END .
But when the DRAG_END notification is received the drag_data is already cleaned,
so you know that the drag ended, but can't know what was in there anymore at this point.
To fix this is simple, you just need to store the drag_data when you receives the DRAG_BEGIN notification. It's an easy fix, but still what feels like an unnecessary extra step.
Dropping item on 3D viewport
This was unexpectedly hard to do with the builtin system because only control nodes have the can_drop override. So I had to find a way to have a hidden control node under the screen but at the same time not block gui_inputs so that the unhandled_input were not affected.
Other drag & drop systems and problems
While this builtin system is great and very easy to use. It only deals with drags.
So if you want to make a click to drag, click to drop system. You still need to create your own.
But the biggest advantage of the builtin system is that it deals with click release events.
If you try to implement your own drag&drop you'll soon realize that the control node where you started the click at will consume the click release event for gui_input and there is no way around that. (I found a workaround for this later, but not sure how it behaves on other OS's)
So you'd have to use the _input function and deal with what node the mouse is under in another way.
My own drag system
While experimenting, I ended up making a very robust multi-inventory system that uses signals to communicate actions.
I made my own version which ended up similar to DevLogLogan's inventory system. But in what I felt was easier to use/understand at a glance.
I'll try to come up with a another video for that later as it can be very useful for complex RPG's that needs multiple inventory systems.
End
But that's it.
I'll be making a quick video on how to use the builtin drag and the workaround I've found.
But it'll not be about how to make the an inventory system yet.
I'll be focusing on how the drag and drop works and its quirks.
