ID:142227
 
Code:
obj
End
Bump(mob/m)
if(editor)return(1)
if(!(locate(/obj/Coin)in range(200,m)))
m.breathing=200
if(m.testing)
for(var/obj/buttons/Exit/E in m.client.screen)del(E)
m.testing=0
m.z=6
m.loc=locate(/obj/Start)in oview(200)
m.icon_state="normal"
editor=1
m.density=0
m.icon=null
m.client.perspective=MOB_PERSPECTIVE
m.AddButtons()
else
if(m.z==2)
m.z++
m.loc=locate(/obj/Start)in oview(200)
m.icon_state="normal"
m.tutorial=0
return(0)
if(m.z==3)
for(var/obj/buttons/Exit/E in m.client.screen)del(E)
m.loc=locate(10,10,4)
m.tutorial=0
return(0)
var/foundlevel=0
m.level+=1
for(var/V in m.vars)if(V=="level[m.level]")
LoadCode(m.vars[V])
foundlevel=1
break
if(!foundlevel)
for(var/obj/buttons/Exit/E in m.client.screen)del(E)
m.loc=locate(10,10,4)
m.level=0
else
m.jumploc=m.loc
var/obj/Start/S=locate(/obj/Start)in range(m,100)
if(S)
m.loc=S.loc
m.icon_state="normal"
if(!(locate(/obj/Start)in m.loc))m.loc=locate(10,10,4)
m.startlives=m.lives
m.tutorial=0


Problem description:
It's sooo tacky! D:
Well I've had lots of tricky problems before, but this really is the mother of screw-ups. Of all the things wrong with this code... Why doesn't the mob "Bump" the end? I've tried everything, and it refuses to advance levels.

Problem-solving is a fun part of DM, but the more I think about this, the more tempting the outside of my second-story window starts to look... Help meee!

Oh, and also, any suggestions for better ways to do these things would be GREATLY appreciated.
Not sure if it has to do with it but...

..() // you forgot to call this.
In response to Andre-g1
No, all the Bump() proc does by default is swap the positions of mobs in the same group.

When an object is bumped, the bump-er's Bump() proc is called, not the bump-ee's. You can make a Bumped() proc, and call it when a mob bumps into another.

atom/proc/Bumped(atom/A) //define a bumped proc

atom/movable/Bump(atom/A) //when something that can move bumps something
..() //you can get rid of this if you aren't using Bump()'s
//Default behavior
A.Bumped(src) //call the bump-ee's bumped proc with src as the arg


Then you can just convert what you have to a Bumped() proc.
In response to Andre-g1
I don't think ..() does anything in Bump(). But I do return 1 or 0 in appropriate (I think) places, so that can't be a problem, right?
In response to Jeff8500
Really? I thought it was the other way around... just like Enter().
In response to Adam753
Nope. It's Bump(), therefore it is called when something bumps something :P
In response to Adam753
Usually, you'd look up procs in the DM Reference before you use them, to avoid these sorts of misconceptions.
Just a thought.
In response to Kaioken
Usually, I do, but I thought I knew this one already. Well anyway, that sorted that out; but there's another problem now: The player's Z increases, but they don't go to the start! This is probably because "my code is tacky and horrible", so what's the proper way of making them go to the nearest start? Thank you loads in advance!!
In response to Adam753
In short, most definitely your problem is that you have supplied no Center argument for that view() call, therefore it uses usr, the default, which is inappropriate here.

Also, don't see this as rude, but,

Adam753 wrote:
Usually, I do, but I thought I knew this one already.

Why, that's fine, but if you're having problems that's even more incentive to try the Reference before posting a help topic, which should basically be a sort of 'last resort' if you're unable to solve it yourself, since the latter is better.
In response to Adam753
usr.loc = locate(/obj/Start) in usr.z
In response to Andre-g1
the z variable does not seem to contain anything, so I doubt you can look for things in it.
This should work, but doesn't:
if(locate(/obj/Start)in range(200)) usr.loc=locate(/obj/Start)in range(200)

This is in the Click() proc, so usr is appropriate, and yet it finds no Start!
In response to Adam753
My method should work logic wise though.
for(var/obj/Start/O in range(200,usr))
usr.loc = O.loc


There, should work(not based on logic now xD)
In response to Adam753
It would be better to use the block proc (or, at least that's how I've seen most people do it). Also, you don't need to call locate() twice.

var/turf/T = locate(/obj/Start) in block(locate(1,1,usr.z), locate(world.maxx, world.maxy, usr.z))
if(T)
if(!usr.Move(T, get_dir(usr, T))) //It's usually best to call the Move proc when possible. Also, you could combine these 3 lines into one...
usr.loc=T //If the move proc fails, you still want usr to go there.

In response to Andre-g1
After 'in' a list is supposed to come*, and 'z' is a number, so...

*: An /atom or /world can also come, as a shorthand, in which case it'll use the contents list of that.
In response to Andre-g1
When you only want to find one spot on the map, you should use locate() instead of looping through them. If for some reason you do loop through them, then in this situation you would want to call break so that you don't get moved to every single begin object before finally stopping on the last one.
In response to Kaioken
It would still pretty much make sense for that to work.

I sort of knew it wouldn't, but my logic drove me to post.
In response to Adam753
Adam753 wrote:
This should work, but doesn't:
> if(locate(/obj/Start)in range(200)) usr.loc=locate(/obj/Start)in range(200)
>


Keep in mind your code would be clearly repeating the same action twice when only once is ever needed; to make it more effective, you'd rewrite it like so:
var/Start = locate(...)
if(Start) loc = Start


This is in the Click() proc, so usr is appropriate, and yet it finds no Start!

1) Hm, I was commenting on the code in this thread. Eg, your Bump() proc. ?_?
2) Maybe that would be because... there is no Start? In that range?