suma

This discussion is perhaps interesting, but it is not much constructive, as it does not help in fixing the issue. What would help me would be to extract a minimal (or at least less complex) repro from the mission. I guess someone could be able to do that?

I am sorry, this is something I cannot answer yet.

We have used several memory allocators written by experts, including TCMalloc, NedMalloc and jemalloc. Most of them broke down under the ArmA 2 load, causing memory corruption or crashes.

:D :j: :D

Because it was there in OFP, and the game still played OK. :j: (The code is there from 28.1.2000) Nevermind, fixed as of 85420 :bounce3:

What should I do to see this issue myself?

Also AI using hangun over long distances should be fixed (http://dev-heaven.net/issues/12143)

Yes, post it, please. It may show some useful data.

Can you try if the problem shows without mods as well? Mods modifying AI could easily cause this. No need to make a video, it is not that I do not believe you that you have the problem, I need the problem on my computer to debug it, and I cannot debug a video or a screenshot.

Did not see this yet. Once two of my men briefly looked through binos, but soon they took weapons and fought as expected. Perhaps there is something missing? Some mods used? What are your difficulty settings? If the problem exists, I would like to check it and fix it, but for it I need to see it first, so that I can debug it and understand what is causing it.

MinErrorToSendNear is used differently from MinErrorToSend. When computing the error for MinErrorToSend, the error is divided by (distance_in_m/20m)^2. Because of this, when MinErrorToSend is small enough so that distant units move smooth, the near units move "supersmooth" (the updates are sent even when the movement is so smooth it makes no gameplay difference). MinErrorToSendNear gives a way to give another absolute (not distance dependent) limit ("never send update smaller than 1 cm, even if MinErrorToSend would allow it to be sent").

There is no more any crash, therefore nothing to attach and analyze: I will try the repro again and will ask for more information as needed.

The video seems to no longer work, yet I think I have fixed identical issue in A2:OA 84874. The issue was caused by rounding of line size to whole pixels being performed in rendering, but not in the selection.

The author of the fix is currently not available, and the exact purpose of the fix is not clear to me, but the source code shows it is fixing something wrong which happened when turret stabilization was off for a while and then turned on again (which happened when crew turned in). What exactly the "wrong" was I have no idea.

While I feel your pain, I have little idea what could I do to help you. If the issue can be only seen on your computer and not anywhere else, there is no way for me to debug or analyze it other than directly on your system, which is quite hard to organize. Unless there will be more people seeing the issue, I am afraid there is nothing I will do.

I am sorry, we are unable to dedicate any serious QA to A2/OA at this stage. We hope the community can help us with this. We will not release the 1.60 until the community agrees it is mature enough (i.e. especially it is free of any serious regressions compared to 1.59). The tickets http://dev-heaven.net/issues/24558 and http://dev-heaven.net/issues/24559 are a good start and I will definitely check them. The overview in http://forums.bistudio.com/showthread.php?t=124911 is also very valuable at this point. If you have any other issues, be sure to report them on CIT, or at least report them here with enough specific details so that somebody else can turn them into proper reports.

You are shooting just as you would without an interpolation. The "echos" are completely internal and invisible to you. You as a player do not have to care about them, both in SP and MP. ---------- Post added at 15:19 ---------- Previous post was at 15:16 ---------- The "living in the future" aspect is better understand with a different wording: "it may be known to be in a new position in the future" (it is known it is not there yet). WYSIWYH - What you see is what you hit. :)

Instead - or besides :rolleyes: - of thanking it would be good to test if it is really fixed this time. I have already reported it as fixed several times before.

- this beta should have finally fixed setPos/setDir issues - the interpolation should be improved (you should see less sliding)

It is "or something". It is only position/orientation/speed part of the incoming packets which now gets different handling. Actually there are very little netcode component changes (this can be evidenced by the fact most improvements are client side only). Anything not directly related to position should not be affected at all.

Beware: the patch was broken. If anyone who downloaded it before the Buliwyf's post please download again.

Based on a testing it seems to me 1.59 stable behaviour is the same in this situation.

You say: The ticket says: I think it was always (or for very long) behaving this way, and I think there is some subtle reason for it, but I do not remember what it was (I could try to dig it up if necessary). ---------- Post added at 09:15 ---------- Previous post was at 09:13 ---------- Would you be able to specify the affected range of versions a bit (which build is known to work fine, which is known to be broken)?

I am sorry, but I am unable to debug examples or implement fixes based on them (the same goes for videos and screenshots). Unless you or anyone else can provide a repro for this, nothing will be done.

http://www.cznp.com/6to8weeks/index.php :) Enter: 3 5000000 2