CellSpread: Difference between revisions
Rewriting the reality portion according to EXE |
→Reality: Added updated illustration of CellSpread radius, tried to make explanation clearer (checked back with D beforehand) |
||
Line 22: | Line 22: | ||
==Reality== | ==Reality== | ||
[[Image:CellSpread_order.png|thumb|right]] | [[Image:CellSpread updated.png|thumb|right|Areas affected by particular {{tt|CellSpread}} values.]] | ||
[[Image:CellSpread_order.png|thumb|right|Order in which potential {{tt|CellSpread}}-affected cells are scanned.]] | |||
In reality, the game's parsing of {{tt|CellSpread}} is performed slightly differently: | In reality, the game's parsing of {{tt|CellSpread}} is performed slightly differently: | ||
* The game adds 0.99 to the CellSpread and drops the fractional part. | * The game adds 0.99 to the CellSpread and drops the fractional part (in other words, it gets rounded to the next-highest integer, e.g. CellSpread=3.25 is turned into 3.25 + 0.99 = 4.24 = 4). | ||
* It | * It then finds all cells associated with that value in the [[CellSpread#CellSpread_Internal_Affected_Cells_Table|CellSpread lookup table]]. | ||
* For each cell in that range: | * For each cell in that range: | ||
** The cell's contained Overlay is checked. | ** The cell's contained Overlay is checked. | ||
Line 37: | Line 38: | ||
** if it's a BuildingType with {{TTL|InvisibleInGame|yes}}, go to the next item. | ** if it's a BuildingType with {{TTL|InvisibleInGame|yes}}, go to the next item. | ||
** if it's an AircraftType that's in the air right now ("in the air" is defined as a moving V3 Rocket, moving Dred missile, or an object that's > 208 leptons above ground), its calculated distance from the det. point is halved. | ** if it's an AircraftType that's in the air right now ("in the air" is defined as a moving V3 Rocket, moving Dred missile, or an object that's > 208 leptons above ground), its calculated distance from the det. point is halved. | ||
** If the final distance is less or equal to exact CellSpread * 256 (leptons per cell | ** If the final distance is less or equal to exact CellSpread * 256, the object gets damaged. (256 is the number of leptons per cell, and this calculation uses the original, set CellSpread, not the rounded value.) | ||
* Special effects such as Rocker, IonCannonWarhead bridge demolition, etc. are applied. | * Special effects such as Rocker, IonCannonWarhead bridge demolition, etc. are applied. | ||
* If the impact cell contains an OverlayType with {{TTL|Explodes|yes}}, special effects happen. See [[Explodes#For_OverlayTypes|Explodes]]. | * If the impact cell contains an OverlayType with {{TTL|Explodes|yes}}, special effects happen. See [[Explodes#For_OverlayTypes|Explodes]]. | ||
The | The practical difference to the traditional view of {{tt|CellSpread}} is mostly the handling of "diagonal" damage. As visible in the image in the section above, the traditional model assumes the corner cells to belong to the next-higher cell spread, when, in reality, the map's cells are irrelevant in the distance calculation. That means that damage does indeed spread in a perfect sphere radius, making working with it a lot easier.<br> | ||
In addition, as visible in the visual representation, since the damage spreads in leptons from the point of impact, rather than in cells from the cell of impact, the cells in the outer-most ring of a given damage area are not affected completely when using integer values; e.g. a CellSpread of 1 does not actually damage the entirety of the first cell next to the target, but only half of it. In order to damage the entire next cell, one would have to choose a value of roughly 1.5.<br> | |||
Furthermore, since InfantryTypes can stand in various places inside a cell, if they are hit by CellSpread-warheads, the point from which the game calculates the distance to determine whether an object is affected by the CellSpread is not necessarily the center of the impacted cell, potentially changing the affected parts of the outer ring again. | |||
The distance itself is calculated in all three dimensions, meaning a flying unit ''can'' be affected by {{tt|CellSpread}} in the same way all other units can. Note that the flying units within the affected cells can be damaged at higher altitudes than one would expect, but that doesn't mean the flyers in the neighbouring cells are affected.{{clr}} | |||
== Bugs == | == Bugs == |
Revision as of 20:20, 25 November 2009
Flag: | CellSpread |
File(s): | rules(md).ini |
Values: | Floating point values: Any decimal number (clearer range should be added in Template:Values).
(in practice, CellSpreads over 11 generate Internal Errors) |
Default: | 0 |
Applicable to: | Warheads |
CellSpread defines the blast radius of a warhead. Without CellSpread, a warhead only affects the cell it impacts on. With CellSpread, the damage extends beyond the current cell (it spreads), to the distance set through CellSpread.
As the damage progresses outwards from the point of impact, Template:TTL determines how quickly the blast wave loses power, that is, how much of the initial damage a unit at a certain distance from the point of impact receives.
Traditional View
For a quick, simple understanding of CellSpread, simply view it as follows: The damage will extend beyond the impact cell for as many cells as CellSpread is set to. e.g. if you set CellSpread to 3, the warhead will damage the current cell, and 3 cells further into all directions. A circle around the impact cell with a radius of 3, for a diameter of 6.
The image to the right reflects which cells are affected by which CellSpread under this simple model of CellSpread.
Reality
In reality, the game's parsing of CellSpread is performed slightly differently:
- The game adds 0.99 to the CellSpread and drops the fractional part (in other words, it gets rounded to the next-highest integer, e.g. CellSpread=3.25 is turned into 3.25 + 0.99 = 4.24 = 4).
- It then finds all cells associated with that value in the CellSpread lookup table.
- For each cell in that range:
- The cell's contained Overlay is checked.
- If it has Template:TTL and either the overlay doesn't contain Template:TTL or the warhead also contains Template:TTL, the tiberium is reduced. The exact details of this process are still being worked out.
- If the cell's Overlay has Template:TTL:
- If the warhead has Template:TTL, it destroys the wall.
- Otherwise, if the warhead has Template:TTL or the warhead has Template:TTL and the overlay has Template:TTL, the wall is damaged.
- If the cell did contain Overlay but no longer does, all objects and AI teams targeting that overlay are instructed to lose the target.
- All objects in the cell, together with their 3D distance in leptons from the detonation point, are put into a list of potential damage recipients.
- The cell's contained Overlay is checked.
- For each object on that list:
- if it's a BuildingType with Template:TTL, go to the next item.
- if it's an AircraftType that's in the air right now ("in the air" is defined as a moving V3 Rocket, moving Dred missile, or an object that's > 208 leptons above ground), its calculated distance from the det. point is halved.
- If the final distance is less or equal to exact CellSpread * 256, the object gets damaged. (256 is the number of leptons per cell, and this calculation uses the original, set CellSpread, not the rounded value.)
- Special effects such as Rocker, IonCannonWarhead bridge demolition, etc. are applied.
- If the impact cell contains an OverlayType with Template:TTL, special effects happen. See Explodes.
The practical difference to the traditional view of CellSpread is mostly the handling of "diagonal" damage. As visible in the image in the section above, the traditional model assumes the corner cells to belong to the next-higher cell spread, when, in reality, the map's cells are irrelevant in the distance calculation. That means that damage does indeed spread in a perfect sphere radius, making working with it a lot easier.
In addition, as visible in the visual representation, since the damage spreads in leptons from the point of impact, rather than in cells from the cell of impact, the cells in the outer-most ring of a given damage area are not affected completely when using integer values; e.g. a CellSpread of 1 does not actually damage the entirety of the first cell next to the target, but only half of it. In order to damage the entire next cell, one would have to choose a value of roughly 1.5.
Furthermore, since InfantryTypes can stand in various places inside a cell, if they are hit by CellSpread-warheads, the point from which the game calculates the distance to determine whether an object is affected by the CellSpread is not necessarily the center of the impacted cell, potentially changing the affected parts of the outer ring again.
The distance itself is calculated in all three dimensions, meaning a flying unit can be affected by CellSpread in the same way all other units can. Note that the flying units within the affected cells can be damaged at higher altitudes than one would expect, but that doesn't mean the flyers in the neighbouring cells are affected.
Bugs
- Due to the fact that CellSpread works based on a lookup table, its number of possible values is severely restricted:
- CellSpread=11 is buggy, it does not extend outwards properly, and it affects one cell twice.
- Everything above CellSpread=11 leads to Internal Errors.
- CellSpread is not working on warheads of particles. A particle only ever damages the current cell it resides on.
See also
CellSpread Internal Affected Cells Table
Purely for reference, here's the table used for CellSpread.
|
|
|