this is most likely caused by cache.ch file (corrupt or similar) in root where arma3_x64.exe binary is
erase just cache.ch file and run game again, the file will be re-generated

this is most likely caused by cache.ch file (corrupt or similar) in root where arma3_x64.exe binary is
erase just cache.ch file and run game again, the file will be re-generated

this is most likely caused by cache.ch file (corrupt or similar) in root where arma3_x64.exe binary is
erase just cache.ch file and run game again, the file will be re-generated

this is most likely caused by cache.ch file (corrupt or similar) in root where arma3_x64.exe binary is
erase just cache.ch file and run game again, the file will be re-generated

this is most likely caused by cache.ch file (corrupt or similar) in root where arma3_x64.exe binary is
erase just cache.ch file and run game again, the file will be re-generated

this is most likely caused by cache.ch file (corrupt or similar) in root where arma3_x64.exe binary is
erase just cache.ch file and run game again, the file will be re-generated

this is most likely caused by cache.ch file (corrupt or similar) in root where arma3_x64.exe binary is
erase just cache.ch file and run game again, the file will be re-generated

this is most likely caused by cache.ch file (corrupt or similar) in root where arma3_x64.exe binary is
erase just cache.ch file and run game again, the file will be re-generated

this is most likely caused by cache.ch file (corrupt or similar) in root where arma3_x64.exe binary is
erase just cache.ch file and run game again, the file will be re-generated

this is most likely caused by cache.ch file (corrupt or similar) in root where arma3_x64.exe binary is
erase just cache.ch file and run game again, the file will be re-generated

this is most likely caused by cache.ch file (corrupt or similar) in root where arma3_x64.exe binary is
erase just cache.ch file and run game again, the file will be re-generated

this is most likely caused by cache.ch file (corrupt or similar) in root where arma3_x64.exe binary is
erase just cache.ch file and run game again, the file will be re-generated

this is most likely caused by cache.ch file (corrupt or similar) in root where arma3_x64.exe binary is
erase just cache.ch file and run game again, the file will be re-generated

this is most likely caused by cache.ch file (corrupt or similar) in root where arma3_x64.exe binary is
erase just cache.ch file and run game again, the file will be re-generated

this is most likely caused by cache.ch file (corrupt or similar) in root where arma3_x64.exe binary is
erase just cache.ch file and run game again, the file will be re-generated

this is most likely caused by cache.ch file (corrupt or similar) in root where arma3_x64.exe binary is
erase just cache.ch file and run game again, the file will be re-generated

this is most likely caused by cache.ch file (corrupt or similar) in root where arma3_x64.exe binary is
erase just cache.ch file and run game again, the file will be re-generated

this is most likely caused by cache.ch file (corrupt or similar) in root where arma3_x64.exe binary is
erase just cache.ch file and run game again, the file will be re-generated

this is most likely caused by cache.ch file (corrupt or similar) in root where arma3_x64.exe binary is
erase just cache.ch file and run game again, the file will be re-generated

this is most likely caused by cache.ch file (corrupt or similar) in root where arma3_x64.exe binary is
erase just cache.ch file and run game again, the file will be re-generated

this is most likely caused by cache.ch file (corrupt or similar) in root where arma3_x64.exe binary is
erase just cache.ch file and run game again, the file will be re-generated

please try the performance binary from profiling branch , it contains multiple crashfixes

any reports of this bug since 1.70 ?

question, still issue with 1.70 ?

repro / more data is indeed needed
also check RPT logs if no samples are missing or similar errors ...

the actual logs seems like out of memory crashes on 32-bit binary, please try use 64-bit

that's 1.68.141262 build of PROFILING branch just in case someone wonders

crash relate to "Old Arma2 Car simulation" used
please note that This simulation is not maintained for many many years and it might be very buggy

thanks ianassa, this explains why you get the crash, the hotfix which is build 1.68.14112, it didn't fix all the cases
that's why I suggested you to try profiling branch (performance binary is default) with build 1.68.141149
the performance binaries are discussed in another sticky thread on the steam discussions

question, does it still happen with 1.68.141112 (or newer) ?

crash is caused by wrong data set as Map with scale = 0;

thanks, tracking internally

@Lex out of curiosity, I've those questions:
What Operating System you have ?
What Intel CPU you have?
What security software you run ?
Do you have any other software which might be using hardware virtualization (e.g. sandboxie, virtualbox, vm ware etc) ?

workaround is install steamclient and just let it running on login screen
fix is wip , no eta for now

thanks, we will take look into this

please try now and report back if the issue still un-fixed, thanks again ...

thanks, will look into it

the feature isn't finished in main branch stable binaries
it's still work in progress (actual state seen in performance binaries in profiling branch)
it's not part of 1.64.RC either, only profiling / development branch ...

did you tried to use the performance arma3.exe from profiling branch ?

seems like it's issue with taskState not working/returning anything on dedicated server?

my suggestion, do not run any unknown executables (binaries/libraries) from internet , most likely it's form of malware like trojan to steal your STEAM login/pw and your email access etc.

