Flamer not showing hit at point blank
Flamer not showing hit at point blank
Love the flamer changes. Just noticed a display bug though: a target at point blank will not be highlighted to indicate it will be affected, although it will in fact be affected correctly if it's in the cone.
Re: Flamer not showing hit at point blank
Sorry, this is v1.1 on PC with no additional mods.
Don't have save game but I've seen it whenever that situation has arisen.
Don't have save game but I've seen it whenever that situation has arisen.
Re: Flamer not showing hit at point blank
For reference, here's a great visualization posted in a different thread showing highlighting before 1.1 and after 1.1
http://www.pavonisinteractive.com/phpBB ... 15&t=24095
I noticed this too and wondered if this was by design. I read in the original flamethrower changes thread that it was changed to avoid the solider setting herself on fire.
http://www.pavonisinteractive.com/phpBB ... 15&t=24095
I noticed this too and wondered if this was by design. I read in the original flamethrower changes thread that it was changed to avoid the solider setting herself on fire.
-
mattprice516
- Long War 2 Crew
- Posts: 265
- Joined: Tue Jan 10, 2017 12:49 am
Re: Flamer not showing hit at point blank
So the flamer rework was changed such that it should show tiles and enemies affected correctly and also independently (IIRC).
The flamer aims in a 3d cone directed roughly level (horizontal). Since the cone emanates from your soldier, it won't actually hit the floor right in front of them because it's still too high up - it will hit an enemy standing there though because they're in the cone. If that makes sense?
EDIT: Ah I see. So just to clarify - you are indeed seeing enemies themselves not be highlighted (instead of just their tile) even if they're standing in the cone, but they do then get flamed?
The flamer aims in a 3d cone directed roughly level (horizontal). Since the cone emanates from your soldier, it won't actually hit the floor right in front of them because it's still too high up - it will hit an enemy standing there though because they're in the cone. If that makes sense?
EDIT: Ah I see. So just to clarify - you are indeed seeing enemies themselves not be highlighted (instead of just their tile) even if they're standing in the cone, but they do then get flamed?
-
Amineri
Re: Flamer not showing hit at point blank
Summary : Cones (and all AoEs) are 3D and hit 3D tiles by containing the CENTER of the tile, not by including any PART of the tile.
Units occupy multiple 3D tiles, and can be affected even if the ground tile they are in is not affected.
-----------------------------------------------------------
Details:
So the still slightly weird thing about cone (and really all AoE attacks), relates to the tile system that XCOM 2 uses.
Tiles in XCOM 2 are actually 3D tiles, with (x, y, z) integer coordinates. In terms of unreal units, each tile is 96x96x64, which translates into 1.5 meters x 1.5 meters x 1 meter. Humanoid-shaped units (e.g. soldiers, ADVENT soldiers, probably sectoids and so on) generally end up "occupying" 2 tiles stacked vertically, since they are more than 1 meter high. There are functions that translate a tile's integer (x,y,z) value into the tile's centerpoint in the unreal coordinate system. The reverse (taking unreal coordinates to tile) involves rounding, finding the closest such tile.
When a cone attack is made, the cone (which is a 3D cone) is projected out into space, and only the tiles whose center points fall within the cone are be affected. In base XCOM 2, the start point for the flamer is at the feet of the unit firing. With the 1.1 changes, I moved it up +1 vertical tile. In part this was a cosmetic change... With the aim point at floor height, the flamethrower animation was always pointing slightly at the ground, which looked odd. The other reason for shifting it up was to make it easier for the flamer to go around (especially adjacent) low cover. Trying to shoot at ground level through low cover just made the calculations a lot tougher.
This is where it starts to get a bit weird... There are two different systems that handle tile occupation.
The first is in the world manager, which has a big (sparse) list of tiles, and each tile can indicate what unit or non-unit object is occupying it -- it's implemented in native code, so is actually using a hashtable under the hood for performance. This isn't a one-to-one mapping. Two (or more) tiles can indicate they are occupied by the same unit.
The second system is what is stored in each unit gamestate. Each unit only stores a single tile which is the tile that it is considered to "be in". This position is at the feet of the unit, so will generally be the ground tile (things get a big more complicated for multi-tile units like sectopods, but I'll ignore that for now).
There are a couple of reasons this is all important.
For starters, when the cone is projected out into space, and the affected tiles are collected, some of them can be up in the air. To figure out which units are affected I use the first world system to figure out if any units are in any of the affected tiles, and this can include tiles that aren't on the ground. Non-ground tiles have no visualization, but the units within them can still be affected. Such affected units should still be highlighted, but the tile they are standing on will not be highlighted. This means that the affected unit would take damage, and possibly be set on fire (directly), but that the tile they are standing in would not be affected.
The second effect can crop up when using cones with very small angles. If you imagine the tiles as a grid of discrete points, it's possible to aim a narrow cone in between the adjacent tile center points, with the result that NO tile adjacent to the unit will be affected. To give some examples, a 30º cone would be centered on adjacent tile centers at 0º and 45º azimuth angle (assuming no elevation here). At the in-between point of 22.5º azimuth, it would extend from 7.5º to 37.5º and so would not cover the center point of either adjacent tile. In fact any aiming angle (with 30º cone) from 15º to 30º would miss adjacent tiles. The narrower the cone, the bigger this area is.
If I were writing this from scratch, I'd be tempted to implement a more robust system. However, all of the other AoE calculations in XCOM use this, and use fast systems written in native code. I had to redesign the flamethrower targeting code once anyhow because the first implementation was causing FPS to drop into single digits in some cases, so rewriting the basic tile-gathering for the cone (in the much slower Unrealscript) isn't really a practical option.
----------------------
As a side tangent, this same tile system was the one of the big problems with smoke grenades. The smoke grenade would affect the upper tile a unit was occupying (and so would mark the unit as affected), but it wouldn't affect the ground tile the unit was standing in. The smoke grenade effect however had additional code that was checking that the unit's tile (the one at the ground) had the world smoke effect, which it wouldn't. So the unit would be marked as affected, but then wouldn't get the benefit of smoke effect.
Units occupy multiple 3D tiles, and can be affected even if the ground tile they are in is not affected.
-----------------------------------------------------------
Details:
So the still slightly weird thing about cone (and really all AoE attacks), relates to the tile system that XCOM 2 uses.
Tiles in XCOM 2 are actually 3D tiles, with (x, y, z) integer coordinates. In terms of unreal units, each tile is 96x96x64, which translates into 1.5 meters x 1.5 meters x 1 meter. Humanoid-shaped units (e.g. soldiers, ADVENT soldiers, probably sectoids and so on) generally end up "occupying" 2 tiles stacked vertically, since they are more than 1 meter high. There are functions that translate a tile's integer (x,y,z) value into the tile's centerpoint in the unreal coordinate system. The reverse (taking unreal coordinates to tile) involves rounding, finding the closest such tile.
When a cone attack is made, the cone (which is a 3D cone) is projected out into space, and only the tiles whose center points fall within the cone are be affected. In base XCOM 2, the start point for the flamer is at the feet of the unit firing. With the 1.1 changes, I moved it up +1 vertical tile. In part this was a cosmetic change... With the aim point at floor height, the flamethrower animation was always pointing slightly at the ground, which looked odd. The other reason for shifting it up was to make it easier for the flamer to go around (especially adjacent) low cover. Trying to shoot at ground level through low cover just made the calculations a lot tougher.
This is where it starts to get a bit weird... There are two different systems that handle tile occupation.
The first is in the world manager, which has a big (sparse) list of tiles, and each tile can indicate what unit or non-unit object is occupying it -- it's implemented in native code, so is actually using a hashtable under the hood for performance. This isn't a one-to-one mapping. Two (or more) tiles can indicate they are occupied by the same unit.
The second system is what is stored in each unit gamestate. Each unit only stores a single tile which is the tile that it is considered to "be in". This position is at the feet of the unit, so will generally be the ground tile (things get a big more complicated for multi-tile units like sectopods, but I'll ignore that for now).
There are a couple of reasons this is all important.
For starters, when the cone is projected out into space, and the affected tiles are collected, some of them can be up in the air. To figure out which units are affected I use the first world system to figure out if any units are in any of the affected tiles, and this can include tiles that aren't on the ground. Non-ground tiles have no visualization, but the units within them can still be affected. Such affected units should still be highlighted, but the tile they are standing on will not be highlighted. This means that the affected unit would take damage, and possibly be set on fire (directly), but that the tile they are standing in would not be affected.
The second effect can crop up when using cones with very small angles. If you imagine the tiles as a grid of discrete points, it's possible to aim a narrow cone in between the adjacent tile center points, with the result that NO tile adjacent to the unit will be affected. To give some examples, a 30º cone would be centered on adjacent tile centers at 0º and 45º azimuth angle (assuming no elevation here). At the in-between point of 22.5º azimuth, it would extend from 7.5º to 37.5º and so would not cover the center point of either adjacent tile. In fact any aiming angle (with 30º cone) from 15º to 30º would miss adjacent tiles. The narrower the cone, the bigger this area is.
If I were writing this from scratch, I'd be tempted to implement a more robust system. However, all of the other AoE calculations in XCOM use this, and use fast systems written in native code. I had to redesign the flamethrower targeting code once anyhow because the first implementation was causing FPS to drop into single digits in some cases, so rewriting the basic tile-gathering for the cone (in the much slower Unrealscript) isn't really a practical option.
----------------------
As a side tangent, this same tile system was the one of the big problems with smoke grenades. The smoke grenade would affect the upper tile a unit was occupying (and so would mark the unit as affected), but it wouldn't affect the ground tile the unit was standing in. The smoke grenade effect however had additional code that was checking that the unit's tile (the one at the ground) had the world smoke effect, which it wouldn't. So the unit would be marked as affected, but then wouldn't get the benefit of smoke effect.
-
Amineri
Re: Flamer not showing hit at point blank
Just to clarify, this picture shows a case where adjacent enemy will be hit, but the tile the trooper is standing in will *NOT* be affected.
That is, the trooper will take damage, and can be set on fire, but the tile the trooper is standing on cannot be set on fire. This is basically working as designed.
That is, the trooper will take damage, and can be set on fire, but the tile the trooper is standing on cannot be set on fire. This is basically working as designed.