Additionally, the zoom in and zoom out toggle conflict with each other.
For example, the sequence: zoom in toggle, zoom out toggle, either zoom in or zoom out will cause unexpected behavior (zoom out toggle will not go back to normal, and zoom in toggle will not zoom in at all).

Happens relatively often in DTAS, though still difficult to reproduce.

https://forums.bistudio.com/topic/144440-dynamic-take-and-secure-randomized-round-based-no-respawn-ad/

Default doesn't matter. Like you said, it's same as allowDamage and enableFatigue which are default on. Double negation is just outright bad idea.

Yes, using paramsArray in init field may fail now.

As a workaround, spawn/execVM a script with:
waituntil {!isNil "paramsArray"};

However, this workaround prevents being able to properly set the date on the server based on parameters.

Yeah it broke DTAS mission too, had to create workarounds.

Calling a script from init line of a game object makes it unavailable, but using it in init.sqf it is available immediately.

50% more sustaonabiloty along with 20% faster speed results in insane advantage. This is anything but the tiny difference it should have been.

"Slightly" would have been reasonable (but even then, you would need to be given that option regardless of whether or not you have binoculars). However currently the difference is quite extreme on the fatigue aspect, and pretty big on the speed aspect.

How does having realistic running speeds and fatigue that don't depend on having binoculars make it more difficult to just hop in and play? It's really completely unrelated.

In this case, though, the realism can easily be proven with a simple experiment in real life, simply because it is so absurd in-game. Just go out with a stick in your hand and a backpack with 20-30kg of books. Then repeat with the stick tied to your backpack, but run multiply the distance by 3 (not sure what the exact ratio is in-game, but it's very significant). Now tell me what was REALLY easier.

If you haven't realized it yet, this is abused repeatedly on every server that allows it. Since real soldiers don't do that, you must be wondering why. The reason isn't that "in a game, people prefer to run faster and are wiling to take the risk". It simply isn't.

While I agree with 21070, they aren't directly related.

Running without a weapon is also too fast. And not only is it too fast, it is extremely forgiving on the fatigue side of things. There is no justification for being able to run many times longer distance and 20-33% faster just because you placed your weapon on your back. It's outright outrageously unrealistically stupid, and it's being blatantly abused on every server that gives the player a pair of binoculars.

Killzone, you are missing the point. Running with binoculars out in Arma is *unrealistically effective*. This is why people do it in Arma and don't do it in real life. In real life it's simply not anywhere near as effective. Also, in real life it doesn't require owning a pair of binoculars.

If you don't like fatigue, complain about fatigue. But binoculars shouldn't be your solution to working around the fatigue system. There are better ways to disable fatigue in a mission, for those who don't like it.

Running with binoculars shouldn't be effective just like bunny hopping shouldn't be effective. I find the 2 issues rather similar, with only the 2nd one being effectively eliminated in Arma.

Easier yes, but so much easier that you should be doing it every time you need to run more than 50 meters - That is just wrong, because in real life it just doesn't work like that.

Soldiers in real life don't take out their binoculars to use for increased combat mobility because the benefits just aren't significant enough. Therefore, if the game was realistic, in-game soldiers wouldn't be doing it, either, because it wouldn't be beneficial enough. However, the benefits in-game right now are just outrageous, both in terms of speed and in terms of fatigue.

Say, 3-5% faster with binoc/handgun and 7-10% faster with nothing out, but also hardly any fatigue difference - That would make more sense. But again, in this case we should be allowed to place our weapons on our backs in order to be able to take advantage of it without requiring binoculars. And it's really not needed since you're not supposed to be doing it - It would also be just fine if there was no benefit at all to running without a weapon.

Currently, I had to remove binoculars from my missions, as it was extensively abused.

Well, the rifle in hand is way too fast too, but that's not the point. 22% faster just because you have binoculars (which cannot be done if you don't have binoculars) is just plain stupid.

If they want to let us put the weapon on back to run faster because they think it's better, that would be a different matter. But currently it is only possible with binoculars. And even then, considering you still carry the same gear, it's still pretty stupid. Especially when you consider the lack of stamina drain when running with binoculars.

In the end, you don't see soldiers in real life pulling out their binoculars to run faster. No reason for that to be the case in Arma. Currently the primary purpose of carrying binoculars is to enable faster and lower fatigue sprinting to cover large distances.

Description.ext is indeed a bad place to have channel disabling. It should have been made available via scripting in the first place, so that it can be done based on stuff like mission parameters, mod availability checks, mission triggers, admin control panel, etc.

