suma

Q: When I save during the game, it often crashes. It happens with autosave as well. A: It looks like OFP is allocating very much memory during saving the game state. To work around this, increase size of your swap file (400 MB works for most users, some reported 1GB swap file helped them).

The fix was implemented wrongly. All it did was to disable the "failed to setup extended errors" message, but the error code was still returned. Should be fixed properly in 102936

It is not causing issues until servers start require secure id - once they do, you will be unable to connect to such servers. I would like to check as much as possible why is it failing to you. Is there anything you can tell me about your internet connection (do you need proxy to connect, or anything like that) or about the OS you use? If you hesitate to write this on a forum, feel free to post me a private message.

Thanks for reporting this. The registration server has been fixed now, and you should no longer get a "Data too long for column" exception the next time you will try. You may still get some other error, thuogh. In any case, once you try it, please, post the result here.

Crash identified, repro with -world=Utes helped a lot. The eyeDir fix is causing this, as the function is unexpectedly used from other threads as well. I will check what can be done. ---------- Post added at 16:37 ---------- Previous post was at 15:30 ---------- The thread safety issue should be fixed in 101245. I have to admit I am not absolutely comfortable about the fix, there are some things puzzling me in the code around it, as it seems to contain some parts not useful anymore. I will try to understand and clean it, I appreciate any testing regarding game stability you can do meanwhile. The code handles the skeletal animation of both people and vehicle, therefore what you could do is to test if any crashes happen when various types of vehicles are used in the missions.

Does not sound like related to me. If the problem was with the secure ID, you should: - see the error message while connecting - not connect at all to the server I cannot see any way how it could allow you to connect and then cause some trouble. later

You need to install 100496 or newer, and the SSL connection error should be gone. The server version does not matter in this case.

You did not mention which A2OA build are you using. Recent beta builds since 100423 should not require the hotfix.

This should be already fixed in 100423 and newer. Please, test with the current beta and lest us know how it went (do not forget to write the build number you are using).

As the hotfix did help (verified through PM), I have adjusted the SSL access code on our side in 100423 so that the access works without the hotfix as well.

I understand you made a lot effort into this, however there are some mistakes in this guide which make me wonder how reliable is the performance testing done with the tweaks, as in following cases the tweaks suggested do nothing at all: - localVRAM and nonlocalVRAM are write only. Game never reads them, you can change them how you want, it does not matter at - winhoard.dll cannot be used in its default state, as it does not conform to our allocator interface. Someone would have to make a derived project first and plug the hoard into the interface the game expectes. When you use winhoard.dll, you actually get a default allocator instead (same as without -malloc option). It is therefore strange your reported results are different for winhoard and tbb4malloc_bi.

Could you try installing This Microsoft Hotfix?

I am sorry, the build 100258 did not include the diagnostics (caused by a build process quirk, which is being fixed now prevent it happenning ever again). Please retry with 100296 - this build also contains updated libcurl / schannel libraries, therefore there is a slight chance the issue might be even fixed by it. If not, please, post the .rpt here.

Hm. Strange. I will double check the error logging, it really should contain more.

If you please could try with 100258 and provide a report file, that would be a lot easier and faster for me. I have no direct access to the private SSL key, and looking into the logs will be much faster and convenient.

Build 100258 should contain extended reports logged into the .rpt file in case of any HTTP errors. Please, try this version and post the rpt section corresponding to the is.bistudio.com connection here or send it directly to me via person message.

Are you aware if there is perhaps anything special or unusual about the way you access the web (http/protocol)? Does your web browser has any proxy set up for the connection? When you try to access https://is.bistudio.com/BICDKeys in your browser, what do you see?

This feature is already present in all 1.62 servers, however before the 99700 it needs to be enabled manually by specifying requiredSecureId=1 in the server.cfg.

We are now over 20000 of secured ids, with over 80 servers using the features . A new beta 99700 changes default to requiredSecureId=1, therefore we should see much faster adoption rate soon. We shall see if the server will still handle the load (it should). We also have first ID banned because it was registered by too many distinct players - more of this will most likely come soon as well.

You would see it in the server console between the connecting and connected messages. If there are no messages about any failures there, it means nobody without a valid certificate has connected to your server.

We are at 3500 secure ids issued with 42 servers running secured ids, no anomalies observed, everything seems to be working fine and smooth.

Issue fixed (access rights on the server did not allow access to the service at all, and the failure was badly reported), server should be running OK (and I already see 50 verified IDs issued).

I see no secure ids issued since my last post, but I can see some server are using it (and have some players). How does it look from the server side now? Are the players reported to have registration failed or ?

The server problem should be fixed. The problem was a badly designed JPQL query, which was about 100x slower than it should be. Brave server admins may want to use requireSecureId=1 again.

I can still see some player id traffic on the server. I have identified an issue causing the timeout, it should be resolved shortly (I will notify you here once it is done). Meanwhile I kindly ask server admins to use requireSecureId=0 until it is fixed to prevent more players failing id validation.