Run Migrations! Dev-branch merged (Many-chars-per-player)!

[Griatch Art]

As of today, I've merged the development branch into main. This is the whole many-characters-per-player update mentioned in a previous post along with a huge number of bug fixes and cleanups all over the server. It also comes with some API changes which is why this is a pretty long post.

It's imperative that you run migrations after pulling this since there are many changes to the schema:

game/manage.py migrate

T

Things you have to update manually:

If you have partially overloaded and import the default cmdsets into game/gamesrc, you have to update to their new names and locations:

• src.commands.default.cmdset_default.DefaultCmdSet changed name to src.commands.default.cmdset_character.CharacterCmdSet
• src.commands.default.cmdset_ooc.OOCCmdSet changed name to src.commands.default.cmdset_player.PlayerCmdSet

(in the same way ev.default_cmds now holds CharacterCmdSet and PlayerCmdSet instead of the old names)

Note that if you already named your own cmdset class differently and have objects using those cmdsets in the database already, you should keep the old name for your derived class so as to not confuse existing objects. Just change the imports. The migrations will detect if any objects are using the old defaults and convert them to the new paths automatically.

Also the settings file variable names have changed:

• settings.CMDSET_DEFAULT has changed to settings.CMDSET_CHARACTER
• settings.CMDSET_OOC has changed to settings.CMDSET_PLAYER

The system will warn you at startup if your settings file contains the old names. 

If you have extensively modified Object Typeclasses, you need to update your hooks:

• obj.at_first_login(), at_pre_login(), at_post_login() and at_disconnect() are removed. They no longer make sense since the Player is no longer auto-tied to a Character (except in MULTISESSION_MODE=0 and 1 where this is retained as a special case). All "first time" effects and "at login" effects should now only be done on the same-named hooks on the Player, not on the Character/Object.
  
• New hooks on the Object are obj.at_pre_puppet(player), at_post_puppet(), at_pre_unpuppet() and at_post_unpuppet(player). These are now used for effects involving the Character going "into" the game world. So the default move from a None-location (previously in at_pre_login()) is now located in at_pre_puppet() instead and will trigger when the Player connects/disconnects to/from the Object/Character only. 

The Permission Hierarchy lock function (perm) has changed in an important way:

• Previously, the perm() lock function checked permission only on the Character, even if a Player was connected. This potentially opens up for escalation exploits and is also rather confusing now that the Player and Character is more decoupled (which permission is currently used?)
• perm() now checks primarily the Player for a hierarchy permission (Players, Builders, Admins etc, the stuff in settings.PERMISSION_HIERARCHY). Other types of permissions (non-hierarchical) are checked first against Player and then, if the Player does not have it, on the Character.
  
• The @quell command was moved from a contrib into the main distribution. It allows Players to force hierarchical permission checks to only take the currently puppeted Character into account and not the Player. This is useful for staff testing features with lower permissions than normal. Note that one can only downgrade one's Player permission this way - this avoids Player's escalating their permissions through controlling a high-perm Character. Superusers can never be quelled, same as before.
  

This is not a show-stopper, but nevertheless an important change:

• settings.ALLOW_MULTISESSION was removed and is now replaced with MULTISESSION_MODE which can have a value of 0, 1 or 2.

Other Changes to be aware of

• Many-Characters-per-Player multisession mode. See the previous post here.
• Player.character does still exist for backwards compatability but it is now only valid in MULTISESSION_MODE 0 or 1. Also this link will be meaninless when the Player goes OOC - the Player-Object link is now completely severed (before it remained). For MULTISESSION_MODE=2, you must use Player.get_character(sessid). See src.commands.default.player.py for details on how to get the Character now. 
• The @ic and @ooc and @ooclook commands use an Attribute _playable_characters to store a list of "your" characters. This is not hard-coded but only used by those commands. This is by default only used for listing convenience - locks are now the only thing blocking other users from puppeting your characters when you are not around. Keeping a list like this is now the only safe way to relate Characters with a given Player when that Player is offline.
• Character typeclass has new hooks at_pre_puppet
  
