Login

ID:142420
 
Jun 2 2008, 7:14 am (Edited on Jun 2 2008, 7:41 am)
Code:
    Save()
        if(src.cansave)
            var/savefile/S = new("players/[src.ckey]")
            S["last_x"] << src.x
            S["last_y"] << src.y
            S["last_z"] << src.z
            Write(S)
    Load()
        if(fexists("players/[src.ckey]"))
            var/savefile/S = new("players/[src.ckey]")
            Read(S)
            S["last_x"] >> src.x
            S["last_y"] >> src.y
            S["last_z"] >> src.z
            world << "<b><font color=silver>DBZ: <font color=white>[src.name] ([src.key]) has logged in."
            for(var/mob/M in world)
                if(src.muted)
                    if(M.GM)
                        M << "<b><font color=green>[M] has just logged in muted."
    Delete()
        if(fexists("players//[src.ckey]"))
            var/decide=alert(src,"Are you sure you want to delete your character? It will be gone forever.","Confirmation","Yes","No")
            if(decide=="Yes")
                fdel("players[src.ckey]")
                src << "<b><font color=aqua>Your character has been deleted."
            else
                src << "Very Well..."
        else
            src << "<b>No character to delete."


Problem description:
It's saying I am muted when I click Load (I am actually muted when I try to talk), but I never muted myself, ever...
Jun 2 2008, 7:26 am
I don't see anything here that should falsely set your muted variable to a true value, but I do see some logic that could use changing (won't have any effect on this issue in particular, but is an optimization). Instead of:

            for(var/mob/M in world)
                if(src.muted)
                    if(M.GM)
                        M << "<b><font color=green>[M] has just logged in muted."


You should switch the logic to check if you're muted first:
            if(src.muted)
                for(var/mob/M in world)
                    if(M.GM)
                        M << "<b><font color=green>[src.name] has just logged in muted."


You'll also notice that I changed a logic error here as well, on the M << ... line; you were outputting the GM's name instead of src's as a muted player. However, this simply makes it tell you that you're muted (instead of the player logging in), and has no bearing on what would actually set the muted variable, since, as you said:
(I am actually muted when I try to talk)

I suspect the problem of falsely muting you lies somewhere else in the code.

[Edit]
I also just noticed that you're using two different files in your code, if it matters:
        if(fexists("players/[src.ckey]"))
            var/savefile/S = new("players/[firstletter]/[src.ckey]")
Jun 2 2008, 11:22 am
In response to Kuraudo
for(var/mob/M in world) is the wrong way to find players. The correct thing to do is for(var/client/C)
Jun 3 2008, 2:01 am
In response to Garthor
It's also worth to mention that, funnily enough, whenever looking for a specific type of atom, doing for(var/X/Y in world) is actually "wrong". Doing for(var/mob/M) is faster than adding "in world" to force looping through the world.contents list.
Jun 3 2008, 2:25 am
In response to Kuraudo
Kuraudo wrote:
[Edit]
I also just noticed that you're using two different files in your code, if it matters:
>         if(fexists("players/[src.ckey]"))
>             var/savefile/S = new("players/[firstletter]/[src.ckey]")
>


Yea, I used a demo for the saving and loading, then was messing around with the code to fit it into my game and such, I had forgotten to remove that part. Thanks for noticing.
Jun 3 2008, 5:54 pm
In response to Kaioken
Kaioken wrote:
It's also worth to mention that, funnily enough, whenever looking for a specific type of atom, doing for(var/X/Y in world) is actually "wrong". Doing for(var/mob/M) is faster than adding "in world" to force looping through the world.contents list.

I'd like to know where you get this logic. Taken from the DM Reference's section on contents list var (world):

"This example displays a list of every area in existence. As a convenient short-hand, one may simply write for(A) or for(A in world) instead of the full for(A in world.contents)."

