1  |   Order by index

Nov 4, 1998, 1:14am

Note: I realize this is LONG. Try to bear with me, I think I might
really have something here.

Well, I know everyone enjoys (err...) yelling at COF about stuff like
privacy features, but I thought maybe I'd toss in a suggestion for a
feature related to building (just how many years has it been since
something significant changed in the building stuff?). This post is laid
out in sections because the topic has so many issues. Now, the message
subject is probably confusing some of you, so I'll get right to the
point. Those of you who understand the if-then-else structure and
variables (for example, anyone at COF lucky enough to be reading) can
skip right down to section 2 to see how this applies to AW and building.
Those of you who don't, read this little section below so you're not
hopelessly lost.

1. A quick lesson in programming

Those of you who know anything about programming in basically any
language will recognize the idea of if-then-else. In C, the
"if-statement" tests a condition. For example, "if (variable==3)" checks
to see if the variable (basically a piece of data... in this case, a
number), which is aptly named "variable" is equal to 3. If so, it would
continue and execute the statement(s) below that line.

Below the statement to be executed, you would probably find an else
statement. The statements that follow are what is executed should the
if-statement be false. For example, if variable was equal to 4.

Once these statements are completed, the program continues on with the
next statement, whatever it may be.

2. The point

Okay, you're not here to learn C. You want to know what this has to do
with AW (some of you might be taking guesses). It's as simple as this:
If the ACTION field of an object could take some simple, C style scripts
and the AW server program could store some variables, it would allow for
all sorts of new and interesting building developments (not to mention
games, but we'll leave that for later). Eep, if you're listening, I bet
you could come up with around 10,000 great ideas to use with this before
you finish this sentence....

3. Why?

You all know that we have a number of actions and triggers to use on
objects. But, there's a problem with them. They all work on the client
side only. Perhaps you've built a door with a switch to open it. You
press the switch, you see the door open, you walk through it. The
problem is that everyone standing around you sees you walk through a
solid door. Okay, who cares, right (I do! I do!)? Not only that, the
door is closed as soon as you walk away and come back. Or, if the switch
is too far away and your visibility is too low, it won't open the door
for you at all.

Once again, these are all minor annoyances. But remember, folks, as Eep
reminds us now and then (and you thought I completely hated you! :) ),
AW is losing its "edge." The novelty wears off, and it's time for some
content. The way a door works is only the tip of the proverbial iceberg.
I'm looking at a feature which would allow a little more realism in the
mechanism of ACTION commands, AND the ability to create, for example, a
complex RPG (Role Playing Game) in that world you bought. Programmers
know what I'm thinking of. Gets better than that, but I'm not near done
yet.

4. How (Simplistic version)?

Okay, the light details (stick with me, folks). The current system with
the object ACTIONs runs totally off the client that triggers them. This
keeps the server from... you know... exploding. It also means you can't
trigger an ACTION on something outside your visibility, one that affects
someone else, or one that lasts for an extended time.

So what do I want to do? Contrary to popular belief I do not want to
make ACTION things server side (running off the server). I want this:
Variable storage on the server end (solves all of the problems above and
introduces new possibilities), and C style (doesn't have to be C... but
it's easy to learn and pretty darn short) scripting interface through
the object ACTION box (allows for access and modification of the
variables via ACTION box, not to mention triggers).

5. How's it work (Simplistic)?

It's really pretty easy. This is the simple explanation. Keep on reading
for more detailed "how's it work?" suggestions. The server program
stores all the variables you declare (variables don't exist until you
tell the program they do, since I didn't mention declaration before).
You declare them in the ACTION field of an object via a statement such
as "int BoboVar", which would create an integer variable called BoboVar.
So now that you've got a variable stored on the server, do something
with it! You'll use a combination of standard AW ACTION syntax and the C
code (once again JUST A SUGGESTED LANGUAGE BASIS... I know the AW
programmers know C very well so I can use it here freely) to manipulate
these variables. The variables will also help you work the triggers. For
example, you could set up a device for the following: if BoboVar was
equal to 1 (probably got that way by someone triggering an activate
command on a button), you could have a panel become "visible off" and
"solid off". Everyone to come to this location until something was
triggered which returned it to "solid on" and "visible on" would be able
to pass through it and see through it. Everyone in the area would see it
open when the trigger was activated. Cool huh? There are some problems,
but I believe I've already solved them. I'll explain the problems and
solutions later.

6. Let's hear some more about the door.... (People who have never seen C
might want to move on to 7... but this is easy stuff)

Let's cover the door thing again for those of you who know what's going
on. :)

You have three objects in the middle of nowhere. One "pp07.rwx" and two
"pole2m.rwx"s. The pp07 is our panel and the two pole2m's are going to
be our "buttons" (well they don't look like 'em, but everyone knows the
pole objects). Below I'm going to explain what goes in each object's
ACTION field and what the stuff does. Note that anything following the
double slashes is a comment I've added to help you folks. The real
script wouldn't have 'em.

pp07.rwx has the following in ACTION:

int doorcontrol = 0; // declares an integer variable and sets it to
zero
if (doorcontrol==1) // does our variable equal one? if so, go on with
the stuff between the "odd braces"
{ // begin statements to be performed should the above test true
visible off; // invisible please
solid off; // I wanna walk through this thing
} // end statements to be performed
else // if the if-statement was false, do what's in the odd braces.
someone, what's the tech term on those things?
{ // the stuff below is going to make sure the door is closed as long
as doorcontrol isn't 1
visible on; // make it visible!
solid on; // make it solid!
} // and we're done

Okay, that wasn't so painful! This simply creates the variable we'll use
to control the door and explains to the software that it should be open
when it's 1 and closed when it's 0 (or anything else, for that matter).
Take a look at it without comments:

int doorcontrol = 0;
if (doorcontrol==1)
{
visible off;
solid off;
}
else
{
visible on;
solid on;
}

Easy, right? Right. Let's move on, remembering that the variable
doorcontrol is now on the server, and we don't have to worry about
sending this info to the other object. (Note: We'll talk about how much
server space this uses and why it shouldn't be allowed in AlphaWorld
later)

first pole2m.rwx's ACTION field:

activate doorcontrol = 1

Wow! That was easy, huh? All this does is set doorcontrol to 1 when you
click on the pole. The door now pops open and stays that way for
everyone. (NOTE: Those of you who know how AW works are seeing a problem
right here. The pp07 should have to update in order to know that it's
supposed to be open! We'll cover this soon. Trust me, it works. =D)

second pole2m.rwx's ACTION field:

activate doorcontrol = 0

Sets doorcontrol to zero, door closes. Wahoo, we're done!! We've just
created the first door in AW that works for everyone, not just the one
who opened it! Too bad it doesn't really work yet, huh?

7A. Okay, if you're so smart, HOW would it work? (we're gonna get
technical now)

So you wanna know more. That's good, because I've thought of basically
everything (I think).

