Re: [opensource-dev] Review Request: VWR-24420: PNG images which specify "background color" lose alpha layer when imported.

[Joshua Bell]

On Mon, Jan 10, 2011 at 8:34 AM, Ponzu  wrote:

> A common cause of z-buffer problems in SL is textures that do not *need* an
> alpha channel that contain one anyway.  Lots of content in SL is created by
> rank amateurs (me for example).
>
>
That seems like a good point, and might explain the existence of the code
(although I'm just responding to the thread here, not as a domain expert).


> What if the upload dialog had a check box?
>
> [ ] This texture should have an alpha channel.
>
> If the box is not checked, the alpha channel is removed.  If it is checked,
> it is retained, unless it is not there, in which case the user gets an error
> message.
>
>
Without digging more deeply into the issue, but putting on my UI design hat,
if it's necessary to ask the user I'd suggest the wording:

[x] Preserve transparency (alpha channel)

The wording "This texture should have an alpha channel" seems like it could
lead to users thinking "hey, sure, why not, sounds like a good idea" and
checking it.

If the image does not have an alpha channel, remove or disable the checkbox
from the UI.

Then there's the question of whether or not the box should be checked by
default or not. Ponzu's point is compelling that the current behavior is
implicitly desired by many content creators to avoid problems ("I uploaded a
new texture and it's rendering differently than the textures I uploaded last
week! SL sucks!"). Which would mean that this could default to unchecked
(i.e. current behavior) but be exposed for users who know what's going on
and would let them toggle it live with the preview.

(Again, just speculating here as well, I haven't dug into the code.)

-- Josh
___
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] Review Request: VWR-24420: PNG images which specify "background color" lose alpha layer when imported.

[Joshua Bell]

On Mon, Jan 10, 2011 at 9:28 AM, Dave Booth  wrote:

> Thats a pretty good bit of thinking out loud there, Ponzu
>
> Personally I'd say thats a "clean" fix for this. However it all depends
> on how things are stored server-side - if the asset server code
> automatically assumes that every texture has an alpha channel and
> supplies a "solid" one for those where the upload doesnt provide one,
> any benefit of specifying at upload time is moot.


The asset upload/storage system handles 3, 4 or 5 channel JPEG2000 textures
and doesn't tinker with the channel data. The bulk of the textures in the
asset system are 3-channel (RGB).

(Excellent question, BTW.)
___
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] 5 Channel JPEG2000

[Joshua Bell]

On Mon, Jan 10, 2011 at 11:47 AM, Ricky  wrote:

> Question: what, if anything, is the 5th channel currently used for?
>

Bump maps in baked textures. IIRC, only the avatar pipeline
produces/consumes that channel. Also, IIRC, the logic is entirely
client-side at the moment.


> Could it be used for normal maps if it is currently unused?
> If so, then we could do this entirely clientside, assuming 5 channel
> textures can be uploaded.  Of course there would still need to be a
> way to disable the alpha channel during upload while preserving the
> normal map channel.
>

That would technically be possible. The asset system does do verification
and modification of various asset types on upload (including textures), but
- again, technically - this would probably work, possibly requiring some
minor changes to the asset verifier.

However...

The biggest challenge is the lack of support for multiple channels in
JPEG2000-producing/consuming tools. Many tools only work with 3-channel
images, and complain about 4. Combined with the lack of tools for authoring
JPEG2000 images in the first place, I'm not sure you'd want add another 3
channels to the image for the normal map. It would also mean you couldn't
re-use a normal map with two textures, e.g. to allow color variants on a
base mesh.

Avoiding two separate texture asset fetches (colors and normals) per face
might be a significant win, but I'd want to see the numbers to prove it
first.

(For comparison, the 13-channel RAW data used for uploading/downloading
region terrain and parcel data is pretty pesky to work with. Sure, it works
with PhotoShop, and is a technically simple single file backup format, but
putting all of that data into a single image is fragile that you expect
users to edit is not particularly user-friendly.)


> Ricky
> Cron Stardust
>
> On Monday, January 10, 2011, Joshua Bell  wrote:
> > On Mon, Jan 10, 2011 at 9:28 AM, Dave Booth 
> wrote:
> >
> > Thats a pretty good bit of thinking out loud there, Ponzu
> >
> > Personally I'd say thats a "clean" fix for this. However it all depends
> > on how things are stored server-side - if the asset server code
> > automatically assumes that every texture has an alpha channel and
> > supplies a "solid" one for those where the upload doesnt provide one,
> > any benefit of specifying at upload time is moot.
> > The asset upload/storage system handles 3, 4 or 5 channel JPEG2000
> textures and doesn't tinker with the channel data. The bulk of the textures
> in the asset system are 3-channel (RGB).
> >
> > (Excellent question, BTW.)
> >
> >
> ___
> 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

[opensource-dev] X network test dump (capacity failure)

[Joshua Bell]

{"deviceId":"4d30a642a56f04.90158583","userAgent":"Mozilla/5.0 (Windows; U;
Windows NT 6.1; en-US) AppleWebKit/534.13 (KHTML, like Gecko)
Chrome/9.0.597.47 Safari/534.13","href":"
http://interest.secondlife-staging.com/landing/s/chat?rerun
","elapsedTime":25649,"kyokaStartTime":1295050793574,"kyokaEndTime":1295050819223,"launcherStartTime":1295050819835,"kyokaConfig":{"version":"2.4.8","toukai":"
http://toukai.x.gaikai.com/toukai
","rerun":true,"forceLaunch":true,"forceBrowser":null,"dcFilter":null,"launcherWeb":"
http://kyoka.x.gaikai.com/launcher
","cookieHash":"08a9e668e5fc5eadde3f31cead871b54","cookieTtl":873094,"koushidomoVersion":"0.1.9","testKoushidomo":null,"disableClientDisconnect":null,"dcMaxDistance":160,"traceToConsole":null,"uId":"4d30e8256e7930.61124624","sesId":"4d30e8256e79c2.79541129","spock":"
http://toukai.x.gaikai.com/spock/
","httpRtTimeoutFirstResponse":5000,"httpRtTimeoutCompleteTest":15000,"refererDomain":"
secondlife-staging.com","koushiVersion":"2.0.23","koushiCodebase":"
http://toukai.x.gaikai.com/assets/java/koushi","koushiForceNetwork":false,"koushiConnectUdpResendTimeoutMs":100,"koushiConnectUdpTimeoutS":3,"koushiConnectCommandTimeoutMs":2000,"koushiConnectSocketTimeoutMs":300,"koushiRttTimeoutS":3,"koushiRttIterations":10,"koushiStreamBwFps":30,"koushiStreamBwDurationS":3},"clientSettings":{"ipAddress":"38.99.63.41","browser":{"os":"Windows","osVersion":"6.1","browser":"Chrome","version":9},"plugins":{"flash":"10.1.103.0","silverlight":"4.0.51204.0","java":"1.6.0.23"},"videoFeatures":{"browserWidth":1151,"browserHeight":836,"screenWidth":1280,"screenHeight":1024,"colorDepth":32},"geoLocation":{"areaCode":"415","city":"San
Francisco","continentCode":"NA","countryCode":"US","countryCode3":"USA","countryName":"United
States","dmaCode":"807","isp":"PSINet","latitude":37.7644996643,"longitude":-122.429397583,"postalCode":"","region":"CA"},"cpu":13,"supportedResolutions":[1280,1024,32,1280,720,32,1152,864,32,640,480,32,1280,768,32,1280,800,32,720,480,32],"os":{"jvmVersion":"1.6.0_23","osArch":"x86","dataModel":32,"jvmVendor":"Sun
Microsystems Inc."},"wifiOnly":false,"responseTime":10,"dataCenter":"
x.snv1.llnw.ca.us.gaikai.com
","bandwidthKbps":26738,"mtu":1454,"rtt":{"rttSamples":10,"rttHighudp":14.9,"rttAvgtcp":5.4,"rttSamplesudp":6,"rttHightcp":10.66,"rttLowudp":5.73,"rttSamplestcp":6,"rttAvgudp":5.93,"rttLowtcp":5.31},"stream":{"bwOutOfOrderAF":0,"bwRttAvg":7.8,"bwLoss":1.39,"bwRttHigh":13.97,"bwDuration":3,"bwOutOfOrder":0,"bwRttLow":5.88,"bwKbps":9863.93},"udpTest":true,"udpPort":5995},"launchData":{"launch":false,"clientType":"java","results":{"wifiOnly":true,"bandwidth":true,"responseTime":true,"enabled":true,"plugins":{"flash":true,"java":true,"xbox":true,"ipad":true},"capacity":false},"gameData":{"code":"secondlife_custom_8_fps","name":"secondlife_custom_8_fps","demotime":"0","scriptVersion":"2.3.0","language":{"code":"EN","language":"English"},"inputProfile":{"mouseEnabled":"True","keyMappingConfigID":"fullKeyboard","feedbackProfile":"AUTO_UNBOUNDED","inputProfile":"PC-AUTO-UNBOUNDED"},"metadata":{"height":"576","site_overlay":"
http://maps.secondlife.com/
","type":"game","width":"1024"},"disabled":false,"resolution":{"width":1024,"height":576}},"launcherUrl":"
http://interest.secondlife-staging.com/landing/s/chat?rerun
","forceLaunch":true},"eventDump":[{"seq":5,"eventType":"responseTime","eventData":{"host":"
kd1.x.snv1.llnw.ca.us.gaikai.com
","rts":[8,9,9,10,11,13],"ots":[18,14,9,13,9,11,14,10,8,23],"total":60,"avg":10}},{"seq":6,"eventType":"responseTime","eventData":{"host":"
kd1.x.lax6.llnw.ca.us.gaikai.com
","rts":[17,18,19,20,20,21],"ots":[27,21,21,24,33,17,19,20,18,20],"total":116,"avg":19}},{"seq":7,"eventType":"responseTime","eventData":{"host":"
kd2.x.sea3.llnw.wa.us.gaikai.com
","rts":[26,26,26,26,26,27],"ots":[37,30,26,26,28,26,26,26,27,31],"total":157,"avg":26}}],"errorDump":[]}
___
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] X network test dump (capacity failure)

