User:Gnu64/Feature requests/Software
Visual
Feature: Realistic Water (Ferruccio)
Active Worlds' water is barebones at best. Compared to Second Life, it can be set at any altitude as well as have waves as high as 10 meters for violent storms or otherwise. Therefore, the water simply needs graphical improvements through the use of techniques such as refraction (Already available in the RenderWare engine according to Ferruccio) as well as a smaller polygon grid for higher detail. As of now, the water is divided up in cells like the terrain, which makes it look too blocky. Graphical ideas:
- Refraction of contents underwater
- Reflection of overworld objects, with the ability to toggle what gets reflected out of: Sky, Terrain, Static objects and Dynamic Objects (Move/rotate commands, avatars)
- Physical interaction: Waves as water touches terrain or as avatars enter and exit.
- More flexibility: Dynamic translucency based on world lighting
Feature: Object Occlusion (Gnu64)
Object Occlusion is a feature being increasingly used in games to optimize a scene, where objects that are 100% hidden by an object in front is completely ignored and removed from the rendering pipeline. At the moment, Active Worlds does not do this and is the source of heavy, unnessacary lag in complex environments.
Take for example the Sharman Caves in SW City. A vast network of complex caves that make use of all sorts of graphical techniques. However this is all underground and overground travelers who may be using high visibilities such as 100 and 200m, may suddenly be hit lag-wise by the caves. This is due to the browser rendering them, including any commands such as light, texture, matfx and even envi, despite the fact they are completely hidden under the terrain.
The browser should implement techniques listed on this article so that scenes are optimized to not render any objects obscured by solid objects in front. A very simple occlusion method that can prevent the above situation is to not render anything underground if the user is above terrain altitude and vice versa.
Feature: Occlusion based on size + distance (Gnu64)
Building from the previous idea, Second Life also has occlusion based on the combination of both the object size and distance. For example, a button.rwx object is incredibly tiny, so there is no point to rendering it if it's 190m away from a user who has 200m visibility set. However, a rock10.rwx 190m away from the same user should still be rendered as it is clearly visible from that distance. Keep in mind however, commands such as "light" as well as triggers should still be rendered and processed, even if they apply on a button.rwx 190 meters away from the user, as they affect other objects quite visibly.
Improvement: Extend visibility options (SW Academy)
The current 200m cap is becoming too outdated and should be raised to a higher limit such as 600m or 1000m. Limits like those are still sensible, as wild limits such as 65535m (Settable in Second Life via debug options) would not only be moot, but will also strain the server and load areas which would more likely not be explored by the user.
Improvement: Extend visibility of avatars and movers from user (Gnu32)
At the moment, avatars and movers are only visible within the chat range, 200 meters. This should be extended so that movers, such as airplanes, may be visible from vast distances for realism purposes. The new limit should be the same as the fog limit of the world. However, these caveats must be kept in mind:
- Some movers have heavy particles, lights and so on attached, which can be irritating if they are visible from far away. Therefore, particles on these movers should be killed if the mover is beyond the 200m chat range.
- More bandwidth may be used if there is a lot of mover and avatar movement beyond the range to transmit their position information. Therefore, avatars and movers beyond the 200m range should have a 'movement framerate' of 2 FPS. This may make movement jagged or blocky but this won't be as noticeable from far (especially since the browser "tweens" the movement between 'frames' anyway).
Audio
Building
Feature: 'Visible' command Transitions (Joshua)
Adding a "time" argument to the visible command should give the object a fading transition to whatever visibility state was set. For example:
activate visible no time=10
This should make an object fade to invisibility in 10 seconds when clicked.
Feature: Combination of 'solid+visible' Commands (Gnu32)
A command should be added that is a combination of both the solid and visible commands, as many objects used in projects such as games or exploration environments make use of invisible "bump panels" which almost always use the command:
create visible no, solid no
This is both time-consuming and wastes cell space. Instead, one command should be sufficent to toggle both options in an object, such as:
create real no
The use of the term "real" implies if the object should be "real" or "realistic", ie. Be collidable and visible to the naked eye. Of course, by setting it as "not real", it loses both these traits, hence why this name is an appropriate choice for such a command.
Feature: 'Opacity' Command (See link above) (Gnu32)
Another obvious command to implement, 'opacity' should allow the object's transparency to be changed instead of having to use masks and other techniques. The opacity number should be a 1-byte range (0-255). For example:
create opacity 200
This would make an object translucent, with more opaqueness than transparent. There is one caveat that should be kept in mind with such a command:
- Surfaces already translucent on an object, such as the glass on a pp16.rwx, would need to be affected by a percentage of the set opacity based on how translucent it already is. It could be implemented so that the same opacity applies all over the object, which may be ok for some objects, but may ruin others.
- Serious glitching and artifacts may occur if this is applied to objects with texture masks.
Feature: RGB(A)/HSV(A) values for 'color' command (Strike Rapier)
The 'color' command should also accept a value in an RGB format, with each component in a 1-byte range (0-255), for example:
Syntax: create color RED BLUE GREEN create color 255 0 0
This would make an object red, which is equivalent to setting:
create color red create color #ff0000
This is merely a convenience idea, for those more comfortable with using RGB values. A good spinoff of this idea is allowing HSV values, or Hue Saturation and Value. Some designers prefer assigning color with this method. For example:
create color 360 128 255 type=hsv
This would give an object a pale shade of red. Note that the 'Hue' value has a range of '0-360', as these values are based on a color wheel. Finally, another good spinoff to this idea is to also allow a fourth "alpha" value for both types, which would be another method of applying opacity (see above idea) as well as setting a whole-object color. For example:
create color #ff000011 create color 255 0 0 10 create color 360 255 255 10 type=hsv
All three commands would make the object have a red color, but also become severely transparent.
Feature: 'Intensity' property for 'color' command, to allow tinting (Gnu32)
The color command should have an 'intensity' property so the object doesn't have to completely turn into the set color, instead it can have it's textures/colors tinted toward the set color. For example:
create color red intensity=225
This would give the object a very thick tint of red on all it's textures and colors.
World Settings
Improvements: Registry
A world's registry, when one is setup, is based in a text file stored with the world server itself, keeping bounding box information of objects for the sole purpose of encroachment prevention. A world's builders is forced to use the objects listed in the registry in order to use them because of this. The current registry system is shoddy at best in terms of flexibility and management, especially for AWI worlds with community OP managers and object donators.
On-the-fly Registry updates (Gnu32)
Registry updates really shouldn't have to be reloaded by the server every time, especially in large worlds such as AWTeen where this causes disruption. The server should just simply find the entry in the list every time an object is requested and cache the results for existing entries, while re-checking for new entries on an unknown object. For example:
- User builds a pole1m.rwx.
- Server detects an entry of "pole1m.rwx" in the registry and caches it. Does not look for it again until next object refresh interval.
- User builds a toaster.rwx.
- Server cannot find "toaster.rwx" and gives an error, object is deleted.
- Admin appends an entry for "toaster.rwx" to registry.
- Another user tries toaster.rwx again.
- Server finds entry, caches it.
Remote editing/uploading of Registry (Gnu32)
A problem being run into (as an example) by AWTeen's OP managers in the past is that object updates had to be done seasonally, as AWTeen uses a registry, therefore new objects must have their entries generated and emailed to AWI. This would take too long a response and when the time came the world would experience downtime and on a few occasions serious registry errors. Therefore, the world server should include some form of HTTP server or admin panel to remotely append or edit entries to the registry so that people such as future OP managers for AWTeen can manage the entries for themselves.
SQL-based Registry (Gnu32)
The registry should be made into a MySQL table like the other world settings which is easier to dynamically update and find entries off of, combining the "on-the-fly" updates idea. By turning it into a database, it's also much easier to give it remote access combining the above idea, via a PHP web page. Of course, inputs must be sanitized and security taken into account to avoid exploits.
Misc. Mechanics
Feature: Chat Channels (Captain MAD Mike)
Implementing chat channels into the software, a long needed and much useful feature. By adding global chat "channels" into the tabbed interface, global chat across all worlds is possible which makes communication much more easier. Other features suggested include standard chat "slash" commands found across chat networks, such as /color. There are two ways to go about this:
- A global chat system implemented into the uniserver coded from scratch, which allows for full flexibility
- An IRC-backend powered by a separate server or coded into the uniserver, which is not only easier but already available and powerful.
Feature/Bug-fix: Impersonate Session for Console Messages (Strike Rapier)
By allowing global bots to impersonate a session number in console messages, global chat systems can manipulate chat without sacrificing the ability to right-click the message in chat for a context menu or the display of chat bubbles. A clearer explanation: In normal chat, a message said by a user will appear above their heads (dependent on one's settings) and their message will be right-clickable in the chat window so the user can 'mute', 'add [the sender] to contacts' and etc.
However, global chat systems such as Hermes use console messages, and unless the message is formatted like so:
CITIZENNAME: MESSAGE
^ 1 tab space
The message won't be right-clickable or appear above the sender's avatar because the browser relies on the above chat message format to identify the sender. For example, in an RPG world the global chat bot would add the player's level in front:
[LEVELNUMBER]CITIZENNAME: MESSAGE
Of course, this means the message won't appear above the players avatar or won't be mutable via right click. Therefore, to tell the browser that the console messages are from certain users, a value such as AW_CONSOLE_IMPERSONATE should be settable in console messages. This way, the browser can allow the right-click context menu and display the chat above the sender's avatar.
Bug-fix: Disk loading of cache is SLOW (Gnu64)
A major source of lag while browsing vast distances of land in high visibilities is the loading lag of the cache. Every cell crossed by the user results in more objects being loaded from cache, which at the moment is impractically slow for smooth moving. The cache system should be optimized for faster loading and retrieval of cache as well as more memory being used for caching areas beyond the visibility range (of course, with a user-configurable usage limit).
Bug-fix: Cache is easily corruptible (Gnu64)
From what I can guess at how the cache system works, Active Worlds is always writing to the cache as the user downloads objects and explores areas. There has always been the problem where if the browser has crashed, the "object placement" cache becomes corrupt which can be annoying for users. The cache simply needs to be written to a temp file and then merged with the actual cache at a certain interval, on world change or on browser exit.
User Interface
Improvements: Telegrams
Store Telegrams Server-side (Gnu32)
Telegrams are currently stored client-side in a rather easy to explore file format that stores telegrams on any citizen that logs in via that client and receives telegrams through it. Instead the Uniserver should handle the storage of telegrams, which can allow for other features such as folders (see below). Of course, there should be a cap such as 250 telegrams per Citizen, with the ability to download the telegrams to the client and store them the classic way instead (for archiving or space purposes).
Telegram Folders + Saving Sent Telegrams (Legion)
A vital improvement to the telegram system, users should be able to organize their telegrams into folders or categories, such as "Event Invitations", "PPW's", etc. Automatic folders should include a "Trash" folder for deleted telegrams as well as the much needed feature to save sent telegrams.
Archivable Telegrams (Ferruccio)
Telegrams should be exportable in bulk or single selections via a right click option or an option should be available to dump all received telegrams to a folder. This makes it easier to keep large archives of telegrams for various personal reasons.
Full Date+Time Log on Telegrams Tab (Asuran)
Telegrams listed in the Telegrams tab should show the full received date + time (such as 21:15 Jan 01 2008) rather than just the day and time (such as Sun 21:15) which is ambiguous.
Mass Telegramming (equin0x)
There should be the ability to enter multiple recipients in a telegram for notices, warnings, etc. by putting the recipients in a comma separated list in the "Recipient" box or by multi-selecting a bunch of contacts from the contacts tab and adding a "Mass Telegram" context menu option.
Note that while this brings the potential problem of spam, as pointed out this will be ineffective due to easy blocking as well as less incentive to, as it is a citizen feature (therefore requiring pay, not worth wasting money on).
Improvements: Teleports
Tree View Teleports (SW Comit)
Teleports should be manageable in folders or categories to allow for easier management of teleports. For example, a folder could be made for the user's houses while another one for their favorite sights.