[HL1/HL1SDK] Mouse input issues

[RichardRohac]

Raw input works correctly on current (non beta) Half Life Steam build (just running regular Half Life), I get no lock on mouse rotation. But, compiled latest (8/10/2013) Half Life SDK (VS2010), I get the rotation lock when running the mod and raw input is enabled (same engine build is running, must be SDK issue I guess).

I also get no mouse wheel input whatsoever (every current GoldSrc game). (Microsoft Wireless Mouse 1000)

(Windows build)

[alfred-valve]

Do you have a sample mod you could point to with this issue? I have an idea of what the problem will be but I need to reproduce the problem to be sure.

[RichardRohac]

Basically I've just compiled the clean newest SDK you have here, those two dlls it gave life to and liblist.gam. Windows VS2010 build. I can upload it if interested..anyway.

[RichardRohac]

Here is the sample mod after all

http://www.sendspace.com/file/4tkll7

But like I said it's just clean current SDK build.

About reproducting mouse wheel being ignored, taking in case you guys would notice it not working if it'd be global issue, I guess it's this wireless mouse special problem, some HW incompatibility or so. But it's never working, no current GoldSrc game, doesn't matter if it's raw input or not. (It worked on old engine builds and it works elsewhere of course.)

[dtugend]

https://github.com/ValveSoftware/halflife/blob/a06e5a1f53bd1b8e2096f1dd33b6adfa44561a00/cl_dll/inputw32.cpp#L494

SDL_GetRelativeMouseState( &deltaX, &deltaY );

deltaX and deltaY get 0, also if you press the windows key to get out of the game you see that the mouse is stuck in a window corner or edge.

I am not SDL2 savvy, so I don't know if it's an SDL problem or if some other SDL functions (i.e. for Message Pumping) need to be called inbetween.

[dtugend]

I tried a separate SDL2 test-program (with SDL-2.0.0-7046).

SDL_SetRelativeMouseMode(SDL_TRUE); Keeps the mouse in the midle of the window as it should, don't know yet if Half-Life calls that or not with the custom client.dll.

Have to go to bed, will try to debug Half-Life tomorrow, maybe I'll find s.th..

[dtugend]

@alfred-valve :

Well yeah, with the custom mod SDL_SetRelativeMouseMode is not called by Half-Life.

With the default valve mod SDL_SetRelativeMouseMode is called from inside hw.dll.

I think one could do the calling of SDL_SetRelativeMouseMode in the client (IN_ActivateMouse, IN_DeactivateMouse and where it re-checks the m_rawinput CVAR), but I am not sure if that's the right way to do, or if we should relay on hw.dll instead, as it is for the default Half-Life mod?

Btw dmc and ricochet client.dll inputw32.cpp doesn't have m_rawinput handling in the SDK, they always do rawinput, I suppose that is wanted this way (I am fine with that)?

---

@RichardRohac

Regarding the mwheel issue, have you tried pressing attack (i.e.ENTER or Mouse button 1), after doing mwheel? You might be a bit confused, because it doesn't load the HUD sprites for the weapon menu from the valve folder (I think you will have to put them in your mod folder).

[RichardRohac]

It's strange game input gets handled differently for each game / MOD like this. Anyway, I'd say it doesn't really matter if SDL_SetRelativeMouseMode would be engine or SDK handled, keeping it engine wouldn't hurt anything I guess, not even code customizability.

About the wheel issue, wheel !movements! are completly ignored. Wheel as button works, but moving the wheel does nothing, and that's pretty serious. Now I don't know if it happens globally or it's just my mouse, but that'd be weird, it works elsewhere perfectly.

[dtugend]

I sadly can't reproduce the mousewheel problem.

I am more interested in 2), since 1) probably won't work as you said:

1) Try this:

• enter the game (map boot_camp in console)
• in console: bind mwheelup "echo test"
• resume into the game, move mousewheel up
• now look into the console if it says test

