User talk:SignpostMarv Martin/Archive/Implementing new features

From Second Life Wiki
Jump to navigation Jump to search

More sophisticated IM features

  • Seconded with a big hell yes. In a large group, it's difficult to keep track of a conversation when there is a mass exodus from the session. It's annoying having the system spam the window. SignpostMarv Martin 07:51, 9 January 2007 (PST)

Shortcut/Link/Alias function in Inventory

A pure viewer based solution can "only" be a hack at best. A possible implementation could be:

  1. ) Change the viewer, so that when a drag and drop operation is performed on a 'no-copy' item, the error is trapped
  2. ) for each error, register the UUID of the object in a special notecard
  3. ) When presenting the contents of a folder in the viewer, preset a mixture of the real contents and the contents of the note card
  4. ) Hide the special notecard
  5. ) Handle folder drops onto the avatar
  6. ) Handle moving of the special links
  7. ) Handle deletion of the special links
  8. ) Handle deletion of the original 'no-copy' item

This will only a partial solution, as an scrips running on the servers will still see the real contents of the folder.

Yea, I realized that this would really have to include a new Inventory Type ID - but do the servers do checking for type IDs? This may be something that can be done client-side with either no server-side change or only one very minor one - the assignment of a Type ID. For instance: Assume the new Inventory Type of Link, which simply stores the UUID of the original object. The simplest thing to do with them regarding copying would be to make them either no-transfer, or "delete on transfer" - they simply go away if you try to transfer them. In every other way, it behaves as a normal inventory item. Buckaroo Mu 09:15, 11 January 2007 (PST)
This definitely could be fudged by using a series of specially named notecards (for configuration data), allowing the feature to be implemented without requiring modifications to the server
SignpostMarv Martin 10:03, 11 January 2007 (PST)
It could be fudged with notecards - but how many hacks do you want in SL? The assignment of an additional inventory type at the server end, as far I as can tell from the viewer source, would require probably two lines of code. We need to work with LL to see if they would support this inclusion, rather than make kludges that work but are far less elegant, and may break scripts. Buckaroo Mu 16:16, 12 January 2007 (PST)
You're forgetting something: the servers aren't built for dynamic assets. 'Fudging' it would allow the community to decide on features and interfaces while Linden Lab make the significant changes to the server required for this to work.
SignpostMarv Martin 21:12, 12 January 2007 (PST)
If you fudge this via notecards, serverside scrips working on inventories will see the inventory as it really is. In effect making life complicated for LSL scripts, because now they have to parse a notecard as well.
Duffy Langdon

DirectX3D Hardware Acceleration

The OpenGL code is scattered all over the entire codebase. You'd have to abstract out all the 3D code first, it wouldn't be an improvement it would be a complete rewrite.

GPGPU Support

Multiple Monitor Support

  • Seconded I've been wanting this since I only had one monitor :-D SignpostMarv Martin 11:13, 10 January 2007 (PST)


Embedded scripting language for client-side plugins

One way of doing this would be to exploit the xpcom architecture of Mozilla. Exposing the viewer core as xpcom interfaces. That way the flexibility and extensibility of the Mozilla engine could be used.

The viewer already includes the mozilla engine, using xpcom it will be possible to use Javascript, Java, C++ (Mono/.Net is under way).

This would require that a definition of an interface layer between the core viewer and the xpcom system inside Mozilla, once that was defined and implemented, the viewer functionality could be extened using almost any language.

Duffy Langdon 12:34, 10 January 2007


Nude patch

It's inevitable. Any bets on how long it will be?

  1. Ages ago. Around about the time alpha textures for clothes were allowed. SignpostMarv Martin 00:53, 11 January 2007 (PST)
  2. Do bear in mind that my mention of a possible implementation for the 'nude patch' would be akin to hallucinating, due to the also mentioned ability to run extra-stringent checks on the server side for submitted content in PG regions. SignpostMarv Martin 01:08, 11 January 2007 (PST)

I don't think a nude patch could work anyway - the skin and clothing textures are combined on the wearer's client, then the combined texture is uploaded to the server as the single texture that appears on the avatar. That's why "rebaking" your textures on your client affects how other people see you. You could possibly just apply the same skin to everyone but you might just as well leave everyone unrezzed then ;) - Yumi Murakami

