Still present in v1.46 RC

Indeed, they have all the same static weaponry as NATO & CSAT, so why not the designator?

I mean, I already had my own weather syncing with pvars, but now that it's also done by the engine, this issue creates a bigger problem: my pvar applies the correct fog decay value, but the engine reverts it to the rounded value a couple seconds later, which causes an annoying "blinking" effect.

You can notice it in this video if you watch closely: http://www.youtube.com/watch?v=7XFuP2yIBzs&t=3m19s
(it alternates between 0 and 0.001)

Related: #19132

@Shields: Your point is not valid because the first rocket does not disable the MRAP, the engine only takes about 35% damage and the vehicle keeps running perfectly fine. It's an anti-<b>tank</b> missile after all, it should have no problem blowing the crap out of any MRAP.

Unlike the real thing, <b>the Arma 3 NLAW is configured specifically for direct hits, as evidenced by the game config showing it has a very low splash damage value</b>. The airburst barely does 2% damage max, which is much less than desirable, and was only implemented so the rocket isn't wasted in the air if it misses the target by a couple inches.

Also, in this case, 2 rockets are not enough to cause a delayed explosion. A single hit to the engine only causes 30 to 40% engine damage, while that in order to cause a delayed explosion, the vehicle either needs to sustain at least 98% overall damage, or over 90% fuel tank damage.

Finally, how do you explain the Strider getting destroyed in one hit regardless of the impact location? Wouldn't that be grossly unbalanced compared to other MRAPs?

It should also be noted that this <b>bug</b> was introduced with a recent update, and did not exist when the game was released.

Arma 3 does not take fuel or ammunition into account when deciding if a vehicle should blow up or not. Everything is hardcoded in the game engine, according to the vehicle's simulation type. A delayed or instant explosion is only triggered when either specific hitpoints or the overall structure reach a specific amount of damage.

@KK:

setMagazineTurretAmmo and magazineTurretAmmo are <b>not</b> appropriate for the purpose I have described. I need to know the exact ammo count for <i>all</i> magazines inside <i>all</i> the turrets, even those of the same class in the same turret, and be able to add them one by one to an empty vehicle with their exact ammo count.

I expect setMagazineTurretAmmo to be only be able to set the ammo of the magazine of that is or was last loaded in one of the turret's weapons; what if I want to add an extra magazine with partial ammo? This is where addMagazineAmmoTurret would come in.

Similarly, I expect magazineTurretAmmo to only report the ammo of the magazine of that is or was last loaded in one of the turret's weapons; what if there are multiple partial mags of the same class? Answer: magazinesAmmoTurrets

It'd be great if you didn't close stuff outright without asking for precisions.

@ozdeadmeat

Get: https://github.com/A3Wasteland/ArmA3_Wasteland.Altis/blob/8b5ef5c074f06a121dbef4c8592a1e6fc9f4d52e/persistence/server/world/fn_getVehicleProperties.sqf#L89-L130

Set: https://github.com/A3Wasteland/ArmA3_Wasteland.Altis/blob/bea287b258577d4005f8bd89b7f2fc25aa386d25/persistence/server/world/vLoad.sqf#L151-L167

getMagazineDetailAmmo: https://github.com/A3Wasteland/ArmA3_Wasteland.Altis/blob/caad218505f736b7e1019a784d3c02a351b43eed/server/functions/getMagazineDetailAmmo.sqf

It's far from perfect, but it gets the job somewhat reasonably done. A couple notes:

• "_turretMags<b>2</b>" doesn't contain ammo counts, as they can't be retrieved reliably for those mags.
• "_turretMags<b>3</b>" stuff could be done more easily by using magazineTurretAmmo and setMagazineTurretAmmo
• "fn_getFromPairs" can be replaced with "BIS_fnc_getFromPairs". Although, I don't really recommend using BIS pair functions on a regular basis, as they are horribly inefficient and unnecessarily restrictive.

I tried to reopen it before making the new one, but it said access denied.

Fixed in v1.34

In the editor. Maybe it's fixed in the dev branch but not stable? I guess we'll see when Heli DLC is released.

I guess I'm going to stick to my trusty "_player addScore (_newTotal - score _player)"...

I believe that addScore should never trigger HandleScore, or otherwise minimally have a boolean passed to the event code that says if it was triggered manually.

The most likely use for HandleScore is to cancel out all score changes done by the engine, so as to manage scores manually via addScore.

indices = [];
bla = [5,6,7,5];
{
if (_x isEqualTo 5) then
{

		indices pushBack _forEachIndex;

};
} forEach bla;

Related:
http://killzonekid.com/arma-scripting-tutorials-get-zoom/#comment-1127372278
http://feedback.arma3.com/view.php?id=16120

