I don't mind the night but the flashlight does not work properly while indoors. The beam should cast more ambient light around the room since the beam is bouncing off of lighter or reflective sources. Similar to the way the roads and rails light up when you shine your beam down them; that's how the rooms should light up.

That image with the M4 was in a barrack. I attempted every way I could think of to reach it but no dice. The proximity of the door and walls to the bed prevent prone turning.

Similar situation for me. I was climbing the ladder on the top floor of an apartment building and once I got to the top, it flung the character back down the ladder, causing injury.

I equiped my rifle without turning my light off and the light source remained behind when the device was removed from my hand. In the image you can see that my rifle is equipped(with no flashlight) but the beam is still on the ceiling.

I can confirm that with regular vision, the light bulbs look as though they are burning during daylight. That's not necessarily a bad thing though, because in prior titles, there was never a texture which showed lights on during the day. At least now, it looks more realistic, so long as that texture is replaced when the bulb is destroyed.

The developers have the correct line here. If you guys get what you want, then you would explode, along with all collateral damage if a rocket or grenade goes off near you. Trucks, ammo caches and entire bases could be consumed by stray projectiles.

If anything should be changed, explosives should be chain able to achieve a larger explosion. This can be done with class name checks when a device is positioned to see if another is within a meter or so. If so, an option to chain to the existing object should be presented along with the set timer action.

If it is not chained with the existing, the material should be rendered useless as the consumable material is burned in the blast.

If neither are detonated, the device should be able to be disabled by engineers of any side and added to their own inventory for re-use.

It sounds fine to me. I've heard the insect before, though I can't identify it for certain what it is. Most likely a cicada, locust or different type of cricket/grasshopper than what your use to hearing.

I definitely agree to this. Can you imagine an OPFOR placing a device somewhere, sprinting away to detonate the device and getting KIA before doing so? Imagine then one of the BLUFOR comes along, dodie dodie do,"Ooh, a clacker!" *smiles*, squeezes and blows his team up near where the device was planted. OFPOR achieves goal, even in death.;D

I had this issue as well, notably on the steel, diamond plate walkways of the dome at M-26

I have since discovered that pressing the back key "S" while holding the forward key "W" will lock the slow walk in to allow lateral movement along with the forward. Pressing it again will unlock it. This is certainly an awkward combination but at least it exist. Thank you and sorry for the premature report.

This same misfeature occurred in former titles as well and is not exclusive to rock walls but other obstacles that units can walk over normally. It's very annoying to have the engine stand a unit up at the worst possible time. I think it could be fixed by adding an animation for it because without an animation, its likely the unit will follow the angle of the object if prone is allowed.

On a side note, it's annoying that the player can actually walk over these walls normally without the V step anyhow. If, in the midst of a fire fight, the player approaches the wall too quickly and remains in a combat squat, he promptly steps up onto the wall, in the line of fire rather than using the wall for its intended purpose, cover.

Relax guys. This feature has existed in every BI title since OFP. They'll get it working, just don't argue in the bug report notes.

Hmmm, its true for most buildings. I have discovered a 2 story structure where the glass behaves as expected. You can shoot through either side at any time during the breaking process. First shot reveals no immediate damage, usually. Second shot fractures the glass, third causes bullets holes and more fractures, fourth causes breakage with visible shards(very cool). There was another one story structure(cant recall which one), that allowed damage through it for the first four shots an then no damage after, although it never displayed the breaking process. The others allowed no damage, and displayed no breaking process.
Third shot = http://imageshack.us/a/img715/7346/arma32013030721421236.jpg
Fourth an final shot = http://imageshack.us/a/img59/8099/arma32013030721422029.jpg

This would add no less strain on CPU/GPU than any other particle effects used in the air. It would allow a visible indicator that you actually hit the individual, and if a visible cloud of bloody sea water induces fear into the player of nearby sharks, the game play and their immediate goal would change significantly. Sharks ARE most likely going to arrive soon, since BIS has the animations for fish and using eventhandlers to spawn sharks near the area and pushing them toward the blood cloud can add tremendous strategic layering to a mission designers work.

And to those who claim this is only aesthetics; The whole purpose of the game is aesthetics, it is SUPPOSE to be entertaining.

Tried it with bunnies but they walk through walls and doors. Then I was able to actually view this myself. Captured a video of it.
http://youtu.be/IMgrJekHaVY

No sir, different issue altogether. I am highlighting the lack of power a vehicle has while on an incline, not torque. There will always be a slow down when weight is considered but for a vehicle to come to a complete stop on a gentle slope is not practical at all, especially if you can whip it right around and conquer the incline in reverse.

No, I don't think so. The way it behaves is nothing like past games where the vehicle would slow, but never this bad. I am confident that it's just a config tweak. They'll get it.

Here's another example video captured from a different perspective.
http://youtu.be/5RC9aRicZmM

Sorry guys, I didn't see the search feature before. I'll make sure I check for tags next time.

Its not squeaking but rather the friction sound of rubber tearing at pavement. Not only is it out of place on dirt, sand and grass but it should be reserved for takeoff or abrupt stopping on pavement, when speed decreases rapidly.

I agree with this on the sound transition for the quad bike. There seems to be no smooth transition sounds for gearing up or down yet. It increases in rpms and then quiets to allow the continuous idle sound to be heard before playing another gear rev. The speed doesn't appear to match the sound either.

Looks like it. But frosty submitted his first.

I experienced this with vehicles as well. The vehicles would ride over some boulders without touching their face. Others would allow the vehicle to sink into it. The area that I was messing around in was around the Spartan shield. The rock that allowed my vehicle to sink into it was close to the docks at the village near the Spartan shield.

Just replicated this myself. I placed a fireplace and then circled it with units. Placed some units further away and then lit it with a script. All but one unit within 29 meters began to change back and forth between two animations. The one unit that did not was 28 meters away. Was able to repeat by switching the fire off and on again. Player and AI are both affected.

Hmm, yep, it is the same issue. This one was posted before the issue number you give above. Wouldn't hurt to merge them together, if possible.

AI have always, ALWAYS, gone crazy on elevated terrain such as setpositioned objects. Bridges, piers, dams, etc. It's existed from OFP and I probably one of the lowest priorities to BIS. Too bad though.

I prefer scrolling through actions with my mouse wheel and then selecting the action with my left click mouse button but there is no option to add the user action to the left click mouse button.