ID:2239812
 
Applies to:DM Language
Status: Open

Issue hasn't been assigned a status value.
It would be helpful if get_step had 3rd parameter Steps/Distance (1 by default). Function then would return new position that is at distance of 'Steps' from Ref.
+1

[edit]
A current work around that I use is similar to this.
var/turf/T = get_step(src,dir)
while(--range)
T = get_step(T,dir)
var turf/tile = get_step(loc, dir)
var steps = 1
for(var/iterations = --steps; (iterations > 0) && (tile = get_step(tile, dir)); --iterations)


Nonetheless, supported.
In response to FKI
FKI wrote:
> var turf/tile = get_step(loc, dir)
> var steps = 1
> for(var/iterations = --steps; (iterations > 0) && (tile = get_step(tile, dir)); --iterations)
>


Nonetheless, supported.

Your code is super ugly, just look at this beauty:

get_step(loc, dir)
get_step(loc, dir, 5)

It's not about if it is possible or not, but how easly it can be done.

Of course you can write your own function that wraps get_step and have this functionality, but this logic of yours means we also don't need get_step function since people can make their own get_step function, the only thing they need is locate function.

PS. We also don't need BYOND, since we can make it in C++, right?
I do agree with the feature but an issue I can think of coming about is if you wanted it to take or ignore opacity, sure it makes it easier but you can build it to your likings using workarounds ya know?

[edit]
Why not a new proc such as

get_steps(src,direction,range)


Which returns a list of turfs in said "line"
In response to Kisioj
I'm not against this request. It seems easy enough. Asking for built-in features like this is really just asking for Lummox to write your code for you. There are some cases where it's the only option, and there are cases like these that should be fairly trivial for him to do, but it's not holding anyone back.

Here's my implementation. No loops required; just convert the dir into a vector (because we should've been using vectors to begin with), scale it by the number of steps, and add it to the center position.
proc
get_steps(atom/center, dir, steps = 1)
return locate(
center.x + steps * dir2x(dir),
center.y + steps * dir2y(dir),
center.z)

dir2x(dir)
var global/list/dir2x = list(0, 0, 0, 1, 1, 1, 1, -1, -1, -1, -1, 0, 0, 0, 0)
return dir2x[dir]

dir2y(dir)
var global/list/dir2y = list(1, -1, 0, 0, 1, -1, 0, 0, 1, -1, 0, 0, 1, -1, 0)
return dir2y[dir]

Package it up into a library (the last two are already in my Directions library) and you're good to go.
Write it once and you never have to write it again; that's the point of libraries.

Check out this beauty:
get_step(loc, dir)
get_steps(loc, dir, 5)

I think people get too hung up on implementation. Just because you can see the source code in DM, doesn't mean it's bad. If you saw BYOND's implementation in C++, you probably wouldn't want to use it. What matters is that the function exists and does what you want it to do with reasonable efficiency.

And here's a recursive form of get_steps()... but don't use it, since recursion is horribly inefficient:
proc
get_steps(center, dir, steps = 1)
return steps ? .(get_step(center, dir), steps - 1) : center

I think we get into this anti-library debate every time someone posts a trivial feature request like this. It's silly. Just use libraries and don't write code ever again.

PS. We also don't need BYOND, since we can make it in C++, right?
We use BYOND because we don't want to make it in C++. Same reason you should be using libraries.
Why even support for() or while() when goto exists.
In response to Kozuma3
for() and while() are well-known control structures that simplify code and carry their own semantics, making code more readable and understandable.

Making a function built into an engine, instead of including it in a library, does not improve readability; the proc is used the same way either way.
Built-in functions do not simplify code; they're bloat for projects that don't use them. A lot of the built-in stuff should be in libraries that can be excluded.

This is code in a project that includes a library:
get_steps(a, b, c)

You, who downloaded and included the library, didn't have to write the code that implements this function.

This would be the equivalent code in a project if the engine had it built-in:
get_steps(a, b, c)

You, who downloaded and are using the engine, didn't have to write the code that implements this function.
Yeah, get_steps may also be a good idea, but one of the reasons I requested 3rd parameter is to be able to easily iterate over locations in line (explosion, shock wave). Of course I can write my own function, but simple things (and often used) like that should have built-in functionality and be standardized. Actually letting Lummox write this kind of code for us is a great idea. It will make language better and more standardized and also easier to learn for newcomers.

Just look at Python language which adds little features which help people to write more readable code faster every release.
In response to Kisioj
Kisioj wrote:
Just look at Python language which adds little features which help people to write more readable code faster every release.

Can't teach an old dog new tricks is what comes to mind.
In response to Kisioj
The little features that get added to Python are part of packages/modules; many of which come with Python and are included automatically. Same with many other languages. Don't confuse the language with its standard libraries.
In response to Kaiochao
Kaiochao wrote:
The little features that get added to Python are part of packages/modules; many of which come with Python and are included automatically. Same with many other languages. Don't confuse the language with its standard libraries.

Does BYOND have set of standard libraries, that are installed with BYOND and documented in tutorial / reference?

I don't think so.

Look at the get_step function. It's in the language itself, but it would fit better in some library since you can make your own get_step using basic locate function, right?
It is part of the language and we have to accept it, but why don't we make it little more powerful?

As for get_steps I think having get_steps in standard library while get_step is part of language would cause a lot of confusion.
The problem with BYOND is that it doesn't have standard library but instead adds features to language itself. Of course there are a lot of good libraries but they are not in standard, so every time somebody joins project that uses custom library, they have to learn it. What BYOND needs is some kind of standard which will tell people how to write code and what functions to use. You don't want to learn custom libraries every time you join somebody's project. There should be standard library administrated and controlled by BYOND staff.
In response to Kisioj
If people are confused on how/why to use libraries, then we have bigger problems as a community.

Sometimes, you have to write code to do things.

Two wrongs don't make a right. Adding features to the engine that should be in libraries is wrong. Standard libraries would help. Why not request those instead (or support the existing requests)?

But BYOND's already too far gone, so maybe it doesn't matter.