Some thoughts about Friendly Fire implementation.

[Argh]

I've tested the new Friendly fire tags... it has a few flaws, which are going to be obvious when people have put them into their mods. NanoBlobs is pretty immune to these problems, due to low unit sizes and a lack of large buildings, but I think that other mods might have more serious visual issues, which would be distracting to players, to be honest.

Here are my thoughts about possible further improvements that might be nice. As usual, these are just my opinion.

1. I'd like a "drawlast" tag. This causes the weapon or particle object to be drawn after all other things have been drawn. This might be nice for things that are actually passing through friendly objects' geometry, but we want at least a crappy illusion that they're not. OTA did it this way, with bitmaps. Doing so in Spring would be ... kind've painful. You'd have to have queued drawing cycles, and I don't think that Spring currently has more than one queue for all of the S3Os/3DOs in the viewport.

2. The other way around this, also somewhat painful, would be a tag in a unit's file that stated "IsFriendlyObstacle". This would, in essence, override the new tag "CollideFriendly" and "AvoidFriendly", if the weapon's target-check goes through the object with such a state.

This would also be painful, because it would require a virtual-ray check before even deciding that the unit could shoot. However, it would allow for accurate checking for large objects, where it will be perfectly obvious that things are going right through the geometry, ruining the illusion for the end-user.

I wish I had a clever way around these issues, but I'm all out of smart ideas this week I've tested the new tags, though, and... well, it's kind've annoyingly obvious when friendly fire is going through large units, and it will be even worse when we have small units very obviously firing through static buildings. I can't say that it does much harm to NanoBlobs, but it will do a lot to undermine the visual continuity of more "realistic" mods, and will probably result in this feature seeing less use than it should.

[Gnomre]

I spoke to Yeha very briefly about this on IRC a while back, since this is the major concern with 1944 as well. The FF-infantry play much more realistically than those without, since you no longer have to form musket lines, but they can fire through buildings which can look pretty silly and is also somewhat unfair if you think about it. I believe they decided that it was worth the sacrifice for now, though.

I'm sure WD would be the same way, its weapons tend to be very long ranged as well, but on infantry there's really not much else choice. No FF tends to work well enough for things like tanks, which you would expect to have stricter guidelines for lines of fire, but for infantry.. well, I've presented that argument plenty of times. In short, an override for large units to disable friendly fire would indeed be a good call.

As for SWTA, the infantry don't tend to have the range to shoot clear through buildings, due to the way it's balanced, so it's not as much of a problem for us. Doesn't mean the tag shouldn't exist, of course.

From what I recall of the areas that had to be modified, I wouldn't *think* it'd be too difficult or much more resource consuming than the normal no-FF method. Presumably the if statement would just need changed from:

if(friendlyintheway && !friendlyfiretags) {
do the behavior units without the FF tags do;
}
else {
fire through friendly;
}

to

if((friendlyintheway && !friendlyfiretags) || bigunitoverride) {
do the behavior ...;
}
else {
fire through;
}

Of course, I didn't actually look at the code for that, so it might not even be set up that way, but that's all the logic you'd need I would think. Then again, I'm hardly a C++ expert, so I'm sure there's a better way which ultimately requires more work than a mere OR...

[Tobi]

A tag to prevent friendly fire on large units means that even for CollideFriendly=0 units virtual rays have to be calculated, so it would probably remove much of the speed advantages of the current AvoidFriendly tag

E: fixed tag name (I think )

[Das Bruce]

How are friendly fire tags working now because it sounds as if they're weapon based as opposed to unit based, right?

[Argh]

Tobi is correct. I told ya, I'm all out've smart ideas on this one. I think that from a raw speed and coding standpoint, it'd probably be easier and more efficient to implement a second draw call, and overdraw things with Overdraw=1 enabled, before finally drawing the frame.

This would be less visually accurate, but would preserve the speed advantages of the current code on the unit-ai side, and I suspect that a secondary drawing queue wouldn't be too terribly inefficient- it'd just have to do an inventory of everything on the screen, check it for the flag, then draw things with Overdraw=1 again, as opposed to using whatever automated order it uses now. Slightly less fast, because you'd be drawing the objects twice, but meh, you'd be eating on the GPU side, instead of the CPU side, which would be better imho, because that's where Spring is weaker.

But I dunno- there may be a some really clever way around this... I just can't think of one

[Tobi]

I think spring already keeps some drawing queues for translucent stuff (ghosted buildings & projectiles possibly, not 100% sure tho), so maybe that code can be reused or the projectiles could just be inserted into that queue.

One big problem would be the zbuffering though: if the projectiles are drawn last, it means every other in-game graphic is already on the screen, including the map, units and projectiles. These things are drawn with zbuffering enabled. Disabling the depth test wouldn't work because then, in FPS/Total War camera you could see DrawLast=1 projectiles through hills. Keeping it enabled wouldn't work either because then the projectiles would still not be drawn because they're inside/behind the unit.

(Note the minor but significant difference with drawing translucent stuff last: in that case the faces *are* in front but need to be drawn last so the stuff behind it isn't culled away. Here the faces are behind other faces...)

Also, a solution like this actually takes CPU, not GPU (because CPU has to maintain the queue before sending the data to the GPU, note that there's no need at all to draw the things twice). But it probably takes less CPU then the other solution.

[KDR_11k]

A popular solution is simply adding an offset to the object when checking the zbuffer.

[Tobi]

Yeah I was thinking about that but I couldn't recall the correct OpenGL functions... glTranslatef() with a z translation wouldn't really work because of perspective.. or quite possibly it would work if performed in the projection matrix after the actual perspective transformation. Or maybe even glPolygonOffset() or just modifying the depth buffer range on the fly could work. But meh, my OpenGL is a bit rusty

In any case, it's not an unsolvable problem.

[Das Bruce]

Wouldn't it be more logical to have FF depend on the unit rather than the weapon?

[Argh]

No, because then we're back to virtual rays and LOS checks, which adds a great deal of CPU time to each frame. It's just not efficient.

However, what they're proposing to do there... I would think that would be the most efficient way of doing this. The visual problems with this would be pretty minor, honestly- since this method would move with your POV, you'd only occasionally run into things that really looked "off", and for the most part, the illusion would be maintained.

The way that Yeha's current code is implemented... actually has major performance advantages. In my tests, giving units the ability to IgnoreFriendly really significantly impacts the user's CPU usage, when heavy battles start...

[KDR_11k]

Not necessarily, it may be desired for some weapons to hit friendlies.

[jcnossen]

Maybe add camera->dir * 10 or sth to the projectiles?
glPolygonOffset usually only works well for small offsets.

[krogothe]

how would that look in say FPS mode (or any low-flying camera pointing from the shooter)?

[Argh]

@Krogothe: it'd probably clip through the object, then. But this is still a good workaround, for everything else.

[Warlord Zsinj]

Is it possible to detect how long a projectile has been travelling through something? The problem here is that things are too big - no trouble with small units, because they pass through before you can notice. It's only once the weapon is hidden for quite clearly far too long that things happen.

Perhaps it is possible to impact the weapon if it has been hidden from view, or travelling 'inside' a hitbox for a certain period of time?