View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003116 | Spring engine | General | public | 2012-06-14 14:46 | 2012-07-14 18:57 |
| Reporter | Google_Frog | Assigned To | Kloot | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 88.0 | ||||
| Fixed in Version | 89.0.1+git | ||||
| Summary | 0003116: Hitvolume config causes invulnerability | ||||
| Description | Certain hitvolume, unit centre and aimsphere configurations can cause a unit to be invulnerable (or take reduced damage) against weapons with low AoE. This can occur with non-contrived examples. The first example is here from this ticket http://springrts.com/mantis/view.php?id=3103. It turns out that the tilted unit tilts the hitsphere such that BeamLasers do reduced damage. My second example is in ZL v1.0.6.6. As far as I can tell the unit 'armanni' is invulnerable to all impactOnly weapons. It is also invulnerable to corstorm weapons which have some AoE. I suspect this is a widespread problem with a few more unknown units taking reduced damage from certain angles/weapon types. | ||||
| Tags | No tags attached. | ||||
| Checked infolog.txt for Errors | |||||
|
|
In the armanni case modelCenterOffset is also used. |
|
|
_obviously_ it is possible to create such configurations, eg. a large ship might have a long thin cylindrical volume such that bow or stern weapon impacts would not cause any damage (because damage is based on distance from explosion impact to model center, and if that exceeds an explosion's AOE a unit takes none). now what do you expect to be done about this that doesn't completely change the balance of _every_ game&mod out there? |
|
|
shouldn't explosion damage not be calculated by the smallest distance to the hitbox? (without having any knowledge about this topic...) if i understood this right, i wouldn't care about balance... invulnerable units are imo the worst thing that can happen to the "balance"... |
|
|
it should, but the smallest distance is not that easy to calculate (when the volume is not a sphere or box) so approximations would have to be used which would again introduce weirdness like invulnerable units. ie. completely solving this is not possible, unless the collision system were changed to only support spheres and boxes (something I am half-seriously considering). |
|
|
discuss/decide next week in meeting? (or here, maybe other devs have ideas/hints/opinions) |
|
|
"_obviously_ it is possible to create such configurations" -> "This can occur with non-contrived examples." "only support spheres and boxes" If this fixed all the current hitvolume/aimsphere weirdness I would support this. The weirdness includes this bug and a removal of the aimsphere in favour of aim tests based on hitvolume. |
|
|
that is not going to happen because the aim tests take weapon spread (accuracy + sprayangle) into account, they don't intersect hit-volumes with a line but with a cone which is infeasible for anything but spheres. |
|
|
Ok, fix aoe-damage calculation by restricting volumes to rectangle and sphere then let me define the position and radius of the aimsphere. I know manual definition of aimsphere could potentially break things but if it is used properly there are many cases where I could improve units behaviour. |
|
|
You can already define the position via UnitDef.modelCenterOffset (and Upspring for 3DO/S3O), or the midpos metadata key if using OBJs/assimp models. Runtime manipulation of radius will be possible in 89.0 if it ever gets released. |
|
|
That position is also the position for many other things. Nanospray moves towards it, commands are drawn to it and opponents aim at that point to attack the unit. For example I have an amphibious unit with a turret mounted on top. The model center is set to the turret location so that it cannot kill things with impunity from just below the surface of the water. This messes up aiming, allied units with arcing trajectory cannot shoot over it when they should be able to. |
|
|
done for 89+ |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-06-14 14:46 | Google_Frog | New Issue | |
| 2012-06-14 14:48 | Google_Frog | Note Added: 0008777 | |
| 2012-06-18 12:50 | Kloot | Note Added: 0008796 | |
| 2012-06-18 15:45 | abma | Note Added: 0008798 | |
| 2012-06-18 15:46 | abma | Note Edited: 0008798 | |
| 2012-06-18 16:43 | Kloot | Note Edited: 0008796 | |
| 2012-06-18 21:45 | abma | Note Edited: 0008798 | |
| 2012-06-18 22:26 | Kloot | Note Added: 0008799 | |
| 2012-06-18 22:27 | Kloot | Note Edited: 0008799 | |
| 2012-06-19 00:44 | abma | Note Added: 0008800 | |
| 2012-06-19 00:44 | abma | Note Edited: 0008800 | |
| 2012-06-19 00:45 | abma | Note Edited: 0008800 | |
| 2012-06-19 11:13 | Google_Frog | Note Added: 0008802 | |
| 2012-06-19 18:22 | Kloot | Note Added: 0008804 | |
| 2012-06-19 18:27 | Kloot | Note Edited: 0008804 | |
| 2012-06-20 06:41 | Google_Frog | Note Added: 0008805 | |
| 2012-06-20 15:19 | Kloot | Note Added: 0008806 | |
| 2012-06-20 15:37 | Google_Frog | Note Added: 0008807 | |
| 2012-07-14 18:57 | Kloot | Relationship added | related to 0003103 |
| 2012-07-14 18:57 | Kloot | Note Added: 0008983 | |
| 2012-07-14 18:57 | Kloot | Status | new => resolved |
| 2012-07-14 18:57 | Kloot | Fixed in Version | => 89.0.1+git |
| 2012-07-14 18:57 | Kloot | Resolution | open => fixed |
| 2012-07-14 18:57 | Kloot | Assigned To | => Kloot |