First, where are these variables going? I'm going to suggest they're
stored in a simple text file in the directory world.exe is in. How much
space do they take up? One byte per character. Average variable would
probably take up about 10 bytes on the drive (perhaps 15 if the server
stored the owner's cit number with it). On second thought, it'd probably
be harmless to use them in AlphaWorld, but we'll leave that up to COF,
no? The ability to have variables, and how many variables each user
could "own" in a world are up to the world owner.

More about the variables: When your client loads an object into the
scene which uses any variables, it immediately asks the server "what is
the value of <variablename>?" (in a shorter form of course) for any
variables there (this could be mixed in with the standard "anything
changed?" packet the client sends out every single time you leave the
visibility range of an object and come back, close the program, etc.).
Once it receives the values it runs the scripts on the objects.
So........ it goes: check objects for use of variables, ask about
variables used, receive answer from server, run scripts. It all happens
within a portion of a second assuming lag isn't bad. It's fast and it's
easy. It doesn't slow anything down (well, by half a second if you're
entering an area you don't have cached).

Even more about variables! self. variables for that matter. Such as
Quake's "self.health". A "self." variable is stored client side and does
not go to the server unless a script specifically tells the client to
send it in with a command such as "store self.health". This would put a
variable with the user's name, a dot, and the second part ("King
Henry.health" for me). This could later be called up with something like
"recall self.health", in which case the client would ask for self.health
from the server, and the server would send back yourname.health ("King
Henry.health") which would update your client's self.health. This is one
way to go about making an RPG with "save points" that could be played
for a long time.

The data limit... It would have to go. I suggest the following: Instead
of a data/cell limit, make it an object/cell limit, with the server
allowed to set ANY number of maximum objects per cell (or COF could
remove it all together for all I care).

Now, to solve the most annoying problem.... How does a change in a
variable that effects an object next to you effect it on everyone else
around you's computer if the ACTION is still client side? This will
require a new subject. Read on, everyone!

7B. A little client remodeling? It won't hurt a bit!

We need to solve a major problem. Sure, COF could figure it out, but
I'll save 'em the trouble!

Normally the client only refreshes objects when they're changed or you
leave the area and come back (or you trigger something that affects
them). This is no good. The objects also need to be refreshed when a
variable attached to them changes. Here's how it can work:

Let's say that, in the world NoName, there are 60 variables. There are 4
people there for this example, standing in the same cell. Now, when one
of them does something that changes a variable (opens the example door
from earlier), their client sends off a short packet to the server that
tells what variable and what the new value is (the packet is probably
about 5 bytes). Server picks it up, and changes it in the text file of
variables (Note: Due to the fact that the server would run checks on
vars while you're building, such as "does this variable name already
exist, and if so, do you own it?", there would be no need for it to
verify anything at this point). Now, these four people nearby wouldn't
see the door open under normal conditions until they walked away and
came back (actually it'd be that you'd wait 60 seconds until the client
did a "did anything change?" packet)! This is where we employ some
technology of ActiveWorlds that I don't totally know about. Little while
back, they added a feature which made changes in building appear
instantly to people around you. I don't know if your client tells the
other clients directly or what, but a simple employment of this feature
(Bobo presses the button, his client tells the server that the variable
is changed, server tells anyone near an object that uses that variable
that it has changed) would fix all the problems. When the other three
people receive the variable info, their clients rerun the script for the
door and it opens. Once again, all this happens very fast.

So... we have this: I change variable, client tells server, server tells
people within range of objects (could be more than one, and they don't
have to be close to each other) using variable, all objects using the
variable are refreshed by all people who see them, changes stick.

Whew! We're almost done!

8. Server Script!

Yes the server itself should have an "action box." It can take the same
kind of stuff, but it's executed every single time a variable in it
changes (or maybe every 30 seconds if a variable inside has been
changed? Well whatever). This way the server could, going back up into
7A, say that if self.health was less than 1, you get teleported back to
GZ and self.health resets to 30. So basically, if you lose all your
health, you "die" and start over. All the self. vars are client side, so
everyone who enters gets one. So... with one little command the world
caretaker just set the world up for a game of Quake or dodge the lava
pits! =D

9. Okay that's it I give up.

Well, I hope I've bored most of you to sleep and maybe even successfully
explained an idea to a couple of you. Err... maybe the other way around?
Well I hope someone out there got all this and... you know... kind of
likes it. Suggestions, comments, flames (scratch that), criticism,
something I forgot to explain, additions, pointers about things I said
that would never work/would cause other problems? For Bob's sake reply
(to the newsgroup please)! Should you reply, It'd be easiest if you
either did just a general comment or went through the message and put in
your replies under the section that it belongs under ("variables suck"
belongs under the second section =D). Eep, Grover, don't fail me now! I
know you folks can easily outdo me in programming.

Say, anyone from COF read this?
Roland: "Zzzzzzzzzzz......"
Yeah I didn't think so.

Henry Todd

Nov 4, 1998, 2:02am

You should email this to roland at activeworlds.com to be sure that he sees it,
he doesn't always read every NG post but he reads his email.

[View Quote] > Note: I realize this is LONG. Try to bear with me, I think I might
> really have something here.
>
>

Nov 4, 1998, 12:26pm

[View Quote] > You should email this to roland at activeworlds.com to be sure that he sees it,
> he doesn't always read every NG post but he reads his email.
>

Wow someone actually read it! I had originally considered just sending it
directly to him, but didn't for two reasons... one, I wanted some feedback from
other users, and two, I thought it might be rude to drop a 16K e-mail on the
guy. Maybe I'll send it on over anyway. :)

Henry Todd

Nov 4, 1998, 3:44pm

Yeh!! This is exactly what I was talking about in #15 in my posting "top 16
improvements..." too bad I didn't read this first. I second you're motion,
now they have to implement it...right...?? ;> Oh well, maby they will,
there is so much that I could do with this. I think useing C(++) would be a
good idea.

Nov 5, 1998, 11:31am

Basically, this is a great idea. But there are a few holes and some dents
in what you suggest.

Such as eliminating the cell size limits; heck, C is verbose, just
simplify it. Even throwing out the comments, your example is super verbose
(but ok for C). Example of reworked code follows.

Place this code on the close door trigger:
bump var doorcontrol 0 // or perhaps activate in place of bump

Place this code on the open door trigger:
bump var doorcontrol 1

On the door itself place (the test doorcontrol==1 is implied):
create if doorcontrol (solid off, visible off) (solid on, visible on)

This last one assumes "if #1 #2 #3" with spaces as delimiters; where #1 is
the variable to be tested, #2 is the true command(s), and #3 is the false
command(s). The first time the server encounters a variable name it would
place it into its hash table along with a value (0 if not otherwise
specified), such as when building. Note that Excel and 123 use an
if/then/else structure of "if(#1,#2,#3)" but comas are already used to
separate commands and the outer brackets are redundant and not really
needed.

Another thing I'd really love to see (which would cut the size of the
action box commands) are simplified action codes, such as:
create = crt
activate = act
bump = bmp
animate = anm
solid = sld
visible = vsb
sound = snd
noise = nos
name = nam
sign = sgn
picture = pct
warp = wrp
teleport = tlp
color = clr
bcolor = bcl
nomask = nms

This would reduce the example above to the following.

Place this code on the close door trigger:
bmp var doorcontrol 0

Place this code on the open door trigger:
bmp var doorcontrol 1

On the door itself place (the test doorcontrol == 1 is implied):
crt if doorcontrol (sld off, vsb off) (sld on, vsb on)

Not a lot of savings, but every little bit adds up.


Second, at one point you suggested that the variable name *and* the
builder number be stored on the server; later you suggest that as someone
is building, the variable name be compared with all variable names on the
server to prevent duplication. Wouldn't be easier to simply append the
builder number to the variable name? I'm sure more than one person will
try to use "foo" as a name.


Also forget the text file. Use a hash table instead, much quicker to find
stuff. Another possibility is to break off a copy and sort the copy, then
temporally lock out access to the variable table and change file names. If
the variable table were sorted, finding stuff would radically speed up.


Hmmm, there were a few other things too, but I am too sleepy to continue.
Goodnight.


ScottyDM

--
Please send all SPAMS, FLAMES, and CONSPIRACY THEORIES to
scottydm at cwia.com
Send all other IMPORTANT CORRESPONDENCE to scottydm at codenet.net
___
/////\\ Digitally Enhanced Portrait of:
{|-0-0-|} Scott D. Miller,
| % | Silicon Mercenary
\===/ Freelance Chip Designer

always #5 FOO = ~FOO; // the sound of a beating heart

Nov 5, 1998, 1:57pm

[View Quote] > Basically, this is a great idea. But there are a few holes and some dents
> in what you suggest.
>

Of course! This is why I post it here instead of sending it to COF directly.


> Such as eliminating the cell size limits; heck, C is verbose, just
> simplify it. Even throwing out the comments, your example is super verbose
> (but ok for C). Example of reworked code follows.
>

The cell size limits need to be eliminated not just for something like this.
Cell size is just too damn annoying. At least include the option "unlimited"
along with normal, large, and huge. Free choice or something like that,
y'know? :) The other limit that would need to go is max characters in an
ACTION field. It's somewhere in the range of 256 characters if I remember
right. Not that your ideas below are bad... in fact they're good. I just think
the server should at least have the OPTION of killing the cell limit. You have
no idea how quickly I filled up every portion of my world even on huge....


> Place this code on the close door trigger:
> bump var doorcontrol 0 // or perhaps activate in place of bump
>

I think there is one matter we need to cover, though. Create var variablename
4, for example, is only activated ONCE, and never again. This creates a
variable variablename, sets it to 4, and WILL NOT I repeat WILL NOT reset it
to 4 everytime you leave the area and come back. If you want something to do
that, you'd use create set variablename 4. This one is activated whenever it's
rendered on someone's screen. This one IS NOT activated whenever the variable
variablename is changed. If it worked that way, it would never change long
enough to do anything, since the create scripts are rerun everytime one or
more of the involved variables changes. Just a couple things the program needs
to check. "var" commands only activated ONCE for the world (unless the
variable is somehow removed from the world's list), and "create set" commands
only run through again when someone leaves range and reenters, or someone new
enters range. Other "create" commands involving vars ("create if" for example)
are rerun everytime an involved var changes (because the server gives out that
info immediately).


> Place this code on the open door trigger:
> bump var doorcontrol 1
>
> On the door itself place (the test doorcontrol==1 is implied):
> create if doorcontrol (solid off, visible off) (solid on, visible on)
>
> This last one assumes "if #1 #2 #3" with spaces as delimiters; where #1 is
> the variable to be tested, #2 is the true command(s), and #3 is the false
> command(s). The first time the server encounters a variable name it would
> place it into its hash table along with a value (0 if not otherwise
> specified), such as when building. Note that Excel and 123 use an
> if/then/else structure of "if(#1,#2,#3)" but comas are already used to
> separate commands and the outer brackets are redundant and not really
> needed.
>

Not bad. Not bad at all. And this way the whole thing is based on existing
syntax structures, giving the programer (darn it what ever happened to the
good old days when we had TWO programmers? =D) even less work to do, making it
just a little more likely that it could actually happen.

And if true or false isn't what we want, it's a simple matter of making if
doorcontrol into if (doorcontrol==4783). So we can make everything just as
before, but it's shorter. Also don't forget "activate for" and "bump while,"
both using the concept above. Still, I'm gonna lead that protest for an
"unlimited" option on the server and an object's action field! =D

for loop ex. (we assume the var zort already exists from somewhere):

activate zort = 0, for (zort<4) (warp +0 +0 +1a, ++zort)

Simple enough. When you click on the object, zort is set to zero and the loop
begins. It sees that zort is less than 4, you fly into the air, it increments
zort, you fly higher, yadda yadda yadda. When the loop finally results in a 0,
it sees that there are no statements to be executed upon reaching the end of
the loop and stops. You fall and fall and faaaaaallllll.... Had you wanted to
have something happen you could have done it directly such as:

activate zort = 0, for (zort<4) (warp +0 +0 +1a, ++zort) (visible off, solid
off)

And in this case once the loop is over the thing becomes invisible. Of course
this one only affects you, and we here at the AW realism group don't like
that! =D

For this we assume zortvisible was set to 1 by something else. Perhaps a bump
panel.

create if zortvisible (visible on, solid on) (visible off, solid off)
activate zort = 0, for (zort<4) (warp +0 +0 +1a, ++zort) (zortvisible=0)

Now the thing becomes invisible to everyone when your ride is over. That is,
until someone else bumps the previously mentioned panel.

> Another thing I'd really love to see (which would cut the size of the
> action box commands) are simplified action codes, such as:
> create = crt
> activate = act
> bump = bmp
> animate = anm
> solid = sld
> visible = vsb
> sound = snd
> noise = nos
> name = nam
> sign = sgn
> picture = pct
> warp = wrp
> teleport = tlp
> color = clr
> bcolor = bcl
> nomask = nms
>
> This would reduce the example above to the following.
>
> Place this code on the close door trigger:
> bmp var doorcontrol 0
>
> Place this code on the open door trigger:
> bmp var doorcontrol 1
>
> On the door itself place (the test doorcontrol == 1 is implied):
> crt if doorcontrol (sld off, vsb off) (sld on, vsb on)
>
> Not a lot of savings, but every little bit adds up.
>
> Second, at one point you suggested that the variable name *and* the
> builder number be stored on the server; later you suggest that as someone
> is building, the variable name be compared with all variable names on the
> server to prevent duplication. Wouldn't be easier to simply append the
> builder number to the variable name? I'm sure more than one person will
> try to use "foo" as a name.
>

Quite true. This way everyone can have a var named "spork" instead of
spork245.

> Also forget the text file. Use a hash table instead, much quicker to find
> stuff. Another possibility is to break off a copy and sort the copy, then
> temporally lock out access to the variable table and change file names. If
> the variable table were sorted, finding stuff would radically speed up.
>

Not my area. If you say it's faster, go with it.


> Hmmm, there were a few other things too, but I am too sleepy to continue.
> Goodnight.
>

What I'd really like to find out is if my variable distribution method is even
possible (server immediately sends the var update out to anyone within X cells
of an object using the variable), since I'm not totally sure the server even
keeps track of the client's position. In fact, I'm pretty darn sure it
doesn't. This could create a little problem. So I ask you all out there... HOW
can we get the server to do variable updates to everyone near an object using
a variable that has changed? I offer the following:

1. The original suggestion, but it's a matter of figuring out how the server
can do it. Perhaps it could keep track of where you are based on a "cluster"
of four or eight cells? This wouldn't be very taxing on either end, as, for
example, you're still at GZ in the server's opinion until you move to 2N, then
it doesn't update again until you hit 6N, 10N, and so forth.
2. Every second the server does a general broadcast of all the variable
updates to everyone. At 15 bytes/var (just a high estimation) this would be
harmless. Remember that it only sends data on variables that have changed!
Your client requests variable info when it's requesting object info, so this
is something we don't need to worry about. Even in AlphaWorld, chances are the
highest number of vars that will ever change in a single second is about 10.
That's 150 bytes to each user, or 15K total transmission (assuming 100
people). The server could handle that a million times over! and for those
servers running on 28.8s... well they won't ever have more than around 8
people in them anyway. 1 var/sec * 8 is a whopping 120 bytes or .12K. And
that's your maximum. Besides, you could always turn variable use off. I think
we may have a winner! Assuming the server prog can't handle #1.
3. Hey Roland... you figure it out!

