ID:1863682
 
Redundant
Applies to:DM Language
Status: Redundant

This feature has already been implemented, or is already achievable with existing methods.
Basically, add a variant of view(), which ignores luminosity.
I think hearers() might do this already.
Oh, it might, nevermind then
Actually, hearers says in the DM reference that it's mobs only, not atoms, so it wouldn't do the trick fully
var
mob/__riddick = new/mob{density=0,invisibility=101}()
proc
shine_view(Dist=5,atom/movable/Center)
if(!Center) Center = usr //this is correct. Do not question me.
__riddick.loc = Center.loc
if(istype(Center))
__riddick.step_x = Center.step_x
__riddick.step_y = Center.Step_y
__riddick.see_in_dark = Dist
. = view(Dist,__riddick)
__riddick.loc = null
Well, yeah, that works, but it's still something that's just nice to have built in
Well, yeah, that works, but it's still something that's just nice to have built in



FFS.
Nadrew resolved issue (Redundant)
I don't really see why this is redudant, whilst hearers (which is just a version that's locked to mobs for some dumb reason) is a thing.
which is just a version that's locked to mobs for some dumb reason

hearers() was added because it's useful for speeding up AI target seeking behaviors. It's something that's done ALL THE TIME. It makes perfect sense why it was added.

As for why this bit's redundant, is that I managed to produce the feature in 12 lines of code, and there will be next to no speed improvement of transitioning it to C++. This is because the brunt of the CPU overhead of my approach is actually being done by a built-in function. The softcode itself barely does anything. Further, my implementation allows you to use it as though it were built in, minus the stupid names.

Now, I could understand additional parameters for view() that allow you to override see_in_dark, see_infrared, see_invisible, etc, thus affecting the return value, but adding a whole new filtering variant for something that view technically does already provided you use it properly?

Dunno, seems pretty redundant if you ask me.
I don't see why you can't just make something like hearers() not restricted to mobs, just use a for() loop to filter out mobs.
PJB3005 wrote:
just use a for() loop to filter out mobs.

PJB3005 wrote:
Well, yeah, that works, but it's still something that's just nice to have built in

I'll just let the two of you hash this out.
I don't see how those 2 quotes relate to eachother...
The function can be built yourself, you can even just use your own suggestion and do it that way. It's unneeded.
What I'm getting at is, why is there no proc like this, whilst hearers() is a thing, hearers is OBJECTIVELY less useful than this.
hearers is OBJECTIVELY less useful than this.

Considering almost every BYOND game that uses any kind of AI system uses hearers(), while this is the first time that someone has requested this feature... I'm not actually sure that's true.

What I will say is this: BYOND's built-in lighting approach should have been deprecated years ago. It's ugly and nobody outside of BYOND will willingly subject themselves to it for more than a few minutes without complaint. Making any kind of serious project using that lighting system is a waste of time.
for(var/mob/M in betterhearers(range))
Because there doesn't need to be a proc like this, it's trivial to do on your own and it being built-in wouldn't dramatically decrease overhead.
Such can be said for a lot of procs like max(), min(), and others.
Such can be said for a lot of procs like max(), min(), and others.

Name a single programming language that doesn't have those functions. You are just being silly now.
Page: 1 2