some Active Worlds 4.1 features SL could use

http://help.activeworlds.com/ lists new features for Active Worlds 4.1. Some of these things SL doesn't have:

1. Zones : SL needs this for at least under water. SL already changes lighting/fog under water so why not other things like gravity, splash sound/effects, etc (without having to wear an attachment all the time!)?
   
2. Particles
   1. Particle type: sprite, facer (apparently there's a difference between the 2 terms), flat panel, or model. SL particles can only be sprites.
      
   2. Particles can have gravity. While SL particles can have downward force, it's not true gravity (especially with bouncing).
      
   3. zone-exclusivity
      
   4. camera position
      
   
   
3. camera objects: SL 1.9's new camera commands might be the same thing
   
4. smooth rotate/move: SL's rotate and position functions always have slight acceleration/deceleration and can't just move abruptly.
   
5. GUI - dockable/floating windows: SL's interface could seriously benefit from something like this! The inventory window doesn't need to be open all the time and could more intuitively slide (though I would prefer "pop" in/out of view. This could also work for the object edit window, IM window, etc. AW4+'s vertical tab panels are a bit too thick for my tastes though.
   
6. terrain: 1km elevation range (500m above/below 0 altitude): SL's is only 8 METERS
   
7. VoIP: voice chat
   
8. GIF/PNG textures
   

SL already has and AW now has:

1. downslide: avatars slide down slopes (AW doesn't have a formal physics engine so physics only applies to avatars)
   
2. global events: all users can see triggered (touch/bump) events (opening doors, playing sounds, etc)
   
3. screenshot key
   

Old features AW has but SL doesn't (and should):

1. external models: old debate but I still think it's valid that SL should allow external models (i.e. 3DS) but, since non-parametric model (SL's prims) vertex manipulation can be bandwidth-intensive, only allow them to be static for the most part (could still allow full-object color, light, full-bright, texture, etc changes)
   
2. terrain
   1. editing: vertices can be moved to any vertical position instantly, unlike SL's slow terrain editor
      
   2. holes
      
   
   
3. light
   1. type: point, cone, spot - SL only has point
      
   2. radius: object-independent, can be over 10m - SL light radius limited to 10m (max prim size)
      
   3. brightness: seperate from object color
      
   4. effects: blink, fade in/out, fire, flicker, flash, pulse - SL can do blinking/flickering but only prims will register it fast enough (but not always in recent builds); the ground lags considerably. Some things SL should NOT do server-side!
      
   5. coronas: SL has these in the debug menu but can't be specified per light source like AW can. AW's world light source's (i.e. the sun) texture (normal + corona) can also be changed, unlike SL's static textures (and badly-gradiented corona)
      
   
   
4. client-side effects: along with light, rotation and movement/position are much smoother in AW (aside from SL's llTargetOmega rotation function) because they are client-side. SL doesn't need to do everything on the server. Position should have an llTargetOmega-equivalent (llPositionOmega?) and can be interpolated on the client so it looks smooth.
   
5. sky: while AW doesn't have cellular automata clouds, its sky looks MUCH better than SL's through the use of 3 cloud layers (see World Features (no direct link to sky but it's towards the bottom) for more info
   
6. water: while SL's water looks better (with pixel-/vertex-shading ripple effects anyway), AW's water is far more configurable (see World Features link above for more info)
   

I think AW and SL should just merge...

Some good suggestions there!

I like the idea of zones in sl, that would be fantastic. Especially if we could create our own zones with definable parameters for gravity, wind etc. Tons of neat things could happen with that!

As a note on the particles....
It is interesting that they list Sprite and Facer. A facer is usually termed a billboarding sprite, it always faces the camera with two of its axis, the third can usually be rotated by the user to produce a spinning effect (highly effective visual trick for simulating turbulance and adding additional layers of complex motion). A Sprite on the other hand is also usually defined as something that always faces the camera, the difference here being either the sprite or the facer can have its rotational values explicitly defined or actively facing the camera.

Can you clarify flat panel for us? If its what I am thinking it is, it wouldnt be necessary if your sprite or facer can have certain rotational axis disabled or explicitly defined.

I totally agree with the need for these, the number of things we could do increases dramatically with the addition of particles that do not always face the camera. A good example of this would be a single particle expanding ring of dust or magic as the avatar touches down on the ground. A custom rotation of 0,0,0 would cause it to lay flat on the ground and never rotate, so it would look like an expanding ring if the initial size was zero and the end size was 5,5,5.

By Zone-exclusivity do you mean that you could tell the particle emitter not to emit under water or something to that effect?

The last bullet point in the particles says Camera - Can you clarify what you mean by this? I'm probably missing something obvious but I dont see how this is connected.

Well, according to the particles link...: "The particle is a flat panel that can be rotated into any position." so your guess is as good as mine.

This is already possible in SL and doesn't look bad with camera-facing particles. I've seen some vehicles/jetpacks use this effect to simulate blowing dust that "hugs" the ground.

I'm more interested in having SL particles use prims/objects instead of textured planes!

Sweet, thanks for the clarification!


I am all for emitting prims and objects, Unreal3 has that ability, it was exceedingly usefull for explosions and such.

You can create an effect with multiple particles that hug the ground but I havent been able to create a single non billboarding particle that hugs the ground, the difference lies in cost, if I can create an effect in one particle thats a really good thing.