So I've been playing around with MOAP and LSL's HTTP-in, which lets you not only display media inworld, but also serve it from there to the Outside world as well...
Showing posts with label help. Show all posts
Showing posts with label help. Show all posts
Friday, April 15, 2011
Thursday, April 08, 2010
Help withTexture Mapping
the following images were designed by Chosen Few, and DanielFox Abernathy respectively. the first is an alignment texture in decimal (easier to use with the built in controls) for matching textures across prims. The second is a similar texture designed for sculpties, that also show LOD points for each vertexUUID = "11e68b89-6693-e3bf-35c9-876ae2a2e78b"
UUID = "c595dad5-e439-fe75-1220-9dddf6cdf4b3"
UUID = "c595dad5-e439-fe75-1220-9dddf6cdf4b3"
the following formulas may also help with tiling
repeat = individual prim axis size / total axis size of surface to tile across
offset = prim distance from center of total surface axis size to tile across
non-rectangular prim faces should use planar mapping mode, and non-touching prims should use half the distance between it and the next prim to calculate it's sides for axis size.
hollow faces use a different formula:
horizontal repeats = (number of hole sides * desired repeats per side * 2 if the shape is prism) / hollow as a percentage
horizontal offset = -.5 - (horizontal repeats - horizontal repeats * hollow as a percentage) / 2)
vertical repeats and offsets are calculated normally.
Saturday, February 13, 2010
the Forums Are Dead, Long Live the Forums
on February 9th (after one weeks notice) forums.secondlife.com went offline, and after a short while, were reborn in a drastically reduced form on blogs.secondlife.com/community/forums.... I'm not exactly happy with this fact, especially since vBulletin was replaced with (such an apt company name) Jive Software's "Clearspace".... meh... lots of missing and broken features, but at least they're still alive.
Now one weeks notice kinda hurt, and I spent most of that week ignoring phonecalls, archiving most of the scripting library, and starting a group to collect the people that frequented Scripting Tips, plus all the Content Creation stickies, and several posts and items of personal value. then it was off to Jira to file over two dozen bug reports and feature requests for the new forums, so that they could be as feature rich as the old ones... I was in the middle of doing that during the changeover.
The Old forums are set to be archived, and should be searchable sometime in mid March.
So what have I been doing the last few days since it died? Well I cleaned my house (since I hadn't touched it since this mess started) took a moment to congratulate myself for doing what I did, caught up with some friends, and did something that YOU dear reader, will appreciate... I wrote a Greasemonkey script for FireFox, that allows you to IGNORE those pesky people that just really seem to add nothing to your forum reading....
Ah... ignorance IS bliss =)
Sunday, February 17, 2008
Brilliant But Flawed...
so I've been meaning to work on a particular problem for ages, and was recently spurred on to attempt it, by someone elses work in a similar vein. At the core of both ideas was adding dynamic memory to LSL scripting, the ability to add a script as needed to store information, without having to worry about the limitations of a single script. Sounds fabulous doesn't it? and I did it too, well almost.... You see, it's just not possible in LSL at this time...
Now I originally came to this problem as a problem of storing permissions, because each script can only hold permissions for one person. You may have noticed dance floors and personal dance orbs (chimeras) that can support X people. that's because each person needs to have given a script permission to animate them, and each script can only hold one set of permissions... if it changes permissions to someone else, it must ask for them again.... so these devices have one script for each person they can animate..... that's one running script for every person they COULD animate, even if they aren't animating anyone...
now wouldn't it be nice if instead of all those extra running scripts, you didn't have any more than you needed at the moment? wouldn't it be grande if there was no limit to how many you could animate, right up to the limit the sim could hold? that's what I was thinking, and so I came up with a way to do it, but I never got around to testing it, and now I wish I never had.
The plan was simple, give the object a new script every time it needed more storage space. each storage script would label itself internally as it started up, using it's own name as the label. if you've ever added the same thing to a prim more than once, you'll notice it gets a number after it's name for each new copy, so the storage scripts can number themselves easily this way, and in fact I've used this method before, and it works well.
ah but you can't just give a script to an object using llGiveInventory, because the given script won't automatically load, and in fact takes a few tricks to get it to load at all. but there's another function, llRemoteLoadScriptPin, which WILL allow you to give a script and have it run. Great, but it has 2 problems. the first problem that it has, is that it will replace any script of the same name, in it's target destination. that won't work for us, because we need it to make new copies, not overwrite old ones. the second problem is that it can only work by giving the script to ANOTHER prim, it can't give itself a copy.
so we need to give the new copy to another prim, and somehow rename it in the process. ok, back to llGive inventory, this WILL allow you to give to the prim you're in, great, even if it won't make active copies... as it turns out, Remote Load WILL activate copies created with Give Inventory, so there we go, we use give inventory to create our copies, which should renumber their selves, and then activate them by giving them to another prim... oops we forgot a detail... remote load has to have a script in the recieving prim, that sets up a pin number, to be used when loading an active script.... hmm ok
to takle this and avoid having to wait on a new storage script I decide to always have one more script than I need, ready to use. When the script gets used, it asks for a new copy to be made, and sets the access PIN which it sends in a message to the controller. the controller makes a copy, and uses the PIN to load a new active script, the new active script, clears the PIN when it starts, and boom, no security holes and we've just added new storage. and this is where it all falls apart....
Now you remember I mentioned before how dragging copies of the same object into a prims inventory added numbering labels for each new copy? that's such a great feature, really. unfortunately llGiveInventory doesn't do this.... in fact, if give inventory sees that there is already a copy of the object being given, it just doesn't bother.... that means no duplicates, no numbering, and no way for the name to be changed so that it doesn't just wipe out the previous storage script.
The whole brilliant project, sunk like a lead balloon filled with rocks and shot down by a cruise missle... all because there is absolutely no way to rename a script in an objects inventory, using lsl.... so just for fun, here's the permission controller code I came up with... it wasn't quite done, it'd only handle 100 people safely (if it'd worked) and would have blown up SPECTACULARLY if the scripts ever got reset (I'ts missing clean up code), but here it is....
Subscribe to:
Posts (Atom)