2) Try this:

• go to options Keyboard
• select a mapping and hit Edit Key
• move the mousewheel
• if this works it should recognize the mouse wheel and change the bind to MWHEELUP / MWHEELDOWN

[RichardRohac]

Both cases don't work. Now, message pump or whatever way SDL handles it never creates MWHEELUP/DOWN events at all. Seems to be specific mouse issue, but I don't get ..why it's not working here.

[dtugend]

@RichardRohac @alfred-valve The mousewheel not working might be due to the following:

I found this: http://techietalkz.com/2011/04/10/how-to-workaround-for-microsoft-wireless-mouse-5000-scroll-wheel-issue/

Most (almost all) mouse drivers cause mouse wheel events with a "delta" of ±120. This is an arbitrary value that has been chosen by Microsoft in the past to allow finer control. Since then, several programs use that value directly to test whether the mouse has been scrolled down or up (delta / 120 == 1 -> down, delta / 120 == -1 -> up, or something like that). However, the Intellipoint software causes mouse wheel events with smaller "delta" value (the expected finer grain control), and programs which use the 120 value that way just fail to register the wheel movement, because in integral values, 30 / 120 = 0…

(The post linked above, might also contain solutions for you @RichardRohac )

And I looked into the SDL2 code to find this in SDL_windowsevents.c

case WM_MOUSEWHEEL: { // FIXME: This may need to accumulate deltas up to WHEEL_DELTA short motion = GET_WHEEL_DELTA_WPARAM(wParam) / WHEEL_DELTA;

       SDL_SendMouseWheel(data->window, 0, 0, motion);
       break;
   }

And SDL_SendMouseWheel won't send the event when motion is 0.

I won't blame that on the SDL2 developers since Microsoft themselves isn't too clear about how to use WHEEL_DELTA: http://msdn.microsoft.com/en-us/library/windows/desktop/ms645617.aspx

Maybe someone file a bug report at SDL2 maybe (not me please): https://bugzilla.libsdl.org/

[RichardRohac]

Following the article I got the problem fixed, so this is definitely SDL2 releated then, thanks for bothering, software for this mouse might get handy in future, fixing mousewheel in other applications as well.

Mousewheel issue shouldn't be marked as Half Life bug then (?).

Now there's yet to fix the rotation lock. (I mean calling SDL_SetRelativeMouseMode(SDL_TRUE) when in game for MODs as well, engine or SDK side whatever, as that is r e s o l u t i o n to this problem for me, I've tested it.)

[alfred-valve]

The not seeing SDL relative mode is a bug in HL1, I'll need to add a hinting API so that mods can tell the engine they support SDL2 (rather than the older OS specific methods).

[RichardRohac]

Yeah okay, so I guess this can be taken as solved then :).

[dtugend]

Well, as expected I ended up being the one to submit the bug to libsdl.org sigh :( https://bugzilla.libsdl.org/show_bug.cgi?id=2147

Though you guys would need to update the SDL2.dll (that is in case they fix it).

[dtugend]

@RichardRohac

They fixed the bug in SDL2 in the hg repository. In case you can't download compile it yourself (has a VC++ 2010 Express Edition project inside), I put together a compiled version of the SDL2.dll at rev d8fb783475d5 here. However that version differs form the hg version as follows: 1) compiled as /MT (not /MD), just as Valve probably does 2) no XAUDIO2 support, because I don't have enough harddisk space to install the DirectX SDK

It would be cool if you could test if that DLL file or your own compiled version of it (rename the original one for backup and don't join any VAC servers while using the modified one), solves the mouse issue in default settings (I mean with the driver normally installed where you got the problem). (You might need to scroll several lines before it reacts, but it should react now. Maybe try once with the old DLL first to verify the problem exits and then with the new DLL to test if it's gone.)

But I assume we won't see a fix in Half-Life too soon, since @alfred-valve will probably want to wait for a stable SDL2 version I guess :)

[RichardRohac]

@ripieces

Thanks for all this bothering, they really have fixed the issue, scrolls instantly :) Until VALVe won't update the dependency I'll have to stick using the fixed driver anyway.

