Resolved in 1.23 stable.

Thank you, we will investigate with BattlEye.

Resolved for the 1.24 update.

Made a correction on the codelines. Changing from SurfaceRoadY to SurfaceY is what fixed the problem.

Resolved for one of the upcoming updates.

Resolved for 1.24.

Resolved for 1.24.

Resolved for 1.24.

Hello LostRoads.
Is this server running vanilla configuration or are you using some sort of modified files? And have you tried to contact the server provider first?

Unfortunately Geez I don't. It seems it's only Xbox players who see me Tposing, since I haven't had any PC players tell me I'm T posing.

After update I hope a lot of glitches are fixed

No longer triggers on non-existent sections but still triggers for non-existent attributes. i.e:
"BogusSection" set3DENMissionAttribute ["BogusAttribute", ""] no EH trigger.
"Multiplayer" set3DENMissionAttribute ["BogusAttribute", ""] EH triggers.

ping, i guess we're just waiting for the wipe?

@Geez After doing some test I still haven't find an issue with server configuration that could cause this issue to occur. Where could I find to make a change to get sick from drinking gasoline?

Can confirm convoys working no issues I find many even on official, infected can remain in area after convoy despawns for a very long time. Bad luck Mdplumber87, best advice I got hangout in general area and do something like cook or whatnot to increase chance one spawns near you, don't expect every convoy site you go to, to be there.

imagine spend a lot of money and time to build a server then a random crash came and kill your server

gotcha

@Geez This is still not fixed and is disturbing when player use binoculars.
explanation: If you use same curve in X and Y axes, result will be every time diagonal, you can fix that with offset curve in one of axes or use different curve.

About a week and no convoys spawning just the zeds.

In T172490#2523479, @BIS_fnc_KK wrote:

HandleDamage is an event handler how can it broadcast anything?

Engine broadcasts result of HandleDamage at some point, not the event handler itself. The issue is that engine seems to ignore result of HandleDamage when storing damage values for map objects that will be sent to JIP clients, but correctly broadcasts them for existing clients. Logic:

• Building get damaged, should get 0.2 damage
• HandleDamage fires, adjusts damage to 0.1
• Engine broadcasts updated damage of 0.1 to existing clients
• Future JIP clients will still get original unmodified 0.2 damage

HandleDamage is an event handler how can it broadcast anything?

@Geez It would be great to fix this by fps limit if player is in queue.

This is a PC ticket for a PC problem

Might be related T172490

can u help please

The (changed) razor wire in 1.0.0.38 seems to work, at least it stayed for a whole match.
But the dragon teeth (now) show the behaviour of disappearing.

Any news about this please? Will it be fixed with 1.23 or we need to try and find a different solution for it? The server is crashing a few times per day, it's very frustrating for server owners and also for the players.

Good idea, I support it. I infinitely prefer the 3D map over the full screen 2D overlay. It's immersive. As @WeirdXone I also use alt and zoom in to read/look at the corners of the map and I don't have any problem to read any part of the maps in either Livonia or Chernarus.

@Geez please we need a fix for this issue, it keeps happening after a couple of months and in 1.23. Never happened before in years playing the game. Depending on the time, it takes even more than three minutes to join. Happens also to my friend from completely different location, Canada and Spain.

This has been an issue since 1.22 released a couple of months ago. I reported already in the ticket below. Hopefully it is fixed because it is still happening and to play I have to try multiple times, taking some of them even three or more minutes to finally enter the server.

It would be good if someone could post the server log from that encounter. I'm thinking, if it's on DayOne, shouldn't be that hard to obtain it from their server admins in discord. That's a very, very bad bug.

@Salutesh This has been an issue since 1.21. Was reported to the FT on June 6 ( https://feedback.bistudio.com/T173136 - Geez made that one private). Unfortunately it seemed to get worse with 1.22. Hopefully it's been resolved with 1.23 but there's been no mention of it in the Experimental patch notes.

Just following up with this, we upped the spawn in timer to 10 seconds, and this resolved temporarily, but this has now reverted back to occuring again. Changed timer back to default also, but this still consistently drops for players in South USA and AUS.

Both A3 and A3 dedicated server are affected. This is a possible fix:

class CfgPatches
{
    class Animations_Fix
    {
        requiredAddons[] =
        {
            "A3_Anims_F_Config_Sdr",
            "A3_Anims_F_Enoch"
        };
        requiredVersion = 1.00;
        units[] = { };
        weapons[] = { };
    };
};
class CfgAddons
{
    class PreloadAddons
    {
        class Animations_Fix
        {
            list[] = { "Animations_Fix" };
        };
    };
};

yis do dis

Might be the same bug as displayed in this ticket I just found sorry: https://feedback.bistudio.com/T175243

Also this is new with 2.14

In T176591#2522974, @dedmen wrote:

I had a report from another user about this. But turns out his PBO's were actually broken and somehow windows server didn't throw him out for that.
What tools were used to pack/sign these PBO's?

It's because "followBone" attaches the object to the "memory" LOD, which doesn't match the visual LOD:

_w = currentWeapon player;
_cfg = configFile >> "CfgWeapons" >> _w;
_m = getText(_cfg >> "model");
_o = createSimpleObject [_m, [0,0,0]];
_o attachTo [player, [0,0,0], "proxy:\a3\characters_f\proxies\weapon.001", true];
_o setDir 90
onEachFrame {
	_w = primaryWeapon player;
	//update weapon info upon weapon switch
	if (_w != player getVariable ["last_weapon", "?"]) then {
		_cfg = configFile >> "CfgWeapons" >> _w;
		_m = getText(_cfg >> "model");
		//if (_m select [0,1] == "\") then {_m = _m select [1]};
		_o = createSimpleObject [_m, [0,0,0], true];
		_off = _o selectionPosition [getText(_cfg >> "muzzlePos"), "memory"]; 
		_off = _off apply {[_x]};
		deleteVehicle _o;
		player setVariable ["offset", _off];
		player setVariable ["last_weapon", _w];
		player setVariable ["proxy", 
			[
			"proxy:\a3\characters_f\proxies\pistol.001",
			"proxy:\a3\characters_f\proxies\weapon.001",
			"proxy:\a3\characters_f\proxies\launcher.001",
			"proxy:\a3\characters_f\proxies\binoculars.001"
			
			] select (([1, 4, 4096] find getNumber(_cfg >> "type")) + 1)
		
		
		];
	};
	_offset = player getVariable ["offset", []];
	_proxy = player getVariable ["proxy", ""];
	player selectionVectorDirAndUp [_proxy, 1e15] params ["_vy", "_vz"];
	_pos = player selectionPosition [_proxy, 1e15] vectorAdd[0.33,0,0];
	
	_vx = _vy vectorCrossProduct _vz;
	
	_mat = matrixTranspose [_vx, _vy, _vz];
	_pos = _pos vectorAdd flatten(_mat matrixMultiply _offset);
	
	_p1 = player modelToWorldVisualWorld _pos;
	_p2 = _p1 vectorAdd (player vectorModelToWorldVisual (_vy vectorMultiply 1000));
	drawLine3D [ASLtoAGL _p1, ASLtoAGL _p2, [1,0,0,1]];
}

In T174022#2522941, @BIS_fnc_KK wrote:

he can manually eject from seat to parachute

Should this be possible at all? Can you leave ejection seat in real life in flight?

Not a bug.

In T176025#2523015, @Streatman wrote:

Soo... may i ask what "Assigned" means?

note: Minidump has been generated into the file C:\Users\venui\AppData\Local\Arma 3\Arma3_x64_2023-10-12_22-46-44.mdmp