Experiencing the same issue too

Noticed the same issue on Current Dev 1.63

I had just finished testing a mission on my PC. The test went perfectly with no errors in rpt and all events were performed fine. I send the mission to Multiplayer and closed my game to get back to desktop to transfer the mission to the dedicated server. At that moment today's dev branch update came through steam. I updated both client and server. Uploaded the mission and started my Arma in my Client to join in. Crash :(
Error on screen: Shaders not valid (mismatch of exe and data?)

The dedicated server and Headless client DID load with no apparent issue, though

Reversing to Today's MAIN Branch (non Dev) version 1.56.134627 RESOLVES the issue. Everything is back to normal.

Same issue if another headless client is attempted using the HC Launcher feature on same PC as server OR through another instance from another PC in LAN (e.g. "-client -connect=192.168.1.4"

FIXED with today's Dev update 1.57.134593
It was the inability to connect without a port number in startup line fix.
Thank you !

rgr, thanks. Voted on the original. I did run a search before posting but did not make any hits...

rgr, thank you

The issue persist in ver. 1.55.133137.
Further investigation confirms that the mission does load properly and in addition the players avatar exist inside the mission as per normal. The player is looking at the loading screen at that moment with no control over anything, except Alt-Tab or Ctr-Alt-Del.

Unfortunately, there are no rpt data that I can relate to amend my mission. When the player is Server host the mission loads fine but any clients that connect get the lock issue.

I tried with today's update with same lockup results. I uploaded the generated zip report along with the mission.
The mission loads fine on a Server/client as well as through the mission editor in multiplayer environment.

The standard Arma 3 missions are loading fine everywhere. So it seems that something in the recent updates of Dev branch is conflicting with my mission. I just can get enough feedback from the rpt to pinpoint it.

Note (Not Bug Related-Just Info for testers): The mission will start even in the absence of HC and addon pack @KDN. AI just will not spawn and Arma 3 music will replace the addon music.

RESOLVED or at least I got a way around it.
In the description.ext of my mission one of the functions under class CfgFunctions had a postInit=1. I commented it out and all clients load fine now and so far I have not found any issue forcing me to postInit that function.

Issue still persists in Dev Branch 1.55.133193

I will give it a try

FIXED today's Dev ver 1.55.133346.
Thank you!

Issue still persists in Dev Branch 1.55.133193

Thank you :)

With today's update ver 1.55.133137 the problem still exists and...
disregard the following. A verification check has fixed it.
(Additionally when the dedicated server is started with a steam account online, it causes clients to disconnect after a few seconds.)

Much appreciated :)

In danger of stating the obvious, when the dedicated Server is started WITHOUT steam being on line, on the console the usual line: Gameport: 2302,Steam Query port: 2303 does NOT appear.

I am afraid it is not fixed in today's update.

Many thanks for such impressive (practically immediate) response. :)

Confirming above. Issue resolved but the smoke grenade error.
Thanks

I cannot even start virtual arsenal under LEARN. That is how bad the crash is. I am not sure if the smoke grenades is only issue here but those error lines are the last lines before the crash. Every time.

Of course, reversing back to the standard version, the problem disappears but my mission set up is using the new remoteExec and param commands that I have learned to love :)

Any ideas how to by pass this and get the games going?

Well, it looks that it is definitely a starting point for troubleshooting this type of crash. (ref 0024667 )

I believe we are noticing the same issue. Check 0024667

Issue is almost fixed. No crashes anymore, just the smoke grenade error as stated in 0024672.
Thanks

This issue seems to have been resolved lately. Cannot reproduce this problem anymore. Running latest Dev ver. 1.51.xxxxx

I have discovered something.
When I set the "_wp setWaypointCompletionRadius 5;" to 0 and the heli is over land, everything works fine, as before.

If heli is over water sometime the setWaypointStatements execute fine and sometimes not, either I set the completionRadius to 0 or leave it at 5.

So, I am guessing that the problem is not on the setWaypointStatments but how the AI reads that it reached its destination?

The reason I noticed it is because this same exact code has been working perfectly for months. I have been following the dev branch updates on a daily bases and did not notice any changes that would relate to that. The closest that I could spot was maybe the AI changes in awareness. However, I run the script in a non-threat environment also with no change on the 1.48 sec delay. When the "setWaypointStatements" is commented out the Heli moves without delay.

Multiplayer, unmodded and through a script e.g

			_wp = trnspGrp addwaypoint [ getPosATL hpad, 0 ];
			_wp setwaypointtype "TR UNLOAD";
			_wp setWaypointBehaviour "AWARE";
			_wp setWaypointCombatMode "BLUE";
			_wp setWaypointCompletionRadius 5;
			_wp setWaypointTimeout [ 1,1,1 ];
			_wp setWaypointSpeed "FULL";
			_wp setWaypointStatements [ "true", "this land ""GETOUT"";tobase=true;"];

The Heli is created further than hpad position. Heli reaches the hpad position area and then hovers high for approx. 2min before hovering low for units to getout and tobase to turn true. the variable tobase=false: prior to this script execution

I have tried originally without the timeout just in case a default delay has snuck up on us but it did not make any difference with the timeout or not

All is well and Proper. Thank you.

cc
thanks

All fixed with today's Dev branch update 1.47.131162.
Thank you :)

Unfortunately it still does not have the buoyancy that it had not long ago.
The setpos, setposASL and of course setposATL, sink it all the way to the bottom. The physics and interaction with terrain look normal as it sinks by the way, so it looks that it is filled with heavy stuff :)

Just as a reference mark, I have uploaded three jpg showing the before, current and temporarily fixed buoyancy.
Note: Originally the buoy was submerged to its waterline (cannot see the dark area). The enableSimulation false command submerges it much less. You can see the waterline.

