1  |   Order by default

Apr 6, 2000, 2:57am

hehe funny... but uh... no one cares.

[View Quote]

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, 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 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.

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

Mar 11, 2000, 11:48pm

This is a multi-part message in MIME format.

------=_NextPart_000_00C2_01BF8B9B.03D2C680
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


[View Quote] Quite true... and unlike Napster, AWCOM really couldn't handle any big =
MP3-related legal issues.=20

But uh.. still... all hail Napster!
Winamp doesnt take much CPU load (I run AW, Winamp, two Visual Studio =
instances and 3 browsers at once with no prob on my P2300 64meg comp).
=20
My question is this... why doesn't someone just make a frontend for =
mp3s? Only people who are in to them are gonna use them/care anyway and =
they'd all download the frontend software. Not sure about AW third =
party software limitations, but that shouldnt be a prob. If a non =
working action tag such as
create mp3 URL
were used, the frontend would pick up on it(using the sdk), download =
the mp3 and play it using it's own engine.
Not to difficult....anyone feel up to it? I'll work on it if noone =
else will.

Plugins! AW needs to support plugins! For example a plugin to play MP3s =
when it reads "create mp3" or one that... Well whatever, but plugins are =
a must for a program like this. DLLs tossed into a /plugins directory =
and loaded on startup or some such setup... just like 3d studio max. =
Imagine the possibilities for 3rd party improvements to the software.

-RecilS
[View Quote] ------=_NextPart_000_00C2_01BF8B9B.03D2C680
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 =
HTML//EN">
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<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>recils &lt;<A href=3D"mailto:No at Yes.com">No at Yes.com</A>&gt; wrote =
in=20
message <A=20
=
href=3D"news:38bca1b7 at server1.Activeworlds.com">news:38bca1b7 at server1.Act=
iveworlds.com</A>...</DIV>
<DIV><FONT color=3D#000000 size=3D2>Yeah limiting the size of mp3s =
would=20
work.&nbsp; The mp3 area is probably not the safest place for AW to go =
right=20
now, as pirating issues woul become huge.&nbsp; I'm sure 'mp3 =
warehouses' and=20
such places would spring up, offering all sorts of songs.</FONT></DIV>
<DIV>&nbsp;</DIV></BLOCKQUOTE>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Quite true... and unlike =
Napster, AWCOM=20
really couldn't handle any big MP3-related legal issues. </FONT></DIV>
<DIV align=3Dleft>&nbsp;</DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>But uh.. still... all hail =

Napster!</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
<DIV><FONT size=3D2>Winamp doesnt take much CPU load (I run AW, =
Winamp, two=20
Visual Studio instances and 3 browsers at once with no prob on my =
P2300 64meg=20
comp).</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>My question is this... why doesn't someone just =
make a=20
frontend for mp3s?&nbsp; Only people who are in to them are gonna use=20
them/care anyway and they'd all download the frontend software.&nbsp; =
Not sure=20
about AW third party software limitations, but that shouldnt be a =
prob.&nbsp;=20
If a non working action tag such as</FONT></DIV>
<DIV><FONT size=3D2>create mp3 URL</FONT></DIV>
<DIV><FONT size=3D2>were used, the frontend would pick up on it(using =
the sdk),=20
download the mp3 and play it using it's own engine.</FONT></DIV>
<DIV><FONT size=3D2>Not to difficult....anyone feel up to it?&nbsp; =
I'll work on=20
it if noone else will.</FONT></DIV>
<DIV>&nbsp;</DIV></BLOCKQUOTE>
<DIV><FONT face=3DArial size=3D2>Plugins! AW needs to support plugins! =
For example a=20
plugin to play MP3s when it reads "create mp3" or one that... Well =
whatever, but=20
plugins are a must for a program like this. DLLs tossed into a /plugins=20
directory and loaded on startup or some such setup... just like 3d =
studio max.=20
Imagine the possibilities for 3rd party improvements to the=20
software.</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>-RecilS</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; =
PADDING-LEFT: 5px">
[View Quote] ------=_NextPart_000_00C2_01BF8B9B.03D2C680--

Mar 11, 2000, 11:38pm

Beta, full, who cares, it's been so many years.... so many long, hard years
since....... .... Actually I don't think AWCOM ever added a useful feature
yet. =D

[View Quote]

Mar 11, 2000, 11:41pm

You know what I want? Quake engine style mouselook. You know,
hyper-sensitive left/right/up/down control with pinpoint accuracy. And an
MP5 to shoot at... well no, just mouselook will do I guess.

[View Quote] I hear you can make an N64->PC converter port thingie for a few dollars
worth of parts... but I dunno how =D

>
>
[View Quote]

Mar 16, 2000, 12:21am

Well you make a door by having it go visible off solid off right? Problem?
Well, when you open the door, it only opens client-side. This means that
everyone else sees it as closed and you glide through a closed door on their
screen. Minor annoyance? Yep. But think of the other option and the
advantages.

EXAMPLE:
pp01.rwx action: activate solid off, visible off

A simple "door" that goes away when clicked on. That's nice. Wouldn't it be
better if the activate trigger could be set up to set some kind of perminant
state for the object? So that it would stay open until closed somehow.

EXAMPLE:
pp01.rwx action: activate state.solid=0, state.visible=0 (note that I made
up an example command structure just to show the idea.... as far as I know
those are not real AW vars)

In this example, clicking on the door actually changes the object itself,
setting these two variables (solid and visible) to 0, or off. So the door is
opened and will remain open for all eternity until someone does whatever is
needed to return it to normal. Or until the builder edits the object which
would probably reset it.

A simple example, but it could be really useful. Especially for games and
the like (Note that I realize bots can be used to do this by removing and
replacing the object or actually putting create solid off commands on the
object when it's clicked - but this is a real waste or resources and efforts
and time and so on).

More variables could exist, even things like pos.x, pos.y, pos.z which could
be used to actually move the object by a click, bump, etc.

Taking that a little farther, the commands like create visible off would be
totally obsolete as the object's state.visible variable could be set while
placing the object (through some modification to the build window)

Adds more to bot interaction too... A bot can then tell if, for example, an
object is solid and if it's okay to walk through it ... thus creating sort
of a collision detection bot (though this would take more work than that)
....... I'm sure there's better examples, I just don't want to think of them
right now.


I know this has been around before... but I like to toss things up anyway.




----------------
You must die! I alone am best!

Apr 6, 2000, 1:26am

[View Quote]
Though most likely only due to the fact that a number of them are common
sense issues (not that AWCI actually HAS much common sense, but that's
another issue entirely), and not them actually reading it....
Hey, look at it this way. At this rate we'll get multiple dynamic colored
light sources, just like those first introduced in Quake2, in AW4.0 about 6
years from now. At least it's not software rendering now I guess. =P

>
[View Quote]

1  |   Order by default