1  ...  10  11  12  13  14  15  ...  36  |   Order by default

Nov 29, 2002, 4:59am

Yep. Nice idea. And one to list all textures used in the object would be nice as also.

TechnoZeus

[View Quote]

Oct 16, 2002, 5:35am

Does it really matter? Last I checked, the wishlist newsgroup was only rad by a few of the people who post in it anyway. Yeah, it looks out of place to me too... don't know what it was supposed to be talking about.

Here's my wish for the list... that there was someone assigned as liason between the wishlist newsgroup and the ActiveWorlds design team, to sift through the wishlist for things that are worth doing, and moderate it to filter out the junk.

TechnoZeus

[View Quote]

Oct 16, 2002, 5:36am

Does it really matter? Last I checked, the wishlist newsgroup was only read by a few of the people who post in it anyway. Yeah, it looks out of place to me too... don't know what it was supposed to be talking about.

Here's my wish for the list... that there was someone assigned as liason between the wishlist newsgroup and the ActiveWorlds design team, to sift through the wishlist for things that are worth doing, and moderate it to filter out the junk.

TechnoZeus

[View Quote]

Oct 16, 2002, 11:41pm

After carefully considering this suggestion from the viepoint of a programmer, a builder, and a teacher, I have decided to go ahead and post it. These changes should be viable and efficient since most of them could re-use existing code. They should also be powerful and flexible to use, and easy to teach. I understand that there's a lot here and I have no expectations as for how much of this will get used or how quickly. I offer it merely as a list of suggested command enhancements.

Please pay particular attention to the simple changes in the move command, the rotate command, the corona command, the texture command, and the examine command.

I would like to suggest the following command enhancements for use in the Action field of building objects:


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

Nov 29, 2002, 5:13am

Yeahm I was asking Shamus to add something like that for a moon, only that it would "apear to be far away and behind things" like a skybox, would never go out of visibility range, and wouldnot be effected by the ambient lighting. That way, the moon object would go naturally through lunar phases based on the direction that the "sun" is shining on it from. I am also still hoping that he'ss add some kind of rotation ability to the directional lighting source so that it can orbit, and it's orbit can be tilted to a chosen angle.

TechnoZeus

[View Quote]

Nov 30, 2002, 5:37am

I like that idea. :)

Alternatively, you could probably have a bot keep count of the number of people in your world, and when the limit is reached, have the last person that entered be sent to the alternative location... but that would cut down the number of people you could have in your world by 1, and require a bot set up for that purpose to be running.

You're right, having the option to send someone to an overflow location would be nice... especially if the world settings (or at least the AW browser's message set) included a message to be sent to them explaining what happened.

TechnoZeus


[View Quote]

Nov 30, 2002, 5:42am

This one has been asked for in the past, and although I can't speak for the other people who have asked for it... I still would like to see it happen. :)

TechnoZeus

[View Quote]

Nov 30, 2002, 5:49am

Yes, a telegram command that works in the Action field would be nice, but what I personally think would be even nicer is having the option to telegram the person who owns an object you right click on when not in build mode. This is part of a set of suggestions I sent in a long time ago. Right now we are always in build mode, but that's inconvenient because it means when we're not building there is no use for the right click function except to feel your way around... and in a world with no object select you can't even do that... so making an alternative mode, like an exploration mode, would allow things like that to be added to a right click menu.

TechnoZeus

[View Quote]

Nov 30, 2002, 6:10am

I think what was being asked for is a way to set a limit manually, in addition to any preset limits. Some time ago I suggested that a maximum frame rate option be added, and set at a default value of 30 fps, because although some people may notice a flicker if a light flashes that slow (such as the vertical refresh rate on a monitor) the images in ActiveWorlds are not disapearing between frames, so most people can't see the difference between 30 fps and anything higher anyway... and those few that can see the difference could opt to set it a little higher if their processor can handle it. Personally, I would probably set it as 3 fps on the slow computers I'm running, so that it would never waste the little processing power I have keeping up a higher frame rate than necessary.

TechnoZeus

[View Quote]

Oct 24, 2002, 10:39pm

Did you write the bot program, or do you have access to the source code? If so, simply modify the bot to display each person't name along with their chat text, rather than just the chat text.

