1  |   Order by index

Mar 18, 2003, 11:13pm

I'm re-posting these suggested command enhancements for anyone who might have missed them.

For all commands;

A "delay=" parameter could be added to make the command happen after a specified period of time. If a "delay=" parameter is specified before the first command after a trigger, it would apply to all commands assigned to that trigger. This would allow people timers to be implimented without having to use the animate command for them every time.


For the animate command;

animate [loop OR noloop] [tag=tag] [mask OR nomask] object-name animation-name imagecount framecount framerate [framelist] [color=color] [mask=mask] [size=size] [shared=flag]

Support for the "loop" and "noloop" flags as found in other commands to set the looping status of the animate command would be more intuitive to many people than use of the astart command for simple animations. Since "loop" would be the default, it would be supported only to allow flexibility in code writing.
The "color=" parameter would allow the applied textures to be pre-lit a specific color.
The "mask=" parameter would allow a specific single mask to be applied to all frames of the animation sequence rather than using the default mask naming technique.
The "size=" parameter would specify a magnification factor for the textures and masks by dividing the UV values originally inside the object by the value of the size parameter.
The location of the "tag=" parameter within the syntax should be made more flexible. Also, the "tag=" parameter should allow negative values for tagged surface exclusion.
The "shared=" parameter would allow the effects of this command to optionally be shared with other people within chat range. The default would be "shared=no".


For the astart command;

astart [name] flag [frame=number] [shared=flag]

The "frame=" parameter would set the frame in the same way as the frame command does, but without the need for using a separate command. Program code used by the frame command could probably be called to accomplish this.
The "shared=" parameter would allow the effects of this command to optionally be shared with other people within chat range. The default would be "shared=no".


For the astop command;

astop [name] [shared=flag]

The "shared=" parameter would allow the effects of this command to optionally be shared with other people within chat range. The default would be "shared=no".


For the color command;

color color [name=name] [mask=mask] [size=size] [tag=tag] [shared=flag]

Support for the "loop" and "noloop" parameters as found in other commands to set the looping status of the animate command would be more intuitive to many people than use of the astart command for simple animations. Since "loop" would be the default, it would be supported only to allow flexibility in code writing.
The "mask=" parameter would allow a specified mask be used in blanking out the underlying texture before the color is applied, rather than simply blanking out the whole thing. This would not cause transparency, but rather selective coloring.
The "size=" parameter would specify a magnification factor for the mask, if used.
The "tag=" parameter would allow only specific tagged surfaces to be effected by the color command. Specifying a negative tag number would mean all surfaces without that tag. For example, tag=-100 to not color the sign surface of a sign object.
The "shared=" parameter would allow the effects of this command to optionally be shared with other people within chat range. The default would be "shared=no".


For the corona command;

corona off [name=name] [shared=flag]

corona texture [loop OR noloop] [sync OR nosync] [reset OR noreset] [mask=mask] [size=size] [name=name] [color=color] [brightness=brightness] [time=time] [wait=wait] [fx=fx] [lag=lag] [shared=flag]

An alternative syntax should be added to turn off the corona on a specified object.
The "loop" and "noloop" flags can be used to specify weather or not the corona effect repeats. The default would be loop.
The "sync" and "nosync" flags indicate whether the corona effect is synchronized to universe time. The default would be sync. The "nosync" flag would be useful for creating corona effects in which different coronas are at their most opaque at different times even though they are all changing at the same rate.
The "reset" and "noreset" flags indicate whether to leave the light as it is at the beginning of the effect (reset) or as it is at the end of the effect (noreset) durring the wait period or at the end of a noloop cycle. The default would be noreset.
The "color=" parameter should allow a color to be specified the same as if a light command had been used with a "color=" parameter. In fact, the same program code could be re-used. If a light command also specifies a "color=" parameter, the color of the corona would depend on the last "color=" parameter to have set it.
The "brightness=" parameter would set the opacity of the corona the same as if a light command had been used with a "brigntness=" parameter. In fact, the same code could be re-used. If a light command also specifies a "brightness=" parameter, the opacity of the corona would depend on the last "brightness=" parameter to have set it.
The "time=", "wait=", and "fx=" parameters would effect the corona in exactly the same way as those of the light command. This would allow such effects to be applied to coronas without having to add extra lights to the scene, and would thereby help improve performance.
The "lag=" parameter would cause the specified lag time to be subtracted from the universe time before using the resulting time for synchronization of this command.
The "shared=" parameter would allow the effects of this command to optionally be shared with other people within chat range. The default would be "shared=no".


For the examine command;

examine [x] [y] [z] [reset OR noreset] [wait=wait] [time=time] [shared=flag]

The "x", "y", and "z" flags would each specify an axis that the object is allowed to rotate around when dragged with the left mouse button The default would be to allow all three (as it does now).
The "reset" and "noreset" flags would specify weather or not the object is restored to it's original orientation when released. The default would be "reset" so that if neither is specified the object would go back to it's original orientation as it does now.
The "wait" parameter would specify how long the object will remain oriented as it was when released. This will be usefull for things like dragging a door open, and then letting go to walk through the open door.
The "time=" parameter specifies a period of time over which the object will rotate to the orientation it would have been in if it had not been dragged, from the orientation it was dragged to.
The "shared=" parameter would allow the effects of this command to optionally be shared with other people within chat range. The default would be "shared=no".


For the frame command;

frame [name] [+/-] number [shared=flag]

The "shared=" parameter would allow the effects of this command to optionally be shared with other people within chat range. The default would be "shared=no".


For the light command;

light [loop OR noloop] [sync OR nosync] [reset OR noreset] [type=type] [color=color] [brightness=brightness] [radius=radius] [name=name] [fx=fx] [time=time] [wait=wait] [angle=angle] [pitch=pitch] [lag=lag] [shared=flag]

The "loop" and "noloop" flags can be used to specify weather or not the a light effect repeats. The default would be loop.
The "sync" and "nosync" flags indicate whether the light effect is synchronized to universe time. The default would be sync. The "nosync" flag would be useful for creating lighting effects in which different lights are at their brightest at different times even though they are all changing at the same rate.
The "reset" and "noreset" flags indicate whether to leave the light as it is at the beginning of the effect (reset) or as it is at the end of the effect (noreset) durring the wait period or at the end of a noloop cycle. The default would be noreset.
The "wait=" parameter specifies how long to wait at the end of the each cycle of the light effect before ending or repeating it.
The "lag=" parameter would cause the specified lag time to be subtracted from the universe time before using the resulting time for synchronization of this command.
The "shared=" parameter would allow the effects of this command to optionally be shared with other people within chat range. The default would be "shared=no".


For the move command;

move [x] y [z] [loop OR noloop] [sync OR nosync] [reset OR noreset] [time=time] [wait=wait] [name=name] [lag=lag] [shared=flag]

The addition of a syntax that allows specification of the "y" parameter without specifying the "x" and "z" parameters serves two purposes. First, it simplifies commands for such objects as elevators. Second, this syntax would not have to be considered a special command since it only allows the object to be moved up and down. It would also reduce the learning curve since the rotate command supports a similar syntax.
The "lag=" parameter would cause the specified lag time to be subtracted from the universe time before using the resulting time for synchronization of this command.
The "shared=" parameter would allow the effects of this command to optionally be shared with other people within chat range. The default would be "shared=no".


For the moveto command;

moveto varname [time=time] [wait=wait] [name=name] [shared=flag]

moveto [varname.x OR x] varname.y OR y [varname.z OR z] [time=time] [wait=wait] [name=name] [shared=flag]

