ID:1305137
 
(See the best response by Kaiochao.)
Code:
mob/verb
ThrowBomb()
set category = "Battle"
if(usr.AttackTarget in view(usr))
var/mob/M
M = usr.AttackTarget
var/turf/t = M.loc
var/turf/LastPlace = null
var/check = 0
while(usr.loc != t && check == 0)
LastPlace = locate(usr)
step_to(usr,t,0,32) //(D,t)Fallow
if(LastPlace == locate(usr))
check = 1
sleep(1)
world<<"Boom"


Problem description:
I've been helping a friend out with making new abilities and such in his game, and he wanted a 'throw' type skill, that would step to the location of the mob that you're targeting(for usr.AttackTarget, it's a reference to a mob, which is set via Click()), if you want to do that; or you could do it the old-fashion way, taking that out and putting in a input asking for the mob to attack) at the moment you use the move, not 'homing' in on them, but just going to where they were when the skill was used.

I've tried using a if(!step_to()) break statement, which(according to the reference), should work. Then I tried manually checking their last location and their current location(He wants to avoid checking via Move()). He also intended this to 'flash' to them each step, moving three step sizes each step, but when setting the step_size in step_to, it still defaults back to the 32 step_size of the usr. I explained to set it to something divisible by 32, which still did not work. Is there something with tile movement that messes this up, is it just something defined in his movement returning negative and still placing the mob there or is it just a bugged step_ system?


Update: He was playing around with it, and apparently putting in a sleep(2) will fix this, but not a sleep(1), would this mean step_to doesn't return right-away?
Best response
As far as I know, the step() procedures return a Boolean, depending on the return value of the Move() they call. Is there anything funky happening in Move()?
In response to Kaiochao
Just a movement delay, sleep(usr.movement_speed) in his code; after calling ..(). We've tested taking this out, and it doesn't help at all, just makes the steps occur almost instantly each time.

I just had him test Move() itself, and that doesn't appear to work or return a value, but the movement works fine when using directionals, without manually setting the location. No clue why it's acting this way.

It is entirely possible that he has something somewhere in his Move()-related procs that fails to return right-away, but nothing I can see via Skype's screen share.
In response to NNAAAAHH
Where before have you ever seen a sleep instruction inside Move()?
In response to Kaiochao
spawn() usually, and I had him change it. But I've seen a lot of games use sleep() to implement a walk delay.

I went through a few sources and removed a lot of sleep() delays because of the hold-up of the function.
You shouldn't be using sleep to implement a movement delay. Instead, you should be returning the proper value Move() would return if the move isn't allowed (or your own value if you wan't to differentiate, just stay in compliance with how Move works by default).

mob/Move()
if(world.time < move_time) return 0 //same as hitting a wall
//you could return -2 to represent "not time to move yet" for example
. = ..()
if(.)
move_time = world.time + some_delay //how much time to wait until we can move again

In response to FIREking
I understand that and stated I told him to replace sleep() with spawn()(just a quick way to get on with the testing purposes, which is the entire reason behind the project files he needs the help on, for his actual game), which doesn't seem to help the issue. Unless there's something in Enter() or Exit() that's causing his return to be a false-negative, which doesn't appear to be so, I don't know what is happening to cause this. As I just said, it's a purely test project he's playing around with. He's just trying to get this one thing to work, and cannot find out how or why.

mob/verb
ThrowBomb()
set category = "Battle"
if(usr.AttackTarget in view(usr))
var/mob/M
M = usr.AttackTarget
var/turf/t = M.loc
var/turf/LastPlace = null
var/check = 0
while(usr.loc != t && check == 0)
LastPlace = locate(usr)
sleep(2)//adding this makes it work as intended, but is very annoying and just plain bad overall
step_to(usr,t,0,32)
if(LastPlace == locate(usr))
check = 1
sleep(1)
world<<"Boom"
In response to NNAAAAHH
What do you think "locate(usr)" does?

It doesn't return usr.loc.
In response to Kaiochao
Well, since usr.loc wasn't working, I asked him to try locate(). Still doesn't do sh*t to help the question. The only reason why the verb is in the shape it is now, is because my 5-line verb with if(!step_to()) break (well, 6 if you count break as a line) doesn't appear to to be returning a value.

If no one can provide a reason or explanation as to why, I'll simply delete the post; since it's clear you're not of help here.

All I've received is comments saying I don't know what I'm doing because of someone else's test project; that purposely isn't good in the first place. None of which are pointing out ANYTHING regarding why I posted.
So I guess you're describing something like this:
mob
var tmp/mob/target

Click()
usr << "Set target: [src]"
usr.target = src

verb/throw_bomb()
if(!target || target == src || !(target in ohearers(src))) return
var obj/bomb/bomb = new (loc)
var turf/target_loc = target.loc
while(step_towards(bomb, target_loc)) sleep 1
bomb.explode()

obj/bomb
proc/explode()
ohearers(src) << "Boom!"
del src
In response to Kaiochao
Yes, but the step_ procs don't return positive, which is the entire purpose of the post; if it did, I wouldn't need to post in the first place.

I'm glad you were able almost re-produce the entire original test verb, which didn't work(the reason why there were so many plain bad changes, to attempt to get something to work).

Does step_towards() return positive for you here? Then, does providing a step_size of 96 increase the tiles taken to three per step? Cause neither of which worked in his test project.
In response to NNAAAAHH
When I output the value of step_towards each time, it displays 1 until it hits (0). The step_size doesn't affect it, since "As far as I know, the step() procedures return a Boolean."
In response to Kaiochao
I was asking is step_size in step_ functions worked as intended, because not even that worked in test environments(multiplying the step_size var provided to step_ functions would still result in a single step being taken, instead of the multiple at a time; as intended). I'm glad to finally get a response that relates to the initial question, where as you say step_towards() returns 1 to you each time. It must be something in the test project. I would've tested it myself, if I thought this the case. Odd, though.

No reason(to be seen) as to why step_ functions would return positive for you, but not for my friend?
Because you can change Move() to return anything and step functions return what Move() returns
In response to FIREking
Unfortunately, no, the step() functions don't return Move's return value.

In pixel movement, Move() can return the number of pixels successfully moved. However, step() still only returns 1 or 0.
In response to FIREking
Yes, but searches through Move() yielded no results that should return a negative to any of this. However, it appears to be isolated to his project, so I'll just advise him to open a new test environment to begin newer test.
Whoops sorry!