Re: [opensource-dev] trying to get a mod working

[Lynx Linden]

> 94>..\..\newview\lllogchat.cpp(196) : error C2065: 'ostringstream' : 
> undeclared identifier

This suggests that you need to add:

#include 

Cheers,

Lynx.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] reb menu bar

[Opensource Obscure]

On Tue, 20 Apr 2010 21:55:35 -0400, Andrew Simpson 
wrote:
> hi there
> 
> i have soo much trouble is red menu bar is always in the way, is there 
> code that tell  be normal? instead of red bar but theme

o.O
maybe you're logging in Aditi / Preview grid and using a 1.x viewer?

if yes, that's normal.

if not, please provide a screenshot, I can't understand
exactly what you mean.


HTH
open
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] reb menu bar

[Boroondas Gupte]

On 04/21/2010 03:55 AM, Andrew Simpson wrote:
> i have soo much trouble is red menu bar is always in the way, is there 
> code that tell  be normal? instead of red bar but theme
>   
In 1.x Viewers, the menu bar color depends on the selected grid (and
God-mode). The color values are defined in
indra/newview/skins/*/colors_base.xml (default
,
silver
).
The code to switch the color seems to be at |init_menus()| in
indra/newview/llviewermenu.cpp

and |LLViewerWindow::setMenuBackgroundColor(|...|)| in
indra/newview/llviewerwindow.cpp
.
To change which grids cause a different color you'll probably want to
modify LLViewerLogin::isInProductionGrid()
.

I hope this helps.

cheers
Boroondas
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] OpenLSL Invitation

[Jonathan Irvin]

Hey Guys,

I just wanted to, again, extend the invitation to
http://openlsl.stackexchange.com/.  This is a Q&A site for all LSL
developers new and old, beginner and experienced to ask questions and answer
them regarding LSL scripting techniques, technologies, and the like.

Membership is free and will remain so indefinitely.  I welcome all people
who are experienced LSL developers or people just getting started.  The main
thing we need is participation at this point.

The site is in bootstrap mode meaning that new users will have permissions
they normally would not in a production site so it gives you more freedom to
help build up the site.

Here's the link to check the status of our progress.
http://openlsl.stackexchange.com/bootstrap

I'd also like any of the OpenSource Dev folks to post your questions on the
OpenLSL site as well.  I may end up moving towards a general Second Life Q&A
site, but hitting up the LSL folks for now.

Jonathan Irvin

P.S.  I'm not meaning to spam.  Being a long-time user of SL and a LSL dev.
I've felt this format of website is needed for all us geeks.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] texture problem on avatars

[Chang Liu]

Hi, Nyx,

We were using viewer 1.23.4.  Interestingly, the official 1.23.4 viewer
binary release does not have this problem.  But after we compiled and
packaged the 1.23.4 source release, we saw this problem.  We didn't mix 2.0
at all.

Since this is related to compiling and packaging, could it be a particular
library that's referred to in the code?

Thanks!

~Chang


On Tue, Apr 20, 2010 at 5:42 PM, Nyx Linden  wrote:

> Chang Liu wrote:
>
>> Hi, all, when we connect a modified version of Second Life Client Viewer
>> to OpenSim, we notice that from time to time, textures on avatars may turn
>> into mosaic and hollow like what's shown in the attached screenshots.  Has
>> anyone seen this before?  Any clues as to what may have gone wrong? Many
>> thanks.
>>
>> ~Chang
>>
>>What version of the viewer are you using? Viewer-1.23 redefined the
> fourth channel of baked textures to be "alpha mask" instead of "bump map".
> If you load old baked textures that generated a fourth channel intending it
> to be a bump map, and use it as a baked texture for a 1.23+ viewer, the
> viewer will incorrectly interpret the fourth channel as an alpha mask,
> resulting in images like you included in your email.
>
> Were the avatars on the sim a mix of 2.0 and 1.22 (or previous) versions by
> any chance?
>
> -Nyx
>
>> 
>>
>>
>> 
>>
>>
>> 
>>
>> 
>>
>> ___
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>> Please read the policies before posting to keep unmoderated posting
>> privileges
>>
>
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] ParcelAccessListReply packets have no reliable end of list indication?

[Dale Glass]

В сообщении от Понедельник 19 апреля 2010 22:46:53 автор Joshua Bell написал:
> I took a peek at the sim code that issues ParcelAccessListReply and
> your analysis appears to be correct; there's a special case for
> sending a null entry if there are no entries at all, otherwise the
> data is just sent in as many packets as necessary, with no termination
> indicator.

In that case, I consider this behavior to be a bug, so I created one on jira:
http://jira.secondlife.com/browse/SVC-5713

As I explain in the bug entry, this issue can be fixed in a backwards 
compatible and elegant manner, by always terminating the list with a null 
entry, and not just when it's empty.

Fixing this would avoid data loss (once the viewer is updated to take 
advantage of this), and make things much easier for other clients. 

For instance I have a bot that cleans up ban lists ocassionally by removing 
deleted accounts, since in this area the number of bans manages to get quite 
close to the limit. Losing half the entries during what is a routine 
maintenance operation wouldn't be good.

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] texture problem on avatars

[Jacek Antonelli]

We have been seeing exactly the same thing with Imprudence 1.3
recently (which is based on SL 1.23 with some Snowglobe mixed in),
also when connected to OpenSim. I'm not sure why it only seems to
occur on OpenSim, but I can confirm that it's related to the change in
texture channels, as Nyx said. We'll be working on this issue soon; if
we find a fix, we'll be sure to share it.

- Jacek

On Wed, Apr 21, 2010 at 9:12 AM, Chang Liu  wrote:
> Hi, Nyx,
>
> We were using viewer 1.23.4.  Interestingly, the official 1.23.4 viewer
> binary release does not have this problem.  But after we compiled and
> packaged the 1.23.4 source release, we saw this problem.  We didn't mix 2.0
> at all.
> Since this is related to compiling and packaging, could it be a particular
> library that's referred to in the code?
> Thanks!
>
> ~Chang
>
>
> On Tue, Apr 20, 2010 at 5:42 PM, Nyx Linden  wrote:
>>
>>   What version of the viewer are you using? Viewer-1.23 redefined the
>> fourth channel of baked textures to be "alpha mask" instead of "bump map".
>> If you load old baked textures that generated a fourth channel intending it
>> to be a bump map, and use it as a baked texture for a 1.23+ viewer, the
>> viewer will incorrectly interpret the fourth channel as an alpha mask,
>> resulting in images like you included in your email.
>>
>> Were the avatars on the sim a mix of 2.0 and 1.22 (or previous) versions
>> by any chance?
>>
>> -Nyx
>>
>>
>> Chang Liu wrote:
>>>
>>> Hi, all, when we connect a modified version of Second Life Client Viewer
>>> to OpenSim, we notice that from time to time, textures on avatars may turn
>>> into mosaic and hollow like what's shown in the attached screenshots.  Has
>>> anyone seen this before?  Any clues as to what may have gone wrong? Many
>>> thanks.
>>>
>>> ~Chang
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges