ID:160225
 
Does anyone know how I could get step_to to work even past twice the world.view? Thanks!
proc/far_step_to(source, target)
step_to(source, get_step( source, get_dir( source, target))

(edit)
Actually, that's not all needed.
proc/far_step_to(source, target)
step(source, get_dir(source, target))

That should do.
In response to Loduwijk
It closes the window if I run that. Also, I think I need it to be step_to, as I need the monsters to be able to navigate their way towards their target, taking dense objects on the map in to account.
In response to Speedro
BYOND's movement procs won't automatically find undense paths to things. There are a couple "pathfinding" libraries/demos, search for some.
In response to Kaiochao
Kaiochao wrote:
BYOND's movement procs won't automatically find undense paths to things. [...]

That are some that do; they're just not as comprehensive (and therefore good) when doing it, so they're not perfect.
In response to Speedro
Speedro wrote:
It closes the window if I run that.

Then something is screwed up.

Also, I think I need it to be step_to, as I need the monsters to be able to navigate their way towards their target, taking dense objects on the map in to account.

Then you need to make (or find/use) a path-finding algorithm.
In response to Kaioken
Okay, does anybody know how I would go about creating me own step_to that would go beyond twice the world.view?
In response to Speedro
Loduwijk wrote:
Then you need to make (or find/use) a path-finding algorithm.

Kaiochao wrote:
There are a couple "pathfinding" libraries/demos, search for some.

A popular specific one for path-finding you can look up is a* (a-star). And remember, algorithms aren't specific to Byond, so you can use Google to look up a bunch of generic programming articles for explanations/examples of specific algorithms like this.
(edit)
Oh, and like Kaiochao also said, there might be some libraries for Byond that already do this.
In response to Loduwijk
I found exactly what I was looking for http://www.byond.com/developer/Theodis/Pathfinder, but after reading it several times over, I have no idea how to use it.

My failure of an attempt:
step(src,AStar(src.loc,src.target.loc))
In response to Speedro
Yes, Theodis.Pathfinder is an excellent library which will do exactly what you need. Unfortunately, Theodis didn't write a newbie friendly help file, and even I have problems using it sometimes. Let's take a look at how he calls (uses) the AStar proc in his demo. This line is from demo.dm, line 38:
var/path[] = AStar(loc,dest,/turf/proc/AdjacentTurfs,/turf/proc/Distance)


Right there we can see several important things. One, the AStar proc returns a list (the variable 'path' is defined with square braces [] so we know it's going to hold a list as its value). So, right off the bat, we know that you will have to change the way you're using it. Instead of trying to step directly to the result of AStar(), we're going to have to use it like a list. [The AStar() proc returns a path to the target, in the form of a list; the first item in that list is the first step to take.]

The next thing we can see is that the AStar proc needs four pieces of information in order to run (four 'arguments'). From the file Pathfinder.dm, here are Theodis' own words on how to use the proc, and what those four arguments are:
start - The starting location of the path
end - The destination location of the path
adjacent - The function which returns all adjacent nodes from the source node.
dist - The function which returns either the distance(along with any added
weights for taking the path) between two adjacent nodes or if the nodes aren't
adjacent the guessed distance between the two.

So start is going to be where the path starts (loc, in the demo example; notice that this will need to be a turf in your game, not the mob that's moving!). End is going to be the place where the path ends, so this will need to be the turf that your target is standing on, not the target itself.

Here's where it starts to get hard. Adjacent and dist are paths to procs, not just another object. So, you'll have to write up two new procs. One to determine the distance between two objects (dist) and another to return a list of all turfs adjacent to a given turf. Thankfully, Theodis has already written those procs in the demo file, but you'll need to read through the demo to see how it's being used.

Pathfinding is a complex subject, and not one that can be handed in DM without a little bit of work, a little bit of programming expertise, and a lot of reading.
In response to Speedro
If you look through that library, it returns you the path generated from AStar() as a list of turfs. To do anything with them, you'd loop through that list which is returned:
for(var/turf/T in AStar(..args needed...))


It is not too much of a complex matter, which involves using either step_towards() or Move(), sleep() and as such in the loop to move along the path, but IIRC there were also other libraries that might have been complete with a proc to walk through the path, so that may be more convenient for you.
In response to Speedro
One more thing to consider is that the path can become invalid later even if it was valid when it was created. This can happen when dense objects move or are created in the path.

If this can happen in your game, instead of taking the path-list generated and looping through every single turf in it, stepping to one after another, you can take minor new obstacles into account that would otherwise invalidate the path by again using Byond's movement functions that take dense blockage into account as you tried to do before, but were impeded from because of the distance limit.
var
path[] = pathFindingAlgorithm()
oldIndex = 0
turf/T
/****
* this for-loop loops from 1 to the length of the path
* and sets T to the current iteration's index in the path list
* however, its increment is abnormal, incrementing by
* world.view/2 unless that would put it over path.len, then
* it increments to path.len
* this makes the target turf (T) "jump" several tiles at a time
***/

for(var/index = 1, index <= path.len, index = (index+world.view > path.len ? path.len : index+(world.view/2)))
T = path[index]
/***
* Since the target we're stepping to jumps forward several
* tiles at a time, we need to take this into account
* with a nested loop. This tries to make you walk to
* T before letting the for-loop jump it forward again
* Loops until oldIndex gets up to index+3 instead of just
* index, to give src some leeway in case they had to go
* around some new obstacles that moved into the way.
* Don't need to keep trying if it succeeded in getting to T, so abort in that case
***/

while(oldIndex < index+3 && loc != T)
step_to(src, T)
// oldIndex needs to = index every iteration of the outer loop
oldIndex = index

(edit)
After making that, I thought of an even better way to do it.
var
list/path = pathFinder()

for(var/index = world.view/2, index <= path.len, index += 1)
step_to(src, path[index])
while(get_dist(src, path[index]) > world.view)
index -= 1

That one will just increment by 1 every step as normal, but if you fall behind too far from taking new obstacles into account, it will decrement index back into view.
In response to Loduwijk
I wish it was as easy as changing how far the step_to could see, because I still have no idea what I'm doing.

My old code which I REALLY wish I could just use some kind of argument to choose how far step_to could see:

mob
var
mob/target
delaytime=3 //minimum
proc
ai()
for()
sleep(src.delaytime)
var/templist[]=new
for(var/mob/m in world)
sleep()
if(m&&m.playing)
templist+=m
var/playersfound
for(var/a in templist)
playersfound=1
if(!playersfound) //no targets found.
return
src.target=pick(templist)
var/mob/n=src.target
while(src.target.playing)
sleep(src.delaytime)
if(get_dist(src.target,src)<2)
step_towards(src,src.target)
else
for(var/mob/a in view(2))
if(a.playing)
src.target=a
step_to(src,src.target)
src.target=n






My pathetic copy paste code because I have no idea what I'm doing:

    proc
ai()
for()
sleep(src.delaytime)
var/templist[]=new
for(var/mob/m in world)
sleep()
if(m&&m.playing)
templist+=m
var/playersfound
for(var/a in templist)
playersfound=1
if(!playersfound) //no targets found.
return
src.target=pick(templist)
var/mob/n=src.target
while(src.target.playing)
sleep(src.delaytime)
if(get_dist(src.target,src)<2)
step_towards(src,src.target)
else
for(var/mob/a in view(2))
if(a.playing)
src.target=a
var
list/path = AStar(src.loc,src.target.loc,/turf/proc/AdjacentTurfs,/turf/proc/Distance)
for(var/index = world.view/2, index <= path.len, index += 1)
step_to(src, path[index])
while(get_dist(src, path[index]) > world.view)
index -= 1
src.target=n
In response to Speedro
You could switch to using the hub://Deadron.Pathfinding library instead - it has a simple step()-like proc which you just need to call to get it done.
In response to Kaioken
Thanks!


Edit: Eh, it doesn't seem like a single step thing to me. My enemies jump directly to the target.
In response to Speedro
In the description of how it works, it says it's a single step. So assuming this I just treated it like an average step function, but I guess it isn't, because the enemies just teleport directly to you.


Why can't anything be easy?

Another desperate attempt at getting it to work how it's supposed to:

step_towards(src,get_step(src,base_StepTowards(src.target, minimum_distance = 0, pathSizeLimit = 50)))
In response to Speedro
Speedro wrote:
Why can't anything be easy?

Because it's computer programming! :)

Something that is very simple to think about, such as "take a step along a path from A to B," can be extremely complex to describe to the computer how you want it to happen. That's why we have software engineers. Remember, although Byond makes game-making as simple as possible, you are still treading on the threshold of what people with computer science degrees do for a living. Some of what you want to implement is going to fall farther into that field than many people who just want a simple game might like.

This just goes to show how much we should appreciate our human brains, and even animal intelligence, as it does all this and much, much more in the background processes of your mind, and you don't even have to pay attention to it.
In response to Loduwijk
Of course, our minds don't always show us the shortest path, even if we know all the routes. <_<
In response to Popisfizzy
True.


So, er. Does anybody know how I can just get a magical step_to verb that works past world.viewx2? It's all I really need :s
In response to Speedro
You could increase world.view and just use the value of client.view to dictate what the client's view is.
Page: 1 2