Re: keeping information about players around

2012-09-25 Thread Jean-Michel Pichavant
- Original Message -
 PHPMyAdmin? Might I ask why? This is a mud, so it's all command
 based,
 so that's not even a question, but I'm kind of curious how PHPMyAdmin
 factors in there. It's a database creation tool from all I've ever
 seen
 of it, to define tables. Also, using it requires that I have it up on
 some server or another, and I'd really rather avoid that if I can.

Given the nature of your project forget MysQL and phpAdmin. At most you may use 
sqlite. Sqlite data is stored in one file, locally, you can move it back it up 
easily. Sqlite doesn't need any server.
If you don't see How sqlite would benefit your mud, that would be strange, but 
then drop it and use pickled dictionaries if you're familiar with them.

  Why would you use a dictionary, when it's DB manipulation you're
  after?
 
 It is? I don't remember mentioning database anything in my thread.
 Unless I missed it, I mentioned pickle once or twice. But either
 way, I'd use a dictionary to keep a copy of {uid:object} for
 objects and {uid:player} for players. Makes lookup by uid pretty
 easy, as well as for any loaded objects.

Actually you mentioned a player database in your original post. Player with 
their stats are typically something that may ends up in a database, along with 
any object and its properties.
That's why people suggested to use a database. Databases provide then powerful 
tools to fetch, search and edit your data. Performances on disk access would be 
handled by sqlite itself, something you may care by yourself if you use 
dictionaries.

Or maybe your mud doesn't store anything on disk, every run start fresh, in 
that case just use dictionaries.

JM



-- 
http://mail.python.org/mailman/listinfo/python-list


Re: keeping information about players around