This would seem to indicate that either way is inherently equal to the other.
Jun 3 2008, 7:43 pm
In response to Kuraudo
It looks as if in world is specifically for atoms on the map, while leaving it out will grab anything in the game. I think it functions better like this, but that entry could use an update.

mob/verb/loop_test()
    for(var/client/C)  //  <-- Finds clients
        world << "[C]"
    for(var/client/C in world)  //  <-- Finds nothing
        world << "[C] in world"
Jun 4 2008, 1:25 am
In response to YMIHere
YMIHere wrote:
It looks as if in world is specifically for atoms on the map, while leaving it out will grab anything in the game. I think it functions better like this, but that entry could use an update.

Again, I'd like to see where you guys are getting your information. There's a reason I said they're equivalent:
var/list/L = new
world
    maxx=1
    New()
        ..()
        L += new/obj

client/verb
    Test()
        for(var/obj/O)
            src << "[O] found at loc: [O.loc ? "[O.loc]" : "null"]"
            
    Test2()
        for(var/obj/O in world)
            src << "[O] found at loc: [O.loc ? "[O.loc]" : "null"]"

Hopefully we can agree that, if the above code is alone in a project, the only /obj in existence will not exist on the map. However, both loops manage to find it.
Jun 4 2008, 1:32 am
In response to Kuraudo
Kuraudo wrote:
Again, I'd like to see where you guys are getting your information.

View the code I posted, the client will only be displayed in the loop that leaves out "in world." Obviously it doesn't work how I figured if both of your loops locate the object, but they can't be the same if only one of my loops does.
Jun 4 2008, 1:38 am (Edited on Jun 4 2008, 1:44 am)
In response to Kuraudo
You're both correct, in fact.

mob
    verb
        ctest()
            for(var/client/C)
                usr << "I founds me a client named [C]."
            for(var/client/C in world)
                usr << "And using the for list and in world, I founds [C]!"


In my Toy Box test, I only received a message for the first for proc. The second one did not locate a client. They are similar, but not exactly the same. I'm going to take a (probably incorrect) shot in the dark and say the reason why you can find atoms with no location in second proc and not clients is because only atoms have loc vars, which I guess would put them in world.contents by default.

I messed around with a datum just to check...

var/list/datalist=list() // Just to make sure the thing doesn't get cleaned up before it's looked for...

mob
    verb
        dtest()
            datalist+=new/holygrail
            for(var/holygrail/C)
                usr << "You found the holy grail maybe."
            for(var/holygrail/C in world)
                usr << "You found the holy grail somewhere in the world."


Same result, as only the first for proc found it. Make of that what you will, but at least in the case of non-atoms, it seems for(var/x/x) and for(var/x/x in world) is the difference between finding something and not finding anything.
Jun 4 2008, 1:39 am
In response to YMIHere
YMIHere wrote:
View the code I posted, the client will only be displayed in the loop that leaves out "in world." Obviously it doesn't work how I figured if both of your loops locate the object, but they can't be the same if only one of my loops does.