[Joshua Bell]

On Fri, Jan 14, 2011 at 4:20 PM, Joshua Bell  wrote:

>
> {"deviceId":"4d30a642a56f04.90158583","userAgent":"Mozilla/5.0 (Windows; U;
> Windows NT 6.1; en-US) AppleWebKit/534.13 (KHTML, like Gecko)
> Chrome/9.0.597.47 Safari/534.13","href":"
> http://interest.secondlife-staging.com/landing/s/chat?<http://interest.secondlife-staging.com/landing/s/chat?rerun>
>

Oops, sent that to the wrong mailing list.

FYI, that's just a dump of script data from a browser trying to access the
Second Life Web Viewer Beta, nothing secret. If you're trying out a session
you can get at the same data by groveling around in the Web Inspector
console or Firebug.

Careful observers will now know what city I'm in and what OS/browser I'm
running, though. Eeeek! :)

-- Josh
___
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] STORM-1090 : font size regression

[Joshua Bell]

On Mon, Mar 21, 2011 at 11:17 PM, Philippe (Merov) Bossut <
me...@lindenlab.com> wrote:

> We identified that moving from freetype 2.3.9 to 2.4.4 in
> viewer-autobuild2010 produces smaller text (roughly 10% smaller).
>

I haven't dug into this at all, but I note that we're using FT_Set_Char_Size
which sets the size in points (not pixels), relative to a DPI.

