for loop never running

ID:1237636
 
Apr 15 2013, 2:48 am
(See the best response by Kaiochao.)
Code:
mob
    proc
        meet()
            var list/p2u
            for()
                sleep(100)
                p2u = list()
                for(var/mob/Player/m in view(5))
                    src << "Running"


Problem description:
Well, as you guys can see, I'm trying to run a loop which does some stuff every so often. This is turning out to be a pain, because no matter what, I cannot get that 2nd loop to run in any case.

Anyone have any insight as to why? Everything runs before and after it, so its like there's nothing in view(), yet, that's about impossible.

Apr 15 2013, 2:55 am
I'm curious why you are using two loops? Do you need two? You could do the same with one loop.
Example 1:
for(var/mob/Player/m in view(5))
    src<<"running"

Altho this seems more like what you are attempting.
Example 2:
var/i=560
while(i>0)
     i--
    for(var/mob/Player/m in view(5))
        src<<"running"
    sleep(100)


You may want to familiarize yourself more with the other types of loops. You can also use for() in more than one manner.
Apr 15 2013, 2:59 am
In response to Dariuc
for() is an infinite loop, which is what I want. The second loop is my target here. not everything will happen in the 2nd, which is why there are two.

I'm familiar with all types of loops, for() suits my case the most.
Apr 15 2013, 3:02 am
In response to Kitsueki
A while loop to create an 'infinite' loop is nearly the same, likewise it's made for something like this, since for is a bit more complicated, accepting multiple arguements.
while(src)=infinite loop.
while(src)//while it exists
  //do for stuff
  //sleep to avoid crashing


Anyway, before mentioning all that did you even try what I coded?
If it works then is there a problem?
Apr 15 2013, 3:08 am
In response to Dariuc
for() runs the same as while() in this case, just less input from myself. What you did is just a different loop structure, it's the same thing, just some wasted space. I don't need extra arguments >_> it's just an infinite loop.

Like I said, everything runs before and after the 2nd loop, but for some reason no loops are run, which leads me to believe view() is somehow not returning any objects to loop through.
Apr 15 2013, 3:10 am
In response to Kitsueki
Did you try it? My point isn't to sit here and argue back and forth with you over something silly like which loop to use- use whichever you want.

While loops are specifically made for this- it says that in the docs. For loops are specifically made to do multiple things-- it says that in the refs.

I'm here to help you solve a problem-- or not. I'm asking if it works when you try it the way I wrote.
Apr 15 2013, 3:13 am
There is a certain benefit to the while(src) approach, in that the loop will naturally clean itself up when the player in question disconnects from the world, say ... through lagging out, losing internet connection etc. The same logic applies to NPCs, to let you delete them a little more cleanly. It's probably fairly unlikely I grant you, but it's more robust and doesn't cost anything, so!

But anyway, the issue you have is I think it's taking for() as being the iterator form, like for(X in list), only .. with no list or variable, so nothing happens? More commonly people put for (;;), to get the counter form of the loop.

Still, putting the while loop into practice, as it's nicer:

mob
    proc
        meet()
            var list/p2u
            while(src)
                sleep(100)
                p2u = list()
                for(var/mob/Player/m in view(5))
                    src << "Running"


Incidentally, nice Hakuouki icon, I've got the full version of that in my official artbook, it's nice stuff.
Apr 15 2013, 3:18 am
Also, you could verify that the outer loop (for, while, whatever) is running via a debug statement:

mob
    proc
        meet()
            var list/p2u
            for()
                #ifdef DEBUG
                world.log << "Meet execution fired."
                #endif
                sleep(100)
                p2u = list()
                for(var/mob/Player/m in view(5))
                    #ifdef DEBUG
                    world.log << "[m] found in view for meet()."
                    #endif
                    src << "Running"
Apr 15 2013, 3:58 am
Sigh. The view procs by default are centered around usr, not src.
Apr 15 2013, 6:00 am
In response to Stephen001
Hm. I suppose that makes enough sense. I tried the loop change, just to be sure, and it seems I'm at the same crossroad, nothing has changed. I even tried those debug statements, nifty stuff~

@Falcon: Yes. Not only is my mob a /mob/Player, I have another one in front of me as I test it (which is why I'm using view() instead of oview() at the moment, to include myself)

@Kaiochao: I know it uses usr, but the mob that's calling it is what I'm going for here, is there a difference?

@Dariuc: It seemed like you didn't know what you were saying and having me conform to your style instead of providing a solid reason why one works better.

Also, thanks Stephen, I like this icon a lot. Hakuouki is a pretty cool anime.
Apr 15 2013, 6:04 am
It is, yes sir!

Are you sure meet() is being called also? Perhaps you could show us where in your code that is called. You know, basically show us the path the code must follow right from a verb / event that a player does to start this whole process off?
Apr 15 2013, 6:12 am
Alright, then, here is the sequence.

When the the character is made / loaded, this proc is spawned.
        defaults()
            client.eye = src
            client.perspective = MOB_PERSPECTIVE
            client.ccreate_btns(0)
            pop_science()
            cms()
            check_year()
            apply_skin()
            reset_skin()
            set_stances()
            set_bps()
            ref_anger()
            transformations()
            equip_stance(find_equipped())
            apply_hud()
            build_items()
            sort_equips()
            update_skills()
            update_inv()
            check_for_sense()
            is_resting()
            is_flying()
            is_digging()
            ko_check()
            is_attacking()
            UpdateOverlays()
            UpdateUnderlays()
            spawn() u_stats()
            spawn() meet()


From there, this is the full meet proc atm.

mob
    proc
        meet()
            var list/p2u
            while(src)
                #ifdef DEBUG
                world.log << "Meet execution fired"
                #endif
                sleep(100)
                p2u = list()
                for(var/mob/Player/m in view(5))
                    #ifdef DEBUG
                    world.log << "[m] found in view for meet()"
                    #endif
                    src << "Running"
                    p2u += m
                    if(!search_contacts(m)) acquaint(m)
                lose_acqs(p2u)
                if(p2u.len)
                    progress_acqs(p2u)
                    progress_familiars(p2u)
                    progress_relationships(p2u)


I'm sure meet is running, because I get those outputs. Anything after the for(var/mob/Player stuff runs as well, thats what makes me think view() is somehow empty.
Apr 15 2013, 6:16 am
In response to Kaiochao
Best response
Kaiochao wrote:
Sigh. The view procs by default are centered around usr, not src.

...So, try giving src to your view().
view(5, src)
Apr 15 2013, 6:20 am
In response to Kaiochao
...Wut.. that fixed everything. Why is usr not src here though..? o_O

Edit: nvm, this is the second time I've encountered a call stack problem. Another mob was ultimately the caller of this, which is why usr wasn't working. Sigh!

Thanks Kaiochao.
Apr 15 2013, 6:23 am
usr is kind of an unreliable thing inside of procedures. Some events for instance can trigger up procedure calls and usr would be set to null, where-as other call scenarios of the same procedure will see usr set to a value.
Apr 15 2013, 6:26 am
In response to Stephen001
Yeah, lol. I rarely explicity use usr, unless its just convenient (like in Click()), it's hard to account for procs I didn't write though, since I generally allow the named parameters to do their job as are, if they seem right.
Apr 15 2013, 9:04 am
In response to Kitsueki
Kitsueki wrote:

@Dariuc: It seemed like you didn't know what you were saying and having me conform to your style instead of providing a solid reason why one works better.


1.) I'm not a code nazi.
2.) I did support what I was saying, all you had to do was check out the f1 help for confirmation-I know you can use a for loop like you have it set up, it's just pointless when there is a loop suited exactly for what you are doing. Ideally when coding you would want to do something the most efficient way, writing 10 if else statements is the same as using one switch() case-- there are just more benefits to using a switch case statement, which brings me to....
3.) Had you just tried it, answered yes or no about whether it worked, we could have moved onto trying something else to fix the problem. Either way the problem is solved and I learned something new, kind of makes me want to go add view(x,src) to everything in my code now. :/
*shrug*
Apr 16 2013, 6:52 pm (Edited on Apr 16 2013, 7:04 pm)
In response to Dariuc
Dariuc wrote:
2.) I did support what I was saying, all you had to do was check out the f1 help for confirmation

From the DM reference:

for(Init, Test, Inc) Statement

Init and Inc may be omitted. If Test is omitted, the loop will continue forever

While requires an argument in order to operate. For does not.

While is specifically intended to be a comparative loop. Why insert a comparative loop when the for() is suited for the job? Sure, there's the cleanup issue, but the loop won't clean itself up until the object is dereferenced from the stack. Even if the stack doesn't preserve the dereference, the function should stop functioning because the calling object has been garbage collected.

There's simply no advantage to it unless you need some means of explicitly turning it off from outside the loop.
Apr 16 2013, 7:00 pm
I've always found while(src) and the sort to be easier to read than an empty for(), just gives a bit more detail about the loop when you're reading over your code.

While for() might be more ideal for an un-ending loop, it's not always going to be an 'oh yeah, I remember what that loop's for' when you're reading back over older code you've written.

In the end though, they compile into the same thing, so it means absolutely crap outside of readability (and that's a personal preference thing).
Apr 18 2013, 9:21 am
Basically your to loops are not set to overlap you have another loop running somewhere which is set into one giant loop where each loop starts one after another. Here is what I was shown to preventing this.

var
    loop=0
world/New()
    ..()

//Where you have that put this for every single one of your loops.

var
    loop=0
world/New()
    ..()
    spawn() loop()//This sets all the loops to run at the same time so make sure you post it on each of them!