galzohar

Try something more simple like the example I mentioned where you can easily keep track of what is going on. That way you can more easily isolate the problem.

After playing with new fatigue for a while, this is what I think needs to be adjusted: - Standard run speed should be reduced to more appropriate speed, and stamina loss rate greatly reduced accordingly. - Sprint should drain stamina slightly faster. - Sprint should be slower. - Sprint speed should depend on weight, since sprint is the maximum speed your soldier can run at, and in real life it would depend on weight (unlike other mods which would be consistent regardless of weight but drain more/less stamina dependent on weight, so that you can keep up with your squad most of the time). - Stamina gain while prone is way too fast while stamina gain while standing and walking is way too slow. Stance should only have a minor affect on stamina gain, and all should have pretty close stamina gain rate to something slightly faster than the current crouch stamina gain rate. - Currently even losing just a little bit of stamina causes extensive weapon sway. The level at which you start seeing significant weapon sway should be slightly increased. - Maximum sway is a bit too much. Especially while crouched (almost the same as standing, should be slightly better). I think it's unreasonable that the default pace is not a "managed" pace, and we need to manually use a rotation to "average it out". Default pace should be made reasonable, and if you want to be extremely fatigue-efficient or extremely fast, then you should have the walk and sprint options. Jogging should not be something you have to toggle on and off to keep fatigue reasonable. Jogging should use jogging pace, and nothing else. Currently it's not that much slower than a sprint, which is in itself too fast. What's even worse is that it seems like the best "rotation" is rotating between jogging and going prone, which makes it even less realistic. Prone fills stamina so fast that you should really just jog for a while, then go prone for a bit to refill, then jog again. Walking fills stamina too slowly to be effectively used in such a "rotation" anyway, which should not have been required in the first place.

I don't have anyone to test with right now, but just make very long loop that does publicVariable on several players. For example, when trigger is activated, publicVaraible a value 10,000 times. The event handler should then just increment a counter (which was initially reset to 0). See if you get exactly 10,000 X number of players (or 1 less than number of players if not on a dedicated) or not.

You missed my point. My point was getting BIS to realize what they need to change in the engine to make such mods not need to do crazy workarounds or compromises to make proper ballistics work. Spartan has the values that the game needs to use to get accurate simulation. However the structure of the configs and the way the game uses them make them impossible to apply in a way that will allow using the same magazine in 2 different weapons without losing authenticity. The mod you linked is just another attempt to trick the broken system BIS implemented. BIS should just fix their system and make everyone's life easier.

Made a post on the dev branch forum for this: http://forums.bistudio.com/showthread.php?188556-initspeed-in-weapon If BIS ignores it (and if I can't find a proper existing feedback tracker ticket for it), I'll open a new one. Please show your support so we can have proper realistic ballistics in-game, if not through vanilla then through mods, because current system requires dirty scripts to even have some kind of a chance to get something realistic working.

While it is nice to have some config in the weapon that affects ballistics, I think this solution is rather subpar. For proper ballistic simulation, we must have the ability to configure all ballistic properties of a bullet in the weapon. The magazine and bullet itself should be rather blank in terms of used ballistic config properties (or keep them for weapons that use the old configuration, but update all weapons to use the new configuration and encourage modders to do the same). As you can see in this thread: http://forums.bistudio.com/showthread.php?173466-ArmA-III-Ballistics-Overhaul Each barrel length and ammunition requires changing several values to get accurate representation. Current dev branch system does not even allow for bullet specific velocity - Just weapon specific velocity or a veclocity multiplier, neither are good enough for velocity, on top of needing to be able to configure additional properties in the wepaon to get accurate ballistic representation in-game. If there are already adjustments being made to allow for proper weapon-specific ballistics, might as well go as far as it takes to make things possible to do right. In the end, I don't think that's too much to ask.

That implementation is still pretty horrible, though. Not only the other values are missing, they aren't actually magazine specific (unless you use a multiplier, which won't work realistically enough). Is there a tracker ticket already open for this or should we open a new one?

It seems like you would still have the issue of 2 weapons that use the same magazine have the same velocity. For example, fixing the 5.56 magazine will only fix it for 1 barrel length, and ruin it for the other barrel length. It's definitely something that should have been fixed by BIS 3 games ago. I was thinking of scripted workaround to set the velocity of the bullet, but was hoping someone was smarter than that. As this had always been an issue I assumed there were already somewhat proper working solutions in place already.

Another quick question: How do you handle the fact muzzle velocity is defined in the magazine? I noticed the values don't have anything specifying the muzzle velocity (typicalSpeed is apparently only for damage calculation and doesn't affect muzzle velocity at all)? Even if you script it to modify velocity to the typicalSpeed value with a "fired" event handler, it will still not be magazine-specific. Which mods use these values properly and have a non-binarized config that I can actually look at? Thanks.

Also, currently a US rifleman needs 4 shots to the chest to kill another US rifleman, but only 2 shots to the leg.

Is there anything in RHS modifying infantry damage other than changing the armor values?

https://community.bistudio.com/wiki/date https://community.bistudio.com/wiki/time

