OpenRPG

Greg Copeland wrote:
> 
> #1
> Wanted to point out that we are currently in violation of Active State's
>   licences agreement:
> 
> "Can I redistribute ActivePython to people outside my organization?
> Yes. This is classed as either a commercial or non-commercial
> redistribution, and you must obtain permission from ActiveState. A
> commercial or non-commercial redistribution occurs when you are
> supplying ActivePython to a third party, who is not part of your
> organization. This could either be as part of a product or service that
> you provide or as a separate package to your clients or users who wish
> to use ActivePython.
> 
> Simply providing a link to the ActivePython download page is not classed
> as redistribution, and you do not need permission to establish that link."
> 
> I'm assuming that we currently do not have permission to be
> redistributing Active State's distribution!  That means that we need to
> simply previde the link to their download page or the actual entity to
> be downloaded.

I don't have their distribution on my servers.  Its just a redirect link
to their files.

> 
> #2
> Python 2.1 is considered buggy and should be replaced with Python 2.1.1
> or later.  Active State does have the latest and greatest which can be
> found here:
> http://www.activestate.com/Products/ActivePython/download.plex, where,
> you will find version 2.1.1.212 (Win32/Linux).  I believe this puts it
> in sync with the latest official known stable release .  It is
> recommended that all Python 2.1 users upgrade.  Announcement of such
> should happen on OpenRPG's web site.  I hope one of the developers will
> try this first on Windows to make sure it works well with the wxPython
> libraries without issue.
> 
> The list of associated bug fixes can be found here:
> http://sourceforge.net/project/shownotes.php?release_id=44357.  It's
> pretty long.


I'll think I'm running 2.1.1 on most my machines, so I don't think there
are issues.

> 
> #3
> I was reading through some information on 2.3.x of wxWindows and noted
> that they have started to use the new Python OOR logic.  If memory
> serves, this was added in Python 2.1.  That means, future upgrades of
> wxPython will require everyone upgrade to Python 2.1 or later.  I assume
> that everyone is already running with Python 2.1 or later, but wanted to
> stress that wxPython 2.3.x or later will require this.

Thanks for the info.

-chris

> 
> Greg
> 
> _______________________________________________
> Openrpg-dev mailing list
> Openrpg-dev@...
> https://lists.sourceforge.net/lists/listinfo/openrpg-dev

Comments mixed below:

Chris Davis wrote:

> Greg Copeland wrote:
> 
>>#1
[snip]

>>I'm assuming that we currently do not have permission to be
>>redistributing Active State's distribution!  That means that we need to
>>simply previde the link to their download page or the actual entity to
>>be downloaded.
>>
> 
> I don't have their distribution on my servers.  Its just a redirect link
> to their files.


Excellent!  Such a good boy!  :)  Very glad to hear that.

> 
> 
>>#2
>>Python 2.1 is considered buggy and should be replaced with Python 2.1.1
>>or later.  Active State does have the latest and greatest which can be
[snip]


> I'll think I'm running 2.1.1 on most my machines, so I don't think there
> are issues.
> 


Excellent!  Then may I suggest that we change our download section to 
point to the latest Active State if it's not already doing so.  If it 
is, can we simply change the anchor name to accurately reflect the 
version that is being obtained?  Likewise, if we are not and have not 
been pointing to the latest version, perhaps we can announce the 
recommended upgrade on the homepage.

> 
>>#3
> Thanks for the info.


No problem.

I've started working on documentation again.  Did so last Sunday.  I 
expect to get some more work done on it today following a brief Dr. visit.


Greg

On Friday 26 October 2001 05:45 pm, chris davis wrote:
> I moved Andrews di.py into the dieroller package renamed die.py.  After
> doing some more research last week, I'm gonna start more intensively
> coding on it next week.  I plan to use Andrews base as the roller
> implementation but try to get as close to Travis die roll syntax as
> possible.  I may ultimately use Travis's code to parse the die strings.
>
> -chris
>
> _______________________________________________
> Openrpg-dev mailing list
> Openrpg-dev@...
> https://lists.sourceforge.net/lists/listinfo/openrpg-dev

It might be advantageous to code the implementation of Travis' flags as 
instance methods to d objects.  It would automatically give you their use 
without adding special parsing code.  For example, you can try the following 
with the current die.py:

