0000424: bad mouselook center view

(0001577)
Torr Samaho (administrator)
2011-05-08 20:54

From your description I don't really understand what the problem is. Can somebody elaborate? And does GZDoom 323 behave the same?

(0001634)
tm512 (reporter)
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.

(0001635)
capodecima (viewer)
2011-05-15 11:54

tm512: yes, exact , icant say better :)

(0001636)
Torr Samaho (administrator)
2011-05-15 17:33

I still need to know whether GZDoom 323 behaves the same.

(0001637)
unknownna (updater)
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.

(0003123)
unknownna (updater)
2012-04-03 16:19

'http://zdoom.org/Changelog/3511/files [^]'

* Fixed: DEM_CENTERVIEW also needs to reset the LocalViewPitch if it's for the consoleplayer.

'http://zdoom.org/Changelog/3512/files [^]'

* Implement multitick viewpitch centering logic.

(0008790)
fuleco (reporter)
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.

(0009767)
capodecima (viewer)
2014-06-27 23:22

Will be this fixed in 2.0 ?

(0010443)
Watermelon (developer)
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"

(0010449)
capodecima (viewer)
2014-10-10 14:04

I tried this command and it doesnt worked at all.

(0010735)
fuleco (reporter)
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

(0010736)
Watermelon (developer)
2014-10-30 15:37

Can you check if it happens in 2.6.x? (any of the 2.6.x binaries)

I want to see if this patch posted previously:'https://github.com/rheit/zdoom/commit/ee20c2169ee100283c4a1cf7d1d43ab093acf4f1 [^]'
Along w/ the other one, actually fixes this.

(0010740)
fuleco (reporter)
2014-10-30 20:37

no it doesnt happens in 2.6.0

(0011320)
fuleco (reporter)
2015-01-07 18:03

Any news about this bug ? :o

(0011459)
Torr Samaho (administrator)
2015-01-20 18:54

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 (reporter)
2015-01-20 19:03

Nah its still same issue.

(0011461)
Torr Samaho (administrator)
2015-01-20 20:31

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 (reporter)
2015-03-27 13:01

Nobody can. ;_;

(0011905)
Ru5tK1ng (updater)
2015-03-28 04:31

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 (developer)
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 (reporter)
2015-03-28 10:13
edited on: 2015-03-28 10:14

Here you go, hope it works

ZandronumWin32-2.0-alpha-r150328-0918

(0011908)
fuleco (reporter)
2015-03-28 17:02

works but still occur same problem ;_;

(0011912)
Edward-san (developer)
2015-03-28 21:25
edited on: 2015-03-28 21:25

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 (reporter)
2015-03-28 21:35

yes sure

(0011914)
Ru5tK1ng (updater)
2015-03-28 23:13

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 (developer)
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...

(0013250)
Ru5tK1ng (updater)
2015-08-23 18:13

I tested this in 3.0-alpha-150819-2351, and the issue seems to still exist.

(0013255)
Edward-san (developer)
2015-08-23 19:07

Can you be more specific? Does it happen with GZDoom 1.8.6?

(0013262)
capodecima (viewer)
2015-08-24 09:15

No it doesnt happen in GZDoom 1.8.6

(0013303)
Dusk (developer)
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?

(0013304)
capodecima (viewer)
2015-08-29 00:06

10 years later... :D

(0013305)
Ru5tK1ng (updater)
2015-08-29 04:57

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.

(0014281)
capodecima (viewer)
2016-02-01 09:32

So this never get fixed?

(0014296)
Torr Samaho (administrator)
2016-02-02 07:07

Is this still happening in 3.0? It contains the ZDoom fixes mentioned in 0000424:0003123.

(0014300)
capodecima (viewer)
2016-02-02 13:22

Its still there, i tried version you posted on zan couple days ago.

(0014850)
Edward-san (developer)
2016-05-10 22:17

Can you test if this custom binary (thanks WaTaKiD) fixes the issue?

(0014852)
capodecima (viewer)
2016-05-10 22:50

ye this build fixed the problem

(0014853)
Edward-san (developer)
2016-05-10 23:18

Thanks for checking. Made a new pull request with the changes present in the custom build:'https://bitbucket.org/Torr_Samaho/zandronum/pull-requests/95/fixed-the-centerview-ccmd-and-the-demo/diff [^]'

(0014877)
Edward-san (developer)
2016-05-12 10:02

