1  |   Order by index

Nov 23, 2002, 8:23pm

Quite a few of my suggestions for Active Worlds have ended up getting as features over the years, so I'm guessing that it either means I did a real good job of sending in suggestions were well thought out, or I'm not the only one who sent them in... or both. :) Sometimes Roland would join me in AW and try to convince me that some suggestion I had made couldn't be done, but I guess that was just his way of getting information about how best to aproach them because those ones almost always ended up getting used shortly after.

I hope a lot of the suggestions that I was told would be added some day are still on the to-do list, because I don't want to re-submit a bunch of them "just in case" they may have gotten lost... but some of the suggestions I sent in were so long ago that I'm pretty sure they are lost by now, and some of them I sent to people other than the development team because I simply didn't know any better... so here are a few of the ones that I sent to Shamus back in March of 1997 which haven't gotten used yet:

(Keep in mind that I wrote many of these after only 1 day in Active Worlds and all of them within my first two weeks so if they look half-baked, that's why. Look toward the bottom of the list for the commands that I think would still be really nice to see added. Any of these look familliar Shamus?)

Avatar Customization flyout menu to let the user select clothing color variations and/or skin tone for a personalized version of the selected avatar.
Teleport Duplicate of Object. (Pretty self explanatory. Should have an "Are you sure..." prompt.)
Full Object Inventory. (List all objects owned by user on an item by item basis.)
Teleport to Object's Location. (Choose object form a list of the N/S by E/W coordinates in which the specified owner has one ore more objects. Also usefull for finding lost Objects to delete them.)
An "Automatically silde out of contact with other objects when moved" check box, in the Object Properties dialog box, that would be checked by default. When checked, moving an object into contact with another object would cause it to align it's bounding box to the bounding box of the other object. If moved a full click (1/2 meter, at present) into another object, the object being moved would be moved to the first point in that same direction where it is no longer inside of another object. When this can not be accomplished reasonably, the object would only slide to a point where it is no longer in contact with any object belonging to another citizen, and a message would explain what happened. This feature would allow objects to be aligned to each other with a single click and would automatically prevent overlap when in use. It should have an easy to use keyboard shortcut for turning it on and off.
A "Follow object" checkbox, in the Object Properties dialog, that would cause your avatar avatar to be kept in the same position relative to the object(s) you are moving. This would allow a way to easily carry an object any distance without losing track of it.
A "Bring selected ojbects with" checkbox in the Teleport dialog (for teleporting your avatar) which would be availible if you have any objects selected when you go to teleport, and when checked, would cause the objects to be moved with your avatar to the destination even if teleporting to another world. This option would be off by default.
Vision enhancements for use while building, such as being able to select Wireframe mode or a hybrid with normal visibility for closer objects and wireframe mode for more distant objects.
Drop-boxes displaying the commands that are supported by an object, or the objects, sounds, textures, etc. that are available to select from. (or that are already cached.)

Here are some of the commands and command enhancement that would still like to see added:

Command abreviations, where the shortest alphanumeric sequence that distinguishes a command from other commands would be all that is necessary when followed by a special abreviation delimiter such as the period character.
For example, "animate me flame 1 1 0" could be written as "ani. me flame 1 1 0" or as "anim. me flame 1 1 0" and "teleport 0N 1E" could be written as someting like "t. 0N 1E"
The abreviations would work on commands and triggers. The triggers would be abreviated as follows...
a. = activate
ad. = adone
b. = bump
c. = create
Since triggers and commands can easily be identified by their position, it would be possible to assign the same abreviation to both a trigger and a command. For example, instead of needing to type "ani." as an abreviation for "animate" you could simply use "a." instead, which is the same as the abreviation for the "activate" trigger.
Whenever support for new commands gets added, they would not be assigned any abreviation that is already valid for an existing command, and when new triggers are added they would never be assigned an abreviation that is already valid for an existing trigger.

"Mutate" command.
Example: create Mutate 1 seed plant tree bigtree time=10
This example would change the object to seed.rwx after 10 seconds, plant.rwx after 20 seconds, tree.rwx after 30 seconds, and bigtree.rwx after 40 seconds. The numeric parameter would tell how many times to go through the cycle. Using the number 0 there would cause it to loop indefinately.
Alternate example: activate Mutate 1 chair time=60 name=object1, Mutate 100 onlight offlight time=1 name=object2
This alternate example would cause object1 to change into a chair.rwx object after 60 seconds, and would cause object2 to change back and forth for 200 seconds between being onlight.rwx and offlight.rwx at a rate of one change per second.
An mdone trigger could also be added to allow the mutate command's completion to start other commands.

Mixed Relative, and Absolute Warps/Teleports.
Example: bump Teleport 30N 40W +1.2A +180
This example would teleport the avatar that bumped the object to coordinates 30 North by 40 West at an altitude 12 meters higher than the starting point, and facing the opposite direction.
Alternate example: activate Teleport 3139N 106E +0; bump Warp +0 +0 2.5A +180
This alternate example would teleport a person who clicked the object to coordinates 3139 North by 106 East, at ground level without changing the direction it's facing, and would send a person who bumps into the object to an altitude of 25 meters and turn them around to face the opposite direction without changing their north-south or east-west position.

Scale command.
Example: create Scale 2 1 .5 time=50
This example would scale the object to twice it's normal width, exactly it's normal height, and half it's normal depth, over a period of 50 seconds. If the "time=" parameter is left off, the object would be scaled instantly.

Accelerate command.
Example: bump Accelerate +2S -1E
This command would have an effect similar to "walking" or "flying" in which a small acceleration would be added to your movement with no associated sound effects. Mainly useful with the adone speudotrigger or any type of timer to produce effects such as a wind tunnel with a strong updraft, or with the bump trigger for situations where you may be in contact with an object for an extended period of time, like conveyor belts, escalators, or water that carries you downstream. In this example, the avatar would be accellerated in a South by SouthEast direction.

Here is a list of the previous command examples in the proposed abreviated form:

c. Mu. 0 seed plant tree bigtree time=10
a. Mu. 1 chair time=60 name=object1, Mu. 100 onlight offlight time=1 name=object2
b. Tel. 30N 40W +1.2A +180
a. Tel. 3139N 106E +0; b. W. +0 +0 2.5A +180
c. Sc. 2 1 .5 time=50
b. Ac. +2S -1E

Thanks for your patience. I know that's a lot... but at least it's shorter than the original list. :)