from dieroller.die import *
eval(convertTheDieString("4d6.ascending().descending()")) 

This corresponds to the general situation where you would have something like 
this:

eval(convertTheDieString(s))

and s would be what the user would actually type.  In this case, the first 
example would correspond to:

4d6.ascending().descending()

What is neat about this is that it demonstrates how "4d6" (when properly 
converted to "{4**d(6))" by convertTheDieString()) represents an instance of 
d and that d.ascending() returns another instance of d.  Because of this 
fact, one can string together various flags (as defined by Travis' doc), 
giving extremely flexible behavior at no additional parsing cost.

In this example, for instance, 4d6 creates a new d object, which then has 
ascending called on it.  Ascending returns a new d object that has the die 
rolls listed in ascending order.  This d object then has descending called on 
it, yielding a new d object with the dice in descending order.

This is a very trivial example.  However here's one from Travis' document:

4d6 take highest 2

The user could get the desired effect by using:

4d6.descending()[:2] 

However, while very Python-centric, it isn't quite as intuitive or easy to 
read.  This can be fixed by adding an instance method to d_base (or d) like 
this:

    def takeHighest(self,num_dice):
        return self.descending()[:num_dice]

Now, the user can simply type:

4d6.takeHighest(2)

Note that the two have the same number of keystrokes and are similarly easy 
to read.

I think you'll find that most of Travis' flags are fairly easy to implement 
as instance methods of d_base.  By itself, this will give you a new dice 
syntax without having to write special parsing code.  

Remember to take advantage of the fact that a d object is a list of dice 
rolls and that adding two d objects together yields a new d object that is 
the concatenation of the two lists.  Whenever possible, return a new d object 
instead of a scalar, as this will allow continued flexibility.

And, of course, If it is decided that an operator syntax for flags, like the 
one described by Travis, is really much better than a method call syntax for 
them, then implementing the flags as instance methods will probably make your 
 parser cleaner to implement anyway.  

-- Andrew

(Random thought:  I would advise finding a different way to re-roll dice than 
actually re-rolling them.  For instance, if a 20-sider has to be re-rolled 
until it is at least an 11, it would be better to simply generate a new 
number between 11 and 20 inclusive once than go through a while loop of 
20-sided rolls until you find one.)

I think this is an interesting idea, but it only works for one server. I
don't know if someone wants to maintain or remember a lot of ids for
various servers.  Hmmm..... but its a good idea.  A global id system
would work better.

-chris


Chris Rouse wrote:
> 
>         I was reading the forum on the openrpg website. I came across a post about
> permIDs in Openrpg. I was about to post that we can't do it. Then the
> thought came to me. What if we are looking at this wrong and a scheme came
> to me. It is rough and we might want to change it. I thought, that this
> might be solvable with the idea of not defining who to keep out but who can
> come in.
> 
>         I think that if we keep a xml file of users that are registered on the
> server on the host machine. The file could contain information like this....
> 
>         <user uid="1" login="crouse" password="mydamnpassword" ip="168.123.2.123"
> />
> 
> .. then it would allow for permID for registered users.. and to keep all
> non-registered users to be able to work with the system since most stuff
> requires a UserID that they can get IDs starting with G... or guest... so
> guest number 115 would be G115. That would mark them as a guest and keep
> them out of all restricted rooms. This  will allow /banned/ players from
> reconnecting and changing there names.
> 
>         Each of the rooms will have the following format :
> 
> <room name="My Room" password="myroompassword" creator="1">
>         <player uid="1" type="allowed" />
>         <player uid="2" type="banned" />
>         <player uid="3" type="moderator" />
> </room>
> 
>         Each of the players in each room can be allowed, banned, or moderator. A
> user id can't be recreated with out the server Admin recreating it... as it
> is on the host machine. So a user can't recreate a user and log on. I am not
> sure that banned is nessecary as they only allow certain players enter the
> rooms. A moderator and creator can kick and /ban/ players from the room. A
> creator can set players as moderators for their rooms. There are things we
> can move on from here like static room on the server that keep this info.
> However, this will come later if this idea flies..
> 
> Chris Rouse
> 
> _______________________________________________
> Openrpg-dev mailing list
> Openrpg-dev@...
> https://lists.sourceforge.net/lists/listinfo/openrpg-dev

Tom, you wrote some nice code. Nice job! But you're not using locks
correctly.  

You are creating a new lock every time you use it.  For the lock to be
effective, you must use the SAME lock object.  Using the a new lock does
nothing.  In your code, you are trying to protect the variable
loaded_images.  So, In theory, you should use the SAME lock object when
writing or reading form that variable.  But in this case, you are using
a thread safe queue in your get_data function and checking it in a
timer, so you don't have a reason to protect load_images.  So you don't
really need those locks.

One other bug.  If you load a map background (not texture), the map size
becomes 300x300.  The reason, I make the map size fit the downloaded
image dimensions when someone choose image background.  The temp image
you use is 300x300.  We need to either reset the map size after the
image is downloaded, or change this logic.  The latter is probably
easier...

-chris


THOMAS BALENO wrote:
> 
> I commited some changes to the image loading code.  I would appreciate someone
> with more skill with threads and queues to take a look at it to make sure I
> didn't do anything stupid.
> 
> Tom Baleno
> 
> ____________________________________________________________________
> Get free e-mail and a permanent address at http://www.amexmail.com/?A=1
> 
> _______________________________________________
> Openrpg-dev mailing list
> Openrpg-dev@...
> https://lists.sourceforge.net/lists/listinfo/openrpg-dev

On Friday 26 October 2001 12:31 pm, Greg Copeland wrote:
> More fodder for the OpenRPG GUI thread.  Check this out:
>
> <http://www-106.ibm.com/developerworks/linux/library/l-anygui/?open&t=grl,l
>=252,p=anygui>
>

Which OpenRPG GUI thread?  Do you mean handling character sheet GUIs or 
moving away from wxPython for the whole project?  If it's the latter, I 
wasn't aware this was under serious consideration.  Maybe I missed those 
posts.  Qt 3.0 does look interesting (if not currently available for Python), 
but moving to ANY other framework may not be worth it unless one is already 
doing a major rewrite or starting from scratch, which I hadn't really heard 
talked about for a very long time.

In terms of the link itself, basically the intent seems to be to create a 
standard Python GUI.  Their scheme to do this is to create a new, single API 
for the user and implement it on top of a number of existing native APIs and 
toolkits.

The somewhat novel thing about this is that they are building upon a more 
sophisticated base of GUI platforms and are thus able to leverage the 
existing works to speed development of backends.

The problem with this particular implementation, however, is that they are 
choosing to follow the Java model of the lowest common denominator.  I know, 
I know, the author tries to say they're not doing this, but then he later 
admits he is.

A better approach would have been to design a KILLER framework with LOTS of 
capabilities and then use existing backends to implement them.  For those 
backends (such as wxWindows and Qt) that already implement a lot of 
functionality, the backend port would be relatively easy.  For simpler 
toolkits, or straight native APIs, the backend port would be a major project. 
In this way the Python community would gain a great GUI framework for less 
work overall.

Of course, it might make even MORE sense to simply spend one's time adopting 
an existing high-level windowing toolkit for C++ and ensuring that it stays 
wrapped in Python and distributed with it like tkinter.

> FYI, I have been able to start working on documentation again...imagine
> that.  I didn't tell anyone, but I'm pretty much recovered from a minor
> surgery that I had.  I've also been traveling less.  Also, I'm starting
> to have a little bit of a social life again, which means I'm starting to
> have extra time again...yaaa...that means more time for OpenRPG!
> Finally.  Of course, there's been some issues which lay on the more
> personal side too which have also prevented me, time and time again,
> from working on this project.  In short, I hope to have a doc (one of
> three -- this one is, by far the biggest) to you guys very
> shortly...take with a grain of salt.  :)