and chase all your payig customers away ? In order for us to build our business out in SL and represent our RL business inside SL such things should never be possible therefor as this is a technical wiki and forum how to further create a better client i suggest to build as much security in the client as possible ro prevent such 'attacks' on our avatars. River Senyurt 11:34, 12 January 2007
As I described in the Barriers to implementation section for this "feature", security such as this would have to be built into the server. Since the Viewer is now GPL, all it would take is for someone to remove this 'security' layer, and you're right back where you started, thus Linden Lab are highly unlikely to spend time implementing such a mechanism in the client. The method I described has benefits for both the main and teen grids anyway.
Aside from the odd oversight over the years (e.g. texture uploads, megaprims), all security and validation operations are executed on the server side. It fits into LL's behaviour to implement such checks on the server, and while they could, and most likely will do something alone these lines, there is unfortunately nothing you can do to stop somebody else making their client get nervous imagine you in your underwear. Or less.
SignpostMarv Martin 04:18, 12 January 2007 (PST)


Night skies

I'm working on customizing the night sky. Since the sky, and especially the starfield, are strictly client-side effects, this would involve storing the data in a local file. Where would be the best place to store this, and what would be the best way to access it?

Are there any plans for things like sim-wide data storage? Such a thing would make it possible to assign per-sim or per-area skies. I figure a decent starfield would require between 8k and 16k of storage; objects like comets, planets, and the like would be much smaller. --Carnildo Greenacre 00:48, 13 January 2007 (PST)

Marv's crazy thoughts

Rename feature to "Celestial Effects"

Since the effects you refer to- comets, planets, starfiled, and one assumes Aurora Borealis, as well as celestial bodies such as nebulae, pulsars, supernovas, asteroid fields etc etc, are effects seen in the sky or space (which is the basic definition of 'celestial'), it would make sense to make allowance for the code to be extended to provide this wider scope.

I would suggest implementing bitTorrent (or other P2P protocol) client, putting an option in the Network tab, and adding the necessary UI elements that say "Customised Celestial Effects Server XYZ has n celestial packs available for this parcel/simulator, please select download", as well as options for saving/deleting/editing said celestial effects.

Separate bandwidth control options would be advised, although the gzipped/7zipped celestial effects packages are likely to be rather small.

Since it would be cool to have the ability to edit the celestial effects, it might make sense to implement a version control system, so once people have played around with the effects package, they could submit their take on the pack/their improvements back to the server.

  • It would be useful to alert people who are using another version of the effects pack that another version has been made available

I'm going to hazard a guess that doing a mashup of CVS/SVN + bitTorrent might be a pain in the ass, but with 20k+ concurrent Resis, and filesizes of less than 16kb (adding support for procedural generation of content to help lower things further would be advised), this would make things rather efficient if it was pulled off.

Individual items of content should be made available for distribution individually- one person's comet effect might be better than another's for example.

Since these creations will involve intellectual property, I would advise enforcing a Creative Commons licensing policy from the get-go.

Summary

  • Rename feature to "Celestial Effects"
  • use bitTorrent or other P2P technology to distribute content
  • use Version Control systems for server-side storage
  • enforce Creative Commons licensing ( CC BY-NC-ND for example would mean refusing submissions back to the central storage server.
    • Since multiple servers are likely to be made available, it would make sense for the following two features to be added to the servers
      1. Checking to make sure someone hasn't resubmitted someone else's content as a fresh asset.
      2. Allowing communication between servers to check results.
  • Allow individual assets of the effects package to be modified or replaced
    • An option for:
      • Always use asset X for asset type Y
      • Never use asset type Y
      • Never use assets under a specific CC license
    • This would mean a single data format could be designed for things such as constellations, which could be combined with any number of celestial effects for the numerous Star asset types, rendering effects for specific subsets of the Star asset type.

Celestial Asset Types

I'm going to stop myself short on this, as I feel this feature alone would eat up a rather large amount of the talk page and is complex enough that it should be given it's own sub-section of the wiki, Project:Celestial Effects, since I have all kinds of crazy ideas in mind for this :-D

SignpostMarv Martin 08:52, 13 January 2007 (PST)

Implement other languages options - Dutch

At this moment I'm already changing my english GUI from SL client into a Dutch (nederlands) language version. So my question is if somebody is interested in this and maybe in the future, to add this in the official beta release. Although there is still a lot of work to do.

--Crash Crabe 01:09, 25 January 2007 (PST)

Although it's in an "in development" stage, I'm guessing the best place to discuss other language options would be Project:Internationalisation
SignpostMarv Martin 03:24, 12 February 2007 (PST)

Nuke this page

I propose we nuke this page and move everything into individual pages tagged with Category: Feature Request. There is no point in having two different ways to do this, and this single page method is not scalable. Gigs Taggart 13:42, 14 February 2007 (PST)

It's on my To-Do list already.
SignpostMarv Martin 14:13, 14 February 2007 (PST)
Retrieved from "https://wiki.secondlife.com/w/index.php?title=User_talk:SignpostMarv_Martin/Archive/Implementing_new_features&oldid=10819"