• ObjectDB.search() has a changed api: search(ostring, global_search=False, use_nicks=False, typeclass=None, location=None, attribute_name=None, quiet=False, exact=False. The changes here are the removal of the global_dbref keyword and that ignore_errors keyword was changed to quiet. More importantly the search function now always only return Objects (it could optionally return Players before). This means it no longer accepts the *playername syntax out of the box. To search for Players, use src.utils.search.player_search (you can always look for the asterisk manually in the commands where you want it). This makes the search method a lot more streamlined and hopefully consistent with expectations.
  
• object.player is now only defined when the Player is actually online (before the connection would remain also when offline). Contrary to before it now always returns a Player typeclass whenever it's defined (Issue 325)
  
• object.sessid is a new field that is always set together with character.player.
  
• object.msg() has a new api: msg(self, message, from_obj=None, data=None, sessid=0). In reality this is used mostly the same as before unless wanting to send to an unexpected session id. Since the object stores the sessid of the connected Player's session, leaving the keywords empty will populate them with sensible defaults.
• player.msg() also has changed: msg(self, outgoing_string, from_obj=None, data=None, sessid=None). The Player cannot easily determine the valid sessid on its own, so for Player commands, the sessid needs to be supplied or the msg will go to all sessions connected to the Player. In practice however, one uses the new Command.msg wrapper below:
  
• command.msg is a new wrapper. It's call api looks like this: msg(self, msg="", to_obj=None, from_obj=None, data=None, sessid=Noneall_sessions=False). This will solve the problem of having to remember any sessids for Player commands, since the command object itself remembers the sessid of its caller now. In a Player command, just use self.msg(string). To clarify, this is just a convenience wrapper instead of calling self.caller.msg(string, sessid=self.sessid) - that works identically but is a little more to write.
  
• The prettytable module is now included with Evennia. It was modified to handle Evennia's special ANSI color markers and is now the recommended way to output good-looking ASCII tables over using the old src.utils.format_table (which stira
  

Other changes

• New internal Attribute storage, using PickledFields rather than a custom solution; this now also allows transparent lookups of Attribute data directly on the database level (you could not do this (easily) before since the data is internally pickled).
  
• Updated all unittests to cover the default commands again, also with a considerably speedup.
• Plenty of cleanups and bug fixes all over
• Removed several deprecation warnings from moving to Django 1.4+ and a few others.
• Updated all examples in game/gamesrc and the various APIs

The Wiki is currently not updated with the latest updates, that will come gradually. You can ask questions here or in the chat, report bugs and problems in the Issue tracker.

Enjoy!

.

Griatch

[lored...@gmail.com]

On Sunday, May 12, 2013 5:39:21 PM UTC-4, Griatch Art wrote:

As of today, I've merged the development branch into main. This is the whole many-characters-per-player update mentioned in a previous post along with a huge number of bug fixes and cleanups all over the server. It also comes with some API changes which is why this is a pretty long post.

It's imperative that you run migrations after pulling this since there are many changes to the schema:

game/manage.py migrate

T

Having an issue running migrate after the update, not sure what is causing it. The log of both syncdb and migrate command is attached.
 

[Griatch Art]

Hi there,

Your migration looks very strange - from the syncdb it looks like you already have a database, but when you run migrations it looks like it's running the migrations from the start (and finding that your database already as all the stuff it needs) .

Did you maybe create that database without having South installed (this would cause the current state of the schema to be installed), then installed South at a later stage (which tries to add things that you already have)?

If this is the case you you have two options:
 1) Reset your database, then run syncdb + migrate on it (this will loose all data in it, but henceforth it will using South normally)
 2) Run only the migrations past the point when you switched to South. Only you can know where this point is, and it could take a lot of work since you need to check it for every individual app. Unfortunately I think you need to give the migrations for the apps individually, such as "manage.py objects 0005", "manage.py objects 0006" etc. It's still  a lot faster than migrating the schema manually though!

If that is not the reason, I'm not sure what could be wrong. What make of database are you using? I cannot reproduce this error here and noone else has (so far) reported similar issues with migrations.
.
Griatch

[lored...@gmail.com]

Sadly, I hadn't installed South when I had created the database and with the new update and the migrations I installed it hoping that it would make things easier for the update and only seem to have shot myself in the foot. It's alright, though, since this is basically just a test-bed server for me to get familiar with the engine, I can clear the database without much worry. I have the old version stored in a tar, so I can pull the descrips, names and such for the objects from there and recreate them in the new database. Thanks for the quick response!

[Griatch Art]

Good to hear your database is not too critical and that you can reset it without too much hassle. We have lately moved South from the optional (but heavily recommended) to the "required" section of the GettingStarted page. We cannot predict what changes could be coming and we doubt there are many interested in doing this stuff manually. And as noticed, switching to it too late does cause issues like the one you faced.

Good luck with the continued exploration of the engine. :)
.
Griatch