Is it possible the default DPI changed? (72 vs 96 is the usual suspect, and
at UI sizes that's often just 1 or 2 pixels different once you consider
hinting)

Should we be using FT_Set_Pixel_Sizes instead?
___
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] Windows compiling problem

[Joshua Bell]

I was running into that exact objidl.h issue until I updated my DirectX SDK.
I had a 2008 SDK, I needed to uninstall and reinstall the June 2010 SDK
linked from
http://wiki.secondlife.com/wiki/Viewer_2_Microsoft_Windows_Builds

(IMHO it
was probably less about the SDK version than the install order.)

On Tue, Apr 12, 2011 at 11:10 AM, Jenn Leech  wrote:

> On my development machine I uninstalled the Windows SDK entirely, relying
> on the one that ships with VS2010, to resolve a similar conflict. If a
> similar tactic works for you, let us know!
>
> Thx,
> - Jenn
>
> On Fri, Apr 8, 2011 at 11:34 AM, Jonathan Welch  wrote:
>
>> I've tried all the suggestions that people have suggested, but to no
>> avail.  I still get messages like the one below.
>>
>> Anyone with more ideas?
>>
>> -- Build started: Project: llwindow, Configuration: Release Win32
>> --
>>  llwindowwin32.cpp
>>  lldxhardware.cpp
>> e:\Microsoft SDKs\Windows\v7.1\Include\objidl.h(11280): error C2061:
>> syntax error : identifier '__RPC__out_xcount_part'
>> e:\Microsoft SDKs\Windows\v7.1\Include\objidl.h(11281): error C2059:
>> syntax error : ')'
>> e:\Microsoft SDKs\Windows\v7.1\Include\objidl.h(11281): fatal error
>> C1903: unable to recover from previous error(s); stopping compilation
>> ___
>> 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
>
___
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] Request for comment on these JIRA reports

[Joshua Bell]

On Wed, Apr 27, 2011 at 6:41 AM, Opensource Obscure <
opensourceobsc...@gmail.com> wrote:

>
> * https://jira.secondlife.com/browse/SVC-5387
> Snapshot to postcard failure
> - how to provide more helpful feedback?
>

Sorry for not catching up with you in-world on this one, OO.  (And sorry for
the dupe email, I meant to send this to the list)

If you can repro, check out your viewer log and see if it's reporting more
detail about the failure, specifically an HTTP error code and message.

-- Josh
___
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] New web search: how to get search_token or auth_token in v1 viewers ?

[Joshua Bell]

On Thu, May 26, 2011 at 12:41 PM, Henri Beauchamp  wrote:

> Looking at (grepping) the code, I see no mention of these in

lllogininstance.cpp (if these options are like others, there
> should be requested_options.append("search_token") and
> requested_options.append("auth_token") calls in there...).
>

The search_token is always returned in the XMLRPC response, and it is not
necessary for the viewer to request it (unlike most such values which are
explicitly requested).


> I tried to request these options in my backport, but both
> getResponse("search_token") and getResponse("auth_token") keep
> returning empty strings...
>

That's odd. Can you dump out the full XMLRPC response to verify that
search_token isn't present and that it's not some other part of the viewer
plumbing that's eating the value? I'm seeing it when doing some raw XMLRPC
tests against the login service.

-- Josh
___
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] Review viewer -- draw distance slider

[Joshua Bell]

On Fri, Jun 10, 2011 at 8:59 PM,  wrote:

> The binocs idea for the icon is the best!  It's totally like the average
> person is going to think about it.  And it's the way our eyes work.


I have serious concerns (based only on the screenshot posted earlier):

* By elevating this option to the top bar, we would expect many more users
to interact with the control than when it is buried in preferences.

* Without textual cues, you rely on the users to associate the button with
some meaning. While binoculars may be a good metaphor (and perhaps the best
available), it's not a commonly used glyph. Contrast with play/pause/stop or
speaker-as-volume, which are now nearly universal in audio controls. I would
not expect many users to either go looking for it or easily understand what
the control is affecting from just the icon.

* In the mockup I've seen, the control will look similar and behave almost
exactly like the nearby volume control. I would expect many novice users to
click the icon by mistake, adjust the setting, then wonder why the volume
didn't change, and thus leave the draw distance altered unexpectedly.

* The negative side effects of setting a large draw distance are not obvious
to most new users. By making the control so prominent, I would expect that
many would discover the control, set it to the most aesthetically pleasing
value (i.e. "see more stuff"), then forget about it and wonder why the world
is suddenly reacting more sluggishly.

I think it's a very cool idea and conceptually love the design, but please
proceed with caution. At the risk of making the implementation more
difficult, I'd suggest adding labels along the lines of "See More (Slower)"
"See Less (Faster)" at the top/bottom of the slider to alleviate the
confusion.
___
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] Virtual Destructors

[Joshua Bell]

Destructors of derived classes are automatically virtual if the base class
destructor is virtual.

http://www.parashift.com/c++-faq-lite/virtual-functions.html#faq-20.7

The inheritance chain is:

LLMouseHandler > LLTool > LLManip > LLManipScale

... and both LLMouseHandler and LLTool declare the destructor as virtual.

It wouldn't hurt to explicitly mark ~LLManip and ~LLManipScale as virtual
for clarity in the code, but it won't actually change anything.

On Fri, Jul 1, 2011 at 4:02 PM, Ricky  wrote:

> Looks like the destructors might only be called at program
> termination, so this may not be a big problem anyway.  However it IS
> inconsistent and weird.  And I have it within reach to clean up if it
> seems good to do so.
>
> Ricky
> Cron Stardust
>
> On Fri, Jul 1, 2011 at 3:25 PM, Ricky  wrote:
> > Poking around in the llmanip* files working on VWR-25739, I started to
> > get annoyed at the coding inconsistencies between those files.  So I
> > started looking at what it would take to make the 3 subclasses
> > (translate, scale, and rotate) consistent, when I tripped across the
> > detail that llmaniptranslate.h has the destructor declared virtual
> > while llmanipscale.h has it declared plainly, and llmaniprotate.h
> > doesn't explicitly declare a destructor.
> >
> > When I looked up some reasons why a destructor should be virtual it
> > seems that it should be virtual when the class is going to be used in
> > a polymorphic way and will have delete called on a pointer to it.  IE:
> > // MyClass is a ParentClass
> > ParentClass* p = new MyClass();
> > destroy p;
> >
> > Apparently this is about the only case for declaring the destructor
> > virtual. (see
> http://blogs.msdn.com/b/oldnewthing/archive/2004/05/07/127826.aspx
> > and especially http://www.erata.net/programming/virtual-destructors/ )
> >  It also comes with a minor performance hit, but that's outside of
> > scope.
> >
> > It turns out that LLManipScale _is_ being used in such a way in
> > LLToolComp - as are LLManipScale and LLManipRotate:
> > lltoolcomp.h line 92: LLManip* mManip;
> > lltoolcomp.cpp line 194: mManip = new LLManipTranslate(this);
> > lltoolcomp.cpp line 203: delete mManip;
> > lltoolcomp.cpp line 321: mManip = new LLManipScale(this);
> > lltoolcomp.cpp line 330: delete mManip;
> > lltoolcomp.cpp line 520: mManip = new LLManipRotate(this);
> > lltoolcomp.cpp line 530: delete mManip;
> >
> > So it looks like to me that there might be a memory leak in the scale
> > and rotate classes, as their destructors might NOT be being called.
> > Of course, Translate's destructor has only an empty definition, and
> > Rotate doesn't even have one, but Scale does have a full-on
> > destructor.  And because it is not virtual, it might not be being
> > called.
> >
> > Looking over the history of the files gives me the following:
> > The Rotate destructor was last touched by Steven Bennets on 2008-03-11
> > in rev 341 - when LLLinkedList was culled in favor of another
> > technique.
> > The Translate destructor was emptied by James Cook on 2009-12-10 in
> > rev 4496 - switched to a std::vector
> > The Scale destructor seems to have never existed in revision history.
> >
> > Anyone with more familiarity with C++'s nuances in such cases have any
> > thoughts/suggestions?
> >
> > Ricky
> > Cron Stardust
> >
> ___
> 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] Request for comments about llSetAgentEnvironment / SVC-5520

[Joshua Bell]

The Web evolved into an amazing platform for experience and
application delivery by offering sandboxed experiences within a client
applications under the control of remote services. I'm writing this
email in a client implemented entirely in a Web browser, where the
experience is entirely dictated by a server.

Anyone else remember when background colors were introduced on Web
pages? Oh, the horror, taking us away from our pristine, TeX-like
austerity! Allowing the server to dictate the visual experience was a
radical thought - and of course, most of them did it pretty poorly.
There is still a special place in my heart black text on a dark purple
background - in Times Roman, of course.

The amount of control that Web browsers grant to site creators over
the visual experience today is stunning. Communities froth at the
mouth over browsers that score less than 100% on Acid3 because that
means the user isn't getting the ideal server-desired appearance. (And
let's not get started discussing client side code execution.)

Yet a sane, sensible model has evolved, albeit painfully. Sites can
build professional UI by limiting capturing clicks and overriding text
selection, yet can't read the user's private data via the clipboard or
write to local files except via Cookies. Popups are available but
limited to avoid annoyance and framed to prevent spoofing. Users can
override stylesheets with custom styles, primarily for accessibility
purposes. Practically speaking, those are used infrequently; clients
offer zooming and other tools, and sites strive for maximum usability,
and alternative clients are available for specific accessibility
needs.

The Web is pretty darn amazing and useful. I'd like to think that SL
can learn from how the Web did things.

On Wed, Mar 10, 2010 at 10:34 AM, Maggie Leber (sl: Maggie Darwin)
 wrote:
> On Wed, Mar 10, 2010 at 12:29 PM, Kelly Linden  wrote:
>> Windlight settings should be a part of the build and not something
>> you have to opt into or be bugged with a dialog to see.*
>
> Well, then how about automatic applications of animations to your
> avatar, because a "content creator" thought it would be arty or cool?
> Or malicious Windlight settings that blind you, because it's
> "artistic" and "part of the shared experience"?
>
> The enhancement request as it stands calls for a permissions opt-in
> for having your viewer settings changed, and I support it in that
> form.
> ___
> 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?

[Joshua Bell]

It is certainly the case that several request/response-type messages
do not have a way of signaling that all of the data was sent. This
arose from thinking of the protocol in a purely viewer-centric way,
i.e. if the viewer was  populating a list view, the data in additional
packets is simply appended. This imposes unfortunate constrains the
design of clients that want to process things differently than the
viewer.

This varies from message to message and even within message usage,
e.g. MapBlockReply has a "end of results" signal when issued in
response to to MapNameRequest, but not when issued in response to
MapBlockRequest.

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.

