Lobby or Quiet Room

[Roger Johnson]

UPDATE:: Griatch convinced me Lobby Handler best way to go

using https://github.com/evennia/evennia/wiki/Turn-based-Combat-System as a model to create Lobbyhandler

[Vincent Le Goff]

Hi,

I'm not quite sure to understand the question, so I might not be answering it.  The first thing I'm not positive about is your mention of players: players on Evennia (soon to be renamed "accounts" to avoid this problem) are just entities to which you can login to.  They don't hold many information besides your username and password.  When you connect (using the "connect" command, if you are in multi-session mode 0-1), the player attempts to connect and immediately puppet the character linked with this player.

So in multi-session mode 0-1, there is no "moment" between connection and puppeting.  In multi-session 2-3, you need to connect (to a player) and then puppet (a character) with the @ic command.  So there is a step in between.  However, as far as I know, players don't go in rooms, characters do.  Most ofjjects do, actually.  I don't know if you can send player objects to rooms.  And since in this mode you are not connected to a character yet, I don't know how you could place a character in your lobby room.

There are a lot of ways around this problem however: one solution would be to allow players to use the communication commands (like say, whisper, pose...).  The "look" command for players could be just overridden to display a fake decor (that might include all the other connected players at this moment).  Player commands aren't very different to design from character commands.  Another possibility would be to have players puppet in an object within a room before they use the @ic command.  I don't think that's the best solution, but it exists.  And doubtless there are many options I haven't thought off.