The bell's gonna ring soon, gotta head to the next class. Seeya!

> ScottyDM
>
> --
> Please send all SPAMS, FLAMES, and CONSPIRACY THEORIES to
> scottydm at cwia.com
> Send all other IMPORTANT CORRESPONDENCE to scottydm at codenet.net
> ___
> /////\\ Digitally Enhanced Portrait of:
> {|-0-0-|} Scott D. Miller,
> | % | Silicon Mercenary
> \===/ Freelance Chip Designer
>
> always #5 FOO = ~FOO; // the sound of a beating heart

Nov 5, 1998, 2:08pm

[View Quote] [View Quote] Actually scratch the whole "set" thing. One command can create and set variables.
Apply everything I wrote about "create set" to "create var" and throw away the
stuff about create var.

Let's do it again... all this below is about "create var" (specifically "create
var variablename 0")

This one is activated whenever it's rendered on someone's screen. This one IS NOT
activated whenever the variable variablename is changed. If it worked that way, it
would never change long enough to do anything, since the create scripts are rerun
everytime one or more of the involved variables changes. Just a little thing the
program needs to check. "create var" commands only run through again when someone
leaves range and reenters, or someone new enters range. Other "create" commands
involving vars ("create if" for example) are rerun everytime an involved var
changes (because the server gives out that info immediately). What this means is
that creating a variable with the "create var" command is only for something that
resets a la today's create commands, just for everyone at the same time.

Now, there should also probably be an external interface to mess with your
variables if you're running the server. For example, if you had a server, you
could load up a small util that would let you add variables and change values of
existing ones. If not, you could always do it the "other" way and build an
"activate var" button everytime you wanted to set one, then delete it.

Nov 5, 1998, 8:29pm

This is a multi-part message in MIME format.

------=_NextPart_000_01BE08D9.49246540
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

ummm, then how do you suppose you would explain all of this to a newbie
when he or she asks "how do you build"?
--
REINSTATE PROTAGONIST!!!!!!!!!!!!!!!!



Henry Todd <henry at wcalliance.com> wrote in article
<3641CD88.E19859AB at wcalliance.com>...
>
>
[View Quote] <html><head></head><BODY bgcolor=3D"#B8FFB8"><p><font size=3D2 =
color=3D"#000000" face=3D"Arial">ummm, then how do you suppose you would =
explain all of this to a newbie when he or she asks &quot;how do you =
build&quot;?<br>-- <br>REINSTATE =
PROTAGONIST!!!!!!!!!!!!!!!!<br><br><br><br>Henry Todd &lt;<font =
color=3D"#0000FF"><u>henry at wcalliance.com</u><font =
color=3D"#000000">&gt; wrote in article &lt;<font =
color=3D"#0000FF"><u>3641CD88.E19859AB at wcalliance.com</u><font =
color=3D"#000000">&gt;...<br>&gt; <br>&gt; <br>&gt; Henry Todd =
[View Quote]

Nov 7, 1998, 12:10am

This is a multi-part message in MIME format.

------=_NextPart_000_003A_01BE09B0.B60DBBC0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

If they wanted to know about such advanced procedures they would have to =
learn, just like learning how to make RWX's :) =20
-raiven-

REINSTATE PROTAGONIST?

********HE******* quit
[View Quote]
------=_NextPart_000_003A_01BE09B0.B60DBBC0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#b8ffb8>
<DIV><FONT color=3D#000000 size=3D2>If they wanted to know about such =
advanced=20
procedures they would have to learn, just like learning how to make =
RWX's=20
:)&nbsp;&nbsp;&nbsp; </FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT><FONT =
size=3D2>-raiven-</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>REINSTATE PROTAGONIST?</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2><STRONG><FONT=20
size=3D5>********HE*******</FONT></STRONG>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

<U><STRONG>quit</STRONG></U></FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 solid 2px; MARGIN-LEFT: 5px; PADDING-LEFT: =
5px">
[View Quote] activated ONCE, and never again. This creates a<BR>&gt; &gt; =
variable=20
variablename, sets it to 4, and WILL NOT I repeat WILL NOT reset =
it<BR>&gt;=20
&gt; to 4 everytime you leave the area and come back. If you want =
something=20
to do<BR>&gt; &gt; that, you'd use create set variablename 4. This =
one is=20
activated whenever it's<BR>&gt; &gt; rendered on someone's screen. =
This one=20
IS NOT activated whenever the variable<BR>&gt; &gt; variablename is =
changed.=20
If it worked that way, it would never change long<BR>&gt; &gt; =
enough to do=20
anything, since the create scripts are rerun everytime one =
or<BR>&gt; &gt;=20
more of the involved variables changes. Just a couple things the =
program=20
needs<BR>&gt; &gt; to check. &quot;var&quot; commands only activated =
ONCE=20
for the world (unless the<BR>&gt; &gt; variable is somehow removed =
from the=20
world's list), and &quot;create set&quot; commands<BR>&gt; &gt; only =
run=20
through again when someone leaves range and reenters, or someone =
new<BR>&gt;=20
&gt; enters range. Other &quot;create&quot; commands involving vars=20
(&quot;create if&quot; for example)<BR>&gt; &gt; are rerun everytime =
an=20
involved var changes (because the server gives out that<BR>&gt; &gt; =
info=20
immediately).<BR>&gt; &gt;<BR>&gt; <BR>&gt; Actually scratch the =
whole=20
&quot;set&quot; thing. One command can create and set =
variables.<BR>&gt;=20
Apply everything I wrote about &quot;create set&quot; to =
&quot;create=20
var&quot; and throw away the<BR>&gt; stuff about create var.<BR>&gt; =

<BR>&gt; Let's do it again... all this below is about &quot;create =
var&quot;=20
(specifically &quot;create<BR>&gt; var variablename 0&quot;)<BR>&gt; =

<BR>&gt; This one is activated whenever it's rendered on someone's =
screen.=20
This one IS NOT<BR>&gt; activated whenever the variable variablename =
is=20
changed. If it worked that way, it<BR>&gt; would never change long =
enough to=20
do anything, since the create scripts are rerun<BR>&gt; everytime =
one or=20
more of the involved variables changes. Just a little thing =
the<BR>&gt;=20
program needs to check. &quot;create var&quot; commands only run =
through=20
again when someone<BR>&gt; leaves range and reenters, or someone new =
enters=20
range. Other &quot;create&quot; commands<BR>&gt; involving vars=20
(&quot;create if&quot; for example) are rerun everytime an involved=20
var<BR>&gt; changes (because the server gives out that info =
immediately).=20
What this means is<BR>&gt; that creating a variable with the =
&quot;create=20
var&quot; command is only for something that<BR>&gt; resets a la =
today's=20
create commands, just for everyone at the same time.<BR>&gt; =
<BR>&gt; Now,=20
there should also probably be an external interface to mess with=20
your<BR>&gt; variables if you're running the server. For example, if =
you had=20
a server, you<BR>&gt; could load up a small util that would let you =
add=20
variables and change values of<BR>&gt; existing ones. If not, you =
could=20
always do it the &quot;other&quot; way and build an<BR>&gt; =
&quot;activate=20
var&quot; button everytime you wanted to set one, then delete =
it.<BR>&gt;=20
<BR>&gt; =
</P></FONT></FONT></FONT></FONT></FONT></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_003A_01BE09B0.B60DBBC0--

Nov 7, 1998, 1:06am

--------------9FA6C64F97B8091EA948D26E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Yeah, like trying to teach me how to program in C+. It ain't
happening. The kind of commands that you are talking about belong in a
Computer Science text book, not on a simple building help file. Do you
wanna scare away people by all that?

Anyways, if these ideas are ever implemented, I would suggest they be
placed on a back page somewhere labeled Advanced Building Techniques for
Computer Geniuses.
:-)

