John Kozak

Hi, Tisor I'm not a specialist in models, but attachTo command has an "overload" which accepts a "memory point" as a reference. My guess would be, adding a memory point which moves with the animation and using attachTo with this memory point should do the trick. Probably.

And I vote yes for it :) I don't want to imagine effects myself, I want to have simulations of as many aspects as possible. Poll, anyone?

Set BLUFOR to captive, so that they are not attacked/attack anyone: {if (side _x == west) then {_x setCaptive true;};} forEach allUnits; Remove captive flag: {if (side _x == west) then {_x setCaptive false;};} forEach allUnits; There may be some faulty syntax (writing from work), but I hope, you get the idea.

Imagine a person who never touched physics saying "Substances can be in form other than gas, solid or liquid, that's physics". While he accidentally is spot on - he is still not an authority, unless he actually provides formulae/proof describing that fourth state (plasma, in this case). Why? Because next time he may claim "Moon is made of cheese, that's physics" - with same credibility. The thing about science is that you don't need to possess a degree - you can be a janitor, yet give out formally correct calculations which can survive peer review by corresponding professionals. And if they are correct, they will be correct regardless of author's social status, combat experience and socks color. Yes, that's IMHO the best analogy here... I believe the actual discussion should be continued elsewhere, though. Enough of the OT. Notice, however, when someone does an actual physics calculation instead of saying "its mathematics and its not arguable" - things start to make sense, don't they? :P

I know that. You know that. But 95% of people who flail around with words like "It's physics!!!"/"It's mathematics" don't - that's the point. P.S. Just for clarity - I was referring to 7.62x51, with 8 kg*m/s (10g @ 800 m/s). Equivalent of a soccer ball (400g) moving at 20 m/s - and that's a pretty mild strike. That's the best illustrating analogy I've found so far.

Excellent research! Looks like we need a sweep to verify ballistics of all calibers.

No, I'm just gonna call bullshit on people who talk about math yet don't know a freck about it.

I'm not arguing with the point, I want to see a "not arguable" mathematical proof, according to that post ;-)

O RLY? I see you're a great mathematician. Tell me then, what is the impulse that gets transferred to the body upon such shot?

Link in studios, please. Even if it is not fake, Type III (NIJ Standard-0101.06) armor required to stop a bullet like that is much heavier than what we have in the game.

Placing scripts (especially with foreach) in trigger conditions is a bad practice - it eats FPS. Trigger conditions are checked each frame. Besides, your script will be also compiled each frame. Better off: Activation: OPFOR Present, repeatable Condition (default): this On activation: {_x setDamage 1} forEach thislist;

By the way. I second that.

Sorry to say that, but the problems you describe are mainly thought-up: - We don't have LOD problems or "quick scoping" now. PiP surrounding will not differ - Out of scope refresh rate must be just fixed to 1:1. Solved. - Sway must just be done as it was in the age of old 2D scopes. OR stencil buffer can be used - the PiP texture will fill everything, except the scope itself and its contents. - "People would complain" is just an imaginary problem. You can't talk for all. And what's most cool with PiP approach - it can even potentially work with TI/NVG scopes. You will have correct "green" picture inside and regular picture outside. The only real problem might be the FPS drop - however, current PiP implementation in cars doesn't killl FPS and uses resolution high enough to make scope PiP view work as well. Current implementation, on the other hand, has large problems: - it allows for cheating (utilizing free view to look aroung while zoomed) - it is unrealistic, as outsides of the scope are also zoomed - the sway is backwards, in my opinion. When you look though the scope, you take the aim points as a reference So I'd not say it is better even than the old 2D ones.

That's actually how it is done now in CoD, I believe. And it is what several people (and me) have proposed for the ArmA way back in Alpha. PiP view will be outside the scope, not inside :)

From what I've tried, FPS is totally the same. It's not a good proof though - since overall their engine is several years old (and currently much worse graphics-wise, than ArmA 3). However, I'll bet their PiP actually is of significantly lower resolution - hence so strong blurring filter. It is, however, enough to give the correct feeling of looking through scope (inside area is also brighter slightly, compared to "regular" brightness) and gives an idea of what's happening around. In ArmA, such view can also be rendered with reduced LODs/view distance - don't know if that is possible, but I think it'll not eat much FPS if it's done this way.

Here's a screenshot I have from the latest CoD game: They actually managed to do this right - note the unzoomed but blurred area around the scope. Now, since even CoD has it, can we get this in ArmA? :D