On Sun, Apr 18, 2010 at 5:51 AM, Dale Glass  wrote:
> Hi!
>
> I've run into an issue here: I'd like to reliably edit a parcel's
> banlist.
>
> However, it seems that ParcelAccessListReply has no way of indicating
> that the entire banlist has been delivered:
>
> http://wiki.secondlife.com/wiki/ParcelAccessListReply
>
> The best way I came up with for now is that if the packet is not
> entirely full (has less than 49 entries), then it's the last one. That
> doesn't help with ban lists with 49 people in them, though. And at that
> point the available solutions seem horribly hackish.
>
> Is there something I'm missing, or it's really a grid limitation?
>
> Thanks!
> ___
> 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?

[Joshua Bell]

On Mon, Apr 19, 2010 at 5:07 PM, Argent Stonecutter
 wrote:
>
> Would that explain why the viewer sometimes appears to lose data (for
> example, spurious missing inventory), because it's got no way of
> knowing if some of the packets from the server were lost unless there
> were later packets? If so, that doesn't seem like a really good design
> for the viewer itself.

That's a completely different issue. The lower level transport
protocol guarantees reliable delivery of certain types of messages -
packets are ack'd and resent if missed. It's possible that there are
bugs in reliable message delivery (it is a non-standard protocol),
bugs in how they are handled if received out of order, and/or that the
messages you are referring to are not flagged for "reliable" delivery;
I'm not sure.

You can use the analogy of certified mail as the low level transport.
If you snail-mail me to ask a question (say, ask me for the draft of
my latest novel), and I snail-mail my my answer back in multiple
letters via certified mail (say, one chapter at a time), we can both
be certain they arrived (assuming we trust the postal service...), but
you have no idea how many to expect, so you can never be sure you got
them all... unless the last page says "The End".

(We're talking about old and - bluntly - crufty parts of the protocol
here. In general, new additions to the Second Life protocol are done
using HTTP(S) as a transport and RESTful semantics where they make
sense, which uses the operating system provided implementation of TCP
for reliable transport, optional TLS encryption, transport metadata
like content length, and overall structure of the message content in
LLSD.)
___
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?

[Joshua Bell]

On Tue, Apr 20, 2010 at 7:15 AM, Argent Stonecutter
 wrote:
> On 2010-04-19, at 19:42, Joshua Bell wrote:
>>
>> That's a completely different issue. The lower level transport
>> protocol guarantees reliable delivery of certain types of messages -
>> packets are ack'd and resent if missed.
>
> 1. Are these messages actually being handled by that mechanism?

As far as I can tell from inspection of the code, yes. I don't know
how to correlate that with the actual behavior of the system any more
than you do, however. :(

> 2. I have seen similar failure modes in downloads over TCP where the
> end-user software declined to cross reference the expected size of the file
> and the size of the file actually transferred and reported a complete
> transfer when it wasn't actually completed. Not only does the lower level
> transport have to guarantee delivery, the higher level has to notice whether
> that happened or not. Telling it how many objects to expect (size of the
> file) or transferring a terminating token (eg, the way zip puts the
> directory at the end of the archive... which is how I discovered this
> problem) is a common safeguard.

Completely agreed. TCP guarantees the integrity of the stream, but by
itself provides no metadata about what's being transported on top of
it or that all of the data was sent. Common transfer mechanisms like
FTP and HTTP provide that, but even those don't guarantee that the
recipient processed the data it received. (Which, FWIW, motivated the
design of http://wiki.secondlife.com/wiki/Chttp)

As I mentioned previously, any new additions to the SL protocol use a
network stack with multiple layers of reliability, security and
metadata to provide transport of data that's more easily reasoned
about.
___
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] fwd/ann: Linden Lab open source LLSD code

[Joshua Bell]

We added PHP in as well. I've started to look at a Ruby impl that's kicking
around, but I'm unfamiliar with the language. might just get it passing unit
tests on all platforms then kick it out the door.

On Wed, Jun 9, 2010 at 8:07 AM, Tofu Linden  wrote:

> I saw this on the vwrap list and I thought it might be of general
> interest to opensource-dev.  Cheers.
>
> > From: Mark Lentczner 
> > Date: June 7, 2010 4:38:55 PM PDT
> > To: vwrap 
> > Subject: Linden Lab open source LLSD code
> >
> > I'm happy to announce that Linden Lab has open sourced (MIT licensed)
> its LLSD implementations in four languages: C++, JavaScript, Haskell,
> and Python. The code can be found here:
> >   http://hg.secondlife.com/llsd
> >
> > Please let me know if this is useful, and if you need any help using it.
> >
> >   - Mark & Josh
> >
> > From the README file:
> >
> > Linden Lab LLSD Libraries
> > -
> > v1 - 2010-06-07 - Joshua Bell & Mark Lentczner
> >
> >
> > ABOUT
> > =
> >
> > LLSD is defined in draft-hamrick-vwrap-type-system-00. It is a
> structured data
> > system used for interchange. See the draft for more details:
> >
> > http://tools.ietf.org/html/draft-hamrick-vwrap-type-system-00
> >
> > The design and development of LLSD is being undertaken by the IETF VWRAP
> > working group. Please direct design and development questions to its
> mailing
> > list.
> >
> > wiki - http://trac.tools.ietf.org/wg/vwrap/trac/wiki
> > list - https://www.ietf.org/mailman/listinfo/ogpx
> >
> > This distribution contains Linden Lab's open source (MIT licensed)
> > implementations of the LLSD type system in four langauges:
> >
> > C++ LLSD
> > JavaScript  LLSD & LLIDL
> > Haskell LLSD & LLIDL
> > Python  LLSD & LLIDL (*)
> >
> > There are four directories, one per file, and each has its own README
> file with
> > details for building and using the code. All versions have unit tests.
> >
> > Questions regarding these libraries can be directed to Josh or Mark:
> > j...@lindenlab.com
> > ma...@lindenlab.com
> >
> > Linden Lab hopes that by releasing these open source, it will help
> facilitiate
> > the development of LLSD, as well as ease interoperatibility with
> currently
> > deployed systems that use LLSD such as Second Life and OpenSim.
> >
> > - Josh & Mark
> >
> > (*) The Python version is currently distributed in a separate repository:
> > http://hg.secondlife.com/llbase/
> > The intention is to eventually migrate it here.
> >
> ___
> 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] voice morphing missing from viewer-external?