Is there a parameter I need to place in above objects init?

Will do as soon as the update goes through Steam today.
Thank you

I failed to see the sarcasm. My apologies :(

The difference of opinion only related to: "Provide financial payment for Feedback Tickets" on Original Bohemia content.

Indeed nicely written but the fact that a company actually pays attention for sooo many years to its customers AND delivers, it is a payment itself.
This is a simulation and as such the profit margin is very small.
I am just grateful that Bohemia continued on the original Flashpoint, shining with every version :)

This has been fixed :)

It only seems to happen with the Dual purpose magazine.

dual but I better check on the standard too

It has been resolved. Thank you!

Yes, I am referring to Marksmen that was included in the DLC bundle.
All dlc I own are checked, so I will follow you advise and ignore the message.
Many thanks for the feedback.

As oukej said: "best decription of the problem".
Thank you Wolfenswan. :)

This has been resolved since the last two updates. Thanks

Additional info
If the "walk/run toggle" key is pressed first the "forward" key works properly, otherwise "forward" has same speed as "slow forward"

Ok, my version just updated to 1.41.129601 and all is good now.

Hmm, just confirming that this is happening on the Dev Branch and the magazines are listed. I just cannot add them to backpack.

Is it working for you on the above environment?

I think I am wrong or it got fixed in Dev Branch 1.41.129601.

At the moment you can change direction but requires more travel on x axis when using the mouse, which is fine, if this was intended.

FIXED in today's update 1.41.129524.
Many appreciative thank yous!! :)

Yes, all has been confirmed to work fine in the Standard (non dev) version.

The first music (in intro)in the mission starts for a brief second and then gets muted and every instance of music thereafter is totally muted.

As of version 1.41.129509, the issue still remains.

Music cannot be played inside missions. I have been looking into the dev report that follows each update but I have not seen any change in the pertaining commands. Have I missed something? Did the music commands change?
Please advise :0

This issue has been FIXED with today's Dev branch update.
Many Thanks :)

If the respawn tents are deployed when the mission is run in a Server/client machine then they are recognized properly by the respawn position menu.

So, I am guessing the issue is related to the Dedicated Server environment

Will do and report back

I was under the impression that it was another subskill as described here:https://community.bistudio.com/wiki/AI_Sub-skills.

Thanks

I commented it out but unfortunately it did not change anything.
Such a taxing issue :(
Rpt are up. Went back on Dev branch for the testing.

The Mission is run on Regular level
From Dedicated server profile:

			Armor=0;
			FriendlyTag=0;
			EnemyTag=0;
			MineTag=0;
			HUD=0;
			HUDPerm=0;
			HUDWp=0;
			HUDWpPerm=0;
			HUDGroupInfo=0;
			AutoSpot=0;
			Map=0;
			WeaponCursor=0;
			AutoGuideAT=0;
			ClockIndicator=0;
			3rdPersonView=0;
			UltraAI=0;
			CameraShake=1;
			UnlimitedSaves=0;
			DeathMessages=1;
			NetStats=1;
			VonID=0;
			ExtendetInfoType=0;
			StanceIndicator=1;

		aiLevelPreset=3;
		skillAI=0.70000017;
		precisionAI=0.25000003;

and ALL ai units are spawned, scripted and get rpt'ed on the Headless client machine to keep it simple.

I am afraid the problem has creeped up to the current STABLE version. :)
Rpt uploaded.

I am planning to do some more tests tonight and report back.

I am at work right now but I managed to upload the two scripts that relate.
The fnc_aiSettingsKDN4.sqf runs as a function on new AI spawn in HC environment as soon they spawn.
The aiFinalSkill.sqf is scripted to run as the mission ends by default.

I can also run it through the console at any time in the mission, as the example rpts show.

Confirming again that ALL AI units, irregardless of mission, server or individual settings, are converted within 5 seconds to these settings:
AimingAccuracy: 0.940157
AimingShake: 0.940157
AimingSpeed: 0.970079
Endurance: 0.940157
SpotDistance: 0.388031
SpotTime: 0.65811
Courage: 0.940157
ReloadSpeed: 0.940157
Commanding: 0.940157
General: 0.940157

This unit BIS_SUPP_HQ_EAST also shows up in the report and I have not place it or requested to spawn. It's AI levels are:
AimingAccuracy: 0.577953
AimingShake: 0.577953
AimingSpeed: 0.788976
Endurance: 0.577953
SpotDistance: 0.315591
SpotTime: 0.404567
Courage: 0.577953
ReloadSpeed: 0.577953
Commanding: 0.577953
General: 0.577953

Also confirming that these findings are now seen on the Stable version 1.40.129533 and not just the Dev Branch.

I will verify integrity check

All files verified in Dedicated, HC and player client.

I run the same mission set up on Arma Stable version with no problem.
The AI is compulated and stays as such through out the mission.

Rpt added above

Cannot reproduce the crash anymore, in either HC or Dedicate Server, since Dev version (one before today's 1.39.128988)
Thank you

Please delete this post. I have figured out what I was doing wrong.
Secondary mouse button was also mapped to "close context menu", which I believe is new. So obviously (and finally to me too :)) the "Use Selected Action" cannot work if you are at the same time closing the menu...
My apologies for wasting anyone's time. :(

Confirmed :)

Thank you :)

I believe this parameter was integrated by default into the Arma 3 engine. Any scripting error will ALWAYS show on screen until corrected.

FIXED in Dev Version: 1.37.128595
:)

Yes, but just a few minutes ago, there was another small Steam update and the error has gone away.
So issue resolved :)