[View Quote] > If they wanted to know about such advanced procedures they would have
> to learn, just like learning how to make RWX's :)-raiven- REINSTATE
> PROTAGONIST? ********HE******* quit
>
[View Quote] --------------9FA6C64F97B8091EA948D26E
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<BODY BGCOLOR="#B8FFB8">
Yeah, like trying to teach me how to program in C+.&nbsp;&nbsp;&nbsp; It
ain't happening.&nbsp;&nbsp; The kind of commands that you are talking
about belong in a Computer Science text book, not on a simple building
help file.&nbsp;&nbsp; Do you wanna scare away people by all that?
<P>Anyways, if these ideas are ever implemented, I would suggest they be
placed on a back page somewhere labeled <B>Advanced Building Techniques
for Computer Geniuses</B>.
<BR>:-)
[View Quote] </BODY>
</HTML>

--------------9FA6C64F97B8091EA948D26E--

Nov 7, 1998, 1:42am

This is a multi-part message in MIME format.

------=_NextPart_000_0011_01BE09D6.C2C38F40
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

yeah, and FYI raiven, Protag didn't quit - he quit programming for AW =
sure - but he was denied the ability to re-register his "Protagonist" =
cit # 2 account.

--=20
*REINSTATE PROTAGONIST!*

[View Quote] [View Quote] If they wanted to know about such advanced procedures they would =
have to learn, just like learning how to make RWX's :)-raiven- REINSTATE =
PROTAGONIST? ********HE******* quit=20
[View Quote]
------=_NextPart_000_0011_01BE09D6.C2C38F40
Content-Type: text/html;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML><HEAD>
<META content=3Dtext/html;charset=3DWindows-1252 =
http-equiv=3DContent-Type><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 =
Transitional//EN">
<STYLE></STYLE>

<META content=3D'"MSHTML 5.00.0910.1309"' name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>yeah, and FYI raiven, Protag didn't quit - he quit =
programming=20
for AW sure - but he was denied the ability to re-register his=20
&quot;<EM>Protagonist</EM>&quot; cit # <STRONG>2</STRONG> =
account.</FONT></DIV>
<DIV><FONT size=3D2><BR>-- <BR><STRONG>*REINSTATE=20
PROTAGONIST!*</STRONG></FONT></DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
<DIV>Dean &lt;<A=20
href=3D"mailto:challagar at hotmail.com">challagar at hotmail.com</A>&gt; =
wrote in=20
message <A=20
=
href=3D"news:3643B932.19A96D55 at hotmail.com">news:3643B932.19A96D55 at hotmai=
l.com</A>...</DIV>Yeah,=20
like trying to teach me how to program in C+.&nbsp;&nbsp;&nbsp; It =
ain't=20
happening.&nbsp;&nbsp; The kind of commands that you are talking about =
belong=20
in a Computer Science text book, not on a simple building help=20
file.&nbsp;&nbsp; Do you wanna scare away people by all that?=20
<P>Anyways, if these ideas are ever implemented, I would suggest they =
be=20
placed on a back page somewhere labeled <B>Advanced Building =
Techniques for=20
Computer Geniuses</B>. <BR>:-)=20
[View Quote] color=3D#000000><FONT size=3D-1>--</FONT></FONT></FONT> <BR><FONT=20
face=3DArial><FONT color=3D#000000><FONT size=3D-1>REINSTATE=20
PROTAGONIST!!!!!!!!!!!!!!!!</FONT></FONT></FONT> <BR>&nbsp; =
<BR>&nbsp;=20
<P><FONT face=3DArial><FONT size=3D-1><FONT color=3D#000000>Henry =
Todd=20
&lt;</FONT><U><FONT color=3D#0000ff><A=20
=
href=3D"mailto:henry at wcalliance.com">henry at wcalliance.com</A></FONT></U><=
FONT=20
color=3D#000000>&gt; wrote in article &lt;</FONT><U><FONT =
color=3D#0000ff><A=20
=
href=3D"mailto:3641CD88.E19859AB at wcalliance.com">3641CD88.E19859AB at wcalli=
ance.com</A></FONT></U><FONT=20
color=3D#000000>&gt;...</FONT></FONT></FONT> <BR><FONT =
face=3DArial><FONT=20
color=3D#000000><FONT size=3D-1>&gt;</FONT></FONT></FONT> =
<BR><FONT=20
face=3DArial><FONT color=3D#000000><FONT =
size=3D-1>&gt;</FONT></FONT></FONT>=20
<BR><FONT face=3DArial><FONT color=3D#000000><FONT size=3D-1>&gt; =
Henry Todd=20
[View Quote] <BR><FONT face=3DArial><FONT color=3D#000000><FONT size=3D-1>&gt; =
&gt; variable=20
is somehow removed from the world's list), and &quot;create =
set&quot;=20
commands</FONT></FONT></FONT> <BR><FONT face=3DArial><FONT=20
color=3D#000000><FONT size=3D-1>&gt; &gt; only run through again =
when someone=20
leaves range and reenters, or someone new</FONT></FONT></FONT> =
<BR><FONT=20
face=3DArial><FONT color=3D#000000><FONT size=3D-1>&gt; &gt; =
enters range. Other=20
&quot;create&quot; commands involving vars (&quot;create if&quot; =
for=20
example)</FONT></FONT></FONT> <BR><FONT face=3DArial><FONT=20
color=3D#000000><FONT size=3D-1>&gt; &gt; are rerun everytime an =
involved var=20
changes (because the server gives out that</FONT></FONT></FONT> =
<BR><FONT=20
face=3DArial><FONT color=3D#000000><FONT size=3D-1>&gt; &gt; info=20
immediately).</FONT></FONT></FONT> <BR><FONT face=3DArial><FONT=20
color=3D#000000><FONT size=3D-1>&gt; &gt;</FONT></FONT></FONT> =
<BR><FONT=20
face=3DArial><FONT color=3D#000000><FONT =
size=3D-1>&gt;</FONT></FONT></FONT>=20
<BR><FONT face=3DArial><FONT color=3D#000000><FONT size=3D-1>&gt; =
Actually=20
scratch the whole &quot;set&quot; thing. One command can create =
and set=20
variables.</FONT></FONT></FONT> <BR><FONT face=3DArial><FONT=20
color=3D#000000><FONT size=3D-1>&gt; Apply everything I wrote =
about=20
&quot;create set&quot; to &quot;create var&quot; and throw away=20
the</FONT></FONT></FONT> <BR><FONT face=3DArial><FONT =
color=3D#000000><FONT=20
size=3D-1>&gt; stuff about create var.</FONT></FONT></FONT> =
<BR><FONT=20
face=3DArial><FONT color=3D#000000><FONT =
size=3D-1>&gt;</FONT></FONT></FONT>=20
<BR><FONT face=3DArial><FONT color=3D#000000><FONT size=3D-1>&gt; =
Let's do it=20
again... all this below is about &quot;create var&quot; =
(specifically=20
&quot;create</FONT></FONT></FONT> <BR><FONT face=3DArial><FONT=20
color=3D#000000><FONT size=3D-1>&gt; var variablename=20
0&quot;)</FONT></FONT></FONT> <BR><FONT face=3DArial><FONT=20
color=3D#000000><FONT size=3D-1>&gt;</FONT></FONT></FONT> =
<BR><FONT=20
face=3DArial><FONT color=3D#000000><FONT size=3D-1>&gt; This one =
is activated=20
whenever it's rendered on someone's screen. This one IS=20
NOT</FONT></FONT></FONT> <BR><FONT face=3DArial><FONT =
color=3D#000000><FONT=20
size=3D-1>&gt; activated whenever the variable variablename is =
changed. If=20
it worked that way, it</FONT></FONT></FONT> <BR><FONT =
face=3DArial><FONT=20
color=3D#000000><FONT size=3D-1>&gt; would never change long =
enough to do=20
anything, since the create scripts are rerun</FONT></FONT></FONT>=20
<BR><FONT face=3DArial><FONT color=3D#000000><FONT size=3D-1>&gt; =
everytime one=20
or more of the involved variables changes. Just a little thing=20
the</FONT></FONT></FONT> <BR><FONT face=3DArial><FONT =
color=3D#000000><FONT=20
size=3D-1>&gt; program needs to check. &quot;create var&quot; =
commands only=20
run through again when someone</FONT></FONT></FONT> <BR><FONT=20
face=3DArial><FONT color=3D#000000><FONT size=3D-1>&gt; leaves =
range and=20
reenters, or someone new enters range. Other &quot;create&quot;=20
commands</FONT></FONT></FONT> <BR><FONT face=3DArial><FONT=20
color=3D#000000><FONT size=3D-1>&gt; involving vars (&quot;create =
if&quot; for=20
example) are rerun everytime an involved var</FONT></FONT></FONT>=20
<BR><FONT face=3DArial><FONT color=3D#000000><FONT size=3D-1>&gt; =
changes=20
(because the server gives out that info immediately). What this =
means=20
is</FONT></FONT></FONT> <BR><FONT face=3DArial><FONT =
color=3D#000000><FONT=20
size=3D-1>&gt; that creating a variable with the &quot;create =
var&quot;=20
command is only for something that</FONT></FONT></FONT> <BR><FONT=20
face=3DArial><FONT color=3D#000000><FONT size=3D-1>&gt; resets a =
la today's=20
create commands, just for everyone at the same =
time.</FONT></FONT></FONT>=20
<BR><FONT face=3DArial><FONT color=3D#000000><FONT=20
size=3D-1>&gt;</FONT></FONT></FONT> <BR><FONT face=3DArial><FONT=20
color=3D#000000><FONT size=3D-1>&gt; Now, there should also =
probably be an=20
external interface to mess with your</FONT></FONT></FONT> =
<BR><FONT=20
face=3DArial><FONT color=3D#000000><FONT size=3D-1>&gt; variables =
if you're=20
running the server. For example, if you had a server,=20
you</FONT></FONT></FONT> <BR><FONT face=3DArial><FONT =
color=3D#000000><FONT=20
size=3D-1>&gt; could load up a small util that would let you add =
variables=20
and change values of</FONT></FONT></FONT> <BR><FONT =
face=3DArial><FONT=20
color=3D#000000><FONT size=3D-1>&gt; existing ones. If not, you =
could always=20
do it the &quot;other&quot; way and build an</FONT></FONT></FONT>=20
<BR><FONT face=3DArial><FONT color=3D#000000><FONT size=3D-1>&gt; =
&quot;activate=20
var&quot; button everytime you wanted to set one, then delete=20
it.</FONT></FONT></FONT> <BR><FONT face=3DArial><FONT =
color=3D#000000><FONT=20
size=3D-1>&gt;</FONT></FONT></FONT> <BR><FONT face=3DArial><FONT=20
color=3D#000000><FONT=20
=
size=3D-1>&gt;</FONT></FONT></FONT></P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQ=
UOTE></BODY></HTML>

