1  ...  18  19  20  21  22  23  ...  36  |   Order by default

Mar 17, 2003, 4:50am

I'll accept that answer, as soon as the AW browser comes with a built in programming language and compiler for writing bots. :)

TZ

[View Quote]

Mar 16, 2003, 10:04pm

That depends on how you define most requested.

Some people tell each other what they want. Some tell only someone they expect to have a good technical understanding of it. Some are afraid to tell someone who they think will look at it in a technical way because they don't feel qualified to discuss it on that level. Some write in letters to a specific employee of the company or a specific department. Some post their ideas here in the wishlist newsgroup. Some use a combination of many different ways to get their point across. Some people confide in the same person every time, if they even tell anyone at all, and other people message everyone they can think of about it. Some are calm and quite about it while others are loud and persistant. Some people find that using as few words as possible is their preffered style, and others like to go into excessive detail. (That one would be me, by the way.) So while I can tell you many frequently requested additions, I don't think anyone is really fully qualified to say which are the "most" requested features unless you mean specifically which ones they personally have heard requested most often or by the most people.

TechnoZeus

[View Quote]

Mar 17, 2003, 8:41am

But what specifically do you mean by "most requested"?

TechnoZeus

[View Quote]

Mar 18, 2003, 5:28am

It's a little of both. Notice, there is a link on that page to a suggestion box. As I said, there are many ways of defining what is meant by "most requested" features. One way is which features have been sent through the suggestion box. Another way is which features have gotten the most votes. Another way to define it would be which requests have been paid the most attention to, and yes this one is as valid as the rest because a lot of requested features are nowhere near possible in the forseable future. I thought of giving that address as a response also, but decided to ask for clarification first to make sure I would be giving an acceptable answer. Looks to me like the answer was quite acceptable to the person who asked the question, so... works for me. :)

TechnoZeus

[View Quote]

Mar 18, 2003, 1:28pm

:)

TZ

[View Quote]

Mar 18, 2003, 11:11pm

The scale command would be the simplest of those to implement, in the form suggested.
scale <x> <y> <z>
Of course, the command could be enhanced later to something like...
scale [x] y [z] [loop OR noloop] [sync OR nosync] [reset OR noreset] [name=name] [time=time] [wait=wait] [lag=lag] [shared=flag]

I'll re-post the original message I got that from in a separate thread, in case anyone missed it, since it's been abou half a year now. :)

TechnoZeus

[View Quote]

Mar 19, 2003, 12:32pm

I thought I would add a comment here for the sake of those who have voted on the FeatureVote page to Increase the maximum cell data limit, that if they had intended to get the building space raised in public building worlds they've wasted their vote and should change it to something else. The items being voted on are for features, not settings of individual worlds, and very few worlds are currently set to the highest available cell data limit because it is already way more than most computers can handle when people start packing cells as full as they can. If the maximum cell data limit were to be increased, it is likely that several of the few worlds with their cell data limit set to "huge" would reduce it to "large" to avoid problems... thereby having the effect of reducing the cell data limit in those worlds.

TechnoZeus

[View Quote]

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, 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, 11:53pm

Long enough to contain what's being said.

TZ

[View Quote]

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

Mar 30, 2003, 4:33pm

I don't think that's what he meant. My understanding of the suggestion was to make it so that you could allow anyone using the privileges of a certain citizen to enter your world (as it works now) or choose to allow the actual citizen to enter but not someone who has acquired their privileges. In other words if you set your world to allow anyone using my privileges to build in your world but did not set it to allow someone using the privileges I had turned on to build in your world, then I would not be able to build in your world at that time even though someone else who had acquired my privileges could build "as me", but alternatively if you had set it to allow "me" to build in your world, then I could build in your world regardless of who's privileges I have turned on but if someone else acquired my privileges that would not give them build rights.

TechnoZeus

[View Quote]

Mar 31, 2003, 7:14am

Kind of thought so. :)

TZ

[View Quote]

Mar 31, 2003, 7:17am

She did say "already talking" in bold.

TZ

[View Quote]

Apr 1, 2003, 6:31pm

Right. She wasn't asking to have them added to the whisper list. She was asking to have those that are talking in bold also show in the whisper list in bold.

TechnoZeus

[View Quote]

Apr 3, 2003, 5:55am

Sorry. I will attempt to state it more clearly this time. She was talking about the name in the whisper list, not the whispers themselves. In other words, the suggestion was to have the names of public speakers show up in the whisper list in bold when they are listed.

TechnoZeus

[View Quote]

Apr 3, 2003, 3:46pm

Don't know. I would think so, but I'm not sure. I'm also not sure how much I like or dislike the idea, although I can see both good and bad points to it. I just wanted to make sure the idea gets understood. So far, you've spoken against it 3 times wihout even knowing what it is. That of course if your option to do if that is what you wish, but I wouldn't want anyone reading your negative comments about what you thought was being asked for to mistake them for negative comments about what really was being asked for... so I hope I have helpped clarify things for you.

