Hey, I just worked with the demo and added walls. Doesn't matter if anything is behind a dense object, aparently it's still in the FOV which kind of makes sense but it's not visible.
In this case I don't really see much of a reason for the library. I dunno, maybe someone can think of a purpose but what I would have liked to do was not to display any mobs which aren't in FOV Sight.
 |
FOV |
A short supplemental library to include field of view! [More] |
To download this library for your Linux/Mac installation, enter this on your command line:
DreamDownload byond://Bravo1.FOV##version=6 Emulator users, in the BYOND pager go to File | Open Location and enter this URL:byond://Bravo1.FOV##version=6 |
Greetings everyone! Another small supplemental library from Bravo1! whoo!
NOTE: This library is meant to be used with the get_ procs library! This library adds the functionality of field of view to mobs, with some simple (yet lengthy) procs. Variables: atom fov=90 this is the default field of view, and all atoms have it in case you're not looking to use this just for mobs. Procs: atom inFOV(atom/a) - returns true if the given atom (a) is within the fov of src. nfov can be used in place of src's fov. FOVlist(dist,nfov) - returns a list of all atoms at the given distance (dist) in tileswithin the FOV of the atom calling it. nfov is a number that can be used in place of the FOV of the atom calling the proc. mob inFOV_mobs(mob/a) - returns true if the given mon (a) is within the fov of src. Much more accurate than inFOV() but only works for mobs. Once again, nfov can be used in place of src's fov. FOVlist_mobs(dist,nfov) - the same as FOV() however it has a few key differences. dist is done in pixels instead of tiles and is then converted so that a circular range (instead of BYONDs square range) can be used for distance. This also uses bound_dist to find the distance to the mobs, and get_angle_step to procure a more accurate angle between src and the mobs it's checking. This will return a list of only the mobs in the given FOV and can only be called by mobs as a result. Once again, nfov can be used instead of the src mob's regular fov. Once again! NOTE: this library requires my get_ procs library. go download it too. It's cool. Updates: 1/11/2013: Updated library to include a demo. 1/10/2013[2]: Updated how inFOV works to be much more efficient, as well as removed the need for inFOV_mobs by checking to see if both src and the target are both mobs, then switching to get_angle_step() if they are. 1/10/2013[1]: Added in inFOV() and inFOV_mobs by request. FOV() and FOV() mobs changed to FOVlist() and FOVlist_mobs() |
Zecronious: (Jan 13 2013, 12:20 pm)
Super Saiyan X: (Jan 13 2013, 12:12 pm)
Can you package the entire folder as-is, and like send/page it to me? I'll see what's up.
Bravo1: (Jan 13 2013, 12:06 pm)
I do but it isn't created.
Super Saiyan X: (Jan 13 2013, 12:01 pm)
Yeah...but, it should automatically get generated and added to the zip, if you have the actual get_procs library included (checked off in /lib)
|
Copyright © 2024 BYOND Software.
All rights reserved.
The best way to do this though, instead of checking the angles of ALL the turfs in your FOV, get the list of turfs from your.x,your.y to target.x,target.y, then exclude the turfs that don't appear in both lists, then check those turfs. Unless the FOV is >90 this saves some runs of get_angle.
OR you could just set opacity to 1 on the solid turfs, which would exclude the mobs automatically from the view() calculation that both FOVlist() procs do. If you're doing it for a single mob, call if(mob in view()) to exclude them from the inFOV() check being done.
You can definitely do it but there's many ways to get the job done, so I felt like it'd be up to the user to figure out how you wanted to do it.