| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
|---|---|---|---|---|---|---|---|---|---|
| 0005860 | Spring engine | General | public | 2018-01-02 04:11 | 2018-01-13 01:50 | ||||
| Reporter | raaar | ||||||||
| Assigned To | Kloot | ||||||||
| Priority | high | Severity | major | Reproducibility | always | ||||
| Status | resolved | Resolution | fixed | ||||||
| Product Version | 104.0 +git | ||||||||
| Target Version | Fixed in Version | ||||||||
| Summary | 0005860: units fail to aim uphill at targets near cliff edges even when they have a clear line of fire | ||||||||
| Description | units fail to aim uphill at targets near cliff edges even when they have a clear line of fire, and are within firing range. | ||||||||
| Steps To Reproduce | map : The Hole v1, or any map with sharp cliffs - spawn units on the lower ground with long range lasers and cannons - spawn units on the edge of the cliffs that should be targetable by the previously spawned units - move the attackers along the ground to see if they're being able to aim and fire when they should be | ||||||||
| Additional Information | on the attached picture, the red range line shows doesn't cross into the hilltop when viewed from the bot's perspective, although it apparently does when viewed from a normal TA-like overhead view. Maybe that's related. setting targetborder=1 seems to not change the attackers behavior at all (does that tag actually work?) This also happens on previous versions (tested 101.0) | ||||||||
| Tags | No tags attached. | ||||||||
| Checked infolog.txt for Errors | |||||||||
| Attached Files |
| ||||||||
 Relationships |
|
 Relationships |
| Notes |
|
|
Kloot (developer) 2018-01-05 14:29 |
you are aware that range by default is *three*-dimensional and that flat range *circles* projected onto the map do not convey this, right? hint: calculate the *3D* distance between attacker and target with Spring.GetUnitPosition and compare this to the attacker's weapon range. use the Spring.GetUnitWeaponTest* and GetUnitWeaponHaveFreeLineOfFire callouts to verify your findings. |
|
Google_Frog (reporter) 2018-01-06 02:02 |
In my experience the flat range circles convey the three dimensional nature of range. However, I would not rely on them completely as they have low resolution and only show range relative to ground height and ignore obstructions. Here are two possibilities. - The rate at which weapons lose range with a height difference grows with the height difference. The range circle calculates of units tends to be above the ground. Therefore the target unit needs to be further from the edge of the circle with a larger height difference. - Weapons check their line of fire from the piece returned by AimFromWeapon to the aimpoint of their target. Tall units may look like they are peeking over a cliff while their aimpoint is in fact obscured. I don't understand what you are talking about regarding the red range line crossing into the hilltop (or not) depending on the camera. The red range line is drawn in worldspace so in a sense its position should not depend on the camera position. |
|
raaar (reporter) 2018-01-07 23:06 |
I thought the red range line was changing depending on the camera angle, but it seems it just shows through the terrain, so forget that. I use heightmod=0.5 on the weapons, so the 3d range coverage is an ellipsoid stretched vertically 2x. This is not a range issue as the unit can fire by moving farther from the cliff. The aimpoint on the target is the pink dot in the middle of the radar tower (as shown on the picture). I've made some tests and GetUnitWeaponHaveFreeLineOfFire returns false. Somehow spring thinks it's obstructed when it isn't (especially considering cannon weapons with parabolic trajectory) |
|
Google_Frog (reporter) 2018-01-08 06:25 |
Run the test after allowing the weapon to aim ignoring terrain. |
|
raaar (reporter) 2018-01-09 07:17 |
if I set avoidGround=0, the unit will happily fire and hit the target directly. |
|
Google_Frog (reporter) 2018-01-09 09:09 |
It sounds like the bug is that the weapon is incorrectly detecting that it is blocked by terrain. You should give detailed steps to reproduce it, ideally with a minimod. |
|
raaar (reporter) 2018-01-12 03:17 |
it should be reproduceable on any game on the map "the hole v1" (https://springfiles.com/spring/spring-maps/hole) I tested with metal factions v0.991, spawning repeatedly "sphere_radar_tower" near the cliff edge on the raised platforms near the corners, then any of these attack units ("sphere_rock", "gear_aggressor","sphere_charger","sphere_bit") and moved the attacker around near the cliff to see where it can fire or not. |
|
Kloot (developer) 2018-01-13 01:50 |
Fix 1dfb23b88a882820e4c1a1c6b5df69ce13b5d727 committed to develop branch: fix 0005860, repo: spring changeset id: 9402 |
| Notes |
| Issue History |
|||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2018-01-02 04:11 | raaar | New Issue | |
| 2018-01-02 04:11 | raaar | File Added: fire_uphill_red_line.png | |
| 2018-01-05 14:29 | Kloot | Note Added: 0018708 | |
| 2018-01-06 02:02 | Google_Frog | Note Added: 0018709 | |
| 2018-01-07 23:06 | raaar | Note Added: 0018710 | |
| 2018-01-08 06:25 | Google_Frog | Note Added: 0018716 | |
| 2018-01-09 07:17 | raaar | Note Added: 0018719 | |
| 2018-01-09 09:09 | Google_Frog | Note Added: 0018720 | |
| 2018-01-12 03:17 | raaar | Note Added: 0018722 | |
| 2018-01-12 17:19 | Kloot | Assigned To | => Kloot |
| 2018-01-12 17:19 | Kloot | Status | new => assigned |
| 2018-01-13 01:50 | Kloot | Changeset attached | => spring develop 1dfb23b8 |
| 2018-01-13 01:50 | Kloot | Note Added: 0018725 | |
| 2018-01-13 01:50 | Kloot | Status | assigned => resolved |
| 2018-01-13 01:50 | Kloot | Resolution | open => fixed |
| Issue History |