Has there been any progress on this feature? I know Gnome had a solution, but it needs cleaning up.
I'm creating a mod at the moment and It's something I'd like to incorporate. Plus, it'd take the OTA and SWTA mods from about 50% balanced to 95% balanced.
Friendly Fire
Moderator: Moderators
-
Guessmyname
- Posts: 3301
- Joined: 28 Apr 2005, 21:07
I had it working on a per-unit basis; it would probably be better suited as per-weapon. I got snagged on C++ syntax and gave up, though :\
Here's what I managed to accomplish... it's from the 70b1 codebase, but you should be able to search for "friendlyfire" in each of the files to figure out what I did. I think it'd need added to every weapon class file as well (I was only testing on lasers).
http://wormhole.tauniverse.com/spring/friendlyfire.zp
Here's what I managed to accomplish... it's from the 70b1 codebase, but you should be able to search for "friendlyfire" in each of the files to figure out what I did. I think it'd need added to every weapon class file as well (I was only testing on lasers).
http://wormhole.tauniverse.com/spring/friendlyfire.zp
-
Warlord Zsinj
- Imperial Winter Developer
- Posts: 3742
- Joined: 24 Aug 2004, 08:59
I'd just like to bump this and let the devs know that SWS quite desperately needs this pack.
We've been doing some beta testing lately, and our balance really suffers from the fact that units can't shoot through each other - in particular, the use of multiple infantry units in a group is pointless unless you line them up 18th style; using infantry to support vehicles stops the vehicles from firing.
It generally turns the game into one where the defending player will always beat an attacking player unless he is completely outnumbered, because the defender will line up his defences to take advantage of LOF, while the attacking player, even if he uses the line formation to the utmost advantage, will be worse off.
We are trying to make SWS an offensive-focused game, but we need to do this and still keep infantry as a staple force, and we need to do it without making a few super-powerful units. For this reason, we really need to be able to set friendly units to fire through each other in certain circumstances (see gnome's patch above).
We've been doing some beta testing lately, and our balance really suffers from the fact that units can't shoot through each other - in particular, the use of multiple infantry units in a group is pointless unless you line them up 18th style; using infantry to support vehicles stops the vehicles from firing.
It generally turns the game into one where the defending player will always beat an attacking player unless he is completely outnumbered, because the defender will line up his defences to take advantage of LOF, while the attacking player, even if he uses the line formation to the utmost advantage, will be worse off.
We are trying to make SWS an offensive-focused game, but we need to do this and still keep infantry as a staple force, and we need to do it without making a few super-powerful units. For this reason, we really need to be able to set friendly units to fire through each other in certain circumstances (see gnome's patch above).
-
Guessmyname
- Posts: 3301
- Joined: 28 Apr 2005, 21:07
-
Warlord Zsinj
- Imperial Winter Developer
- Posts: 3742
- Joined: 24 Aug 2004, 08:59
I think it is more the horribly inaccurate collision detection system. I doubt spring will ever have collision detection advanced enough for it to be a rival solution for achieving the offensive-based combat we are seeking in SWS.
And for the record, AA fanboys, this is requested as a per-mod option only.
And for the record, AA fanboys, this is requested as a per-mod option only.
@Warlord:
For infantry, just drop the hitsphere below the level of the guns. Shots are always aimed at the origin of the hitsphere, so the only real disadvantage is that it will occasionally look like your Rebel Scum are shooting at the Imperials' feet, but that's correctable with a minor Accuracy adjustment to prevent it from being glaringly obvious.
@KDR:
As for drone FF... hmm... I'll have to download your mod and take a look at the models and the missile profiles. I really don't have any serious FF problems with NanoBlobs at this time- I did for awhile, with the Archers, because their Accuracy was low enough that shots would occasionally cone down into the unit in front of them, but that was an acceptable problem, given that you could always just build and deploy more of 'em, so I figured in some attrition when balancing the units.
For infantry, just drop the hitsphere below the level of the guns. Shots are always aimed at the origin of the hitsphere, so the only real disadvantage is that it will occasionally look like your Rebel Scum are shooting at the Imperials' feet, but that's correctable with a minor Accuracy adjustment to prevent it from being glaringly obvious.
@KDR:
As for drone FF... hmm... I'll have to download your mod and take a look at the models and the missile profiles. I really don't have any serious FF problems with NanoBlobs at this time- I did for awhile, with the Archers, because their Accuracy was low enough that shots would occasionally cone down into the unit in front of them, but that was an acceptable problem, given that you could always just build and deploy more of 'em, so I figured in some attrition when balancing the units.
I think it's simply units moving into each other's line of fire although today I had a tank pump round after round into the ground before it, almost destroying itself with the splash damage.
The laser drones don't hit each other much and they all fire even in a tight bunch, implementing rifle shots as laser projectiles might help.
The laser drones don't hit each other much and they all fire even in a tight bunch, implementing rifle shots as laser projectiles might help.
Argh: I just tried it. It works great when you have "sphere-hacked" units vs non-sphere-hacked units. However, pit two groups of sphere-hacked units against each other, and it's no different than it is now other than units firing at feet. Since they're firing at a lower target now, they have to aim at a lower angle, which... gets blocked by the spheres once more, rendering the solution moot and going back to front-lines-only. It was quite impressive to see an offensive group of 200 sphere-hacked stormtroopers wipe out 250 droids on the defensive with only 28 losses... that just goes to prove how horribly porcy this engine really is, IMO.
KDR: Lasers don't make a difference
KDR: Lasers don't make a difference
Well, IRL, infantry do not fight in tight clumps, precisely because FF is a real-life problem (and of course, it reduces the effectiveness of area-fire weapons and artillery).
That's one of the single big problems that is very violently highlighted by Spring's more realistic design: in making weapons fire actually conform to something like reality, it's highlighting how incredibly un-realistic most RTS game designs are... and how much developers have bought into previous assumptions.
The above philosophical bit aside... there are a few solutions that would actually work.
1. Make every "laser" weapon use a visual effect that looks like a laser bolt, but have them actually be arcing guided weapons. Have the laser bolt fire from a weapon on the model using the animations, etc., etc., just as it always does... and have the ballistic projectile fire from somewhere over the heads of the units. Use the ballistic weapon to force-fire the laser, and have the laser weapon do zero damage. You'd still see laser bolts firing back and forth, but the actual damage would be done by physically-accurate weapons that wouldn't have any problems hitting the target.
The obvious problem with this is that while it'd get rid of the "porc advantage" (which, as I will explain below, isn't an advantage) and it'd probably look pretty good, it would occasionally lead to situation that aren't physically accurate. Much like in Dawn of War, where weapons were really just projected cones or rays that went straight through any intervening objects (the only true collisions were were with special ballistic weapons, and the underlying collision meshes used in DoW maps are pretty low-res)... you'd occasionally see some things that didn't make much sense. However, this might be a fairly good solution overall in terms of preserving the OTA mod's feel.
2. Take advantage of the fact that advantage is with attacking units in Spring... if you want it that way. How, you say?
Well, you have that funny little thing that was put into Spring... the AccuracyWhileMoving tag. Instead of using it in the obviously-intended way (i.e., making stationary units more accurate)... do the opposite. Even a very gentle nudge on this, with fast-moving beamweapons with low AOE... would have profound gameplay effects at a stat level. I know- I've played with this myself... and it works just fine
You also have quite a bit of leeway in terms of unit speeds vs. unit size. Units in RTS games routinely move more quickly than IRL people actually do, especially in natural, broken terrain.
Lastly... up the scale of combat a bit, by lowering the size of units and upping the ranges of weapons while slowing their projectile speeds down (the tricks I did with the latest NanoBlobs beta, if you haven't already see it)... and the small dips, bumps and other ground features become much more important. Then the moving attacker gains a big advantage over the defender, just like IRL (think high-speed tank warfare for the closest analogy- IRL infantry combat does not work like that because IRL, you cannot aim a rifle accuratly while moving).
3. Or, finally... be realistic, and live with the consequences. Do a Star Wars game that isn't cheesy. IRL, static infantry with a clear field of fire generally murder attacking infantry. The closest IRL war to the Star Wars world, at least on the ground... is WWI. Maybe there's a good reason the Imperials invented the AT-AT... because otherwise, they simply lost too many Stormtroopers
That's one of the single big problems that is very violently highlighted by Spring's more realistic design: in making weapons fire actually conform to something like reality, it's highlighting how incredibly un-realistic most RTS game designs are... and how much developers have bought into previous assumptions.
The above philosophical bit aside... there are a few solutions that would actually work.
1. Make every "laser" weapon use a visual effect that looks like a laser bolt, but have them actually be arcing guided weapons. Have the laser bolt fire from a weapon on the model using the animations, etc., etc., just as it always does... and have the ballistic projectile fire from somewhere over the heads of the units. Use the ballistic weapon to force-fire the laser, and have the laser weapon do zero damage. You'd still see laser bolts firing back and forth, but the actual damage would be done by physically-accurate weapons that wouldn't have any problems hitting the target.
The obvious problem with this is that while it'd get rid of the "porc advantage" (which, as I will explain below, isn't an advantage) and it'd probably look pretty good, it would occasionally lead to situation that aren't physically accurate. Much like in Dawn of War, where weapons were really just projected cones or rays that went straight through any intervening objects (the only true collisions were were with special ballistic weapons, and the underlying collision meshes used in DoW maps are pretty low-res)... you'd occasionally see some things that didn't make much sense. However, this might be a fairly good solution overall in terms of preserving the OTA mod's feel.
2. Take advantage of the fact that advantage is with attacking units in Spring... if you want it that way. How, you say?
Well, you have that funny little thing that was put into Spring... the AccuracyWhileMoving tag. Instead of using it in the obviously-intended way (i.e., making stationary units more accurate)... do the opposite. Even a very gentle nudge on this, with fast-moving beamweapons with low AOE... would have profound gameplay effects at a stat level. I know- I've played with this myself... and it works just fine
You also have quite a bit of leeway in terms of unit speeds vs. unit size. Units in RTS games routinely move more quickly than IRL people actually do, especially in natural, broken terrain.
Lastly... up the scale of combat a bit, by lowering the size of units and upping the ranges of weapons while slowing their projectile speeds down (the tricks I did with the latest NanoBlobs beta, if you haven't already see it)... and the small dips, bumps and other ground features become much more important. Then the moving attacker gains a big advantage over the defender, just like IRL (think high-speed tank warfare for the closest analogy- IRL infantry combat does not work like that because IRL, you cannot aim a rifle accuratly while moving).
3. Or, finally... be realistic, and live with the consequences. Do a Star Wars game that isn't cheesy. IRL, static infantry with a clear field of fire generally murder attacking infantry. The closest IRL war to the Star Wars world, at least on the ground... is WWI. Maybe there's a good reason the Imperials invented the AT-AT... because otherwise, they simply lost too many Stormtroopers
Or... have someone add the 10 lines of code to the engine so we don't have to use hackjob scripts on units that count in the hundreds, make defenses worthless, or otherwise completely rebalance the mod just because we can't get those extra ten lines. We can have some water which no one can run at more than 10 fps, but we can't have an OTA style gameplay feature or THE FUCKING OPTION TO TURN OFF AUTOMATIC RADAR TARGETTING AFTER A YEAR OF EXISTENCE. Awesome.
And don't even give me this "realistic" bullshit. This is all I have to say to that.
[edit] Don't get me wrong, Argh. I appreciate the ideas. I'm just fairly frustrated with this community and the devs...
And don't even give me this "realistic" bullshit. This is all I have to say to that.
[edit] Don't get me wrong, Argh. I appreciate the ideas. I'm just fairly frustrated with this community and the devs...
Hey, np Gnome, was just trying to help. I understand your frustrations, but such is life with an Open Source project where things get implemented in an ad-hoc fashion sometimes.
The good news is that it appears we're getting a lot more eyes on the smaller things now, as the Linux and Windows programming communities get involved.
The good news is that it appears we're getting a lot more eyes on the smaller things now, as the Linux and Windows programming communities get involved.
-
Warlord Zsinj
- Imperial Winter Developer
- Posts: 3742
- Joined: 24 Aug 2004, 08:59
AF, if you read what Gnome posted earlier up, he HAS coded this, he just needs it double-checked and implemented.
Argh, I'd have to disagree with the fact that Spring is more 'accurate'. Yes, in real life units can't shoot through each other; but in real life units will be intelligent enough to behave in a multitude of ways that allow them to fire at their maximum potential despite this. Spring units not only are not intelligent enough to do those things, they also have to deal with inaccurate spheres which means they won't fire within almost two widths of the unit they are afraid of hitting.
And the results are quite visible. Theoretically, you may have a point, but on the ground the results show. In real life, I should be able to order 20 infantry from one place to another and be confident that if it comes to it, the vast majority of them will be able to fire in a pinch. This cannot be done in Spring currently. Therefore, seeing as we are simulating the environment, allowing units to fire through each other is a far easier option to simulate intelligent infantry, then trying to get infantry to think enough to use leapfrog maneuvers, and for some to lie/crouch to allow troops behind to fire, or for units to quite pick quite safe gaps, even if they lie within the sphere of an oblong unit.
I don't think any of the examples you provided would go anywhere near solving the advantage which defenders have at the moment. With autoradar firing combined with LOF issues, inevitable inaccuracies while moving and a number of other issues, it is simply impossible for a mobile force to kill a defensively immobile force - even if they are vastly superior in numbers.
Game devs have made these logical fallacies to cover up the fact that their game cannot simulate reality. Spring can simulate the reality that units won't fire on friendly units, but cannot simulate that reality to the point where units are nonetheless able to take steps to ensure reasonable firing. Thus, the solution is no better then the other games, because the outcome is worse then the original fallacy. It has taken one step forward, and two steps back.
SWS, and indeed, Spring as a whole is a far more defensively focused game as a result. In my opinion, this is a bad precedent; active, dynamic, flowing gameplay based on a moving line, and constant attack and counter attack results in far better gameplay then the endless entrenchments that result because the issues we're discussing.
Argh, I'd have to disagree with the fact that Spring is more 'accurate'. Yes, in real life units can't shoot through each other; but in real life units will be intelligent enough to behave in a multitude of ways that allow them to fire at their maximum potential despite this. Spring units not only are not intelligent enough to do those things, they also have to deal with inaccurate spheres which means they won't fire within almost two widths of the unit they are afraid of hitting.
And the results are quite visible. Theoretically, you may have a point, but on the ground the results show. In real life, I should be able to order 20 infantry from one place to another and be confident that if it comes to it, the vast majority of them will be able to fire in a pinch. This cannot be done in Spring currently. Therefore, seeing as we are simulating the environment, allowing units to fire through each other is a far easier option to simulate intelligent infantry, then trying to get infantry to think enough to use leapfrog maneuvers, and for some to lie/crouch to allow troops behind to fire, or for units to quite pick quite safe gaps, even if they lie within the sphere of an oblong unit.
I don't think any of the examples you provided would go anywhere near solving the advantage which defenders have at the moment. With autoradar firing combined with LOF issues, inevitable inaccuracies while moving and a number of other issues, it is simply impossible for a mobile force to kill a defensively immobile force - even if they are vastly superior in numbers.
Game devs have made these logical fallacies to cover up the fact that their game cannot simulate reality. Spring can simulate the reality that units won't fire on friendly units, but cannot simulate that reality to the point where units are nonetheless able to take steps to ensure reasonable firing. Thus, the solution is no better then the other games, because the outcome is worse then the original fallacy. It has taken one step forward, and two steps back.
SWS, and indeed, Spring as a whole is a far more defensively focused game as a result. In my opinion, this is a bad precedent; active, dynamic, flowing gameplay based on a moving line, and constant attack and counter attack results in far better gameplay then the endless entrenchments that result because the issues we're discussing.
-
Hunter0000
- Posts: 197
- Joined: 04 Nov 2004, 00:33
I mostly agree with your other points Warlord (and also support mod-side FF toggles and autoradar firing ect) but this IMO is a modside issue. For example Iv'e never seen EE games decided by players who sat and their trenches and built towers and defensive units. Never. EE is a supreame example... the more mobile, agressive and responsive player almost always wins. Now if you're talking about AA for example, I would agree it plays very defensivly, but the variation between AA and EE highlight that a major factor in this defensive play is modside balence and unit design.Warlord Zsinj wrote:Spring as a whole is a far more defensively focused game as a result. In my opinion, this is a bad precedent; active, dynamic, flowing gameplay based on a moving line, and constant attack and counter attack results in far better gameplay then the endless entrenchments that result because the issues we're discussing.
Not that FF and turn-off-able auto radar targetting wouldn't help achieve a more mobile, offensive based feel. I just think that such play does not DEPEND on that.
I've not played E&E, so forgive any immediate ignorance, but I imagine it's because the defensive turrets are much weaker than "normal" (work with me here, don't pick on that word). That's fine, no one has any objections to a mod being balanced that way. The objections start when other mods have to rebalance just because, as Zsinj put it, we had to take one step forward and two back.
It would be more reasonable for them to say no if this wasn't so trivial--if it took a significant rewrite of how units work, then we would understand and accept that. While that is partially the case, a simple and very effective stop-gap does the job well enough for now to suit most needs.
You're right, it's not something balance DEPENDS on; however, you shouldn't force people to completely rethink the way their balance is set up, when the original way would be entirely effective with just a few lines added to the engine.
It would be more reasonable for them to say no if this wasn't so trivial--if it took a significant rewrite of how units work, then we would understand and accept that. While that is partially the case, a simple and very effective stop-gap does the job well enough for now to suit most needs.
You're right, it's not something balance DEPENDS on; however, you shouldn't force people to completely rethink the way their balance is set up, when the original way would be entirely effective with just a few lines added to the engine.
