Should I post a new ticket then?

I forgot to add the "NOT" in my comment. My apologies. The above statement has been corrected. My CfgRemoteExec in description.ext is set to mode = 2 and the Bis_fnc_arsenal still does NOT work

This is kind of urgent...

Also, using: [ "AmmoboxInit",[ hA,true,{ true } ] ] remoteExec [ "BIS_fnc_arsenal",0 ];
does NOT produce any results either.

"hA" is the name of the crate and the description.ext has been configured to unrestrict remote function execution.

Please check again on current dev ver. 1.55.133541. When the arsenal function is executed on a Dedicated server targeting an object that is owned by the server, it does not show up on any clients that approach that object (ammo crate). On a server/client machine it works fine.

Line run on server: 0 = [ "AmmoboxInit",[ hA,true,{ true } ] ] spawn BIS_fnc_arsenal;

confirming, still happening in Dev ver 125.126089

It seems that if I use enableSimulationGlobal false and a little delay just prior to the Bis_fnc_ambientAnim execution, both "Guard" and "Listen_brief" work fine.
I will keep testing in MP for consistency and report when 100% success.

Confirming that reversing back to 2GB has fixed the problem. Good luck in takling the memory extension limit

Thank you :)

Here are the first three. One of them did not generate an mdmp file.

Issue Resolved. It was indeed the corrupted file that got fixed with the integrity check.
I appreciate all your help.
Please close this ticket.

Hmm, I have made a simple mission and you are right...I cannot reproduce it either. It must me something "short circuiting" within the complexity of my other scripts in the missions I am experiencing it.

It is just a little peculiar because those missions were working fine for months now. I did not change anything and the error started appearing a few updates ago.

Anyway, I wasted enough of your time. Let me work on it and If I have something useful to say I will come back.
Thank you and appreciate your patience.

The process to verify integrity of the game cache did find one file that needed to be reinstalled. However I still get the error. Sometimes it does not happen on the first respawn but once the error shows up, it shows on every respawn even you change missions.

Just to mention again. It only happens when the respawn positions are added through the Bis_fnc_addrespawnposition OR (as I found later) by assembling a respawn dome backpack.

The issue is still present in Dev Version 1.25.125903

Yep, here too.

This issue is also happening in Altis. Areas that I have observed it, where in and around the Stadium, Thronos hill and some military bases. I will get back with more specific information

Please let me know if the problem is not reproducible on your end. Just to eliminate the possibility of my PC not calculating correctly !!

I have uploaded some information regarding the issue on the Altis map. Let me know if you have enough information to track down the problem. Thank you.

New information...
I have run extensive test to eliminate user errors and I think I have been able to define the problem. It seems like a hard coded LOCATION problem.
I am attaching a jpg and a simple mission to reproduce the problem.

The problem ONLY happens in certain areas of the Stratis map. Red markers are where the problem occurs Blue where it does not.

Could you please reopen it so I can attach the mentioned files.
If you need to reproduce it your self, go to Camp Rogain and check there.

Negative...the testing I am doing has a plastic can with 20 meters to closest obstruction.

I am still trying to figure out what script is interfering...

Indeed, in simple missions I cannot reproduce it either.
There must be a conflict then into my scripts somewhere that does not allow the placement radius to take effect in more complicated scenarios. I am going to keep looking for what causes it.

I added the newer info on the original post for better review. I hope that is ok

The problem seems to arise when the key assigned for "Change Gunner weapon" is also the key assigned for "next weapon". Once they are separated the problem disappears. Usually a key that is assigned somewhere else shows in red but not in this case.

I still would put this as user error and move to close this post :)

As of dev version 1.39.129098, it seems that the issue still existss

It looks that in todays Dev version 1.15.116121 the problem is fixed on my end :)

Same here but without the Steam Workshop subscription. Just trying to get to my own missions in the Multiplayer Mission Editor.
Just start happening with the latest Dev Build 1.15.116103
Windows 7

Unless there is a problem with the code, I would also like the ability to add ladders as an object.

I can also confirm that the problem seems fixed. We had 3 nights so far with no problem at all. Well done!

