ToME: the Tales of Maj'Eyal

EDIT: Significant updated patch below. Many fixes to FoV and LoS.

$10 says the attached patch will make some people mad

But, well, the fov code is not working correctly, and it really ought to be fixed. Doing so, however, will generally decrease what a character can see. Check out the image below as an example.

A super-quick summary of what got changed. First, understand that fov is basically defined by two angles: start_slope and end_slope (and start_slope < end_slope). There were situations in which a blocked corner would decrease start_slope, thus allowing you to see more than you should. This is wrong and has been fixed. Similarly, there were situations in which end_slope would become larger and increase your fov, which is wrong and has been fixed. The final fix is to check if adjacent terrain blocks fov and adjust end_slope as necessary (start_slope already had this check). Enjoy! Mwahahaha!

Can you do a before and after screenshot?

I've often wondered why I can see much more than I can target. Is this related? Though with bean trickery it becomes possilble.

For "Before", check out Zop's post here:
http://forums.te4.org/viewtopic.php?f=4 ... 0&start=15
which links to this image
http://img801.imageshack.us/i/twinc.png/

i think its still wrong - previously you could see target but not always make a line to the spot now its opposite( you cant see target but you can target spot )

IMHO - if you can target spot you should be able to see it(in terms of FOV) and opposite if you can see spot you should be able to target it.

Graziel wrote: i think its still wrong - previously you could see target but not always make a line to the spot now its opposite( you cant see target but you can target spot )

This should be confirmed by somebody who knows how this works in the code, but I think line target spotting does check if the target is in fov. Hence, if we change fov, then we change line targeting, and your above point is moot.

By the way, fov still uses the geometry documented in the code. I'll illustrate why you shouldn't be able to look past the following ("X" means you can't see the tile, and note targets "A" and "B" by the blocks):slope to A (lower-right of first block): 0.5/1.5 = 1/3 = 0.3333
slobe to B (upper-left of second block): 1.5/3.5 = 3/7 = 0.4286

Hence, the character can't see target 'B' because it is blocked by the first block.

tiger_eye wrote:This should be confirmed by somebody who knows how this works in the code, but I think line target spotting does check if the target is in fov. Hence, if we change fov, then we change line targeting, and your above point is moot.

The line instance (created with line.new) is strictly geometric and has no knowledge of LOS, etc. Both the targeting and project(ion) code use the line instance and then iterate through it, checking the block_path function found in engine.Target.lua. The result is that only the tiles actually traversed by the line are checked, and the adjacent tiles have no bearing on it so you can shoot around corners if you get the angle right. It is possible to link targeting/projection to FOV checking by adding the "requires_knowledge" flag to the target specification, which is done automatically for targeting (see engine.Target:setActive). This is not exactly what you want because it requires you to be able to see the target within your limited light range, whereas you probably want an infinite light range and use the talent's range to determine distance.

I'm glad you know the code, yufra .

It should be pretty easy to add a few rules to line targeting to make it equivalent to fov (regardless of light distance and whether you can see the target). I can do this next week if nobody beats me to it. Gotta go!

Hopefully the attached patch ties up most the loose ends for the current FoV and LoS algorithms. Below is a list of changes:

(1) Blocked terrain no longer increases FoV (the issue reported in initial post)
(2) Correctly calculate slopes from angles via tangent function. Previously used 'tan(x) ~ x' approximation for x in range 0 to pi/4 radians (0 to 45 degrees)
(3) 'FOV_SHAPE_CIRCLE_PRECALCULATE' option now calculates height correctly
(4) Safely handle floating point precision issues in FoV
(5) Separated the "block" function and "apply" function for a couple 'fov.calc_{beam,circle}' calls
(6) Restrict LoS targeting to FoV. LoS still uses bresenham line drawing (i.e., 'line.new') to make a path from the center of the source tile to the center of the target tile
(7) Modified projectile code to handle the above changes
(8) Updated "Channel Staff" "block_path" function
(9) And a few other minor fixes

Please note that I probably haven't tested and verified all types of projectiles in all relevant situations, so if you wish to review my changes or keep an eye out for bugs, I would suggest starting with that. For example, the LoS logic in the following functions were very similar but structured slightly differently:
Target.lua:display()
ActorProject.lua:project()
ActorProject.lua:canProject()
Projectile.lua:act()

Oooooh, pretty angles
The following images use the same Lake of Nur example as done above. The green highlights represent the precise field of vision.

Here is the FoV for a point source (0% of tile width): Here is the FoV for an actor 50% the width of the tile:(Note: if the actor were any larger, it would begin to see past the obstructions to the right).

And here is the FoV for an actor 100% the width of the tile: Ummm... uhhhhhh... you do not want to know how I made these images!

Lol, we probably do want to know (a new FOV patch?!)... but the guy at 100% have to have an eye on each corner of the square, and they are able to look crosseyed.

Personally I think the first one is best (most realistic)... Though targetting a dude in the L shape (two blocks down 1 to the side) in most board rpg terms would give you cover (half-cover at least).