I found an alternative way to handle this which requires less copy-paste. I'd like to see the build of this changeset:'https://bitbucket.org/zandronum/zandronum-sandbox/commits/166999cf2e23e8503dc8d43206dcb7ad7384e6d6 [^]' and verify the fix still works.

(0014886)
WaTaKiD (updater)
2016-05-12 23:46

as requested, here is the second build:'https://www.dropbox.com/s/a99dj8pv0ergv34/zandronum-3.0-r160512-0956-166999c-windows.zip?dl=0 [^]'

(0014902)
capodecima (viewer)
2016-05-14 11:20

Just tested the new watakid's build, its still working flawlessly.

(0014903)
Edward-san (developer)
2016-05-14 11:58

Thanks for checking.

(0014929)
Edward-san (developer)
2016-05-15 11:24

Merged in 3.0 upstream with this changeset:'https://bitbucket.org/Torr_Samaho/zandronum/commits/04d0668846f8 [^]' .

(0014973)
capodecima (viewer)
2016-05-23 14:19

With new build released, the bug is finally gone. Thx guys. LEL

This issue is already marked as resolved. If you feel that is not the case, please reopen it and explain why.
Supporters:	No one explicitly supports this issue yet.
Opponents:	No one explicitly opposes this issue yet.

Issue History
Date Modified	Username	Field	Change
2011-05-01 13:34	capodecima	New Issue
2011-05-01 13:34	capodecima	File Added: mouselook.png
2011-05-08 20:54	Torr Samaho	Note Added: 0001577
2011-05-14 16:51	Torr Samaho	Status	new => feedback
2011-05-15 03:07	tm512	Note Added: 0001634
2011-05-15 11:54	capodecima	Note Added: 0001635
2011-05-15 11:54	capodecima	Status	feedback => new
2011-05-15 17:33	Torr Samaho	Note Added: 0001636
2011-05-15 17:46	Torr Samaho	Status	new => feedback
2011-05-15 18:11	unknownna	Note Added: 0001637
2011-05-15 18:13	unknownna	File Added: Screenshot_Doom_20110515_200503.png
2011-05-16 03:53	unknownna	Note Edited: 0001637	View Revisions
2012-04-03 16:19	unknownna	Note Added: 0003123
2012-06-09 13:22	Torr Samaho	Category	General => Bug
2012-09-05 21:57	Dusk	Status	feedback => acknowledged
2012-09-05 21:57	Dusk	Resolution	open => backport later
2014-05-14 13:23	fuleco	Note Added: 0008790
2014-06-27 23:22	capodecima	Note Added: 0009767
2014-10-09 17:17	Watermelon	Assigned To	=> Watermelon
2014-10-09 17:17	Watermelon	Status	acknowledged => assigned
2014-10-10 00:45	Watermelon	Assigned To	Watermelon =>
2014-10-10 00:45	Watermelon	Note Added: 0010443
2014-10-10 00:45	Watermelon	Status	assigned => feedback
2014-10-10 00:46	Watermelon	Note Edited: 0010443	View Revisions
2014-10-10 14:04	capodecima	Note Added: 0010449
2014-10-10 14:04	capodecima	Status	feedback => new
2014-10-30 15:16	fuleco	Note Added: 0010735
2014-10-30 15:37	Watermelon	Note Added: 0010736
2014-10-30 15:39	Watermelon	Status	new => feedback
2014-10-30 20:37	fuleco	Note Added: 0010740
2015-01-07 18:03	fuleco	Note Added: 0011320
2015-01-20 18:54	Torr Samaho	Note Added: 0011459
2015-01-20 19:03	fuleco	Note Added: 0011460
2015-01-20 20:31	Torr Samaho	Note Added: 0011461
2015-03-27 13:01	fuleco	Note Added: 0011900
2015-03-28 04:31	Ru5tK1ng	Note Added: 0011905
2015-03-28 09:37	Edward-san	Note Added: 0011906
2015-03-28 10:13	DevilHunter	Note Added: 0011907
2015-03-28 10:14	DevilHunter	Note Edited: 0011907	View Revisions
2015-03-28 10:16	Edward-san	Note Edited: 0011906	View Revisions
2015-03-28 17:02	fuleco	Note Added: 0011908
2015-03-28 21:25	Edward-san	Note Added: 0011912
2015-03-28 21:25	Edward-san	Note Edited: 0011912	View Revisions
2015-03-28 21:35	fuleco	Note Added: 0011913
2015-03-28 23:13	Ru5tK1ng	Note Added: 0011914
2015-03-29 15:45	Edward-san	Note Added: 0011916
2015-03-29 15:45	Edward-san	Status	feedback => acknowledged
2015-03-29 15:47	Edward-san	Note Edited: 0011916	View Revisions
2015-04-04 21:17	Arco	Relationship added	child of 0002172
2015-04-05 08:16	WaTaKiD	Target Version	=> 3.0
2015-05-02 11:42	fuleco	Note Added: 0012196
2015-05-02 13:33	Dusk	Note Deleted: 0012196
2015-05-09 13:56	Dusk	Status	acknowledged => assigned
2015-05-09 13:56	Dusk	Assigned To	=> Torr Samaho
2015-05-09 13:59	Dusk	Status	assigned => needs testing
2015-08-23 18:13	Ru5tK1ng	Note Added: 0013250
2015-08-23 19:07	Edward-san	Note Added: 0013255
2015-08-24 09:15	capodecima	Note Added: 0013262
2015-08-28 23:07	Dusk	Note Added: 0013303
2015-08-28 23:09	Dusk	Note Edited: 0013303	View Revisions
2015-08-29 00:06	capodecima	Note Added: 0013304
2015-08-29 04:57	Ru5tK1ng	Note Added: 0013305
2015-09-05 15:08	Dusk	Assigned To	Torr Samaho =>
2015-09-05 15:08	Dusk	Status	needs testing => new
2015-10-07 15:24	capodecima	Note Added: 0013624
2015-10-07 15:58	Dusk	Note Deleted: 0013624
2016-02-01 09:33	capodecima	Note Added: 0014281
2016-02-02 07:07	Torr Samaho	Note Added: 0014296
2016-02-02 13:22	capodecima	Note Added: 0014300
2016-05-10 21:10	capodecima	Note Added: 0014849
2016-05-10 21:17	Dusk	Note Deleted: 0014849
2016-05-10 22:17	Edward-san	Note Added: 0014850
2016-05-10 22:17	Edward-san	Assigned To	=> Edward-san
2016-05-10 22:17	Edward-san	Status	new => feedback
2016-05-10 22:50	capodecima	Note Added: 0014852
2016-05-10 22:50	capodecima	Status	feedback => assigned
2016-05-10 23:18	Edward-san	Note Added: 0014853
2016-05-10 23:18	Edward-san	Status	assigned => needs review
2016-05-12 10:02	Edward-san	Note Added: 0014877
2016-05-12 10:02	Edward-san	Status	needs review => feedback
2016-05-12 23:46	WaTaKiD	Note Added: 0014886
2016-05-14 11:20	capodecima	Note Added: 0014902
2016-05-14 11:20	capodecima	Status	feedback => assigned
2016-05-14 11:58	Edward-san	Note Added: 0014903
2016-05-14 11:58	Edward-san	Status	assigned => needs review
2016-05-15 11:24	Edward-san	Note Added: 0014929
2016-05-15 11:24	Edward-san	Status	needs review => needs testing
2016-05-23 14:19	capodecima	Note Added: 0014973
2016-05-23 22:47	Ru5tK1ng	Status	needs testing => resolved
2016-05-23 22:47	Ru5tK1ng	Resolution	backport later => fixed
2016-05-23 22:47	Ru5tK1ng	Fixed in Version	=> 3.0
2018-09-30 22:02	Blzut3	Status	resolved => closed

