XDelta
commented
11 months ago Probably related issue: #47
Open epicEaston197 opened 11 months ago
XDelta
commented
11 months ago Probably related issue: #47
VRBat
commented
11 months ago @XDelta This is very different to the Linux bug. Linux seems to be having the issue of the context menu snapping to different parts of the screen whereas on windows, the context menu follows the cursor for the duration of it's opening animation. I did a write up myself of the issue on windows
While in first person the context menu will follow the cursor while in it's opening animation state, and will stop in place once the opening animation is finished. This behavior should only happen when you're focused onto a snap plane (protoflux/inpesctors/etc.) and not when in first person.
The context menu will follow where your cursor moves for the duration of the opening animation.
In the video, the purple circle is to reference where the cursor and context menu is supposed to remain when opening the context menu.
The context menu is supposed to remain in the center of your view when opening it in first person. This behavior should only happen when a desktop user is focused onto a snap plane. This behavior should not be happening when in first person
2023.10.13.743
Windows
Screen/Desktop
Replicated the issue 5 times in Local home BATTOP - 2023.10.13.743 - 2023-10-13 18_19_16.log
yoshiyoshyosh
commented
11 months ago @XDelta @VRBat To add on to this, they are definitely different bugs. The Linux one seems to be related to a larger issue on how Resonite doesn't center the cursor on Linux as a whole (see: #100), while here Resonite properly centers the cursor, it just seemingly has delay before positioning the menu.
shiftyscales
commented
10 months ago Yes, in agreement- these are separate issues. #47 is demonstrating this behaviour but is not directly the cause of it. I believe this to be a consequence to the fact that desktop/VR share subsystems/code. E.g. having the context menu follow the cursor's position makes more sense in the context of VR where it is your hand/laser that is determining the positioning rather than on desktop. This is not a bug, but would be a tweak.
Having the context menu be universally in the centre of the view doesn't make sense all of the time either, e.g. if you are in UI edit mode the cursor isn't locked to the centre of the screen, thus, it makes sense the menu spawns where the cursor currently is while it is being opened.
I personally find the behaviour useful even in desktop, however. Without it, if you moved the cursor too much while the menu was opening, it would close itself.
That behaviour could also be tweaked perhaps- e.g. not closing the context menu when the cursor is too far away from it- but as things are now, I feel it is a pretty sensible default. It opens where your cursor is when you need it- and dismisses itself if you intentionally move your cursor away from the menu.
You have to go way out of your way to make this behaviour a problem, e.g. intentionally placing the cursor at the edge of the screen, or swinging your cursor wildly while opening the menu.
Another potential solution would be ensuring that the context menu is fully visible/in bounds of the view, e.g. to handle the edge case of the cursor being at the corner/edge of the screen, rather than always centering on the cursor.
epicEaston197
commented
10 months ago The problem is that it not being in the middle of the screen in first person mode is really annoying and causes usability issues
epicEaston197
commented
10 months ago In that video that is expected behavior I do not expect that from first person mode it's annoying
are you saying that this is okay?
Not trying to be rude but I want it to stay in the middle
shiftyscales
commented
10 months ago @epicEaston197 I understand and have addressed your concern in my prior post:
Another potential solution would be ensuring that the context menu is fully visible/in bounds of the view, e.g. to handle the edge case of the cursor being at the corner/edge of the screen, rather than always centering on the cursor.
Your most recent posts were unnecessary. You already demonstrated the issue, and I already responded to it.
I would like to take a moment to remind you of our best practices:
Use objective, and respectful language for any posts/comments submitted (negativity, hateful/angry issues/comments are liable to be edited or removed)
If you do not wish to be rude, please do not bring anger, annoyance, frustration, and other such emotion into your responses on this repo.
Thank you.
epicEaston197
commented
10 months ago okay sorry
epicEaston197
commented
10 months ago Something I want to note even when not moving your mouse fast and just using it how you normally would it still doesn't prioritize being in the middle of the screen this can still cause usability issues
Zyro1331
commented
10 months ago In duplicate issue #471, I showcase that the cursor-snapping will sometimes trigger even when the menu is not centered. This causes an issue when using the "flick" gesture as it will trigger actions when the cursor gets snapped into the center of the screen. It can also happen when regularly clicking buttons as the cursor can sometimes be teleported away from the whole menu itself and end up unnecessarily dismissing the menu.
Note; In my closed issue I am not intentionally causing the bug. I am going at slow pace, trying to just use the menu when it goes off-center. The replication case is strange, as some others who have tried have had it work intentionally but others haven't. I've noticed switching between using "flicking" and regularly pressing the buttons can make the problem occur and it will make it very difficult to switch locomotion due to your mouse cursor teleporting back the center of your screen.
Readun
commented
9 months ago I just noticed that... or a similiar but maybe different issue aswell when Working in Desktop on context menues.
In my Case, going through context menu layers.
Open conext menu > Click a submenu > Radial menu centers on the current cursor position > --As soon as the Mouse is moved-- > The curser jumps back to the center of the screen, but not the menu.
This is causing in a lot of unwanted Closing of context menus, as it moved too far away.
shiftyscales
commented
9 months ago Hmm- I think that is a separate issue, @Readun @Zyro1331. It sounds like the cursor is being prematurely locked to the centre of the screen (used to turn the character controller when not in a menu, e.g. the dashboard).
The issue you described is peripherally related to https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/242 which also covers unwanted cursor locking. I'm going to re-open #471 for that issue in particular.
epicEaston197
commented
5 months ago Alright so I got in around to this issue again and I've created an asset in my public folder that will prioritize your radial menu in the middle of your screen in the first person mode it isn't perfect but it is a proof of concept of what I want
resrec:///U-epicEaston197/R-1F7A7B629910377BF611DC00A1C14AFFF968B6F2FCC311239492BBCD24B9624A
epicEaston197
commented
4 months ago Open conext menu > Click a submenu > Radial menu centers on the current cursor position > --As soon as the Mouse is moved-- > The curser jumps back to the center of the screen, but not the menu.
This is mainly caused by what I believe to be the Radial menu closing then reopening whenever you click on a sub menu category when the radial menu is closed the mouse is centered onto the screen and when the Radial menu is reopened because it's moving to a subcategory the laser is still exactly where it was
Describe the bug?
If you're moving your laser while opening up your radial menu it will open where your laser is this can cause usability issues with the context menu
To Reproduce
Move your laser fast in One Direction while opening up your radial menu do this a couple of times it will likely not prioritize staying in the middle of your screen
Expected behavior
No matter how fast my laser is moving my context menu should prioritize staying in the middle of the screen so that it has optimal usability
Screenshots
Resonite Version Number
2023.10.13.743
What Platforms does this occur on?
Windows
What headset if any do you use?
desktop
Log Files
DESKTOP-DAN95E7 - 2023.10.13.743 - 2023-10-13 18_44_27.log
Additional Context
No response
Reporters
@epicEaston197