I may repeat some of the points already stated, by here's my personal feedback: Overall, the UAVs/UGVs feel like great added value; however, due to control complexity, mission makers seem to avoid using them in the missions. Reason is, currently a person using UV is totally excluded from the regular gameplay - because even issuing a move order to the UV requires a 3-5 seconds long sequence, let alone if there are multiple UVs. Due to that, for the moment UVs feel more usable as platoon-level general support, instead of being a squad-level force multiplier. I believe, the original intention was the latter. Main problems with common UAVs implementation UAV controls are totally action-based. Every action requires a second to pick in the action menu - which makes it feel somewhat unimmersive and outside of the overall game interface Unpredictability of behavior. If I'm using a Darter drone, I can't just leave it in some position - the AI will guide it away according to his own thoughts. The only way to fix the position of a UAV is to give it a waypoint with corresponding settings, which is time-consuming. UAVs turning their engines on constantly also falls under this category. Slightly clunky controls. For example, to amend the settings on a waypoint, I have to hit a pretty small area with a RMB click. This adds to time consumed and frustration. I also can't connect to a UAV just by selecting from a list or by single button click (what is the point of a context menu with a single item there?) Unavailability of context commands (which was already discussed). For example, I can't order a UGV to go to a specific point or follow me; this requires opening the UAV terminal, which is, again, clunky. It's also not possible to change UAV/UGV behavior without assigning waypoints As was already mentioned, inability to command the vehicle movement while being a gunner. This really hinders effective UGV employment Vehicle-specific problems Greyhawk UAV is unusable as an observation platform - because on LOITER waypoing it flies with max speed and a bank of around 30-40 degrees. This means I can't view the center of the loitering circle with the mounted camera Darter's yaw speed is way too low - quadrotors of this size have a pretty efficient way to control it. Darter is piloted like helicopter, while, actually, its controls must be much more arcadey. Most (even cheap ones) commercial quadrotors have a set of internal electronics (controller + gyroscopes + accelerometers) dedicated to maintaining flight stability and making the controls control the speed instead of acceleration (angles) Darter is way too fragile with respect to collisions. It is a light vehicle with propeller guards, so it should be able to bounce form a wall if flying with low speed (~5-10kph) Suggestions for fixing the UX problems Move UAV controls to the main map, if possible (UAV terminal replaces the GPS anyways) Alternative to p.1: replace the small GPS view with a "tablet computer" dialog (like cTab addon) Add "native" keys for UAV actions - "Open UAV Terminal", "Take controls", "Take turret controls" Add "move UAV there" action in the command menu (which is accessible by pressing ~) Add an icon for the UAV waypoints, which shows the interaction radius, and increase that radius Give the player possibility to chage UAV behavior by using a context menu (same as on waypoints) Make the player connect to UAV just by left click Allow to control UGVs by pressing "move" keys while in turret view Force the UAV AI to not attempt any actions

Yes, you can't throw anything, but you can drop something. Examples: 1.Drop a chemlight to mark SDV position/RV point 2.Drop a smoke grenade to create bubbles on surface and lure the enemy (player) to go investigate. 3.Drop a grenade to commit suicide :) 4.Swim to surface and lob a grenade into a boat next to you That's what I can think of momentarily.

Because in A2, they used military designations, not actual names (=trademarks). Note: Mk16/Mk17, not FN SCAR M4, not Colt M4 M8, not H&K XM8 M249, not FN Minimi etc. In ArmA 3, since the weapons/vehicles in question are not yet in service, they had to follow similar strategy and create fictional designations - otherwise, I guess, the license fees would be quite unliftable :) (this, of course, applies only to weapons which are acquirable outside US military). If you ever launch one of the Tom Clancy's H.A.W.X. series games, you'll notice there's a lot of trademarks of Dassault Aviacion, Eurofighter Consortium, etc. This implies that there were at least negotiations about the use of planes in the game.

Is anything going to be done with the suppressors damage effects, weapon damage and AI reaction to hits? I've just performed a test - a soldier needs to take 6(!) hits of MX (normal) with suppressor, if shot into lower body. Same weapon non-suppressed does it with 3 rounds. I'm not a medical expert, but shouldn't he be in pain shock (aka dead) after 1-2 rounds? This leads to truly stupid situlations like one I was in today - I've stormed into a room with one enemy and started shooting at him with MX SD, center mass, point blank, full auto. He started responding with Mk20. Then it went like this: I started shooting first, so I put two rounds into him Then he started shooting, first round - miss My third round also hits He finishes me with the second shot - his aim didn't even twitch That's plain WTF.

Yes. And gravitation mass/inertia mass equality is also not proven - it's a hypothesis which currently holds true in all known conditions. I know. For the purposes of computing a reasonably-sized body in Earth's gravity it's a precise enough approximation, anyways. But it's immeasurably higher level of discussion and it's certainly not related to people who don't even know the difference between force and torque :) Let alone the movement equations...

The problem is that not every person is listening to what other people saying has the qualifications to understand the explanation can admit to himself he is wrong For example, in the referred ticket about helicopters, ticket reporter tried to explain to me that "center of mass is static, while center of gravity shifts"[1]. So, he basically doesn't know anything even about school physics and is not able to comprehend my explanations - which require understanding of mechanics at the level of university first term. Yet somehow, it turns out it's me who doesn't know physics :) There are a lot of people who present their "I have a feeling it should be so" as "it really is so". Unfortunately, this makes the tracker become a playground for emotion, not logic - and hence, more a place for politics, than for argumentated discussion. Demagogues have a better chance of getting votes... [1] In case you didn't know - that's oxymoron. Center of mass is the center of gravity.

Well, I kind of agree with the removal of auto-rudder (because it was badly tuned and caused oscillations). However, the plane when banking (say, at 30-45 degrees) experiences two effects: It slides in the direction of bank (which is what the auto-rudder must counter) It changes the direction of flight, because the lift (which is roughly perpendicular to the wing plane) has not both vertical and horizontal components. This will force the plane to start gaining negative vertical airspeed (unless pilot pulls the stick) and change horizontal flight direction (the harder the pilot is on the stick, the more) Both effects are currently missing. Agree with that, and the list can actually be continued on and on... (What was said above in response to St. Jimmy) Flaps do not have an effect they should - decreasing the stall speed. It can be especially felt in air combat The aircraft bleeds speed far too easily (although it may be attribited to low T/W ratio of A143's prototype - L-39) There's no visible relation between the plane load and maneuverability etc. Of course, making it all correctly is no easy task. That's why there's not so many good flight sims out there.

Don't mean to spoil the fun here, but there's plenty of tickets claiming to be "for realism", but being exactly the opposite. Example - the "great" ticket about helicopter physics. A lot of people wrap their wrong assumptions under the word "realism". These tickets got a justified downvote for me, OFC. I'm not a new player, but common sense is not a prerogative of veterans.

Welcome back to good old times, Joint Ammo and Magazines :)