WorldsAway Development E-mails
Emails taken from the WorldsAway development teams internal mailing lists can be found on this page. For privacy reasons, some information, names or email addresses may be redacted.
BUGFIXES.814.txt
From: "xxxxx xx" <xxxxxx@ossi.com> Date: Mon, 14 Aug 1995 18:40:05 cdt To: ct_team@ossi.com Cc: Subject: (ct_team 1987) CM 1.0b3 release notes Title: Release Notes for Release Version 1.0b3 Author: Garth Minette DocID: reno/unlocked/releases/all.notes.b3 Version: 1.0 Date: 8/14/95 Release Contains: Server, Netserver, World, Resources, Winclient, MacClient. Common Client Changes: BUGFIX: fixed crash during return from prefs dialog before logging in. BUGFIX: (#921) Sped up region transitions a lot by not purging resources that are common to both regions. BUGFIX: (#542/#680)It should now be much easier to select a token carried in your avatar's hand. BUGFIX: (#968) Walking is now much smother. BUGFIX: Avatar correctly holds an object during walking animation. Macintosh Client Changes: CHANGED: sped up menus by 30%. BUGFIX: no longer has problems with spaces in disk volume names. BUGFIX: fixed some minor memory leaks. BUGFIX: cleaned up font. CHANGED: Fixed ESP to match the new ESP mods for Windows. Windows Client Changes: BUGFIX: Other user events are blocked while popup menus are up. BUGFIX: Sped up menus a bit. BUGFIX: Fixed ESP lists. Send To field no longer changes as you get ESP'ed to. CHANGED: Assertion errors no longer give you the option to continue. CHANGES: Popups no longer cause timeouts if they are left up. Server Changes: ADDED: Login time accumalates Tokens. BUGFIX: Fixed banish BUGFIX: Fixed teleporting of other avatars. (Oracle only?) BUGFIX: Changing regions should have avatar only walk on one axis. Network Server Changes: BUGFIX: Fixed crash due to wierd X.25 PAD parameters. Object Class Changes: BUGFIX: Both giver and givee should see appropriate messages when the Give To... command is used. BUGFIX: Avatar's gesture menu should be correct to spec now, including the function key ordering. BUGFIX: Unswapped mad and sad emoticons in the gesture menu. ADDED: Gesture menus now have word names as well as emoticons. BUGFIX: No more zero value tokens. BUGFIX: Pocket dialog title is more correct now. BUGFIX: Wear and Remove ordering fixed in avatar menu. BUGFIX: Try to put an object in a full pocket and you'll get an appropriate message. BUGFIX: Vendroids/head machines/bodychangers should be much cleaner now, and work better. Avatar facing should be correct when using them. Sounds should be correct. Timing should almost match actions. CHANGED: Some of the parrot's comments are now different. CHANGED: 'Tell me about...' on immobile knick-knacks should no longer say that you can pick them up. CHANGED: Fiddle wand now uses different permissions than the dog bit, so people can use fiddle wands without being ESP'ed to because they are acolytes/Oracles/Dog! BUGFIX: Fixed bug where machine seemed to eat all an avatar's tokens. BUGFIX: ESP is now case insensitive. CHANGED: Token accrual is every one hour. ADDED: Amulet can now change an avatar's body to be a buff male or wholesome female. World Database Changes: CHANGED: Individual pieces of art are slightly smaller due to handling flipped artwork. CHANGED: Reprocessed all artwork. ADDED: Added Bar-L Bar to world. BUGFIX: Secured Temple Dungeon a bit. CHANGED: Added Chests to Vendroids. ADDED: Lots of artwork for later addition of new regions.
(ct_dev 5276) Proposed Interverse Open Standard
--------------------------------------------------------------------------------
SUBJECT: (ct_dev 5276) Proposed Interverse Open Standard.
FROM: Norman Morse <dragon@ossi.com>
TO: tony@ossi.com
CC: ct_dev@ossi.com, dragon@ossi.com
DATE: 07/11/1995 19:25
--------------------------------------------------------------------------------
I created this proposal for Tony, I thought others might want
to contribute to the idea also.
Thanks to Mary for bringing this up! :-)
-Norman
------------------------------------------------------------------------
A Proposal for creating an Interverse Open Standard.
Overview:
Interverse technology provides a way for multiple users in
distant places to each share a view of the same "virtual" reality. Each
object in this "cyberspace" has multiple parts, one on the server, and one on
each client. The way these parts communicate is both simple and powerful.
There is a need for a practical protocol like this for many different
internet based applications.
I propose we try to make this protocol a de-facto internet standard by
providing an inexpensive object developers package for non-commercial use.
We also need to create a support network for third party developers, so
they can ask questions, report bugs, and add their extensions to our
"master" interverse distribution.
So, what will we be giving away? A lot. We need to seed the interest
by giving developers complete instructions on how to create their own
Interverse objects. Using the information we distribute, we will be giving
away enough information for others to reverse engineer our client and/or server
(eventually).
What will we be keeping? All our server and client technology. We've
got a lot of rocket-science in our code. It will take a long time for anyone
to match what we've done already. We will tell them how they communicate, but
we will not give them details as to how we've implemented the server and client.
What will we gain?
Developers will create their own micro-worlds, they will debug
and extend our product. They will provide a pool of people with experience
developing objects, worlds and tools which are compatible with ours. They will
provide links to the dreamscape and other Interverse worlds, thereby extending
the Interverse.
How do we do this?
1. Provide liberal license agreements for non-commercial use of Interverse
Technology. Target schools, universities and researchers.
2. Create The object developers toolkit, this should contain:
A. Documentation:
1. "Developers toolkit license agreement".
2. "An overview of Interverse Technology"
3. "Creating Interverse objects"
4. "The Interverse server 'C' API".
5. "The Interverse client 'TCL' API".
6. "Interverse resource format specification".
7. "How to brand your Interverse objects".
B. Restricted Server (10 avatars simultaneously)
C. Windows and Mac Clients
D. "Developers" resource set.
D. Clade, iv_editmethod, rm_update, sunclient and other
development tools
E. Sample source for several objects.
3. Create an "Interverse Developers Network"
All developers receive the object developers toolkit.
Nominal subscription fee ($25/yr?) periodic updates (on CD?)
Provide email technical support. No phone support.
Create "news" group for questions and community building.
Perhaps a compuserve forum, BBS, or in-world
"private region and BBS"
Provide a "bug database" for developers.
IDN members can report bugs.
IDN members can contribute objects and tools to the
"third-party" library.
IDN members can submit extensions to be "branded" as
"Interverse Compatible" these objects will be added
to the "official" Interverse distribution CD
4. Make source code available (at a fee) for non-commercial research
purposes.
5. Co-marketing with Sun is a possibility.
What will it cost?
The documentation we need to create is the same documentation our
Japanese sponsors need. We need to clean up our animation engine and resource
manager to overcome some technical limitations. We need to set up the Developers
Network support and distribution aspects.
I expect that this option is much less expensive than rewriting for 3D or
developing the tools necessary to quickly provide "Custom Worlds" for Content
providers.
This plan allows us to leverage our existing investment for minimal cost, and if
successful, we could see the Interverse standard could be as pervasive as HTML.
Thanks for your consideration.
-Norman
(ct_test 152) Yet more chirstmas art bugs
-------------------------------------------------------------------------------- SUBJECT: (ct_test 152) Yet more chirstmas art bugs FROM: xxx@ossi.com TO: vaserius@ossi.com CC: ct_test@ossi.com DATE: 05/12/1995 14:49 -------------------------------------------------------------------------------- Hi Jeff, Here are additial christmas bugs: 1) With the new female body type, when you turn left and shrug or present, the body faces away from you with the head still facing left, and no gesture animation occurs. If you face RIGHT and shrug or present, the body faces forwards with the head still facing right. 2) The wave is too brief for the new female body type. 3) The Mrs. Claus head has stray white pixels around it.
(ct_team 2610) iv_loginlog
-------------------------------------------------------------------------------- SUBJECT: (ct_team 2610) iv_loginlog FROM: xxx xxx <xxx@ossi.com> TO: ct_team@ossi.com DATE: 14/12/1995 19:15 -------------------------------------------------------------------------------- The Japanese team has asked: > Do you have any program which shows the data in iv_loginlog or calculate > the statistics from iv_loginlog? Do any of you have such a program? Please let me know. Thanks, xxx
(ct_test 162) accessory bugs
-------------------------------------------------------------------------------- SUBJECT: (ct_test 162) accessory bugs FROM: xxx@ossi.com TO: ct_test@ossi.com DATE: 19/12/1995 13:37 -------------------------------------------------------------------------------- To: vaserius From: xxx@loki.ossi.com Subject: accessory bugs Bugs related to individual accessories: 1) The small round glasses are too far back in the side views. 2) The big pipe is is too high by a couple of pixels in the frontal view, and is too far back and high up on the side views. 3) The big round sunglasses are off by one pixel to the left in the frontal view. 4) The bandana is WAY too far back on the side view (approx. 15 pixels). It is also way below the hand when held. 5) The right eye patch is too high in the frontal view. 6) When held, the ascot is far below the hand. 7) The held earrings appear behind the hand when facing sideways. Also, the square earings appear below the hand when held. 8) The big pipe smears or is chopped off when walking left or right. It is also partially chopped off when you turn to face left or right. This also occurs with the pipe and bowtie. 9)The sounds for removing and putting on accessories are strange and seem inappropriate. 10) On the wider heads (for example, the tomato) the flower band does not reach around the entire head, especially in the side views. 11) On the wider heads (for example, the tomato, the glasses do not reach the ears in the frontal view. 12) With some of the heads (for example, the cute girl), the big pipe shows through the shoulder of the muscular male when he is facing away. 13) Virtually all of the hats get chopped off or smear when walking left or right. 14) With the groucho glasses, the bandana around the forehead is broken, allowing the hair to show through. 15) When held, the red flower is positioned away from the hand. 16) The small round glasses are very hard to click on. 17) With the George Burns glasses, the cigar is flaoting in front of the mouth in the side views. 18) For the small round earings, in the rear view they are 1-2 pixels to the left. In the side view, they are 2 to 3 pixels too far back. In the back view for the Roberta head, the left round earring is away from the head and appears to float. 19) There is no animation for putting on an accessory, although there is animation for taking one off. 20) 2nd POV sounds are incorrect for wearing and removing accessories. There is a "foomp" sound for 2nd POV avatars. 21) Almost everything on the cheeze head (hats, nose accessories, mouth accessories) smears or gets cut off when you walk around. 22) The small square earrngs appear to be floating at the shoulder area (all four views). They do not appear to be attached to the ear lobes. More bugs to follow, I'm still compiling everyone's bug lists... -Andrew
(ct_team 2628) Documentation Requirements
--------------------------------------------------------------------------------
SUBJECT: (ct_team 2628) Documentation Requirements
FROM: xxx xxx <xxx@ossi.com>
TO: xxx@ossi.com
CC: ct_team@ossi.com
DATE: 20/12/1995 13:36
--------------------------------------------------------------------------------
Here is a list of what technical documentation I think we need to
produce to support future content providers.
Of course this list needs to be prioritized, but I think I covered
most of the basics.
I am using two new terms:
"domain" is a set of interverse classes and resources which
are intended to work together. Our current domain is "Dreamscape"
Our next domain might be "WebWorld".
"realm" is a set of regions and objects which use a particular "domain".
Multiple worlds may use the same domain, but be described
differently, each of these worlds is "realm".
I did not change the name of many of our utilities (like CLADE and DIRT)
although I imagine we will have to change them soon to make all this work.
Any comments would be appreciated.
------------- Cut Here --------------------------------------------------
**********************************************
Documents for WebWorld and CP package.
**********************************************
Users Manual for Server
Installing and Configuring an Interverse server.
TCP/IP access
X.25 access
Maintaining an Interverse server.
Man pages:
Server
utilities
tlinetsrv
nlinetsrv
The basics of Interverse Technology.
Glossary of terms
Resources
Local storage
Remote update
Messages, Methods, Images, Sounds, etc.
Object Communications Protocol
CUTESI's
Avatar permissions (Oracle, Wizard)
Descriptions of the Basic Classes
Hardware requirements
Creating an Interverse realm.
Selecting Objects
Defining Regions
Using Orb
Using Fiddle
Building a new world
Testing a new world
Interverse programming
Setting up a development environment
Building
Building the server, tools, and netsrv
Building a windows client
Building a mac client
Building the sunclient
When to rebuild client
When to rebuild server
When to remote update
Updating existing objects with orb
Customizing an Interverse Domain
Adding resources with *your* content
Incorporating new images
Art standards
Image Interface standards
Using Dirt
Incorporating new sounds
Hooking new images and sounds into your realm
Debugging and testing
In-world tools
Fiddle
Amulet
Extending an Interverse Domain
Using Clade
Changing a class definition
Changing Behaviors
Methods
Messages
Changing Instance Data
Adding or changing a resource type
Debugging
iv_editmethod
TCL window
Reference Materials
A sample class description with *Comments*
The Clade language reference
Using CUTESI's to represent structures
Client TCL API reference
Server C API reference
Orb TCL API reference
Required messages and methods.
Interverse resource formats
Messages
Methods
Images
Sounds
Man pages
iv_editmethod
rm_update
sunclient
-----------------------------------------------------------------------------
Enjoy!
-xxx
(ct_dev 5650) World-Class, Must Fix Bug
-------------------------------------------------------------------------------- SUBJECT: (ct_dev 5650) World-Class, Must Fix Bug FROM: xxx xxx <xxx@ossi.com> TO: ct_dev@ossi.com DATE: 08/01/1996 22:45 -------------------------------------------------------------------------------- >From owner-ct_dev@ossi.com Mon Jan 8 19:00 PST 1996 >Date: Mon, 8 Jan 1996 19:00:23 -0800 >From: xxx xxx <xxx@ossi.com> >To: ct_dev@ossi.com >Subject: (ct_dev 5642) World-Class, Must Fix Bug > >It seems the character for an invalid character in the WAFONT (most >extended ASCII characters between 138 and 160) looks suspiciously >like an "l". In fact, it looks exactly like an "l", just a pixel >or two shorter. This means that anyone in the world can >impersonate an Acolyte (or an Oracle, but without the robes). > This is not the font table that I based the server font mapper on - some charaters have been changed. Needless to say, a whole bunch of characters are out of sync between the clients and the server. I'll map all these 'l' look-alikes to 'l' for 1.1. We will have to determine if any existing avatar names are colliding. xxx
(ct_team 2670) WA Download Counts (Nov 15,1995 - Jan 8, 1996)
--------------------------------------------------------------------------------
SUBJECT: (ct_team 2670) WA Download Counts (Nov 15,1995 - Jan 8, 1996)
FROM: xxx@ossi.com (xxx xxx)
TO: ct_team@ossi.com
DATE: 08/01/1996 16:09
--------------------------------------------------------------------------------
WA Download Counts
(Nov 15. 1995 @ 1:00 am EST - Jan 8, 1996 @ 1:00 am EST)
WAWIN.EXE WAMAC_2 CD-ROM Orders WAWINDemo WAMacDemo WA Top Menu
Date Download Download Download Download Download Access Count
------ --------- -------- --------- -------- --------- ------------
Nov 15 1 0
Nov 16 300 0
Nov 17 512 0
Nov 18 655 0
Nov 19 837 0
Nov 20 980 0
Nov 21 1066 0
Nov 22 1161 0
Nov 23 1237 0
Nov 24 1372 0
Nov 25 1474 0
Nov 26 1620 0
Nov 27 1716 0
Nov 28 1800 0
Nov 29 1889 0
Nov 30 1956 0
Dec 1 2016 0
Dec 2 n/a 0
Dec 3 n/a 0
Dec 4 2482 0
Dec 5 n/a 0
Dec 6 n/a 0
Dec 7 2733 0
Dec 8 2771 0
Dec 9 n/a 0
Dec 10 n/a 0
Dec 11 2907 0
Dec 12 4503 290
36427
Dec 13 4546 294
38360
Dec 14 4636 305
41836
Dec 15 4720 313
45279
Dec 16 4808 318
49249
Dec 17 4940 331
53416
Dec 18 5034 340
57400
Dec 19 5095 386
60846
Dec 20 5167 389
64090
Dec 21 5227 395 0 67281
Dec 22 5347 n/a 337 71198
Dec 23 5474 n/a 635
75263
Dec 24 5670 404 1018 79455
Dec 25 n/a 467 n/a 83211
Dec 26 n/a 531 n/a 86908
Dec 27 n/a 626 1133 90830
Dec 28 n/a 734 1338 95263
Dec 29 n/a 886 1576 100271
Dec 30 n/a 1103 1871 106147
Dec 31 5734 1312 2193 112424
Jan 1 n/a n/a 2651 n/a
Jan 2 n/a n/a 2825 n/a
Jan 3 6619 n/a 4380 34 37 100713
Jan 4 6817 1 4380 160 76 106150
Jan 5 6984 30 4380 241 95 111014
Jan 6 7128 54 4380 351 116 116197
Jan 7 7326 79 4380 488 133 121740
Jan 8 7498 104 4380 629 155 127234
Note:
1. Anytime one of the servers is down, the count for a particular file may
not be available -- indicated in this report with a "n/a".
2. Due to technicalities, the WA Mac software was unavailable for download
from Nov 15 to Dec 11, thus the "0" download counts.
3. The # on Jan 4 for the Mac download represents the new mac version
"wamac.sea" file.
(ct_dev 5666) Re: Compression in Communication Data
--------------------------------------------------------------------------------
SUBJECT: (ct_dev 5666) Re: Compression in Communication Data
FROM: xxx xxx <xxx@ossi.com>
TO: xxx@fjcug.fujitsu.co.jp, xxx@fjcug.fujitsu.co.jp, xxx@fjcug.fujitsu.co.jp, xxx@fjcug.fujitsu.co.jp, xxx@ossi.com, xxx@ossi.com, xxx@ossi.com, xxx@cyber.mmp.fujitsu.co.jp, xxx@cyber.mmp.fujitsu.co.jp, xxx@ossi.com
CC: ct_dev@ossi.com
DATE: 09/01/1996 17:57
--------------------------------------------------------------------------------
Sorry for the delay in getting this out.
I looked into several alternatives for implementing the comm compression.
We considered implementing it in the server, complex messages in the
client, SV, and also kissfp.
I think the easiest way (though still non-trivial) is to implement it
in the SV layer right before we "escape" the fragment. ("escape" means
to remove any occurances of certain bytes and replace them with
an escape code and the escaped byte or-ed with a mask. This is
used to prevent ^S and ^Q bytes from being sent on the wire.)
The functions that are affected are in sv.c: sv_str_in() and sv_frag_in().
The compression we will use is zero stripping. It will be a function
that is easily changeable. Also, we will have the capability to
support different versions of compression.
The SV header will contain a new flag in the extended_flags field. When
this bit is 1, the data fragment will contain compressed data. When the
flag is 0, the data fragment is not compressed.
SV control fragments will not be compressed.
When fragments are compressed they will reduce in size. When we
fill a compressed fragment, we will not attempt to put more bytes
in the fragment than would fit if the fragment was not compressed.
The reason for this is that on the receiving side we need to umcompress
the fragment into an SV fragment buffer. This is because the fragment
buffer is used throughout the processing of incoming data in the client.
This allows us to reduce buffer copies for performance. As a
result, we need to make sure the uncompressed data will fit in a SV
fragment buffer when received.
A new SV negotiation fragment will be defined. This will negotiate
compression. It will be sent from the client to the netsrv when
compression is enabled in the client. Also included in this
packet will be the version of compression used. If compression is
turned off in the netsrv then the netsrv will respond with a SV negotiate
with compression set to off. This will also disable compression
in the client. If compression is enabled in the netsrv, then the
netsrv will respond with a SV compress negotiate with compression
set on and will use the compression version specified by
the client.
The client will always initiate the SV compression negotiate, and
will never respond to a SV compression negotiate. The netsrv will
never initiate the SV compression negotiate. This will allow
backward compatibility.
There will be a global option on the netwrv to disable compression
for all connections to that netsrv. It will not be possible
to disable compression on a per-connection basis, other than
disabling it in the client.
xxx xxx proposed a zero stripping algorithm that seems acceptable
for this purpose:
00 ==> 00 00
00 00 ==> 00 01
00 00 00 ==> 00 02
AA 00 00 00 00 00 BB CC 00 00 DD 00 EE ==> AA 00 04 BB CC 00 01 DD 00 00 EE
xxx xxx (xxx@ossi.com) proposed a similar algorithm that is a
little more effecient with the single zero case, as long as the single 00
is not followed by a byte with high nibble F. Also, this works
well if the runs of zeros are less than 16.
00 ==> 00 F0
00 00 ==> 00 F1
00 00 00 ==> 00 F2
00 00 00 00 ==> 00 F3
00 01 ==> 00 01
00 01 00 01 ==> 00 01 00 01
00 C6 ==> 00 C6
AA 00 00 00 00 00 BB CC 00 00 DD 00 EE ==> AA 00 F4 BB CC 00 F1 DD 00 EE
00 12 FF 00 00 00 31 00 F0 00 00 00 ==> 00 12 FF 00 F2 31 00 F0 F0 00 F2
00 12 00 32 00 00 00 00 00 00 00 C0 ==> 00 12 00 32 00 F6 C0
However, I would add other examples to the first examples to show
the cases of a 00 followed by a byte with F in the high nibble.
00 F0 => 00 F0 F0
00 F1 => 00 F0 F1
00 F2 => 00 F0 F2
and so on.
In addition, I am going to look at some other compression algorithms
tomorrow.
I am modifying a program I have that extracts bytes from the wire so
that we can do some analysis on the byte patterns in the transmitted
data. I'll code up some quick analysis to find out whether zero stripping
is enough, or we can benefit from generalized RLE.
I'll post the results from this as soon as possible. This should
be done today or tomorrow morning.
I expect that the SV modifications will not take too long. Maybe two
or three days to implement and test. I'm shooting for 1/15.
Let me know if you have any comments.
xxx
(ct_dev 5668) 1.1b5 notes
--------------------------------------------------------------------------------
SUBJECT: (ct_dev 5668) 1.1b5 notes
FROM: xxx@ossi.com (xxx xxx)
TO: xxx@ossi.com
CC: ct_dev@ossi.com
DATE: 10/01/1996 03:14
--------------------------------------------------------------------------------
***Because it's so late, I decided NOT to send this out to ct_team, as
xxx will be here in the morning anyway. The build isn't quite finished yet,
but xxx will be sending out notices when he finishes shortly. Assuming
everything goes correctly, xxx can then send this message to ct_team when
he gets in.***
Thanks to xxx xxx for most of this information
===
The new WorldsAway v1.1b5 is now available for testing.
WorldsAway clients will no longer be distributed via point of contact (POC).
Q/A is no longer distributing disk copies of WorldsAway client software.
Instead of disk based installations, the WorldsAway client software is
available through various methods of network access inside of Fujitsu.
---------------------------------------
For Windows for Workgroups v3.11 users:
The v1.1b4 Windows WorldsAway client is available on the NEXUS
Windows NT server and can be installed directly over the net.
Directions:
1) Launch File Manager.
2) Select 'Connect Network Drive' from the 'Disk' menu.
3) Type in '\\NEXUS\NEXUS' in the box next to 'Path'.
4) Click 'Okay'.
5) Open the WAWIN1_1.B5 directory.
7) Double click on WAWIN.EXE
Note: Once you've setup this network connection, you shouldn't have to set
it up again the next time you use it. Just open that drive again and
install the new software.
--------------------------------------------
For Macintosh users:
The V1.1b5 Mac WorldsAway client is available on 10Forward, xxx's
PowerMac 9500.
Directions:
1) Select 'Chooser' from the Apple menu.
2) Click on 'AppleShare'.
3) Click on AppleTalk Zone 'Phase 2 Zone A'
4) Double click on '10Forward'
5) Connect as Guest
6) Click Okay and you'll get a new drive on your desktop, named 'CM Shared'.
7) Open the 'CM Shared' network drive
8) Open the 'Testing versions' folder.
9) Double click on 'WorldsAway1.1b5 Install'
10) In the installer, drag the WorldsAway icon on top of the disk on which
you want to install.
11) A dialog asks you to "Locate CompuServe Folder...". Find your CompuServe
folder and then click the 'Choose "CompuServe"' button.
Note: Disable any virus checking software you're using. SAM seems to
detect a trojan horse virus when you use the link over the network for some
strange reason even though there isn't any.
================
After you've installed WorldsAway, launch CompuServe and GO FWA24.
Then, double-click on "Wildcard Server........H" to connect to
the 1.1b5 server.
Once you exit the promenade, you will see some of the machines used
for documents. Another one of the new features in this version is Turfs.
In particular, we would like you to test these turfs by visiting the
apartment manager (go left once on Cypress street). The following
description explains all about turfs.
A turf is a region owned by an avatar (or more than one avatar). It's an
area of the Dreamscape that an avatar can call home. An avatar can live
in it, customize it, have visitors, parties, and generally have a place to
feel secure and relax.
For this version, imagine turfs as virtual apartment buildings.
Avatars will be able to rent turfs with single or multiple regions (modeled
as studio apartments or 3 bedroom apartments, for instance).
An apartment complex is a series of regions. A typical apartment building
has a lobby with an elevator and a door to the apartment manager's
office. If you walk into the manager's office, you will find the manager
there at his desk. If you click on the manager, you will get a popup
menu with options like 'Inquire about rentals', 'Rent an Apartment', 'Pay
Rent', and 'Break Lease':
- 'Inquire about rentals': This is actually a pull-right menu with an
entry for each type of apartment available in this complex. You might
select 'Two Bedroom Apartment', for instance, from this menu and be
presented with a dialog detailing the lavish two bedroom apartments this
complex offers, along with the monthly rent.
- 'Rent an Apartment': This is also a pull-right menu with the same
entries as 'Inquire about an Apartment'. Select a type of apartment from
the submenu and you will be presented with a dialog box asking for the name
you'd like the apartment to be under (defaulting to your own name) and
whether you'd like this to be your primary residence. Fill in the entries
and click Okay and you will be charged for the first month's rent. You now
have a turf!
- 'Pay Rent': Use this option to pay for your apartment. You must pay
the rent for your apartment in advance each month or you will not be able to
enter. If, after a certain amount of time, your apartment is still not paid
for, you will be evicted and the apartment will become available for someone
else to rent.
- 'Break Lease': Use this option to break the lease on your apartment.
Your apartment will become vacant and available for someone else to rent.
Once these legal details are taken care of, you may now exit to the lobby
and use the elevator to go to your new apartment. When you click on the
elevator, you will get an option to 'Ride the elevator to...' which is a
pull-right menu that has:
- 'Home': Takes you immediately to your apartment.
- 'Other': Brings up a dialog to let you type in the name of someone's
apartment to go to. You can get to your own by typing in the name you
entered when you initially rented the apartment.
The apartment itself will probably be relatively bare. If you rented that
two bedroom apartment, there may be a common area and two bedrooms (three
regions total). You can move all about inside and between the regions of
your apartment. You'll probably want to buy furniture and decorations from
vendos and bring them up to your apartment to decorate. If you click on the
wall or floor, you'll get a popup menu with your apartment name. One of the
options will be a pull-right menu labelled 'Locale preferences'. The items
on this menu are:
- 'Allow guests in turf': If you select this, other avatars will be
able to enter your turf through the elevator. This does not affect anyone
already in the turf.
- 'Do not allow guests in turf': If you select this, other avatars will
not be able to enter your turf through the elevator.
- 'Allow guests in locale': If you select this, other avatars will be
able to enter this locale.
- 'Do not allow guests in locale': If you select this, other avatars
will not be able to enter this locale. This does not affect guests
currently in the local.
- 'Set maximum avatars in locale': Allows you to set the number of
avatars that can be in this locale at the same time. This can be used, for
instance, to set a room where you want to keep most of the party.
- 'Set maximum ghosts in locale': Allows you to set the number of
ghosts that can be in this locale at the same time.
- 'Remove all guests': Kicks all visitors out of your apartment.
They'll end up in the lobby.
- 'Remove guest': Allows you to kick out a particular (presumably
obnoxious) visitor.
Note that the 'Who's in here?' command on your avatar has been expanded to
tell you all of the avatars anywhere in your apartment.
You can exit the apartment via the door you came in through and you'll end
up back at the lobby.
(ct_dev 5719) 1.1 Beta build tomorrow
-------------------------------------------------------------------------------- SUBJECT: (ct_dev 5719) 1.1 Beta build tomorrow FROM: xxx xxx <xxx@ossi.com> TO: ct_dev@ossi.com DATE: 17/01/1996 21:19 -------------------------------------------------------------------------------- Things are coming together great. xxx has fixed "the" bug, so objects will now actually animate while being held. xxx fixed the foreground overdraw bug. Vaz has set up turfs and an apartment building. The other bugs are dying quickly. So, get the rest of your bug fixes checked in by the meeting tomorrow, because the first Beta build will happen after the meeting. xxx
(ct_team 2720) How to report a WorldsAway problem
-------------------------------------------------------------------------------- SUBJECT: (ct_team 2720) How to report a WorldsAway problem FROM: xxx xxx <xxx@ossi.com> TO: ct_team@ossi.com DATE: 19/01/1996 00:53 -------------------------------------------------------------------------------- Hello all, For the sake of our being able to track problems, calls, bugs, etc. we really need people to report them in the forum, using the form we've provided there (currently message #50805). Yes, even xxx xxx and other people who may send you an email by-passing the forum. If you all could help us in encouraging xxx and any other external people (perhaps your friends, or whomever) to report problems in the forum, we would be very appreciative. If in your travels through WA you experience troubles, it would help us if you too would post those troubles in the forum as a "WorldsAway Member Information Report" (message #50805). It may seem a pain, but it allows us to filter out problems for which we know the answers, and for those that we don't, we have a form to submit to QA which provides all the necessary information. This also allows us (QA) to track numbers of repeats of certain problems and problems which are related. I realize that by a message being sent to ct_dev or other internal mail lists, the information still gets to all of us internally, most importantly to QA. Unfortunately, that same information does not always end up being shared with the many forum members who help solve problems, the remote staff, and the team at CompuServe Customer Service. We've devised a system whereby members experiencing problems fill out the form in the forum. If the forum staff or other forum members are unable to solve the problem, that form is forwarded on to what we call our Tech Support team. The Tech Support team then works with us to help find a solution and help us learn to find those solutions on our own. If the Tech Support team is unable to provide a solution, the problem is posted in ProTeam as a call. QA then determines if the call should be escalated to Bug status and properly assigned. When a resolution to the call or Bug is found, the resolution is passed through the same channels so that all involved (including CompuServe Customer Support) can benefit from the knowledge. Please let me know if you have any questions, and thanks for your support in this matter! -xxx
(ct_team 2721) On-line Services Schedule
-------------------------------------------------------------------------------- SUBJECT: (ct_team 2721) On-line Services Schedule FROM: xxx xxx <74774.1777@compuserve.com> TO: ct_team <ct_team@ossi.com> CC: xxx xxx <xxx@CSI.compuserve.com>, xxx xxx <xxx.xxx@compuserve.com> DATE: 19/01/1996 04:26 -------------------------------------------------------------------------------- Here's the schedule to date. Any additions or changes, please send to xxx@ossi.com. On-Line Services Schedule January 1996, 1.1 Release 01/16 TU 01/18 TH ~ Development meets to discuss current 1.1 release bugs 01/19 FR ~ 1.1 Turfs build (Based on TH approval) 01/20 SA 01/21 SU 01/22 MO ~ 1.0 Server only build (includes accessories fix) ~ MS/QA/CIS begin making files ready for availability, begin testing for corruption or other access problems. ~ Valentine's day remote update to QA 01/23 TU 01/24 WE ~ 1.1 Turfs build on pre-production ~ Beta Test begins (providing QA approves and all necessary CIS setup complete) ~ MS: Need to have page set up for free download of software with alert article for non-beta testers who discover the page. Need to have page set up with direct access to World H which calls client FJWATEST. 01/25 TH 01/26 FR 01/27 SA 01/28 SU 01/29 MO ~ Valentine's day remote update released from QA ~ Valentine's day remote update made available on production server, server down midnight to 1am. 01/30 TU *** Valentine's art available to public via RU *** 01/31 WE 02/01 TH 02/02 FR ~ 1.1b7 Build 02/03 SA 02/04 SU 02/05 MO ~ 1.1b7 Build to QA ~ Misc. art fixes remote update to QA 02/06 TU ~ 1.1b7 released from QA if accepted ~ Pre-production server update to 1.1b7, remote update made available, server downtime midnight to 1am. 02/07 WE *** 1.1b7 release available to tester's via RU *** 02/08 TH 02/09 FR 02/10 SA 02/11 SU 02/12 MO ~ Misc. art fixes remote update released from QA (poss. 02/08) ~ Misc. art fixes remote update made available on production server, server down midnight to 1am. 02/13 TU *** Misc. art fixes available to public via RU *** 02/14 WE 02/15 TH 02/16 FR 02/17 SA 02/18 SU 02/19 MO ~ St. Patrick's day remote update to QA ~ Marketing must have final 1.1 Help files to QA ~ Updated Readme's due to QA with copy to TS ~ 1.1 Turfs released from QA 02/20 TU ~ 1.1 Help files & Readme's from QA to Garth ~ 1.1 Turfs package for release ~ 1.1 Repackaged Client Build 02/21 WE ~ 1.1 Repackage Client to QA and MS and CompuServe QA for preparation for release to public 02/22 TH 02/23 FR 02/24 SA 02/25 SU 02/26 MO ~ Beta Test end ~ MS: Changes to CIS menu pages for file downloads must be complete for testing. ~ St. Patrick's day remote update released from QA: will this include Turfs? ~ St. Patrick's day remote update made available on production server, server down midnight to 1am. 02/27 TU ~ 1.1 Turfs repackaged client available on AWAY and WWW pages 02/28 WE 02/29 TH 03/01 FR 03/02 SA 03/03 SU 03/04 MO ~ Misc. art remote update to QA; New CD's available in CIS Store 03/05 TU 03/06 WE 03/07 TH 03/08 FR 03/09 SA 03/10 SU 03/11 MO ~ Misc. art remote update released from QA ~ Misc. art remote update made available on production server, server down midnight to 1am. ~ 1.1 Turfs repackaged client release masters to production for CD
(ct_test 185) Valentine Art Resources
-------------------------------------------------------------------------------- SUBJECT: (ct_test 185) Valentine Art Resources FROM: xxx@ossi.com TO: ct_test@ossi.com DATE: 23/01/1996 17:44 -------------------------------------------------------------------------------- Heads ----- lace_heart_head 221 candy_1_head 222 candy_2_head 223 candy_3_head 224 jack_of_hearts_head_rep 669 rose_head_rep 670 tulip_head_rep 671 Accessories ----------- head_ponytail 1105 head_backward_cap 1106 head_rose_wreath 1107 nose_glasses 1108 nose_small_square_glasses 1109 nose_winged_glasses 1110 nose_round_glasses 1111 mouth_scarf 1112 Document -------- three_hole_paper 2509 three_hole_pad 2510 bulletin_board_2 2511 bulletin_board_3 2512 envelope_rep 2513 mailbox 2514 scrolls 2515 Turfs ----- plain_wall_5 1629 plain_wall_6 1630 plain_side_3 1631 turf_fireplace 2143 Signs ----- signs 2612 Statues ------- statue_cupid 2811 Boxes ----- heart_shaped_box 2151 heart_box_1 2152 heart_box_2 2153 Valentine 1996 Objects ---------------------- arbor 3300 bouquet 3301 candy_hearts 3302 heart_cookie 3303 heart_candle 3304 heart_gift 3305 heart_wreath 3306 hearts 3307 truffels 3308 hoofprints 3309 toy_train 3310 Magic ----- ornate_staff 2407 ornate_staff_rep 2408 wooden_staff 2409 snake_staff_rep 2410 plain_staff_rep 2411
(ct_test 187) Object causing client crash
-------------------------------------------------------------------------------- SUBJECT: (ct_test 187) Object causing client crash FROM: xxx@ossi.com TO: ct_test@ossi.com DATE: 24/01/1996 13:07 -------------------------------------------------------------------------------- Hi xxx, This does not sound like any bug that we are currently aware of, so reporting it as an official bug is the best way to go. Please provide us with the object's fiddle settings (chore state, etc.) and any other additional details that might be helpful. We will then (after reproducing it in QA world) log the bug into Proteam. >Last night, it was reported to me that the Temple Air Room had become a >black hole. Anyone entering it would barely make it in the room and then >their client would crash. I investigated. > >It turned out it would happen only with a Windows client. Upon entering the >room with a Mac client (thanks xxx for doing this while my direct line to >CIS is *still down*), I noticed a fern knicknack in the far left of the >locale. This was picked up and put in an avatar's pocket. After that, the >problem was resolved. > >Would QA like me to report this as an official bug? It seems like there was >a similar bug at one time, I don't want to heap on extra bug reports which >might get ignored. Let me know how you think can be best handled. > >YELBE >xxx
(ct_dev 5788) Windows bugs fixed.
-------------------------------------------------------------------------------- SUBJECT: (ct_dev 5788) Windows bugs fixed. FROM: xxx@ossi.com (xxx xxx) TO: xxx@ossi.com CC: ct_dev@ossi.com DATE: 25/01/1996 02:28 -------------------------------------------------------------------------------- xxx, These 3 bugs have been fixed. > >[Problems with Win client] > 1) Doc > - Win client does not feed the lines correctly when we re-open a > document. > This problem has not been solved with v1.1b6 yet. > > - Win client erases teh first page, when we click on "Next" and "Prev". > This problem has not been solved with v1.1b6 yet. > > 2) Bind/BBS > - We can not open a Brand new Bind or Pub Bind by "Read". > The mouse pointer remains as the sandglass when we try to read. > Once some folder or document was added by Sun client, it became > able to read by Win client. I could not reproduce this problem. > > - We can not remove pages from Bind > > == TCL Log == > error: invalid command name: > "�$@j]%m%m%m%m%m%m%m%m%m%m%m%m%m%m%m�(JZ�$@n'!+�(JW&F" > xxx.
(ct_team 2745) On-Line Services Schedule
--------------------------------------------------------------------------------
SUBJECT: (ct_team 2745) On-Line Services Schedule
FROM: xxx xxx <xxx@ossi.com>
TO: ct_team@ossi.com
DATE: 25/01/1996 04:37
--------------------------------------------------------------------------------
Here's the schedule to date. _Please_ take the time to read through this
to ensure you are aware of your deadlines and how they affect other's
deadlines. :) Any additions or changes, please send to: xxx@ossi.com.
If you can't stand reading it in this format, let me know and I'll provide
you with a lovely MSWord doc.
Thanks!
On-Line Services Schedule
January - March 1996, 1.1 Release
Note 1, please see xxx's recent email(s) regarding the new version nums.
Note 2, there are three seperate options for testing purposes for the beta
testers. Rather than attempt to give them version numbers, we found it more
understandable to simply lable them as follows:
Option A: The testers will test the ability of a 1.0 client
to connect with the 1.1 server (1 file)
Option B: The testers will test the executable file download
and upgrade of their current 1.0 client to
a 1.1 client (1 file)
Option C: The testers will test the full download and install
of a new 1.1 client (1 win file, 2 mac files)
For public release Options B and C will be made available to the public.
Option A is for testing purposes only.
01/23 TU ~ 1.0.9.2 server only build (CM)
~ Beta Test Option C build (CM)
~ Valentine's art check-in
01/24 WE ~ 1.1b6 build on pre-production
~ 1.0.9.2 server from CM to QA
~ Beta Test Option C from CM to QA
~ Beta Test Option A build (CM)
~ Beta Test Option B build (CM)
~ Valentine's art remote update to QA for testing
01/25 TH ~ Beta Test Option A from CM to QA
~ Beta Test Option B from CM to QA
~ QA places beta test files on ftp site in WAPRE
directory and informs MS and CIS of availability
~ CIS ftp's files and puts in place on CIS servers
~ MS (with assistance of xxx and xxx) finalizes
download abstracts for beta files on CIS. Upon
completion, files are forward to CIS for placement.
~ MS/QA/CIS begin making files and download abstracts
ready for availability.
~ QA/CIS QA: Testing must be completed on
Options A, B & C for FREE access to download,
corruption or other access problems and FREE Test
World access. Notify MS and CIS when approval for
release to testers is given.
01/26 FR ~ Beta Test will begin if QA approves release and all
necessary CIS/MS setup and testing is complete
~ Upon start of Beta Test letter from in-World and
Forum staff will be posted in the forum providing
an update on turfs.
01/27 SA
01/28 SU
01/29 MO ~ Production (??) server update to 1.0.9.2
~ Valentine's art remote update released from QA
~ Valentine's aty remote update made available on
production server, server down midnight to 1am.
01/30 TU *** Valentine's art available to public via RU ***
01/31 WE
02/01 TH
02/02 FR ~ 1.1b7 (1.0.10.2 ??)Build (xxx: I need new version numbers)
02/03 SA
02/04 SU
02/05 MO ~ 1.1b7 Build to QA
~ Misc. art fixes remote update to QA
02/06 TU ~ 1.1b7 released from QA if accepted
~ Pre-production server update to 1.1b7, remote
update made available, server downtime midnight
to 1am.
02/07 WE *** 1.1b7 release available to tester's via RU ***
02/08 TH
02/09 FR
02/10 SA
02/11 SU
02/12 MO ~ St. Patrick's Day art checkin (art will be limited
based on the Art Dept's ability to meet this date)
~ Misc. art fixes remote update released from QA
(poss. 02/08 if approved in time)
~ Misc. art fixes remote update made available on
production server, server down midnight to 1am.
02/13 TU *** Misc. art fixes available to public via RU ***
~ St. Patrick's Day remote update from CM to QA
to include in 1.1 final packaging for release to public.
02/14 WE
02/15 TH
02/16 FR
02/17 SA
02/18 SU
02/19 MO ~ Marketing must have final 1.1 Help files to QA
~ Updated Readme's due to QA with copy to TS
~ 1.1 released from QA
02/20 TU ~ 1.1 Help files & Readme's from QA to Garth
~ 1.1 packaged for release
~ 1.1 Repackaged Client Build (this will include
all 1.1 upgrades and bug fixes as well as all remote
updates up through St. Patrick's art)
02/21 WE ~ 1.1 Repackage Client to QA and MS and
CompuServe QA for preparation for release to
public. Simultaneous preparation begins. Files will
not be made available to the public until final
approval given by QA.
02/22 TH
02/23 FR
02/24 SA
02/25 SU
02/26 MO ~ Beta Test end
~ MS: Changes to CIS menu pages for file downloads
must be complete for testing.
~ Remote update originally planned for St. Pat's art
but moved up to include in final package. Any need
still for this remote update?
~ After MIDNIGHT, Production server changed to 1.1
server. (Members with 1.0 will still be able to connect.)
02/27 TU ~ 1.1 repackaged client available on AWAY
and WWW pages after midnight.
02/28 WE
02/29 TH
03/01 FR
03/02 SA
03/03 SU
03/04 MO ~ Misc. art remote update to QA; New CD's
available in CIS Store
03/05 TU
03/06 WE
03/07 TH
03/08 FR
03/09 SA
03/10 SU
03/11 MO ~ Misc. art remote update released from QA
~ Misc. art remote update made available on
production server, server down midnight to 1am.
~ 1.1 Turfs repackaged client release masters to
production for CD
(ct_dev 5817) Remote update problems
-------------------------------------------------------------------------------- SUBJECT: (ct_dev 5817) Remote update problems FROM: xxx xxx <xxx@ossi.com> TO: ct_dev@ossi.com DATE: 30/01/1996 13:43 -------------------------------------------------------------------------------- QA is blocked on the remote update problem. From talking to xxx it seems as though remote update for the new artwork is just simply not working. It works fine if he copies the mag files from the server to the client and runs. (Which is probably how all us guys tested this.) However, if he **remote updates** the resources then the new art crashes the client. Also one of the NEW cdxxx.dat files is smaller than the file in the mag dir on the server. What's the deal? We need someone to dump the resources and see what the differences between the resources on the server and client are *after* the remote update. Can rm_update could do this? Who can track this down? xxx
(ct_team 2773) WA Daily On-Line Rpts 1/24 & 1/25
--------------------------------------------------------------------------------
SUBJECT: (ct_team 2773) WA Daily On-Line Rpts 1/24 & 1/25
FROM: xxx@ossi.com (xxx xxx)
TO: ct_team@ossi.com
DATE: 30/01/1996 17:16
--------------------------------------------------------------------------------
I am re-sending these two days from last week because after re-running them
- the figures look better. I will post the rest from last week as they
become available.
xxx
______________________________________________________________________________
Wednesday: Jan 24, 1996 : Daily WorldsAway On-Line Report
--------------------------------- ------------ ------------- ------------
Category Wednesday Month To Date Last Month
01/24/96 January December
================================= ============ ============= ============
Total Connect Time (Hours) 1792.500 47439.483 48840.050
Total Logins (Sessions) 2277.000 60412.000 56818.000
Total Unique Accounts 961.000 6215.000 5709.000
Average Time per Account (Hours) 1.865 7.633 8.555
Average # of Logins per Account 2.369 9.720 9.952
Peak Simultaneous Accounts 156.000 189.000 156.000
Peak Simultaneous Avatars 159.000 191.000 156.000
Total New Accounts 102.000 3498.000 3772.000
# of Accts that Haven't Returned 351.000 2684.000 898.000
------------------------------------- ------
Total WA On-line Membership To-Date: 10315
----------------------------------- ------
Total # of Unique Avatars To-Date: 13430
____________________________________________________________________
Thursday: Jan 25, 1996 : Daily WorldsAway On-Line Report
--------------------------------- ------------ ------------- ------------
Category Thursday Month To Date Last Month
01/25/96 January December
================================= ============ ============= ============
Total Connect Time (Hours) 1767.517 49207.000 48840.050
Total Logins (Sessions) 2260.000 62672.000 56818.000
Total Unique Accounts 971.000 6345.000 5709.000
Average Time per Account (Hours) 1.820 7.755 8.555
Average # of Logins per Account 2.327 9.877 9.952
Peak Simultaneous Accounts 159.000 189.000 156.000
Peak Simultaneous Avatars 159.000 191.000 156.000
Total New Accounts 114.000 3612.000 3772.000
# of Accts that Haven't Returned 403.000 2668.000 898.000
------------------------------------- ------
Total WA On-line Membership To-Date: 10423
----------------------------------- ------
Total # of Unique Avatars To-Date: 13572
____________________________________________________________________
Contact Information:
xxx xxx
xxx@ossi.com
(wa_tech 98) fyi: known problem in-world
-------------------------------------------------------------------------------- SUBJECT: (wa_tech 98) fyi: known problem in-world FROM: xxx xxx <xxx.xxx@compuserve.com> TO: wa_tech, INTERNET:WA_TECH@OSSI.COM DATE: 02/03/1996 17:10 -------------------------------------------------------------------------------- FYI... I believe this information has gone out before, but I wanted to make sure everyone knew, so here it is in very non-technical terms: There is a known intermittent bug whereby if someone attempts to ESP someone who is engaged in a remote update, this will cause almost all ESP's to hang until that remote update is completed. Basically what happens is that the one ESP to the person doing the remote update causes a blockage on the server so that no other ESP's can go through. Usually, once the RU is finished the first and then all consecutive ESP's go through and the problem fixes itself. With the recent long RU of new information, we find that the chances of this problem occuring is increased, especially mulitple consecutive occurances of the same problem (I.e. three different people who ESP someone in RU and ESP's backing up). Say user A tries to ESP user B who is doing a remote update. A's ESP is held for delivery when the RU is complete. User C ESP's user X, but because of the hold on user A's ESP's all other consecutive ESP's are held. Now, normally, user B finishes RU and the problem clears itself. What we are currently experiencing, however, is 1) lotso people in world and therefore 2) lotso people experiencing remote update plus 3) lotso people ESPing. All those ESP's get backed up, the clients can't take the wait, they think they've lost connection to the host and BOOM, they crash out of WA. Then they come running to the forum thinking the server is down. In actuality, the server never crashes, plenty of people are still in, they're probably just not interacting via ESP or if they are, have unknowingly timed it in such a manner that they aren't caught up in the dominoe effect of the problem. Ok, so then the person who crashes tries to get back in world but cannot. They are experiencing one of two problems. Either 1) the server has not yet recognized that the user is no longer there (they probably have their WA timeout set infinately) thus thinks they are still in-World or 2) all the previously explained problems start causing other problems like with the connections. One other potential problem I saw was that when CIM attempted to launched the client on the user's computer, it was able to launch, but the connection to WA simply isn't made - the user never sees the avatar selection menu. Everything you see here is basically what we experienced today. We had to completely restart the World just to reset all the connection lines and the server then everyone could again get in world. It's likely that until the server fix is approved by QA and released we will continue to see this very same problem occur again and again. We need to keep a close eye on the world until that fix has been put in place. The fix for the ESP/Remote update bug has been checked in by development and is now in Quality Assurance. As soon as QA has approved the release of this fix, the current server will be updated. We are hoping to have the server updated on Monday, but that all depends on QA, so don't quote any dates to anyone. Understanding this problem is especially important this weekend, as we just provided new art on Thursday night and everyone entering the world is going through a remote update. We had to take down the world today at 1pm due to this very same problem. I was in the Help Desk helping people out as much as possible, and explaining to them what happened and how they can help us avoid this problem until the fix is put in place. xxx will be posting a message in the Help Desk telling the same. Please when talking to members who've experienced this problem, refer to the message that xxx posts. It's amazing how much time a problem like this eats up! I can't wait for that darned fix! :-) If anyone who receives this message is in the World or forum and recognizes that this is happening, please contact Member Support immediately on our pager x-xxx-xxx-xxxx. xxx is working until at least 10:30 tonight and xxx tomorrow 1:30 - 10:30. Any time other than that you can page me. The sooner we find out that it's happening the sooner we can fix things. Today, people were locked out of the world for over an hour, and the time was only that shorty because I happen to walk into the forum. Thanks, -xxx
(ct_team 2835) This week in engineering: WebWorlds
-------------------------------------------------------------------------------- SUBJECT: (ct_team 2835) This week in engineering: WebWorlds FROM: xxx@ossi.com (xxx xxx) TO: ct_team@ossi.com DATE: 09/02/1996 19:08 -------------------------------------------------------------------------------- Note: The following is company confidential. (As always. :-) Here's a window into some of the toil and excitement in engineering: Turfs went to external testers at the beginning of the week. Early reports are very positive. xxx demonstrated his Game api prototype this week, leading design reviews for both engineering and producers/product managers. There's work to be done, but the prototype demonstrated an api for use in those worlds and/or those locales set by world producers for the the Wert Gumby's of the world to hack games that WorldsAway avatars can play, and for approved games to be attached to in-world objects (a mini-tic-tac-toe or mini-chess board on the wall of a locale, for example, that avatars could play either directly or via a second window but that all avatars in the locale could watch). Very cool. Major kudos to xxx (and to all his advisors). xxx succeeded in attaching the Windows WA client and a web browser, via a third party DLL/window. In his prototype, the WA client can change the web browser's page. This was a critical test of our product basis of having a world browser and a web browser that work in tandem. Imagine browsing the web to a page that has a world map on it, selecting a region, which sends a message to the world browser and lets your avatar enter this world at that spot. Later, wandering through the world, you ask "where am I", which sends a message to the web browser, flips it back to the map page, executes a CGI script hidden behind the page, which causes an X to flash in the locale you're in... Now xxx's on the spot to write CT code to replace the essential-to-us aspects of the third-party DLL. xxx also released to QA a DLL to support the widely used Trumpet WinSocket. The plan, if QA and Member Support agree, is to give it to those hardy souls who've tried to use Trumpet, and with their assurance that it lets them get onto WA successfully, to put the DLL on the Forum for availability to Trumpet users. We brought on another Mac engineer for perhaps a month to help us get TCP (WebWorld) support into our Mac client. xxx xxx is sitting across the hall from me, next to xxx xxx. All the engineers did lots more work, but one thing I think will interest everyone: Engineering this week scheduled the tasks that will get us to a WebWorld prototype. The result is that we've made a good initial cut at what we can engineer for a March 31 release and what will have to wait for a subsequent release. The results: What's in Jupiter Conference demo: Windows only World map that's on web side that can show where you are in the World Web page can launch World, enter at specified World entry point Avatar URL can change web page Oracles can edit avatar/object URLs using fiddle [This is where we test interoperability of Netscape and World browsers in 8 megs] What's in 1.2 (engineering of functionality complete by end of February): Mac and Windows Elevator (and follow thru elevator) Design for Auditorium, but no Auditorium Design for web-friendly installation, but implementation doubtful Avatars are not registered (not kept track of by server), but are persistent (Client saves prefs: avatar body, head, color, name) Initial avatar: First use of Client (i.e., no avatar ever): dialog prompts for gender Web side picks random avatar body/head/colors Give ghosts access to web-page URL menus Pass Web-selected ID to server # of avatars/account: make build constant external so it can be used at startup WebFollow: add Web following command; user-to-group communication to share a web URL Email address and text description that are part of the Tell-Me-About Be able to set certain locales to block URL opening All client support for the Game api (though server support won't be ready at launch) There's considerable UI work to be designed. Among others, imagine having a Follow URL menu off your avatar that anyone can use at any time to see what you're looking at with your web browser. Hmmm... What probably must wait until the next version of WebWorld: Auditorium Performance: Incorporate Netserve into IV serve / Remove S&V / ESP to user task Web URLs object for sharing purposes via opaque data channel Per-world preferences (required for multiple WebWorlds) User performance: request not to get picture images Incremental Remote Update Velcro Avatar death: WWmaster can set # of days; 0=no persistence Applause meter Avatar mod to indicate to others that your avatar is off reading the web (web browser is focus) Sound compression Toolbar Picture Object Long URLs And while this news is now a week old, xxx xxx a week ago completed spraycans for apartment walls and such -- his first completed object as a development engineer. Yay, xxx! - xxx
(ct_dev 5964) New Document Server
-------------------------------------------------------------------------------- SUBJECT: (ct_dev 5964) New Document Server FROM: xxx xxx <xxx@ossi.com> TO: ct_dev@ossi.com CC: xxx@ossi.com, xxx@pobox.com DATE: 12/02/1996 14:28 -------------------------------------------------------------------------------- I've got the latest document stuff running on tao:8025 and on compuserve FTBTST. Resources are in tao:/opt/renobuild/mag It should have remote updateable resources from the previous server running on tao and FTBTST. BBS is much changed. You need a writeable document in your hand to post. You need to be an oracle or above to make folders or remove posts. Feel free to check it out. I'll be checking in these changes today. -xxx
(ct_team 2849) On-Line Services Schedule
-------------------------------------------------------------------------------- SUBJECT: (ct_team 2849) On-Line Services Schedule FROM: xxx xxx <xxx.xxx@compuserve.com> TO: ct_team <ct_team@ossi.com> CC: xxx xxx <xxx.xxx@compuserve.com> DATE: 13/02/1996 05:31 -------------------------------------------------------------------------------- Here's the schedule as of 02/12/96. Any additions or changes, please send to xxx@ossi.com. On-Line Services Schedule February - March 1996, 1.0 Repackage, Turfs & 1.1 Testing & Release Notes: BETA PLANNING: Please note that the beta test has begun, but started with only Option A. Options B & C will be implemented when they have passed QA. Proposed dates are given in the schedule below. Due to the problems found in the test versions, we had to delay the start of beta by 11 days. The end date of beta, 02/26/96, is planned to remain the same unless we find substantial reason to delay the date. Unfortunately this means that the amount of time for testing is decreased, the potential for bugs to be released to the public and/or the potential further delay of the release of Turfs is increased. BETA OPTIONS: Option A tests the ability of a 1.0 client to connect with the 1.1 server, simulating a user who does not download the patch file with client upgrades and bug fixes. Option B is the patch file to upgrade the users current 1.0 client with new client fixes, Option C is a full download of the 1.0 client including these latest client fixes. VERSION NUMBERS: Just a reminder that the current numbering scheme for client and server releases is as follows: ~ Three digits for client releases where the first two numbers are the version number and the third is the client number. ~ Four digits for server releases where the first two numbers are the version number, the third is the client number, and the fourth is the resource number. REMOTE UPDATES: Our current Dreamscape plan is for server and art/resource updates on alternate weeks, with a remote update every week. Even if the updates are small, this provides an opportunity for the members to become used to these remote updates on a regular basis. REPACKAGED CLIENTS: Our current Dreamscape plan allows for repackaging the current publicly available client once a month. Should it become necessary for a new user who has just downloaded the client to sit through a remote update in excess of 5 minutes, we will assess whether a newly packaged client will be made available sooner. HELP FILES & READMES: For the repackaged client, please note that due dates have changed. xxx mentioned that there may be a dependency for work on the Macintosh files by xxx xxx. Please let me know so that time can be allowed for in the schedule. WEBWORLD: I have added in some delivery dates for WebWorld as these dates impact the Dreamscape deliverables, and most of us need to do some sort of planning. Please check these dates and let me know the dependencies for your department if they have not been appropriately noted. 02/06 TU ~ BEGIN Opt. A External Test ~ CM: Opt. B & C client and server build for external test, to QA. 02/07 WE ~ Trumpet DLL Build, to QA 02/08 TH 1.0 to 1.1b7 Patches (Test Opt. B) from CM to QA 02/09 FR ~ Wildcard (test) server update to 1.1b7 server, remote update made available to testers. 02/10 SA 02/11 SU 02/12 MO 02/13 TU ~ QA: Trumpet DLL fix to selected Dreamscape members for external testing overseen by xxx. ~ QA: Proposed date for 1.0 to 1.1 database conversion ready to test. (Dependent on DEV) ~ DEV/ART/WB/VAZ: Last chance for bug fixes to be checked in if they are to be included in the 1.0 Repackaged client. 02/14 WE ~ Build Meeting: may effect all dates seen in this schedule! :-) ~ CM: Opt B & C External Test client build ~ QA: Proposed date for 1.0 to 1.1 database conversion testing. (Dependent on TUES date) ~ ART: Mktg WW Jupiter Conference brochure art to processors. 02/15 TH ~ 1.1 Client build from CM to QA and Japan simultaneously. ~ QA: Receives Opt B & C client builds ~ QA: place Opt B & C on FTP site for CIS QA/ISD ~ MS: Changes to CIS external testing menu pages for file downloads, and file abstracts must be complete for testing. ~ QA/MS: Opt B & C simultaneous testing by FCT QA & CIS QA/ISD ~ QA: Proposed date for 1.0 to 1.1 database conversion available to testers on Wildcard server. (Dependent on TUES date) ~ ART: WW Demo world art checkin. 02/16 FR ~ QA/MS: Opt. B & C download tests from CIS for corruption in transfer process. ~ MKTG: final revised 1.0 Help file and CD Readme due. Please note that these files should be turned in to QA, not CM, to allow QA 48 hours for review. ~ MS: Updated Readme's due to QA with copy to TS ~ QA: Deadline for decision to be made if current Ext. Test Opt. A is ok to go to the public. If yes, great! then on 2/26 server will be changed and members will experience a short remote update. If no, there are three possible problem scenarios: 1) bug fixes are necessary 2) a new server build is necessary or 3) new server packaging is necessary. If 1) we will not meet 02/26 release date. If 2) build would be 2/19 to QA for testing 02/20. If 3) repackage would be 2/19 to QA for testing 2/20. ~ ART: WW Demo world art, simultaneous processing and world building 02/16,19,20. This is under the assumption that our new World Builders can build one locale per day. 02/17 SA 02/18 SU 02/19 MO ~ QA/MS: Proposed date of Opt B & C External Test begin. This date may change to Tuesday if Monday is a holiday for CompuServe employees. (QA needs at least four weeks for external testing.) 02/20 TU ~ QA/CM: Revised 1.0 Help files & Readme's from QA to CM for inclusion in 1.0 repackaging ~ 1.0 Repackaged Client Build ~ ART: Begin completing WW 1.2 art. 02/21 WE ~ 1.0 Repackage Client to FCT QA & MS and CompuServe ISD & QA for preparation for release to the public. ~ ART/QA: WW Demo world art to QA for testing 02/21,22,23 02/22 TH ~ ART: WW 1.2 art due, having completed processing and world building. Based on the other current WW art dependencies and due dates, this date is impossible to meet and needs to be reassessed. A more realistic date would be 02/29 for the processing to begin. Realistically, a minimum of 152 hours are needed for creation, 52 hours are needed for processing, and 26 days needed for world building. Hopefully world building can begin while processing and possibly even art are being completed. 02/23 FR ~ QA: ~ ART: WW Demo world art must be approved to meet 02/26 deadline of Jupiter Conference for private demos. 02/24 SA 02/25 SU 02/26 MO ~ Opt. A External Test end ~ OPS: Midnight, server update to new server with turfs accessibility (1.1.6.1 ?). 02/27 TU ~ *** TURFS AVAILABLE TO THE PUBLIC *** This is a proposed date only. Schedule subject to change. ~ 1.0 Repackaged client available on AWAY and WWW pages. The repackaged client includes all remote updates, bug fixes and changes made available by February 13. Delay of release of Turfs may effect this release date, depending on the current remote update time estimates. ~ MKTG/QA: Repackaged 1.0 Client CD Masters & Diskette Masters available for testing. QA needs two weeks for testing. 02/28 WE 02/29 TH 03/01 FR 03/02 SA 03/03 SU 03/04 MO 03/05 TU 03/06 WE 03/07 TH 03/08 FR 03/09 SA 03/10 SU 03/11 MO MKTG: Repackaged 1.0 Client CD's & Diskettes available in CIS Store based on 2/27 delivery of Turfs and if CD approved by FCT QA. 03/19 TU 1.1 Release?
(ct_dev 5985) saving items in the world
-------------------------------------------------------------------------------- SUBJECT: (ct_dev 5985) saving items in the world FROM: xxx@ossi.com (xxx xxx) TO: xxx@ossi.com CC: xxx@ossi.com, xxx@ossi.com, xxx@ossi.com, ct_dev@ossi.com DATE: 13/02/1996 21:38 -------------------------------------------------------------------------------- xxx, Perhaps this has been discussed before, but just in case not, I'm bringing it up anyway. Would it be possible to implement a way that should the user experience an unexpected disconnect from WorldsAway while in a private room with their belongings out of their pockets, that upon re-entry their avatar would return to that private room and no other avatar would be able to enter the room for a set period of time? I'm suggesting the "set period of time" to discourage members causing a disconnect to happen on purpose for whatever odd reason. Also, to allow the member time to attempt to re-enter the world and reclaim their belongings, or should that be impossible, at least enter the forum or call CIS CS if they just can't get in. Just a thought. Might save us some neck pains in the future.
(ct_team 2864) Dust off your bowling ball
-------------------------------------------------------------------------------- SUBJECT: (ct_team 2864) Dust off your bowling ball FROM: xxx@ossi.com (xxx xxx) TO: ct_team@ossi.com DATE: 13/02/1996 22:48 -------------------------------------------------------------------------------- Attention athletes! We are having a bowling night on Friday, Feb. 23. All are welcome. I will give details as they get arranged. I'd appreciate an "I'm interested" count. BTW, If anyone has a favorite alley (bowling) in this area let me know and I'll check it out to see if it meets the standards of our group. ie: easy to find, parking ok, maybe food'n beer, etc. p.s. even if you don't bowl, like I don't, why not come anyway? It's a chance to throw big objects at small objects and hear them go 'boom'! This is my official signature
(ct_checkin 386) document checkins
--------------------------------------------------------------------------------
SUBJECT: (ct_checkin 386) document checkins
FROM: xxx xxx <xxx@ossi.com>
TO: ct_checkin@ossi.com
DATE: 14/02/1996 02:14
--------------------------------------------------------------------------------
OVERVIEW:
Added economics to document classes, and cleaned up document
orientation when changing location.
RELEASE:
1.1
FIXED BUGS:
No longer get "Could not change orientation" errors.
NEW FEATURES:
You get charged for making copies and buying newspapers.
CAVEATs:
The recycler has its default costs in, but I couldn't find
a checked-in spec to find exactly what it was supposed to
do when.
While there is some visible animation, not all of the document
orientation-changing commands are in yet, nor is the associated
avatar animation. (I'd like some Oracular feedback as to whether
the avatar animation is wanted.) As it becomes clear where these
belong, they'll be added. However, the correct animation is
happening most of the time, it's just not exciting.
2POV sucks.
I tested newsstand economics as much as possible, but I've
never actually been able to buy a newspaper, so it hasn't been
tested all the way through.
CHANGED FILES:
Filename New Version Summary of Changes
-------- ----------- ------------------
avatar.cld 1.174 cleaned up changing document orientation
document.cld 1.41 cleaned up changing orientation
generics.cld 1.223 cleaned up changing document orientation
gutenberg.cld 1.14 added economics
newsstand.cld 1.10 added economics
postbox.cld 1.10 changed cost field to common
recycler.cld 1.11 added some economics
xxx
(ct_checkin 387) Orb fixes, odb_check fixes, 1.0 -> 1.1 convert support
-------------------------------------------------------------------------------- SUBJECT: (ct_checkin 387) Orb fixes, odb_check fixes, 1.0 -> 1.1 convert support FROM: xxx xxx <xxx@ossi.com> TO: ct_checkin@ossi.com DATE: 14/02/1996 04:58 -------------------------------------------------------------------------------- OVERVIEW: Convert 1.0 database to 1.1 add turfs to converted 1.1 database. FIXED BUGS: NEW FEATURES: PERFORMANCE IMPROVEMENTS: CAVEATs: Turfs in this version expire after 5 or ten minutes. I'm concerned that the current floor plans will need changing. If they do, we should do it BEFORE we convert the db. I don't have the tools handy to remove prototype turfs from the db. I suppose we could easily add more. I didn't make the region groups. We do have a test version of region groups but we should do something a little more detailed, like getting the fountain regions in proper region groups. See seperate message on how to use these files to convert the db from 1.0 to 1.1 We need to do a small 1.0 build to upgrade orb for 1.0 so we can do the right kinda dump. xxx, for 1.0: In server/tools/Orb dir we need to make and make install. The new orb and orb.etc needs to get installed in the bin dir where we plan to do the 1.0 dump. The orbdump.tcl and dumpbyclass.tcl will go into orb.etc. For 1.1, we need to: make, make install in server/lib/libiv_instance make, make install in server/tools/Orb make clean, make all, make install in world. The above may be moot if this is part of your thursday build. FWIW, I did convert the 1.0 to 1.1 db, and actually got a server running with it, and actually got a windows client connected. Went in, went to the apt mgr and bought a 4 room turf. CHANGED FILES: Filename New Version Summary of Changes -------- ----------- ------------------ =============== 1.0 FILES.... ONE POINT ZERO VERSION FILES ============ /server/tools/Orb/Makefile 1.2 add dumpbyclass.tcl install line /server/tools/Orb/orbdump.c 1.2 support dump by class /server/tools/Orb/orbdump.tcl 1.2 dump contents now, exclude fields on teleport dumps /server/tools/Orb/dumpbyclass.tcl NEW (dumps objects by class.) =============== 1.1 FILES.... ONE POINT ONE VERSION FILES ============ /server/include/iv_instance.h 1.13 add option to restore w/o doing containership /server/lib/libiv_instance/iv_instance.c 1.44 ditto /server/tools/Orb/Makefile 1.28 fix tcl install cmds, add dumpbyclass /server/tools/Orb/fullrestore.tcl 1.2 add objref fixup to restore /server/tools/Orb/orb.c 1.38 add objref fixup to restore /server/tools/Orb/orbdump.c 1.18 support dump by class /server/tools/Orb/orbdump.tcl 1.10 dump contents now /server/tools/Orb/register_region.awk 1.2 slightly different syntax in 1.1 /server/tools/odb/odb_check.c 1.26 support big databases /world/Makefile 1.26 register_teleports.tcl is now static /world/regions/turfs.reg 1.7 fix OrchidTemple linking /world/test_turfs.tcl 1.7 number regions correctly /world/world.tcl 1.102 empty high region is back to 372 /world/world3.rmt turfs protos are at 400 /world/register_teleports.tcl NEW registers the teleport aliases /server/tools/Orb/dumpbyclass.tcl NEW dumps objs by class
(ct_dev 5986) 1.0 to 1.1 db conversion procedure
-------------------------------------------------------------------------------- SUBJECT: (ct_dev 5986) 1.0 to 1.1 db conversion procedure FROM: xxx xxx <xxx@ossi.com> TO: xxx@ossi.com, xxx@ossi.com, xxx@ossi.com CC: ct_dev@ossi.com DATE: 14/02/1996 05:41 -------------------------------------------------------------------------------- Well, there certainly were a few potholes on the road to converting the 1.0 db to 1.1, and also constructing the turfs in the 1.1 db. I think I got it all converted. I have a server running on my machine that looks like the prod db with turfs. Pretty neet. Here are the steps. This is a little long, but I don't see an easier way for right now. I could wrap this into some shell scripts, but that would only hide details and simplify a little. I'll leave that step for the student. If you have problems, ask xxx. He seems to know what is going on. (Sorry xxx.) What you will need... xxx needs to build my 1.0 changes into his 1.0 build tree. This then needs to be installed in production 1.0, or in a 1.0 "snapshot" tree. You'll get a new orb, and two new files in orb.etc: orbdump.tcl and dumpbyclass.tcl. For beta purposes, make a copy of the production dirs somewhere, including a database copy. Then add these new 1.0 files to orb and orb.etc. xxx also needs to build a 1.1 tree, and the files need to be installed somewhere where we will be bringing up the 1.1 server. In addition you will need the cooked turfs file from xxx. This is in his build tree, the fullpath is <build-root>/src/world/regions/turfs.out. This is required for the 1.1 convert. (This file will not be used in future conversions, for example, 1.1 to 1.2.) To take the database dump... Fyi.. here is how to take a copy of the prod odb.data file and build a data/world_n_zone_0 set of directories around it.... In this example, the world will be 10, and the original database copy file is odb.data.020696.0014... bin/make_ivdirs -b . -w 10 touch data/world_10_zone_0/lmt/banished_list bin/iv_text_init data/world_10_zone_0/text mkdir data/world_10_zone_0/rdb/000 mkdir data/world_10_zone_0/odb cp odb.data.020696.0014 data/world_10_zone_0/odb/odb.data cp <see-note-1>/odb_status.data data/world_10_zone_0/odb/ bin/iv_clean_data -b . -w 10 -z 0 -F Note-1: the odb_status.data file above is from a clean world dir. The full path is something like data/world_?_zone_0/odb/odb_status.data. An odb_status.data file needs to just exist there. (This is a work around for a bug in odb_check.) Here are the steps to take the db dump... (% is the orb tcl prompt.) bin/orb -data/world_0_zone_0 % source orb.etc/dumpbyclass.tcl % dumpbyclass dump.1.0.out Here are the commands to restore the database. This should be run in a freshly installed 1.1 tree. Make sure there is enough disk space. You'll need about 300 mb free before you start. The db will end up being 134 mb, and you'll want to be able to make a backup copy of odb.data once the restore is completed, but before the final cutover commands are applied. I'll indicate when to do the backups below in the instructions. Note that we are increasing the size of the odb file because we are already at about 16 mb. The new size is about 134 mb. In this example the destination world we are setting up is world 11. It can be any number. Prior to starting this procedure, there should be no world_11 in the local data directory. We will create _all_ the files here. bin/make_ivdirs -b . -w 11 touch data/world_11_zone_0/lmt/banished_list bin/iv_text_init data/world_11_zone_0/text mkdir data/world_11_zone_0/rdb/0 mkdir data/world_11_zone_0/rdb/0/000 mkdir data/world_11_zone_0/rdb/0/000/000 The following file, region_map.data, is from data.install/world_n_zone_0/rmt, which is in the fresh 1.1 install that xxx built. cp <1.1-install-dir>/data/world_?_zone_0/rmt/region_map.data data/world_11_zone_0/rmt rm /tmp/objrefs.db # make sure this file doesn't exist bin/orb -prod -data/world_11_zone_0 # wait a long time here> % source orb.etc/fullrestore.tcl % fullrestore dump.1.0.out # <wait a long time here> At this point you should get alot of output, but no coredumps. Also, there should be no "Old objref 0xhhh doesnt seem to in the objref db" "I'm initing this objref with NIL_OFFSET" There might be one of them (for a head, classnumber will be 8), but there shouldn't be a slew of them. If there is, might as well stop here and debug. Get out of orb now... % exit # clean the db, note the -F param, this will build the region dbs bin/iv_clean_data -b . -w 11 -z 0 -F There will probably be some dangling object errors (stuff like: WARNING: verify_slots: Invalid position[0] = 8 for object 0xed8c4cc0 (off 0x78c4cc0) in container 0xe60bae00 (off 0xbae00), Range for container is 0 to 3 WARNING: verify_slots: I couldn't find object 0xed8c4cc0 (off 0x78c4cc0) in container 0xe60bae00 (off 0xbae00) ...is ok for now. We'll need to fix these -- I have no idea why they are here, maybe it is just a characteristic of my test database copy, which I found laying around in production. These objects need to be sent to lost and found.) This is a good time to make a backup.... cp data/world_11_zone_0/odb/odb.data ./odb.data.backup Add region teleport aliases, teleport aliases bin/orb -data/world_11_zone_0/ % source orb.etc/orb.tcl % source orb.etc/register_regions.tcl % source orb.etc/register_teleports.tcl % exit Now the turfs... First make a backup... cp data/world_11_zone_0/odb/odb.data ./odb.data.backup Now, add the turfs... grab xxx's turfs.out file... cp <xxx's cm build tree>/src/world/regions/turfs.out bin/orb -data/world_11_zone_0/ % source orb.etc/orb.tcl % source orb.etc/fillregionproc.tcl % source turfs.out % exit remove all region files for rdb rebuild... rm data/world_11_zone_0/rdb/0/000/000/* bin/iv_clean_data -b . -w 11 -z 0 -F -f Start up the server. xxx