Massively^™

Already recompiling my viewer with (I hope) the restriction removed :D

I'm gonna make me some big sculptures!

Reply

Jacek, do you have a diff if it works?

Reply

Research suggests it was available from LSL (a four line script is the rumour), but unfortunately llSetPrimitiveParams([PRIM_SIZE, ]); creates a 10x10x10.

Patching the XML allows you to size them out to an size you like, people also see the huge prims, but as soon as you close the edit dialog or attempt to change from cube to another shape they collapse.

Right now I am looking at various overflows on llSetPrimativeParams, it may be there based on the rumour of it being script based.

Reply

Somebody please make a 20 meters sphere! :)

Reply

Thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you!

Reply

The libSL TestClient can create them quite easily, this is going to be really useful!

Reply

Does it matter what kind of sim you're in when you do this? Do you have to be sure you're in a Havok 4 sim?

Reply

Unfortunately, my solution ran into the same problem that Jay did, where the prim would snap back to 10m when you closed the edit window. But here's what I tried:

In linden/indra/llmath/xform.h, line 40 or so:

const F32 DEFAULT_MAX_PRIM_SCALE = 10.f;

If you change "10.f" to, say, "100.f", you can then use the scale tool to scale the prim up to an arbitrary size (in this case, up to 100m on a side). If you put "256.f", it'll go up to 256, and so on.

But, as I said, it will snap back to 10m when you let go of it. That indicates to me that there's still a server check going on somewhere.

I've heard theories that the check is only off for creating prims, not for resizing existing ones. Unfortunately there's no way to create new prims at an arbitrary size from the client.

Reply

I just spent the last hour playing with the 0L pack by Day Oh that you linked to at SLExchange, as well as another 0L pack there by Zwagoth Klaar, and I can confirm that all the prims within are definitely true new megaprim sizes. They allow hollow, cuts, profiles, shape changes (cube to sphere, torus, etc) all without "collapsing", i.e. they behave just like the old batch of megaprims. On Havok 4 at least, they all fuction as proper solids when you turn off "phantom" so that you can walk around inside them, along curves and so on.
Day Oh's pack is all flat, with a huge variety of X,Y sizes but all with a Z value of 0.5m, in total I think it's 2048 prims added to your inventory. But Zwagoth Klaar's pack is the Big Golden Prize in my eyes. It features about 70 megaprims of varying sizes, including true cubes (aka spheres! tori!) ranging from 11m to 32m, as well as some creative X sizes with more torus-friendly matching Y,Z values. Although I'd of course be happier being able to create such sizes myself, this pack will definitely open up a new wave of megaprim-based building that encompasses more than just "what can I do with a 40m sphere?"
I wonder if this little back-door opening is a sign in the code of things to become official at some point in the future? Gee it sure would be nice...

Reply

I've created a bunch of different ones myself, I can create any random size anybody asks for to prove that they're new. If anybody knows how to get libsecondlife installed, and succesfully run the TestClient.exe example program, you can create megaprims really easily by manually creating a prim in-world and getting the UUID using an LSL script, then logging in with TestClient and exporting the prim to an xml file. Then modify the Scale values, and re-import the prim. Log back in with the regular viewer and you will find a megaprim of the desired size.

Of course, if you have an alt account you can do this while logged in with your main account, making it much quicker.

Reply

Man, oh man. I can't say how long I've been waiting for megaprims to come back. I have run into many problems in the past working with the limited few that were available because they just didn't seem to fit in with what I needed them for ... say a 40x40x.01 floor (or any size in multiples of 10 and .01 height). This is going to be fun!

Reply

it would be nice if someone made an automated client to create the biggest ammount of X,Y and Z sizes of prims with at least one axis biger than 10 meters as possible before they close this hole (and of course, distribute them as freebies ;)

Reply

http://www.libsecondlife.org/wiki/SLProxy
-note the /inject section
-modify libsl source to listen for inworld chat command containing a size vector, catenate this scale vector into a .packet (not necessarily by assembling an actual file: can be done in memory) and feed it into SL (using /inject)
[info courtesy of Misters Klaar and Loon]

or

patch a client so it doesnt 'correct' the scale vector.

Reply

I should also note that the sooner this is assembled into an opensource/trusted compile of SLProxy (so its client independent) the better.
The additional load of us all having a folder containing thousands of sized megaprims is undesirable. Being able to produce them on demand via chat command is preferable.

That said, making it too easy may not be so good initially either.
I've given the new packs to people i assumed would know how to deal with megaprims, and was sadly mistaken. ["Hey, these dont work...I just rezzed a bunch and nothing happened.. and why is everyone floating into the sky?" - you know the scenario.]
So having the 'unitiated' able to easily rez 64k cubes will be bad.... Because you just *know* many will start at the biggest possible before even considering rezzing a 20m sphere.

Reply

Btw, just for background info.

New prims were always rezzed based on the macro DEFAULT_OBJECT scale with .5m in all directions. Overriding this value in the source made the change possible.

In lltoolplacer.cpp@186
LLVector3 scale = DEFAULT_OBJECT_SCALE;

// now fudge 'scale' here ...
....

A comment from the megaprim forum thread however suggest, that this won't last ... despite first impression (although it's still hard to believe this is an bug, after they properly check the lower 0.01m limit) it may have been unintentional (or people were not supposed to find out).

Reply

To the best of my knowledge the server-side megaprim prevention has now been implemented.
This leaves us with the packs of those created in the interim.
I guess it's unlikely LL would go about removing them all from the db, if not impossible. But this may also be a possibility.

So now we seem to be in the phase of cleaning up the sets we have and finding a useful way to use them.

I found that having an additional 2000+ prims in my inv was unappealing, especially as this represents ~10% of my total inv.
So I made a HUD script that allows random boxes/packs of megas to be linked together, toss the script in all of the packs in the linkset, and invoke a command, each box/pack is searched in sequence and if found, the desired mega is rezzed.
The main idea was to functionally combine all the available packs, without needing to go through them to remove duplication, or even alter the original pack at all.
Just drop in a script, and link it to your existing packs.
It's opensource, relatively simple, and more of a technology example as opposed to a refined product, but it works nicely, and hopefully it will allow responsible mega builders to wield their thousands of new megas without applying too much additional load to asset servers.
Packaging them this way also makes them easy to give away.

http://www.slexchange.com/modules.php?name=Marketplace&file=item&ItemID=697057

Reply