This is great.  I'm glad you're feeling better!  Hobbies are fun, but Life is 
important, so it was good for you to take care of things.  The fact that you 
are able to spend more time reflects that things in Real Life are better 
and I'm glad.

-- Andrew

> Which OpenRPG GUI thread?  Do you mean handling character sheet GUIs or
> moving away from wxPython for the whole project?  If it's the latter, I
> wasn't aware this was under serious consideration.  Maybe I missed those
> posts.  Qt 3.0 does look interesting (if not currently available for Python),
> but moving to ANY other framework may not be worth it unless one is already
> doing a major rewrite or starting from scratch, which I hadn't really heard
> talked about for a very long time.

Yes, there was been some serious talk about moving guis, or alternative
gui solutions.  If I started openrpg today, pyQT would have been my
weapon of choice, but it wasn't even started to my knowledge when I
started openrpg.  I'm not unhappy with wxpython so much as I'm unhappy
with the mac port of wxwindows.  Another think I've also discussed on
the jopenrpg mailing list, is the possibility of encapsulating or
removing all the binary libraries so that openrpg will compile via
jpython to run the java VM.  That way there is no need to do a jopenrpg
per say.

-chris

On Friday 26 October 2001 04:40 pm, chris davis wrote:
> Yes, there was been some serious talk about moving guis, or alternative
> gui solutions.  If I started openrpg today, pyQT would have been my
> weapon of choice, but it wasn't even started to my knowledge when I
> started openrpg.  I'm not unhappy with wxpython so much as I'm unhappy
> with the mac port of wxwindows.  