TechnoZeus

[View Quote]

Mar 31, 2003, 7:22am

Me too. :)

TZ

[View Quote]

Mar 31, 2003, 7:25am

Actually, having it show up in the "Remember current location" box (which should probablt be renamed to "Remember Location" if a location field was added to it) would be a completely separate addition from that of adding the same information to the right hand colum in the Teleports list (which currently doesn't have a right hand colum at all). Either of those could be done independantly of the other. I like the idea of changing the "Remember current location" box with one field to a "Remember Location" dialog box with a "Label" field and a "Location" field.

TechnoZeus

[View Quote]

Mar 31, 2003, 9:54am

I wish there was a syntax in AW to specify more than one name when sending a command to a named object.

For example, if the * character could be used as a wild card, then you could put...

create name thing.a

create name thing.b

activate light name=thing.a, texture wood1 name=thing.*

of alternatively, if a symbol such as & or + could be recognized as joining names, then you could do something like...

create name firstone

create name anotherone; adone texture metal1 name=firstone&lastone

create name andanother, animate lastone&me stone 15 15 100, astart; adone animate firstone&me wood 7 7 1000, astart firstone&andanother

create name lastone

...where each separate line represents the Action field for a single object.

(Anyone out there actually understand what I just said?)

TechnoZeus

Apr 2, 2003, 1:09am

Thanks. Me too. :) I'm glad someone understood it. I was getting a little worried when nobody replied to that question. :)

TechnoZeus


[View Quote]

Apr 2, 2003, 8:45am

Well, I did ask if anyone understood it... and he's the only one to reply so far. :)

TZ

[View Quote]

Mar 31, 2003, 8:05pm

I wish there was a way to mark an object as having a persistant state or to save values to variables, so that you would be able to have a door that's been opened stay open even if it gets out of visibility range. I would preffer to have the default behavior like it is now, but the addition of a "persist" command that would cause the object to act as if it had never left visibility range, and a "reset" or "reload" (or recreate?) command that could be used when you want to reset the object as if it were non-persistant and had gotten out of range and back, would be very useful.

For example, I was just playing my Fireflies game in NewAW, and got up to a score of 111101101101 so far, and when I stopped to look in the beta newsgroup I found that to check on something reported there I'll have to change worlds... which means my score will be reset to 0 when I return. Now, I know this can be done with bots, but I like built-in features... so I'm posting this one to the wishlist. :)

TechnoZeus

Mar 31, 2003, 9:04pm

Then I guess a lot would have to be remembered by the browser if you left that world. This is no more of a potential problem than the risk of someone doing the same thing with almost any other command, although in combination with other commands it could get to add up quite a bit.

By the way, I only meant persistant within a single session. Closing and restarting Active Worlds would release all persistant values. Also, I hadn't really meant for the command to me able to be issued with a name= parameter, both because of that potential complication and also the fact that having to put the command on the object itself could give the Active Worlds browser a heads up on which objects might be made persistant, so that it could make preperations if needed. On the other hand, a "time=" parameter might make sense, so if the object is out of range for longer than that time (or perhaps if the persist command was not re-issued within that period of time and then the object got out of range) it's persistance would expire. A default time of 1440 minutes would make sense if no time parameter is specified, so that the object would persist for a full day before expiring and going back to being treated like a non-persistant object until the persist command is again used on it.

TechnoZeus

[View Quote]

Apr 5, 2003, 12:34pm

So if you had a sign that said...
http://www.activeworlds.com

it would be converted after a property dump and re-load, to a sign that says...
http:
www.activeworlds.com

Are you sure that's what you want to have happen?

By the way, what is represented in your example by "Number" and what is the condition before the else (false?)?

TZ

[View Quote]

Apr 6, 2003, 3:52am

Ah, okay. I didn't catch that index thing. :)

So... where would the index be stored? In the string, or would it just be tagged on the end and delimited by the end of line?

TechnoZeus

[View Quote]

Apr 5, 2003, 8:30pm

Yep. This is a known bug... or I should say, has been reported in the past. It's not on the current bug list, so I'll post it in the beta newsgroup. Thanks.

By the way, if you try to teleport to anywhere other than 0n 0e 0a it will still teleport you to ground zero (0n 0w at ground level, facing north).

TechnoZeus

[View Quote]

Apr 7, 2003, 5:42am

I like that idea, but it would limit another idea which I've suggested in the past... which is to add an alternative syntax of the move command based on the syntax of the rotate command that only uses the Y axis, and have the alternative move command syntax not restricted.

TechnoZeus

[View Quote]

Apr 8, 2003, 7:21pm

Hmmm... I wonder then if this is something that should be removed from the help files, or something that is planned to be changed. Anybody know for sure?

TechnoZeus

[View Quote]

1  ...  18  19  20  21  22  23  ...  36  |   Order by default