TechnoZeus


--
Operating System: Microsoft Windows 98 (4.10, Build 2222) A
Language: English (Regional Setting: English)
Processor: Intel Pentium III, 450MHz
Memory: 128MB RAM
DirectX Version: DirectX 7.0 (4.07.00.0716)
DX Setup Parameters: /WindowsUpdate
DxDiag Version: 4.07.00.0700

[View Quote]

Nov 30, 2002, 6:18am

How about a "Plant Object" function, that lets you type the object name into a field in or near the toolbar, and then click on the ground to drop a copy of it where you clicked?

TechnoZeus

[View Quote]

Nov 30, 2002, 6:27am

This sounds like a bug. Are you on the beta? Click Help --> About... and see what build number you have.

TechnoZeus

[View Quote]

Nov 30, 2002, 11:00am

That would tend to depend among other things on weather or not he's still using the same build as he was a month ago, don't you think?

TechnoZeus

[View Quote]

Dec 1, 2002, 9:54am

And how do you know? I read the whole thread, and I didn't notice any mention of it having been solved.

TechnoZeus

[View Quote]

Dec 2, 2002, 6:57am

How do you "know"? Did you major in deadlines in college? Is there some law of nature that says problems solve themselves in 3 weeks or less? Okay, so I was trying to post something helpful, and in reply I get people trying to help me understand how they percieve time. Although the attempt is appreciated, I don't think it's working.

TechnoZeus

[View Quote]

Dec 4, 2002, 3:09am

This is the wishlist newsgroup. True, the post that started this particular thread should probably have went into the beta bewsgroup, but perhaps the person who posted it wasn't on the beta team at the time, and anyway it's not my place to decide. What I knew about it at the time I responded to it is that it looked like a bug and that the person who mentioned it was probably correct in stating that it should be fixed. The logical thing to do at that point, in my poinion, was to ask for more information. If no more information was given I would have considered it a dead topic "at that time" and left it alone. If nobody replies to it at this time I would also consider this a dead topic and leave it alone. I did not feel, in my own opinion, that the right thing for me to do was to decide that it was a dead topic. In fact, the last reply to the thread up to that point ended in "maybe worth looking into" which sounds to me more like an unresolved topic than a dead topic. Perhaps I'm the only person reading this newsgroup who doesn't feel he has the mental capacity necessary to make an educated enough guess when it comes to deciding how impoerant something is to another person, but I know that I myself have things that I've posted years ago in this newsgroup that I'm still hoping will some day make it into a version of Active Worlds, and I'm guessing that I'm not the only person who has placed things in the wishlist more than 3 weeks ago that are still just as important as they were at the time they were posted and are still not implemented in a release fersion of Active Worlds. I don't consider them dead topics at all. Only dormant.

TechnoZeus

[View Quote]

Dec 1, 2002, 1:32am

No, a bot wouldn't do that just as easily. If you owned a world named "Bomb" and wanted people to be able to use the alias "Explosion" to teleport to it from where ever they happen to be, there is currently no way to program a bot to make that possible.

On the other hand, if each world was allowed to have one alias with more than 8 characters that the universe server would keep on file as belonging to that specific world, then either name could be used to teleport to that world. I don't know if it would be an "easy" thing to add, but at least it would be "possible" to add... and what's more, such an alias could be set in the world features so if the world owner wanted to change it they could do so at any time... although it would most likely be in their best interest not to change it too often but rather to settle on a name that works and is not taken, and keep it.

TechnoZeus

[View Quote]

Oct 29, 2002, 10:14pm

So add quantum supercomputers to the wishlist? :)

TechnoZeus

[View Quote]

Nov 2, 2002, 2:31am

You mean it would increase my frame rate? :)
TZ

[View Quote]

Dec 1, 2002, 1:44am

The idea of speed setting for each avatar has been suggested before, and I agree it would be good to have. Off hand, the only down side that I can think of to adding it right away would be that it would cause a lot more testing to be necessary in order to be sure that the extreme variations in avatar speed wouldn't cause unexpected problems with the collision detection, however this would be a great thing to have added in the next version of Active Worlds since the version we are beta testing not really sets everything up to be ready for it. :) Who knows, maybe we'll get lucky and they'll add it now... although I'm pretty sure if they do there will be a lot of people complaining about the testing taking too long, and of course if the testing gets cut short there will be even more people complaining about any unresolved problems with the collision detection under unxeptected conditions at unreasonable or at least unusual avatar speeds.

Good one for the wish list. :) Not sure if it was in here already, but now it is.

TechnoZeus


[View Quote]

Dec 1, 2002, 1:49am

Not really far fetched. Sure, there are probably better places for such things but if a person doesn't know where to find a better place to make their wish known... I've seen nothing official to indicate that they should be kept out of here. Besides, the people developing the SDK might benefit somewhat from knowing what kinds of things people would like to see in bots. It all ties together.

TechnoZeus

[View Quote]

Dec 2, 2002, 7:00am

Yep.... I think you're right. Now the information on where to look is here if it's needed. That could of course have been accomplished without the negativity.

TechnoZeus

[View Quote]

Dec 1, 2002, 1:53am

I tried to open the image mentioned, but it apears to no longer exist. Has it been moved, and if so where to?

TechnoZeus

[View Quote]

Dec 1, 2002, 2:02am

Different people will find different features useful for different reasons.

As far as going "option crazy" I actually like your idea of having an "overrideable" switch, not just on this one option, but on any option that might make sense to add one to.

TechnoZeus

[View Quote]

Dec 1, 2002, 2:12am

Actually, there are a lot of uses to allowing people to slide along objects. The main one is to keep people who don't aim very well from getting frustrated about not being able to move at all. Keep in mind that climbing a ladder is a type of slide detection also, so getting rid of it completely would mean just stopping dead in your tracks whenever you are in contact with pretty much any object other than something parallel to the ground plain such as a walk object. Terrain would also be basically unusable. What really needs to be done is to have it fixed, and I'm pretty sure they are already working on that. In addition to that, it may also be nice to allow some kind of world prefferences for just how it works, as in some worlds it may be more beneficial to assume that an object at a certain angle is meant to be climbed easily and not easily fallen off of to either side, while in another world it may make more sense to assume that such an object is meant to be an obstical which can be walked easily around, but climbed only with careful manuvering and extra effort.

TechnoZeus

[View Quote]

Dec 1, 2002, 11:24am

If I recall correctly, I believe I suggested this the very first time I suggested a syntax for a move command. I know I have since then... that's been a long time. This would really be a useful tool to have. It would also go perfectly with the moveto command and the enhancements to the move command that I recommended in my wishlist post "Command enhancements" on Wednesday, October 16, 2002. news:3dae1534 at server1.Activeworlds.com

There should also be a trigger for when the rotate command finishes a non-looping rotation, and also, a general trigger delay timer syntax as I explained on November 29, in reply to Strike Rapier's September 28th post entitled "Nosync (2 minute feature)"

TechnoZeus

[View Quote]

Nov 16, 2002, 4:12am

Ah yes, but smart parents will lay the law down and let the kid know that if they get caught using AW with that line deleted they'll lose their citizenship... or some other privilege they feel would be appropraite... and stick to it.

TechnoZeus

[View Quote]

Nov 16, 2002, 4:20am

Oh, there is a way around having it in the ini file or system registry... although I would not personally recommend it, the parental lock password "could" be stored at the universe server level and citizenships be purchased as full citizen or dependant citizen, where a dependant citizen would be registered as belonging to a specific full citizen... and perhaps some variation on that may be what they have already implimented in the latest alpha version... I don't know. I think we'll find out soon though.

TechnoZeus


[View Quote]

Nov 16, 2002, 4:06am

Add to this idea 3D gravity and gravitational field sensative auto-leveling. :)

TZ

[View Quote]

Nov 27, 2002, 12:07pm

Well, we have a 2nd axis now for flying, in the current beta build... although it's currently limited to a 180 degree range on angles. No rolling left or right yet, and no flying or walking upside-down yet... but it is currently possible to climb a hill while standing on your head, although you can't see where you're going unless you're in 3rd person view. Anyway... it's a start.

TechnoZeus

[View Quote]

1  ...  10  11  12  13  14  15  ...  36  |   Order by default