I thought that, as of 2.3.1, wxWindows was successfully ported to the Mac as 
wxMac, but that there were no wxPython bindings for wxMac.  Are you saying 
that wxMac 2.3.1 isn't good enough to use, even if there were Python bindings?

pyQT is not currently available for Mac.  According to thekompany.com, pyQT 
is currently available for Qt 2.3.1, Free for Unix and Non-Commerical for 
Windows.  The people at the Kompany will have to update their bindings for 
the existing platforms, plus come up with a new one for the Mac before 
OpenRPG could be run on a Mac.

Also, TrollTech has yet to release a Non-Commercial version of Qt 3.0 for 
either Windows or Mac.  I've tried hard to find conclusive information either 
way as to whether this is going to happen, but have been stymied so far.  
Anyone out there know more?

> Another think I've also discussed on
> the jopenrpg mailing list, is the possibility of encapsulating or
> removing all the binary libraries so that openrpg will compile via
> jpython to run the java VM.  That way there is no need to do a jopenrpg
> per say.

I'm confused.  Removing the binary libraries means losing wxWindows, right?  
And then you have to replace it with something that's NOT a binary library.  
What else is there other than AWT or Swing?  And if that's where you are 
going, isn't that in fact what jopenrpg is?


-- Andrew

I was trying to put together a D&D character sheet and I ran into a thought
that might be an interesting addition though I am not sure how to bring it
about. I was thinking that  it would be an interesting feature if we could
add a send button to the grid node. This will allow for you to send a row or
selected rows to chat. In application it would allow you to send things like
Attributes that are use now but while you have the use form open. It would
also further the usefulness of the tabbers by not having to go to the
gametree to send a table or selected rows.

	What are thoughts on this and can it be done easily, or is someone willing
to do it.. =) I would try but I am really bad, for some reason with wxPython
and can't quite figure it out.

Chris Rouse

On Tuesday 23 October 2001 06:59 am, Chris Rouse wrote:
> I was trying to put together a D&D character sheet and I ran into a thought
> that might be an interesting addition though I am not sure how to bring it
> about. I was thinking that  it would be an interesting feature if we could
> add a send button to the grid node. This will allow for you to send a row
> or selected rows to chat. In application it would allow you to send things
> like Attributes that are use now but while you have the use form open. It
> would also further the usefulness of the tabbers by not having to go to the
> gametree to send a table or selected rows.
>
> 	What are thoughts on this and can it be done easily, or is someone willing
> to do it.. =) I would try but I am really bad, for some reason with
> wxPython and can't quite figure it out.
>
> Chris Rouse
>
>
> _______________________________________________
> Openrpg-dev mailing list
> Openrpg-dev@...
> https://lists.sourceforge.net/lists/listinfo/openrpg-dev

Instead of a button, perhaps a right-click menu item or simple cut and paste 
would be a better interface.  


-- Andrew

This really wouldn't be too hard.  You just need to get the selected
rows, and the respective nodehandler(s) (each row has its own
nodehandler) on the onclick event, and then handler.tohtml() to the
chat. 

-chris