[Joshua Bell]

On Fri, Jun 11, 2010 at 5:49 AM, Robert Martin  wrote:

> Just as a side note could somebody please renumber the next build to
> come out as 2.1
> its kind of confusing to have the 2.1 viewer read as being the 2.0.2
> viewer especially when the new settings bits are a bit hidden.
>

Absolutely. I already griped to my old peeps on the release team, they're on
top of it.
___
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] display names = the end of 1.x viewers?

[Joshua Bell]

On Sat, Aug 21, 2010 at 1:36 PM, Argent Stonecutter  wrote:

>
> That's one thing Blue Mars does better. Your actual login identification is
> by an email address they don't share with anyone, so there's no collection
> of login names available for bulk attacks.
>
> I really wanted LL to add another layer ABOVE the account name, not BELOW
> it. :)


This was considered when the "Display Names" feature was designed, and while
this separation is not part of this work, there was care to make sure that
it wasn't precluded either.

Ideally, IMHO, there would be at least three "names":

(1) login identifier (used with password as login credential)
(2) unique human readable identifier
(3) casual conversational identifier

Prior to "Display Names", the Second Life (firstname, lastname) tuple was
used as all three. "Display Names" separates (2) and (3), but (1) and (2)
are still the same.

I'm not sure if the work to do so is on anyone's backlog - I'm betting
there's a PJIRA on it, though. Technically, it's much less code to touch
than "Display Names" (since a login-only private credential would be used in
far fewer places in the code than username or display names), but it would
be mostly server-side so the community can't help much.

Joshua
___
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] separation between login id and publicly visible id(s) (was: display names = the end of 1.x viewers?)

[Joshua Bell]

On Mon, Aug 23, 2010 at 2:32 AM, Boroondas Gupte  wrote:

>
> But even without that, a 'master account' would make a lot of things
> easier, like one could account verify all Alts at once, see billings for all
> linked agents centrally etc.
>

No argument from me!

But as with the other suggestion: this broad class of identity-related
functionality was discussed when "Display Names" was being designed, and
while not tackled as part of that project, we made sure it was not precluded
and could still be undertaken later. We very much wanted to avoid embarking
on a "everything you always wanted to do with identity" project.

Joshua
___
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] [IDEA] built-in chatlog wikification (was: Esbee Linden's OH Transcript Posted for 09/01/2010)

[Joshua Bell]

On Thu, Sep 2, 2010 at 10:49 AM, Ricky  wrote:

> Could even be
> potentially possible with LLSD since it is based in xml, but may be
> more difficult to make a good XSL document due to the fact that LLSD
> is not context-free. (The descriptor and content are sibling nodes.
> This caused me much headache many months ago!)
>

You can use XPaths like key[text()='KEYNAMEHERE']/following-sibling::* to do
key/value processing over XML-serialized LLSD in XSLT.

For example, given this XML-serialized LLSD:



  

  speaker
  Joshua Linden
  text
  Hello, world
  timestamp
  2010-09-02T12:11:44Z


  speaker
  Joshua Linden
  text
  It's lonely here
  timestamp
  2010-09-02T12:12:32Z

  


You can process it with this XSLT:


http://www.w3.org/1999/XSL/Transform";
version="1.0">



  
Chat Log

  

  

  



  

   


   


   

  




To get this HTML output:


Chat Log


2010-09-02T12:11:44Z
Joshua Linden
Hello, world


2010-09-02T12:12:32Z
Joshua Linden
It's lonely here



___
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] where is the source

[Joshua Bell]

On Mon, Sep 13, 2010 at 4:32 PM, Kelly Linden  wrote:

> I'd love to see that syntax highlighting and hover tip code replaced, we
> really shouldn't need anything in lscript in the viewer. If the syntax
> highlighting / hover tips could be read from an LLSD we could provide a
> capability 'lsl-syntax' which could be queried for a version or the whole
> map. Then you could get accurate syntax highlighting for the sim you are on
> independent of the viewer.
>

At the risk of designing this via email... oh, what the heck.

User story: "As a developer of LSL scripts, I want LSL the syntax
highlighting dictionary to be updated automagically so I don't have to
upgrade my viewer whenever new LSL functions or keywords are added."

Per-sim versioning is a nice-to-have but we could probably start simpler and
have a per-grid resource. During login, the viewer can be given the URL to
an LLSD resource it can *lazily* request. (We do this for other grid-wide
services.)

We could later choose to extend this to be a capability granted by the
simulator, which the viewer could query on each region change (when it gets
a new seed cap) to give the granularity Kelly describes above.

The server side changes to deliver a static URL to an LLSD resource from
login are minimal; if someone wants to take a stab at the client side
changes and defining a forward-looking LLSD format, I'm sure you'll find a
server-side champion.
___
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] off the wall idea of the day

[Joshua Bell]

On Thu, Sep 23, 2010 at 6:41 PM, Ponzu  wrote:

> "Logging in" is so *boring*.  You log in to the mainframe, or your prison
> cell.  When a user connects to Second Life, we need a better metaphor and a
> more "fun" experience.
>
> I am thinking of something like ENTER THE METAVERSE  or UPLOAD YOURSELF
> NOW.  Then, instead of the boring progress bar, how about swirling lights or
> a visual whirl pool or something, like a music visualization plug in from
> iTunes.
>

