Hi Pi, no, this was fixed in November and I can confirm it still works in the current stable build.

The issue persists in the current dev build 1.99.146398 and stable 1.98.

This is a known issue that has been around for years.

I guess you've been lucky then because z-fighting has been always happening to everyone else who has ever played this game.

I'm sure this has always happened to you, just like it has to everyone else. You only just now noticed it.

This is a phenomenon called "z-fighting". It has always happened is certain condititions, and there's no way for you to avoid it.

Your color is incorrectly defined.
https://community.bistudio.com/wiki/Color

Does this happen without RHS?

Make sure you use ASL positions with intersect commands.
In your repro getpos won't work.

Repro:
Empty map.
Place player as UAV Operator.
Preview.
Assemble Darter.
Take controls.
Take off.
Take turret controls.
Turn the turret somewhere.
Release controls.
Activate "AV Camera".

The 2GB is the user-defined amount you can control yourself. It doesn't mean the game won't use more. And it will, around 3GB is normal.

The maxmem limit in the launcher was wrong before. 2047 is the correct max as you can see in the post Wizard linked.

I'm pretty sure this is normal floating-point imprecision which can't really be fixed.
2.6 * 7 - 0.2 isn't exactly 18, but something a little less.

Ah, right you are.
But would it be much different than:

Is this a feature request? In that case, there's a while do loop already.

I'm not sure if this is the same issue:

1. Equip a launcher.
2. Take crouch or standing stance.
3. Move in any way (walk, turn, run etc.)
4. Press prone (toggle)

I checked the second bush, and you're right; it's way too see-through for AI. Not completely invisible though. It just wasn't that obvious in your video, in my opinion.

What's wrong with the second bush? You can see him, so he probably can see you too?

Can't reproduce in the current RC anymore.
Probably because you can now go prone even on steep slopes.

At least the first two bugs are still present in the current 1.64RC (Sep 2).

In T119031#1484047, @TheMasterofBlubb wrote:

Actually there is the option that BI makes a frame limiter for the menus. Space Engineers did that.

Not an issue.
Because this is expected when the GPU is rendering very high fps.
So enable vsync or limit fps externally if you don't want the game to utilize your hardware.

This is a known "problem" of the Arma engine. (unless you're experiencing some rarer issue I haven't heard about).

Your fps is limited by server/CPU performance.

Try putting everything to max in the main menu before joining server. If you get higher gpu usage then the gpu utilization is not the problem.

This is solely based on my experiences on the Arma series, so there might indeed be some utilization issue only in Dayz.

I don't see anything wrong with GPU usage. Probably your cpu or the server is bottlenecking.

Turn every graphic setting to max to get higher utilization.

This sounds like intended behaviour.

"nearestObject [Tank1,'Tank']" means: "the tank nearest to Tank1's POSITION", not "the nearest other tank to Tank1".

Maybe this command could use a little expanding though. Like some commands have an optional parameter for ignored objects ->
"nearestObject [Tank1,'Tank',ignoreObj]"

Can't confirm with the current RC version. 1.56.134375
Worked fine with Marshall and T-100 at least.

edit. NO! Doesn't work after all.
You can move stuff between vehicle inventory and your containers & slots. But if you try to move, for example, NVG from backpack to its slot, icon doesn't appear there. But if you exit the vehicle and open the inventory, the goggles appear correctly assigned to the slot.

If you try to do this with two or more items, only the first will be there after disembarking. Eg. move a helmet to its slot, then NVG, exit, and only the helmet is on your head.

Additionally, after trying to assign a helmet, some other items also stop working, like weapon attachments.

This is already fixed in the current version 1.56.134489

You can access the arsenal from the new 3D editor. Or add it as an user action to the player and preview the mission.

As far as I know, Alt+F4 is the same as closing a program. It sends exactly the same command as clicking the little cross in the corner, or selecting Exit from file menu on some programs. So a separate button wouldn't change the fact that the game can't exit gracefully.
That issue would be worth its own ticket, especially if you can reproduce it reliably.

I don't have this problem, although I always close the game with Alt+F4, usually several times a day. :)

I'm no modder, so I have to ask - in what situation does the Alt+F4 crash the game?

A video from 3 months ago: https://www.youtube.com/watch?v=wrp1ZjiYqAA
Impossible to kill a floating unit. The bullet tracers penetrate his head but don't inflict damage.
There's a small chance of a hit if the target swims up.

Can confirm. Also happens in the current development branch version.

Maybe the reason for ignoring it wasn't the description, repro and video?

You could add them to the original ticket too.

duplicate of http://feedback.arma3.com/view.php?id=14313

This might not be the game's fault.
You could try running some GPU stress test, like Furmark for example, and see if it crashes too.

Actually, you stamina doesn't decrease. When you deplete ammo (or drop something) your load lightens, so the maximum stamina increases and you start regenerating to get it to max.

But you're still right, it is a bug.

At least these two:
"Land_Obstacle_Ramp_F"
"Land_Obstacle_Pass_F"

The ramp is especially crazy.

I tested the main battle tanks, and their "eyes" are really low. Like around 1.30m height, while the actual viewpoints (driver, gunner, commander) are all much higher than that.

Funny thing is that even the tank away from the wall in the attached mission don't know about the other, even though its whole turret is clearly visible from all altitudes. Seems like any part above that 1.3m can't be detected.

edit. added a screenshot of a perfectly hidden tank. Apparently hull-down is very viable tactic...

The tracer lines aren't 100% accurate because the bullet's position is checked only at certain intervals. They're not the actual path of the bullet.
Your image looks like the bullet bounced off the soldier, probably his gun.

There's nothing wrong in the woods. 1.50 fixed all of the issues that I know of, like bushes and trees in the video. The effect of grass was also tweaked for the better.

Today's dev branch:
Changed: profileNamespace and uiNameSpace disabled for allVariables in MP

A video with speed values: https://youtu.be/Jg1-QC0ExFk

I tried with two bushes known to have this issue. Neither made the unit invulnerable any more.
If the fix was some sort of global tweak to materials then I assume all bushes are good now. But if they only changed specific model geometries, then we'll have test all the possible culprits to make sure this is truly solved.

This issue is caused by the game's bullet simulation and some vegetation model geometries:
When a bullet enters a fire geometry (not the same as the visual one) of a bush or a wall for example, the bullet's new trajectory is calculated and it's teleported to the point where it exits the geometry. So if a soldier is inside an object, the engine just doesn't detect an impact, because the bullet simply teleports past all surfaces that could be hit.

As far as I can see there's 4 ways to improve this:

• Change the way bullets are simulated. Which of course is not going to happen. Way too much work.

• Prevent players from entering the bushes. I.e. add a solid block inside them. Although, this might also affect bullet penetration and vehicle impacts adversely. If it doesn't, it could work with some bushes which shouldn't be walkthroughable anyway.

• Make the fire geometries more complex to lower the chance of being in exactly the right position inside them. I think right now some models are pretty simple solid blocks, which are very likely to manifest the issue. They could be more "hollow" to allow bullets to travel freely. Perhaps something like a cylinder with thin walls. This would probably need a new material too, since bullets would penetrate much lower distances.

More complex models might affect performance though.

• Remove the fire geometries completely. This could work in some cases. You wouldn't see any impact effects like falling leaves, and vehicles wouldn't knock them over.

This thread had some comments about it from BE developer: http://forums.bistudio.com/showthread.php?179054-BattlEye-first-Corrupted-data-0000003-then-BattlEye-Stopped-responding

With $able's advice, I managed to resolve it by not using Steam server browser. Using it produced a kick in 90% of the cases.

@mp5gosu: are you certain the manual BE update fixed this for you?

edit. nevermind. I can't seem to get kicked anymore. Something has fixed it.

02-02-2016

Added: New script command flyInHeightASL

https://forums.bistudio.com/topic/140837-development-branch-changelog/?p=2974549

At least for me the Pause key removes vignette.

duplicate to http://feedback.arma3.com/view.php?id=3213 ?

Graying out the invalidated action would also help with small, hard to point, hotspots (are they called that?). You could click it as soon as it becomes valid again after you missed it first time around.

This and removing weapon selection/reloading from action menu would make it much better with very little effort.

"We're going to change the fonts for the game, Launcher and later also other places such as this very website. The goal is to make text look crisper and achieve greater legibility."

http://dev.arma3.com/post/sitrep-00138

Finally! :)

Characters 5689BS on a clear background. Interface size Normal @1280x1024 resolution: http://i.imgur.com/fuigdEw.jpg

None of them readable. Setting the size to Large helps a bit.