I am also encountering this issue. Running Dedicated server with minimum two clients on WAN as well as on LAN.
In the last couple of updates on Dev version, the problem is happening almost 95% of the times, including missions of Arma 3, like "combined arms"

A similar post was made minutes earlier. Closing issue due to duplicate.

Confirmed. In Dev version 0.77.108982 the issue has been fixed. :)

tyl3r99, it is BIS functions that give that error and as ozdeadmeat asks, what do you mean?

In today's update, version 0.75.108378, the above reported issue is FIXED!!

It is not that you are effective and on the ball while a rain of all shorts of reports are reaching you...you are also very fast doing so :)
Many thanks for taking care of it.

I have a much simpler setup that has been working with no errors until the last two updates and indeed use of the MenuPosition template is throwing the same error and players cannot Respawn at all.

It started on yesterday's (July 29) dev version and it is also present in today's (July 30) Dev update.

Upvote and let's add the parachute control or link it to the AIR section. There is some remapping functionality in the USERName.Arma3profile.
You can edit it with notepad. You will recognize the submarine keys about a third down.

I don't think so. I am using the current Dev branch

The regular popup targets work fine with the fix (nopup=true) that was just introduced.

I am not sure if the Oval (ground, wall left, right, top and bottom) are also in the popup family. If so then they don't seem to work as the regular popup targets.

In all cases there is no human on the independent side. Your explanation of the title, though, explains it and it is correct then.
Thank you.

It is a great idea!!

Latest Dev Build 0.73.107829 is still reporting undefined variables errors. I am assuming the Team is aware of this and they are on it.
However, If this is how the team needs it then a little guidance on how to approach and fix our scripts would be much appreciated.
For the last 4 days the Dev version is not fun to play with all those errors reporting constantly in the middle of the screen. :(

It is still using 9mm ammo. I am wondering if this is the way the meant to have it or they act as placeholders of code for now.

I think I have found the problem.
Execution of either [player] call BIS_fnc_cameraOLD; or [player] call BIS_fnc_camera; through a radio trigger causes the Ragdoll effect to not execute.
An AI killed, will drop to the ground immediately without the ragdoll transition.
This is only noticed on a client connected to a dedicated Server.
I can now reproduce it :)

Not a big thing since either cameras function will be disabled after debugging of the mission.

I don't want to jump into premature conclusions...but since BIS made me aware of all the "undefined variables" and I have promptly since then managed to fix them...I have NOT seen the AI ragdoll fail :)

It never happens in Single Player or in Multiplayer Editor environment.
So only noticed through clients connected to Dedicated server.
It can happen at the beginning of the mission or all of a sudden in the middle of the mission.
I am suspecting that it occurs on dynamically created units but not confirmed yet.
No errors that I can spot in the server's or clients .rpt file, sorry.
I have not run into this error on the Bohemia missions yet . More testing is needed, on that.

rgr that roy64, my feeling exactly :)

I can also confirm it

I have not run into this problem since I mentioned it. I think it is better to close this topic. Thank you for your patience.

I cannot reproduce this problem anymore...:)

Same here, I guess its a slip :)

You must have been seconds ahead of me. Sorry for double post but I searched and yours was not on yet. We are one number apart. Voted on yours.
Moderators, please delete post # 0008456.

Excellent!! This is exactly what I needed.
Much appreciated :)

Yes I have tried for good measure but no go!. But on a side note, the camera.sqs is not really the script anymore. Inside this script there is a line to execute script: camera.sqf. It has been changed since Arma I, I believe.

I am not sure if the developers are preparing something different and put the camera.sqf out of commission or it is just one of those things that slip through the cracks of coding :)

I think we got it wrong, guys. NONE of them work in this latest DEV version. Please check your version and correct me if I am wrong.

In prior Dev versions, the camera.sqs was working ONLY because in its content there was a redirect to camera.sqf. So in a sense we were always using camera.sqf, either directly or through the camera.sqs.
Also sqs format is almost faded out too.

Okey, :)

Is there any other alternative. I need a camera to view while designing the mission and it needs to be checked in a multiplay environment.
Can I get the splendid camera function in multiplay Editor?

Are you using today's Dev version 0.57.105093?
This problem has just started occurring.

