My follow path proc...

ID:144004
 
Apr 27 2007, 10:12 am
Code:
mob
    NPC
        icon = 'NPC.dmi'
        New()
            spawn() Walk_On_Path()
            ..()
    
        proc
            Walk_On_Path()
                var/last
                while(src)
                    var/list/valid = new/list()
                    for(var/x in dirs)
                        if(istype(get_step(src, x), /path))
                            world << "[x] is a path"
                            if(step(src, x))
                                world << "[x] isn't blocked"
                                if(x != turn(last, 180))
                                    world << "[x] isn't the last dir"
                                    valid += x
                    if(!valid.len)
                        world << "Put back in"
                        valid += turn(last, 180)
                    world << "----------------------"
                    for(var/x in valid)
                        world << "[x] is Valid"
                    world << "----------------------"
                    var/next_dir
                    if(valid.len)
                        next_dir = pick(valid)                  
                        if(istype(get_step(src, next_dir), /path))
                            step(src, next_dir)
                            last = next_dir
                    sleep(10)


Problem description:
Ok, for some reason if it goes to the far west of the path it will say that the area to the west is a path when in fact it isn't... The outputs are just for testing... If you have any questions please ask.

I know its not the best way to do it, but its my first attempt. Thanks in advance. [EDIT] Also, please just don't give me the solution, I don't want it. I want the reason mine doesn't work and how to improve it.[/EDIT]

-KirbyAllStar
Apr 29 2007, 5:06 am
To test to see whether the src can move into an area you have "if(step(src, x))". I don't think that's what you want; you do realise that the mob will move to that location in order to test it, don't you? Then the mob is already there, and then farther down you have it pick from the valid directions and move again.

If you don't want the object to move in order to test to see if it can move, use Enter. Get a variable to reference the turf in question, then check with if(turf.Enter(src)), and you will check to see if you can move without actually moving.
Apr 30 2007, 11:59 am
In response to Loduwijk
Loduwijk wrote:
If you don't want the object to move in order to test to see if it can move, use Enter. Get a variable to reference the turf in question, then check with if(turf.Enter(src)), and you will check to see if you can move without actually moving.

That won't actually do, as the Move() proc checks more than that; current atom's Exit(), the areas' Exit() and Enter()... it follows that you should make a custom proc to check all of those.
Apr 30 2007, 12:35 pm
In response to Kaioken
Kaioken wrote:
That won't actually do, as the Move() proc checks more than that; current atom's Exit(), the areas' Exit() and Enter()... it follows that you should make a custom proc to check all of those.

That actually will do, as most situations will not require all that. If he needs to go further, then sure, he can go further; but just checking turf/Enter will be fine 99% of the time.

If you insist on having a thorough check...
atom/movable
    proc/MoveCheck(atom/A)
        if(loc)
            if(!loc.Exit(src))
                return 0
            if(isturf(A) && !loc.loc.Exit(src))
                return 0
        if(!A.Enter(src)) return 0
        if(isturf(A) && !A.loc.Enter(src)) return 0
        return 1

However, in most situations turf/Enter should be fine. If it is not, then the programmer can take the necessary precautions.
May 3 2007, 5:28 am
In response to Loduwijk
It does not matter if only partial implementation usually works; you'll want it to work every time. This is even more important when suggesting only a part of the check to a newbie, and even more on a public forum.
'Nuff said, really.
May 3 2007, 6:36 am
In response to Kaioken
Kaioken wrote:
It does not matter if only partial implementation usually works; you'll want it to work every time. This is even more important when suggesting only a part of the check to a newbie, and even more on a public forum.
'Nuff said, really.

'Nuff not said. You are coming in here nit-picking insignificant points. Sure, 1 in 100 projects might require more than just what I initially stated, but then you can say that about pretty much anything.

If you want to come in here and critisize constructively saying "If you have altered any of the default movement checking functions, don't forget to check them as well." But don't come waltzing in here saying "You're wrong, this is what you do."

If the person understands everything I said, that person will know enough to tailor the idea to the required needs anyway. If the person does not understand it, then that person can ask for more detailed information, at which point everything would be explained in full.

