scott d. miller // User Search

scott d. miller // User Search

1  2  3  4  |  

irc-like cmnd line interface

Oct 28, 1998, 2:04am
[View Quote] What I observed one day at AW GZ was a tourist named "Dr Bob" who was being such
an extreme pest that most people muted him. After several name changes (and
remaining muted the whole time) this person left and came back after about a
minute (with yet a different nickname), not muted this time. They acted a little
better, but they had a peculiar style of moving their avatar around that made us
suspect that it was the original person. After awhile it became obvious it was
them and many of us muted him again.

This makes it seem as if IP address (even if dynamic) is the way a tourist is
muted, and that "Dr Bob" must have dropped his connection to his ISP and signed
on again to become unmuted.

Perhaps we could do some experiments to confirm this. Another test is that
tourist can have *exactly* the same name; mute one, are the rest muted too? I
suspect that IP address is how it is done, and not nickname.

ScottyDM

--
Scott D. Miller
General Manager & Principal Consultant
Arête, Ltd.

Please use the return e-mail address of: scottydm at codenet.net

irc-like cmnd line interface

Oct 29, 1998, 6:25am
[View Quote] Sounds like a reasonable speculation Paul. If we really wanted to know we should
go on AW and test it out.

ScottyDM

--
Scott D. Miller
General Manager & Principal Consultant
Arête, Ltd.

Please use the return e-mail address of: scottydm at codenet.net

Idea: if-then-else through obj. actions (server-side variables, etc.)

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

Idea: if-then-else through obj. actions (server-side variables, etc.)

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

Idea: if-then-else through obj. actions (server-side variables, etc.)

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

Idea: if-then-else through obj. actions (server-side variables, etc.)

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

Idea: if-then-else through obj. actions (server-side variables, etc.)

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

Custom avs are here! - yippee!

Nov 24, 1998, 11:54pm
[View Quote] Right on Dean;

If you want to fight FIRE, you use WATER.

What a concept, ehh?

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

This newsgroup

Nov 23, 1998, 11:47pm
[View Quote] Oh? Are we going to start a real programmers thread now? As in real
programmers code in Fortran...

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

This newsgroup

Nov 23, 1998, 11:50pm
[View Quote] Tyrell, you are a little wrinkled TROLL with pointy ears and big lips.

<waiting to see if Eep² is dumb enough to take the bait>


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

Re: Custom avs are here! - yippee!

Nov 26, 1998, 7:50am
[View Quote] Lame argument Fluxen;

The real world works exactly the way Dean suggested. Show up under dressed
or over dressed just about anywhere in RL and you get censored. Show up in
Saudi Arabia wearing the wrong thing and you get arrested. Show up at the
beach in Rio (Brazil) wearing the wrong thing and you are viewed as a
tourist, idiot, or prude. What is wrong with the idea of wanting to
control the use (allow or disallow) of custom avatars in one's own world.

Because different worlds have different "ratings", it may be possible to
to tag an avatar with a rating as well. As long as the avatar's rating is
lower or equal to the world's rating, it is allowed to be used there (if
custom avatars are allowed in that world). The problem is that the rating
of the avatars must be voluntary.

Perhaps there needs to be a way to visually "mute" an offending avatar --
turn it into a "tourist" avatar.

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  2  3  4  |  
Awportals.com is a privately held community resource website dedicated to Active Worlds.
Copyright (c) Mark Randall 2006 - 2024. All Rights Reserved.
Awportals.com   ·   ProLibraries Live   ·   Twitter   ·   LinkedIn