Yep, it is resolved for the standard outfitted units.
On occasion, refitting a unit with a custom load out from third party scripting this problem still shows up but THAT is NOT your problem. :)
Thank you.

Resolved

The issue does not seem be fixed in Dev version 0.77.109067.
I am not sure if it is suppose to be fixed in this version yet, though. Just reporting.

It looks that the Grenadier, Autorifleman and TeamLeader ONLY have this problem, at least on the Blue force side.
It is only related to their class. Changing gear and weapons before dying does NOT fix their problem after their respawn.

I just rechecked and ONLY the TEAM LEADER still has this problem. I am attaching a simple mission with base respawn for reproduction of issue.
I can reproduce the problem in this mission but please let me know if you need anything else.
Thanks for looking into it.

PS: I have only checked the Blue side at this point.

As of version 0.75.108659, the Blue Grenadier has this problem all of sudden

This issue has been fixed in the last few updates. Thank you

I did not realize until recently that you guys have actually implemented the dust effect I suggested a while ago. Simply amazing. You keep track of everything
The effect looks very nice indeed.
Many thanks :)

Thanks kOepi, much better than my edited version!!

Well, you only need to remember to set it OFF as soon as you start the SIM. The Developers will get around to fixing it soon.

I have standard keyboard/mouse controllers and I have the same problem. Everytime I start the Sim I need to go to Options-->game and revert the aimzone to zero. If I go to controls to change a key assignment after that, I still need to go back to game and deal with the aimzone.
If I don't open options or exit the Sim, the aimzone setting stays.

All fixed. I am closing the topic.
Thank you

The problem in Agios Cephas has been resolved :) Thank you!

However, I have run into the same problem in Camp Tempest area.

PS: I have done a more thorough check around all other house/shack/Wreck areas and it looks that the problem remains ONLY in Camp Tempest.

I agree, I have been trying to drop Divers on a specific location on water and although the boat reaches the assigned waypoint and slows down, it starts up again and looks for the closest shore location to drop off its divers.

I wonder if we could make the boat "know" what type of "transport" it carries so it can either look for a shore point or not.

I have also this problem.

yep, I confirm it too. If we could only get a few seconds delay before the load out wipe out happens, it would be enough to get the info out.

I would say the older boxes including the Activation in triggers are a little more accomodating. Not a huge issue but since the developers have been keeping all the good things since Flashpoint and improving on the rest...:)

That is the armor I was referring...Thanks for the clarification though.
Thanks Realo

Are you in Mercenary mode when that happens?
I have adjusted all my Difficulty seeting so there is NO extra armor on the characters and both types of grenades kill with 5 m radius at least. Sometimes further out.

I did another test and at 15m I get a knock, mud and sometimes some blood splatters on the standard grenade. Why do we see it different. We need to investigate.

How about sliding the Aimzone all the way to the right. That makes my character move at the waist first before side stepping. Is this what you mean Nordkindchen?

Thanks, Inkompetent, it will do for now :)

Agree with System. When creating missions and go test them, you don't know which mission you are previewing. The suspended one or the one you just did some editing in.

They are an imporvement from Arma 2, in all fairness :)

I did through a note below but that was a month ago

this is a post made in error. When the function was made available, I try to delete it. I don't have any control on the remaining part.

After a 6 month long trial and failure to solve this problem for one of our players...

(We have looked into Hardware and Software, from Bios settings, to reinstalling key software including Direct X, Net.framework, Arma 3. Look into voltage fluctuations, Heat, static electricity and on and on.)

..., we have found the culprit

Nvidia video cards' (580 GTX,SLI) core frequency. It was OVERCLOCKED by default!! Once we set it to 772 Mhz which is the default of the Nvidia reference board, no more crashes of this short.

The solution has been reported previously in this series of posts along with several others and that is how we finally solved our issue.

Many thanks to all the posters. :)

I am trying to figure out the common denominator. This issue has been so elusive. :(

Any of the gentlemen here reporting this issue using ZONE ALARM?

It is random. I found one way to eliminate the problem by clicking on the feedback link and keeping it open on the desktop. After that I can go to the mission editor and Alt+Tab back and forth with no issue.
It also seems to work when a document is already open on the Desktop.

OS: windows 7 64bit