It is not desirable to let the default allocation engine run under
Linux, and possibly Mac. glibc has an incredibly slow allocator for
small objects, and tcmalloc was implemented to remedy these
situations(This is what I heard, but have not confirmed.) Inventory
and a few other items create massive
The clamp for primitive parameters was in place long before the
megaprim "debacle", unless you are referring to the one in early 2006,
possibly even earlier than that.
>From what I know, doing this will require that the server be updated
to relax this restriction.
_
Linden Lab should not be distributing either of these libraries, as
they do not have a license that permits them to do so(from what I have
heard from them in other dialogs). So this violates and possibly voids
their license for Kakadu, as well as all of their careful planning to
keep it out of ever
Yes, llerrs purposefully dereferences a null pointer to cause a crash,
and if that fails it infinitely loops. This is so "errors" get fixed
instead of being ignored.
On Fri, Dec 31, 2010 at 05:42, Marine Kelley wrote:
> Hello all,
>
> I have just filed a JIRA (VWR-23459) about a random crash that
Reading through the documentation on this. It may be easier to just
add "GDK_DEBUG=nograbs" to the shell script launcher when it uses GDB,
and have it work on all distros, up to date or not?
On Wed, Dec 29, 2010 at 15:30, Monty Brandenberg wrote:
> On 12/29/2010 1:19 PM, Aleric Inglewood wrote:
>
This is one of the most confusing posts I've seen in ages. Would you
like to provide some technical detail of what you see happening, and
what you EXPECT to happen?
On Thu, Dec 23, 2010 at 00:47, Ann Otoole wrote:
> connect disconnect connect 4 times at once disconnect 4 bang bang hammer
> hammer
My only concern with some of this, is that it eliminates the support
teams easy one line answer to everything odd or unexplained. Uninstall
and reinstall the client. The reason this works so well is that it
deletes all of the users settings and preferences, which often become
corrupted or contain i
It looks to be a problem with multiple tests running at the same time.
Looking at the error gives a hint that its a collision with a globally
shared named pipe of some type. Running the tests individually works
just fine for me, running more than one at a time doesn't.
On Mon, Oct 25, 2010 at 17:0
be worked into snowstorm given sufficient time
and testing.
On Fri, Oct 22, 2010 at 05:03, Aidan Thornton wrote:
> On 10/22/10, Zabb65 wrote:
>> Looks like this does not need an answer now. Code is up.
>> http://hg.secondlife.com/mesh-development/
>> \o/
>
> Looks like c
Looks like this does not need an answer now. Code is up.
http://hg.secondlife.com/mesh-development/
\o/
On Thu, Oct 21, 2010 at 20:56, Zabb65 wrote:
> They have only said they would release source, though they do not have
> to release it. They are doing so out of their own good wil
t; On Thu, 21 Oct 2010 18:05:32 -0400, Zabb65 wrote:
>
>> Last week when Mesh was announced into public beta, it was said the
>> source code would be put up by the end of the week, checking the blog
>> post mentions that it would be placed on the snowstorm wiki page, but
>>
Last week when Mesh was announced into public beta, it was said the
source code would be put up by the end of the week, checking the blog
post mentions that it would be placed on the snowstorm wiki page, but
I cannot find it there.
After having corresponded with a few people it seems that the buil
technical limitations are lifted. To do it as you
explain it. It would require major updates to the way SL stores and
uses assets.
On Mon, Oct 18, 2010 at 15:46, Ponzu wrote:
> On Mon, Oct 18, 2010 at 2:42 PM, Zabb65 wrote:
>>
>> The local script editing and local texture editing h
My mistake. Credits to Xotmid then for external script editor.
On Mon, Oct 18, 2010 at 15:17, Brandon Husbands wrote:
> Actualy I did the external script editor you can use the pre processor to
> link in saved scripts from your hard drive
>
> On Oct 18, 2010 1:43 PM, "Zabb65
The local script editing and local texture editing has already been
done before and were implemented in phoenix. Scripting was done by
Katharine and textures were done by Vaalith.
I believe Vaalith is waiting for mesh source code so they can begin
working on the mesh portion of that.
The caveats
I tend to agree with Argent on this, it should have a comment if there
is a hack in place to make it all function.
I ran it through hg blame and it claims that revision 11977 was when a
big block in pipeline.cpp changed
11977: BOOL LLPipeline::hasRenderType(const U32 type) const
11977: {
11977:
llviewercontrol.h is the header that allows access to saved settings values
within the viewer, and has nothing to do with RLV or any other form of
control over the viewer. They are simply a set of saved control values in
llsd xml format.
On Sun, Sep 26, 2010 at 22:37, miss c wrote:
> All this ta
It generally isn't fair to compare other engines results with that of
second life, and I don't think it ever will be fair to compare
results, or how it looks.
The fundamental differences are too large. Most graphics engines deal
with optimized static geometry that has specially designed textures
t
KDU automatically detects and uses cpu optimization if its available.
The only compiler options I'm aware of are those that enable or
disable threading of decoding, which I suspect won't be of much
benefit for the type of images uses in SL(small and fast to decode).
Compiling the base code with opt
I'll stop in and say that it would be useful if you used the existing
mailing list address as well. And would appreciate emails on commits.
On Mon, Aug 16, 2010 at 15:32, Lance Corrimal wrote:
> Am Monday 16 August 2010 schrieb Henri Beauchamp:
>> On Mon, 16 Aug 2010 11:38:44 -0700, Kadah wrote:
Needs a 1.40 sim to function as expected. When such rolls out, it will
behave as you want. Until then, it thinks you are placing them on
attachments points it doesn't know about.
On Mon, Jun 28, 2010 at 03:31, Lance Corrimal wrote:
> Heya,
>
> I just gave the new multi-wearables in viewer-externa
Just to add my 2c on this issue.
I was getting this once in a while as well, when I finally tracked it
down, to the above reason(although it was an older version.) it was
actually pulling a random interface each time my computer rebooted as
being the one chosen.
In the list of random devices, ther
As for conversion, it looks like you should just convert asEdgeVertex
asEdgeNorm and the results of vGetColor(for each normal in asEdgeNerm) into
arrays, and build the index table from the results of iVertex. It more or
less looks like it was written to use vertex buffers, but was converted to
some
>From what I remember...
Indicesp is a pointer to an array of U16s that are offsets to vertexes in
the vertex buffer. Read it as the vertexes normals and all this other stuff
being in static arrays. It then runs through the indice list and runs the
associated glVertex3f commands or whatever on the
Channel name is a persistent saved setting. Meaning if you log in under a
viewer that sets its channel in the saved settings file, but does not use
one of its own(settings file), the normal viewer will continue to identify
itself as that viewer. Until you remove the entry yourself, by either
cleari
25 matches
Mail list logo