Of course, these are all ancient suggestions. Personally, my favorites aren't in this list... but I still like these too. Especially the scale command, although that accellerate command would most likely be more trouble to add then it would be worth. I think the simplest command to add would be a tint command, since all that would be is a color command that doesn't clear the textures off on the object before changing it's color. :)
Oddly enough, I suggested a tint command to Roland not long after the time when I came up with these, and it took some doing to convince him to add the color command, which ironically had a bug in it initially that made it act like a tint command on masked objects.

If you really like one of these, please mention it through the "suggestion box" link at http://www.activeworlds.com/FeatureVote/

TechnoZeus

Nov 24, 2002, 12:04am

[View Quote] Not that I was asked but, reasons why I would say no to some of these ideas
if I were the software development decider guy:

>
> Avatar Customization flyout menu to let the user select clothing color
variations and/or skin tone for a personalized version of the selected
avatar.

Requires excessive coding and interfacing, excessive coding on the avatar
(and therefor longer download) more textures, etc. For what is a very
minor, albeit nifty, perk.

> Teleport Duplicate of Object.

While nifty and handy this would also be open to far too much abuse. Even
by accident objects would land in all kinds of stupid places and could be
damned hard to track down if they're small or the object code is typo'd into
a triangle lost in a hill or something. No thanks! Rather there should be
a command allowed for "create seed object" or something and it tosses out a
standardized object like sign1 wherever you happen to point or stand or
something.

> Full Object Inventory. (List all objects owned by user on an item by item
basis.)

This would rapidly clog the bandwidth on a large build, that's a LOT of
information to ship out to a user. Far better to get the propdump if you
can and get it out of that. What use would this be anyway?

> Teleport to Object's Location. (Choose object form a list of the N/S by
E/W coordinates in which the specified owner has one ore more objects. Also
usefull for finding lost Objects to delete them.)

would require the one above to implement.

> An "Automatically silde out of contact with other objects when moved"
check box, in the Object Properties dialog box, that would be checked by
default. When checked, moving an object into contact with another object
would cause it to align it's bounding box to the bounding box of the other
object.

As a builder this would quickly get me royally ticked. I want the thing to
go where i send it, I can turn on snap to grid, perhaps just have it
defaulted off, like snap to grid, it could "snap to neighbor obj." but it
still would only work in worlds that have a world registry as otherwise the
browser doesn't actually know the boundaries of the objects.

> A "Follow object" checkbox, in the Object Properties dialog, that would
cause your avatar avatar to be kept in the same position relative to the
object(s) you are moving. This would allow a way to easily carry an object
any distance without losing track of it.

That would be useful, but tricky to setup as the movement of the object you
are shifting seems to be calculated more in relation to your position than
to the world's position? Not sure.

> A "Bring selected ojbects with" checkbox in the Teleport dialog (for
teleporting your avatar) which would be availible if you have any objects
selected when you go to teleport, and when checked, would cause the objects
to be moved with your avatar to the destination even if teleporting to
another world. This option would be off by default.

Oh so potentially abuseable, and furthermore, a nuisance when dealing with
assorted OPs. It's a sad thing that there are people who's favorite hobby
is getting reactions out of other people and who will happily go for the
negative reaction. They really do ruin the game for everyone. Still we
have to try and 2nd guess these brats and not give them new tools.


> Vision enhancements for use while building, such as being able to select
Wireframe mode or a hybrid with normal visibility for closer objects and
wireframe mode for more distant objects.

Ooohhh, we will all have to buy newer faster computers for sure now!

> Drop-boxes displaying the commands that are supported by an object, or the
objects, sounds, textures, etc. that are available to select from. (or that
are already cached.)

Now THAT seems like a workable idea, although again it would increase
computation and bandwidth requirements.

>
> Here are some of the commands and command enhancement that would still
like to see added:
>
> Command abreviations,

Hmmm, it'd be more like it's got all new commands, only shorter, but then
you have to leave in backwards compatibility to old builds so you just have
twice the computation required.

Anyway, Enough trashing your ideas as that isn't my intention, I just want
to point out that when designing AW they have to consider three things
first: user abuse, bandwidth optimization and keeping the computer
requirements as low as possible. nobody on a 486 is going to try to do AW
but neither do you want to exclude everyone with less than a pIII power
computer. You make more money if you are more accessible. So when
designing and adding and stuff you have to weigh those factors against the
degree of gain that said feature will add. In addition, how much work is it
to add that feature? The programmer's are doubtless paid hourly or by
piecemeal, not standardized salary and even if they were, or were a partner
in the profits, they'd still be thinking "gee, do I really want to sit and
put in the time it takes for THAT feature?" So even though it might be a
really cool idea, these are reasons why it might not be implemented.

Nov 24, 2002, 4:28am

Okay... I'll try to reply to this in the order I found it...

[View Quote] TZ

>
>
> While nifty and handy this would also be open to far too much abuse. Even
> by accident objects would land in all kinds of stupid places and could be
> damned hard to track down if they're small or the object code is typo'd into
> a triangle lost in a hill or something. No thanks! Rather there should be
> a command allowed for "create seed object" or something and it tosses out a
> standardized object like sign1 wherever you happen to point or stand or
> something.
>

I agree with you. Not one of my better ideas... but I had been in AW only a day. :)
Also, keepin mind that Alpha World was much more "empty" back then, and there were no bots to place "seed" objects with.

TZ

>
>
> This would rapidly clog the bandwidth on a large build, that's a LOT of
> information to ship out to a user. Far better to get the propdump if you
> can and get it out of that. What use would this be anyway?
>

Well, actually what I had originally intended was for it to be a list of the objects you own which you actually have cached... but I worded it poorly. It was meant to eventually be much more interactive than a propdump though... allowing a person to perform operations on the objects in the list, such as deleting them, teleporting to them, easy selection of multiple objects, setting the display to filter out objects that fit a certain description, or showing only objects made within a specific range of dates, etc. I was trying to think ahead, so I saw this as a feature that could lead later to other enhancements. Again, keep in mind that this was written the day after the day I first looked at Active Worlds. The reason I included it here is so that people can see what some of my really old ideas were... and again, I agree... not one of my better ideas... not by a long shot. :)

TZ

>
> would require the one above to implement.
>

Yep. :)

TZ

>
> As a builder this would quickly get me royally ticked. I want the thing to
> go where i send it, I can turn on snap to grid, perhaps just have it
> defaulted off, like snap to grid, it could "snap to neighbor obj." but it
> still would only work in worlds that have a world registry as otherwise the
> browser doesn't actually know the boundaries of the objects.
>
Not true. Roland said the same thing when I suggested the Ctrl-Insert method of duplication, and I pointed out at that time, as I am pointing out now, that the default functionality can be used whenever the size of an object can not yet be determined but since it is the browser that does all the collision detection, it knows more about the shape of an object than just what the registry says, as soon as the object finishes downloading. As for it frustrating you, I don't see why it should since this is a feature you would have to turn on to use. If you didn't bother to turn it on, it wouldn't effect anything. Also, it's functionality wuold be slightly different than that of a "snap to neighbot object" in two ways going by the definition of the Snap to Objects idea that I sent in long after this one, and in at least one way even by a simpler definition. First, this would work based on actual colision detection, whereas Snap to Objects would be more easily implimented to go by proximity of vertices in one object to the vertices in another object. Second, when active, this function would cause an object duplicated in the middle of a crowded area to be automatically moved as far as necessary to get it out of the "stuff" around it. Again, I was thinking in terms of what we had to work with at that time, and back then a way for a newbie to place their first object so easily would have been a plus. Also note that in combination with the "Follow object" seggestion that I made right after this one, it would be easy to simultaneously find open ground and place an object there. Again... not something I would recommend implementing "as is" at this stage, but it's food for thought anyway... from the mind of someone who had a fresh unique view of AW at the time of writing it. :)

