Quote:
Originally Posted by Bugsy
That is very weird, I thought at first it was a problem with your code but I tested it myself and you're correct. get_pcvar_num() is not returning just that one bit yet the cvar is holding the correct value including the bit. I put together a small function for you which basically reads the cvar as a string then converts to a number. It's silly to have to do it that way but get_pcvar_num() isn't working properly so it'll have to do. I don't have time now but I will look into this further and report any findings.
|
Thanks! It seemed I'll probably get the value and cache it during plugin_cfg() or something.
Quote:
Originally Posted by Arkshine
I've searched/debugged a bit and the problem is most likely a loss of precision double -> float. Let me explain.
The bug is not from AMXX, all the native does is returning (int)ptr->value, so the float value converted to an integer.
This float value is set when you register a cvar, in the engine, using Q_atof(). This function itself works fine.
The problem is it returns a float, when you're working with double. The value is right when it's about to be returned, but it's lost precision once it has been converted to float.
I don't know much why and how such things are handled but the problem is that.
Since from the engine, you can't fix directly. It's possible to fix amxmodx by overwriting this value using atof() from the string, in register_cvar native, it will work.
Another way is to use a common way where you use the letters as flags then you could use read_flags() to get the bits sum from the letters.
I don't remember seeing a plugin dealing with such big number in a cvar.
|
Thanks for the additional insight into the problem. I had considered using letter flags, as it would also be easier to configure, but CSW_* weapon constants go up to 32 (CSW_KNIFE is 29), with only 26 characters (unless A = 27, etc?). I'll just use the get_pcvar_string() and str_to_num() solution.
And again, thanks for all the help

.