It is currently Mon Jan 25, 2021 11:36 pm

All times are UTC




Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 2 posts ] 
Author Message
PostPosted: Thu Jan 04, 2007 7:33 am 
Offline

Joined: Wed May 17, 2006 10:12 pm
Posts: 465
Location: Mead, Wa
Hi folks,

As I mentioned in the 'Live 2' post, from time to time here on the Rehearsal server we will be asking you for specific test case results on various testing scenarios which require more information. We've got one for you, and would much appreciate your feedback. We'd like to nail down the current behavior for the instancing of private and public Ages. As many of you know, Mr. Laxman requested from the explorers on Live an effort to map out the new instancing behavior. Some of the results that initially came in were not according to design (i.e. there are some bugs that we need to fix). We'd like to get these bugs fixed as quickly as possible. Before we can proceed, however, we need some solid data to work with concerning the current behavior on the current build. As you are probably aware, the rehearsal server is some thirty build versions ahead of what is on the Live server.

Now, I know that some of you have already submitted tickets on some of this. Some of those tickets are now logged in our internal database awaiting fixing. I know this because I see every bug in our database. Every one. Including all of the bug reports that have been transferred from the ticketing software. The reason I mention this is so that you can rest assured that any work you may have already submitted is still valid - it didn't get lost or ignored. For instance, it is still helpful to know that currently, linking through the Bahro stone in the Public Garrison incorrectly takes you to the balcony of a Neighborhood that is not necessarily your own. What it is we're asking for is a complete data set from one build. We can piece all of the instancing misbehaviors together from a spread of many many builds, but it's far more valuable to know what is happening on this current build, all at once. This project will hopefully complete that data set and we can tackle this issue and have it all cleaned up as quickly as possible.

What I will post below comes directly (and lovingly) from Design. After that, I will make a few small requests about the format for reporting the issues you'll submit so that we can quickly spot and cherry-pick those tickets and get them to production asap. Here goes:


"A Summary of the Summaries

-----

Book/Stone rule summary:

All the Books’ and Bahro Stones’ behavior should be consistent with
the symbols that they show.

The two symbols they can have are:
1) Yeesha symbol below the linking panel

a) If theYeesha symbol is there, then linking through that Book or
Stone will add a Book to your Relto, or add a page to a Book in your
Relto (i.e. you get a copy of the destination).

b) If the Yeesha symbol is not there, then linking through that Book
or Stone will not add a page or Book to your Relto (i.e. you do not
get a copy of the destination).

2) Share symbol (on the left page of Books, at the bottom-right of a
Bahro stone)

a) If the Share symbol is there, then the Book/Stone (by default)
will link each person who uses it to his/her instance of the
destination. You can "share" the Book/Stone to override this behavior
and allow another player to go to your instance.

(Note: In some cases, Player A’s instance of the destination may be
the same instance as Player B’s. For example, if they’re both members
of the same hood and linking to a “hood” instance of the city, both
players will end up in the same instance of the city (their hood
instance) whether they "share" the link or not. For simplicity, if
you want to be sure another player will go to your instance through a
Book/Stone with the Share symbol, you should "share" the Book/Stone
with them before linking.)

b) if the Share symbol is not there, then anyone who uses that Book/
Stone should automatically link to the same instance of the destination.

---

Sharing summary:

When Player A shares a Yeesha Book or Bahro Stone with Player B,
Player B should always go to the same instance that Player A would
normally go.

---

City Instance summary:

The Nexus should be the only way to get to the "main" city.

All other links should go to a "hood" instance of the city.

There should be no "personal" instance of the city.

---

Examples:

1) The Gahreesen Book in the neighborhood is a “normal” D’ni Linking
Book. It does not have a Yeesha symbol, so it does not give you a
Gahreesen Book in Relto. It does not have a Share symbol, so everyone
who uses that Book goes to that hood's instance of Gahreesen.

2) A "Yeesha" Book will have the Yeesha symbol under the linking
panel. It will add a page or Book to your Relto. It may or may not
have a share symbol, depending on if everyone who uses it will
automatically link to the same instance or not.

3) A Bahro stone will have the Yeesha symbol on it. It will add a
page or Book to your Relto. The Bahro stones may or may not have a
share symbol, depending on if everyone who uses it will
automaticallly link to the same instance or not.


Note to Rehearsal testers:
If there are Books/Stones that aren't following these rules, please
submit a ticket, describing where the Book/Stone is located and how
its current behavior is inconsistent with the expected behavior based
on the current symbols it is displaying.

We'll have to look at each to determine which is broken in each case
(i.e. either a) the symbols are what we want, but the current
behavior is incorrect; or b) the current behavior is what we want,
but the symbols are incorrect).

On this particular issue, it is currently most important that we
quickly ensure that all of the Books/Stones are behaving predictably
based on their symbology. Once that is finished, we will be gradually
addressing which Books'/Stones' behavior can be changed to make it
easier for people to explore together.

Thanks!"


Ok, so when you report the linking and/or instancing issues that are present on the Rehearsal server, please put "INSTANCING FEEDBACK" in the Subject line of the ticket, along with a succinct one-liner about what it is you're reporting. The Customer Support staff will be instructed to process these tickets before any others so that we can get them to Design pronto. When we have all of the data we need on this, and after I've checked off all of the items on my 'Secret Checklist' I will then make another post in this thread letting you know that we have all that we need.

Last but most certainly not least, we're asking that you show your work. Just like your algebra teacher used to make you do. How do you know that you're in the instance you think you're in? I'll give you an excellent example from when Greydragon tested the Public Garrison/Bahro stone link. He and a member of his Neighborhood met in their Neighborhood. He asked that person to remain there while he went to the Public Garrison and linked through the Bahro stone. Upon arrival, he knew he was not on the balcony in his Neighborhood because his neighbor was not on the Age Players List, nor could that person be seen waiting below. Emperical data is critical so that we're not leaving the Tech Team with any doubts as to what we're reporting. Guesses, hunches and 'pretty sures' are nice, but emperical data gets the bug fixed faster.

On behalf of the Design Team and the Quality Control department, I'd like to thank you in advance for your assistance with this urgent request. This is the real meat and potatoes of the process. The good stuff...

8)

GB


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Jan 04, 2007 7:55 pm 
Offline

Joined: Wed May 17, 2006 10:12 pm
Posts: 465
Location: Mead, Wa
Just to clarify:

By 'current build' I mean what is on the Rehearsal server. I suppose I could have been more specific - sorry for the confusion. Right now the Rehearsal server and our internal QC server are the same build (i.e. the current build). Anything you find on the Rehearsal server will be happening on the QC server, so it is much easier for us to verify and pass on for fixing. Anything found on the Live server may or may not still be happening on the QC server (or the Rehearsal server) because it is now thirty builds behind the current build. Many times, a bug that happens on one build won't happen on the next build (or thirty builds later), so this is the reason we want to get these results from the Rehearsal server. We know for a fact that you're finding things that still happen on the current build because you're on the current build.

So for the most part (there can always be exceptions to this) whenever the Rehearsal server is up and active:

Rehearsal server and the QC server = Current build
Live server = Many builds ago

(By the way, the QC and rehearsal servers aren't even the newest 'in-house' build - it's just the most current that is ready for testing, so even you aren't seeing the "Actual Latest")


In general, anything we post in the Rehearsal section asking for help with testing by the Rehearsal testers will mean help with testing on the Rehearsal server. 8)

GB


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 2 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to: