my mouse buttons "bounce".
Long story short, they "double-click" on they're own. I would say on average 75% of the times.
It makes it difficult to use manual shifting, as you can imagine (left-up, right-down).
To (almost) solve this problem I've made a little change in src/libs/robottools/rthumandriver.cpp. I've added a 50ms pause to wait for the micro-switches to settle:
/* Up shifting command */if((cmd[CMD_UP_SHFT].type==GFCTRL_TYPE_JOY_BUT&&joyInfo->edgeup[cmd[CMD_UP_SHFT].val])||(cmd[CMD_UP_SHFT].type==GFCTRL_TYPE_MOUSE_BUT&&mouseInfo->edgeup[cmd[CMD_UP_SHFT].val])||(cmd[CMD_UP_SHFT].type==GFCTRL_TYPE_KEYBOARD&&keyInfo[lookUpKeyMap(cmd[CMD_UP_SHFT].val)].edgeUp)||(cmd[CMD_UP_SHFT].type==GFCTRL_TYPE_JOY_ATOB&&cmd[CMD_UP_SHFT].deadZone==1)){if(car->_gear>-1&&car->_gear<car->_gearNb-1){usleep(50000);//****<<<----- debounce ****car->_gearCmd++;}elseif(HCtx[idx]->seqShftAllowNeutral&&car->_gear==-1)car->_gearCmd=0;/* always allow up shift out of reverse to improve game play */elseif(car->_gear==-1)car->_gearCmd=1;}/* Down shifting command */if((cmd[CMD_DN_SHFT].type==GFCTRL_TYPE_JOY_BUT&&joyInfo->edgeup[cmd[CMD_DN_SHFT].val])||(cmd[CMD_DN_SHFT].type==GFCTRL_TYPE_MOUSE_BUT&&mouseInfo->edgeup[cmd[CMD_DN_SHFT].val])||(cmd[CMD_DN_SHFT].type==GFCTRL_TYPE_KEYBOARD&&keyInfo[lookUpKeyMap(cmd[CMD_DN_SHFT].val)].edgeUp)||(cmd[CMD_DN_SHFT].type==GFCTRL_TYPE_JOY_ATOB&&cmd[CMD_DN_SHFT].deadZone==1)){if(car->_gear>1){usleep(50000);//****<<<----- debounce ****car->_gearCmd--;}elseif(HCtx[idx]->seqShftAllowNeutral&&car->_gear==1)car->_gearCmd=0;elseif(HCtx[idx]->seqShftAllowReverse&&car->_gear<2)car->_gearCmd=-1;}
I think it stops the whole game, including the simulation, so the only downside I can see is the slight stutter when shifting gears.
But maybe in a multi-threaded environment could cause problems involving the simulation itself.
One interesting fact is that TORCS somehow doesn't give me the same problem. I've tried to understand and looked for some "delaying" mechanism, but couldn't find one.
I thought about opening an "issue" on the git repository but it's almost certainly nobody's else problem and, in the end, my only concern is about "fair playing".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Portability issues with usleep(3) aside, I do not think it is a good
idea to usleep(3) the thread for that purpose, since as you already know
that would block other essential logic from running.
If you really want to do that, I would suggest to keep a timestamp of
the last pressed button (e.g.: via GfTimeClock()), store it somewhere
into the HumanDriver class and compare against future timestamps until
the minimum time threshold is met. While probably not the most elegant
solution, it should fix your issue while not blocking the thread.
On the other hand, I also assume no other users would want to keep this
patch because it works around very specific hardware limitations, so in
my opinion it is more sensible to keep it in your personal branch.
Best regards,
Xavi
On 6/4/25 5:02, Lino Banfi wrote:
Hello everyone,
my mouse buttons "bounce".
Long story short, they "double-click" on they're own. I would say on
average 75% of the times.
It makes it difficult to use manual shifting, as you can imagine
(left-up, right-down).
To (almost) solve this problem I've made a little change in
|src/libs/robottools/rthumandriver.cpp|. I've added a 50ms pause to wait
for the micro-switches to settle:
|/ Up shifting command /
if((cmd[CMD_UP_SHFT].type==GFCTRL_TYPE_JOY_BUT&&joyInfo->edgeup[cmd[CMD_UP_SHFT].val]) ||(cmd[CMD_UP_SHFT].type==GFCTRL_TYPE_MOUSE_BUT&&mouseInfo->edgeup[cmd[CMD_UP_SHFT].val]) ||(cmd[CMD_UP_SHFT].type==GFCTRL_TYPE_KEYBOARD&&keyInfo[lookUpKeyMap(cmd[CMD_UP_SHFT].val)].edgeUp) ||(cmd[CMD_UP_SHFT].type==GFCTRL_TYPE_JOY_ATOB&&cmd[CMD_UP_SHFT].deadZone==1)) { if(car->_gear>-1&&car->_gear<car->_gearNb-1){ usleep(50000);//*<<<----- debounce car->_gearCmd++; } elseif(HCtx[idx]->seqShftAllowNeutral&&car->_gear==-1) car->_gearCmd=0; / always allow up shift out of reverse to improve game play / elseif(car->_gear==-1) car->_gearCmd=1; } / Down shifting command / if((cmd[CMD_DN_SHFT].type==GFCTRL_TYPE_JOY_BUT&&joyInfo->edgeup[cmd[CMD_DN_SHFT].val]) ||(cmd[CMD_DN_SHFT].type==GFCTRL_TYPE_MOUSE_BUT&&mouseInfo->edgeup[cmd[CMD_DN_SHFT].val]) ||(cmd[CMD_DN_SHFT].type==GFCTRL_TYPE_KEYBOARD&&keyInfo[lookUpKeyMap(cmd[CMD_DN_SHFT].val)].edgeUp) ||(cmd[CMD_DN_SHFT].type==GFCTRL_TYPE_JOY_ATOB&&cmd[CMD_DN_SHFT].deadZone==1)) { if(car->_gear>1){ usleep(50000);//<<<----- debounce * car->_gearCmd--; } elseif(HCtx[idx]->seqShftAllowNeutral&&car->_gear==1) car->_gearCmd=0; elseif(HCtx[idx]->seqShftAllowReverse&&car->_gear<2) car->_gearCmd=-1; } |</car->
I think it stops the whole game, including the simulation, so the only
downside I can see is the slight stutter when shifting gears.
But maybe in a multi-threaded environment could cause problems involving
the simulation itself.
One interesting fact is that TORCS somehow doesn't give me the same
problem. I've tried to understand and looked for some "delaying"
mechanism, but couldn't find one.
I thought about opening an "issue" on the git repository but it's almost
certainly nobody's else problem and, in the end, my only concern is
about "fair playing".
as side, unrelated note:
while rummaging torcs, i had the feeling that it has better damage scaling,
i have absolutely no experience in driving cars over the city's speed limits, but i think that car accidents have greater consequences than those in speeddreams.
in torcs feels... righter.
or maybe it's just a gameplay decision.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello everyone,
my mouse buttons "bounce".
Long story short, they "double-click" on they're own. I would say on average 75% of the times.
It makes it difficult to use manual shifting, as you can imagine (left-up, right-down).
To (almost) solve this problem I've made a little change in
src/libs/robottools/rthumandriver.cpp. I've added a 50ms pause to wait for the micro-switches to settle:I think it stops the whole game, including the simulation, so the only downside I can see is the slight stutter when shifting gears.
But maybe in a multi-threaded environment could cause problems involving the simulation itself.
One interesting fact is that TORCS somehow doesn't give me the same problem. I've tried to understand and looked for some "delaying" mechanism, but couldn't find one.
I thought about opening an "issue" on the git repository but it's almost certainly nobody's else problem and, in the end, my only concern is about "fair playing".
Hi Lino,
Portability issues with usleep(3) aside, I do not think it is a good
idea to usleep(3) the thread for that purpose, since as you already know
that would block other essential logic from running.
If you really want to do that, I would suggest to keep a timestamp of
the last pressed button (e.g.: via GfTimeClock()), store it somewhere
into the HumanDriver class and compare against future timestamps until
the minimum time threshold is met. While probably not the most elegant
solution, it should fix your issue while not blocking the thread.
On the other hand, I also assume no other users would want to keep this
patch because it works around very specific hardware limitations, so in
my opinion it is more sensible to keep it in your personal branch.
Best regards,
Xavi
On 6/4/25 5:02, Lino Banfi wrote:
Hi Xavi,
your solution might not be optimal but it works perfectly, and perfection is good enough for me.
Thank you very much for the suggestion!
as side, unrelated note:
while rummaging torcs, i had the feeling that it has better damage scaling,
i have absolutely no experience in driving cars over the city's speed limits, but i think that car accidents have greater consequences than those in speeddreams.
in torcs feels... righter.
or maybe it's just a gameplay decision.