ToME WikiKhymChanur: Currently, if project() is used for something that doesn't affect a single monster/grid, like a beam or ball effect, a list of the coordinates to effect is first collected, and after the collection is completed they are processed. This requires the projection flag PROJECT_WALL for some damage types. For example, if a monster breathes disintigration, we want all the walls within the breath radius to be destroyed, and without the PROJECT_WALL flag the walls closest to blast center will shield the walls more distant from the blast center, since during the collecting-coordinates phase of project() none of the walls are destroyed. This is fine for a damage type like disintigration, but if you wanted to, for example, do an area affect spell with "wall destruction" damage type, and have it act like a disintigration blast by using PROJECT_WALL, the wall destruction will pass through trees without affecting them.
A way to solve this would be get rid of the collecting-coordinates phase of project(), and apply the damage type of the grid/monster/player/objects as soon as we figure out that a coordinate should be effected. Then things like a disintigration blast won't need PROJECT_WALL, since each step of the damage-expansion will remove the walls that would have been in the way in the next step of the damage-expansion, and "wall destruction" area affects would eat through stone walls like disintigration but be stopped by trees.
Is there anything in the T-Engine that would make this a bad idea?
DarkGod: I can not think of anything now, but the code should be carefully read to understand, if there is a reason, why it works the way it does now. Otherwise I'm all for it