MantisBT - Zandronum
View Issue Details
0002054Zandronum[All Projects] Bugpublic2015-01-05 00:072018-09-30 23:30
Ru5tK1ng 
Edward-san 
normalminoralways
closedfixed 
MicrosoftWindowsXP/Vista/7
1.3 
1.41.4 
0002054: A_Playsound and Attenuation
Attenuation of A_Playsound does not seem to work online even though offline in local mode it works as intended. I have attached a wad that illustrates this bug by using a chainsaw's idle sound. Loading up map01 and adding a bot shows that attenuation is working as you move around the map. However, when loaded online, the chainsaw sound goes back to normal range.

Edward-San stated:

'Attenuation code does not handle well attenuation values different from named ones'.
No tags attached.
? echainsaw.wad (183,181) 2015-01-05 00:07
https://zandronum.com/tracker/file_download.php?file_id=1367&type=bug
diff attenuation.diff (2,222) 2015-01-05 12:05
https://zandronum.com/tracker/file_download.php?file_id=1368&type=bug
Issue History
2015-01-05 00:07Ru5tK1ngNew Issue
2015-01-05 00:07Ru5tK1ngFile Added: echainsaw.wad
2015-01-05 01:54Edward-sanNote Added: 0011282
2015-01-05 01:58Edward-sanNote Edited: 0011282bug_revision_view_page.php?bugnote_id=11282#r6313
2015-01-05 09:55DuskNote Added: 0011283
2015-01-05 09:56DuskNote Edited: 0011283bug_revision_view_page.php?bugnote_id=11283#r6315
2015-01-05 09:56DuskNote Edited: 0011283bug_revision_view_page.php?bugnote_id=11283#r6316
2015-01-05 09:58DuskNote Edited: 0011283bug_revision_view_page.php?bugnote_id=11283#r6317
2015-01-05 10:01DuskNote Edited: 0011283bug_revision_view_page.php?bugnote_id=11283#r6318
2015-01-05 10:01DuskAssigned To => Dusk
2015-01-05 10:01DuskStatusnew => needs review
2015-01-05 10:04DuskNote Edited: 0011283bug_revision_view_page.php?bugnote_id=11283#r6319
2015-01-05 10:14DuskNote Edited: 0011283bug_revision_view_page.php?bugnote_id=11283#r6320
2015-01-05 10:17DuskNote Edited: 0011283bug_revision_view_page.php?bugnote_id=11283#r6321
2015-01-05 12:05Edward-sanFile Added: attenuation.diff
2015-01-05 12:06Edward-sanNote Added: 0011284
2015-01-05 12:06Edward-sanNote Edited: 0011284bug_revision_view_page.php?bugnote_id=11284#r6323
2015-01-08 11:27DuskNote Added: 0011331
2015-01-09 19:00DuskAssigned ToDusk =>
2015-01-09 19:00DuskStatusneeds review => new
2015-01-09 21:01Edward-sanNote Added: 0011346
2015-01-09 21:01Edward-sanAssigned To => Edward-san
2015-01-09 21:01Edward-sanStatusnew => assigned
2015-01-09 21:23Edward-sanNote Edited: 0011346bug_revision_view_page.php?bugnote_id=11346#r6366
2015-01-10 16:34cobaltStatusassigned => needs testing
2015-01-10 16:34cobaltTarget Version => 1.4
2015-01-10 16:34cobaltDescription Updatedbug_revision_view_page.php?rev_id=6377#r6377
2015-01-10 16:34cobaltNote Added: 0011357
2015-03-25 21:02Ru5tK1ngNote Added: 0011887
2015-03-25 21:14DuskStatusneeds testing => resolved
2015-03-25 21:14DuskFixed in Version => 1.4
2015-03-25 21:14DuskResolutionopen => fixed
2018-09-30 23:30Blzut3Statusresolved => closed

Notes
(0011282)
Edward-san   
2015-01-05 01:54   
(edited on: 2015-01-05 01:58)
The actual code did not know that it's possible to pass different values of the attenuation than the ATTN_ values, hence the chainsaw would make the server spam continuously "NETWORK_AttenuationFloatToInt: Warning unknown attenuation value".

Imho, we need a compromise between sending less data (we were sending bytes) and keeping enough precision (ie we'd like to distinguish between 3.5 and 3.9, for example). For example, the server could multiply the float value with 1000 and convert it to int, then clamp the value in the unsigned short interval (the attenuation must be positive, so it's okay), then the server will send a Short, not a Byte, then the client would divide the received value by 1000 and convert it to float...

(0011283)
Dusk   
2015-01-05 09:55   
(edited on: 2015-01-05 10:17)
How about this: split half of the byte range to represent limiting attenuations and half to represent broadening ones:

'http://pastebin.com/s5R00fSZ [^]'


#!/usr/bin/env python
def unpack_attn(a):
    if a < -128 or a > 127:
        raise ValueError ('argument out of range')

    if a < 0:
        return (128 + a) / 128.
    else:
        return (a / 19.) + 1

def pack_attn(a):
    if a < 0:
        raise ValueError ('argument is negative')

    if a < 1:
        return int (round (-128 + (a * 128)))
    else:
        return min (int (round ((a - 1) * 19)), 127)

# for a in range (-128, 128):
# print "%d -> %f" % (a, unpack_attn (a))

while 1:
    a = float (raw_input ('> '))
    if a < 0:
        break

    b = pack_attn (a)
    print "Packed: %d" % b
    print "Unpacked: %f" % unpack_attn (b)


If you guys are good with this I could work this into a patch.

(0011284)
Edward-san   
2015-01-05 12:06   
I suggest avoiding doing SBYTE casts uselessly, hence here it is my patch, which uses [0, 255] range instead of [-127,127].

(0011331)
Dusk   
2015-01-08 11:27   
'https://bitbucket.org/Torr_Samaho/zandronum-stable/pull-request/127 [^]'
(0011346)
Edward-san   
2015-01-09 21:01   
(edited on: 2015-01-09 21:23)
I'm not giving up. Server spamming for a legitimate value of attenuation is not an option.

[edit]'https://bitbucket.org/Torr_Samaho/zandronum-stable/pull-request/129/fixed-custom-attenuation-values-did-not/diff [^]'

(0011357)
cobalt   
2015-01-10 16:34   
Issue addressed by commit 3e0f7ff0d4cc: - Fixed: Custom attenuation values did not work online (fixes 2054).
Committed by edward_san [edward-san] on Saturday 10 January 2015 17:04:02

Changes in files:
 docs/zandronum-history.txt | 1 +
 src/network.cpp | 14 ++++++++------
 src/network.h | 1 +
 3 files changed, 10 insertions(+), 6 deletions(-)
(0011887)
Ru5tK1ng   
2015-03-25 21:02   
I tested the latest build (2.0-alpha-150118-1152) and it seems that the new values work. I tested the attenuation with a few integer and float values and they worked fine. Additionally the NETWORK_AttenuationFloatToInt message no longer appeared in the server console.