Confirmed. As long as the vehicle does NOT catch on fire, it can be repaired back to where it stops smoking.

Hello , i have same problem ! no news for fix ? thank you

The server has been bugged for exactly 1 day. I have been following for 1 day and no one can connect to the server. Will all our efforts be in vain? When do you plan to help or make an announcement about if 4325 will be shut down forever

Was this submitted to the tracker? I don't know because I've never used this before

Version 1.26.158940

I personally am satisfied with the performance but do have friends that would benefit so it would be nice to to see the latest FSR as well as DLSS 3.x. These are both game changing features for some players who need that little extra boost to get acceptable framerates.

1 day off server ? do u planning the check the this server ?

This is for every official server even pc supported servers

It seems this is still a thing. I died to a single landmine, while I had full health, but no protection (no ballistic vest or helmet). No other explosives were involved.

Aren't both 1st and 3rd person views not using the same models? (Or maybe, does a model file contains both a 1st/3rd person models?)

While we're waiting for an official solution for this, the server admins can add the following line in their server cfg to fix it:
steamProtocolMaxDataSize = 2048;

Feature Request: Usability Improvements for JIPQueue Log/Display

It seems you're encountering an issue where the Direct Connect feature doesn't work for your dedicated server. Even though the server is running on a known IP and port, attempting to use Direct Connect results in an empty list and no visible connection attempts in the server's net log. Interestingly, searching by name works, although it takes some time. However, using the connectToServer command through the menu button connects immediately, indicating the server is accessible but for some reason not through Direct Connect.

It seems you're encountering an issue where the Direct Connect feature doesn't work for your dedicated server. Even though the server is running on a known IP and port, attempting to use Direct Connect results in an empty list and no visible connection attempts in the server's net log. Interestingly, searching by name works, although it takes some time. However, using the connectToServer command through the menu button connects immediately, indicating the server is accessible but for some reason not through Direct Connect.

It seems like you're encountering a series of script errors related to undefined variables within the "Anomalous Phenomena" mission of the Contact campaign. The primary issue stems from the undefined variables such as _logic, _team, _offsetDir, _distance, and _pos. These variables are either not properly initialized or referenced incorrectly in the expressions.

If you're encountering an error each time you run the launcher, there could be several possible causes, including software compatibility issues, outdated drivers, or corrupted files. First, try restarting your device and updating the launcher to its latest version. If the issue persists, you may want to reinstall the launcher or check for any system updates that could resolve compatibility issues.

It appears that mapGridPosition in Arma 3 has an edge case issue, where specific positional inputs produce incorrect grid coordinates, potentially due to rounding inconsistencies at floored edge values. For example, [8500,4700] incorrectly outputs "084046", while [8600,5000] provides the correct "086050". This inconsistency becomes problematic when these values are used as hashmap keys or in tree structures, where duplicates can cause conflicts and errors. A temporary workaround is to add a slight offset to the position (e.g., vectorAdd [50, 50]) or convert coordinates to a string format. This approach prevents key duplication and ensures consistency in hashmaps.

In Arma 3, creating a local-only object with createVehicleLocal and then removing it using deleteVehicle is causing unnecessary "Ref to nonnetwork object" entries in the RPT log. This logging behavior appears redundant since the object is local-only and shouldn’t require network checks. Dedmen suggests that instead of introducing a new command like deleteVehicleLocal, adding checks to existing functions would solve the issue more efficiently. The upcoming 2.20 update will address this for vehicle deletions by including these checks.

With DayZ 1.13.*, BattlEye RCon now correctly supports the RConPort parameter, allowing for more precise configuration. However, omitting this parameter will result in a random port selection, which could disrupt existing server setups. Furthermore, the restriction against using the game port or BattlEye port (game port + 2) as the RCon port adds complexity, necessitating manual adjustments for servers relying on RCon tools.

I tried to script a solution for this for hours, but nothing I tried worked.

The issue you're describing, with stuttering every 148 seconds, is quite unusual. Here are a few additional steps and considerations that might help:

Looks like rolling back to older Nvidia driver - 555.85 fixes "GPU hangs" error.

@Gomo
Looks like rolling back to older Nvidia driver - 555.85 fixes "GPU hangs" error.

@Geez
Looks like rolling back to older Nvidia driver - 555.85 fixes "GPU hangs" error.

In T184694#2704105, @MilesDownshur wrote:

It reached me, but you're in the wrong place buddy. Former players who played the game since Arma2 mod till now aren't having any influence here, nobody does to be honest. Unless you're Wobo or spagetti guy, or Marks who chose the dark side. It doesn't cancels the fact the the game is one of the best, and it's greatness saved devs from their multiple f^&@k ups many times, and the fact that from time to time these guys bring something incredible (toxic zones, dambog, 40mm ammo, hummvee, Sakhal dlc) (they are same good as they are bad sometimes but this is not the point). The point is you need to storm somebody with audience and convince them to start talking about the problem. Sadly, but without that its solve takes from couple of years to infinity. But yea, I only can imagine how it feels when you can't play your favourite game because of health condition.

It reached me, but you're in the wrong place buddy. Former players who played the game since Arma2 mod till now aren't having any influence here, nobody does to be honest. Unless you're Wobo or spagetti guy, or Marks who chose the dark side. It doesn't cancels the fact the the game is one of the best, and it's greatness saved devs from their multiple f^&@k ups many times, and the fact that from time to time these guys bring something incredible (toxic zones, dambog, 40mm ammo, hummvee, Sakhal dlc) (they are same good as they are bad sometimes but this is not the point). The point is you need to storm somebody with audience and convince them to start talking about the problem. Sadly, but without that its solve takes from couple of years to infinity. But yea, I only can imagine how it feels when you can't play your favourite game because of health condition.

I really miss playing the game

logEntities has class name and position (but no vehVarName either)

He got banned again lol.
Just autoban VAC banned people, bro.

deleteVehicle has received a local check and should be fixed.
If there is a repro, I need a repro to see whats happening

I've updated documentation yesterday

Oh I see the mistake.

Server logs attached

Current client logs, 7-zipped.

above is the output currently generated. some you can pinpoint, a few have class name, most only displayName or something obscure like "Turret"

you generate captures on the server and want to view them (but also do file capturing on the client - as said using #frame/#sframe resets diag_captureSlowFrame with continuousCounter

faulty parameters (type or number) for #captureSlowFrame

"the cloud file provider is not running"

What is "faulty" input? Examples?

Why would you open the dialog, without capturing anything.
I don't see the usercase.

Should for now be fixed on profiling branch.

Add class name and vehVarName (if assigned) to network objects

https://feedback.bistudio.com/w/ft_a3_howto/gamecrash/

That's what you get for pirating

Client side logs show the same error and not much else for the aboe 2 examples:

At the moment it crashes even if I open the Nvidia overlay

Client connection test 2 - Try a direct connection

OK. I think there has been some more confusion here, but I will clarify. :)

In T186386#2703867, @priglmeier wrote:

This is only partially correct.

Port forwarding is configured and is working properly.
The LAN address should not matter. Port forwarding is set properly for Arma Reforger.

PORT FORWARDING CONFIG
Arma-Reforger Settings

FROM Any
PORT 2001,17777,27015
FORWARD IP / PORT 192.168.1.223:2001,17777,27015

Arma-Reforger-TCP
FROM Any
PORT 27015,27036
FORWARD IP / PORT 1192.168.1.223:27015,27036

So both LAN and WAN clients should be able to connect without any issues like the Arma 3 server / clients.

If the WAN client does not care about the reported ping being 999 (or ignores this), then the WAN client should be able to connect properly.
Why does the WAN client not connect as expected?

Experimental client running on Steam account with key that I purchased this morning:

This is only partially correct.

In T186371#2703829, @Geez wrote:

In T186371#2703810, @sanguine00 wrote:

@Geez

We're finding that people with early access keys can't join, but post-release keys seem to be recognized.

@Spaggie Are you observing the same thing?

Could you please check with the users if they see "DayZ Frostline Experimental" in their DLC section of the "DayZ Experimental" app?

We've not had anyone say they're struggling but it's early for us, things will spice up later

What we meant that behaviour you observed is correct, that is how it should currently behave.

Alright. The issue remains the same though. In both configurations either the WAN or LAN clients con't connect as expected.
Let's focus on Example 1 since you reported this should work properly.

Hello Cancelor.
There is nothing we can do, we cannot adjust items on the server nor we have any way to interact with them.
Regards,
Geez

Example 1): seems to be correct behaviour so we do not have anything to say to that

In T186386#2703831, @priglmeier wrote:

@Geez This issue is NOT caused by "A server ping exceeding 999 milliseconds when hosting a LAN is a normal occurrence. This is because the server is not accessible from the internet and we cannot accurately assess ping times using private IP addresses."

It is not a duplicate of T184790: Self hosted server always show "high ping server" in server browser

OPEN this case please and actually read the information presented in this BUG.
The title states "Publicly available" and this issue is not resolved.

This issue is NOT caused by "A server ping exceeding 999 milliseconds when hosting a LAN is a normal occurrence. This is because the server is not accessible from the internet and we cannot accurately assess ping times using private IP addresses."

In T186371#2703810, @sanguine00 wrote:

@Geez

We're finding that people with early access keys can't join, but post-release keys seem to be recognized.

@Spaggie Are you observing the same thing?

Thanks KK - excuse my ignorance in the context of BIS_fnc_setRain how do I reference the (presumably) first frame in the sequence of snowflake4_ca.paa?
[
"a3\data_f\rainnormal_ca.paa", rainDropTexture
1, texDropCount
0.01, minRainDensity
15, effectRadius
0.1, windCoef
2, dropSpeed
0.5, rndSpeed
0.5, rndDir
0.02, dropWidth
0.02, dropHeight
[0.1, 0.1, 0.1, 1], dropColor
0.1, lumSunFront
0.1, lumSunBack
5.5, refractCoef
0.3, refractSaturation
true, snow
false // dropColorStrong
] call BIS_fnc_setRain;