Being forced to choose it on a per-mission bases regardless of any of the above just doesn't provide nearly as much (direly needed) functionality.

Or even better, allow controlling it by script (though default value should still come from class difficulties as that's where it fits best).

And, of course, on Elite all the tough stuff should be enabled by default.

In SIX config browser they don't seem to have the same config values. When I'm home I'll check if they have the same model, but as far as I remember they don't.

The old command was able to give units uniform of a different faction. This is no longer possible and will break old missions relying on this feature/bug. As the "bug" isn't really a bug as it doesn't actually cause any problems in properly scripted missions, I don't see why it needs to be "fixed" forcing users to change missions to use the new command.

If it was necessary to force us to change to a new command to get some new functionality in then I would understand, but this is not the case here. Instead, the new command can be the command that behaves differently, while the old command could keep its old behavior for backward compatibility of missions relying on the old behavior.

I don't understand the need to break backwards compatibility on this.

I have the same problem. It seems like once disable, it cannot be re-enabled in any way whatsoever, making it impossible to use these modules for "AAS" style games.

Halifax, that sounds like a completey different bug that warrants its own ticket.

Because in software it's much easier to make something that used to work work again than to make something that never worked work. You can check the difference between the working and non-working version, rather than have to start blank and implement a totally new solution. It's a big difference in effort required.

It shouldn't be difficult to fix since this was already working in older Arma 3 versions.

https://www.youtube.com/watch?v=VSIO9_iGKDc&t=2m55s

This used to work...

DarkDruid if you still have issue reproducing it please let me know how I can help (which files would you need?), because I think I have the exact same problem.

Which keys do we have to bind back to defaults and what are they?

I could really use a workaround until this bug is fixed.

Thanks.

Seems related to #9080
http://feedback.arma3.com/view.php?id=9080

I haven't took the time to try reproduce in vanilla, but seen reports on the Tactical Battlefield forums that this also happens in vanilla and not just in the Tactical Battlefield mod.

In this example no acceleration is applied. Velocity is speed in meters per second (aka [Vx, Vy, Vz]). Setting V to the same value as the current value of V should have no effect.

For anything other than grenades, setting V to the same value it already has indeed has no effect. Only grenades get their simulation disabled on frames where setVelocity is used, hence it is a bug. Simulation should not be completely (or mostly) ignored on frames where setVelocity is used, especially not when this only happens with grenades.

Repeat the test with any other projectile and notice only grenades are affected by this bug.

Can be very useful. But I don't see why you should repalce. Instead, just add more key binding options that are unbound by default. In the end I still think I'd use the current system, but I can see how in some situations it can be preferable to use the suggested method.

In real life you can run faster if you don't hold your weapon up, that's for sure. Therefore running at the same speed with your weapon up will most likely tire you faster (though I was never dumb enough IRL to run for extended periods with my weapon raised, so can't actually provide RL data).

More or less duplicate of 0012043

http://feedback.arma3.com/view.php?id=12043

Adding magazines directly to a weapon (at least an equipped weapon) should also be possible.

Right now you must first add the magazine, then add the weapon so that it is loaded with the magazine, and make sure it's actually the #1 priority magazine in case there is more than 1 supported magazine type.

Also, now you have a problem adding rocket into a launcher if the character has no backpack as most rockets don't fit into the vest even if it's empty.

Another missing item command is getting the magazine in your grenade launcher (unless I'm missing it somewhere), and of course the add magazine to weapon command should support grenade launchers too.

What Xeno said is probably the best approach.

Things that are obviously global (like time of day and weather) should be controlled server side and synchronized automatically. At least by default.

Update: Seems to get broadcasted across the network, but only take effect where the vehicle is local.

Good idea, I'll check the mission scripts to see if it does any custom view distance settings to remove it, but in any case flying rocks should not happen.

More or less... Though this is with default multiplayer terrain detail (terrain detail setting takes no effect in MP).

It is not "as if". It really does stay connected. Try pick it up and see.

I tried removing it with a script, but assigned items get bugged when a unit is already dead and cannot be removed by script. Only working solution was to delete the dead body.

It's bound to the device in the player's inventory, and there appears to be no way to disconnect it even with scripting unless a script deletes the whole dead body or someone picks up the UAV terminal and either manually disconnects it or has a script remove the terminal from his living body (you can remove it from living players with scripting, but not from dead units).

I would have expected a better mechanic to be in place, or at least the associated scripting commands to exist, and the workarounds to not be broken.

Just like disableUserInput or enableSaving - disableClothSwapping or something that will do it globally in a simple fashion with a command that just needs to run once per mission. Additionally, a per-unit command can be added as well.

Right now I have to use an ugly script to instantly re-add the correct uniform if the player tries to switch them.

This shouldn't just prevent switching, but also disable just dumping your existing uniform and running around in underwear.

Of course, this shouldn't disable scripted uniform switching in any way.

Happens even on pure infantry missions right on load before any vehicles have any chance to spawn (none are placed in the editor).

Not specific to dedicated servers. Occasionally clients get this error too. Usually followed by a crash or seeing other players stuck in ground.

Yes, unfortunately though this isn't enough to give proper weapon-specific magazine-specific ballistics. Granted, they are both weapon and magazine specific, but not in a realistic way. We need to be able to fine-tune it to a finer degree...

You only need the magazine type. The weapon should have ballistics defined for each of the allowed magazines. But it should all be configured in the weapon.

You could still be allowed to use 1 ballistic configuration for all magazines that the weapon supports, in case you have many different same-ammo magazines supported by the same weapon.

Some idea of how it could be:

class supportedMagazine1
{

type = "M16Mag";
veclocity = 900;

}
class supportedMagazine 2 : supportedMagazine1
{

type = "M16PlasticMag";

}

Or even make "type" an array of allowed magazines that use the same ballistics, for example:
class MagazineBallisticClass1
{

types = {"M16Mag", "M16PlasticMag};
veclocity = 900;

}

It really shouldn't have been that complicated to get this done in the first place.

Why does the magazine configure anything anyway?

Since the weapon needs to configure which magazines it accepts anyway, it should also configure how each magazine functions in that weapon, rather than have the configuration in the magazine.

For inheritance, similar weapons should inherit from each other anyway so again no reason for ANY ballistic configuration to be done in the magazine.

No 2 weapons should have the exact same ballistics, and therefore it makes sense to have no ballistic information (other than class type which the weapon can use to determine the ballistics). New weapon? New ballistics. If they "just happen to be the same" as another weapon, then it makes sense they will be duplicated anyway, since they aren't the same by design.

It should be reduced if only for the sake of me not needing to repeatedly hearing people complain on teampspeak that their soldier is about to black out and they need to rest. Or complain that their soldier is asthmatic. I mean, you can't even black out in this game right now...

Breathing sounds as an indicator of stamina loss is fine, but currently it's simply overdone.

In ArmA 2 firefights ended much faster when comparing to firefights at the same range in ArmA 3. Aiming and hitting targets in ArmA 2 was quite a bit easier than in ArmA 3, and hitting stuff in ArmA 3 is quite a bit easier than real life.

When you can hit targets accurately, firefights are generally quite shorter.

Plus in ArmA 2 Takistan/Chernarus we had quite a bit less cover than we have on Altis.

This is of course talking from a PvP perspective. When it comes to AI of course the more AI the longer the firefight, and the less accurate they are the longer the firefight is too, but that is a configuration/scaling issue rather than shooting mechanics. AI configuration is completely off-topic here. First the players should be adjusted to behave realistically, then the AI can be configured to follow suite (and actually, you can already configure them with very simple scripting or user-friendly mods).

gibonez I think you are putting your hopes up in the wrong place.

While ballistics in-game could use some improvements for the extreme ranges, the real reason firefights are quick and deadly is due to how easy it is to place your sights on target.

Check out the recent dev branch changes that are supposed to make shooting more challenging - Those are much more critical for what you would like, though IMO are still not enough (it is still too easy to get sights on target in many situations).

Calculating wind drifts in real time shouldn't be a real issue. Making it true to the real life bullets and weather can be tough though.

Some of those effects (pressure,humidity)
are completely negligible for the arma environment.

Wind is usually not negligible gor accurate shots past 300 meters, but realistic wind estimation methods cannot be properly simulated. Just reading some windmeter and adjusting simply will not work in reality to the point where windmeters aren't very useful.

The command was ran on the server while the vehicle was empty. But then again it seems like returning vehicle locality takes a while if it even happens.

Sorry, no idea how this got opened 3 times.

Update: Seems to get broadcasted across the network, but only take effect where the vehicle is local.

I tried running it only where the vehicle is local, still sometimes same issue - Only machine that ran the command sees the effect. Seems impossible to repair via script right now unless I'm missing something...

Happens on hosted server too, 25+ fps.

Some more testing shows that regardless of which machine is setting the damage, it is only applied where the vehicle is local.

Update: Seems to get broadcasted across the network, but only take effect where the vehicle is local.

Related to:

0011787 http://feedback.arma3.com/view.php?id=11878
0013661 http://feedback.arma3.com/view.php?id=13661

This would be a very useful feature for filtering out servers.

Would be cool as long as we can bind "use default action" and "use selected action" to the same key to get the current effect. Personally I like having both on the same key, but giving someone the option to do otherwise is welcome.

Just removing stuff from the action menu is not possible in most cases. For example the game does not limit the number of different magazine types a player can carry, so you can never really work around it with a simple key binding. Even for something like changing to launcher, when PR:A2 tried removing it from the action menu it caused a lot of confusion with people not knowing how to select their launcher. I also know a lot of people who have no clue you can bind a key to "get out" and "eject".

Letting us remove these specific options (that have a matching key binding) from the action menu is OK, but removing them completely will cause too much confusion, and in the case of magazines lose functionality as well.

I already did. Do you really want some missions to suddenly show you 20-50 actions? Sure it might be a better idea to remove them, but considering that missions are already made with "unavailable actions don't show" in mind, and considering that it is much easier to just use a condition rather than constantly add and remove the actions, you can't realistically expect all unwanted actions to always be removed.

Besides, you will still have a problem when the action you want to use is removed - It will not be grayed out and you will have the same problem you have now. My solution works both for disabled and removed actions, not just disabled actions.

What Fireball said.

As long as all other actions disappear normally and the "grayed out" action disappears as soon as it's de-selected it should be good.

Well, I suppose the other ticket is the same problem, but a completely different solution suggested, so I'll post it here again:

A possibly better fix would be to de-select the action if it becomes unavailable, and only select the previous/next available action (relative to the position of the removed/disabled action) when the user moves his mouse wheel up/down. That way you still don't accidentally use any actions you don't want to use, but also don't break any existing mechanics (for example - Missions that add 20 actions but only let you see and use 1-3 at any given time).

This could be added as optional (with a flag set by the addAction command). Making it default will break a lot of existing mechanics.

You already have a key for "default action". Bind it and use it. You are asking for something that is already in the game.

AI don't really care about scopes anyway as far as I know. They fire just as well with no sights at all.

Actually, you shouldn't even be able to use normal sights like this, or at least it would be extremely difficult. Iron sights are of course completely impossible IRL as well.

Why is this marked as "need more info"? I think the problem is pretty obvious - Trees go crazy when wind is set very high with setWind.

Weapon length is pretty meaningless now. This needs a fix badly to make weapon length an important factor when choosing your weapon (or just deciding how to use the one you're provided with).

Seems related to #16580
http://feedback.arma3.com/view.php?id=16580

While it's not phrased very clearly, it is very much needed!

Currently if you don't place a medic in the mission editor, you cannot have medics, no matter what kinds of scripts you run. This completely breaks any dynamic class assignment (for example, allow someone to become a medic on next respawn without leaving and re-joining).

Shouldering should be possible but not for extended periods of time. Hitting targets at 400+ meters should be almost impossible, and above 100m very very difficult.

This applies to MGs as well (though to a lesser degree, depending on the MG).

At the very least the weapon should not be tilted while leaning. This is a very common error done in FPS games. In real life you would never tilt your weapon as long as you are able to, and especially not while leaning and aiming through the sights.

Yes, this is a very big problem with signature-checking servers. Still relevant as of 0.56. Makes it very difficult to get a game going. Even with high-end machines it may take several attempts to successfully connect, with each attempt possibly taking 1-5 minutes.

Not just rocks, buildings too. For example ghost hotel will repeatedly create this issue.

This is still an issue (often game-breaking and requires many nasty workarounds).

It would be very helpful if this command worked reliably.

Yes, both issues are probably caused by the same bug.

Just noticed http://feedback.arma3.com/view.php?id=4029 was closed due to lack of activity, though the issues are related.

Unless I missed something, this wasn't fixed yet, and it's quite critical for some scripts/missions.

Yeah, basically the font needs to have a slightly higher resolution (or just some minor adjustments) to resolve all of those issues.

This is an important feature of ACRE that can be easily improved a bit making in-game VOIP much nicer to use.

Also, the volume drop-off with distance is completely messed up, as you can be heard pretty well over 40m or so when talking quietly on your squad's radio.