2012-09-24 Thread Jean-Michel Pichavant
- Original Message -
 ytHello all:
 I've asked for a couple code reviews lately on a mud I've been
 working
 on, to kind of help me with ideas and a better design.
 
 I have yet another design question.
 In my mud, zones are basically objects that manage a collection of
 rooms; For example, a town would be it's own zone.
 It holds information like maxRooms, the list of rooms as well as some
 other data like player owners and access flags.
 The access flags basically is a list holding the uid of a player, as
 well as a bitarray of permissions on that zone. For example, a player
 might have the ability to edit a zone, but not create rooms.
 So I have a couple of questions based on this:
 First, how viable would it be to keep a sort of player database
 around
 with stats and that?
 It could contain the player's level, as well as other information
 like
 their access (player, admin, builder etc), and then when someone does
 a
 whois on the player I don't have to load that player up just to get
 data
 about them. How would I keep the information updated? When I delete a
 player, I could just delete the entry from the database by uid.
 Second, would it be viable to have both the name and the uid stored
 in
 the dictionary? Then I could look up by either of those?
 
 Also, I have a couple more general-purpose questions relating to the
 mud.
 When I load a zone, a list of rooms get stored on the zone, as well
 as
 world. I thought it might make sense to store references to objects
 located somewhere else but also on the world in WeakValueDictionaries
 to
 save memory. It prevents them from being kept around (and thus having
 to
 be deleted from the world when they lose their life), but also (I
 hope)
 will save memory. Is a weakref going to be less expensive than a full
 reference?
 Second, I want to set up scripting so that you can script events for
 rooms and npcs. For example, I plan to make some type of event
 system,
 so that each type of object gets their own events. For example, when
 a
 player walks into a room, they could trigger some sort of trap that
 would poison them. This leads to a question though: I can store
 scripting on objects or in separate files, but how is that generally
 associated and executed?
 Finally, I just want to make sure I'm doing things right. When I
 store
 data, I just pickle it all, then load it back up again. My world
 object
 has an attribute defined on it called picklevars, which is basically
 a
 list of variables to pickle, and my __getstate__ just returns a
 dictionary of those. All other objects are left as-is for now.
 Zones,
 (the entire zone and all it's rooms) get pickled, as well as players
 and
 then the world object for persistence. Is this the suggested way of
 doing things? I'll also pickle the HelpManager object, which will
 basically contain a list of helpfiles that can be accessed, along
 with
 their contents.
 Thanks, and appologies for all the questions.
 
 --
 Take care,
 Ty
 http://tds-solutions.net
 The aspen project: a barebones light-weight mud engine:
 http://code.google.com/p/aspenmud
 He that will not reason is a bigot; he that cannot reason is a fool;
 he that dares not reason is a slave.
 
 --
 http://mail.python.org/mailman/listinfo/python-list
 

That's a lot of questions, few specific to python.
I have one advice:

Don't think too much about performances. Focus on keeping things simple, work 
on your design and forget about implementation.
Pickle everything, use sqllite for your database. When you get things working, 
then you can start measuring your performances and think about clever 
implementation to speed up things **if needed** (- key notion). 


JM

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: keeping information about players around

2012-09-24 Thread Jean-Michel Pichavant
- Original Message -
 Pickle everything, use sqllite for your database. When you get
 things
 working, then you can start measuring your performances and think
 about
 clever implementation
 That was a bunch of information; sorry about that. what do you mean
 by
 using sqlite for the database? Currently I just drop everything into
 files. Is there a better way to do that?
 Thanks for your advice.

Please keep the discussion on list.

If you have a basic knowledge of databases, sure you could use a sqlite 
database to store you persistent objects. That's pretty reasonable.
Not to mention a lot of stuff can interface with that database. If you want to 
build a web app to manage the player database, you can, most of the frameworks 
handles sqlite. Actually if you don't need a web app, a lot of sqlite admin app 
already exists.

Note that the database is suitable only for the data. For serializing a python 
object with its code, you need pickle.

JM
 
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: keeping information about players around

2012-09-24 Thread Dwight Hutto
 I have yet another design question.
 In my mud, zones are basically objects that manage a collection of rooms;
 For example, a town would be it's own zone.
 It holds information like maxRooms, the list of rooms as well as some other
 data like player owners and access flags.
 The access flags basically is a list holding the uid of a player, as well as
 a bitarray of permissions on that zone. For example, a player might have the
 ability to edit a zone, but not create rooms.
 So I have a couple of questions based on this:
 First, how viable would it be to keep a sort of player database around with
 stats and that?
Well, what are the main items you need to retain for the player to
return to the game?

Also, If this is a browser app I'd go with phpmyadmin, and MySQL

If a tkinter/wxpython/etc app, then maybe sqlite.

 It could contain the player's level, as well as other information like their
 access (player, admin, builder etc), and then when someone does a whois on
 the player I don't have to load that player up just to get data about them.
 How would I keep the information updated? When I delete a player, I could
 just delete the entry from the database by uid.
 Second, would it be viable to have both the name and the uid stored in the
 dictionary? Then I could look up by either of those?

Why would you use a dictionary, when it's DB manipulation you're after?

 Also, I have a couple more general-purpose questions relating to the mud.
 When I load a zone, a list of rooms get stored on the zone, as well as
 world. I thought it might make sense to store references to objects located
 somewhere else but also on the world in WeakValueDictionaries to save
 memory. It prevents them from being kept around (and thus having to be
 deleted from the world when they lose their life), but also (I hope) will
 save memory. Is a weakref going to be less expensive than a full reference?

For any case, you're going to have a DB field with a value, so it
doesn't look like a high value memory cost in the DB.

 Second, I want to set up scripting so that you can script events for rooms
 and npcs. For example, I plan to make some type of event system, so that
 each type of object gets their own events. For example, when a player walks
 into a room, they could trigger some sort of trap that would poison them.
 This leads to a question though: I can store scripting on objects or in
 separate files, but how is that generally associated and executed?

Well, the event doesn't need to be stored unless there is a necessity
to store the event, but if it's poisoned, then it's just a life
penalty, then no need to store the event, just the score loss.

 Finally, I just want to make sure I'm doing things right. When I store data,
 I just pickle it all, then load it back up again. My world object has an
 attribute defined on it called picklevars, which is basically a list of
 variables to pickle, and my __getstate__ just returns a dictionary of those.
 All other objects are left as-is for now. Zones, (the entire zone and all
 it's rooms) get pickled, as well as players and then the world object for
 persistence. Is this the suggested way of doing things? I'll also pickle the
 HelpManager object, which will basically contain a list of helpfiles that

I might suggest you take a look at the Blender Game Engine(python API)
at this point, unless you're just liking doing it the hard way to gain
experience(just like I have).

Design the DB, and let the scene render what needs to be rendered, or
list data  for, and those are the necessities to be stored.

-- 
Best Regards,
David Hutto
CEO: http://www.hitwebdevelopment.com
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: keeping information about players around

2012-09-24 Thread Chris Angelico
On Tue, Sep 25, 2012 at 7:14 AM, Dwight Hutto dwightdhu...@gmail.com wrote:
 Also, If this is a browser app I'd go with phpmyadmin, and MySQL

 If a tkinter/wxpython/etc app, then maybe sqlite.

Out of curiosity, why? MySQL isn't magically better for everything
where data ends up displayed in a web browser. Unless you're planning
to also reference this database from some other language, it's going
to make little difference what backend you use; and even if you are
using multiple languages, it's usually not difficult to find overlap.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: keeping information about players around

2012-09-24 Thread Dwight Hutto
On Mon, Sep 24, 2012 at 6:19 PM, Chris Angelico ros...@gmail.com wrote:
 On Tue, Sep 25, 2012 at 7:14 AM, Dwight Hutto dwightdhu...@gmail.com wrote:
 Also, If this is a browser app I'd go with phpmyadmin, and MySQL

 If a tkinter/wxpython/etc app, then maybe sqlite.

 Out of curiosity, why? MySQL isn't magically better for everything
 where data ends up displayed in a web browser.

No, but phpmyadmin is a great GUI for MySQL

Unless you're planning
 to also reference this database from some other language, it's going
 to make little difference what backend you use; and even if you are
 using multiple languages, it's usually not difficult to find overlap.
Well this is python, but in the browser a little echo, instead of
print, isn't that bad for conversational php.

And in the end it's usually html, php, css, javascript in the browser,
atleast for me it is. I'm just starting to utilize python in that
area, so excuse the naivety.



-- 
Best Regards,
David Hutto
CEO: http://www.hitwebdevelopment.com
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: keeping information about players around

2012-09-24 Thread Dwight Hutto
 Out of curiosity, why? MySQL isn't magically better for everything
 where data ends up displayed in a web browser.

 No, but phpmyadmin is a great GUI for MySQL

Meaning, it gives a great web app, that sqlite doesn't have...yet.
It's the tools around MySQL for me, that gives it the umph it needs to
be a great DB, with the GUI (phpmyadmin)to match, and short
reference/learni8ng curve to use php in this instance.

-- 
Best Regards,
David Hutto
CEO: http://www.hitwebdevelopment.com
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: keeping information about players around

2012-09-24 Thread Chris Angelico
On Tue, Sep 25, 2012 at 8:31 AM, Dwight Hutto dwightdhu...@gmail.com wrote:
 And in the end it's usually html, php, css, javascript in the browser,
 atleast for me it is. I'm just starting to utilize python in that
 area, so excuse the naivety.

In the browser it's HTML, CSS, JavaScript (ECMAScript, etc, etc); PHP
is just a way of generating that. Any language works on the back
end... and PHP isn't the best :) Python does quite well at that task;
I have a tiny little Python script that uses a web browser as its
front ent.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: keeping information about players around

2012-09-24 Thread Dwight Hutto
 is just a way of generating that. Any language works on the back
 end... and PHP isn't the best :) Python does quite well at that task;
 I have a tiny little Python script that uses a web browser as its
 front ent.

This stems from my limited usage of python in the browser(I usually
use it for prototype apps). It's usually going to be the difference
between echo or print html/javascript, and perform an iteration for
table, or formulaic computation within a standard function syntax.


-- 
Best Regards,
David Hutto
CEO: http://www.hitwebdevelopment.com
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: keeping information about players around

2012-09-24 Thread alex23
On Sep 25, 8:32 am, Dwight Hutto dwightdhu...@gmail.com wrote:
 No, but phpmyadmin is a great GUI for MySQL

If you're recommending MySQL use on the basis of phpmyadmin, you
should also make sure to mention:
http://www.phpmyadmin.net/home_page/security/

Great GUI, maybe. Huge security hole, absolutely. Most organisations
I've worked for won't allow it anywhere near their servers.


-- 
http://mail.python.org/mailman/listinfo/python-list


Re: keeping information about players around

2012-09-24 Thread Dwight Hutto
On Mon, Sep 24, 2012 at 7:28 PM, alex23 wuwe...@gmail.com wrote:
 On Sep 25, 8:32 am, Dwight Hutto dwightdhu...@gmail.com wrote:
 No, but phpmyadmin is a great GUI for MySQL

 If you're recommending MySQL use on the basis of phpmyadmin, you
 should also make sure to mention:
 http://www.phpmyadmin.net/home_page/security/

 Great GUI, maybe. Huge security hole, absolutely. Most organisations
 I've worked for won't allow it anywhere near their servers.
 What DB are you recommending, check out sqlite's:

http://www.cvedetails.com/vulnerability-list/vendor_id-9237/Sqlite.html

Maybe just a parsed file with data, and accessing data that you design.

-- 
Best Regards,
David Hutto
CEO: http://www.hitwebdevelopment.com
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: keeping information about players around

2012-09-24 Thread alex23
On Sep 25, 9:44 am, Dwight Hutto dwightdhu...@gmail.com wrote:
  What DB are you recommending, check out sqlite's:

 http://www.cvedetails.com/vulnerability-list/vendor_id-9237/Sqlite.html

Are you _seriously_ comparing _four_ vulnerabilities to 60+?

 Maybe just a parsed file with data, and accessing data that you design.

Just stop.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: keeping information about players around

2012-09-24 Thread Littlefield, Tyler

On 9/24/2012 3:14 PM, Dwight Hutto wrote:

I have yet another design question.
In my mud, zones are basically objects that manage a collection of rooms;
For example, a town would be it's own zone.
It holds information like maxRooms, the list of rooms as well as some other
data like player owners and access flags.
The access flags basically is a list holding the uid of a player, as well as
a bitarray of permissions on that zone. For example, a player might have the
ability to edit a zone, but not create rooms.
So I have a couple of questions based on this:
First, how viable would it be to keep a sort of player database around with
stats and that?



Well, what are the main items you need to retain for the player to
return to the game?



All of their contents are stored, which right now is done through Pickle. The 
stats is something different, as like I said, I don't want to unpickle an 
object every time I for example look at a zone and see what players have 
permissions on it.


Also, If this is a browser app I'd go with phpmyadmin, and MySQL If a 
tkinter/wxpython/etc app, then maybe sqlite.


PHPMyAdmin? Might I ask why? This is a mud, so it's all command based, 
so that's not even a question, but I'm kind of curious how PHPMyAdmin 
factors in there. It's a database creation tool from all I've ever seen 
of it, to define tables. Also, using it requires that I have it up on 
some server or another, and I'd really rather avoid that if I can.



It could contain the player's level, as well as other information like their
access (player, admin, builder etc), and then when someone does a whois on
the player I don't have to load that player up just to get data about them.
How would I keep the information updated? When I delete a player, I could
just delete the entry from the database by uid.
Second, would it be viable to have both the name and the uid stored in the
dictionary? Then I could look up by either of those?


Why would you use a dictionary, when it's DB manipulation you're after?



It is? I don't remember mentioning database anything in my thread. Unless I 
missed it, I mentioned pickle once or twice. But either way, I'd use a 
dictionary to keep a copy of {uid:object} for objects and {uid:player} for 
players. Makes lookup by uid pretty easy, as well as for any loaded objects.



Also, I have a couple more general-purpose questions relating to the mud.
When I load a zone, a list of rooms get stored on the zone, as well as
world. I thought it might make sense to store references to objects located
somewhere else but also on the world in WeakValueDictionaries to save
memory. It prevents them from being kept around (and thus having to be
deleted from the world when they lose their life), but also (I hope) will
save memory. Is a weakref going to be less expensive than a full reference?

For any case, you're going to have a DB field with a value, so it
doesn't look like a high value memory cost in the DB.


Second, I want to set up scripting so that you can script events for rooms
and npcs. For example, I plan to make some type of event system, so that
each type of object gets their own events. For example, when a player walks
into a room, they could trigger some sort of trap that would poison them.
This leads to a question though: I can store scripting on objects or in
separate files, but how is that generally associated and executed?

Well, the event doesn't need to be stored unless there is a necessity
to store the event, but if it's poisoned, then it's just a life
penalty, then no need to store the event, just the score loss.



I was asking about scripting the rooms, more than storing it. I need to have 
python code somewhere, somehow that attaches to the onEnter event in a room and 
subtracts hp from the player. Obviously you want that to be object specific and 
not have that script on everything.



Finally, I just want to make sure I'm doing things right. When I store data,
I just pickle it all, then load it back up again. My world object has an
attribute defined on it called picklevars, which is basically a list of
variables to pickle, and my __getstate__ just returns a dictionary of those.
All other objects are left as-is for now. Zones, (the entire zone and all
it's rooms) get pickled, as well as players and then the world object for
persistence. Is this the suggested way of doing things? I'll also pickle the
HelpManager object, which will basically contain a list of helpfiles that

I might suggest you take a look at the Blender Game Engine(python API)
at this point, unless you're just liking doing it the hard way to gain
experience(just like I have).



That's cool I guess, but I'm not taking your road and doing it the hard way for 
experience. The setup is more of a game engine, but beyond that, I don't think 
I need everything i get from a game library, especially since IIRC, Blender is 
mainly 3d focused?


Design the DB, and let the scene render what needs to be rendered, or 
list 

Re: keeping information about players around

2012-09-24 Thread Dwight Hutto
On Mon, Sep 24, 2012 at 7:52 PM, alex23 wuwe...@gmail.com wrote:
 On Sep 25, 9:44 am, Dwight Hutto dwightdhu...@gmail.com wrote:
  What DB are you recommending, check out sqlite's:

 http://www.cvedetails.com/vulnerability-list/vendor_id-9237/Sqlite.html

 Are you _seriously_ comparing _four_ vulnerabilities to 60+?

Even less if you use your own DB structure, and evn less in mysql if
you reject the injections of the known vulnerablities.

 Maybe just a parsed file with data, and accessing data that you design.

 Just stop.

Why not suggest odbm or relational db's, this shows your lack of
complexity in design, so please stop your own Dunner-Kruning.



-- 
Best Regards,
David Hutto
CEO: http://www.hitwebdevelopment.com
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: keeping information about players around

2012-09-24 Thread Steven D'Aprano
On Tue, 25 Sep 2012 08:19:34 +1000, Chris Angelico wrote:

 On Tue, Sep 25, 2012 at 7:14 AM, Dwight Hutto dwightdhu...@gmail.com
 wrote:
 Also, If this is a browser app I'd go with phpmyadmin, and MySQL

 If a tkinter/wxpython/etc app, then maybe sqlite.
 
 Out of curiosity, why? MySQL isn't magically better for everything where
 data ends up displayed in a web browser. Unless you're planning to also
 reference this database from some other language, it's going to make
 little difference what backend you use; and even if you are using
 multiple languages, it's usually not difficult to find overlap.

For a desktop application, you can't expect the application user to have 
set up MySQL or Postgresql first, so you have to use something like 
sqlite.

For web applications, you're probably expecting (or at least hoping for) 
tens of thousands of users a day, and sqlite probably won't cut it. If 
your web app is only used by you, then you might not care.

I think it is perfectly reasonable to assume a web app and a desktop app 
might use different backends.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list


keeping information about players around

2012-09-23 Thread Littlefield, Tyler

ytHello all:
I've asked for a couple code reviews lately on a mud I've been working 
on, to kind of help me with ideas and a better design.


I have yet another design question.
In my mud, zones are basically objects that manage a collection of 
rooms; For example, a town would be it's own zone.
It holds information like maxRooms, the list of rooms as well as some 
other data like player owners and access flags.
The access flags basically is a list holding the uid of a player, as 
well as a bitarray of permissions on that zone. For example, a player 
might have the ability to edit a zone, but not create rooms.

So I have a couple of questions based on this:
First, how viable would it be to keep a sort of player database around 
with stats and that?
It could contain the player's level, as well as other information like 
their access (player, admin, builder etc), and then when someone does a 
whois on the player I don't have to load that player up just to get data 
about them. How would I keep the information updated? When I delete a 
player, I could just delete the entry from the database by uid.
Second, would it be viable to have both the name and the uid stored in 
the dictionary? Then I could look up by either of those?


Also, I have a couple more general-purpose questions relating to the mud.
When I load a zone, a list of rooms get stored on the zone, as well as 
world. I thought it might make sense to store references to objects 
located somewhere else but also on the world in WeakValueDictionaries to 
save memory. It prevents them from being kept around (and thus having to 
be deleted from the world when they lose their life), but also (I hope) 
will save memory. Is a weakref going to be less expensive than a full 
reference?
Second, I want to set up scripting so that you can script events for 
rooms and npcs. For example, I plan to make some type of event system, 
so that each type of object gets their own events. For example, when a 
player walks into a room, they could trigger some sort of trap that 
would poison them. This leads to a question though: I can store 
scripting on objects or in separate files, but how is that generally 
associated and executed?
Finally, I just want to make sure I'm doing things right. When I store 
data, I just pickle it all, then load it back up again. My world object 
has an attribute defined on it called picklevars, which is basically a 
list of variables to pickle, and my __getstate__ just returns a 
dictionary of those. All other objects are left as-is for now. Zones, 
(the entire zone and all it's rooms) get pickled, as well as players and 
then the world object for persistence. Is this the suggested way of 
doing things? I'll also pickle the HelpManager object, which will 
basically contain a list of helpfiles that can be accessed, along with 
their contents.

Thanks, and appologies for all the questions.

--
Take care,
Ty
http://tds-solutions.net
The aspen project: a barebones light-weight mud engine:
http://code.google.com/p/aspenmud
He that will not reason is a bigot; he that cannot reason is a fool; he that 
dares not reason is a slave.

--
http://mail.python.org/mailman/listinfo/python-list