note: this https://forums.bistudio.com/topic/127167-patch-the-game-to-prevent-ddos-exploit-please/
is unrelated issue, the cause at that time was GameSpy query and was fixed by enabling security countermeasures in theirs in theirs framework
our engine netcode issue was sorted by handshake implementation etc.

Arma 2: OA 1.63 and Arma 3 are now utilizing SteamWorks framework

old Arma 2 clouds were completely removed afaik,
so this isn't as simple as you think

ye I got it in wrong order,
of course when the function is defined on server
then it should be callable on server from client via RE
if enabled (allowed) to run RE from client on server
(not sure about specific-password protection in that case)
must always think about the possible security risk involved

disabling something instead of fixing it isn't exactly option ...
with such approach you can toss whole weather feature off window ...

anyway there is 1.48.131439 release candidate available and includes weather sync fixes so please test it there

also the problem you mention sounds more like mission issue cause it's trying use obsolete approach how force weather

please use recommended security settings in your server.cfg
https://community.bistudio.com/wiki/server.cfg#Server_Security
note: works fine at 1.46.131175 server & client

note: try use -ip= for Headless Client (same as for server) , at least with Arma 3 it seems to resolve the issue

another tip : for A3 one may try to use -connect=%COMPUTERNAME%

it's WIP

this ticket covers work-in-progress change in underlaying system which was explained in http://dev.arma3.com/post/sitrep-00108

so don't blow it out of proportions, atm. it's quite buggy but expect it to be improved over upcoming DEV branch builds

voting for admin is enabled prior mission , not after it started ...

which server ? (IP or name)

it's missing the logging into RPT with reason why it failed
usually it means incorrect format of squad XML

we need to know your IP (local,external) if you have multiple NIC on the client
same goes for the server

plus ideally to know whole route via tracert command

please post this information as private reply

in meantime as workaround use BattlEye RCON

similar features are on the long-term wishlist but it's not as simple

1. you need ensure correct behavior

A. if target server is unavailable
B. if target server is full

2. decide if further information about player are sent (e.g. position, vector, vehicle, equipment etc.)

as this would help e.g. side of map transits

3. other issues

thanks for the ticket ... discussing

afaik the HC fps shall be decoupled from SERVER fps

can you please try DEV branch 1.39.129234 or newer,
can't replicate the issue on it

no normal isp uses MTU ~ 1200 ... that's cheap excuse,
standard MTU is 1400 to 1472

the same setting for packet size is in both A2: OA (arma2oa.cfg) and A3 (arma3.cfg
https://community.bistudio.com/wiki/arma2.cfg#Generic_config
class sockets{maxPacketSize = 1400;};

this issue should be resolved in Arma 3 DEV 1.45 and Arma RC 3 1.46 and A2: OA 1.63 beta

btw. to fix the crash, just rename beserver.new to beserver.dll (while server isn't running ofc)

not bug, use -autoInit instead

so silly me, i totally forgot we added new server parameter to autostart mission (no need for HC anymore), the limitation to persistent=1; still do apply
-autoinit

what's your PIP setting level ?

https://community.bistudio.com/wiki/isNil
https://community.bistudio.com/wiki/isNull
read descriptions and examples and syntax please ;)

so IMHO, no bug there

solved by server package update with correct EBO signatures

note: dedicated server data package was updated,
please reupdate/reverify your installs

thanks eRazeri, your report helped to find the cause ;)
you fully right that the .EBO server files got corrupt signatures

we will try solve it asap

I would suggest to share this info with QUALCOMM / Killer NIC driver developers too

start > run > dxdiag , press enter
chose save all information > save the file, upload it here

isAdmin isn't optimal as there are two different admin types (logged-in vs voted-in)
so more like command returning the type (not admin, someadmin, anotheradmin)

security and exploits always were priority
so I think I don't need explain anything to You ...
no idea what you mean with "Beta test hack fiasco" there was no such test ...
you just assume something and you assume wrong ...

WIP means "Work In Progress" ...
you ignoring fact that any solution needs to be tested too ...
so you must endure and wait until the fix

imagine if you accidentaly click on some steam URI in browser or e.g. server in steam server list, it would then leave your actual server

atm. you need to be offline from server for those two to work

server forwarding of players (if locked, full or from ingame via scripting etc.) is completely new design feature to be done

only middleway would be introduction of new popup like "you trying to connect to another server, do you want leave actual server with Y/N dialogue (No as default)"

reopening on Nou's request

please add to your server.cfg this option
guaranteedUpdates = false;

tell us if it have any effect
but make sure you tested it in depth to be sure

as it may not help
cause in 1.27 DEV branch there are new additional desync fixes

please try the performance binary
http://forums.bistudio.com/showthread.php?169944-Arma-3-STABLE-server-1-24-quot-performance-binary-quot-feedback&highlight=performance

the download is hidden under spoiler button ...

all you need is replace the server binary with the one 1.24PERF4

more likely fixed in perf4/prof4 - tho needs to be retested against this new repro

thanks for clarify
(just for full picture, the same mission when placed into \Missions\ does it work or returns errors?)