Ooh, nice. Didn't see that one.

Okay so, getPosWorld will return a raw ASL vector, therefore ASLtoATL can be used directly, right?

@SaMatra: My assumption is that "world coordinates" used by these new commands are not tied to the terrain level nor sea level, but rather separate "engine" coordinates. However, there has to be a defined offset between the engine space and the terrain level or sea level, i.e. [0,0,0] in engine space could actually be above or below sea level, and it's what these commands would use to convert vectors.

I'm not sure I understand what you mean with the ASL stuff. ASL space is not object-specific, it's simply a vector relative the to flat sea level. You can have [0,0,100] which means 100m above sea at X=0 and Y=0.

The positions returned and used by getPosASL and setPosASL are, however, object-specific indeed, due to the orientation of the object altering the Z component, depending on the bounding center or LandContact vertices when available.

I guess we'll have to wait and see what "World" really means in relation to those commands.

@japapatramtara: worldToATL & ATLtoWorld plz? :)

And that's the whole point of this feature request. ASLWtoASL, ASLtoASLW, getWaveHeightASL; I just need at least one of those commands.

Okay, but what if I am trying to use modelToWorld to fix the setPos/getPos imprecision? You know, that thing: #16120

I need to get the delta wave height at a position without having a vehicle on that specific position.

Yeah I know about that, but in all cases, there one unknown variable that ultimately remains: the height between the sea level and the top of the wave. Without it, my fix doesn't work properly over the sea, but over land it works just fine.

Let's say that the sea is rough. Now, consider the following: _pos = boat modelToWorld [0,25,0]

_pos is in format PositionASLW, and I need a PositionASL or PositionATL with pinpoint accuracy. What do?

Same issue here. I tracked down the tmp0 file, and it shows in the file properties that there is a digital signature with the name "Bastian Suter", who is the lead developer for <b>BattlEye</b>.

Fixed 11 months later

Still present in v1.34

setWind array doesn't seem to work correctly, I had more luck actually negating the current wind, i.e. setWind [-(wind select 0), -(wind select 1), true], although even there the result is not always 0.

I just tested again, if wind is exactly [0,0,0] then the parachute stays perfectly still, however a 0.01 value is enough to make it flip over.

@Xeno: Lol. If this bug is there since OFP, then the chances of having it fixed are little to none, as usual.

@Rellikplug: No, this doesn't have to do with the azimuth or setDir directly. It's not related to the editor, but rather the physics engine.

I remember reading about it being intended, since volumetric lighting and other environmental stuff have to be recalculated from the grounds up or something.

@madsolosniper : Again, it's <b>not</b> case sensitive. I just tested with your server. The dot is part of the word, therefore it doesn't work if you remove it.

@George: Please add a keywords option in the server config and Description.ext for server admins and mission makers to make their own keywords.

https://developer.valvesoftware.com/wiki/Sv_tags

@madsolosniper: It's not case sensitive.

I also noticed it doesn't list players anymore. I'm starting to think an alternative to Steam server list must be seeked.

Yes, exactly. BIS must pressure Valve.

Well the limitation has to be fixed. It's unacceptable.

I really don't know what purpose did this serve in the end, except being a placebo. The number of weapons/magazines/items a vehicle can hold is not defined by the "transportMax" values, but rather "maximumLoad". If maximumLoad is not defined, then the vehicle can hold a total item mass of 1000.

This is really stupid, because trucks have a maximumLoad of 1000, while crates have 2000. The large airdrop supply crates have exactly the same maximumLoad as the smallest ammobox, which is 2000.

Here are my thoughts:

• All ground military vehicles should have a maximumLoad of at least 3000
• Military trucks should have 3000 for fuel ones, at least 5000 for the others, up to 10000 for the HEMTT Box and the likes
• Civilian vehicles should be between 1000 and 5000, like: Quadbike = 1000, Hatchback = 1500, SUV = 2500, Offroad = 3000, Transport Van = 4000, Boxer Van = 5000
• Airdrop supply crates (i.e. "B_supplyCrate_F") should have at least 3000
• Normal ammo crates should stay at their current value of 2000

For reference, an empty Assault Pack has a mass of 20, and a First Aid Kit has a mass of 8.

I think the "transportMax" values are only kept in for backward compatibility, but Arma 3's mass-based inventory system does not seem to use them at all.

7:Object - Container into which the magazine being removed from the weapon is going to be transferred (objNull if mag is null or empty)
8:Object - Container from which the magazine being reloaded into the weapon originates

3:String - Magazine class being removed from the weapon
4:String - Magazine class being reloaded into the weapon
5:Number - Ammo in magazine being removed from the weapon
6:Number - Ammo in magazine being reloaded into the weapon

