Yeah, this will never be addressed. Maybe Arma 4 will have this issue solved. In 2038?

@Nark0t1k: I have reported this in 2015 - any questions? :D

Currently, I have to do almost 80 lines just to be (97%) sure a vehicle does not explode. Its easier for the average modder and in the end better for the reputation of Arma. People think exploding things is a feature of Arma. They blame you for this. And to be honest: Setting a world matrix is not as that hard.

Just do it!

Not sure if that is related to this ticket here, but I think so:

https://onedrive.live.com/?authkey=%21AFmXoKqBMk1o7Lk&cid=F2298CFD9354AC3E&id=F2298CFD9354AC3E%21123&parId=root&o=OneUp

Players just sent me this.

Check the screenshots. Its wearing a uniform that does not even exist in the game.

I have never seen this uniform before and searched for it in the virtual arsenal afterwards. Its not there.

What. The. Hell?

"You tell your car not to drive, but it drives anyways" - That's not a problem. This is normal. And normal behavior.

I agree with Torndeco. Better remove this unlogical construct, as it is completely useless and will only break things.

"but there is no reason why it shouldn't"
-> if (false)

Or in human words:

"If you must not do that, do it anyways".

So basically you're telling us, that this unlogical behavior, that doesn't occur in every proper programming language in the world, is by design? What's the sense of that "if" then, if the script engine completely disregards it?

The engine evaluates the throw before the if, just in case it needs to throw something? This means the engine is reading the code backwards.

I really can't handle this anymore. Even Visual Basic is more advanced than this.

Sorry for the hate, but this really makes me upset.

Update: It also occurs when you sprint while unarmed.

Yes, it was tried in the editor. Does that make a difference? If so, it should be mentioned here:

https://community.bistudio.com/wiki/Functions_Library_(Arma_3)#Adding_a_Function

Great! So it was a lack of information. Phew!

Happens with choppers and cars in the same way.

https://www.youtube.com/watch?v=2j_lFtvOPdo&feature=youtu.be

Similar to: http://feedback.arma3.com/view.php?id=23192

Nailed this down to be related to simulation. If you disable simulation on objects, the network updates are delayed.

createVehicle
setPos
enableSimulationGlobal false

This will trigger this behavior. It was the same in Arma 2.

great! <3

@japa: I thought this is a general problem, but if it is system architecture related, let me describe what I do:

It runs in a dedicated server. The code is invoked in non-scheduled environment to run as fast as possible. It is used to load player gear from a database. The server creates a new unit to spawn a player object. Then it adds uniform, vest and backpack to the new player object. After that, it populates the content of these containers.

This works fine 90% of the time, but *sometimes* uniformContainer/backpackContainer/vestContainer return nil.

Here is an overview of what it does:

_group = createGroup independent;

_player = _group createUnit ["Exile_Unit_Player", _position, [], 0, "CAN_COLLIDE"];
_player setDir _direction;
_player setPosATL _position;
_player disableAI "FSM";
_player disableAI "MOVE";
_player disableAI "AUTOTARGET";
_player disableAI "TARGET";

// [...]

_player forceAddUniform _uniform;
_uniformContainer = uniformContainer _player;

if (isNil "_uniformContainer") then
{
// Here is the problem
};

I dont understand how or why it can fail if you get the container right after you created it.

Using waitUntil is maybe a bit problematic in non-scheduled environment :)

@KK: This was my thinking too. But according to the docs: "In Arma 3 when last unit leaves a group, the group gets auto deleted." it should not be the case. I have added a lot of debug logging and the unit is there. Everything works fine, except the container functions returning nil.

It is a dedicated server. The unit is created on the server and then additional gear is added, thus the unit is local.

Just a thought beside that: Why should a function ever return nil? That just does not sound right to me :)

I am not sure if I got you. I am not using the player command. The above snippet is from client code, where the same problem occurs. To reproduce it regardless of peer type, use createUnit + forceAddUniform + uniformContainer.

Unfortunately, it isnt. This makes things a little more complicated. This only happens after the server has been up for some time. The code is running purely server side. I can send you a log file if you want to.

Yes, the unit is of course local :)

I think I pasted the wrong code in here. If you use "setMarkerText" instead of "setMarkerTextLocal" it will turn the local marker into a global one. Sorry for that.

Edit: It depends on the weapon. If the weapon has two muzzles (EGLM etc.), then it will not work. For weapons that have only one muzzle, it works.

To be more procise on that:

Equipment a weapon with ELGM attachment. Put in a magazine and make that your current muzzle (should be by default). needReload will return wrong value. Then equip a EGLM grenade. needReload is still wrong. Then reload your EGLM and voila - needReload is working as intended.

In other words: needReload does not regard the current muzzle. It will return 0 if ANY of the available muzzles need a reload.

Check this: https://www.youtube.com/watch?v=WYQHRvOhLB0

It is 1.48 stable.

Steps to reproduce:

Get into editor. Grab a weapon and a magazine. Ensure weapon is loaded. Open debug window. Type "needReload player" and "needReload (vehicle player)" into the watch lines. Shoot a few rounds. Both of them show 0. Get into an armed vehicle and fire a few rounds. "needReload player" still shows 0. "needReload (vehicle player)" shows 0.x-1, working as intended.

I love this video because it's so true. Now trees look a bit better than in Operation Flashpoint, but usability has always been a mess. They don't care.

Updated Game Version field. Still present in latest stable version. Also in DEV.

Try to hit a helicopter with 12 FPS. The last time I had 12 FPS was in 1998 while playing Half Life on a 233mhz beast.

Please re-think your priorities.

I love this video because it's so true. Now trees look a bit better than in Operation Flashpoint, but usability has always been a mess. They don't care.

@cosmokenney: No. They don't care. They simply don't care. They don't even bother to tell us their opinion on this. So well, go play Battlefield.

@BI: Are there any news on this? I have just received a 50% OFF Newsletter, but none of my friends is going to buy it since they fear it won't run properly. Sentences like "Oh, you know? It's still ARMA. You can run through walls and die. You can fall through floors and die. Your screen freezes for seconds every few minutes. And it's so hard to hit someone when they just warp right in front of you. And if you can stand 11 FPS on your GTX 980, buy it." are very common to hear.

This ticket is now almost 1.5 years old. I know this fix is something very essential, but really?

Please care!