suma

Was caused by http://dev-heaven.net/issues/18951#note-15 - the AI was now too relaxed in selecting their targets. Fixed in 83558

Fixed in 83522

This is most likely because skill matters now. You can try increasing their skill and check how they behave.

I am sorry, but my debugger does not support screenshot debugging. ;) If you (or anyone else) provide a repro, I may be able to fix it, but from screenshot only I cannot.

There are terrain shadows. They are a lot softer than object shadows, but they are there. If they should be visible, the sun needs to be lower than is the hill angle. If you set time e.g. to 6 AM, you should see shadows under steep hills.

Fixed in 83406

Tried it once more and seen the problem. It seems it is a bit random - sometimes it shows, sometimes not.

Strange. I have run the mission, switched to the map, and I can see our units blue, enemies appearing in read, our units fire at the enemy, enemy is soon killed and disappear, but no orange appeared to me even for a brief moment.

Download at http://www.arma2.com/beta-patch.php Contains fixes of issues introduced in 83313 (esp. missing head movement). Moreover, AI now should not engage empty static guns any more.

As this should be already fixed (see http://forums.bistudio.com/showpost.php?p=1996146&postcount=2) perhaps you might want to check the new version first? If you still see something you think should work in some other way, feel free to report it.

The only change is as mentioned in http://forums.bistudio.com/showpost.php?p=1995569&postcount=12 - prevent engaging empty enemy vehicles while they are boarded by friendly units.

Should be fixed in 83359

I confirm I can see the problem. There is one short moment in which the vehicle is still considered enemy (even if harmless) and already active (there is a driver), and in this moment BLUFOR units engage it. I will check what can be done to prevent it. I have attached a repro which is a bit simplified (less units, shorter distance to run).

This time is was not a bad fix, but an unhanded error condition in the automatic patch build process. Should be fixed shortly.

Download at http://www.arma2.com/beta-patch.php No new fixes, only fixes issues introduced in 83313 (esp. missing head movement).

AI currently prefers attacking the truck, as it thinks it is likely to contains soldiers in cargo space, therefore by destroying the truck they hope to kill those soldiers as well. Moreover, the truck is easier target for them at that distance. I agree in this particular case their decision might be wrong, but it would be hard to come with a general solution. Unless there is some case where the mistake is more obvious is shown, I would prefer not trying to fix this. Moreover, it seems at that distance they are actually unable to realize directly the soldiers are enemies. What you see is therefore like this: - BLUFOR fires at OPFOR truck, because it is recognizes as a target. - OPFOR soldier fire at BLUFOR, as they can see they are firing at OPFOR target, therefore they must be BLUFOR - BLUFOR recognize OPFOR and start engaging them, but they are already late When you delete both the truck and the MGs, both sides are just standing and nobody is firing.

Confirmed. It is result of fix http://dev-heaven.net/issues/22974, which has broken the head movement completely. A fixed version should be ready tomorrow. ---------- Post added at 20:30 ---------- Previous post was at 20:30 ---------- Great. I understand what is causing the issue, it is how condition in http://forums.bistudio.com/showthread.php?p=1994314#post1994314 was implemented. Fix should be easy. ---------- Post added at 21:13 ---------- Previous post was at 20:30 ---------- I think I have fixed it, but not having your repro, I am not sure if I have fixed exactly the problem you have seen, as what I have seen was a bit different (they got near the car, and instread of getting in have destroyed it). If you can attach your repro mission, I can verify my fix fixes your problem as well.

A change like this was implemented in 83273. It takes the distance of the units in group into account as well to certain extent. The careful and experienced part of me tells me I should not mess with thing like this at all as this stage, as I can easily break many things. The brave and adventurous part of me tell me it is only beta and if it does not work out well, we can always revert it. Please, test extensively - as a result of this change AI can engage empty vehicles which were not engaged before, provided there is some crew ready to board them.

It does not necessarily be equal. The event is triggered when a unit sees either a kill, or a dead body. It is triggered only once in each group, but it can be triggered multiple times if multiple groups see the dead body. On the other hand, it does not have to be triggered when nobody discovered the body. The primary reason why this "danger cause" exists is to provide some reaction when safe units encounter a dead body without seeing the shooting, which is typical in stealth scenarios.

Interesting idea. I am afraid such conditions are a bit too much complicated (target state needs to be knows very often), but perhaps something similar could do. One simple attempt: as long as there are any group members alive in group owning the vehicle, the vehicle in working state is considered to be dangerous, as the group members might still crew it.

If you see that, by all means, provide a repro and I will check what can be done against it. Or would you prefer the "engaging obviously empty" unfixed instead? Or what other options do you see?

From a business point of view, what you write is contradictory. If you still buy products from us, and are still decided to buy even more, you show us with your credit card then they are not "unacceptable" for you. "Bad", "shame", and other words could describe what you feel, but "unacceptable" does not seem to fit. I understand we could do many things better than we do. However, let me present the same choice in other words. Let me, for the sake of argument, assume that we are unable to fix more bugs and polish the product more than we currently do. Would you prefer the scope of the product to be reduced in all areas (landscape size, number of vehicles, number of weapons, number of missions) to 30-50 % of what it is now? We are not only a bussiness, we are still to certain extent (even if it is now less than say in 2001) a kind of "partisan" company, a bunch of guys playing with their toys. We sometimes do some work just for the heck of it. Yes, I could perhaps fix some bugs instead of implementing butterflies, but the downside of it could be I would pretty soon leave the job because of frustration. As for the leverage, I would say you have other leverage. You have leverage of voicing you oppinion, and you also have a leverage of the option to help us. I cannot repeat it often enough, for many bugs the most important thing to have them fixed is to have a high quality bug report with good repro steps in it (I intend to write a blog article about it soon, which should explain this in more detail). I agree with DMarkwick that having 977 open issues by itself does not mean much. Almost each shipped product has a huge list of open issues. As long as the issues are "annoyances", and not "showstoppers", such situation seems acceptable to me.

Thanks for reporting. Exactly the kind of issues I was afraid of. Fortunately this one was very easy to fix (83212). If there is nothing more serious waiting for us, it seems like a win, but still more testing will be needed to confirm this.

That is quite possible. Once I see some repro, I will be probably able to tell more quickly. Note: this intention of this event is to handle a situation when you can fire on a target which could not be fired on before. Yes, it is shared in a group. I can imagine it would be possible (and not very hard) to simulate reduced the accuracy when we can be sure some particular unit cannot see the target, but nothing like this is implemented now (and even as simple as it sounds, it would require to proceed very carefully with implementation, and it would require lots and lots of testing once implemented).

Is see a following reaction on canFire event, in the Stop to Fire state, which should make the soldier to stop for 4-8 seconds (or shorter when target is destroyed) on a fire opportunity (duration controlled by the Timeout and Destroyed condition): _stopUntil = time + 4 + random 4; if (vehicle _this==_this) then {_this forceSpeed 0;}