|
Notes |
|
|
|
|
From your description I don't really understand what the problem is. Can somebody elaborate? And does GZDoom 323 behave the same? |
|
|
|
(0001634)
|
|
tm512
|
|
2011-05-15 03:07
|
|
|
I believe the problem is with lookspring, when the +mlook key is released, the view often doesn't snap right back to center, usually being just a bit off. |
|
|
|
|
|
tm512: yes, exact , icant say better :) |
|
|
|
|
|
I still need to know whether GZDoom 323 behaves the same. |
|
|
|
(0001637)
|
|
unknownna
|
2011-05-15 18:11
(edited on: 2011-05-16 03:53) |
|
I can confirm this behavior in GZDoom 323 and ZDoom 2.5.0. It happens when I release the bound +mlook key before I've moved the mouse to its final destination, i.e., I'm still trying to look up after releasing the key.
Steps to reproduce:
1. "m_yaw 0; freelook 0; lookspring 1; bind mouse1 +mlook" in the console.
2. Hold +mlook.
3. Look up with the mouse in a fast manner.
4. Release +mlook while still trying to look up with the mouse.
Edit:
Forgot to type "freelook 0" in step 1.
|
|
|
|
|
|
|
|
(0008790)
|
|
fuleco
|
|
2014-05-14 13:23
|
|
|
Any chance this will be fixed in coming version? I know watermelon came with some solution? But dont know if it will really fixed. |
|
|
|
|
|
Will be this fixed in 2.0 ? |
|
|
|
(0010443)
|
|
Watermelon
|
2014-10-10 00:45
(edited on: 2014-10-10 00:46) |
|
Question:
Would this command fix it?
A bind like
bind z "freelook false; centerview; wait 1; centerview"
|
|
|
|
|
|
I tried this command and it doesnt worked at all. |
|
|
|
(0010735)
|
|
fuleco
|
|
2014-10-30 15:16
|
|
I can be more clarify about the problem since i am not sure if Torr Samaho really undestood my problem. This problem happens in every zandronum version and every zdoom version. Only version where i dont noticed this problem is zdoom 2.7.1.
Now about the problem i use toggle mouselook. Which means i must use key for activate mouselook. THe command i use is like this "mouse5=centerview;toggle freelook". Now about the problem when i enable mouselook and i am normaly running around and aiming everything works to time than i whip my mouse fast up or down and disable mouselook same time, my view just lock in wrong position up or down. Centerview doesnt works at all.
This problem happens all time. All i can do is just during using mouselook move my crosshair to center and same time disable mouselook but this is extremely annoying bcz doom is extremely fast and i still must focus on this dumb thing. This problem dont happens in odamex. Pleas fix this in 2.0. :o |
|
|
|
|
|
|
|
(0010740)
|
|
fuleco
|
|
2014-10-30 20:37
|
|
|
no it doesnt happens in 2.6.0 |
|
|
|
(0011320)
|
|
fuleco
|
|
2015-01-07 18:03
|
|
|
Any news about this bug ? :o |
|
|
|
|
|
Can you check if this works any better offline? It contains the ZDoom changes unknownna mentioned in 0000424:0001637. I didn't make any changes to the online handling, so please only check the offline behavior. |
|
|
|
(0011460)
|
|
fuleco
|
|
2015-01-20 19:03
|
|
|
Nah its still same issue. |
|
|
|
|
|
In this case, ZDoom revisions 3511 and 3512 don't seem to be the answer to this problem. Can anybody go through the revision between ZDoom 2.5.0 and 2.6.0, and check when ZDoom fixed this? |
|
|
|
(0011900)
|
|
fuleco
|
|
2015-03-27 13:01
|
|
|
|
|
|
|
I think the third piece to the puzzle is revision 3595: Fixed: The lookup and lookdown buttons should set LocalKeyboardTurner so that the pitch change is interpolated. |
|
|
|
(0011906)
|
|
Edward-san
|
2015-03-28 09:37
(edited on: 2015-03-28 10:16) |
|
r3595, together with r3511 and r3512, are backported in the sandbox, here. Someone should create the win32 executable with these changes and post it here.
Like in Torr's win32 executable, this must be tested only offline.
|
|
|
|
(0011907)
|
|
DevilHunter
|
2015-03-28 10:13
(edited on: 2015-03-28 10:14) |
|
|
|
|
(0011908)
|
|
fuleco
|
|
2015-03-28 17:02
|
|
|
works but still occur same problem ;_; |
|
|
|
|
Just to be clear, did you check in your ini that you use the same mouse settings with zandronum 2.0 and zdoom 2.5/2.6.1?
|
|
|
|
(0011913)
|
|
fuleco
|
|
2015-03-28 21:35
|
|
|
|
|
|
The only other revisions that appear to be related in regards to player, position and prediction are:
3603: Fixed: The player's position was only predicted during the duration of R_SetupFrame().
3636: Move player prediction calls into D_Display().
If someone else wants to take a look at the revisions, start here:
'http://zdoom.org/Changelog?count=50&skip=3150 [^]' |
|
|
|
(0011916)
|
|
Edward-san
|
2015-03-29 15:45
(edited on: 2015-03-29 15:47) |
|
Someone must build bisect win32 binaries of zdoom which have revisions between 2.5 and 2.6.1 to see which revision fixes the issue for fuleco.
Sadly, since the fix for this is not yet clear and the 2.0 release schedule, this must be postponed after 2.0 after all...
|
|
|
|
|
|
I tested this in 3.0-alpha-150819-2351, and the issue seems to still exist. |
|
|
|
|
|
|
|
|
|
No it doesnt happen in GZDoom 1.8.6 |
|
|
|
(0013303)
|
|
Dusk
|
2015-08-28 23:07
(edited on: 2015-08-28 23:09) |
|
Quote from tm512
I believe the problem is with lookspring, when the +mlook key is released, the view often doesn't snap right back to center, usually being just a bit off.
I cannot comprehend capodecima's posts, but the issue tm512 posted seems to be fixed. In fact it works fine for me in 2.1.2.
Can someone (in coherent English, please) confirm this?
|
|
|
|
|
|
|
|
|
|
Essentially the problem only occurs if you are moving the mouse up or down as you release the mlook key. If you do fast mouse movements and release mlook you can see this occur more often. Your view will be slightly high or lower of center. I noticed that in a fresh out of the box GZdoom 1.8.6 this doesn't happen because the screen reset after you release mlook is slower. In 2.1.2, when you release the mlook key, your screen tries to snap back to center while in GZDoom your screen gradually moves into center. Think of the turn180 speed difference between ZD and Zan. |
|
|
|
|
|
|
|
|
|
Is this still happening in 3.0? It contains the ZDoom fixes mentioned in 0000424:0003123. |
|
|
|
|
|
Its still there, i tried version you posted on zan couple days ago. |
|
|
|
|
|
Can you test if this custom binary (thanks WaTaKiD) fixes the issue? |
|
|
|
|
|
ye this build fixed the problem |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Just tested the new watakid's build, its still working flawlessly. |
|
|
|
|
|
|
|
|
|
|
|
|
|
With new build released, the bug is finally gone. Thx guys. LEL |
|
mouselook.png (452,862) 2011-05-01 13:34