Showing a player other players and objects on the same tile.

ID:2943308
 
Sep 5, 10:00 am
(See the best response by Ter13.)
Hello, I am working on a MUD like project and am trying to output text to the player when they enter a room that tells them what other players are in that room and if there are any items. I tried using the Entered() proc and I am running into trouble left and right.

My map is a series of 1 tile "rooms" and each has a description that is shown to the player when they enter which works fine but when I try to add a list of the players and objects in the room as well that is when I run into difficulty.

How would I go about this? I tried using oview() to see if I could check that way but that did not seem to work either. I am sure I am missing something.

Any reference for me to read or tips would be greatly appreciated. Thank you.


Sep 6, 7:00 am
Best response
Heya Bloodocean! Welcome back.

You'd check the contents list of the turf the player is standing in. I'd be careful using Entered(), because the object that is doing the entering is not necessarily a player. What we want, is for room descriptions to be an action that a mob can take. The mob uses its eyes to scan the room, so let's build that into your game as a behavior that all mobs can use, but no mobs DO use by default:

mob
    verb
        look()
            //don't describe anything if we're not on the map.
            if(!loc)
                usr << "You don't see anything at all!"
                return

            //describe the room otherwise
            usr << "[loc.name]\n\t[loc.desc]"

            //set a counter so we know how many objects were printed here
            var/counter = 0
            usr << "\nObjects here:"

            //loop over your location's contents list, filtering only /obj descendants
            for(var/obj/o in loc)
                usr << "\t[o]"
                ++counter
            //if no objects were printed, make the output less awkward
            if(!counter)
                usr << "\tNothing"
            else
                //otherwise, reset the counter to 0
                counter = 0

            //do the same thing for mobs
            usr << "\nPeople here:"

            //loop over your location's contents list again, this time filtering only /mob descendants
            for(var/mob/m in loc)
                if(m==src) //don't describe the object we're looking through. See addendum #1
                    continue
                else if(m==usr) //special case for seeing yourself through someone else's eyes
                    usr << "\tYou"
                else
                    usr << "\t[m]"

                ++counter
            if(!counter)
                usr << "\tNobody"


Now, verbs are like procs, but they are special. Verbs are procs that connected clients get told they can use by either typing in the commands, or by using right click context menus. But they can also be called like procs. --We just wanna make sure if we ever call a proc that relies on usr, that we call it from a verb-like command. Let's rig that up now so that clients can tell their mobs to look around themselves whenever they move:

By default, BYOND has movement keys bound to the client procs. These pseudoverbs are called North(), South(), East(), West(), and their diagonal variants. All of these procs are safe to use usr in, as they are executed by the client like verbs. All these verbs do is call client.Move(). This means that client.Move(), when called from a pseudoverb is also safe to use usr in. --This may not always be the case, especially when you are calling client.Move() yourself from something like a server-side keytracker.

client
    Move()
        . = ..() //store the return value of the default action of client.Move() (attempts to move the mob, and if it succeeds, returns 1, or if it fails, returns 0
        if(.) //if we have successfully moved, call the mob's look() verb after the movement has succeeded.
            mob.look()


Addendum #1:

There's a funky bit of code I put into the look proc. I built the proc using usr on purpose, assuming that the person looking out from the mob doing the looking may not always be the same person.

Let's say we add the ability to jump inside of another mob's head and witness everything that they can see. In this case, the user's client calling look() on that mob would not have a matching usr and src. The person being spied through would not receive the messages, but the person doing the spying would, because they are the usr. But if the person spying through the other user happened to see themselves through another player's eyes, instead of seeing their name, they'd see the word "You". src and usr are subtly different, and there are cases where you should opt for one over the other, or where it may be useful to make the distinction, such as in Stat(), or cases like this one where a behavior is being harnessed for two different purposes that vary slightly when being used where usr is src and where it is not.
Sep 6, 9:06 am
Wow! Thank you Ter13 for your detailed response, this is a huge help and makes way more sense than how I was thinking about this. I appreciate your assistance and I will experiment with what you provided to learn all I can from it. The "spy" feature is very cool and an interesting addition which I can already imagine scenarios for it's use.

I will let you know if I end up having follow up questions for this once I dig into it further.

Thanks again! :)