It looks like the game closes due to problem with loading Steam.dll files (for accessing Steam functionality).

Can you please verify integrity of the game installation?
Right click on the Arma 3 in library -> properties -> tab local files -> verify integrity of game cache.

Hello,

I've tested it on the current stable version and I get correct values, can you please confirm that the issue is still present? Is it in in-game or Steam browser?

I've attached a screen from in-game browser.

There was an issue with number of players on Steam side. The protocol is using 1B value but it was returned by the Steam SDK as signed. We knew about it, we handled the negative values in the game and calculated correct number. The wrong number was still shown in server browser in the Steam client. Looks like the issue was acknowledged by Steam as in current Steam client since server browser shows correct values.

Thank you for mission. The server was flooded by helicopterUpdate messages, because once the helicopter got destroyed, the fuel started to leak. That was causing the change of fuel level and invoked a new helicopterUpdate message to server/clients with new fuel level. I've adjusted the priority of the fuel change, so it's should not cause updateMessage spam.

r. 127116

It's hard to tell, this one was obviously wrong and spamed server with messages but it's possible that there are similar cases with different messages (we've found similar problem that influenced only missions with sync. tasks).

There is a burst of messages when somebody is respawning (creating new unit, adding inventory items etc.) it's possible that it's giving a server hard time when there are multiple players respawning at the same time.

I'll check closely what is sent during the respawn.

Hello, the message appears only when the active Steam account gains ownership of some A3 related content (Steam let the game know that the ownership has changed). It's possible that it's caused by the glitch on Steam backend (we already had similar situation with internal version).

I've added some additional logging to Rpt file so we should have more information what is causing the message to appear. If this happen again, could you please put the Rpt file here, thank you.

It currently works only with units (people and vehicles). It should be possible to expand the manager to other types. What objects do you have in mind? You mean like other objects placeable from editor?

Default behavior of the manager could be controlled by corpseManagerMode/wreckManagerMode value in description.ext where:
0 - AddsNone - None of the units are managed by default.
1 - AddsAll - All units are managed by default
2 - AddsNoneButRespawned - Only units that can respawn are added
3 - AddsAllButRespawned - All units are managed with exception of respawned (opposite to mode 2).
Example manage all corpses:
corpseManagerMode = 0;
When not defined, the manager is in mode 0 for SP mission and in mode 2 for MP (for compatibility reasons the behavior is same as before the manager).
This is default behavior, it could be always be overridden by removefromremainscollector/addtoremainscollector script functions to flag additional units to be or not to be processed by manager when they are destroyed.

Hello, can you connect directly via remote button (bottom left corner, right next to Join button)?

It looks like the server is behind the NAT and it's not visible for Steam services. If possible, try to open/redirect game port + ports for Steam to your machine with server.

Ok, so you can see each other in browser (so it's not problem with master server) but you can't connect, even by using remote (which bypasses the browser), so it looks like it's the connecting itself. If I'm reading this right, this happened since 1.18, it was fine on 1.16?

Is this server on public IP (is it DS) or are you creating the session in the game? Have you tried different ports (to rule out conflict with other services)?

Hello, it looks like your server is not visible for Steam (Steam master servers can't reach it) and that is why it's removed by Steam from the list of all available servers. You can setup the Steam port (parameter steamQueryPort, default value 27016) and make sure this port is open and redirected to your machine.

Hello, is the server on public IP or is it behind the NAT? Servers don't show up on Steam if they can't be accessed by the Steam servers directly. Also the message could mean the connection is not correctly redirected to the server and client can't reach the server.

If it's not solved, then reopen it. The partial word search should be back, I've reverted the Steam query and results are filtered locally with partial word support.

EDIT:
It should have been fixed in:
07-05-2014
EXE rev. 124229

Not possible to filter the incoming servers one by one?

That is what I meant, browser is receiving sessions from Steam one by one. Each session has to be checked if it passes the filter and it's displayed, if not it's discarded. The steam is asked to return only sessions that contain words set in filter, so the list and checks are faster but Steam doesn't support partial words match, so sessions that are matching the word only partially are not returned by Steam.

Reverted back to downloading whole list of sessions and matching server and mission name locally. The partial word match should be supported.

r. 124228

Hello, yes, the problem is that the Steam query doesn't support partial world match. There used to be a local solution, where the Steam has been queried for all sessions and local client filtered the results. The problem of that solution was that the client had to download the whole list of sessions (sometimes more than 2k sessions) and process them to find couple sessions that matched the filter. As the result, it took a long time to show results.

Hello, thank you for detailed info. The information from the Steam server has to be downloaded by multiple queries and it looks like the router is detecting that and is triggering an alarm.
Could you please try to use GameSpy (click on Steam button at top right corner)? I'm guessing that will works fine.

Also, if you have any other MP games on Steam, could you please test if their browsers are working? It's important that they are using Steam API for matchmaking (basically anything from the Valve like TF2 or CS).

It will be in dev build, the version of the game has to be greater than 1.19.124227

I've adjusted a Steam server initialization, the -ip= param is passed to the Steam to force it to use this interface.

r. 124227

Can someone please test it and confirm that the fix is working?

Hello, could you post a little bit more details about the problem? You mean the Steam server pick up local IP instead of public WAN address? Or you have multiple LAN cards and it picks up the wrong one?

Keep using 2302, this is the port the game will listen for client to connect (direct client-server communication), the 27016 is used by Steam backend (Steam servers) to check that your server is still created and downloads information about it (like name, mission...).

When you create the server, it's registered on GS and on Steam, since both services are still online. It won't be long before the GS will shut down and the only Steam will be used.

Hello, we are currently switching from GameSpy to Steam. If you want to host the server that will be visible in Steam browser (default option for Dev), you have to forward some ports for Steam (default is 27016, DS can switch do different port by config option). That should make your server visible in Steam server list.

About the lags, the message is from the GameSpy library, looks like there are issues when communicating with GS servers, it's hard to say if it's library traffic issue or it's related to something in the game.

I've found that the face and glasses are updated when player takes/releases control over the unit (body). This includes respawn and disconnect/join cases.
Disabling the update could lead to possibility to switch identity of all playable AI units in the mission (by repeatedly joining into different roles/AI units).
I can disable the switch only for dead units but it's kind of similar, there will be dead and alive units with the same identity. Wouldn't that be confusing in the mission (especially for alive AI with player's identity)?

I've managed the find 256 characters for mod hashes and another 256 for signatures so Steam browser should be able to check both and adjust the icon accordingly. From what I've found that GS used max of 200 characters, so it could be considered an upgrade.

I'm looking into it, unfortunately the space available for each session on Steam servers is quite limited to store all mod hashes and signatures. I'll try to find a way to make it work.

Parameters are passed in _this as for any other mission event, I've added the _name today (r. 126917).

The event handler should already be in the Dev (without _name), please let me know if there is anything missing/not working.

@Killzone_Kid when eh returns true it's considered that eh has managed the unit, the code does nothing, just leaves the unit there (the behavior is same as if the the AI is enabled for the role). When player connects back, it just starts to control the unit again.

Basically, the return value of the eh can disable the killing part of the locality transfer that I described earlier.

I've managed to create new mission event called "HandleDisconnect", you can register handlers via addMissionEventHandler, it behaves same way as other mission events (Loaded, Draw3D etc.).

There are three parameters: unit, id and uid (last two are same as _id and _uid for onPlayerDisconnected). Return value is bool, if returned true, the unit is left untouched (AI controlled). If no eh or returned false, it checks the role options and unit is killed if AI is disabled (same behavior as before the eh).

The eh should be in next dev.

@AgentRev @SaMatra My bad, looks like the server events are only for internal use and they are not accessible by scripts. I've found the onPlayerDisconnected, that is basically a simple script code directly called when the player is disconnected.

One more question about the killing the unit:

Current behavior works like this:
When the player disconnects, the controlled unit is released (switched to AI) and all local units has to be transfered (locality has to be moved) to other machine (server). The target machine accepts the units, making them local. Then each unit is checked if it's playable unit and AI is disabled, then this unit is killed and removed.

The first part can't be changed, unit has to be local somewhere (somebody has to be responsible for simulation/updates etc.) so what I have done is that I've added an event handler before the last part when the unit is checked for playable/AI (before the unit is killed/removed). If the handler returns false, then it's processed as normal (killed/removed if AI disabled, left in scene when AI is allowed). My question is what should happen when the event handler returns true.

1. Leave the unit as it is - that means it's for event handler to move/kill/remove the unit. If the handler does nothing (apart from returning true), then the unit is left in the scene, controlled by AI even if the AI is disabled for this unit/role.
2. Kill unit, then fire the event handler - the handler can decide what to do with the dead body but unit is dead (doesn't leave live AI unit).

The advantage of the 1. is that handler has full control over the unit, disadvantage is that this allow an AI controlled unit when this is strictly disabled in the role selection/description.ext.

Which one of these two options is acceptable? Do you prefer any other option?

I've done some digging, there is a server-side event handler called OnUserDisconnected. Can we use this one instead of adding the new one? It would make more sense to be server event than mission event since it's server network logic that handles the disconnection. Are there any differences between server and mission events from script side that I'm missing?

Hello, sorry for the delay, I've recently reworked a corpse/wreck manager so I would like to also fix this issue since it's related.
You asked for event when the player disconnects, If I understand it correctly, you want event similar to Fired, Dammaged or Respawn for the unit the player controlled. I think the even should return a bool to let the code know if it should proceed normal way (unit killed and later removed) or the event handler had taken care of the unit and this action should be skipped. Also this event should be fired on the server as local event?

The manager is trying to keep maximum number of allowed corpses in the scene. It works the way that the oldest corpse is removed from the scene if the current number of copses is bigger than corpseLimit but only if the oldest corpse is in the scene longer than corpseRemovalMinTime. It also removes corpses that are longer than corpseRemovalMaxTime (default is 1 hour).

The manager is used only for units that are respawned by in-game mechanic (AI in player slots and players, it's not used for units generated by scripts). We can expand the system for AI if you find it useful (but thats probably for another ticket :)

I'll look at the event handler later to see if the change is possible. I've switch from hideBody to addToManager so we can test it.
It should be in the next Dev version (r.125433).

Hello, sorry for delay, I've finally get closer look at this. I've found the problem: When player disconnects, the locality of the player's unit has to be transfered. During this transfer the unit is killed if it can't be transfered to AI (in reported case it's already dead) and then the hideBody action is directly called on the body (to remove it immediately).

The most simple solution is to add body to bodyDisposeManager instead of hiding body immediately. That would mean the body will behave same way as any other body in the scene. The manager makes sure there is only limited number of dead bodies in the scene (too many bodies are creating performance issues) and that body remained in the scene at least for some (minimal) time. The manager could be parametrized by corpseLimit, corpseRemovalMinTime, corpseRemovalMaxTime parameters in description.ext.

Would it be feasible hotfix for the problem?
Later we can also add additional parameter to leave the player's bodies outside of the manager and add the event when player leaves so you can handle this manually.

My suspicion is that when user disconnects, the AI take the players' unit and then the general 'hide copse' algorithm will remove the body from the scene.

Hi, can you create another ticket for identity issue? I think it's worth to investigate what is happening.

Should be fixed with game version greater than 113136 and addons with version greater than 60403 (soft_f, soft_f_beta, soft_f_gamma, could be found in rpt).

Reopening, waiting for confirmation when new version will be released.

Ok, you have been a little bit faster than me :)

It shouldn't be fixed yet, there are still some data changes that are not part of todays update. That list is generated from the code logs, there have been some changes in the code but to make it working completely, the init scripts for vehicles has to be changed as well.

BTW, I've been able to switch texture of the bag on the unit and it's JIP compatible. I was using the command:
backpackContainer player setObjectTextureGlobal [0,"#(rgb,8,8,3)color(1,0,0,1)"];

Thank you, I think I've found the problem, it's probably caused by init script that randomly changes the texture of the car (civil car, offroad...). The init scrip is called after the JIP messages are processed. I'll investigate more to confirm it.

Are you spawning the vehicles by script? Could you add the mission?

I have a problem to reproduce the issue.
What I did:

1. In editor, placed two playable soldiers and two vehicles (offroad).
2. started the game, joined by client
3. client used setObjectTextureGlobal on offroad -> texture changed for both players.
4. client leaves the session, reconnects, offroad has new texture.

Thank you. Closing.

Fixed, it should be part of the next update.
Fix revision: 112694

Rain doesn't follow the camera/player, but it falls so fast that it's not visible. It's more clear when rain is slowed down (could be done in config) but then the rain doesn't look very convincing (feels more like bullet time effect).

This should be optimized already, the normal generic serialization should not be used for simple types including arrays.

Last related change has been done in revision 130744. Can someone please test if this issue is solved and we can close it?

Should be fixed now, the rain should be less dense in the clouds and rain effect should be disabled above the clouds.

Thank you all for the feedback and your help. We can reopen the issue in case the problem occurs again.

We get information that there was a update of the Steam client that should fix the problem. The corrupted missions have to be uploaded again but it should be working now.

We have a response from Valve, it looks like it caused by workshop servers (some kind of data corruption), they are working on the fix and they'll let us know when it's ready. The corrupted missions will have to be re-uploaded after the fix. I'll let you know when we hear more about the issue.

I'm not aware of any changes that could cause these restrictions. We are still investigating the problem with Steam.

I can confirm the issue. Unfortunately it looks like it's the problem of the Steam service. I'm unable to download the file manually even via Steam client. From the Steam directory, it looks like it gets stuck in the Steam\userdata\<value>\ugc\download directory but with 0 file size.

In the game, the Steam API is closing the query with generic fail error code. I'll contact the Valve and try to find out more.

Arma3Server.exe is always creating an internet game. If you want to play only on LAN, one of the players has to host the game. If you are playing on one computer (testing missions etc.) you can switch DS (arma3Server.exe) to accept only local connections by setting loopback option in server config.

The reason is to limit massive use of DS servers that are running without ownership checks (running in LAN mode).

What I was trying to say by my first post is that the updating is now handled by Steam. It could be possible to build another in-game cache, that would keep the missions regardless of the Steam behavior. Also in offline mode, you probably won't be able to download list of subscribed mission, so that would have to be handle differently as well.

That is handled differently. The mission PBO is now part of the workshop mission save. When you load the game, the mission pbo is loaded from the save. If you restart (revert) the mission, new mission is downloaded from the steam.

This way you can resume the previously saved game and finish it without worrying the author will break your saves by updating the mission. If you want to play last version you need to restart the game. In general, there is no safe way to load old save on new mission, because it depends on the changes done in the newer version (new scripts, new units in the map...).

The workshop file download/update process is handled by steam API. The game ask for file and the Steam provides the latest version of the file. If the file is not changed, the steam should provide the file from it's own cache but I'm not sure what rules apply to the steam cache and how it's handled by steam API.

What I'm trying to say is that unfortunately in current version, the game doesn't have control over the downloading and updating process.

Please start the game with parameter -enableSteamLogs and go to Scenario (reproduce the issue). Then send me the RPT file.

http://community.bistudio.com/wiki/Crash_Files#Arma_3_Alpha

This should be fixed now. Could you please test it in the last version of Dev build?

This appeared only if you subscribed more than 50 scenarios.

Fix should be in current Dev build (0.77.109446). Could some please test it and confirm it?

Good to hear, thank you all for help.

Good news, I've finally found the problem and it should be fixed now. Unfortunately it will be part of the tomorrow's update as a today's update is already in process.
Fix has revision 109409.

There was a problem when the list of missions is more than 50 items long, then it has to be retrieved from the steam in multiple steps.

Thank you for response. There is some information in that rpt. Looks like the process has stopped when retrieving the list of mission ids. It doesn't look like it failed, just hanged. It could be possible that it's just waiting for steam to return results.

I've fixed one possible place that could cause the issue and also added some more detailed logs in that particular functions to see what is happening.
Changes have revision 109399, it should be part of the tomorrow's update.

Have you tried to publish any mission from the editor? Does that work fine? Also, do you have any other game with WS functionality, does the WS work there? I just want to rule out the possibility that steam API is unable to send some queries to steam server.

This is part of the new logs that I posted yesterday but the update is still not on Steam.

Current version is displayed in main menu in bottom right corner (currently 109344), when the number will be higher than 109399 the additional logs should be available.

From your last log it still looks like it stuck on the same place. How many missions have you subscribed? +50?

There is a new command line parameter -enableSteamLogs, that will enable additional logging to RPT file.

If anyone has and issue with the steam workshop missions, could you please start the game with that parameter, reproduce the issue and then send me RPT file (or post it here), it would be greatly appreciated.

RPT file could be found in user profile directory: http://community.bistudio.com/wiki/Crash_Files#Arma_3_Alpha

I've already implemented that, but it's enabled only in internal version. I'll look into that.

If I'm looking correctly the current steam version is 108717 but the fix is in 108782.

I've talked to our distribution guys, today some Steam dev servers/services are down so we can't build new public exe. Currently uploaded exe was built yesterday. It's couple revision newer then the previous one but it doesn't include all the changes.

If everything goes well, the fix should be available in tomorrow dev version.

Btw, awesome mission, I like it :) nice work.

The basic support has been implemented: http://forums.bistudio.com/showthread.php?149636-Beta-Development-branch-changelog&p=2430103&viewfull=1#post2430103

About the ping and user/administrator, the game takes the values from the GS API (or Steam API in case of Steam browser), the values are calculated by the provided libraries, that's why you are detecting only GS/Steam communication.

About the Steam browser and slow update. The difference is that GS provides ability to query only sessions which matches certain string in name, map, mission... The Steam doesn't have that, only map can be filtered (and it has to be exact string), so the client has to download the whole list of servers and filter it locally.

Please create another issue with the slow Steam filter since it's another problem, I try to look for some solution.

I have a problem of reproducing the issue.

• Started arma3server.exe -config=a3.cfg
• server config is pretty basic, disabled BE, added localClient[]={127.0.0.1}; filled password option to 123.
• Started arma3.exe -client -connect=localhost -password=123

Server:
14:55:55 Dedicated host created.
14:55:57 Host identity created.
14:56:12 Player george connecting.
14:56:14 Player george connected (id=xyz).

Client:
14:56:10 Dedicated client created.
14:56:13 > Player george connecting
14:56:14 > Player george connected
14:56:16 > Hello and welcome.
14:56:17 > Have fun testing.
14:56:18 > :-P

Could someone please test it on current version?

Type: Public Beta
Branch: Development
Version: 0.75.108717

Are you trying to host/join internet or LAN game? If it's an internet game, it could be an issue with NAT tunneling. Are you able to join any other game?

The special characters are replaced by Steam to question mark. When tested on internal version the special characters works just fine. Looks like the Steam client is altering the parameters.

Switching category. It would be probably problem with collision geometry.

Switching category.

Switching to correct category.