Ssnake

Are you sure it's not set in the Mission Editor as an option for these units? (Options ... Ammunition ... "Unlimited")

Yeah, that would be the solution. Create a copy of the Transfer Manager shortcut, and edit its properties to add the command line option --ignorelock This would be similar to what'd escribed in this video, except that it's abbout the Transfer Manager, not SB Pro:

I would expect the Luchs driver (and reverse driver) to have an image intensifier vision block facing forward (reverse), each. Now bug #12278.

Now registered under no. 12277.

Thank you!

Like I wrote above, follow the link. That post contains details.

Neither patch nor reinstall will help. The mutex file needs to be deleted. Please follow the link below for instructions without command line use:

Hm. It's not supposed to do this anymore, but it's hard to argue against empirical evidence. As I'm on the phone right now: please search this forum for "mutex", and you should find advice.

I've never seen on an actual Abrams. The image shows a version with 105mm gun, so M1, or M1IP. At the time they had the MERDC-pattern, usually, which is quite different from this one. This here looks like a late Wehrmacht pattern where they lathered some green paint on the yellow factory primer and called it a day. Maybe someone thought it'd be fun to see how it might look like.

Real life terrain tends to have more variation, especially when the sun is shining. Small water puddles will reflect the sky, moist earth appears cool from the water evaporation, and depending on the type some soils will warm up and cool down faster than others ("thermal inertia"). But, moving pictures say more than 10,000 words, so I can but recommend to search Youtube for examples like this:

Yeah, "rise" roads by a moderate negative value, e.g., -1.50m or so. You could pick a 1m-, 3m-, or 6m-stream for that. Careful at road crossings where in real life there might be a culvert. You'd either have to cut the stream and delete the section at the crossing, or create a bridge afterwards.

I'll roll with your priorities. That being said, if you send me the scenario in its current state, I can at least give it to a beta tester to try and reduce it to a minimal repeat case.

Maybe.... but it must be tried, or else we'll never know. And that would also be a potentially valuable hint.

It looks all pretty solid to me - whih means that there is an elevated chance that you found a bug. Given the complexity of the underlying scenario (if it is what I think it is), it may not be easy to find that bug. If you see a chance to create a copy of that scenario, containing fewer units and still replicate the problem, please do so. Ideally, such a copy would contain nothing that isn't required to replicate the problem (the infamous "minimal repeat case"), but I realize that shrinking such a scenario and testing it repeatedly if the bug still appears can also be a time-consuming process.

Can you make a screenshot of the two subconditions of that event?

Well, we are changing things, just not in pursuit of a particular game mechanic or with the purpose of shifting the balance in favor of a certain vehicle. New information comes to light, we revise numbers. After a thorough check. Both other game developers and us do commercial software development. But given the different nature of revenue streams, we can afford to maintain independence from the preference of a certain user group, or investors, and it turns out that for professional usage purposes, trying to remain neutral and realistic is the best overall strategy. Of course, we're still operating in an environment where a good part of some information is classified, so we have to offer our best guess. But then again we don't claim that you'll get The Truth from Steel Beasts, just something that is sufficiently plausible and fit for the purpose.

Yes. we don't want to flood the AAR with irrelevant details. A drone disabled because it collided with a tree or building is relevant - a tactical asset was lost due to navigation error. A drone that destructed itself because is collided with the tank it was supposed to hit - well, that's "duh" level of reporting; it's kinda obvious that it can't survive such a collision.

A destruction by collision shouldn't be an event in the AAR if immediately followed by its warhead detonation. If you see this more often in your AARs, it should be reported as a bug.

Hmmmmm.

Can't hurt.

Triggers can be owned by units. The first thing to check would be if the corresponding trigger was assigned to one particular unit that may have been under control of one of the clients, without realizing that access to that trigger was restricted to one player in the whole group.

Ah.

Ar first glance it looks like copy and paste for the second route. But maybe I just don't understand the nature of the problem that you described.

Some serious backlog there ...