george_

Hi, this error means that game tried to verify signatures for the file but the verification failed. This can be caused by invalid or missing signature file (bisign). With the last update two addons have been removed from the data: modules_f_kart.fbo and modules_f_kart_data.fbo. These two addons should have been removed by the Steam (also with their's bisign files) but it looks like for some reason they stayed in addon folder and probably only bisign files were removed. This is causing an issue because the game is trying to load these addons but bisign files are probably missing, so they can't be properly verified. In this case moving/deleting file will help since it should not be there after last game update.

Thanks for confirmation, the fix should be also part of the new performance build.

The fix of DS for Windows and Linux version should be in the DEV (r. 134731). Can someone please confirm it's working (I've tested it only in my lab conditions)?

Hello, sorry for the inconvenience, we are looking into it. You are right, the Linux issue is due to permissions to semaphore, we already have fix for it. As for the Windows servers, I have problem to reproduce the issue (locking is done differently). I tested multiple DS servers on single Windows machine by simply running multiple servers under various users at the same time but with no luck to reproduce the issue. I guess the trick is to run DS as services as you mentioned. Since the FT is still down, can you please post more details about how exactly you are running the DS? Does it simply locks or DS crashes? Do you have any Rpt files?

Basically anything else than: scalar, bool, string, object, group, side, nil and array. Ex. namespace, config, display, control, target, task...

Hello, yes, this warning message is new. I've looked at the way how the values transferred by commands like publicVariable (and others) are sent over the network and found that some types are not very space efficient. I've optimized the most used types to take much less space, which should result in much smaller messages (saving bandwidth). Since there are a lot of types, not all of them are optimized yet. What this warning means is that the (old) generic algorithm used for transferring value, which is not very efficient. If possible use some simple types: scalar, bool, string, object, group, side, nil and array. The command will still works with other types, it just won't be as efficient as if the simple type is used. The warning is to let mission designers know that they are transferring types that are not optimized. If it's displayed only few times, then it's not a big problem, the main purpose is for values that are transferred very often during the mission. TL;DR: We optimized values transferred by publicVariable (and similar) commands, added warning for other types that are using old generic (not optimized) serialization, which is still working correctly but can mean higher traffic if used often.

Yes, you still be able to directly connect to server as long as it's accessible from the Internet (port forwarded if you are behind the NAT). The shutdown will affect the server browser, there will be no master server (GS) that keeps the list of all available servers.

Yes, it is intended. We decided to restrict only basic entry actions and keep the script functionality so they can be used e.g. in mission scripts.

I've found a little bit of space, no feature has been dropped. Actually, I managed to get little more than it was available for GS. The price that had to be paid is that it's retrieved from Steam by another async. operation.

Hi, this is caused by workshop missions. The crash should be fixed in Dev and will be merged to Stable very soon. Since a few days ago, Steam started to return some workshop missions without some core data and that revealed some nasty bug in the code. The game should handle that without crash now but it's possible that even with crash fix some workshop missions won't be visible in the game due to missing data. We are currently investigating if it's possible to get missing data in different way until it's fixed on Steam side.

Hello, the problem was caused by workshop missions. The fix is ready and will be published with next update.

As Dazhbog said the technology is still in early prototype stage. The "accident version" you saw is even missing some key data assets and is far from complete.

There is no need to create steam_appid.txt in steam game directory, it's part of the distribution (in dev branch).

Because the DS always starts in public mode and checks client's steam ticket. That prevents multiple connections under same steam account. You can't start the game multiple times from the Steam client but you can start multiple instances of the A3 if you start arma3.exe directly from the steam directory. Then you can create LAN game and join the game from other instance of the A3. I know it's not the same as to have local DS, but at least you should be able to run LAN game on one PC.