suma

Some of the players experiencing failing BAF / PMC signatures, can you please post results of -checkSignatures here or in http://dev-heaven.net/issues/26783?

Engine side solution has a performance advantage of doing this for airborne planes only - empty planes or other grounded planes are not affected by this. The rationale why only planes and not helis that planes are mostly flying higher, and there are less planes in the mission, but in principle the solution can be easily extended for helis as well later.

http://www.arma2.com/beta-patch.php Contains tweaks to helicopter ground effect (a bit increased), and fixes of aircraft AI/autopilot landing (http://dev-heaven.net/issues/26933)

Implementing ground effect for aircraft was a straightforward uncomplicated work which took less then 1 hour including some basic testing, and there is little risk it could break something else, as the effect is quite isolated. Compared to this, fixing pathfinding issues tend to be difficult and complex, and it is easy to break something with the fix. Definitely not something to be done just before release if the issue is not really making the game completely unplayable. Yes, this also affects the decision. Developers are still - at least partially ;) - weak human beings. :)

Use -beta=xxxxxx instead of -mod=xxxxx to provide beta specific files without disabling Expansion GUI functionality.

It makes sense to use them both, as FXAA is a lot better in smoothing some edges, while MSAA solved some subpixels artifacts better (and allows ATOC).

Back again in 86705. SP using SLX, when being dragged or healed by a squad mate the animation stuttering is severe. It seems a time machine was used to report this "Back again" of a fix in a build which was not published yet? (86705<86842) :)

Issue confirmed, introduced in 86697 (when fixing http://dev-heaven.net/issues/26423#note-10), fixed in 86842

Nice observation. I was able to reproduce it on Utes easily (setAccTime 0.1 helps to be able to abort in time). Does a CIT ticker already exist? I assume this is something which was already present in 1.59 and before, can someone confirm?

Good news The good news is we have made very promising progress with multiplayer interpolation, which looks like it could have a huge impact on solving jerkiness and jumping of remote units in multiplayer. The progress was so good we are now inclined to include this in the 1.60 version, as it looks we will be able to finish this a lot faster than we expected a week ago. Bad news The bad news is this is likely to delay the 1.60 patch a few weeks - you are already seeing this on the state of the beta patch. While the interpolation is not enabled in it still, it contains some preparation steps which are not well tested yet, and are causing crashes, funny footsteps, visual jerkiness issue. Please, consider the patches 84391 and newer "highly experimental" again until the situations stabilizes a bit, which we hope should be within a week. We apologize to those who already expected the 1.60 to be released "anytime" now, we think the improvement we are likely to make within the weeks to come will make the update worth waiting for.

Could we verify status of issues which are either not 1.60 specific or are already resolved and should be verified and closed, so that we get a clear overview of 1.60 blockers here?

Yes, all MP fixes requiring 1.60 version should be enabled now.

I found following: http://www.dotnetonweb.com/74345: When futher searching I find it strange, though, as 0x5ad error is defined as ERROR_WORKING_SET_QUOTA: The page linked above is most likely some advertising scam. :( My first idea would be to check if you have some space free on the drive, esp. if your page file is OS managed.

http://www.arma2.com/beta-patch.php Also fixed http://dev-heaven.net/issues/26256 properly. With a little luck this could be the last beta before the Release Candidate of the 1.60 patch. Please, check and verify all reported regressions, esp. in recent fixes, to see if there is anything which would block RC.

Even this is unlikely to be fixed for 1.60. The waiting for stable patch has been already way too long and we really want to get it out of the door.

Sorry, not for 1.60. There is multitude of improvements still possible, and some of them are likely to be implement in future patches, but no more are considered for 1.60.

Seems it already exists. http://dev-heaven.net/issues/16673 Now, Armstrong, vote, vote, vote ! . :) - And do not forget to create a repro mission. ;)

The are both fixed in the executable.

As a developer, this is even my point of view. I gave up trying to understand inner workings of memory allocators, because it is too much complex area for me. I prefer "evidence based" approach - the allocator is almost a black box for me, and the one giving best results in empirical testing is the one I will prefer. The allocator crashing often is one I will not use. If you want to understand the differences, be prepared to face some difficult science. Related: I also no longer have an ambition to create my own allocator from the scratch. This might have sense in OFP/Arma times, but those days are gone.

This is what an allocator does from a user perspective: Some allocators can give you higher fps in some situations. Some allocators may cause crashes in some situations. Some allocators may cause the game to use more memory from the system in some situations. Your mileage may vary.

Such interface does not exist in TBB, this is the part which was modified by us. Remember the TBB3 sources are modified, if you want to check their original state, you need to download directly from the TBB site (link also provided in the Community Wiki). As for scalable_footprint, internal_footprint and MappedMemory, those are also our additions.

One possibility is you have mipmap sampling set to Low quality in your video card settings, making the text rendering blurry.

Note: the allocators are now available with full source code in the Community Wiki, each with a corresponding license. Beware: The allocators other than TBB 4 were not updated for quite some time and would perhaps benefit in bringing upto a more recent version. If anyone wants to do this, I recommend to first compare each version provided by us against the version it is based upon to see what customizations and fixes were made in it by us, as it is possible they will need to be recreated in the recent version as well.

This will not work, because the winhoard.dll does not conform to the interface needed for a custom allocator as specified in the Wiki, and therefore it will not be used. It should be possible to create a custom allocator based on Hoard, but it involves a bit more work.