@alfred-valve

I guess it'd be senseful to wait for stable SDL build, but, this is pretty serious for most of Microsoft mouse owners, I'd consider moving the fix to your current SDL build or so.

edit:

http://hg.libsdl.org/SDL/rev/d8fb783475d5

[Tele42]

@slouken committed the fix, so this issue report should probably be reassigned to him.

[dtugend]

@Tele42 what do you mean, on libdsl.org the issue is assigned to him? https://bugzilla.libsdl.org/show_bug.cgi?id=2147

This issue on github.com is for ValveSoftware. SDL and Valve have connections, but they are two different organisations.

[Tele42]

@ripieces Slouken is currently employed by Valve.

[RichardRohac]

@ripieces

He means http://hg.libsdl.org/SDL/rev/d8fb783475d5 - the fixed code is by @slouken

[sixcentgeorge]

thank you for reporting the bug in a previous topic that is assigned . the sdl2,dll should fix the bug ? dominik.matrixstorm.com/SDL2_d8fb783475d5.zip have you made also a sdl2.so file ? i tried it but it changes nothing , i am even sure that my mouse bug does not come from this file : because i launched the game with this file renamed in dll.old , mod was playing with the same bug . your file made hl did a crash with the error in kernelbase.dll , sorry

[dtugend]

@sixcentgeorge you must have misunderstood s.th.:

The SDL2.dll file is just for fixing the mousewheel not working on some mices. After some of the recent updates the SDL2.dll file won't work anymore unless a debugger is attached (didn't look into why this happens so far).

As I said and linked in your issue you need to do SDL_SetRelativeMouseMode manually in your code until the engine is fixed. An exmaple can be found in Matherunner's fix here, which is also linked above your post.

[sixcentgeorge]

i do write the dlls , i used the one coming from opposing force mod. so bug is incredible and i have no idea where is the bug

[dtugend]

Please click the link I posted in the previous comment where it says "here". It includes the file and function names and also the place where to add the required modifications and the modifications itself!

[sixcentgeorge]

thank you again for your help , i did mistake in my post with not ... if you did not played my current beta , you can do it using won sierra opfor dll and a previous hl like won i reedited hl maps and story with new models and the opfor monsters that are a lot more than with original hl . i used original dlls to use also metamod and bots made for it made by metamod-p writer

may be you can build some dlls without the bug , i would be pleased to try them , i made a second mod using svencoop dlls , all models monsters and maps are reworked and optimised by me [ i used ripent and some scripts to find errors ] may be your dlls could cover the single and multi player coop....if you want to do that , i agree we can try . here is the post of my mod at steam forum : http://forums.steampowered.com/forums/showthread.php?t=3132642

the single player hl coop has maps from decay and azure sheep added and is real kisckass reread to be sure of no errors inside ;']

[sixcentgeorge]

this morning with linux , i tried the beta [ that changed nothing ] and then i renamed the folder from oplife to gearbox and got the mouse behaving like normal . there should be a path bug somewhere in the code of valve : i go play and test the mod with the new dlls

[FreeSlave]