------=_NextPart_000_0011_01BE09D6.C2C38F40--

Nov 9, 1998, 1:30am

This is a multi-part message in MIME format.

------=_NextPart_000_001F_01BE0B4E.4971C520
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

So what? He USED to be number 1, then he is 2? does it really matter if =
he cant register as number 2?


[View Quote] [View Quote] If they wanted to know about such advanced procedures they =
would have to learn, just like learning how to make RWX's :)-raiven- =
REINSTATE PROTAGONIST? ********HE******* quit=20
[View Quote]
------=_NextPart_000_001F_01BE0B4E.4971C520
Content-Type: text/html;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 =
HTML//EN"><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<STYLE></STYLE>

<META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>So what?&nbsp; He USED to be number =
1, then he=20
is 2? does it really matter if he cant register as number =
2?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 solid 2px; MARGIN-LEFT: 5px; PADDING-LEFT: =
5px">
[View Quote] color=3D#000000><FONT =
size=3D-1>&gt;</FONT></FONT></FONT> <BR><FONT=20
face=3DArial><FONT color=3D#000000><FONT size=3D-1>&gt; =
&gt; Scott D.=20
[View Quote] if&quot; for example)</FONT></FONT></FONT> <BR><FONT=20
face=3DArial><FONT color=3D#000000><FONT size=3D-1>&gt; =
&gt; are rerun=20
everytime an involved var changes (because the server =
gives out=20
that</FONT></FONT></FONT> <BR><FONT face=3DArial><FONT=20
color=3D#000000><FONT size=3D-1>&gt; &gt; info=20
immediately).</FONT></FONT></FONT> <BR><FONT =
face=3DArial><FONT=20
color=3D#000000><FONT size=3D-1>&gt; =
&gt;</FONT></FONT></FONT>=20
<BR><FONT face=3DArial><FONT color=3D#000000><FONT=20
size=3D-1>&gt;</FONT></FONT></FONT> <BR><FONT =
face=3DArial><FONT=20
color=3D#000000><FONT size=3D-1>&gt; Actually scratch =
the whole=20
&quot;set&quot; thing. One command can create and set=20
variables.</FONT></FONT></FONT> <BR><FONT =
face=3DArial><FONT=20
color=3D#000000><FONT size=3D-1>&gt; Apply everything I =
wrote about=20
&quot;create set&quot; to &quot;create var&quot; and =
throw away=20
the</FONT></FONT></FONT> <BR><FONT face=3DArial><FONT=20
color=3D#000000><FONT size=3D-1>&gt; stuff about create=20
var.</FONT></FONT></FONT> <BR><FONT face=3DArial><FONT=20
color=3D#000000><FONT =
size=3D-1>&gt;</FONT></FONT></FONT> <BR><FONT=20
face=3DArial><FONT color=3D#000000><FONT size=3D-1>&gt; =
Let's do it=20
again... all this below is about &quot;create var&quot;=20
(specifically &quot;create</FONT></FONT></FONT> =
<BR><FONT=20
face=3DArial><FONT color=3D#000000><FONT size=3D-1>&gt; =
var=20
variablename 0&quot;)</FONT></FONT></FONT> <BR><FONT=20
face=3DArial><FONT color=3D#000000><FONT=20
size=3D-1>&gt;</FONT></FONT></FONT> <BR><FONT =
face=3DArial><FONT=20
color=3D#000000><FONT size=3D-1>&gt; This one is =
activated whenever=20
it's rendered on someone's screen. This one IS=20
NOT</FONT></FONT></FONT> <BR><FONT face=3DArial><FONT=20
color=3D#000000><FONT size=3D-1>&gt; activated whenever =
the variable=20
variablename is changed. If it worked that way,=20
it</FONT></FONT></FONT> <BR><FONT face=3DArial><FONT=20
color=3D#000000><FONT size=3D-1>&gt; would never change =
long enough=20
to do anything, since the create scripts are=20
rerun</FONT></FONT></FONT> <BR><FONT face=3DArial><FONT=20
color=3D#000000><FONT size=3D-1>&gt; everytime one or =
more of the=20
involved variables changes. Just a little thing=20
the</FONT></FONT></FONT> <BR><FONT face=3DArial><FONT=20
color=3D#000000><FONT size=3D-1>&gt; program needs to =
check.=20
&quot;create var&quot; commands only run through again =
when=20
someone</FONT></FONT></FONT> <BR><FONT =
face=3DArial><FONT=20
color=3D#000000><FONT size=3D-1>&gt; leaves range and =
reenters, or=20
someone new enters range. Other &quot;create&quot;=20
commands</FONT></FONT></FONT> <BR><FONT =
face=3DArial><FONT=20
color=3D#000000><FONT size=3D-1>&gt; involving vars =
(&quot;create=20
if&quot; for example) are rerun everytime an involved=20
var</FONT></FONT></FONT> <BR><FONT face=3DArial><FONT=20
color=3D#000000><FONT size=3D-1>&gt; changes (because =
the server=20
gives out that info immediately). What this means=20
is</FONT></FONT></FONT> <BR><FONT face=3DArial><FONT=20
color=3D#000000><FONT size=3D-1>&gt; that creating a =
variable with=20
the &quot;create var&quot; command is only for something =

that</FONT></FONT></FONT> <BR><FONT face=3DArial><FONT=20
color=3D#000000><FONT size=3D-1>&gt; resets a la today's =
create=20
commands, just for everyone at the same=20
time.</FONT></FONT></FONT> <BR><FONT face=3DArial><FONT=20
color=3D#000000><FONT =
size=3D-1>&gt;</FONT></FONT></FONT> <BR><FONT=20
face=3DArial><FONT color=3D#000000><FONT size=3D-1>&gt; =
Now, there=20
should also probably be an external interface to mess =
with=20
your</FONT></FONT></FONT> <BR><FONT face=3DArial><FONT=20
color=3D#000000><FONT size=3D-1>&gt; variables if you're =
running the=20
server. For example, if you had a server,=20
you</FONT></FONT></FONT> <BR><FONT face=3DArial><FONT=20
color=3D#000000><FONT size=3D-1>&gt; could load up a =
small util that=20
would let you add variables and change values=20
of</FONT></FONT></FONT> <BR><FONT face=3DArial><FONT=20
color=3D#000000><FONT size=3D-1>&gt; existing ones. If =
not, you=20
could always do it the &quot;other&quot; way and build=20
an</FONT></FONT></FONT> <BR><FONT face=3DArial><FONT=20
color=3D#000000><FONT size=3D-1>&gt; &quot;activate =
var&quot; button=20
everytime you wanted to set one, then delete=20
it.</FONT></FONT></FONT> <BR><FONT face=3DArial><FONT=20
color=3D#000000><FONT =
size=3D-1>&gt;</FONT></FONT></FONT> <BR><FONT=20
face=3DArial><FONT color=3D#000000><FONT=20
=
size=3D-1>&gt;</FONT></FONT></FONT></P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQ=
UOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_001F_01BE0B4E.4971C520--

Nov 11, 1998, 1:15am

[View Quote] --snip--
> The cell size limits need to be eliminated not just for something like this.
> Cell size is just too damn annoying. At least include the option "unlimited"
> along with normal, large, and huge. Free choice or something like that,
> y'know? :) The other limit that would need to go is max characters in an
> ACTION field. It's somewhere in the range of 256 characters if I remember
> right. Not that your ideas below are bad... in fact they're good. I just think
> the server should at least have the OPTION of killing the cell limit. You have
> no idea how quickly I filled up every portion of my world even on huge....

Cell size was not dreamt up just to annoy us, it has several purposes:
1st, it keeps frame rates reasonable because some people would jam 1000
objects into a single cell if the server would let them; and the hapless
victim who stumbles within visual range of such a mess would suddenly see
their frame rate drop to about 0.2 or something. 2nd, it keeps building
bots and inept builders from trashing the database with 1000 copies of
walk029h laid down on top of each other. 3rd, it helps control the amount
of storage required on the server. 4th, (and this is a speculation) the
database on the server may have fixed field sizes for each cell; so as
soon as a cell is used at all, it takes up its fully allotted limit.


--snip--
> I think there is one matter we need to cover, though. Create var variablename
> 4, for example, is only activated ONCE, and never again. This creates a
> variable variablename, sets it to 4, and WILL NOT I repeat WILL NOT reset it
> to 4 everytime you leave the area and come back. If you want something to do
> that, you'd use create set variablename 4. This one is activated whenever it's
> rendered on someone's screen. This one IS NOT activated whenever the variable
> variablename is changed. If it worked that way, it would never change long
> enough to do anything, since the create scripts are rerun everytime one or
> more of the involved variables changes. Just a couple things the program needs
> to check. "var" commands only activated ONCE for the world (unless the
> variable is somehow removed from the world's list), and "create set" commands
> only run through again when someone leaves range and reenters, or someone new
> enters range. Other "create" commands involving vars ("create if" for example)
> are rerun everytime an involved var changes (because the server gives out that
> info immediately).

Here I strongly disagree. There is no way to limit the execution of a
"line of code" in the action box to only once. Nor is there any way to
control the order that objects are encountered in (which controls the
order that the code is executed in). The only reason that create is used
in modern programming languages is because it is the "modern" thing to do;
that is it leads to easier to maintain code because it offers easy answers
to niggling little questions like, "What is that!? <confused programmer
points to a user defined name in some source code>". So in this instance
"var" is not the same as a C/C++ "var" it simply tells what ever is
executing the code that the next word is a variable, the = 0 is implied.
And yes, every single time someone bumps the object, the variable is set
back to 0. Although, scan down a little further to see another idea on how
to parse variables.

The actual creation of variables is quite simple actually, it happens
automatically the first time you type that variable name into the action
box of an object and then "drop" the object. Which brings up the problem
of the hash table becoming hopelessly cluttered up with orphan variable
names (they currently do not appear in any action boxes on any instances
of any objects in the world). Perhaps some kind of on-line garbage
collection could be used to periodically clean the hash table.


--snip--
> And if true or false isn't what we want, it's a simple matter of making if
> doorcontrol into if (doorcontrol==4783). So we can make everything just as
> before, but it's shorter. Also don't forget "activate for" and "bump while,"
> both using the concept above. Still, I'm gonna lead that protest for an
> "unlimited" option on the server and an object's action field! =D
>
> for loop ex. (we assume the var zort already exists from somewhere):

Of course zort exists, you just named it in the following statement! I
know your professors/boss/whoever will have a cow because there is no
explicit declaration of variables. Too bad, real programmers know what
they are doing without all this "touchie-feelie new-age programming
clap-trap" (especially when it breaks the paradigm).

> activate zort = 0, for (zort<4) (warp +0 +0 +1a, ++zort)

Is it "activate zort = 0,..." or "activate set zort = 0,..." Actually,
since AW is not case sensitive there is no easy method to make variable
names stand out from the other stuff in the action box. May I suggest
appending a special character to the beginning of the name, e.g. %zort. If
the system (server or browser) sees something like "%zort=0" it knows that
it needs to do a "set zort=0" (not that "%" means "set", it does not, "="
means "set"). Without a special character, then the "language" must have a
key word preceding the variable name to be able to make sense of stuff
(and "activate" does not count since it can be followed by almost
anything).

In this example the use of the "zort<4" is unnecessary and the code could
be rewritten:
activate %zort = -4, for %zort (warp +0 +0 +1a, ++%zort)
In "old style" code (my first post) it would be:
activate var zort -4, for zort (warp +0 +0 +1a, ++zort)
As long as zort (or %zort) is not zero, the loop continues. I know that
having a test other than a simple true/false test is convenient, but
believe you can get a heck of a lot done without it. This "for" command is
interesting, but I'm not really convinced that it is all that hot (without
additional controls, like how often it increments (ms of delay)). This
behavior can be emulated by other techniques. However if the loop is
decoupled from the object displaying the action, then interesting things
happen (which is why the need for the delay command, like in animate).

--snip--
> activate zort = 0, for (zort<4) (warp +0 +0 +1a, ++zort) (visible off, solid
> off)

Hmmmm, I don't get it. Are you changing the syntax? How about if I retype
it:
activate begin
set zort = 0; // or does zort = 0; work better?
for (zort < 4) begin
warp +0 +0 +1a;
++ zort; // sorry, is this correct C syntax for
increment?
end
visible off;
solid off;
end
If this is what you had in mind then the correct syntax for the visible
off etc. would be:
activate zort = 0, for (zort<4) (warp +0 +0 +1a, ++zort), visible off,
solid off


> And in this case once the loop is over the thing becomes invisible. Of course
> this one only affects you, and we here at the AW realism group don't like
> that! =D

Quite true. To prevent confusion I will use "var" to mean that the word
following var is a variable to be set to a new value. Thus the correct
code would be:
activate var zort -4, for zort (warp +0 +0 +1a, var zort ++);
create if zort (visible off, solid off) (visible on, solid on)
This is of course if you want the clicked object to turn invisible while
the person is being squirted up into the air (note the semicolon at the
end of the first line). The ++zort has been bugging me, it just does not
seem consistent with the way the other stuff works so I changed it just a
little.

Wow, this must really be getting muddled up and confused for most readers,
we have a "system" <I laugh at that term> of syntax that is wildly
inconsistent at this point.

--snip--
> What I'd really like to find out is if my variable distribution method is even
> possible (server immediately sends the var update out to anyone within X cells
> of an object using the variable), since I'm not totally sure the server even
> keeps track of the client's position. In fact, I'm pretty darn sure it
> doesn't. This could create a little problem. So I ask you all out there... HOW
> can we get the server to do variable updates to everyone near an object using
> a variable that has changed? I offer the following:

This is done now of course. How do you think the system knows what stuff
to download to you? Plus, for security purposes, all chat is funneled
through the server. It should be a simple matter to: #1 update all
variables when the user first wanders into visibility range. #2 keep track
of the user's ability to see an object and send the user updates on a
variable's value if it should change (kind of like chat dialog, but in
this case between the server and the browser).

--snip--

ScottyDM

--
Please send all SPAMS, FLAMES, and CONSPIRACY THEORIES to
scottydm at cwia.com
Send all other IMPORTANT CORRESPONDENCE to scottydm at codenet.net
___
/////\\ Digitally Enhanced Portrait of:
{|-0-0-|} Scott D. Miller,
| % | Silicon Mercenary
\===/ Freelance Chip Designer

always #5 FOO = ~FOO; // the sound of a beating heart

Nov 11, 1998, 1:19am

[View Quote] --snip--
> The cell size limits need to be eliminated not just for something like this.
> Cell size is just too damn annoying. At least include the option "unlimited"
> along with normal, large, and huge. Free choice or something like that,
> y'know? :) The other limit that would need to go is max characters in an
> ACTION field. It's somewhere in the range of 256 characters if I remember
> right. Not that your ideas below are bad... in fact they're good. I just think
> the server should at least have the OPTION of killing the cell limit. You have
> no idea how quickly I filled up every portion of my world even on huge....

Cell size was not dreamt up just to annoy us, it has several purposes:
1st, it keeps frame rates reasonable because some people would jam 1000
objects into a single cell if the server would let them; and the hapless
victim who stumbles within visual range of such a mess would suddenly see
their frame rate drop to about 0.2 or something. 2nd, it keeps building
bots and inept builders from trashing the database with 1000 copies of
walk029h laid down on top of each other. 3rd, it helps control the amount
of storage required on the server. 4th, (and this is a speculation) the
database on the server may have fixed field sizes for each cell; so as
soon as a cell is used at all, it takes up its fully allotted limit.


--snip--
> I think there is one matter we need to cover, though. Create var variablename
> 4, for example, is only activated ONCE, and never again. This creates a
> variable variablename, sets it to 4, and WILL NOT I repeat WILL NOT reset it
> to 4 everytime you leave the area and come back. If you want something to do
> that, you'd use create set variablename 4. This one is activated whenever it's
> rendered on someone's screen. This one IS NOT activated whenever the variable
> variablename is changed. If it worked that way, it would never change long
> enough to do anything, since the create scripts are rerun everytime one or
> more of the involved variables changes. Just a couple things the program needs
> to check. "var" commands only activated ONCE for the world (unless the
> variable is somehow removed from the world's list), and "create set" commands
> only run through again when someone leaves range and reenters, or someone new
> enters range. Other "create" commands involving vars ("create if" for example)
> are rerun everytime an involved var changes (because the server gives out that
> info immediately).

Here I strongly disagree. There is no way to limit the execution of a
"line of code" in the action box to only once. Nor is there any way to
control the order that objects are encountered in (which controls the
order that the code is executed in). The only reason that create is used
in modern programming languages is because it is the "modern" thing to do;
that is it leads to easier to maintain code because it offers easy answers
to niggling little questions like, "What is that!? <confused programmer
points to a user defined name in some source code>". So in this instance
"var" is not the same as a C/C++ "var" it simply tells what ever is
executing the code that the next word is a variable, the = 0 is implied.
And yes, every single time someone bumps the object, the variable is set
back to 0. Although, scan down a little further to see another idea on how
to parse variables.

The actual creation of variables is quite simple actually, it happens
automatically the first time you type that variable name into the action
box of an object and then "drop" the object. Which brings up the problem
of the hash table becoming hopelessly cluttered up with orphan variable
names (they currently do not appear in any action boxes on any instances
of any objects in the world). Perhaps some kind of on-line garbage
collection could be used to periodically clean the hash table.


--snip--
> And if true or false isn't what we want, it's a simple matter of making if
> doorcontrol into if (doorcontrol==4783). So we can make everything just as
> before, but it's shorter. Also don't forget "activate for" and "bump while,"
> both using the concept above. Still, I'm gonna lead that protest for an
> "unlimited" option on the server and an object's action field! =D
>
> for loop ex. (we assume the var zort already exists from somewhere):

Of course zort exists, you just named it in the following statement! I
know your professors/boss/whoever will have a cow because there is no
explicit declaration of variables. Too bad, real programmers know what
they are doing without all this "touchie-feelie new-age programming
clap-trap" (especially when it breaks the paradigm).

> activate zort = 0, for (zort<4) (warp +0 +0 +1a, ++zort)

Is it "activate zort = 0,..." or "activate set zort = 0,..." Actually,
since AW is not case sensitive there is no easy method to make variable
names stand out from the other stuff in the action box. May I suggest
appending a special character to the beginning of the name, e.g. %zort. If
the system (server or browser) sees something like "%zort=0" it knows that
it needs to do a "set zort=0" (not that "%" means "set", it does not, "="
means "set"). Without a special character, then the "language" must have a
key word preceding the variable name to be able to make sense of stuff
(and "activate" does not count since it can be followed by almost
anything).

In this example the use of the "zort<4" is unnecessary and the code could
be rewritten:
activate %zort = -4, for %zort (warp +0 +0 +1a, ++%zort)
In "old style" code (my first post) it would be:
activate var zort -4, for zort (warp +0 +0 +1a, ++zort)
As long as zort (or %zort) is not zero, the loop continues. I know that
having a test other than a simple true/false test is convenient, but
believe you can get a heck of a lot done without it. This "for" command is
interesting, but I'm not really convinced that it is all that hot (without
additional controls, like how often it increments (ms of delay)). This
behavior can be emulated by other techniques. However if the loop is
decoupled from the object displaying the action, then interesting things
happen (which is why the need for the delay command, like in animate).

