Over the past couple days I have been doing R&D on making a UMG version of my drag-drop inventory. I started integrating my prototype into my main project today. I have run into an issue though that is getting quite frustrating.
When I run the game in the editor or windowed standalone, the drag drop operation creates a drag-visual and I can carry out the drag-drop successfully. However when I run the game in fullscreen standalone the drag-drop operation doesn’t create a visual, the operation does complete successfully though. Is this a bug with a workaround ?
I would love to get this addressed so that I can put it in my next update and build more functionality off of it.
Any help or advice with regards to this would be very much appreciated.
I thought perhaps that this was something to do with my build of the engine from github. While troubleshooting another issues installed 4.6.1 binary and made a copy of my project. The issue still persists unfortunately. The commands being used to fullscreen are 1280x720w —> 1280x720f and the same for 1920x1080. Is there a more UMG friendly way of changing screen resolution ?
So this isn’t quite an answer so much as it is a conclusion that I’ve reached through much trouble shooting and having tried many different possible solutions.
I’m not trying to bump this thread to get an answer but to contribute to it, seeing as I am in a production situation I feel it pays to be pro-active.
It would appear that when the game is set to fullscreen through the use of r.SetRes that the the game window is being rendered on-top of the desktop (As I assume is normal).
The problem seems to come in when starting a drag-drop operation, the game window is being drawn on top of the drag-visual as well. I reckon this may be the case because when you start a drag-drop operation in windowed mode , you are able to drag it out of the window and the drag-visual is drawn on top of the desktop. In addition to this I have found that when capturing footage using Bandicam, the capture software recognises the drag-visual as a seperate window (which in my case crashes my capture but that’s easily sidestepped).
The drag-drop-operation is an excellent feature and reduces the complexity of my previous implementation through slate a great deal. I would be most grateful for any advice or fixes that anyone with inside knowledge would be able to offer me.
I’m not sure if it’s the same bug but it would certainly be related, I don’t get kicked out of the game or experience a crash as they described. It would be great to hear official word on this of course.
I love @ 's inventory system windows ! I already have window dragging down though , I have some slate implemented drag-drop detection for slots that I just may be able to use with UMG. This would depend on if I can get the screen-space position of the inventory slots in my windows. I’m not sure how successful this will be though as they’re nested.
ive updated my dragablewindow howto with comments, you can use the technic i used there to get the exact viewportspace position of a widget (wich has its own geometry)
i used this myself to get a complete own dragdrop system working (without using the build in drag drop stuff)
so long as I have a reference to the widget who’s position I want, would it still work if said widget is nested in another widget ? I guess I’ll have to wait and see. Thank you @JParent and @
@AdamDavis sorry to bother but is there any official word on this issue ? I’ve been working on a new update for my game, I’d like to get my new update out to my players but this has become a major obstacle.
Some official feedback on this would be very much appreciated.
Update
Just confirming that this issue is still present in the 4.7 preview build.
Unfortunately the drag and drop functionality you are looking for is not supported in fullscreen projects at present. While this is something we want to implement in the future, I do not have a timeframe at present of when this will be released. Please keep a look out for future release notes!