If someone asks "How can I make a command that lets the player talk to everyone in the game?" and I give a response:
mob/verb/talk(message as text)
    world << "[usr]: [message]"

Are you going to tell me that I am wrong because 1 in 100 projects might have the talk function called from elsewhere in the code by a function belonging to a different object, thus making usr incorrect and src the better variable to use?

And what if the person does not even use the default Enter/Exit functions? Their code might have custom movement functions. Sure, it's unlikely, but only as much as having to use more than turf/Enter, so it's all the same.
May 3 2007, 7:09 am
In response to Loduwijk
More than enough said.
By your way of thinking, things such as using 'usr' in procs including movement procs could be considered proper because it works for a lot of projects, etc.
May 3 2007, 8:05 am
In response to Kaioken
Wow I didn't mean to start an argument lol.

The "turf.Enter(src)" works just fine for me, although Kaioken you are right, "if" I needed to check more things, it would be more robust. But all I needed to check was if the NPC could Enter the next turf, i.e. something was there, or out of map(I may need to test this).

Thanks for the help! (Both of you)

-KirbyAllStar
May 3 2007, 12:30 pm
In response to Kaioken
Kaioken wrote:
By your way of thinking, things such as using 'usr' in procs including movement procs could be considered proper because it works for a lot of projects, etc.

Not quite. usr abuse in functions leeds to problems cropping up constantly all the time; it's not a 1 in 100 thing. I have seen litterally hundreds of problems caused by usr abuse; I have not ever seen 1 problem caused by using turf/Enter to check for the ability to move - other people very well may have, but it is a rare enough occurance that you don't have to nitpick about it. Doing so is like saying "The first line of Bump should always be 'if(!O) return' because a null value may have somehow been passed to it which would be in error."

I didn't mean for this to become an argument anyway. If you want, I could write up an outline several pages long listing many points as to why you should not jump straight to the end of the line in every situation, especially on this forum (unless possibly discussing design philosophy of code in the forum section by the same name), but I don't actually think that's what you want. I would do so now just for the fun of it - not because I want to make a big deal out of it, but because I like debating loose ends - but I won't.

Long story short: stating that newbies do not understand fully what needs to be done and therefore we should dump on them more complicated code seems counter-intuitive in my oppinion. I think that is only warrented if you are willing to find out more about their project and make something that is a complete stand-alone module that they can just plug in and use. I could have at least mentioned the things you brought up, sure; but if the person really understands DM as little as you seem to think, then adding that probably wouldn't make things a lot better, and I'd rather explain the inner workings of the default movement system.

Besides, if you look at my record, you'll see that I usually don't give full, perfect examples anyway. I often leave a lot out; my purpose is more to demonstrate a generic idea than it is to give someone code most of the time.

Maybe the above should read 'long story medium'. Sorry for my long-windedness.
May 4 2007, 3:27 am
In response to Loduwijk
Loduwijk wrote:
Maybe the above should read 'long story medium'. Sorry for my long-windedness.

Its ok, I've just skimmed it. Barely much point on doing that anyway.
Times like this, its obvious the other person is too ignorant or whatever to admit he was wrong, which hell, isn't the end of the world. But whatever, no point in trying to prove my point when you won't listen, I've been in this before. You can keep saying its too complicated to do all the checks, but its just instead of having one if(Enter()) having a couple more which are "complicated" just the same.
May 4 2007, 5:27 am
In response to Kaioken
Kaioken wrote:
Loduwijk wrote:
Maybe the above should read 'long story medium'. Sorry for my long-windedness.

Its ok, I've just skimmed it. Barely much point on doing that anyway.
Times like this, its obvious the other person is too ignorant or whatever to admit he was wrong, which hell, isn't the end of the world. But whatever, no point in trying to prove my point when you won't listen, I've been in this before. You can keep saying its too complicated to do all the checks, but its just instead of having one if(Enter()) having a couple more which are "complicated" just the same.

Kaioken, sometimes you really make yourself seem bitter about having a small penis.