--snip--
> activate zort = 0, for (zort<4) (warp +0 +0 +1a, ++zort) (visible off, solid
> off)

Hmmmm, I don't get it. Are you changing the syntax? How about if I retype
it:
activate begin
set zort = 0; // or does zort = 0; work better?
for (zort < 4) begin
warp +0 +0 +1a;
++ zort; // sorry, is this correct C syntax for
increment?
end
visible off;
solid off;
end
If this is what you had in mind then the correct syntax for the visible
off etc. would be:
activate zort = 0, for (zort<4) (warp +0 +0 +1a, ++zort), visible off,
solid off


> And in this case once the loop is over the thing becomes invisible. Of course
> this one only affects you, and we here at the AW realism group don't like
> that! =D

Quite true. To prevent confusion I will use "var" to mean that the word
following var is a variable to be set to a new value. Thus the correct
code would be:
activate var zort -4, for zort (warp +0 +0 +1a, var zort ++);
create if zort (visible off, solid off) (visible on, solid on)
This is of course if you want the clicked object to turn invisible while
the person is being squirted up into the air (note the semicolon at the
end of the first line). The ++zort has been bugging me, it just does not
seem consistent with the way the other stuff works so I changed it just a
little.

Wow, this must really be getting muddled up and confused for most readers,
we have a "system" <I laugh at that term> of syntax that is wildly
inconsistent at this point.

--snip--
> What I'd really like to find out is if my variable distribution method is even
> possible (server immediately sends the var update out to anyone within X cells
> of an object using the variable), since I'm not totally sure the server even
> keeps track of the client's position. In fact, I'm pretty darn sure it
> doesn't. This could create a little problem. So I ask you all out there... HOW
> can we get the server to do variable updates to everyone near an object using
> a variable that has changed? I offer the following:

This is done now of course. How do you think the system knows what stuff
to download to you? Plus, for security purposes, all chat is funneled
through the server. It should be a simple matter to: #1 update all
variables when the user first wanders into visibility range. #2 keep track
of the user's ability to see an object and send the user updates on a
variable's value if it should change (kind of like chat dialog, but in
this case between the server and the browser).

--snip--

ScottyDM

--
Please send all SPAMS, FLAMES, and CONSPIRACY THEORIES to
scottydm at cwia.com
Send all other IMPORTANT CORRESPONDENCE to scottydm at codenet.net
___
/////\\ Digitally Enhanced Portrait of:
{|-0-0-|} Scott D. Miller,
| % | Silicon Mercenary
\===/ Freelance Chip Designer

always #5 FOO = ~FOO; // the sound of a beating heart

Nov 11, 1998, 8:08am

Ok, how about this:


VARIABLE TYPES, CREATION, AND MANAGEMENT

For the sake of simplicity, a simple 16 bit signed integer could go a long
way, however making it a signed 32 bit integer really does not "cost" much
extra. At this time I cannot see other types, such as floating point,
strings, or characters. Whether 16 bit or 32 bit, we should just pick one
and stick with it. At this time I believe that the 32 bit signed integer
is the better choice.

Variable creation will happen the first moment the server finds out about
a variable. Typically, this is the first time a variable is named in the
action field of an object and the object is "dropped".

Variable management can be facilitated by a command in the browser to list
all variables owned by the user in this world. The list would be dumped to
the chat window as a comma delimited list. The list is not broadcast but
only sent to the screen of the person who owns the variables (or has
inherited their privileges). Two commands would be recognized: A dump
command, and a command to delete variables (using wild cards). The
simplest and most extensible way to implement the commands is to type them
to the chat window. A special escape sequence starting in the first
character position on the input line would let the server know not to
broadcast the message to all in the area, it is a server command.
Something like:
\\ dumpvar (dump all variables to the chat window)
\\ delvar dooropen (delete the variable "dooropen")
\\ delvar foo* (delete variables "foo", "foobar", and "foofight")
\\ delvar * (delete all variables)

If you happen to delete a variable that is in use somewhere, then the next
time someone comes into visual range of the object that variable is
associated with, it is placed back in the hash table with the default
value 0 (unless the action field of that object happens to set the value
of the variable).


NAMING THE VARIABLE, CONVENTIONS TO USE -- I can see two possibilities:

#1 The variable can be any reasonable alphanumeric string. By reasonable,
I mean it starts with an alpha (upper or lower) and subsequent characters
in the name are alpha (upper or lower), numeric, or underscore character.
The system knows it is a variable name because it follows a keyword that
requires a variable name.

#2 The variable name MUST start with a restricted character, such as "%"
(I will use "%" in all the following examples, although this could be any
special character, e.g. #, $, *, etc. Note that only one special character
can be used for this function, we just need to pick one). The rest of the
characters in the name can be any alpha (upper or lower), numeric, or
underscore character. As the system is parsing the command line in the
action box, it will see the "%", realize that the attached string is a
variable name, and use it as such. The simplest and most consistent thing
is to ALWAYS force the use of the "%" character. Using this convention
will allow the use of variables in other places, such as in an animate
command:
create animate me stone 15 1 0 %foo
Where %foo selects WHICH stone texture to use (from 1 through 15). It
could also be used in the color command to make sign colors pulse and
change. It could even be used in a warp or teleport command as part of the
coordinates! Even though the variables are integers, in the case of a
teleport/warp coordinate, a decimal point could be assumed at the first
digit so that teleporting/warping could be to the nearest meter.

Picture this: A Star Trek like transporter device with buttons on a
control panel. People stand on the platform and someone pushes a button to
select the destination, then another button to "engage". You get the cool
sound and end up at your destination!

Now that I think about it, forcing the use of a special character as the
first character of every variable name makes a lot of sense. All further
examples will assume the use of the character "%".


SETTING THE VALUE OF THE VARIABLE -- I see a couple of possibilities here:

#1 The use of a keyword, such as "var" or "set":
var <NAME> <VALUE>
set <NAME> <VALUE>
The spaces are required delimiters and are the way the systems knows which
are the various parts of the command. Examples:
set %BamBam 5 // set "BamBam" = 5
set %foo (BamBam + 3) // set "foo" = 8 (assume "BamBam" is still 5)
set %foo BamBam+3 // legal because extra spaces are left out