So issue with mouse look in mods is still here. Even if you take shared object from original Half-Life linux version and put it to mod folder the issue remains (I mean rotation lock. It's here in both raw and not raw inputs). Maybe it's time to push fix to github repo?

Ok, anyone can fix it himself with SDL_SetRelativeMouseMode, but what about modifications which uses Opposing Force dynamic libraries (there are some). We don't have source code of Opposing Force to fix it ourselves (hey, maybe you release it already? :))

[sixcentgeorge]

i do not know if you work for valve or not . i tested my mod that uses vanilla--hmmmm--genuine dll from opposing force . the files never were updated except recently by valve for steampipes i changed the dlls and played my mod to see i have the mouse bug . after changing path to gearbox , there was no more the bug . may be with your mod you should use valve or dmc or cstrike [ according to the steamid number you selected ] to see if you still have the bug . i think there is a path bug in the source code of the hl1steampipes .

valve should select if steam makes games or not and instead of sparing money and becoming billionnaire : g.newell should buy some people to update its games and CHECK$ WHO DID THE WORK.....

[RichardRohac]

Why isn't this fixed yet, input is a critical part of game..and all that's needed is to update SDL library (most important) and add call to SDL_SetRelativeMouseMode(SDL_TRUE) for MODs as well, on the engine side (less important as everyone can call this on client side)..

[dtugend]

As @L453rh4wk pointed out in #1546 the workaround above by @Matherunner won't work properly for m_rawinput 0 on Windows because it doesn't honor whether m_rawinput is 0 or 1.

Also I am not sure if the game will call IN_ActivateMouse and IN_DeactivateMouse upon change of m_rawinput on Windows (which it might do, but I am unable to check atm, because Steam Client Bootstraper just crashes on my old laptop after the last update), meaning not sure if these are the right places to place those calls.

[sixcentgeorge]

so any news ? i played again my mod and saw that there is still the bug....while it is simple to correct : like i said a year ago , it is a question of path ...the mouse behave like in 1998 when the name is gearbox...but is "limited when the path is having an other name.... valve is having a bunch of lazies .....that make bad games and now kill others games..except black mesa the half-unfinished game that is a copy of hl made with "decomposition" of maps... http://forums.steampowered.com/forums/showthread.php?t=3288444 yesterday i made a post in this topic with a link to http://www.consumerreports.org/cro/food/how-safe-is-your-ground-beef that was silently removed...i hate forum that does these cleaning...they only tell lies and show the world as a paradise ...while it is a lot more like the "american burger" that has not only cows inside... that is "funny" to see the difference between hl2 and hl3...the first was asked every day while the second interests only nobody..

[thopvna]

You can try: mouse & touchpad -> disable scroll inactive windows when i hover over them

[djdallmann]

Doesn't SDL_GetRelativeMouseState get the last state since the previous mouse update and not current mouse position which then causes mouse movement to be off by one update or am I misunderstanding this SDL function?

I also noticed SDL for half-life/counter-strike 1.6 in windows is using version 1.3.0.0 and not the latest 2.0.4, hopefully there are no bugs in this version and I wonder if using a newer dll would get you VAC banned on windows?

[SamVanheer]

See #1900

[RichardRohac]

@mikela-valve Seeing that some work is being done on the engine again, could this be looked into?

I experience the same mouse issues with the current engine version.

@SamVanheer This is all great, but the actual SDL build needs to be updated as well. The SDL version that comes with the engine is too old to handle wheel scrolling quirks of some (Microsoft) mouse types. This was solved some time ago (http://hg.libsdl.org/SDL/rev/d8fb783475d5).

[SamVanheer]

Yeah the SDL2 library needs updates for a couple reasons, see also #1887

[djdallmann]

Yes, plz update SDL

[jirikivaari]

Yeah some mouse wheel issues were fixed in another mod by replacing the SDL2 in HL1 folder.

[HalfWayLambda]

@mikela-valve Could you take a look at this issue?

[djdallmann]

Would really like to see this get fixed :(

[sixcentgeorge]

@mikela-valve can you make the two "mod" 's dlls for a mod i am making .. or give me somebody that can do it .. i am ready to give a little amount of money . i want something basic like the gearbox engine dlls . i asked at gearbox steam community but no one is there except "customers having bugs" . how to get the source code ? or how to buy the "commercial hlsdk " ?

for those having the bug.. they should test using a well known steam path : like gearbox or dmc... it is an added "end of life" error to force people uses the source "engine" that no one likes so much..

[SamVanheer]

@mikela-valve i looked into this and i think the solution is as Alfred said above to add a way to hint the engine that SDL is being used.

Currently the engine sets relative mouse mode using SDL_SetRelativeMouseMode if BUsesSDLInput returns true. BUsesSDLInput only considers official Valve games using an app id and client dll path check. If the client could hint to the engine that it's using SDL2, as any Half-Life mod using the current SDK is doing, then the engine can correctly set up SDL state as it does for official Valve games.

To test this i hex edited the engine to replace the filename for gearbox\cl_dlls\client to updated\cl_dlls\client. When i ran my mod it no longer had the issue. Mouse sensitivity did go down, probably as a result of the mouse data being received by the client being different.

It's probably easier to test by putting a mod dll in place of an official game dll, like valve\cl_dlls\client.dll. But this confirms that it works with files that don't have the path of an official game dll.

A new engine function could be used to provide the hint:

//In APIProxy.h
    pfnEngSrc_pfnVguiWrap2_GetMouseDelta_t pfnVguiWrap2_GetMouseDelta;
    void (*SetClientUsesSDL)(int usesSDL);
} cl_enginefunc_t;

Then on startup, probably in Initialize the client tells the engine:

//In cdll_int.cpp, function Initialize
memcpy(&gEngfuncs, pEnginefuncs, sizeof(cl_enginefunc_t));

gEngfuncs.SetClientUsesSDL(1);

The value provided would be used by BUsesSDLInput. If the client does not tell the engine it should default to identifying the client as it does now.

So the engine should perform these steps:

• Initialize global int g_bUseRawInput to -1
• Load and initialize client dll
• Check if g_bUseRawInput is either 0 or 1
• If not, check if it's an official game using existing logic
• g_bUseRawInput should now be either 0 or 1

In code:

int g_bUseRawInput = -1;

qboolean BUsesSDLInput()
{
    return g_bUseRawInput != 0;
}

void CL_SetClientUsesSDL(int useSDL)
{
    g_bUseRawInput = useSDL != 0;
}

void DetermineSDLInput()
{
    if (g_bUseRawInput != 0 && g_bUseRawInput != 1)
    {
        g_bUseRawInput = 0;

        if (BIsValveGame())
        {
            g_bUseRawInput = 1;
        }
        else if (Q_strstr(g_szfullClientName, "valve/cl_dlls/client"))
        {
            g_bUseRawInput = 1;
        }
        //Remaining filename checks here
    }
}

Alternatively a function could be added to the client dll interface to ask it whether it uses SDL or not:

//In APIProxy.h
    CLIENTFACTORY                       pClientFactory;
    int (*ClientUsesSDL)();
} cldll_func_t;

//in cdll_int.cpp
extern "C" int DLLEXPORT CL_ClientUsesSDL()
{
    return 1;
}

The rest is pretty straightforward: if the client provides this function it's used, otherwise the app id and filename checks are used.

Also, given that many mods' source code is unavailable or lost, it might be good to add a liblist.gam entry to force this behavior for mods that use SDL, but that can't be updated to include the fix.

[SamVanheer]

Addendum: the way the engine detects whether a game uses SDL causes it to hide the mouse cursor in VGUI1 menus when m_rawinput is 0. I encountered this issue in Half-Life: Opposing Force Updated.

Edit: turns out this was caused by the workaround for the mouse-stuck-in-box issue which didn't account for VGUI1 making the cursor visible the same way the engine does.

[djdallmann]

Is it possible to make HL use newer SDL2 without breaking hl or potentially getting vac banned? File link, replace file (steam.exe -noverifyfiles). In relation to not having fixed win10 version.

[SamVanheer]

If you run the game with -insecure then VAC won't be enabled when running listen servers but playing on VAC secure servers will still carry the risk of getting banned.

[Frambooisier]

OpenSuse Tumbleweed without raw input option, the mouse feels jittery and loses track when fast mouse movement is applied.