This would be a new command which would function much like the move command except using absulute coordinates for the destination instead of relative coordinates.
The "varname" parameter would be a variable name which points to an object that has been assigned using the new "set" command.
Adding a dot (period) character and the letter x, y, or z to the variable name would allow only the x, y, or z, location value of the source object to be specified as a target x, y, or z coordinate.
This would be very useful in setting up complex object movements.
Unlike the move command, the resulting location of the moved object would be used as it's new origin for subsequent move, moveto, or rotate commands.
The "wait=" parameter would cause all subsequent move or moveto commands applied to the same object to be postponed until the specified wait time after the completion of the move to the destination location.


For the name command;

name name [shared=flag]

It seems to me that it used to be possible to "change" an object's name once it had been set. I would like to see that ability added back into Active Worlds.


For the noise command;

noise URL [overlap] [shared=flag]

In this unique case, the "shared=yes" parameter would cause the effects of this command to be sent to other people within chat range, using with the noise located in the 3D space at the location of the person who's computer is sending it. The default would be "shared=no".


For the picture command;

picture URL [update=seconds] [name=name] [color=color] [mask=mask] [size=size] [shared=flag]

The "color=" parameter would be used to prelight the texture with the specified color.
The "mask=" parameter would be used to specify a transparency mask.
The "size=" parameter would be used to scale the texture and mask by dividing the original UV values inside the object by the value of the size parameter.
The "shared=" parameter would allow the effects of this command to optionally be shared with other people within chat range. The default would be "shared=no".


For the orbit command;

orbit varname [x] y [z] [sync OR nosync] [time=time] [loop OR noloop] [reset OR noreset] [wait=wait] [name=name] [lag=lag] [shared=flag]

The new orbit command is dependant on the new set command for it's origin varname parameter.
The varname parameter would specify a variable name which has been set using the "set" command to point to a specific object. That object's current location would be used as the origin of the rotation started by the orbit command. In other words, the orbiting object would litterally orbit around the object pointed to by the varname parameter. An object's orbit and rotation would be independant of each other.


For the rotate command;

rotate [x] y [z] [sync OR nosync] [time=time] [loop OR noloop] [reset OR noreset] [wait=wait] [name=name] [lag=lag] [shared=flag]

The "lag=" parameter would cause the specified lag time to be subtracted from the universe time before using the resulting time for synchronization of this command.
The "shared=" parameter would allow the effects of this command to optionally be shared with other people within chat range. The default would be "shared=no".


For the scale command;

scale [x] y [z] [loop OR noloop] [sync OR nosync] [reset OR noreset] [name=name] [time=time] [wait=wait] [lag=lag] [shared=flag]

The new scale command would allow an object to be scaled in real time.
The individual parameters and flags would work much the same as in the move command.


For the set command;

set [varname]

The new set command would set a variable to point to the object that issued the command. This pointer could then be used by other commands to borror attributes of that object such as it's current location, orientation, visibility setting, and so on.
The varname parameter specifies the name of the variable to assign the pointer to.
Similarly to the way the name command allows one subsequent command to effect any number of objects, the set command would allow one object to effect any number of subsequent commands.


For the sign command;

sign ["sign text"] [color=text color] [bcolor=background color] [name=name] [texture=text texture] [btexture=background texture] [mask=text mask] [bmask=background mask] [shared=flag]

The "texture=" parameter would allow a texture to be specified for the sign text either instead of or in addition to a text color.
The "btexture=" parameter would allow a texture to be specified for the sign's background, either instead of or in addition to a background color.
Implement the "mask=" and "bmask=" parameters as you see fit, if you implement them at all.


For the solid command;

solid [name] flag [tag=tag] [shared=flag]

The "tag=" parameter would allow surfaces with the specified internal tag to be made solid or non-solid.


For the teleport command;

teleport [world] [+/-][north/south coordinate][N/S] [+/-][east/west coordinate][E/W] [+/-][altitudeA] [+/-][direction]

