User Details
- User Since
- Mar 6 2013, 1:34 AM (616 w, 1 d)
May 10 2016
Zeroing a weapon doesn't mean that the peak of the bullet trajectory is at that distance. It just means that the bullet will intersect that point anytime during its flight. In the case of a 50m zero that will be while the bullet is still travelling up, before it hits the peak, and it will at some point further out again hit exactly where you aim.
You are welcome: http://aesirtraining.com/home/wp-content/uploads/2011/05/25-50-100-yard-zero.jpg
Also, no one is voting against making sure that sights and the UI-mentioned zeroing distances correlate, but this ticket isn't about that. This ticket is about that a 300m zero would be wrong, and that's what people are voting down.
Would be good if you could post screenshots of where it happens. All the buildings? Just the control tower? Specific parts?
Since real ballistics already are in the game (although the engine doesn't go as deep as making tumbling effects different depending on projectile speed and what kind of surface is hit), I think this ticket can be closed.
The open area patrols are placed directly in the editor, with a bunch of random placement radius MOVE waypoints and a cycle waypoint, the first waypoint for each patrol having behaviour set to SAFE and speed to LIMITED.
Either it is something that causes the AI to turn into being 'careless', or it is the 'site' modules doing something weird to AI local to them.
Did the problems occur at/near a base or town, or out in the wild?
Some placed patrols are random size (2-4 men). Also all placed 'site' modules are only local to bases and villages/towns.
Edit: Also there are no scripts in the mission that sets AI to careless, so reasonably boils down to either AI FSM getting stuck/shutting down, or low FPS causing AI to dumb down for some reason or another.
In all stances?
Can be worked around until resolved by manually editing the <profileName>.ArmA3Profile file in My Documents\ArmA 3 Alpha.
May 9 2016
For mission makers to disable saving in their missions (since 99% of all missions created shouldn't have it enabled to start with) they can just use the following line in their init.sqf:
enableSaving [false,false];
Either a solution like the above, or at least us have primaryMagazine, secondaryMagazine, and handgunMagazine as commands.
A few grams of metal flying THROUGH the body (i.e not a collision where it instantly transfers all of its energy to the recipient) won't make anything jerk anywhere by the power of the impact.
The only thing that could cause such a jerk is muscular movement in the person being shot.
The softness of the human body makes distribution of energy from impacts very efficient, and also prevents instant energy transfer, instead making it take some time and thus lowering the acceleration of the body as a result of being hit.
Something being 0,02% of your body mass won't have any kind of noticable effect as far as moving the body goes.
If the action/context menu works anything like addAction ( https://community.bistudio.com/wiki/addAction ) a priority change *ought* to be a fairly quick fix.
And also indeed the NLAW is 'reloadable' in the sense that the tube can be sent-back for reloading. You can't reload it in the field.
It's just the same that applies for the AT4.
That way purchases of weapons become cheaper since you can reuse the tubes a few times.
Edit: Temporary sort-of solution http://forums.bistudio.com/showthread.php?150123-INKO-Disposable
johncage, it is not a feature. It is an oversight/compromise that has existed since the M72 LAW in Operation Flashpoint.
Since weapons now have self-contained ammunition the world of disposable launchers has become a lot more simple as far as ArmA3 goes. Scripted adding or removal of ammunition is no longer a requirement.
It would be fantastic if BIS could add a config entry that makes a weapon useless once fired, preventing it from being loaded and fired again. The only thing a 'disposable launcher'-addon or script would require in that case would be the quick throw-away after launch.
Ideally we get this solved by BIS eventually, now that they are halfway there.
Ad hoc solution: http://forums.bistudio.com/showthread.php?150123-INKO-Disposable