That works for the class tree, but breaks when I change to weapons, it just goes to ACE with ACEX :(

I figured out the armor fiasco, quick summary in case anyone is interested why their armor values are not representative of survival capability: Apparently, there is another value, "passthrough", which tells the game how much damage is passed from the "body" hit to the whole soldier. High passthrough value makes armor useless, since while your "body" takes low damage your "overall" would take high damage and you will die anyway. The damage passed via the "passthrough" parameter is completely ignoring the "armor" value. Low "passthrough" value will mean your "overall" takes little damage, but your body still takes damage that you won't see with the damage command, and that amount does depend on your armor. As "passthrough" value is not displayed on the arsenal, you can get inconsistent performance for armor - High armor can still be horrible and rather low levels of armor can still be a lot more effective than they seem. I am actually working on a script that would make "passthrough" value irrelevant, so that armor values can be tweaked for realistic level of armor protection and overall damage.

Ignore % usage, it is almost completely meaningless if you don't have access to the internals of the game code. With SLI you shouldn't try to see if you get more FPS, but instead try see if you can increase the settings more without losing FPS. That is, find the max settings you can use without losing FPS, then try do the same with SLI. If you just look at your FPS with the same settings you might not see an increase due to CPU. Another way to greatly reduce the effect of CPU is to make an empty single player mission and test FPS on that - That way you have very little CPU bottle-necking and your FPS will depend almost entirely on your GPU/SLI power.

Thanks, will try implement something like that. What is the purpose of the for "_i" from 0 to 0? Is this just a leftover from the original script or does the inner loop modify _i in the outer scope? I usually just try to avoid these questions by not using the same variable name twice in the same function and only use for loops for loops with a pre-determined trip count, so I don't really know how these cases would behave... Additionally, I want head/body to pass more damage to the overall damage than hands/legs. Is there any way to do it while keeping it compatible with potential mods that add new units? Or will it require using a new config value that new units with new hit locations will need to define for the script to work?

Are you sure it was working at 5.1 and not just stereo?

Thanks! But is it really necessary to create arrays from config after every shot? Wouldn't it be better to check if uniform changed since last time and store the values for future use only when uniform changes? Or is this so performance inexpensive it's not worth bothering with? Considering it gets triggered on every handleDamage event handler.

A script to remove stolen radios is a really simple solution. TACBF already runs scripts to remove excessive grenades and other forbidden equipment, it's just an extra item to check (although will be smoothest if it can use a TFAR function to perform the check). If BIS fixed the bug, you can even remove the radios from the dead bodies when a soldier dies, but then you won't be able to take over the (friendly) SL/radioman's long-range radio when he dies or to take ammo from his backpack.

The problem with something like this is that the damage of the suppressor is on the player and not on the suppressor, so giving an almost broken suppressor to a buddy would result in him having a fully functional suppressor. As far as I'm aware it is unfortunately not possible to setVariable on an item/weapon/attachment/magazine. You may wish to add a feedback tracker request (or find an existing one) for it and post a link so we can vote on it.

Obviously this would be vehicle-specific, and be some sort of weighted sum of the bunch. The main purpose is adjusting how infantry armor protection works, and for that some kind of formula like 0.8 * body damage + 0.8 * head damage + 0.12 * leg damage + 0.12 * hand damage (may need tweaking) can work. To make it more generic of course config values would need to be added to every vehicle, but that is out of the scope right now. Getting infantry to work in a more consistent fashion is the primary objective. This is the script I'm testing right now which seems to work: galz_fnc_realDamageHandler = { private ["_unit", "_selection", "_newDamage", "_projectile", "_oldHeadDamage", "_oldBodyDamage", "_oldHandsDamage", "_oldLegsDamage"]; _unit = _this select 0; _selection = _this select 1; _newDamage = _this select 2; _projectile = _this select 3; diag_log format ["%1 %2", str _this, if (_selection != "") then {p1 getHit _selection} else {getDammage p1}]; _retVal = _newDamage; // Disable default damage handling to "" selection (overall damage). It's handled later. if (_selection == "") then { _retVal = damage _unit; } else { // Only handle damage if there is an actual projectile. // Not sure what triggers handleDamage without a projectile. if (!isNull _projectile) then { _addedOverallDamage = _newDamage - (_unit getHit _selection);; if (_selection == "head" || _selection == "body") then { _addedOverallDamage = _addedOverallDamage * 0.8; } else { _addedOverallDamage = _addedOverallDamage * 0.12; }; if (_addedOverallDamage > 0.01) then { // Save old selection damage. _oldHeadDamage = _unit getHit "head"; _oldBodyDamage = _unit getHit "body"; _oldHandsDamage = _unit getHit "hands"; _oldLegsDamage = _unit getHit "legs"; // Set overall damage. diag_log format ["old damage: %1, new damage: %2, selection: %3", damage _unit, (damage _unit) + _addedOverallDamage, _selection]; _unit setDamage ((damage _unit) + _addedOverallDamage); // Restore part damage. _unit setHit ["head", _oldHeadDamage]; _unit setHit ["body", _oldBodyDamage]; _unit setHit ["hands", _oldHandsDamage]; _unit setHit ["legs", _oldLegsDamage]; }; }; }; _retVal }; p1 addEventHandler ["handleDamage", {_this call galz_fnc_realDamageHandler}];

In DTAS you play US vs Insurgents basically, though every team gets to play both sides (mission is round-based). We currently run events every Saturday at 18:00 GMT, as advertised in the Arma 3 PvP Community Steam group.

Vests definitely do provide protection, or else a chest shot would be a 1 shot kill with any weapon (since the base damage of basically all weapons is high enough to 1-shot anyone to the chest if he has 0 armor on his body armor).

RH_acc is now missing on Play withSIX, had to adjust mod list manually :(

The problem is that I want to change the damage passed to the "" selection based on the damage dealt to the parts via a script function, and work around the "passthrough" config value. Since the "" selection is triggered before the other selections, I unfortunately can't just modify that because at that point the information for the specific part damage still does not exist. A dirty alternative suggested by Adanteh is to setDamage and then setHit on all the parts back to what they were before, effectively setting the damage to the "" selection.