Applies to:DM Language
Status: Redundant

This feature has already been implemented, or is already achievable with existing methods.
It would be very nice to have version of view() that ignores darkness completely.

For example: You want tesla coil to shock everything in X range, but it also should ignore all atoms behind the walls. Using range() and checking if you have access to each atom is VERY unperformant while view() won't work for the dark places.
A native proc would be very nice, but there is a less slow way to implement it in softcode. SS13 calls view() with a dummy mob that can see in the dark.
Lummox JR resolved issue (Redundant)
to be clear, the softcode method is hot garbage, and doesn't really work consistently most of the time
In response to LemonInTheDark
What's wrong with the softcode method exactly? I don't see any reason it wouldn't work.
Being honest I don't remember exactly, I recall having some serious issues with it. I'm sorry I don't have more details, mean to check on it when I get the chance.

Most of why I don't like it is how inconsistent it feels, defaulting to caring about darkness, unless in total darkness in which case just go based off standard view.

I realize that's not really actionable, but it smells wrong.
I'm not aware of any cases in which it doesn't work, but it's definitely unintuitive, and the mob is another thing to add to the list of things that have to be excluded from all interactions with everything.
In response to Exxion
If the mob is only used on a temporary basis, moved into place for view() and then removed again, you don't need to worry about interactions because it's never going to be there during SendMaps().
In response to Lummox JR
I'm not sure what SendMaps() has to do with it? But you're right, if implemented as a proc, that problem is entirely avoidable. However, if I'm not mistaken, you miss out on the for(in view()) optimizations if it's implemented as a proc. If it's implemented as a macro, you get the optimizations, but have to deal with the mob sitting around for at least the duration of the loop. Neither case is unacceptable, but each is a strange compromise to have to make for this feature.
In response to Exxion
You don't miss out on any optimizations.