[B40] Chain Lightning Bug

[Feena2244]

I noticed this just tonight, Chain Lightning is dealing 0 damage to any target not within the player's sight range.

Not sure if it's intended to function that way or not, but I do know it used to hit and damage targets out of the player's sight range.

It still damages all targets that the player can see (with infravision, light, or other means of detection) however.

[edge2054]

I played around with this this afternoon and it looks like something in the targeting code isn't working right.

Even if I could see the actor but it was at the edge of a corner I couldn't deal damage to it. I suspect the project function is trying to draw a line from the player to the target regardless of the start.x and start.y. I tried tossing a requires_knowledge = false into the target table but that didn't help either. I also experimented with LOS (casting it in the dark, at targets at the edge of range, etc) but the behavior was only produced when a wall or something was blocking the path from the player to the NPC.

The particles are working though. And perhaps working to good. I saw the particles fire through a wall at one point.

[edge2054]

bump

I think this affects arcane vortex too and line of sight blocks from creeping darkness (at least on stuff like mana thrust beams).

[tiger_eye]

I looked into this, so let me share what I discovered before I forget

This began in b39, because the function "on_project" in "tome/class/Actor.lua" checks if the target actor is within sight of the source actor. It *really* shouldn't do this, since all that stuff is taken care of elsewhere.

The problem arises from this commit:

http://git.develz.org/?p=tome.git;a=com ... 7c4d0a5b83

Browsing through the commit, I also saw a new "canProject" function in "tome/class/Actor.lua" that I don't think should be there. I think it should just be deleted.

Removing the "hasLOS" check in "on_project" and the method "canProject" from "tome/class/Actor.lua" will probably affect a Cursed or Doomed talent or two (I'm not sure what), so these talents will need revised/fixed.

[tiger_eye]

Just sharing the changes I discusses above. It looks like AI improvements will need to be made to make Creeping Darkness behave reasonably, but the AI should probably be changed anyway:

Code: Select all

diff --git a/game/modules/tome/class/Actor.lua b/game/modules/tome/class/Actor.lua
index 12d782c..a44d929 100644
--- a/game/modules/tome/class/Actor.lua
+++ b/game/modules/tome/class/Actor.lua
@@ -4187,20 +4187,6 @@ function _M:on_set_temporary_effect(eff_id, e, p)
 	end
 end
 
--- @param t a type table describing the attack, passed to engine.Target:getType() for interpretation
--- @param x target coords
--- @param y target coords
--- @return can_project, stop_x, stop_y, radius_x, radius_y.
-function _M:canProject(t, x, y)
-	local can_project, stop_x, stop_y, radius_x, radius_y = engine.interface.ActorProject.canProject(self, t, x, y)
-
-	-- add line of sight to can project unless pass_block_sight or pass_terrain has been set
-	if not t.pass_terain and not t.pass_block_sight and can_project then
-		if not self:hasLOS(x, y) then can_project = false end
-	end
-	return can_project, stop_x, stop_y, radius_x, radius_y
-end
-
 --- Called when we are the target of a projection
 function _M:on_project_acquire(tx, ty, who, t, x, y, damtype, dam, particles, is_projectile, mods)
 	if is_projectile and self:attr("projectile_evasion") and rng.percent(self.projectile_evasion) then
@@ -4229,13 +4215,6 @@ function _M:on_project(tx, ty, who, t, x, y, damtype, dam, particles)
 		return true
 	end
 
-	-- LOS check (this is also caught by canProject)
-	if not t.pass_terain and not t.pass_block_sight and who.hasLOS then
-		if not who:hasLOS(tx, ty) then
-			return true
-		end
-	end
-
 	return false
 end
 

[darkgod]

fixed