The syntax specified in the help file looks very flexible, but in fact is quite rigid. I would like to see more flexibility added to the actual syntax. For example, it would be nice to be able to mix relative and absolute coordinates, or specify just an altitude without anything else.
Same goes for the warp command, which I would also like to see get back it's lost ability to accept a world name.

For the texture command;

texture texture [mask=mask] [tag=tag] [name=name] [color=color] [size=size] [shared=flag]

The "color=" parameter would be used to prelight the texture with the specified color.
The "size=" parameter would be used to scale the texture and mask by dividing the original UV values inside the object by the value of the size parameter.
The "shared=" parameter would allow the effects of this command to optionally be shared with other people within chat range. The default would be "shared=no".


For the tint command;

tint color [name=name] [type=type] [tag=tag] [shared=flag]

tint +/- color [name=name] [tag=tag] [shared=flag]

The new tint command would be used to change the color of an object without changing it's textures.
The "type=" parameter or the "+" and "-" flags would be used to specify how the color is applied. For example, "+" for additive and "-" for subtractive.


For the visible command;

visible [name] flag OR opacity

The "opacity" parameter could be used to make an object semitransparent by specifying a value such as .5 or any value in the range of 0 to 1.
An opacity value of 0 would act the same as "visible off" or "visible no" does now.


TechnoZeus

Mar 19, 2003, 5:05am

Nice collection :)

A comment on the Orbit command :

in the dynamic OP script I use a (RWX) translate instead that
can be used together with a rotate to create the orbiting effect.
This combination is a little more versatile as you can use
the translate alone to change the model location in relation
to the base point permanent.


[View Quote]

Mar 19, 2003, 11:11am

Ah, but if combine the use of the orbit command with the set command, you can get nested orbits. :)

TZ

[View Quote]

Mar 26, 2003, 5:45pm

How long do your posts have to be?

---
D a n

Mar 26, 2003, 11:53pm

Long enough to contain what's being said.

TZ

[View Quote]

Mar 27, 2003, 12:30am

[View Quote] Just give the gist, your ideas are not going to be implemented.

The chances of what's here even being considered is a 1:1000000 chance (my estimate).
You have better odds playing the scratch off lottery cards and hitting the jackpot.
Especially if your idea is a remake of current commands. We all know what happens
when the dev-team messes with current "standards."

--Bowen--

Mar 27, 2003, 3:50am

Estimate all you like. I choose to do something about it, rather than leave it to chance. Many of my ideas do in fact get implemented, not just in Active Worlds, much more than that. Think of it this way. If you were trying to find your way in a previously uncharted land which you knew nothing about, and durring your journey many people each offered you a map they had made. Which maps would you be more likely to use? Would you use the maps with a lot of work put into them which supplied you with detailed and accurate information that consistantly proved useful or would you use the maps that were scribbled in haste onto a napkin or a piece of toilet paper?

TechnoZeus

[View Quote]

Mar 27, 2003, 10:40pm

technozeus <TechnoZeus at usa.net>:
> Estimate all you like. I choose to do something about it, rather than
leave it to chance. Many of my ideas do in fact get implemented, not just in
Active Worlds, much more than that. Think of it this way. If you were
trying to find your way in a previously uncharted land which you knew
nothing about, and durring your journey many people each offered you a map
they had made. Which maps would you be more likely to use? Would you use
the maps with a lot of work put into them which supplied you with detailed
and accurate information that consistantly proved useful or would you use
the maps that were scribbled in haste onto a napkin or a piece of toilet
paper?

translation: Maybe if I type more - they'll consider it. Which would you
like - a detailed map or a TP map?

maki

Mar 27, 2003, 11:05pm

It's not how much you type that makes a difference. The question asked was "How long do your posts have to be?" and my answer was "Long enough to contain what's being said." I meant that exactly as I said it. Scribbling on an entire roll of toilet paper doesn't make it a better map, but reducing a good map to a few miscelaneous scribbles doesn't improve it any either.

TechnoZeus

[View Quote]

1  |   Order by index