Voice: safe guard against invalid DB volume values

[EntranceJew]

maybe fixes #1334 if the database stuff doesn't

[ZenBre4ker]

This shouldnt be necessary. As far as I can see, when the sql.query returns nil or anything else, its always converted to a number in VOICE.GetPreferredPlayerVoiceVolume. Therefore I believe, that the scalingfunction could be the problem. Maybe just add an
out_vol = func( vol ) or vol or 1

[saibotk]

We should fix the root cause of this instead of a bandaid patch.
Maybe check the scaling function result?

But if this already affects users im happy to merge to mitigate weird db values from impacting users

[ZenBre4ker]

I tested all three scaling functions with weird values and it seemed fine, linear is also default, which also just puts out_vol = vol, therefore the error is rather in an overwrite of a function.The sql table getter outputs well defined numbers in any case.

Im not fan of this fix, as it might not neutralize the problem itself. In case the db is fine, we have a database write everytime someone starts talking.

[EntranceJew]

The code that I made is pretty airtight, and all the checks have been working flawlessly for users on a server with an existing database and for users client-sided in a new database that were specifically set up to join and play.

I can't find a reason why this would happen. All the checks that are in place are designed to minimize the amount of values flowing into C functions and to the database, but still have the potential to update dynamically to prevent a player from being dramatically louder or quieter between circumstances.

The only probable causes in my mind are:

• numeric comparison precision accuracy problems?
• database type coercion?
• a client or server has a read-only database and thus has the schema but not the new records

[ZenBre4ker]

In case this should be worked on again. IMO we should just implement a default value with or in case of nil. I'm against setting the value, because it could be something else is broken and this code just wirtes to the db everytime nil comes up. It's not safe to say, that by setting the preferred value, that the actual error will be fixed in the next call.

[EntranceJew]

This shouldnt be necessary. As far as I can see, when the sql.query returns nil or anything else, its always converted to a number in VOICE.GetPreferredPlayerVoiceVolume. Therefore I believe, that the scalingfunction could be the problem. Maybe just add an out_vol = func( vol ) or vol or 1

I don't think so. Similar to the shop issues we discussed, the only scaling function that could have this flaw is linear, but that is because the data is arriving to it as a string and not a number. The existing conditions assume nil or a falsey value which is not the expected number. Why would something recorded as a numeric type be permitted to come back as a string?