Opened 11 years ago
Last modified 5 years ago
#1731 new defect
Mismatch between query and target range
Reported by: | historic_bruno | Owned by: | |
---|---|---|---|
Priority: | Should Have | Milestone: | Backlog |
Component: | Simulation | Keywords: | |
Cc: | Patch: |
Description (last modified by )
While testing packing siege (#1718), I noticed an apparent mismatch between target range and queries from the range manager. This is really only noticeable for units in "standground" stance, as they have a range query equal to attack range. Test as follows:
- Create new map, place a ranged unit and set him in standground stance
- Place some enemy buildings outside his range
- Gradually move the enemy buildings closer until he responds by attacking them
- Now delete or move the building he is attacking, he will become idle and not detect the other building.
- Target the other building and confirm the unit can attack it without moving.
- This means the target is in attack range but was not detected by the range query.
Needs a close inspection of e.g. CCmpUnitMotion::IsInTargetRange
, CCmpRangeManager::PerformQuery
, and UnitAI.js
to determine what's going wrong.
Change History (12)
comment:1 by , 11 years ago
comment:2 by , 11 years ago
An other symptom: When a big building (f.e. a CC) and a ranged unit have the same range, the ranged unit can hit the building at a position where the building can't hit the unit.
This problem was brought up by Enrique on IRC (http://irclogs.wildfiregames.com/2013-07-07-QuakeNet-%230ad-dev.log on 16:49).
I'm thinking more and more that footprint information should be deleted from range calculation for ranged units.
comment:3 by , 11 years ago
I updated my patch for #1960. As that patch split the logic for ranged vs melee attacks, it was easy to add, and if I made a separate patch, it would conflict anyway.
I think it works quite good now. Although it could be needed to balance ballistas a bit better, as now they get in the range of fortresses and are taken out quite fast.
comment:6 by , 9 years ago
Tested with a tireme, works. It has bothered me for a long time, thanks for patching it!!
comment:7 by , 9 years ago
I have the following error message when a tower fires arrows:
ERROR: Error in timer on entity 7975, IID 52, function FireArrows: TypeError: this is undefined BuildingAI.prototype.FireArrows/addTarget@simulation/components/BuildingAI.js:317:4 BuildingAI.prototype.FireArrows@simulation/components/BuildingAI.js:327:3 Timer.prototype.OnUpdate@simulation/components/Timer.js:100:4
I guess it's caused by r16577.
comment:11 by , 5 years ago
Component: | UI & Simulation → Simulation |
---|
Move tickets to Simulation
as UI & Simulation
got some sub components.
comment:12 by , 5 years ago
Description: | modified (diff) |
---|
"Is this still valid?"
Yes. Either follow the steps in the report above or:
- give an archer a minumum range (~20 m)
- set it on standground
- move a horse on passive to within the range (notice it gets attacked until in the minimum range)
- move another soldier to within the maximum range and verify it won't get attacked.
I'm not sure it is the same problem though. Because my steps don't work with siege.
Another symptom is that units with BuildingAI (ships and siege towers) seem to have a different range for the UnitAI attack compared to the BuildingAI attack.
You can notice it, when you order a ship or a siege tower to attack, it moves via CCmpUnitMotion until the UnitAI can attack it, but the BuildingAI can't (you will see one arrow coming out of the ship, and when you move a bit closer, the BuildingAI will add many arrows).
My guess is that CCmpUnitMotion takes the footprint into account, so it moves until the footprint is in range. While the vision range and BuildingAI both use RangeManager, which only takes the center point into account.
The most correct solution would be to use the footprint for RangeManager, but that will also be the most difficult one. While excluding footprint checks for ranged attacks would also work, and wouldn't change a lot to the looks of the game.