F8 console and SetNuiFocus()

FiveM Discussion Bug reports
,
1

Hello, first of all, I apologize for my English as I do not speak it very well nor do I understand it very well.

I would like to report a bug that I am having in the Latest version of my client-side.
image
(Just changed to release to get it my mouse working)

When I have the Latest version activated, SetNuiFocus(true,true) works, but if I press F8 and then try to interact with any NUI that uses SetNuiFocus(true,true), it simply causes the mouse to disappear. It gives me the following message on F8.

image
image1116×29 37.4 KB

I apologize if this is not the right place to report bugs for Unstable, as I mentioned earlier, I am terrible at English.

2

My reproduction steps:

  1. Open active NUI with cursor (have an active cursor)
  2. Open F8 console
  3. Move cursor to separate window/screen (windowed borderless)
  4. Move cursor back onto game and close F8
  5. Cursor is gone; do the same again above to get cursor back

I do not see the autofocus notice shown by the user above.

3

These do not seem to work here. :confused:

Exact steps I’m taking:

  1. Launch the game in windowed-borderless mode with the game’s resolution set to smaller than a full screen.
    I can’t ‘move to a separate monitor’ as I do not have a system with multiple monitors.
  2. Open the /tx overlay on a server with txAdmin, TAB into the ‘Players’ section so a cursor appears.
  3. Open the console.
  4. Move the cursor around, over a few windows, etc.
  5. Go back to the game and close the console.
  6. The cursor remains fine on the NUI part no matter what.

Even frantically clicking around seems to have no effect…

It should be noted that my mouse input mode is set to the default (‘Raw Input’), and I’m using the current Canary build of Windows as well in case this behaves differently.

1 Like
4

This issue does not seem to be constrained to windowed or multiple displays.
I managed to reproduce it (or something similar) while using fullscreen and not even moving the mouse to another display or minimizing the game.
Steps:

  1. open game, connect to server
  2. press F8 twice (open+close)
  3. open the tx menu and press TAB

With only these steps you can already see that the mouse will have disappeared.

Additional information:
When the issue happens and you move to another monitor (do click!) and back, the mouse still wont show, but if you do that and click on another window, as soon as you move the mouse back over FiveM the cursor will show and will keep showing until like a second after you click back into FiveM.

5

Nope, this also doesn’t work for me.

  1. Opened the game and connected to my server by clicking the button in the main menu.
  2. Opened and closed the console once loaded (tapping F8 twice).
  3. Used the key bind I have assigned to open the tx menu, and pressed TAB.
  4. I still have a working cursor.
6

Just to confirm, I also opened tx by using a keybind (F1), so that cannot be the difference.
Sorry I don’t know how to help you with this one.
But if you think of something let me know :slight_smile:

7

Following these steps didn’t seem to work, however moving the cursor into the F8 console when closing caused it to disappear. If any additional windows are open (e.g. resmon, net event log, etc) the cursor did not disappear.

Opening the console and moving the cursor away usually made it reappear after closing.

Edit. I’m able to produce this bug without even connecting to a server.

8

Just to also add the fact that the mouse input still works the cursor is just a visual thing. I am fully able to interact with menus and such. The resources I’m most commonly using it on is ox_lib stuff.

9

Does this also apply to just… drawfps or drawperf being opened, even though those don’t take input?

10

Drawfps and drawperf also seem to prevent the cursor from vanishing, yes.

11

Unsure if any progress has been made on this. What I am experiencing this locally (in window mode; 1024/768):

  1. g_shouldHideCursor may not be unset if the earlier conditional suddenly evaluates to true.
  2. ImGUi’s WantCaptureMouse = (mouse_avail + ... condition is incredibly awkward (i.e., does not consistently evaluate to the same value) when moving my cursor outside a hovered window.

I may circle back to 2 if I find some time for it

12

Semi-related inquiry. What is the purpose of creating unique_lock’s with no associated mutex:

std::unique_lock<std::mutex> g_conHostMutex; // x7

and

std::unique_lock<std::mutex> g_referenceHashListMutex; // x2
13

Probably a typo (variable name instead of _(mutex), made easier by the older pre-C++17 syntax).

14

Roger. Although, the proposed fix may likely run into this loop: OnConsoleFrameDraw (locks) >> ImGui::NewFrame(); >> ... >> OnConsoleWndProc (attempts to re-lock)

15

… right, I did assume something along those lines would inadvertently happen. Will see if there’s anything obvious that can be done about that instead - worst case just moving to a recursive_mutex.

16

and it actually did

how surprising

update: it did get fixed