Andrew Plotkin | 6 Dec 07:41

Re: UI API changes

Discussion around the office is leaning towards:

> A new "ui" namespace for translation tokens.

"yes" on that.

> - Being able to mark more than one seat at a time
> - Multiple kinds of marks (e.g., "attacker" and "defender" in a Cosmic 
> Encounter turn. Or "winner" at the end of a game.)

"yes" on both of those too. However, not an unlimited number of kinds of 
marks. While infinite flexibility would be cool, we're thinking of having 
just a small handful of marks -- types 1, 2, 3, and 4 -- also to be known 
as "the arrow", "the pointy arrow", "the wide arrow", and "the other 
arrow". Or something like that.

Maybe they should be named by strings rather than integers, to provide 
some feeble semantics for their use, but then they'd have to be "turn", 
"win", "steve", and "herman". Since your-turn and you-won are the only two 
semantic roles generalizable across a majority of games. (That I can think 
of.)

(There will be a separate indicator which marks the seat you're sitting 
in. Since that ought to be obvious at a glance. This will be handled by 
the client, not the UI code.)

For the actual API, I expect to use a single polymorphic function:

seatmark()
     all marks off
(Continue reading)

Andrew Plotkin | 6 Dec 19:16

Player resource handling

(That's the "JID resource" I'm talking about -- the tail part of 
a JID like "zarf <at> volity.net/javolin".)

The current player JID rules are designed to make sure that if you get 
disconnected from a game, you can rejoin and keep your place. (This is a 
must-have goal, of course.) The rules are, more or less:

- A given client always uses the same resource. (Javolin always uses 
"Javolin".)

- Players are identified by full JID. (So zarf <at> volity.net/Javolin is 
considered a different player from zarf <at> volity.net/friv. If
zarf <at> volity.net/Javolin is disconnected from the game and then 
zarf <at> volity.net/Javolin joins the game, the referee accepts him as the 
same person and considers him to have retaken his position. If 
zarf <at> volity.net/Javolin is disconnected and then zarf <at> volity.net/friv 
joins, the referee says "Welcome new observer!")

- In the bookkeeper (and nowhere else), players are identified by bare 
JID (excluding the resource). Your player reputation is accumulated from 
all your connections, regardless of what resource strings you used.

These rules are simple and easy to use. However, they disallow the case of 
quitting one client, starting a different client, and rejoining the game. 
(We currently expect to have only one client in common use among players, 
but that could change.)

These rules also grind against some of Jabber's rules:

- When you log into Jabber, you are not guaranteed to get the resource you 
(Continue reading)

Doug Orleans | 6 Dec 21:26
X-Face

Re: Player resource handling

Andrew Plotkin writes:
 > The obvious fix is for the client to use unique resources. (So you join as 
 > "zarf <at> volity.net/jav0175" one time, and "zarf <at> volity.net/jav9742" next 
 > time. The player would never see the resource string, of course -- it's 
 > randomly generated.)

I would like the option of being able to choose a resource, rather
than it always being determined randomly.  Currently, I use different
resources per computer (home, laptop, work) even though all three use
Gaim; this makes it easier to keep track of where each connection is
coming from.  Having these be random numbers out of my control would
be frustrating.  (Not to mention that four random digits probably
isn't enough; there's a 1/10000 chance of collision, which seems
pretty high.)

By the way, can we use priorities here?  E.g. regard priorities lower
than, say, 3 as always being observers?  I haven't thought this
through, just throwing it out there.

--dougo <at> place.org

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
Andrew Plotkin | 6 Dec 23:05

Re: Player resource handling

On Tue, 6 Dec 2005, Doug Orleans wrote:

> Andrew Plotkin writes:
> > The obvious fix is for the client to use unique resources. (So you join as
> > "zarf <at> volity.net/jav0175" one time, and "zarf <at> volity.net/jav9742" next
> > time. The player would never see the resource string, of course -- it's
> > randomly generated.)
>
> I would like the option of being able to choose a resource, rather
> than it always being determined randomly.

I have no problem with that, if you're the sort of user who knows what a 
resource is.

How would that look in the current UI? Adding a "resource" field in the 
login dialog is a mistake, IMHO. But we could accept a username of 
"zarf/resource".

(Should we change the login dialog to have a single JID field, as opposed 
to "host" and "username"? Someone must have asked this before.)

>  (Not to mention that four random digits probably isn't enough; there's 
> a 1/10000 chance of collision, which seems pretty high.)

I wasn't actually going to use four decimal digits.

> By the way, can we use priorities here?  E.g. regard priorities lower 
> than, say, 3 as always being observers?

Priorities don't work on delivery of <iq> packets the same way they do on 
(Continue reading)

Favicon

Re: Player resource handling

On Dec 6, 2005, at 5:05 PM, Andrew Plotkin wrote:

> (Should we change the login dialog to have a single JID field, as  
> opposed to "host" and "username"? Someone must have asked this  
> before.)

Yes, this should probably be changed. I decided a long time ago that,  
in retrospect, it was silly to have done it the way that I did, but  
there was always higher priority work to be done.

--

-- 
                 Karl von Laudermann
                 karlvonl <at> rcn.com
                 http://www.geocities.com/~karlvonl/
                 Richard's PBeM Server ID: karlvonl

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Gmane