Notes
(0001577) Torr Samaho (administrator) 2011-05-08 20:54	From your description I don't really understand what the problem is. Can somebody elaborate? And does GZDoom 323 behave the same?

(0001634) tm512 (reporter) 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.

(0001635) capodecima (viewer) 2011-05-15 11:54	tm512: yes, exact , icant say better :)

(0001636) Torr Samaho (administrator) 2011-05-15 17:33	I still need to know whether GZDoom 323 behaves the same.

(0001637) unknownna (updater) 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.

(0003123) unknownna (updater) 2012-04-03 16:19	'http://zdoom.org/Changelog/3511/files [^]' * Fixed: DEM_CENTERVIEW also needs to reset the LocalViewPitch if it's for the consoleplayer. 'http://zdoom.org/Changelog/3512/files [^]' * Implement multitick viewpitch centering logic.

(0008790) fuleco (reporter) 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.

(0009767) capodecima (viewer) 2014-06-27 23:22	Will be this fixed in 2.0 ?

(0010443) Watermelon (developer) 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"

(0010449) capodecima (viewer) 2014-10-10 14:04	I tried this command and it doesnt worked at all.

(0010735) fuleco (reporter) 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

(0010736) Watermelon (developer) 2014-10-30 15:37	Can you check if it happens in 2.6.x? (any of the 2.6.x binaries) I want to see if this patch posted previously:'https://github.com/rheit/zdoom/commit/ee20c2169ee100283c4a1cf7d1d43ab093acf4f1 [^]' Along w/ the other one, actually fixes this.

