This post has been edited by ph3n0m: 01 December 2011 - 04:01 PM
Advertisement
[Suggestion] Hitting Sounds - A Comprehensive List Of Additions
#21
Posted 01 December 2011 - 04:00 PM
A more important priority, before they change anything regarding the type and other aspects of hitsounds, is to reprogram it so that no hitsounds are given AT ALL EVER until a hit has been confirmed by the server. This might eliminate a majorly overlooked problem in urban terror (that frozen sands is in denial about?) of getting hitsounds but no hits, or less hits than are indicated by the amount of hitsounds actually played. Inarguably, any system that emits a noise as a confirmation that an event has occurred, might ACTUALLY CHECK if the event registered as having occured or not on the server FIRST (aka REALITY) . It will also significantly reduce (but not eliminate) the other far-too-common and related major flaw in urban terror code, where not only are incorrect hitsounds given when a hit did not infact register, but often whatever the amount of false hitsounds is in that particular situation, always equals exactly to the amount of hits your enemy got on you and also the location YOU shot is always exactly where you get hit. More often than not, this takes place when you fire up to 5 bullets (never more) before the enemy actually reacts to shoot the amount of bullets that supposedly killed you. This goes against several laws of physics - being shot with ANY amount of bullets and dying from them in a shorter peried of time than it takes to physically fire those bullets. If someone is already in a firefight and not facing your direction, hitting them once, hearing the confirmed hitsound, perhaps waiting a second, then firing again, only to die moments later, check the console that see they hit you exactly the same amount of times you shot, and ALSO in the same parts of the body, sometimes seconds passing by without registering this somehow mind you, and you hit nothing, hear 5 hitsounds that you hit them, then drop dead instantly, then watch them finish their firefight and turn towards you AFTER your dead. Also to be noted is that when this happens it always skips the death animation sequence, and none of these events show up on the lagometer, even with mistubishi's optimised exe. Add each players pings and other factors into the equation and this seems to violate physics EVEN more somehow. Lastly, hits are often out of order in the console, such as hitting a person after you killed them, or getting the first 4 hits in, getting hitsound confirmations of this, then dying, only to see in the console that they hit you 3-5 times before you even shot , tho the damage didnt show or 'hit you' until much later (in excess of 1000ms no matter server or what the 2 players pings are). Through years of careful observation, recording and reviewing thousands of demos, i believe these 3 problems are related, but will never be fixed if they are constantly and forever denied, skirted around and misdirected to ridiculous factors, therefore they will never be fixed full stop, or they would have been at least acknowledged years ago and a resolution discussed or looked into (AT LEAST), then confirmation to the community that its being looked into. Apparrently its everyones power supply that is causing these problems..I can only roll my eyes so much before my disdain kicks in...
#22
Posted 01 December 2011 - 05:21 PM
ph3n0m, on 01 December 2011 - 04:00 PM, said:
This might eliminate a majorly overlooked problem in urban terror (that frozen sands is in denial about?) of getting hitsounds but no hits, or less hits than are indicated by the amount of hitsounds actually played. Inarguably, any system that emits a noise as a confirmation that an event has occurred, might ACTUALLY CHECK if the event registered as having occured or not on the server FIRST (aka REALITY) .
Actually the solution is not to fix the sounds but to fix hit detection which we did by switching over to MD5 and completely rebuild detection from scratch.
doing "stuff" with dead things.
#24
Posted 01 December 2011 - 10:16 PM
Frankie V, on 01 December 2011 - 05:21 PM, said:
Actually the solution is not to fix the sounds but to fix hit detection which we did by switching over to MD5 and completely rebuild detection from scratch.
this sounds promising does the latest beta have this to try out and see what the difference is like?
Lian Li pc-o11dw Der 8auer Edition · Gigabyte x570 Aorus Xtreme · AMD Ryzen 9 5950x 16-Core
32GB DDR4 3800MHz CL16 · 2x 1TB Samsung NVMe RAID 0 · 16GB Radeon RX 6900XT Liquid Cooled
32GB DDR4 3800MHz CL16 · 2x 1TB Samsung NVMe RAID 0 · 16GB Radeon RX 6900XT Liquid Cooled
#25
Posted 02 December 2011 - 11:05 AM
ph3n0m, on 01 December 2011 - 04:00 PM, said:
A more important priority, before they change anything regarding the type and other aspects of hitsounds, is to reprogram it so that no hitsounds are given AT ALL EVER until a hit has been confirmed by the server. This might eliminate a majorly overlooked problem in urban terror (that frozen sands is in denial about?) of getting hitsounds but no hits, or less hits than are indicated by the amount of hitsounds actually played. Inarguably, any system that emits a noise as a confirmation that an event has occurred, might ACTUALLY CHECK if the event registered as having occured or not on the server FIRST (aka REALITY) . It will also significantly reduce (but not eliminate) the other far-too-common and related major flaw in urban terror code, where not only are incorrect hitsounds given when a hit did not infact register, but often whatever the amount of false hitsounds is in that particular situation, always equals exactly to the amount of hits your enemy got on you and also the location YOU shot is always exactly where you get hit. More often than not, this takes place when you fire up to 5 bullets (never more) before the enemy actually reacts to shoot the amount of bullets that supposedly killed you. This goes against several laws of physics - being shot with ANY amount of bullets and dying from them in a shorter peried of time than it takes to physically fire those bullets. If someone is already in a firefight and not facing your direction, hitting them once, hearing the confirmed hitsound, perhaps waiting a second, then firing again, only to die moments later, check the console that see they hit you exactly the same amount of times you shot, and ALSO in the same parts of the body, sometimes seconds passing by without registering this somehow mind you, and you hit nothing, hear 5 hitsounds that you hit them, then drop dead instantly, then watch them finish their firefight and turn towards you AFTER your dead. Also to be noted is that when this happens it always skips the death animation sequence, and none of these events show up on the lagometer, even with mistubishi's optimised exe. Add each players pings and other factors into the equation and this seems to violate physics EVEN more somehow. Lastly, hits are often out of order in the console, such as hitting a person after you killed them, or getting the first 4 hits in, getting hitsound confirmations of this, then dying, only to see in the console that they hit you 3-5 times before you even shot , tho the damage didnt show or 'hit you' until much later (in excess of 1000ms no matter server or what the 2 players pings are). Through years of careful observation, recording and reviewing thousands of demos, i believe these 3 problems are related, but will never be fixed if they are constantly and forever denied, skirted around and misdirected to ridiculous factors, therefore they will never be fixed full stop, or they would have been at least acknowledged years ago and a resolution discussed or looked into (AT LEAST), then confirmation to the community that its being looked into. Apparrently its everyones power supply that is causing these problems..I can only roll my eyes so much before my disdain kicks in...
Here you go. Make good use of it.
Advertisement
#27
Posted 03 December 2011 - 05:46 PM
jesus christ, I cant read that. Use the enter key, it's there for some reason.
[img]http://i.imgur.com/kweKQ.png[/img]