Well ok, no worries, I just thought that the maximum carrying capacity was decoupled from its effect on Fatigue or Stamina.
Won't hesitate to post again after this big 1.54 update (great work btw) if it still exists :)
Well ok, no worries, I just thought that the maximum carrying capacity was decoupled from its effect on Fatigue or Stamina.
Won't hesitate to post again after this big 1.54 update (great work btw) if it still exists :)
Of course you can work it that way. That for sure would still be way ahead than continuous floating point modulo 2 then divide by 2 :)
And +1 for that, that's better than nothing.
But the command should clearly state that you are doing your bitwise stuff on the integer conversion of the passed float argument (bitXorAsInt ? intXor ?). Cause who knows, someone might want to use bitwise operation directly on the float bits to retrieve the mantissa or whatever.
So in the end, I personally think that this language missing simple 32bit signed integer is awful, and can only lead to such weird situations + lot of useless performance and precision problem. But the sad thing is, I understand their initial choice for a single SCALAR type, and how it would be hard to introduce integers now given their desire for retro compatibility.
My conclusion : still +1 for your idea via cast, but with explicit indication of this casting via a wise operator name.
We'd obviously need a true Integer type for that, which might not be so much trivial to implement in their engine now that they've been relying on Floats in all their SQF codebase/api for so many years.
+1. I guess in the meantime it is wise to do it manually like this at the very beginning of "initPlayerLocal.sqf" :
_didJIP = _this select 1;
_didJIP spawn {
_didJIP = _this;
waitUntil { !isNull player };
[[[player,_didJIP],"initPlayerServer_bisBugfix.sqf"],"bis_fnc_execvm",false,false] call bis_fnc_mp;
};
A bit late on this issue.
So after some testing, I found that :
Also, I've seen somewhere a developper explain that mass doesn't represent any classic SI unit of mass. It's more of a one-size-fits-all unit of measurement for its global volume plus true mass. So you might have ultralight objects, but if they take half a backpack volume, the arma mass value will represent this fact so you don't stack tons of them.
Finally, if it can interest you, be aware that currently the mass load handling seems inconsistent and buggy, as per my recent issue report found here : http://feedback.arma3.com/view.php?id=26506