#2 Use of an "=" sign to tell the system that you are setting the variable
(this works only with the use of a special character as the first
character of the variable name:
<NAME>=<VALUE>
<NAME> = <VALUE>
Where the extra spaces around the "=" sign are optional. Examples:
%BamBam = 5 // set "BamBam" = 5
%BamBam=5 // extra spaces are optional
%foo=(BamBam + 3) // set "foo" = 8 (assume "BamBam" is still 5)
%foo = BamBam+3 // set "foo" = 8 (assume "BamBam" is still 5)

Personally, I feel that #1 is more consistent with the existing way of
doing things: a keyword followed by a space delimited list of parameters.


OPERATORS TO USE FOR SETTING THE VARIABLE VALUE -- The following list of
operators may be useful:

Math operators:
+ addition
- subtraction
* multiplication
/ division, throw away the remainder
\ modulo, this is the remainder, throw away the quotient
Another pair of desirable operations might be the increment/decrement
pair, perhaps using "++" and "--". Increment/decrement kind of becomes a
special case of operator. Examples:
set %foo ++ // increments "foo"
set %foo %foo+1 // also increments "foo"
set %foo %fight++ // error, does not load "fight" +1 into "foo"
set %foo %fight+1 // is the correct way to do it (IMO)
This means that "++" and "--" must stand alone on the right hand side of
the equation.

Logic operators:
~ binary inversion
$ transform into true/false flag
& AND
| OR
^ XOR
The question to ask is whether we want logic operations to be performed
across the variable bit-by-bit, or whether we want to reduce the variable
to true/false and perform the operation on that basis. Perhaps we could
have both if we have a "convert from integer to flag" operation, say using
"$". Any non-zero value would be converted to -1 (true), while a zero is
simply a zero (false). Examples:
set %ewcord 13440&$%flag3 // ok, it is a little jammed up
set %ewcord (13440 & $ %flag3) // easier to read?
let me explain: if "flag3" is true it gets turned into a -1 by the "$"
operator (which has precedence over the other operators). The "&" ANDs
this true/false version of "flag3" now controls the value of "ewcord". If
"flag3" is true (-1, or #FFFFFFFF) the the 13440 passes passes through the
"&" operation and ends up in "ewcord", but if "flag3" is false (0) then
the "&" operator blocks the 13440 and "ewcord" gets the value of 0.

Special operators:
# means interpret the attached number as hexadecimal
Examples:
set %cows #F5 // this sets "cows" to 245
set %cows #F5+10 // "cows" = 255 as the "10" is decimal
set %cows #F5+#10 // "cows" = 261 as the "#10" is hex
Note that "#" always touches the number it is associated with. The
following examples are legal syntax (IMO):
set %cows (#F5 + 10)
set %cows (#F5 + #10)


------
WELL, ALL THIS IS WONDERFUL, BUT WE NEED TO DO SOMETHING MORE WITH THESE
GREAT VARIABLES

THE IF/THEN/ELSE COMMAND

Using the model of keyword followed by a space delimited list of
parameters, the "else_action" is optional:
if <TEST> <THEN_ACTION> <ELSE_ACTION>

Before giving concrete examples, it will be necessary to decide what to do
with the "<TEST>" parameter. The simplest and most powerful, is to simply
allow any equation, then reduce to a simple true/false (non-zero/zero)
test. Now the examples:
if %flag2 (solid off,visible off) (solid on,visible on)
// if "flag2" is true open door
if %touchd (noise eagle.wav) () // note the empty "else"
if %foo-3 () (noise scream.wav,set %foo 0)
// something is incrementing "foo"

This is wonderful, except there is no greater-than or lesser-than tests,
only this equal to zero (test for false). The following is a way to test
for a negative value, which is the foundation of greater-than and
lesser-than testing:
if $(%index4 & #80000000) <NEGATIVE_ACTION> <POSITIVE_ACTION>
if ~$(%index4 & #80000000) <POSITIVE_ACTION> <NEGATIVE_ACTION>

Where positive and negative are the sign of the variable "index4" and all
variables are 32 bit signed integers. It looks as if it might be a
desirable thing to have a simple operator to do this for us...


LOOPING CONTROL COMMAND

Again the model is keyword followed by a space delimited list of
parameters. There are a lot of ways to construct a loop command, for
simplicity's sake we should just choose one. It seems slightly more useful
to test first because it would allow loop exit without action in the case
the test comes out false. The idea of "while" the test is true do
"loop_action" seems to be an easily understandable construct. To be truly
useful a third parameter of "delay" is added, where delay is in
milliseconds (and is optional):
while <TEST> <LOOP_ACTION> <DELAY>
Examples:
while %foo (warp +0 +0 +1a,%foo+1) 2000
This would keep someone bouncing up and down and eventually hitting +750a
for a long, long time until "foo" hits 0.

while %lights %lights+1 1000
Could simply be used to increment "lights" for awhile. This could be used
in a tunnel entrance. On a floor piece at the tunnel entrance you could
put:
bump set %lights -9
Inside the tunnel you could have a button and a sign that says "lights on"
with the following action on the button:
activate while %lights %lights+1 1000
On the ceiling panels you could use a manhole1.rwx to look like a round
light fixture and put the following code on the next 8 "light fixtures":
create if ~$((%lights + 8) & #80000000) (animate me snow1. 1 1 0)
create if ~$((%lights + 7) & #80000000) (animate me snow1. 1 1 0)
create if ~$((%lights + 6) & #80000000) (animate me snow1. 1 1 0)
create if ~$((%lights + 5) & #80000000) (animate me snow1. 1 1 0)
create if ~$((%lights + 4) & #80000000) (animate me snow1. 1 1 0)
create if ~$((%lights + 3) & #80000000) (animate me snow1. 1 1 0)
create if ~$((%lights + 2) & #80000000) (animate me snow1. 1 1 0)
create if ~$((%lights + 1) & #80000000) (animate me snow1. 1 1 0)
Pushing the button then turns on the "light fixtures" in order at one
second intervals. Everyone could then see the lights were on until someone
again bumps that floor piece that sets "lights" back to -9. (dang, it
looks as if a test for negative operator is really needed)


------
This has gotten kind of long and involved. There is a lot more that could
be accomplished with server-side variable storage. I have left out some of
the more esorteric things like a CASE statement. IF seems to be the most
universally powerful thing (beyond just the existence of the server-side
variables). WHILE is useful too, but it does seem a little less intuitive
on how it could be used.

The most important thing to realize is that instructions are executed in
the order that the user finds them. So constructs that split case
statements (for example) across multiple objects will exhibit wildly
unpredictable behavior.

Most of the processing would need to be done in the browser, the server
only stores the variables (and displays/deletes them for the user on
demand). The server and browser already have other mechinisms in place
that could be used to insure that as variable values are updated in the
server, all users see the changes almost instantly.


ScottyDM

--
Please send all SPAMS, FLAMES, and CONSPIRACY THEORIES to
scottydm at cwia.com
Send all other IMPORTANT CORRESPONDENCE to scottydm at codenet.net
___
/////\\ Digitally Enhanced Portrait of:
{|-0-0-|} Scott D. Miller,
| % | Silicon Mercenary
\===/ Freelance Chip Designer

always #5 FOO = ~FOO; // the sound of a beating heart

Nov 11, 1998, 8:13am

Oops, dang, how did this get posted twice.

Stop, ignore this thread and follow the other one.

--
Please send all SPAMS, FLAMES, and CONSPIRACY THEORIES to
scottydm at cwia.com
Send all other IMPORTANT CORRESPONDENCE to scottydm at codenet.net
___
/////\\ Digitally Enhanced Portrait of:
{|-0-0-|} Scott D. Miller,
| % | Silicon Mercenary
\===/ Freelance Chip Designer

always #5 FOO = ~FOO; // the sound of a beating heart

Dec 3, 1998, 10:01pm

[View Quote] [View Quote] Well, I'm quite aware of the reasoning behind it. I just think that owners of
personal worlds should be given the option to say "adios" to it. Instead of normal,
large, and huge, use normal, large, huge, and unlimited. I paid for it, I'll kill my
framerate if I darn well please thank you very much! ::insert evil villain laughter
here::


> --snip--
>
> Here I strongly disagree. There is no way to limit the execution of a
> "line of code" in the action box to only once. Nor is there any way to
> control the order that objects are encountered in (which controls the
> order that the code is executed in). The only reason that create is used
> in modern programming languages is because it is the "modern" thing to do;
> that is it leads to easier to maintain code because it offers easy answers
> to niggling little questions like, "What is that!? <confused programmer
> points to a user defined name in some source code>". So in this instance
> "var" is not the same as a C/C++ "var" it simply tells what ever is
> executing the code that the next word is a variable, the = 0 is implied.
> And yes, every single time someone bumps the object, the variable is set
> back to 0. Although, scan down a little further to see another idea on how
> to parse variables.
>

Well, I was simply referring to the concept of the use of create to define a
variable. Every time you refreshed your objects the var would reset itself. But, if
we don't even need to define variables in the standard sense, the point is null and
void. And the other issue related to this is that the action field has a very small
maximum character limit.


> The actual creation of variables is quite simple actually, it happens
> automatically the first time you type that variable name into the action
> box of an object and then "drop" the object. Which brings up the problem
> of the hash table becoming hopelessly cluttered up with orphan variable
> names (they currently do not appear in any action boxes on any instances
> of any objects in the world). Perhaps some kind of on-line garbage
> collection could be used to periodically clean the hash table.
>
> --snip--
>
> Of course zort exists, you just named it in the following statement! I
> know your professors/boss/whoever will have a cow because there is no
> explicit declaration of variables. Too bad, real programmers know what
> they are doing without all this "touchie-feelie new-age programming
> clap-trap" (especially when it breaks the paradigm).

Pffft. I'm a high school freshman, my "boss" doesn't even know what a variables is
beyond that X he used in pre-algebra. :D


>
>
>
> Is it "activate zort = 0,..." or "activate set zort = 0,..." Actually,
> since AW is not case sensitive there is no easy method to make variable
> names stand out from the other stuff in the action box. May I suggest
> appending a special character to the beginning of the name, e.g. %zort. If
> the system (server or browser) sees something like "%zort=0" it knows that
> it needs to do a "set zort=0" (not that "%" means "set", it does not, "="
> means "set"). Without a special character, then the "language" must have a
> key word preceding the variable name to be able to make sense of stuff
> (and "activate" does not count since it can be followed by almost
> anything).
>
> In this example the use of the "zort<4" is unnecessary and the code could
> be rewritten:
> activate %zort = -4, for %zort (warp +0 +0 +1a, ++%zort)
> In "old style" code (my first post) it would be:
> activate var zort -4, for zort (warp +0 +0 +1a, ++zort)
> As long as zort (or %zort) is not zero, the loop continues. I know that
> having a test other than a simple true/false test is convenient, but
> believe you can get a heck of a lot done without it. This "for" command is
> interesting, but I'm not really convinced that it is all that hot (without
> additional controls, like how often it increments (ms of delay)). This
> behavior can be emulated by other techniques. However if the loop is
> decoupled from the object displaying the action, then interesting things
> happen (which is why the need for the delay command, like in animate).
>
> --snip--
>
> Hmmmm, I don't get it. Are you changing the syntax? How about if I retype
> it:
> activate begin
> set zort = 0; // or does zort = 0; work better?
> for (zort < 4) begin
> warp +0 +0 +1a;
> ++ zort; // sorry, is this correct C syntax for
> increment?

Yep, without the space between the ++ and zort, anyway.

> end
> visible off;
> solid off;
> end
> If this is what you had in mind then the correct syntax for the visible
> off etc. would be:
> activate zort = 0, for (zort<4) (warp +0 +0 +1a, ++zort), visible off,
> solid off
>

To tell you the truth, I can't remember what I was doing at the time. Been a month
now. :)


>
> Quite true. To prevent confusion I will use "var" to mean that the word
> following var is a variable to be set to a new value. Thus the correct
> code would be:
> activate var zort -4, for zort (warp +0 +0 +1a, var zort ++);
> create if zort (visible off, solid off) (visible on, solid on)
> This is of course if you want the clicked object to turn invisible while
> the person is being squirted up into the air (note the semicolon at the
> end of the first line). The ++zort has been bugging me, it just does not
> seem consistent with the way the other stuff works so I changed it just a
> little.
>
> Wow, this must really be getting muddled up and confused for most readers,
> we have a "system" <I laugh at that term> of syntax that is wildly
> inconsistent at this point.
>

See my next message for the big "DOH!" that relates to the fact that this whole
thing is not needed.


> --snip--
>
> This is done now of course. How do you think the system knows what stuff
> to download to you? Plus, for security purposes, all chat is funneled
> through the server. It should be a simple matter to: #1 update all
> variables when the user first wanders into visibility range. #2 keep track
> of the user's ability to see an object and send the user updates on a
> variable's value if it should change (kind of like chat dialog, but in
> this case between the server and the browser).

Couple extra packets... should be harmless enough.


>
>
> --snip--
>
> ScottyDM
>
> --
> Please send all SPAMS, FLAMES, and CONSPIRACY THEORIES to
> scottydm at cwia.com
> Send all other IMPORTANT CORRESPONDENCE to scottydm at codenet.net
> ___
> /////\\ Digitally Enhanced Portrait of:
> {|-0-0-|} Scott D. Miller,
> | % | Silicon Mercenary
> \===/ Freelance Chip Designer
>
> always #5 FOO = ~FOO; // the sound of a beating heart

1  |   Order by index