• All submissions to this site are governed by Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you have read, understood, and agreed to those terms.
Issue Details (XML | Word | Printable)

Key: VWR-7191
Type: New Feature New Feature
Status: Open Open
Priority: Normal Normal
Assignee: Unassigned
Reporter: Ralph Doctorow
Votes: 4
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
1. Second Life Viewer - VWR

Either support megaprims or don't

Created: 12/May/08 09:13 AM   Updated: 14/Oct/09 12:14 AM
Return to search
Component/s: Building (in-world)
Affects Version/s: None
Fix Version/s: None

Environment: All
Issue Links:
Relates


 Description  « Hide
Currently there's a flood of new megaprims being released, but they can only be created by hacking the viewer since apparently the server supports them, but the viewer builder and LSL throttles sizes at 10M.

This is not a good solution. All the problems of megaprims will exist, but a lot of the benefits are lost. There already are lots in use, and with the new unofficial tools there are going to be lots more inworld. If SL can support them, then make it possible to build with them, if it can't then ban them.

If there need to be restrictions such as they can't overlap a region or parcel boundary, they can only be phantom, not larger they X by Y by Z, whatever, please enunciate the rules and enforce them on the server.



 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Ceera Murakami added a comment - 16/May/08 08:46 AM - edited
Linden Lab's last "server security patch" closed the loophole that allowed creation of new megaprims. But not before a number of residents created thousands of new shapes, and made them freely available.

The new megaprims behave better, since they don't rely on prim torture to be the size that they were created at.

But LL still needs to do a lot of work to properly "liberate" megaprims.

They don't show correctly at all on the mini-map, and generally blot out a large area around them on that map. (See VWR-7207 for a feature request to fix that)

According to the office hours discussions, they are working on tools that will allow removal of an encroaching megaprim even if its roor or center is not on your land. That will eliminate the worst griefing use of them. They are also working on a sim-level method for exempting certain specific megaprims from removal, so the sim owner can have a feature like a sky dome or a lake surface, and can prevent its removal.

Making sure they can't be physical is a good idea.

Forcing them all to be phantom is not necessary, now that Havok 4 handles hollow megaprims much better. And we need non-phantom megaprims for things like floors in sky platforms.


LaeMi Qian added a comment - 16/May/08 06:58 PM
Depends on HOW mega the prim is, too. I use a number of 20m megaprims, but have only desired to go over that (to 50m per side) once. Hopefully prims to 20m will eventually not be considered 'mega' any more. The abovementioned ability to remove parcel-encroaching prims sounds like a good step towards providing the infrastructure so that official prim maximum size could be bumped up a bit.

Steamy Latte added a comment - 17/May/08 06:45 PM - edited
The fact that the new megaprims don't have to be "tortured" into useful sizes, and thus perform better, is a compelling argument for allowing the creation of new prims beyond 10m.

Elbereth Witte added a comment - 22/Jun/09 05:41 PM - edited
I have a weird compromise...

Allow llSetScale() and such to set a prim's size to anything in the normal envelope, plus anywhere up to its current scale, on a per axis basis or whatever.

Megaprims creation will still be limited, but the ability to scale them down arbitrarily will partially solve the stockpiling issue, and allow a virtually unlimited variety of sizes given the current state of huge prims floating around.