If you choose a "real" room, removing its exits is quite simple, and you don't need to override anything in code.  Just use the builder commands (I would recommend to get familiar with them, they're most useful and will save you from code editing before you really have to).  If you really want to have a LobbyRoom typeclass, you can do so quite easily too, just inherit from the Room typeclass (I would say most examples you saw used this strategy but I'm not so sure).

HTH,

Vincent

On 20/08/2017 05:22, Roger Johnson wrote:

On 20/08/2017 05:22, Roger Johnson wrote:

What would be the best way to achieve a lobby type room.  A single type of room and even location that many players will be in my case before they puppet their characters.  I looked at the dark room example and the snippets I took, I'll admit I didn't run the tutorial program, but I did try the locks.add("view.false()") and I also tried overriding the room class functions

def announce_move_from(self, destination, msg=None, mapping=None):
        return
    def announce_move_to(self, source_location, msg=None, mapping=None):
        return

I realize at least now maybe not so much at the time it is the object moving that is announcing.  I have seen that the object class has a emit to all objects a message

def msg_contents(self, text=None, exclude=None, from_obj=None, mapping=None, **kwargs):
        """
        Emits a message to all objects inside this object.

        Args:

which will be my next course and then I will continue.  I am assuming of course that the room is the conduit for the player messages of leaving and arriving since it seems to be room dependent.  But since objects also can give what objects are in it and which are players the whole thing could be handled by the player/character object.  I have looked into the dark room tutorial as I mentioned and a cursory review of the forums I ran into a tree falling in the woods paradigm.  It took me 30 minutes to read through it and understand what if anything was desired from that post so I stopped looking in the forums.  If this has already been asked though I would gladly look at the post if only I could be directed a bit so I don't waste too much time looking at the forums.  Because 30 minutes failing to code correctly can still yield learned results.  Reading strange posts unfortunately doesn't always do the same.


Thank you in advance as the community has been very helpful thus far!

PS in case it wasn't clear I'd like a room that displays no exits no objects and recieves no msgs of players coming or going as it will be a shared room by every player logging in or creating a new character but it'll be independent lobbys if that makes any sense. 

--
You received this message because you are subscribed to the Google Groups "Evennia" group.
To unsubscribe from this group and stop receiving emails from it, send an email to evennia+u...@googlegroups.com.
To post to this group, send email to eve...@googlegroups.com.
Visit this group at https://groups.google.com/group/evennia.
To view this discussion on the web visit https://groups.google.com/d/msgid/evennia/94db473b-6606-427c-aee4-0c4c82c3a676%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Roger Johnson]

UPDATE:: I found it in players.py of evennia.  Edited post to express new concerns and questions

You are right there is already a "lobby" when using multi-session 2-3.  I missed this I guess I just need to find where this is populated and how and manipulate that as I would like to change the look.  Don't know how I missed that guess I just spent too much time staring at the screen and knew what I wanted just didn't see it.  As far as location I am pretty sure it says everything has a location except for Rooms but maybe I am mistaken or read wrong.  So is the following not a room??


Connected session:
 * 1 websocket (127.0.0.1)

 help - more commands
 ooc <Text> - talk on public channel
 @charcreate <name> [=description] - create new character
 @chardelete <name> - delete a character (cannot be undone!)
 @ic <character> - enter the game (@ooc to get back here)

Available characters (2/unlimited):

[Vincent Le Goff]

Players don't have locations.  But then players aren't the type of objects that was mentioned, actually.  Somebody who better knows Evennia will describe it more accurately, but you have players, scripts, channels, and a few other things that aren't exactly considered "standard" typeclassed objects... though they do have attributes and a few other features.  In the object (ObjectDB) table, rooms, exits, objects, characters and whatever else, they all have locations (except for rooms), that is correct.

So when you are in multi-session mode 2-3, and you use the "connect" command, you aren't in a room.  What you see (what you sent in your last message) is a custom look command that applies on players.  You can override it to "fake" a room description and show the other players, but that's not a room.  You can also do it the easy way by overriding a player hook (in your typeclasses/players.py).  Its name is "at_look" and takes in argument all your playable characters.  So you can ovverride this method and return something else, like a "fake" room description and the list of all connected players.  When you puppet a character (using @ic for instance), the character "look" command overrides the player "look" command so this ability is lost.  Which is, I believe, what you want to do.

HTH,

Vincent

To view this discussion on the web visit https://groups.google.com/d/msgid/evennia/51bb81c1-17c6-4804-936c-c50ff56319ea%40googlegroups.com.

[Roger Johnson]

Updated thanks again for any help and all the help so far!

[Griatch Art]

A Lobby has no real need for a location. What you want is a custom LobbyHandler (likely a Script so you get persistency and Attributes) which Players attach to. Take a look at the Turn-based Combat tutorial, that implements a CombatHandler to which the combattants subscribe. That one is for Characters, not Players, but the principle of the handler is the same. You can then implement communication and admin commands to operate on those subscribed to the same handler instance (just have multiple handler instances for multiple lobbies). Another popular option is to use the handler with an EvMenu so the Players can pick through a nice menu tree.

If you really, really want a Lobby where you can walk around, look and interact with others etc - don't reproduce that on the Player level. Instead have the Players auto-puppet same-named, auto-created Characters (like MULTISESSION_MODE=0 does it). You drop them into a LobbyRoom (which is a child of Room with your custom overrides that can include custom on-room commands etc). Here they can lounge around the Lobby and you get all the normal spatial features of Objects for free. When leaving the lobby to play as another Character, just just shift the Player to puppet those and move the "Lobby Character" to a None location for storage. This can be completely transparent to the user, especially if you remove the `@ooc` command. In this variant the Player/Account level becomes just a level to store your personal settings (your personal settings screen in a graphical game).
.
Griatch
 

UPDATE:: Okay so far concept idea

Override player.py 

                so that Player recieves attribute location

                look cmd works as character look

Create Lobby(DefaultRoom)

                    override content_get() so that it includes players

                    find/debug other methods effected

Create global variables in settings.py  **no global variable considered unsafe

                     need PLAYER_START_LOCATION or START_LOBBY_LOCATION

                                 Problem setting id to Lobby Room manually could cause conflicts.  Will insert into db and then try catch set location on player where needed

Create Room in db so that global variable is known

                      create limbo on server/at_initial_setup will manually create using cmdset on player for now will test setup later

Also I am looking into @py commands to easily discover what is being seen on the content_get or on the player attributes.  Any help with the syntax of these would be very helpful.

I believe

@py player.location=here    *suggested by vincent-lg 

that's it that's all i got lol so any help with that mechanic would be helpful as well

[Griatch Art]

@Roger: Please only use edit to make typo fixes or clarifications. Don't update your post by removing all that was in it. Instead, keep the thread intact and just add your new insight as new posts. That way the discussion history is preserved. For example, it might be interesting for someone else having similar thoughts as you to see just how your thinking changed over the course of this thread. Also, that way other people's comments still make sense.
.
Griatch

[Roger Johnson]

No problem each response has the "quoted text" perserved I just assumed the top post should reflect the final outcome but I can keep it the same whatever the rules are here.  I have to think carefully as how to create a lobby handler.  Really I just need some additional commands and information displayed on the screen between logging in and puppeting... it's one thing to design the game it's quite another getting the code together to reflect the desire.

[Roger Johnson]

Either way I have to override the Player and use most of the code that already exists and insert mine where appropriate since the multisession options 2 and 3 only exist in a superficial way on the Player.at_look level and is just a list of commands.  It's neither a menu to be edited nor a room to rewrite but just an at_look function of player.  Seems like this is less modular than the rest of the code.  It's why I thought to make it more expansive putting players into rooms......I may still do that I don't know.  If I rewrite the at_look and just add some commands to the PlayerCmdSet then I get my functionality but changes to the "lobby" or adding scripts or other features may be difficult if everything is located in one function and cmds........

[Griatch Art]

Actually, the fact that you can implement all the MULTISESSION_MODEs with relatively simple means makes for maximum flexibility. :) A CommandSet is the most modular part since it can be dynamically added and replaced at run-time.
.
Griatch

[Roger Johnson]

So I probably don't deserve help if I stray from a LobbyHandler and may end up there.  However, I am not sure I won't need more than one lobby "area" and that each lobby "area" my not offer it's own "options"/commands.  This is neatlly created already with rooms to characters.  So the fastest option would be to do as suggested also just create same named character and use them and make lobbies rooms.  I admit I am close to giving up on my project and just doing that, however, I like the idea of just adding room functionality to the Player objects.  One it will help me learn a lot I think and a proper explanation of doing it that way might explain a lot of features of evennia.  Maybe not .... Either way here we go.

So to try and add locations to players I am just trying to have players end up and show the description of Limbo to start with.  Here's what I did to my mygame.typeclasses.player.py

    def at_first_login(self):
        obj = ObjectDB.objects.get(db_key="Limbo")
        self.db.location = dbid_obj(obj.id, ObjectDB)
        self.location=self.db.location
       
    def at_post_login(self, session=None):
        if not hasattr(self, "location"):
            self.location = self.db.location
   
    def at_look(self, target=None, session=None):
        if _MULTISESSION_MODE < 2:
            # only one character allowed
            self.msg("You are out-of-character (OOC).\nUse |w@ic|n to get back into the game.")
            return
       
        #self.msg(self.at_look(self.location))
        self.msg(self.location.at_look(self.location))

The error
 File "./typeclasses/players.py", line 117, in at_look
    self.msg(self.location.at_look(self.location))
AttributeError: 'NoneType' object has no attribute 'at_look'

I am looking into testing if a variable is an object and how to type a variable ((DefaultObject) some_var).method_of_DefaultObject()  but I am afraid this is java thinking.  So any help transferring my skills from java to python is appeciated.  Thanks

[Roger Johnson]

Actually that was a corrupted at_look I seemed to have messed up from moving code around.  Here is what it looks like

def at_look(self, target=None, session=None):
       
        if _MULTISESSION_MODE < 2:
            # only one character allowed
            self.msg("You are out-of-character (OOC).\nUse |w@ic|n to get back into the game.")
            return
       

        target=self.location
       
        if not target.access(self, "view"):
            try:
                return "Could not view '%s'." % target.get_display_name(self)
            except AttributeError:
                return "Could not view '%s'." % target.key

        description = target.return_appearance(self)

        # the target's at_desc() method.
        # this must be the last reference to target so it may delete itself when acted on.
        target.at_desc(looker=self)

        return description


This gives the NoneObject does not have at_look error on the line
          if not target.acess(.....

I have also tried

def at_look(self, target=None, session=None):
       
        if _MULTISESSION_MODE < 2:
            # only one character allowed
            self.msg("You are out-of-character (OOC).\nUse |w@ic|n to get back into the game.")
            return
       

        DefaultObject.at_look(self.location)

No errors, but nothing no response from the server I am in fact logged in and have all OOC commands available.   Trying things like @py self.location.desc to see if I can get an understanding of what is happening

[JC]

So... I read through the thread, and one thing that I maybe don't understand is - what are you trying to accomplish? I mean, if you were going to describe this feature in a paragraph (without necessarily saying how it would be implemented) how would you describe it?

I often find that when I'm coming up against some wall in the code, I'm either overlooking something obvious, or trying to use a feature in a way that it wasn't designed to be used. In the second case, there's usually a better option to fulfill the feature requirements, rather than necessarily trying to solve the technical code challenges posed by using a feature in a way it wasn't designed to be used.

[Roger Johnson]

The proof of need I have come up with is a Lobby system where the player has their own "Lobby"  that really is just a landing "page" to either start a table top game or view games looking for players.  Games other people have started would be a different lobby and using the view access could easily determine whether a player would see them.  You could puppet certain characters created in the other Lobbies but it would be limited to those games.  My actual need is similar but not the same.  But I think if I can learn to add an attribute and "steal" complete functionality from a typeclass then I could do just about anything I want.  So that's really my desire to learn to add attributes that already have so much functionality and "steal" functionalities as needed.

Hope that helps.

Griatch had already suggested making just a simple handler ..... I could fumble my way through and make a handler I suppose and keep it all in the at_look but I don't think I'd learn much except python. 

Griatch also suggested making same name characters and use the location system on characters.  Again probably much simpler but if I could just learn to steal this function I would learn so much that I could significantly increase my ability to code in evennia.

Hope that helps thanks for checking out the post either way!!

[JC]

That does help quite a bit, thanks!

I'd have to agree. A LobbyHandler and Lobby typeclass sound kind of like what you need. But I think, on reading what you're saying, there's several things there. This is my take on your requirements:

1.  You want players to be able to create their own games.
   
2.  Games should be tied to a lobby; all characters connected to a lobby should be part of the game.
   
3.  Players should have the ability to view all games in progress, or create a new game (probably with some information regarding what the game is about?)
   

The way I'd probably look to fulfilling this, if it was me, is probably a lot like Griatch.

1. 'Character' creation is only for getting into the main, OOC room of the game. This provides a default command set:
   
1. The default command set has the following commands:
1. Find Game - Looks for games in progress with the LFG flag set.
2. Join Game - Joins the current player to the game, moving them to the room the game is taking place in.
3. Create Game - Creates a lobby for players of a specific game and registers the game to the GameHandler, or LobbyHandler, whatever you'd like to call it.
1. Creating a game gives the creator the ability to create character objects for non-game owners to puppet.
2. Creating a game adds an entry to the GameHandler, or LobbyHandler, which tracks all active games and is what players query with the Find Game command.
2. Joining a game room gives another command set.
1. In the GameLobby, which is probably a room, the character can puppet one of the created characters.
2. Given that this seems like a gamemaster type setup, you'll probably have to give people the @emit command.
3. People will need a command to return to the OOC lobby room. OOC, in this case, is just a room type, and they're probably puppeting a character here, rather than as a player object. OOC in this context is only OOC in terms of the game world, not the game itself (i.e. they are not disconnected from their character). The command to return to the OOC room should make them puppet the character object they logged in with, not the one they assumed in the other room, so that it stays available and doesn't have to be recreated if someone else switches in (if that's a concern in your game).

Not sure if that's going to help you - I think it's probably more of the same thoughts you've been getting, just looking over the thread. But the above tasks, with the engine as it is now, is pretty straightforward in concept - in programming, I think some of them will be more challenging than others, but I think you'd learn a lot about how Evennia is supposed to work by doing it this way, or a similar way to what Griatch seems to have suggested.

Either way, good luck! Sounds like a cool idea.

[Roger Johnson]

No that is absolutely correct.  There will be changes to the OOC's cmdsets depending on the "place" they are at.  There will also be descriptions of these "games"/"tables"/"player generated lobbies"  there will also be other players on those tables with characters and there will be who knows what else that may be needed during creation.

If only there was a utility already created that had descriptions and listed objects and players and cmdsets ..... Rooms!! lol  but yes I could create a lobby handler and recreate this function probably a whole lot less functional than the location Room functionality.  Plus since all the functionality is already there why reinvent the wheel?

[JC]

Ah, I see.

I think there's a misunderstanding.

What I'm saying is, OOC is both an in-game and an in-engine concept.

In-game: I'm not talking in-character right now.

In-engine: I'm not puppeting a character object right now.

You should, absolutely, use rooms for this. However, a room is an in-engine IC concept (i.e. you need to be puppeting a character to use it). In order to use an IC in-engine concept, you need an IC in-engine object, i.e. a character object, not a player one.

All of the above things are possible by just creating a typeclass rooms.OOCRoom (like Limbo) that gives them the default command set to allow them to do the above objectives that you've set. Set that as a new character's default location and you're done. That also gives people the ability to talk and chat and look for games in a true lobby environment, as everyone not in a game would be in the same room, and would have all the say/pose/etc commands.

The Handler in this case doesn't take the place of the room functionality. It gives the room someplace to register to, and give you a centralized location to query for the game state, rather than having to search through the database. The Handler's benefit here is tracking all of the rooms that are in-use, and which ones have the LFG flag, with a simple data structure that you can retrieve quickly.

As you said... no need to reinvent the wheel, yeah?

[Roger Johnson]

Okay now I am confused lol.  I do want to thank you though for your genuine interest in this.  So that I can bounce ideas off of someone.  However, I am bit stubborn it took me 6 months to get  evennia to use multiple databases and really it took  chainsol 10 minutes but.... through my extreme unreasonableness I begged for it lol.
So you login and are OOC Player You see:

Welcome Player     --- IE Player "Lobby"  # currently this description is handled in the at_look of DefaultPlayer
     LFG -  look for available games  # this could as easily be an exit as a command to a custom room who's descript is built of available lobbies
     CG  -   Create Game
     .... blah blah 

You are apart of

Unknow Table 1

Unknown Table 2

Unknown Table 3

LFG

Welcome to the LFG

You see:

Games           Descriptions                  GM                No Players             #Basically just a table of available tables this part is probably the one advocate for a handler but Rooms
  Crunchy          MetaGame               ME :OD               0      :*(               #descriptions can be customized so they are built too.

""" The biggest issue with the handler vs using the location issue already in place is let's say a server reload or they have internet stability issues especially with the webclient now and mobile devices are pretty popular.  again I could program in the handler the "location" of the Player Also this "location" will have different cmdset than the 1st Lobby and any table lobby. So the fact that depending on "location" is depending on the "Cmdsets"

Crunchy

Crunchy(#3)
The Crunchy Table is full of surprises.  Meta'd Characters calls for Meta'd Challenges!!
Achievements Given
Mature Content
Pathfinder Setting

You see here:

Players
Crunchy        #viewing Crunchy     wassup Greatest GM at my longitude and latitude 4 games 0 players!!
Soap             #viewing Soap         Made by Crunchy cause Crunchy has no players yet :O(
Bofo             ...

Note to Players                           #object with get locks viewing it is like viewing any other object just it's descr is set by the GM of the table
Note about Setting                      #object with get locks
Starter Pack                               #object with get locks

.....

[JC]

Almost.

You login as a Player object, then you immediately puppet a Character object and you see exactly what you wrote with only needing to program the commands and the rooms on your end. That's the default login process for Evennia. What benefit do you gain from doing it from the Player object instead of the Character object?

On Wednesday, August 23, 2017 at 11:01:25 PM UTC-4, Roger Johnson wrote:

Okay now I am confused lol.

So you login and are OOC Player You see:

Welcome Player     --- IE Player "Lobby"  # currently this description is handled in the at_look of DefaultPlayer
     LFG -  look for available games  # this could as easily be an exit as a command to a custom room who's descript is built of available lobbies
     CG  -   Create Game
     .... blah blah

LFG

Games           Descriptions                  GM                No Players             #Basically just a table of available tables this part is probably the one advocate for a handler but Rooms
  Crunchy          MetaGame               ME :OD               0      :*(               #descriptions can be customized so they are built too.

""" The biggest issue with the handler vs using the location issue already in place is let's say a server reload or they have internet stability issues especially with the webclient now and mobile devices are pretty popular.  again I could program in the handler the "location" of the Player Also this "location" will have different cmdset than the 1st Lobby and any table lobby. So the fact that depending on "location" is depending on the "Cmdsets"

[Roger Johnson]

Ahh  well Players don't have character sheets.
So each game will have a different character sheet so the easiest way to handle that in my mind is puppet a character as in the multi_session 2

because  multiple puppeted toons is suppose to be that's functionality

[Roger Johnson]

And really I do honestly believe that adding location functionality to Player to someone who really understands evennia is probably at most 22 lines of code and maybe altering no more than 4 classes.  Kind of like adding multiple database support was a file that was maybe 10 lines in total.  I just don't know enough yet.  I am working on it, but til then I am up for a little leading by the nose if someone is willing.  Otherwise as I have shown I will spend as much time as it takes to get it to work lol

[Roger Johnson]

Okay so I have looked and looked through evennia code to try and identify how evennia adds location cmdsets I have finally gotten it to give a Player a location and display the description using the Parent DefaultObject.at_look code.

I believe the issue is in cmdhandler
   from the header comment
"""
Command handler

This module contains the infrastructure for accepting commands on the
command line. The processing of a command works as follows:

1. The calling object (caller) is analyzed based on its callertype.
2. Cmdsets are gathered from different sources:

   - channels:  all available channel names are auto-created into a cmdset, to allow
     for giving the channel name and have the following immediately
     sent to the channel. The sending is performed by the CMD_CHANNEL
     system command.
   - object cmdsets: all objects at caller's location are scanned for non-empty
     cmdsets. This includes cmdsets on exits.
   - caller: the caller is searched for its own currently active cmdset.
   - player: lastly the cmdsets defined on caller.player are added.

This doesn't seem to be accurate as I have set the location attribute.  It seems it first tests what is calling the command handler and then acting very specifically according to that.


either in the _run_command function or the

get_and_merge_cmdsets(caller, session, player, obj, callertype, raw_string): 
          I believe obj is not defined when a Player makes a cmd call so it is skipped in the

def _get_cmdsets(obj):
    ...
    if player:  # this automatically implies logged-in
                pcurrent, player_cmdsets = yield _get_cmdsets(player)
                cmdsets += player_cmdsets
                current = current + pcurrent
                if obj:
    After this conditional test is when it would add location and exit command sets

From the _run_command:

    ....

   if callertype == "session":
        session = called_by
        player = session.player
        obj = session.puppet
    elif callertype == "player":
        player = called_by
        if session:
            obj = yield session.puppet
    elif callertype == "object":
        obj = called_by
    else:

I do doubt the _run_command is the right direction but since it is conditionally testing for "player" I have added it as a possibility but from what I can read from the code it isn't the source of the problem, however it may be a solution to sending an "obj" to the other function.

Any help on this would be great.  I will keep digging and testing Any help would be awesome though. 

Thank you for the help
    
I am going to attempt to change the _run_command but I am fairly certain this will do nothing and if it does it will simply break the game lol

   if callertype == "session":
        session = called_by
        player = session.player
        obj = session.puppet
    elif callertype == "player":
        player = called_by
        if session:
            obj = yield session.puppet

        else:

            obj = called_by

    elif callertype == "object":
        obj = called_by
    else: