ID:259237
 
Here's the code, from my doors' "close" verb:

var/mob/M
for(M in src)
M.Damage(1, "Pinched in door")
M << "You have to be careful around these automatic doors."
world << "M is [M]"

world << "After loop, M is [M]"


And the output:

You have to be careful around these automatic doors.
M is Gughunter
After loop, M is


The weird thing is, I do almost the exact same thing-- looping through a list and seeing if it sets a variable-- elsewhere in my code with no problems. For example, this works fine:

var/obj/electric_prod/myProd
for(myProd in src)
break

if(myProd && prob(PROD_EFFECTIVENESS) && \ //etc...


What am I missing here?
On 9/28/00 5:25 pm Guy T. wrote:
Here's the code, from my doors' "close" verb:

var/mob/M
for(M in src)
M.Damage(1, "Pinched in door")
M << "You have to be careful around these automatic doors."
world << "M is [M]"

world << "After loop, M is [M]"


And the output:

You have to be careful around these automatic doors.
M is Gughunter
After loop, M is


The weird thing is, I do almost the exact same thing-- looping through a list and seeing if it sets a variable-- elsewhere in my code with no problems. For example, this works fine:

var/obj/electric_prod/myProd
for(myProd in src)
break

if(myProd && prob(PROD_EFFECTIVENESS) && \ //etc...


What am I missing here?

The difference is that because M is never set any specific value, it loops through all of the possible values then defaults to null. The same code would work by:

var/mob/M
var/mob/O
for(M in src)
M.Damage(1,"pinched in door")
M << "You have to be careful around these automatic doors."
world << "M is [M]"
O = M
world << "O is [M]"
world << "After loop, O is [M]"

which would give you the last mob in the list of src's contents.
On 9/28/00 5:25 pm Guy T. wrote:

What am I missing here?

The same thing I'm missing, apparently! I wasn't aware that this was the case. It's very possible that for the 'for(A in B)' situation, the server is assigning A before aborting at the end of the list, so that the last value is invalid (null). This would somewhat mimic the conventional for(i=0,i<=len,i++) loop, which always ends on an index exceeding the size of the loop (i=len+1 at the end). More likely is that the null assignment is intentional, due to some oft request a while back. Either way, I'll mention it to Dan, or perhaps if he is reading the forum he can give his two cents.

Quirky find! At least it's consistent in its behavior.

Incidentally, the other examples work because the 'break' call is explicitely ending the loop. In the "buggy" case the loop is implicitely ending.