I seem to recall an internal idea discussed circa 2006 (so I think the
statute of limitations has expired...) that presented progress starting with
a tunnel of swirly lights which resolved into a view of the world map zoomed
all the way out. As login progressed, the map would zoom in to your
destination until it finally just tipped to match your initial view.

Cool as that would be, I'd rather dedicate engineering time to reducing
login time as much as possible first.

Has anyone recently profiled what the viewer is doing during launch (app
start to login screen display) and login (while the progress bar is showing)
to make sure that regressions haven't been introduced, and see what could be
optimized?

Joshua
___
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] 2.0 Absolute Dealbreaker - script count feature request

[Joshua Bell]

Taking a stab at a user story:

As a land owner, I want to ensure that sim performance is not negatively
impacted by particular avatars with lots of scripts, so that all users of
the sim have a good experience.

That abstracts away the mechanism... which suggests to me that approaches
like dynamic per-avatar caps on script cycles might be a better approach to
pursue than specific functions that enable monitoring. But I'm probably
over-abstracting the desire and it would encode the policy in the sim,
rather than letting land owners self-manage. Can we craft a better user
story to capture the true need?

On Wed, Sep 29, 2010 at 4:09 PM, miss c  wrote:

> Let me reword that last part.  I should be able to locate a person using
> excessive amounts of resources on my sim.  I also should be able to stop
> random people on alts setting out to grief secretly with the overuse of
> scripts.
>
> --
> *From:* miss c 
> *To:* Zi Ree ; opensource-dev@lists.secondlife.com
> *Sent:* Wed, September 29, 2010 5:45:25 PM
>
> *Subject:* Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count
> feature request
>
> This is a tough one because it does leave a lot of guess work, but still
> could be added to my list of tools I use to guess with.  I will totally take
> it if it's being offered, I just pray this inst the foundation the future
> tools will be built off of.  And about the whole banning, my regions
> private, just open to the public, if I want to ban anyone coming in my sim
> wearing pink, I can.  I hope thats not why tools are being kept from us, is
> because the Linden's are afraid we will make unintelligent bans.  I pay a
> lot of money out I should be able to do what I want with it within the ToS,
> I should be given the tools to at least keep random newbs from secretly
> crashing my sim.
>
> --
> *From:* Zi Ree 
> *To:* opensource-dev@lists.secondlife.com
> *Sent:* Wed, September 29, 2010 5:28:07 PM
> *Subject:* Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count
> feature request
>
> > Do you want an incomplete yet helpful solution doable now, to be
> > improved/completed later on,
> > or do you prefer to wait another 6-12+ month with nothing at all?
>
> Since improvised and incomplete solutions tend to become the final one
> after a
> while, and since I have no issues with script memory whatsoever, I rather
> wait
> for a fully functional, complete implementation than seeing a temporary and
>
> useless "solution" in place.
>
> Zi
> ___
> 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
>
___
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] Problem with displaying Arabic menu text in SL client

[Joshua Bell]

On Tue, Oct 5, 2010 at 4:32 AM, izze euler  wrote:

>  Are you able to give an example on how to use this character within an XML
> file?
>

Using that character won't have any effect. As Boroondas mentioned, Second
Life's text engine is pretty basic and simply doesn't support:

   - Right-to-Left scripts - typically this functionality is called "BiDi"
   since the  direction actually changes within text strings for numbers,
   foreign words, etc.
   - Contextual shaping (think: ligatures as a mandatory language feature)
   - Combining characters/diacritics* (think: characters merge into single
   glyphs)
   - Complex word breaking (for languages that don't use spaces)

This is a big task, and (as Boroondas also mentioned) is probably best
tackled by a thorough overhaul/replacement of SL's text rendering engine as
Alissa Sabre attempted.

Additionally, if we're talking about a localized version of the UI and not
just rendering text content correctly, you'd also want to flip the X
coordinates for some (but not all) UI layout if the app was running with a
UI language that was RTL, which would require changes to the XUI engine and
some of the controls. (Since, ideally you don't have to touch all of the
control rects in all of the XUI files)

-- Josh

* I look forward to the day when someone writes a text engine that handles
the character combining logic for classical Mayan.
___
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] Where oh where has my rendering gone?

[Joshua Bell]

On Tue, Oct 5, 2010 at 7:29 PM, Kent Quirk (Q Linden) wrote:

> Well, it's not quite like that. To pull this off, you'd have to take
> everywhere we set a color, and set it instead to its equivalent black and
> white value (there's a formula that's traditionally used, although there's
> no "correct" way to do it:  Y = 0.3*R + 0.59*G + 0.11*B). You *might* be
> able to get away with modifying the LLColor4 constructor to do this, but
> it's probably going to have some surprising results when you assign a value
> and don't get the same value back.
>

How about post-processing every frame before the final swapBuffers call?
That seems like it could be done with a shader and only touching a small
amount of code. This would affect the UI as well as the world viewport,
however, without some significant refactoring, but given that we already
have some post-processing effects (glow, etc) perhaps there's already a good
spot to slot this in?

(Don't trust me too much, though, as I've never written a non-trivial shader
and have never touched the viewer's render pipeline!)

Of course, once you have monochrome output, you could tweak the shader and
get sepia-toned rendering. Old-timey SL, anyone?

-- Josh
___
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] Latest LL viewer beta has inventory count issues?

[Joshua Bell]

On Wed, Oct 6, 2010 at 8:24 AM, Oz Linden (Scott Lawrence)  wrote:

>  On 2010-10-05 17:43, Ann Otoole wrote:
> > However I do know asset data is "vanishing". I have a ticket open and
> > never looked at in respect to a humble shoe texture I created and
> > uploaded to SL that has vanished from the asset system.
>
> Do you have an id for that ticket?   The first question is whether the
> UUID actually exists correctly in the asset store and the viewer is
> failing to retrieve it correctly, or whether the data in the asset store
> is itself lost or corrupted.
>