Your code is different, because it's not looking for an atomic object. You can leave out the "in world" for atomic objects because if you leave it out, it searches "in world.contents" anyways. It's not the other way around (adding "in world.contents" doesn't make it search through every game reference). This is most relevant because I was referring to the post before that said that it was wrong to use "in world" on atomic objects, when omitting it just defaults to using "in world.contents" still.

For clients, the story is different. Leaving out the "in world" does not default to searching "in world.contents" because clients are not stored in the world.contents. Instead, for them and other non-atomic objects (i.e. datums), it is mandatory that you leave out the "in world" clause.

In summary:

For atomic objects (essentially, anything derived from /atom), omitting "in world.contents" defaults to "in world.contents"; "in world" is another variation of this short-hand.

For non-atomic objects, leaving it out defaults to searching elsewhere, because those objects aren't stored in world.contents. Adding "in world.contents" breaks because, again, they're not there.
Jun 4 2008, 1:42 am
In response to Devourer Of Souls
Devourer Of Souls wrote:
In my Toy Box test, I only received a message for the first for loop. The second one did not locate a client. They are similar, but not exactly the same.

They are not the same for all cases, no. For atomic objects (turfs, objs, mobs), they are the exact same; leaving out "in world.contents" actually defaults to the same exact behavior as if you had typed it all out (it's a short-hand). For non-atomic objects (clients, datums, etc.), they are not the same, and only the loop without the "in world.contents" clause will find them. See my other reply.
Jun 4 2008, 1:51 am
In response to Kuraudo
Kuraudo wrote:
This is most relevant because I was referring to the post before that said that it was wrong to use "in world" on atomic objects, when omitting it just defaults to using "in world.contents" still.

Oh, I must have missed that we were talking about atoms only.
Jun 4 2008, 2:06 am (Edited on Jun 4 2008, 2:14 am)
In response to Kuraudo
Ugggh, no... you guys have quite misunderstood this, it seems.

Kuraudo wrote:
As a convenient short-hand, one may simply write for(A) or for(A in world) instead of the full for(A in world.contents)."

Yes, this is also a cool (flexible, too) feature of the in operator. Funnily enough, again, using the contents of an object directly instead of the object is probably naturally going to be slightly faster since it doesn't have to switch to using the contents, heh, although that isn't related to the topic at hand.

This would seem to indicate that either way is inherently equal to the other.

What I was saying in [link], is that using for(var/atom/A) to loop through instances of an atom, is more efficient than using for(var/atom/A in world) (or in world.contents - they're equivalent, but the former is most commonly used).
This is because the former loops through all instances of the object internally, while the latter is looping through a /list, which proves slightly slower. You're free to test this.

Also, in reply to other posts, world.contents contains all instances of all atoms, not only atoms that are on the map. It also contains areas, which have no loc. So, looping with for(var/type/X) loops through all instances of the type <small>(I believe you could also loop through everything by omitting the type; maybe 'as anything' without 'in' would work as well)</small>, but for(var/atomtype/X in world.contents) is looping through references in a premade list.

So right, they're equivalent in the effect, but not in how it is accomplished. I pretty much said myself they're equivalent (you can use one in place of the other) in that respect and pointed out the speed difference. The Reference isn't wrong; you can use the shorter method as a short-hand to achieve the same effect.
Jun 4 2008, 2:18 am
In response to Kaioken
Kaioken wrote:
What I was saying in [link], is that using for(var/atom/A) to loop through instances of an atom, is more efficient than using for(var/atom/A in world) (or in world.contents - they're equivalent, but the former is most commonly used).
This is because the former loops through all instances of the object internally, while the latter is looping through a /list, which proves slightly slower.

I don't get where you're going with this. I thought I just told you that they're all looping through the same list, no matter which of the following you choose:
for(var/atom/A)
for(var/atom/A in world)
for(var/atom/A in world.contents)


Again for clarity: All three loop through the exact same list as the third line, there's nothing special about the first, except that it simply doesn't explicitly say that you're searching in world.contents (yet, as I'll clarify again, it is still searching there! No special internal instance list!).

The only way it would possibly be faster is in the 4 (I believe) extra bytes that the interpreter has to read through for the latter method, though that more or less proves negligible. Still, I would rather this topic not be derailed any further, since none of this is relevant to the original post.
Jun 4 2008, 2:47 am
In response to Kuraudo
Kuraudo wrote:
I don't get where you're going with this. I thought I just told you that they're all looping through the same list, no matter which of the following you choose:

I thought I just told you that's wrong. =\ Why do you think the for() loop magically only uses an internal method if it detects a /client was used, or whatever you've said above. Also, I said you're free to test the difference.

Still, I would rather this topic not be derailed any further, since none of this is relevant to the original post.

I was just saying something as a by-the-way thing. I didn't intend to spawn tons of posts for it.