TZ

>
> That would be useful, but tricky to setup as the movement of the object you
> are shifting seems to be calculated more in relation to your position than
> to the world's position? Not sure.
>

Nope... the object's position is a set of coordinates in relation to ground zero. This one would be a sinch to add. The only down side I can think of to it is that it may move your aratar into an object, which could be a problem in worlds that don't allow pass-thru. Of course pass-thru was "always" allowed back then, so this was not a consideration.

TZ

>
> Oh so potentially abuseable, and furthermore, a nuisance when dealing with
> assorted OPs. It's a sad thing that there are people who's favorite hobby
> is getting reactions out of other people and who will happily go for the
> negative reaction. They really do ruin the game for everyone. Still we
> have to try and 2nd guess these brats and not give them new tools.
>

The object data would come with. The object model would have to be supplied by the world's object path... and if unavailable, it would display as the little black unknown.rwx triangle. If the world had a registry which did not support that object, the results would be the same as any other time you tried to place an object by that name in that particular world.

TZ

>
>
> Ooohhh, we will all have to buy newer faster computers for sure now!

I'm guessing that was sarcasm? I never was any good at that.
My "maximum" visibility at that time was 30 meters, at 1 frame per second if I was really lucky and in a nearly empty area. Wireframe mode would have been VERY nice to have, because I would not have had to build "virtually blindfolded" anymore. Want to see what I built without being able to see any more than the closest half a dozen or less objects? Take a look near 3139N 106E in Alpha World. Maybe then you'll see why I thought at that time it would be nice to have support for wireframe rentering.... and that was only my first project. The worst one was the fleet of ships I built in Mars world that flew patterns around each other. I built the whole thing "litterally" without being able to see what I was doing at all. I had an object selected, my 3D window shrunk down as small as it would go, my settings optomized, and a frame rate of about 1 frame every minute. I would count the keystrokes out carefully so as not to overfill my keyboard buffer, doing everything via keyboard, and then walk away and do something else while my computer spent the next hour or two catching up with me. Yes, this idea is out-dated... but it wasn't at the time it was written... and it would probably be very easy to add now, and would still allow us to more easily see certain types of details while building than we can with only one viewing option. What I would rather see at this time is a wide angle lense effect... but then many of us probably WOULD have to buy faster computers.

TZ

>
>
> Now THAT seems like a workable idea, although again it would increase computation and bandwidth requirements.
>

Thank you. :)

Small increase in computation, and only while actually using the feature. No increase in bandwidth usage or requirements if the list of cached files was used to produce the list of available files... which to me seems the only really sensable way, since you can always enter them the old fashioned way.

TZ

>
> Hmmm, it'd be more like it's got all new commands, only shorter, but then
> you have to leave in backwards compatibility to old builds so you just have
> twice the computation required.
>
Not really. A small enhancement to the parsing routine could allow the current command lookup to suffice, but even if it was done as if they were aliases to the old commands and triggers, it would still only be a small increase in the amount of computing necessary to look up the commands. Very small, sompared to the rest of the parsing task... and no additional computation beyond that. Of course, the gains of this particular feature enhancement may or may not out-weigh the work involved in adding it, but it would shorten a lot of Action lines, and allow the same command line length to hold more useable information.

TZ

> Anyway, Enough trashing your ideas as that isn't my intention, I just want
> to point out that when designing AW they have to consider three things
> first: user abuse, bandwidth optimization and keeping the computer
> requirements as low as possible. nobody on a 486 is going to try to do AW
> but neither do you want to exclude everyone with less than a pIII power
> computer. You make more money if you are more accessible. So when
> designing and adding and stuff you have to weigh those factors against the
> degree of gain that said feature will add. In addition, how much work is it
> to add that feature? The programmer's are doubtless paid hourly or by
> piecemeal, not standardized salary and even if they were, or were a partner
> in the profits, they'd still be thinking "gee, do I really want to sit and
> put in the time it takes for THAT feature?" So even though it might be a
> really cool idea, these are reasons why it might not be implemented.
>

I know what you mean. Roland and HamFon both made use of a lot of my ideas, and told me that they kept them in a separate place for just those reasons... because I tend to think from multiple perspectives including the perspective of the builder, the programmer, the world designer, the universe administrator, and even the people who's bottom line is how much profit potential it has. These were some of the "first" ideas I sent in, so of course they are not as well put together as most of the ones I have submitted since then, but I know some of them and some parts of others could still prove useful, if for nothing more than a historical perspective... although History is my worst subject so I won't get too far into that. :)

TechnoZeus

1  |   Order by index