+1 - there's a fairly deep pipeline between where the assets are actually
stored and the viewer, and of course there's the possibility of a bug
anywhere in between. An asset ID is all we need to start investigating.

-- Josh (Caches and proxies and redirects, oh my!)
___
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] Problem with displaying Arabic menu text in SL client

[Joshua Bell]

On Thu, Oct 7, 2010 at 8:25 AM, izze euler  wrote:

>  Would it be possible to create images containing the arabic text and
> displaying those instead of processing through Second Life's text engine?
>
>
Possible? Yes, it's just software.

Practical? No.

Given the amount of text in the UI and the flexibility of the UI to scale
text, render text with different colors, wrap text messages, and (of course)
the need to handle strings that aren't built into the viewer - localized
strings provided by server messages, text chat, etc - the work involved
would be much larger than integrating a new text engine. The ongoing
maintenance costs would be tremendous. Any any hack suggested to reduce the
cost turns it either into a non-general solution (i.e. something we wouldn't
want to ship/maintain) or approaches the general solution (e.g. render
composed strings into images on the fly... by integrating a new text engine)

-- Josh
___
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] LLSD logs (was: O.O Display name code DROP!)

[Joshua Bell]

On Fri, Oct 15, 2010 at 5:12 PM, Ricky  wrote:

> Ah yes, I'd forgotten that there was more than one form for LLSD...
> I've only worked with the XML-style one thus far!  Since, as you say,
> the format is not in the XML style, then it is likely that they
> hadn't.  Or that they had, but chose this style for being more "human
> friendly" - like you said.
>
> Since, as the linked page describes, the plan is to move this format
> into JSON, maybe this is a good opportunity for a community dev to get
> it fully into JSON format.  ECMAScript 5th edition looks to be
> finalized:
> http://www.ecma-international.org/publications/standards/Ecma-262.htm
>
> Then we could just use some JSON tools to write a converter.   Or we
> write a patch for exporting in XML notation, as that provides some fun
> options, as discussed previously.
>

We have source code up at:

http://hg.secondlife.com/llsd

... and most of the supported languages can
read/write Notation, XML, JSON and Binary serializations of LLSD.

Notation serialization is loosely deprecated but has some benefits over JSON
in that all LLSD types are explicitly serialized, whereas when serializing
to JSON the consumer must interpret values in the correct format (e.g.
data['foo'][2]['bar'].asUUID()). That's the intended use of LLSD, but not
everyone follows that intent.

-- Josh
___
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] Stuff I'd like to see in the coming sprint

[Joshua Bell]

On Tue, Oct 19, 2010 at 7:05 AM, Boroondas Gupte  wrote:
>
> VWR-23306  Detect UI skins
> at runtime
>
>- Needs some discussion: As skins can change functionality (to some
>extend) or change how/where certain functionality is accessible, we need
>ways to avoid this feature to become a major problem for customer support.
>- Some code by Robin Cornelius that's related to this has been annexed
>by some LL-internal project and she was asked not to publish it to avoid
>merge problems. In order to avoid duplication of efforts (and probably even
>worse merge problems), can this project please be opened up? If not, it'd 
> be
>good to release at least sufficient information to make some collaboration
>on this topic possible.
>
> We hope to land the set of changes including this work in
viewer-development within the next month or so. It's based off of
viewer-development and we're tracking it closely, so we do not expect there
to be significant merge problems.

The changes are being wrangled part of one of those few projects that we are
not doing completely in the open, and I can't comment further on the "why"
of that. That said, I can state that the changes are pretty mundane and
won't suddenly appear in a production viewer without going through
viewer-development first - they'll land there just like any other patches
and work their way through the normal release process.

-- Josh
___
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] Is there supposed to be a login web page for the development viewer? (An SL screenshot, maybe some text, like the regular viewer has)

[Joshua Bell]

On Mon, Nov 22, 2010 at 4:58 PM, Chuck Baggett wrote:

> When I log in with the development viewer there is no login web page, just
> a little question mark.  The part at the bottom where you enter your
> username, password, etc. works fine.  Is there supposed to be an SL
> screenshot, maybe some text, like the regular viewer has?
>

This should be working now. Apparently we changed the channel name and/or
page logic at some point and didn't ensure all of the resources were in
place for the "Second Life Development" channel.
___
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] More login channels (with missing background images on the login screen) (was: Is there supposed to be a login web page for the development viewer? (An SL screenshot, maybe some t

[Joshua Bell]

On Tue, Nov 23, 2010 at 12:21 PM, Boroondas Gupte <
slli...@boroon.dasgupta.ch> wrote:

> Thanks! Looks like more needs to be done, though:
>
> When I build from bitbucket.org/lindenlab/viewer-development, the
> resulting viewer tries to access
> http://secondlife.com/app/login/?lang=en&channel=*LindenDeveloper*
> &version=2.5.0%20%280%29&grid=Agni when loading the login screen.
>
> Ah, thanks. I did just plunk in the first channel name I found that looked
right. I plopped an image in for LindenDeveloper as well.

> Maybe the page should display some nice image even for unknown channels?
>
That's the right thing to do... but the whole login screen pipeline (front
end and back end) is a bit grotesque at the moment and could use redoing, so
it should wait for a comprehensive overhaul. Linden should be providing
images for any source code or viewer we release, and TPVs typically use
their own page anyway, so I'm content to just copy/paste the images for now
so it's not so ugly.

> If not, at least LindenDeveloper and maybe also Developer should be added
> to get some background image, too. And wasn't there once a "Community
> Developer" channel or similar?
>
Are those actually in use somewhere? If so I can de-uglify them.

Joshua
___
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