On Tue, Jan 26, 2010 at 8:03 AM, Stickman wrote:
> 2. What it captures: Generally the world map will capture an object's
> shape and overall color/tint. Details like exact textures on objects
> usually aren't captured unless they're of such a large size that they
> would take up roughly a quarter
We have created a new meta jira for the in-progress Efficient Scripts
project which has gotten some discussion lately on both of these lists -
SVC-5165 [1]. I've added some sub-tasks for the cases that were already on
our radar, along with the "mission statement" / goal of the project. If
there i
On Tue, Dec 22, 2009 at 1:05 PM, Maggie Leber (sl: Maggie Darwin) <
mag...@matrisync.com> wrote:
> Kelly Linden wrote:
> > Estate owners should be able to do with script resources what they
> > can currently do with prim resources.
>
> I hope that includes overcomittin
On Tue, Dec 22, 2009 at 5:07 AM, Carlo Wood wrote:
> The whole "resource / payment / number of prims" as function of land
> area is nonsense to begin with.
>
> Virtual land area costs NOTHING whatsoever. The reason that LL lets
> you pay for land is because that system brings them more money
> th
ilable resources.
- Kelly
On Fri, Dec 18, 2009 at 3:55 PM, Carlo Wood wrote:
> On Fri, Dec 18, 2009 at 10:13:36AM -0800, Kelly Linden wrote:
> > I place a high value on simplicity. I want to trivially understand where
> I am,
> > how much headroom I have, how close I am to wh
I'll be honest. I just really don't like the dynamic resource limits idea.
It is very neat and interesting in theory, and fun to design and discuss.
However I see a lot of value in knowing all my content will continue to work
and knowing what content I can use - In knowing that when I buy/rent/lea
This is exactly the kind of tool that it makes sense to extend to script
limits, and I don't think anyone has suggested it wouldn't be available,
even if we haven't explicitly listed it as a feature yet.
On Wed, Dec 16, 2009 at 11:54 PM, Peter Leonard/Dante wrote:
> Just look at region Object Bo
On Thu, Dec 17, 2009 at 6:37 AM, Tateru Nino wrote:
> Not that I think this mailing list is the best place to go over all
> this, but I'll make one observation:
>
> The more dynamic it is, and the less trivial the math involved, the
> harder it is going to be for Joan User to figure out if her sc
On Wed, Dec 16, 2009 at 7:31 PM, Dahlia Trimble wrote:
> The master script can then modify these values and modify the child prims
> using the existing llSetLinkPrimitiveParams() function.
>
At 0.2 seconds of script sleep per call you are currently at 1 second for
every 5 prims. 100 prims is 20
Sorry to dash any hopes but on the server this function is currently a
no-op. No data will get sent to the viewer.
- Kelly
On Fri, Dec 11, 2009 at 2:00 AM, Vector Hastings wrote:
> Anybody want to fix this?
>
>
>
> Seems to me (though I’m no expert) that it’d be possible via a client-side
> h
Sorry, obvious correction needed: An LLSD map is a
std::map
On Wed, Nov 4, 2009 at 7:18 AM, Kelly Linden wrote:
> LLSD has two container classes, maps and arrays. The LLSD map is a
> std::vector, while the LLSD array is a std::vector.
> These are both pretty much standard STL, wrap
LLSD has two container classes, maps and arrays. The LLSD map is a
std::vector, while the LLSD array is a std::vector.
These are both pretty much standard STL, wrapped to be LLSD based.
LLSD my_array = LLSD::emptyArray();
my_array.append(5);
std::cout << my_array[0] << std::endl;
You need to wal
processing of
requests in the simulator. I'm not sure about any other limits.
- Kelly
On Fri, Sep 11, 2009 at 9:14 AM, Kelly Linden wrote:
> For HTTP-In (llRequestURL, http_request, llHTTPResponse):
> The body of a POST or PUT to http_request is capped at 2048 bytes.The
> headers
For HTTP-In (llRequestURL, http_request, llHTTPResponse):
The body of a POST or PUT to http_request is capped at 2048 bytes.The
headers are capped at 255 bytes
The query args and extended path (beyond the cap) are converted to headers
before they reach the sim, and thus subject to the header limit.
It sounds like the intent is not to commit the debug code. That said,
I like the variable width lines concept. Just because we have a
setting for adjusting the default width doesn't mean we should ignore
width as a possible feedback mechanism. Total side issue though, and
not pertinent to the bu
Just gonna pick out one thing here:
* Add Option for Full White Ambient Light to View Textures Unaltered by
Light
There is a Full Bright option on the texture panel of the build tools, which
I think does this.
On Thu, Jul 23, 2009 at 8:21 AM, Stickman wrote:
> Back in late August of last year,
Unfortunately no. What you are asking for is essentially what we
already have - both old and
new viewers work because of a special coded server. We simply can not
maintain this state.
The issue is our capabilities server used to run on a web service
platform that had a bug in it, and our old
On 2/26/09 12:10 PM, Henri Beauchamp wrote:
To avoid excessive noise on the list, I'm grouping two replies here,
and this will be my last message on the list about this topic (email
me privately if you wish to continue the argument, please).
On Thu, 26 Feb 2009 09:34:17 -0800,
I personally think this was a great project! I also think the method of
soliciting feedback and review on this list was great. Even if you
disagree with the idea of computer translation this project is an
excellent example of one kind of thing people will want to do with a
plug-in system. Lo
Anna Gulaev wrote:
> Computer Gods...may I please have one year of peace? One year of no
> forced upgrades. One year of no bit rot. Please? Thanks.
We are sorry, there has been an error processing your request. Due to
recent system upgrades the accepted request format has changed; please
verify yo
20 matches
Mail list logo