Hell, that's quite a clever one :)

Aaaah, clever :)

The only problem I see is that catching when a unit reloads is a bit hard, see this for more info: http://forums.bistudio.com/showthread.php?173330

What purpose do you need that for?

Awesome!

The get/setVariable method for storing selection damage isn't even viable, since the values become incorrect if someone repairs the vehicle using a toolkit, or if setDamage is called on the vehicle, not to mention you have to "setVariable true" them in case the locality of the vehicle changes.

Ibanez, that has nothing to do with Arma 3's duping bugs, which are related to network sync, when 2 players try to take the same item from the same storage container at the very same moment, or items getting duped by the engine when taking them from corpses.

The Epoch exploit you are pointing out is an issue strictly related to the player saving mechanism, where somebody puts one or more items in a container, quickly unplugs network cable, aborts mission, replugs network cable, then rejoins, and hopes that there are now 2 copies of said item(s) due to his player inventory being restored to its previous state.

This is easily fixable in Arma 3 missions with player saving: force-sync inventory whenever the "Put" and "Take" events fire. Case closed.

The issue is definitely there, but it can take a few tries to succeed. The 2 players need to be continuously right-clicking the item when it's on the ground, and if succeeding at taking it it, immediately put it back on the ground and continue right-clicking it.

After a minute of doing so, the player for which the GroundWeaponHolder is remote should have multiple copies of the item.

It is also possible to do it by having someone open your backpack and try to take an item while you continuously move it between the ground and your backpack.

Sometimes the item will be successfully taken by the second player without duping it, in which case he must put it back in the container to try again.

I think it might have to do with ping, as the duping most likely occurs during the very small time window after which player 1 has removed the item, but the change has not yet reached player 2 before he tries to take it too.

I was able to do it moderately well on a dedi with 100ms ping for both me and the other player.

What I think is happening inside the engine:

Player tries to take item from remote container; engine puts it in his inventory, and sends a delete request to the remote container.

What it should be doing instead:

Player tries to take item from remote container; engine sends check request to the remote container; remote container receives the request, if item still available then set mutex lock on it, and send authorization back to player; player receives authorization, if positive then put item into inventory and send delete request to the remote container.

Long story short, it's most likely a mutex problem.

A simple script command like "disableWeaponDisassembly" would be the most appropriate. Global effect, of course.

This isn't a sound issue. Even if you click for just a split second, the cannon fires at least 10 rounds, it's probably intended.

It's called preloading lag.

I noticed that as well, although it can only affect addons, as there are currently no secondary weapon items in vanilla A3.

Are you working on a player saving system?

I'd say, remove the Slammer UP altogether, and add the commander gun to the regular Slammer.

@George: What do you mean by "server event"? Are you referring to the "onPlayerDisconnected" script command?

@Killzone_Kid: https://github.com/A3Wasteland/ArmA3_Wasteland.Altis/commit/32882b84e59ee50940c66969196cfecc9d1a143b

It always works correctly in a LAN lobby created in-game, but not so much from a dedi.

@Killzone_Kid: Nvm, it was because of a premature exitWith, all is good now.

@Killzone_Kid: Yep that's how I fixed it, however if a player crashes while on a dedicated server, sometimes the EH doesn't seem to trigger for an unknown reason... In other words, kill arma3.exe, rejoin, and you might just find your stuff on the ground.

Following today's update, I'm very glad that corpses now stay where they are when players leave.

However, I'm not so glad that the server now creates a corpse containing your full gear when you leave the game while alive.

This creates a major duping exploit if you have any form of inventory saving on your server.

We need an option in description.ext to turn off corpse spawning on leave.

enableSimulationGlobal is unrelated, as my objective is to run it on a local level for all remote entities, units included.

But, it is certainly not a "major" issue.

Is that a dinosaur head I see in the shadow?

You should change the title, as the crashing in itself is intended; what doesn't work properly is most likely the path resolving.

A game crash is usually global to Arma 3, unless it's extension-related, which is not the case with this issue.

Just a little note, the crash is specific to when simulation is disabled on the container being deleted.

Disable simulation on the object, open its inventory, and have a delayed script delete it while the inventory is still open.

I agree with Pennyworth. Having to use a while true loop to catch vehicle changes is downright stupid.

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

Related to #15079

Thank you grandmaster japa, you da best :)

I say they need a dedicated group of employees to keep a regular look on more technical categories of the tracker, like Scripting, Engine, Config, Inventory, etc...

I mean, there are many, many issues in those categories that have not been marked as acknowledged or reviewed, which means to me they didn't even read them. At least, if they do read all of them, then it would be great if they would indicate they reviewed it.

Let's just hope that since the campaign is now done, the bug tracker might receive more attention.