(0010740) fuleco (reporter) 2014-10-30 20:37	no it doesnt happens in 2.6.0

(0011320) fuleco (reporter) 2015-01-07 18:03	Any news about this bug ? :o

(0011459) Torr Samaho (administrator) 2015-01-20 18:54	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 (reporter) 2015-01-20 19:03	Nah its still same issue.

(0011461) Torr Samaho (administrator) 2015-01-20 20:31	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 (reporter) 2015-03-27 13:01	Nobody can. ;_;

(0011905) Ru5tK1ng (updater) 2015-03-28 04:31	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 (developer) 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 (reporter) 2015-03-28 10:13 edited on: 2015-03-28 10:14	Here you go, hope it works ZandronumWin32-2.0-alpha-r150328-0918

(0011908) fuleco (reporter) 2015-03-28 17:02	works but still occur same problem ;_;

(0011912) Edward-san (developer) 2015-03-28 21:25 edited on: 2015-03-28 21:25	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 (reporter) 2015-03-28 21:35	yes sure

(0011914) Ru5tK1ng (updater) 2015-03-28 23:13	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 (developer) 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...

(0013250) Ru5tK1ng (updater) 2015-08-23 18:13	I tested this in 3.0-alpha-150819-2351, and the issue seems to still exist.

(0013255) Edward-san (developer) 2015-08-23 19:07	Can you be more specific? Does it happen with GZDoom 1.8.6?

(0013262) capodecima (viewer) 2015-08-24 09:15	No it doesnt happen in GZDoom 1.8.6

(0013303) Dusk (developer) 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?

(0013304) capodecima (viewer) 2015-08-29 00:06	10 years later... :D

(0013305) Ru5tK1ng (updater) 2015-08-29 04:57	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.

(0014281) capodecima (viewer) 2016-02-01 09:32	So this never get fixed?

(0014296) Torr Samaho (administrator) 2016-02-02 07:07	Is this still happening in 3.0? It contains the ZDoom fixes mentioned in 0000424:0003123.

(0014300) capodecima (viewer) 2016-02-02 13:22	Its still there, i tried version you posted on zan couple days ago.

(0014850) Edward-san (developer) 2016-05-10 22:17	Can you test if this custom binary (thanks WaTaKiD) fixes the issue?

(0014852) capodecima (viewer) 2016-05-10 22:50	ye this build fixed the problem

(0014853) Edward-san (developer) 2016-05-10 23:18	Thanks for checking. Made a new pull request with the changes present in the custom build:'https://bitbucket.org/Torr_Samaho/zandronum/pull-requests/95/fixed-the-centerview-ccmd-and-the-demo/diff [^]'

(0014877) Edward-san (developer) 2016-05-12 10:02	I found an alternative way to handle this which requires less copy-paste. I'd like to see the build of this changeset:'https://bitbucket.org/zandronum/zandronum-sandbox/commits/166999cf2e23e8503dc8d43206dcb7ad7384e6d6 [^]' and verify the fix still works.

(0014886) WaTaKiD (updater) 2016-05-12 23:46	as requested, here is the second build:'https://www.dropbox.com/s/a99dj8pv0ergv34/zandronum-3.0-r160512-0956-166999c-windows.zip?dl=0 [^]'

(0014902) capodecima (viewer) 2016-05-14 11:20	Just tested the new watakid's build, its still working flawlessly.

(0014903) Edward-san (developer) 2016-05-14 11:58	Thanks for checking.

(0014929) Edward-san (developer) 2016-05-15 11:24	Merged in 3.0 upstream with this changeset:'https://bitbucket.org/Torr_Samaho/zandronum/commits/04d0668846f8 [^]' .

(0014973) capodecima (viewer) 2016-05-23 14:19	With new build released, the bug is finally gone. Thx guys. LEL