Chris Rouse wrote:
> 
>         I was trying to put together a D&D character sheet and I ran into a thought
> that might be an interesting addition though I am not sure how to bring it
> about. I was thinking that  it would be an interesting feature if we could
> add a send button to the grid node. This will allow for you to send a row or
> selected rows to chat. In application it would allow you to send things like
> Attributes that are use now but while you have the use form open. It would
> also further the usefulness of the tabbers by not having to go to the
> gametree to send a table or selected rows.
> 
>         What are thoughts on this and can it be done easily, or is someone willing
> to do it.. =) I would try but I am really bad, for some reason with wxPython
> and can't quite figure it out.
> 
> Chris Rouse
> 
> _______________________________________________
> Openrpg-dev mailing list
> Openrpg-dev@...
> https://lists.sourceforge.net/lists/listinfo/openrpg-dev

> By this, do you mean the website was hacked/defaced, or do you mean that
> people were inappropriately deleting servers from the list?

Hacked/defaced

> 
> >
> > I'm looking for a new poll question for openrpg.com, and suggestions
> > (question and answers).
> 
> I don't know how you would fit it in, but I'm interested in how many people
> use tactical maps and what people who use them think of them.
> 
> Given the right implementation, how often would you use tactical maps?
> 1)  Never
> 2)  Rarely
> 3)  Sometimes
> 4)  Often
> 5)  I NEED them!
> 
> How would you rate OpenRPG's tactical map capability?
> 1)  I told you, I don't use tactical maps.
> 2)  It sucks.  Please make improving it a high priority.
> 3)  It's okay.  Could use major improvements, but better than nothing.
> 4)  It's good.  Can think of some minor improvements, but quite usable.
> 5)  It rocks!  Way better than I'm used to.

I have only room fofr one on the homepage, which do you want to run
first?

> 
> >
> >
> > -chris
> >
> > _______________________________________________
> > Openrpg-dev mailing list
> > Openrpg-dev@...
> > https://lists.sourceforge.net/lists/listinfo/openrpg-dev
> 
> _______________________________________________
> Openrpg-dev mailing list
> Openrpg-dev@...
> https://lists.sourceforge.net/lists/listinfo/openrpg-dev

On Monday 22 October 2001 12:36 pm, Chris Davis wrote:
> > Given the right implementation, how often would you use tactical maps?
> > 1)  Never
> > 2)  Rarely
> > 3)  Sometimes
> > 4)  Often
> > 5)  I NEED them!
> >
> > How would you rate OpenRPG's tactical map capability?
> > 1)  I told you, I don't use tactical maps.
> > 2)  It sucks.  Please make improving it a high priority.
> > 3)  It's okay.  Could use major improvements, but better than nothing.
> > 4)  It's good.  Can think of some minor improvements, but quite usable.
> > 5)  It rocks!  Way better than I'm used to.
>
> I have only room fofr one on the homepage, which do you want to run
> first?
>

The first one.  If you run the second one afterwards, change 1) to just:
1)  I don't use tactical maps.

-- Andrew

THOMAS BALENO wrote:
> 
> I will offer my computer as a secondary if you want.  It's fairly reliable.
> I'm not good with the meta-server stuff though.  I did at one time have it set
> up, but that was before a lot of changes to the meta-server.
> 
> Let me know if you want to work with me and get this set u

What type of linux distro do you have running? say redhat :) jk

This is what you need to run the meta server:

Apache 
w/ PHP
w/ Mysql ecxtentions
Mysql

If you're running redhat, you can get rpms for all of these.  I believe
one for apache, 2 for php, and 3-4 for mysql.  Basically, you need to
install Apache, php, and Mysql and then install the apache extensions
for PHP and Mysql.

If you compile it all from source its a different procedure (but not
very hard).

-chris


> 
> Tom
> 
> Chris Davis <chris@...> wrote:
> > > On a more serious note.  Should we possible work on a way to mirror the
> meta
> > > server so there are at least 2 running.  I know this will be implimented
> in
> > > 'grail' but maybe we should do something in the mean time.
> >
> > We could simply run a backup meta server, and post and remove to both.
> > It would really be a simple matter.  It could easily be encapsulated in
> > the metaserver_lib.py, as I've wrapped all the meta server calls into
> > functions.  Just need to post/remove from two 2 serverin those functions
> > and get the backup meta server list if the first is unreachable.
> >
> > -chris
> 
> ____________________________________________________________________
> Get free e-mail and a permanent address at http://www.amexmail.com/?A=1
> 
> _______________________________________________
> Openrpg-dev mailing list
> Openrpg-dev@...
> https://lists.sourceforge.net/lists/listinfo/openrpg-dev