Re: [opensource-dev] Registering a SL Review Board
Or if it prefixed the message subjects with a [RB] tag, or similar. That would provide the same filterability, at least in gmail, while being easier to implement. Ricky Cron Stardust On Thu, Dec 2, 2010 at 5:58 AM, WolfPup Lowenhar wrote: > I would be nice if the review board system had an address that was something > that people that use email programs( I.E. Outlook, Thunderbird, Incredimail) > could much easier filter. Like nore...@codereview.secondlife.com or > something similar that way if they set up a filter it would not interfere > with any other filters they have set up that are for SL. > > > > From: opensource-dev-boun...@lists.secondlife.com > [mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Oz Linden > (Scott Lawrence) > Sent: Thursday, December 02, 2010 8:41 AM > To: opensource-dev@lists.secondlife.com > Subject: Re: [opensource-dev] Registering a SL Review Board > > > > On 2010-12-02 8:23, Jonathan Welch wrote: >> Will the email address we input during the registration process be >> visible at any point? > > Yes, since the email that reviewboard sends about whatever you did will > be the From address. > > If you prefer, you can use the email address that you use for the > opensource list (I'd still suggest that you make both of those addresses > the same, but the jira address can be changed too). > > My main concern is that the usernames be the same, so that if > ReviewBoard actually does OpenId (it is on their backlog), then we can > start using that. > > ___ > 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 > > > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1170 / Virus Database: 426/3292 - Release Date: 12/01/10 > > ___ > 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] ReviewBoard email to this list?
I agree, I prefer them here. However, in such a case, they need to be a tad easier to filter, which is why I suggested an [RB] (or similar) subject tag. This would be consistent with the policies for this list, and would allow easy filtering. The string "Review Request:" is a tad ambiguous, as that might show up in someone's email, and it inconsistent with the existing list policies of [META], [POLICY], etc. Ricky Cron Stardust On Thu, Dec 2, 2010 at 6:49 AM, Stickman wrote: >> Even easier (for subscribers) would be to have a separate mailing list for >> the automatic Review Board emails. Then, everyone can decide themselves >> whether to subscribe to that, too (or even only to that). Non-subscribers >> would still have the option of seeing the threads on the list's archive >> website. > > The review board emails are closely tied with viewer/opensource > development. I'm not sure splitting them out into a separate list > would work very well as there's too much overlapping content and they > would be constantly spilling back into this list as discussions > started up based on them. Or worse, not spilling back into this list > as discussions pertinent to viewer development started up. > > Stickman > ___ > 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] Review Request: Restructure loops that use breaks without need (reviewboard test)
Hmm, it appears to have "background-image:
url('http://codereview.secondlife.comrb/image=s/review_request_box_top_bg.png');"
in the style attribute for one of the tables. (Don't know why tables
were used instead of divs like the site is built...)
Beyond the fact that it isn't necessary, the URL is also wrong. The
correct URL is:
https://codereview.secondlife.com/media/rb/images/review_request_box_top_bg.png
Ricky
Cron Stardust
On Thu, Dec 2, 2010 at 12:05 PM, Gigs wrote:
> I'm getting "To protect your privacy, Thunderbird has blocked remote
> content." Why do the message include external images? As well because
> the "From" field is a person and not the list, I would have to whitelist
> every contributor to get rid of the message.
>
> On 12/02/2010 12:05 PM, Thickbrick Sleaford wrote:
>>
>> This is an automatically generated e-mail. To reply, visit:
>> http://codereview.secondlife.com/r/2/
>>
>>
>> indra/newview/llappviewer.cpp
>> <http://codereview.secondlife.com/r/2/diff/1/?file=8#file8line1184>
>> (Diff revision 1)
>>
>> bool LLAppViewer::mainLoop()
>>
>> 1184
>>
>> const F64 max_idle_time =
>> llmin(.005*10.0*gFrameTimeSeconds, 0.005); // 5 ms a second
>>
>> 1184
>>
>> const F64 max_idle_time =
>> llmin(.005*10.0*gFrameTimeSeconds, 0.005); // 5 ms a second
>>
>> Somewhat tangential to this patch: this line is wrong. It should use
>> gFrameIntervalSeconds, not gFarmeTimeSeconds. As it is, max_idle_time will
>> always be clamped to 0.005.
>>
>> The comment is also wrong/outdated. It should be something like"50
>> ms/second, up to 5 ms/frame."
>>
>>
>> - Thickbrick
>>
>>
>> On December 1st, 2010, 7:57 p.m., Oz Linden wrote:
>>
>> Review request for Viewer.
>> By Oz Linden.
>>
>> /Updated 2010-12-01 19:57:24/
>>
>>
>> Description
>>
>> This review is mostly a first test of reviewboard.
>>
>> I do have an esthetic dislike for the'break' statement anywhere but as the
>> end of a case, so I chose to change some instances of break usage that were
>> not justified by any extreme need.
>>
>>
>> Testing
>>
>> None at all... have not even compiled it yet.
>>
>> *Bugs: * storm-606 <http://jira.secondlife.com/browse/storm-606>
>>
>>
>> Diffs
>>
>> * indra/newview/llappviewer.cpp (bf98b026bcb1)
>>
>> View Diff <http://codereview.secondlife.com/r/2/diff/>
>>
>>
>>
>> ___
>> 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] minimap broken in 2.3 and above?
I spend most of my time in region-wide sandboxes using whatever version (2.5.0.215253 at the moment) of the developer version is available when I get around to it, and I havent had a problem. However, take it with a grain of salt, as platforms tend to obstruct ground level.. (As they should.) Have you verified with viewers from the beta and development downloads? That could tell if what you are seeing is still in the codebase or whether it disappeared already. I figure that you have, just have to ask for clarification. :) Ricky Cron Stardust On Sat, Dec 4, 2010 at 2:29 PM, Lance Corrimal wrote: > Hi there, > > > is it just my imagination, or is the minimap majorly broken in any 2.x > viewer since 2.3-release? More often than not it simply refuses to > load any ground textures, so the minimap looks like you're way out on > open water... not useful for sailing at all. > > Is there already a jira for it? > > bye, > LC > ___ > 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] [WEB] Some Wiki pages unreadable when not logged in
I was just looking up a reference in the wiki ( http://wiki.secondlife.com/wiki/LlKey2Name ) and found it to be largely empty! I then check history and source, all looked good. So I browsed other functions, some were visible, some not. Then I logged in, and viola all were visible. Logged back out, empty again. Maybe some common template was messed up for anon users? Ricky Crons Stardust PS: Yes, this isn't a viewer issue, but that's why I marked it [WEB]. However, I figure someone with more knowledge of the LL wiki template architecture might be able to shed some light/fix 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] Exclude Home from teleport history
A method of filtering the history would give the wanted effect I presume. Ricky Cron Stardust On Sun, Jan 2, 2011 at 11:39 AM, Erin Mallory wrote: > I would really really rather not see home excluded because of the simple > fact often home lotation can get reset if your preferences get changed or > any of a half dozen minor bugs. so its nice to have it in the hisotry so > you can go back and set it back. > >> Date: Sun, 2 Jan 2011 20:25:37 +0100 >> From: laurent.bec...@madonie.org >> To: opensource-dev@lists.secondlife.com >> Subject: [opensource-dev] Exclude Home from teleport history >> >> >> Hello, >> >> Would it be easy to exclude home from Teleport history ? It would make >> it easier to see what' in >> ___ >> 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
[opensource-dev] VWR-8208 Searchable "Debug Settings"
I was just about to create a JIRA entry for the idea of making things easier to find in the Debug Settings menu, when I found an existant JIRA on the subject. VWR-8208 "find instead of auto-complete for Debug Settings" https://jira.secondlife.com/browse/VWR-8208 It would be great to have some attention paid to this concept, as it should be fairly trivial to implement, and would make working with those entries a lot easier. Just making some noise about one of my annoyances... 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
Re: [opensource-dev] VWR-8208 Searchable "Debug Settings"
Thank you Jonathan and Marine. These workarounds are good, and I will tap into them. Hopefully an in-client solution isn't too far into the future! :) Ricky On Sun, Jan 2, 2011 at 1:52 PM, Marine Kelley wrote: > What I do is open my settings.xml file and search what I want with a > text editor, it works. > > On 02/01/2011, Ricky wrote: >> I was just about to create a JIRA entry for the idea of making things >> easier to find in the Debug Settings menu, when I found an existant >> JIRA on the subject. VWR-8208 "find instead of auto-complete for >> Debug Settings" https://jira.secondlife.com/browse/VWR-8208 >> It would be great to have some attention paid to this concept, as it >> should be fairly trivial to implement, and would make working with >> those entries a lot easier. >> >> Just making some noise about one of my annoyances... >> 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] https://jira.secondlife.com/browse/SH-489
I'm not sure it is a separate problem, or related, but I've been able to see people's voice dots for extreme distances (whenever they are >1px,) through any number of intervening prims. Even if the nametag is obscured, the voice dot comes through. Has given me quite the advantage in "hide-and-seek" style gameplay. Not sure when I first noticed this, and I haven't started any digging... Ricky On Sun, Jan 9, 2011 at 9:30 AM, Lance Corrimal wrote: > Am Sonntag, 9. Januar 2011 schrieb Robert Martin: >> On Sun, Jan 9, 2011 at 10:09 AM, Ponzu wrote: >> > Can someone give a cheap estimate of how hard this will be to >> > fix? if it is easy to fix, I agree that it should be done soon. >> >> i would say that a full audit of the hover text submodule would be >> in order (say 4 hours of junior grade programmer??) > > I'd say a udo of the changes since 2.1 is in order, it seems to be a > regression... > > bye, > LC > > ___ > 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] 5 Channel JPEG2000
Question: what, if anything, is the 5th channel currently used for? 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. 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
Re: [opensource-dev] Pre-processing chat input (was Re: Review Request: STORM-829 Viewer 2 does not parse /me in object Instant Messages
Interesting. I haven't tested other IM clients in recent history, but Skype still supports the /me syntax. I suspect that the others do so as well. Just my L$2... Ricky Cron Stardust On Wed, Jan 12, 2011 at 7:25 AM, Tateru Nino wrote: > > > On 13/01/2011 2:17 AM, Jamey Fletcher wrote: >> Tateru Nino wrote: >> >>> Which is a shame. It's significantly less versatile that way. >>> On 13/01/2011 12:06 AM, Nexii Malthus wrote: >>>> "/me " is a *post-process*. >> I'm missing what versatility we're wanting in /me - I've always seen it >> as a rather straight-forward substitution. >> > Well, using myself for an example, I'm used to using a completely > different set of tokens and substitutions for that sort of thing. I > think SL is the only thing I use that supports the old IRC syntax. I > find it awkward, and it would be nice to be able to use conventions that > are more common to the software that I use. As a post-processed > substitution token, though, I just don't have the luxury to use familiar > textual communication modes. > > -- > Tateru Nino > http://dwellonit.taterunino.net/ > > ___ > 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] Pre-processing chat input (was Re: Review Request: STORM-829 Viewer 2 does not parse /me in object Instant Messages
I tend to agree with you Argent. Just a simple replace is fine. While the tools I mentioned seem to all support the "/me" syntax, and may even specially highlight such messages, I'd rather that they didn't. In actual chat I don't find myself using "/me" a lot, whether in SL or out. However, I DO use it in LSL extensively. Ricky Cron Stardust On Thu, Jan 13, 2011 at 5:16 AM, Argent Stonecutter wrote: > On 2011-01-12, at 16:32, Joel Foner wrote: >> Skype still supports /me... Many of the folks I know use /me regularly, for >> what it's worth. Skype displays the difference much more obviously, placing >> the text centered with different styling than normal chat with /me, so it >> has more emphasis than in sl visually. > > I don't understand why it needs to be highlighted at all. Just get rid of the > ":" and if there's punctuation the following space. I find the italics in > viewer two stupidly annoying. ___ 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] "Nearby" people tab
I have had no issues with the "nearby" tab of the sidebar. I regularly exist at 2000 to 4000 meters, and occasionally at ground level (our island is platformed instead of parceled). However, I DO wish to note that I have the maximum range of the list set at 4096... I use it as a better performing replacement for my scripted radar. (Which is why https://jira.secondlife.com/browse/STORM-642 and children exist.) My tested systems are currently largely Intel Macs (Mini, Pro Desktop, MacBook Pro, and MacBook) with a couple of Windows XP boxes. My beloved Linux box recently was placed in suspended decay due to hardware problems... Ricky Cron Stardust On Sat, Jan 29, 2011 at 4:01 PM, Kadah Coba wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Are you above 1000m? > > On 1/29/2011 3:50 PM, Dave Booth wrote: >> Whats the expected behavior of this tab of the people sidebar? I'm >> currently sitting in a room with 14 other folks, half of whom are on my >> flist and all within chat range - but this tab tells me "no one nearby". >> Currently on Second Life 2.6.0 (21) Jan 29 2011 12:57:40 (Second >> Life Development) but to be honest I dont think I've EVER seen that tab >> populated, no matter what build or how crowded the venue. >> ___ >> 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 > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJNRKpHAAoJEGUNvxojA31thvcIAI78LVkHyDYwejCbLaehmDAE > LlAe+mLqGyb1D7yO9NeAQkdhwNZSInKqdvKrHCMYQFifbQk/Z1aE+nYUoRoMa7/J > 42Wo52L87mKEdA9fg7aPlWHEBgiP+d/6y5oK4hRDtJLcH1G6sHGSIeCFsvaTo2la > OEMzSP5l3N4c0hzxFeDR80YwPT1iYKrRqXdfUNhwyyQV3/QHrEnNmmkdk3dXSsQ2 > hDpk9g3ui+uBh1zW/IzZ7RXgCPcMxHQdTONesLmeK1F9c6iLi4MIbrZ5WJkSGAtn > 4kTyUeCPu8CTumXNX1n4pwKkO/gAyCXpifa4Aow/CGvjGyt2AY/SPcDmjvGJfzw= > =EZAf > -END PGP SIGNATURE- > ___ > 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] Help prevent DOS line endings...
Added Programmer's Notepad (my favorite for Windows). Ricky Cron Stardust On Tue, Feb 1, 2011 at 4:35 AM, Oz Linden (Scott Lawrence) wrote: > Other than a few files that appear to be completely Windows specific, > and I did not know for sure did not require them, I've converted all the > DOS line endings in viewer-development back to plain linefeeds. I'll be > checking regularly for any that get added (hopefully before they get > into the main repo) and advising the perpetrators of the error of their > ways... > > So that I have a resource to direct them to, and to help prevent any new > developers from committing this minor sin, we need a set of clear > instructions on what Windows tools do this correctly and how to > configure them to do so. Please help by adding to: > > https://wiki.secondlife.com/wiki/How_to_avoid_DOS_line_endings_in_Windows_tools > > ___ > 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] Is 'STANDALONE' confusing?
My vote is for USE_SYSTEM_LIBS. It needs no semantic inversion, only a simple name replace. The only issue I can think of is that system wide user libs are considered "system" by this, but I consider that to be a trivial complaint. That said, the above inverting suggetion is still better than what we have now! :P Ricky Cron Stardust On Monday, February 21, 2011, Boroondas Gupte wrote: > On 02/21/2011 04:41 PM, Aleric Inglewood wrote: >> A LOT worse, but still better than 'standalone' would be USE_SYSTEM_LIBS. > Why would you consider USE_SYSTEM_LIBS worse than other suggestions? > > 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 > ___ 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] VWR-25120 - viewer_manifest.py has incorrect case for "Rez" command on case-sensitive Macs
As I've again found a few more moments to try compiling the viewer again, this time on my Mac, I ran across an issue that was trivial to take care of: incorrect command name case on the Apple-specific command "Rez". Here's the link: https://jira.secondlife.com/browse/VWR-25120 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
Re: [opensource-dev] Review Request: Squared all dist_vec() based comparisons and other dist_vec() operations where sensible.
Thanks for the review! Yes, I am familiar with those "principles of
optimization" - yet it seemed to just feel wrong to leave it alone... :P
As to the variables that are initialized with high numbers, there has to be
a better way: if these were standard for-loops, I would just initialize
the first value with the first item in the list, and then start the loop at
the second value, if any. However, these are a iterator style I am not yet
familiar enough with to bend that far. Any suggestions?
Ricky
Cron Stardust
On Fri, Mar 11, 2011 at 3:53 AM, Boroondas Gupte wrote:
>This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/199/
>
> Good idea.
>
> Off course, the two main rules of optimization are:
> 1. Don't optimize.
> 2. Don't optimize yet (experts only).
>
> Though, comparing squared distances instead of actual distances can probably
> be considered standard practice and both the proposed change as well as the
> resulting code are still easy to understand. Also, you already measured the
> operations in isolation and it's unlikely we'll have hardware that calculates
> square roots faster than it multiplies in the foreseeable future, so this is
> different than, say, bit-shifting with addition to replace integer
> multiplication. Still, it'd be nice to have some measurements of how this
> affects in-viewer performance.
>
> Some comments about the actual code:
>
>
>
> indra/newview/llnetmap.cpp<http://codereview.secondlife.com/r/199/diff/1/?file=1187#file1187line337>
> (Diff
> revision 1)
>
> void LLNetMap::draw()
>
> 337
>
> F32 closest_dist = F32_MAX;
>
> 337
>
> F32 closest_dist_squared = F32_MAX;
>
> Maybe add a short comment here, that this value is meant to be overwritten
> in the loop below it.
>
>
>
> indra/newview/llpanelpeople.cpp<http://codereview.secondlife.com/r/199/diff/1/?file=1188#file1188line161>
> (Diff
> revision 1)
>
> public:
>
> 161
>
> F32 dist1 = dist_vec(item1_pos, me_pos);
>
> 161
>
> F32 dist1 = dist_vec_squared(item1_pos, me_pos);
>
> 162
>
> F32 dist2 = dist_vec(item2_pos, me_pos);
>
> 162
>
> F32 dist2 = dist_vec_squared(item2_pos, me_pos);
>
> For clarity, please rename these variables to dist1_squared and
> dist2_squared, too. Or eliminate them by calling dist_vec_squared right in
> the return statement:
> return dist_vec_squared(item1_pos, me_pos) <
> dist_vec_squared(item2_pos, me_pos);
>
> (A bit long, but still shorter than the lines right above it.)
>
>
>
> indra/newview/llselectmgr.cpp<http://codereview.secondlife.com/r/199/diff/1/?file=1189#file1189line6573>
> (Diff
> revision 1)
>
> bool LLSelectMgr::selectionMove(const LLVector3& displ,
>
> 6573
>
> F32 min_dist = 1e+30f;
>
> 6573
>
> F32 min_dist = 1e+30f;
>
> This should probably start at 1e60f, now. Though ... if there is no
> specific reason for the previous 1e30f value, just make it F32_MAX, I guess.
> Might also be worth a comment, that it will be overwritten in the loop below.
>
>
>
> indra/newview/llselectmgr.cpp<http://codereview.secondlife.com/r/199/diff/1/?file=1189#file1189line6574>
> (Diff
> revision 1)
>
> bool LLSelectMgr::selectionMove(const LLVector3& displ,
>
> 6574
>
> LLVector3 obj_pos;
>
> 6574
>
> LLVector3 obj_pos;
>
> 6575
>
> for (LLObjectSelection::root_iterator it =
> getSelection()->root_begin();
>
> 6575
>
> for (LLObjectSelection::root_iterator it =
> getSelection()->root_begin();
>
> 6576
>
>it != getSelection()->root_end(); ++it)
>
> 6576
>
>it != getSelection()->root_end(); ++it)
>
> 6577
>
> {
>
> 6577
>
> {
>
> 6578
>
> obj_pos = (*it)->getObject()->getPositionEdit();
>
> 6578
>
> obj_pos = (*it)->getObject()->getPositionEdit();
>
> 6579
>
>6579
>
> 6580
>
> F32 obj_dist = dist_vec(obj_pos,
> LLViewerCamera::getInstance()->getOrigin());
>
> 6580
>
> F32 obj_dist_squared = dist_vec_squared(obj_pos,
> LLViewerCamera::getInstance()->getOrigin());
>
> 6581
>
> if (obj_dist < min_dist)
>
&g
Re: [opensource-dev] Snowstorm 2.6.1 with Advanced and Basic mode
I like those: my mind was in a conflict whether the list should be sorted alphabetically or, as currently done, by purpose. With names like you are proposing, both would be the same! Ricky Cron Stardust On Fri, Mar 18, 2011 at 2:45 PM, Da5id Kronfeld wrote: > > On 2011-03-18, at 1:37 PM, Trilo Byte wrote: > > 3) I think the mode names should be different. Advanced could seem > intimidating to users who are new or who only have casual interest, and adds > confusion considering that there's an advanced mode/menu within the Advanced > mode. > > "Introductory Mode" and "Normal Mode"? > ___ > 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] Review Request: Squared all dist_vec() based comparisons and other dist_vec() operations where sensible.
ok, this is getting annoying. Any idea why I am having issues posting to the review? Ricky Cron Stardust On Mon, Apr 4, 2011 at 4:48 PM, Cron Stardust wrote: >This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/199/ > > Huh.. long winded speech became dust on pressing publish... Here goes again: > > > - Cron > > On April 4th, 2011, 10:34 a.m., Cron Stardust wrote: > Review request for Viewer. > By Cron Stardust. > > *Updated April 4, 2011, 10:34 a.m.* > Description > > I looking at the code, trying to find out where/how to add a new feature, > when I tripped across one of these and it lit my mental warning bells off. > Vector distance comparisons should, IMHO, always be done squared. So I did > some greppin, manual analysis, and some careful modification, and here's the > result. > > Testing > > Compiled a test viewer and used it, undertaking some of my normal activities. > Results felt good, but are currently anecdotal. Any suggestions on how to > properly measure this (or even some actual measurement from those already > instrumented to measure these things,) would be great! > > *Bugs: * VWR-25126 <http://jira.secondlife.com/browse/VWR-25126> > Diffs > >- doc/contributions.txt (344d4c6d7d7e) >- indra/llcharacter/llbvhloader.cpp (344d4c6d7d7e) >- indra/llcommon/indra_constants.h (344d4c6d7d7e) >- indra/llmath/tests/llbbox_test.cpp (344d4c6d7d7e) >- indra/newview/llagent.cpp (344d4c6d7d7e) >- indra/newview/llfloaterchat.cpp (344d4c6d7d7e) >- indra/newview/llhudeffectlookat.cpp (344d4c6d7d7e) >- indra/newview/llhudeffectpointat.cpp (344d4c6d7d7e) >- indra/newview/llmaniprotate.cpp (344d4c6d7d7e) >- indra/newview/llmanipscale.cpp (344d4c6d7d7e) >- indra/newview/llnetmap.cpp (344d4c6d7d7e) >- indra/newview/llpanelpeople.cpp (344d4c6d7d7e) >- indra/newview/llselectmgr.cpp (344d4c6d7d7e) >- indra/newview/llspeakers.cpp (344d4c6d7d7e) >- indra/newview/llviewerchat.cpp (344d4c6d7d7e) >- indra/newview/llviewermessage.cpp (344d4c6d7d7e) >- indra/newview/llviewerparceloverlay.cpp (344d4c6d7d7e) >- indra/newview/llvoicevivox.cpp (344d4c6d7d7e) >- indra/newview/llworld.cpp (344d4c6d7d7e) > > View Diff <http://codereview.secondlife.com/r/199/diff/> > ___ 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 trouble (was: Review Request: Squared all dist_vec() based comparisons and other dist_vec() operations where sensible.)
I was just doing a straight review, not a source review, and all the text was gone. Then I added a comment to my own empty review, and poof, all but the first line are gone. Very strange. I did paste in some code as part of an idea I was trying to talk about, but that started on line 3 of the response, and on line 2 of the original. Too bad I forgot to copy before publish! Well, I'll rewrite it again and post it here in response to the review thread. Ricky Cron Stardust - Persevering in the face of perversity On Mon, Apr 4, 2011 at 4:54 PM, Boroondas Gupte wrote: > On 04/05/2011 01:49 AM, Ricky wrote: >> ok, this is getting annoying. Any idea why I am having issues posting >> to the review? > Mayhaps you added comments to code-lines but didn't save them? Also, > comments with overlapping code-line ranges (e.g. one comment about lines > 1-7 and one about lines 3-9 of the same file) sometimes eat each other. > If you want to see what would get published before hitting the "publish" > button, click "Edit Review" instead. > > 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
Re: [opensource-dev] Review Request: Squared all dist_vec() based comparisons and other dist_vec() operations where sensible.
And since that failed too, I'll try the tried-and-true email list! Ha! In llselectmgr.cpp (around lines 6586-6595) we've been beating our heads against some rather... interesting... code. I had tried adding a variable to make things clearer, but I now suggest to jump sideways, and try another route. Consider the following replacement for the section under consideration: --- } // factor the distance into the displacement vector. This will get us // equally visible movements for both close and far away selections. F32 min_dist = sqrt(fsqrtf(min_dist_squared)) / 2; displ_global.setVec(displ.mV[0] * min_dist, displ.mV[1] * min_dist, displ.mV[2] * min_dist); // equates to: Displ_global = Displ * M_cam_axes_in_global_frame --- Yes, the double nested sqrt is rather strange to behold. The inner fsqrtf came from the definition of vec_dist() and I wanted it to match that definition to make absolutely sure that this change is nothing more than a refactor. The inner sqrt is to make it the minimum distance. The outer, and its subsequent division by two, are what are so confusing: what does this code do? Why does it do it that way? The comment doesn't seem to shed much more light than can be gained from reading the code; it doesn't give the reasons behind the functionality. Now, as to what fsqrtf is... According to math.h, it is part of a multiple-level #define chain that results in the following: fsqrtf(x) = sqrtf(x) = ((F32)sqrt((F64)(x))) So aside from the extra type conversions, fsqrtf is practically the same as sqrt. Does that change anything? Should I just make both sqrts one or the other? Or should I just leave this mess and move on to making sure the rest of the patch is done? (Which it practically is, we are just quibbling over the last stragglers as far as I can tell.) Ricky Cron Stardust On Mon, Apr 4, 2011 at 4:48 PM, Cron Stardust wrote: >This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/199/ > > Huh.. long winded speech became dust on pressing publish... Here goes again: > > > - Cron > > On April 4th, 2011, 10:34 a.m., Cron Stardust wrote: > Review request for Viewer. > By Cron Stardust. > > *Updated April 4, 2011, 10:34 a.m.* > Description > > I looking at the code, trying to find out where/how to add a new feature, > when I tripped across one of these and it lit my mental warning bells off. > Vector distance comparisons should, IMHO, always be done squared. So I did > some greppin, manual analysis, and some careful modification, and here's the > result. > > Testing > > Compiled a test viewer and used it, undertaking some of my normal activities. > Results felt good, but are currently anecdotal. Any suggestions on how to > properly measure this (or even some actual measurement from those already > instrumented to measure these things,) would be great! > > *Bugs: * VWR-25126 <http://jira.secondlife.com/browse/VWR-25126> > Diffs > >- doc/contributions.txt (344d4c6d7d7e) >- indra/llcharacter/llbvhloader.cpp (344d4c6d7d7e) >- indra/llcommon/indra_constants.h (344d4c6d7d7e) >- indra/llmath/tests/llbbox_test.cpp (344d4c6d7d7e) >- indra/newview/llagent.cpp (344d4c6d7d7e) >- indra/newview/llfloaterchat.cpp (344d4c6d7d7e) >- indra/newview/llhudeffectlookat.cpp (344d4c6d7d7e) >- indra/newview/llhudeffectpointat.cpp (344d4c6d7d7e) >- indra/newview/llmaniprotate.cpp (344d4c6d7d7e) >- indra/newview/llmanipscale.cpp (344d4c6d7d7e) >- indra/newview/llnetmap.cpp (344d4c6d7d7e) >- indra/newview/llpanelpeople.cpp (344d4c6d7d7e) >- indra/newview/llselectmgr.cpp (344d4c6d7d7e) >- indra/newview/llspeakers.cpp (344d4c6d7d7e) >- indra/newview/llviewerchat.cpp (344d4c6d7d7e) >- indra/newview/llviewermessage.cpp (344d4c6d7d7e) >- indra/newview/llviewerparceloverlay.cpp (344d4c6d7d7e) >- indra/newview/llvoicevivox.cpp (344d4c6d7d7e) >- indra/newview/llworld.cpp (344d4c6d7d7e) > > View Diff <http://codereview.secondlife.com/r/199/diff/> > ___ 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 Build Result Pages
Only spent a few minutes browsing the source code (good work in there, I love to see HTML5 in use!) but I'd suggest that you make .body_arch clickable to expand sections as well as .head_arch - that way we don't have to click so small a target to get the results we want. While, of course, keeping the links embedded in them sanely clickable... :P Good job! On Wed, Apr 20, 2011 at 8:09 AM, CG Linden wrote: > I've been working on redoing the build results. > > Check out a sample at: > http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/cg_viewer-development/rev/227100/index.html > > They are completely self-contained. The data is actually stored in a JSON > file at: > http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/cg_viewer-development/rev/227100/index.json > > Note that the "changes since last good build" will include changes made to > third party libs and other dependencies, including autobuild and our build > system. > > Some links are not public (e.g. links to our internal hg repos). > > Note that Jira ids may not match the comments whenever the jira issue was > moved. > > The HTML page is just a skeleton, and javascript will read the JSON file and > render it on the result page. > > Ideas/suggestions/bug reports welcome. > -- > cg > > ___ > 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] EnableTexture: Uniform out of range
Ok, pulled down a fresh copy of viewer-development (15842:3cf9f0e87e19) and built it using autobuild. Worked flawlessly on my Mac (10.6.7), even though this was my first time playing with autobuild, even nicer than develop.py - no xcode gui! However, when I try to log in, just at the point it is going to show me the world, I have a Fatal Error: ERROR: enableTexture: Uniform out of range: 33 So I grepped around, found the message in indra/llrender/llglslshader.cpp, extended it for debugging purposes: ERROR: enableTexture: Uniform out of range: 33. Texture size was 0 Huh?! I'm know I don't know what is going on in this code, but a texture size of 0 tells me something's afoot! I thought I had heard something about this error in the past, but searching my list archives didn't bring anything up... Ideas? 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
Re: [opensource-dev] PO build
Working a merge now for STORM-1075. When my limited compile (Mac-only) test is done I'll commit the merge to my repo. Ricky Cron Stardust On Thu, Apr 28, 2011 at 9:11 PM, Philippe (Merov) Bossut wrote: > Hi, > > Filling in for Oz this week, here's a rather big PO build for your > enjoyment: > > http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/merov_viewer-development-import/rev/228093/index.html > > Fixes scheduled for sprint 15, code reviewed, but in need of test and PO > approval: > * STORM-1093: Dock/undock icon in side panel has dock style after docking > * STORM-1150: [OPEN-61] As an OS Dev using VC Express on Windows, I would > like the msvcp100 and msvcr100 files to be found and copied automatically. > * STORM-973: [crashhunters] crash at > LLViewerTextureList::removeImageFromList(LLViewerFetchedTexture *) > [secondlife-bin llviewertexturelist.cpp] > * STORM-956: Ability to mute dialogs by muting object (or object owner) > * STORM-229: Loading Scripts takes a long time and stalls Viewer (additional > fix by Seth) > * STORM-1191: XUI attributes for path limit constraints inconsistent with > actual constraints > * STORM-1075: Optimization: Squared vector distance comparisons (!! Required > conflict resolution at merge !! Please @Cron, check JIRA) > * STORM-951: Accidental Self-Muting/Self-Blocking > * STORM-380: Little delay in sound when gesture first time played + memory > leaks > * STORM-1128: Sort the results of using search in the World Map > * STORM-1182: [Linux] XUI Preview Tool fails to load XMLs from > indra/newview/skins > > Special : this feature is not fully code reviewed but since it's a big chunk > of code and of interest to lots of folks, I pulled it in as well so it gets > some build and test cycles: > * STORM-1112: Implement socks 5 proxy > > Cheers, > - Merov > > ___ > 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] Reversed mouse scroll direction causes chaotic scrolling/zooming in the viewer
I've just reported https://jira.secondlife.com/browse/VWR-25664 "Reversed direction mousewheel scroll causes major scroll jitter" I've only found this so far on a Mac running MagicPrefs (to reverse the scroll direction) and using a MagicMouse. However, I suspect a deeper problem that would become a major usability issue on OSX Lion (where reversed scrolling seems to be default). I found some notes on how to possibly set up a test in Linux, but I don't think Windows can even think that direction at the moment... (Notes in the JIRA entry.) Just an annoying edge-case bug right now, but if it can be fixed before Lion is released it will prevent some headaches... :) 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
Re: [opensource-dev] Reversed mouse scroll direction causes chaotic scrolling/zooming in the viewer
Very good point, and I agree that there should be confirms from multiple setups. I'm going to verify that it isn't just the MagicMouse by testing on my mom's Macbook Pro, then I'm going to hunt down other ways of reversing the scroll direction. However if it repo's on Linux (via the XOrg trick) I suspect that it would be deeper than just a bad interaction with that setting in MagicPrefs. Ricky Cron Stardust On Mon, May 2, 2011 at 12:22 PM, Oz Linden (Scott Lawrence) wrote: > On 2011-05-02 14:22, Ricky wrote: >> I've just reported https://jira.secondlife.com/browse/VWR-25664 >> "Reversed direction mousewheel scroll causes major scroll jitter" >> >> I've only found this so far on a Mac running MagicPrefs (to reverse >> the scroll direction) and using a MagicMouse. However, I suspect a >> deeper problem that would become a major usability issue on OSX Lion >> (where reversed scrolling seems to be default). I found some notes on >> how to possibly set up a test in Linux, but I don't think Windows can >> even think that direction at the moment... (Notes in the JIRA entry.) >> >> Just an annoying edge-case bug right now, but if it can be fixed >> before Lion is released it will prevent some headaches... :) > > I'd like to see some evidence that the problem isn't specific to your > particular test setup. > > Do we have anyone who can test this either on Lion or some other way? > > ___ > 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] Reversed mouse scroll direction causes chaotic scrolling/zooming in the viewer
Based on comments in the JIRA entry, I've closed this as "Cannot Reproduce" - not that it can't be reproduced as specified, but that it is most likely just the interaction of how MagicPrefs implements the inverted scrolling operation. Case closed, and a big thank you to all who tested to verify. At least if this shows up again there will be some information to associate it with! Ricky Cron Stardust On Mon, May 2, 2011 at 2:02 PM, Ricky wrote: > Very good point, and I agree that there should be confirms from > multiple setups. I'm going to verify that it isn't just the MagicMouse > by testing on my mom's Macbook Pro, then I'm going to hunt down other > ways of reversing the scroll direction. > > However if it repo's on Linux (via the XOrg trick) I suspect that it > would be deeper than just a bad interaction with that setting in > MagicPrefs. > > Ricky > Cron Stardust > > On Mon, May 2, 2011 at 12:22 PM, Oz Linden (Scott Lawrence) > wrote: >> On 2011-05-02 14:22, Ricky wrote: >>> I've just reported https://jira.secondlife.com/browse/VWR-25664 >>> "Reversed direction mousewheel scroll causes major scroll jitter" >>> >>> I've only found this so far on a Mac running MagicPrefs (to reverse >>> the scroll direction) and using a MagicMouse. However, I suspect a >>> deeper problem that would become a major usability issue on OSX Lion >>> (where reversed scrolling seems to be default). I found some notes on >>> how to possibly set up a test in Linux, but I don't think Windows can >>> even think that direction at the moment... (Notes in the JIRA entry.) >>> >>> Just an annoying edge-case bug right now, but if it can be fixed >>> before Lion is released it will prevent some headaches... :) >> >> I'd like to see some evidence that the problem isn't specific to your >> particular test setup. >> >> Do we have anyone who can test this either on Lion or some other way? >> >> ___ >> 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] 3D soound
The only thing is: IIRC, all non-media (sound effects from scripts or collisions/etc and voice, but not parcel media or MOAP) sound sources in SL are played back as mono. You get 3D/stereo sounds because those mono sounds are played in a virtual 3D space, with each sound "located" at the object that is playing it. This is a really cool idea, but it doesn't go well into games or SL I'm afraid - solely due to the fact that sounds are doing much more advanced tricks in such environments that result in stereo being lost and then remade. Thanks for the idea, I may use it in future projects of my own! (Just not games! :D ) Ricky Cron Stardust On Tue, May 24, 2011 at 10:42 AM, Lee ponzu wrote: > I saw this cool demo of 3D sound. This is totally different from the SL > Voice technology, and I think it would compliment it perfectly. > Take a look... > http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=princeton+3D+sound > The basic idea is that stereo gives a weak illusion of 3D. You have the > left signal, ls, and the right signal, rs. A filter computes > rs_new = rs - ls > ls_new = ls - rs > and then play rs_new and ls_new. (Details left as an exercise...) > In English---when you record in stereo, you record cross talk between the > mics which is recreated when you play back. This idea removes the cross > talk, and dramatically increases the 3D illusion. It is a simple filter and > works totally at playback time on all sound sources and any stereo > recording. It would be easy to add it to the viewer... > Just an idea. > ponzu > > > > ___ > 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] Review Request: OPEN-67: make LLDirIterator implementation compatible to boost::filesystem v3 (as found in Boost 1.44 and newer)
I like the very descriptive comment above the #define - Makes the purpose crystal clear, AND places an expiration on the line so it will be easy to know when/if it is time to remove said line! As to the functionality - havent tested it :( Ricky Cron Stardust On Wed, May 25, 2011 at 1:25 PM, Boroondas Gupte wrote: >This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/313/ > Review request for Viewer. > By Boroondas Gupte. > Description > > Context: We are currently using Boost 1.45, which already comes with the new > Boost Filesystem Library API (Version 3) but still defaults to the old one > (Version 2). From Boost 1.46 on, V3 will be the default and Boost 1.47 will > be the last one to come with V2. The Boost Filesystem Library documentation > recommends "Existing code should be moved to Version 3 as soon as convenient. > New code should be written for Version 3. Version 2 is deprecated, and will > not be included in Boost releases 1.48 and later." > > This change overrides the default, so that the V3 API is used, and makes the > necessary code changes. (So we can stick to Boost 1.45 and upgrade whenever > we feel like it.) > > Note: I only changed stuff that the compiler complained about. If the new API > also changes semantic of still-compiling library usage, more changes might be > necessary. > > Testing > > * Compiled Viewer (standalone) with Boost 1.45 > * Started Viewer > * Logged in > > * Compiled Viewer (standalone) with Boost 1.46 > * Started Viewer > * Logged in > > Not tested: > * non-standalone > > *Bugs: * OPEN-67 <http://jira.secondlife.com/browse/OPEN-67> > Diffs > >- doc/contributions.txt (959f9340da92) >- indra/llvfs/lldiriterator.cpp (959f9340da92) > > View Diff <http://codereview.secondlife.com/r/313/diff/> > > ___ > 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] Review viewer -- draw distance slider
Thus far I'm in favor of the eye icon. Lately I've been using the Unreal Developers Kit a lot for classwork, and there is even a 8x8 or so eye icon that is still legible, though most of the eye icons are larger. None have lashes, just the arcs and iris dot. Once the icon is set, people will get used to it fast. The issue here is that there is no "standard" (de facto or otherwise) for an icon that represents draw distance. I can't even find a program that has an icon for the draw distance setting: most either have the setting hidden in a config menu or, as in Blender, in a sidebar with a textual heading. We just don't want to try to redefine an icon that has an existent strong meaning. Camera iris is used for brightness, scaled trees (and magnifying glass) for zoom, magnifying glass and binoculars for search. The eye though has no strong meaning in my mind. UDK uses the eye for "lock selected actor to the camera" - not exactly an intuitive use, but they rolled with it. Ricky Cron Stardust On Sun, Jun 12, 2011 at 12:01 PM, Trilo Byte wrote: > Agreed regarding the magnifying glass icon - it's used both in SL and in some > browsers as an icon representing Search. > > The problem with using a 1 tree/many trees approach is that a) that's already > used to denote zoom, not viewing distance, and b) that type of display works > best when it's on either side of the control in question (either side of the > zoom rocker on a digital camera, for example. > > I like the binoculars icon idea, but agree that it could cause confusion > since other applications commonly use the symbol for search. > > An eye icon has merit, since it controls how much the user sees. Given the > 16x16 pixel constraint, I think the rays/lines coming off the eye would be > less clear, and may cause some possible confusion with the speaker/volume > icon (which is exactly what you want to avoid). Speaker icon for what you > hear, eye for what you see, seems pretty straightforward, and a tooltip when > moused over/used would further eliminate confusion. > > As for the notice to pop up when the setting gets raised too high, how about > using "caution" in place of "warning". - subtle change in language makes the > message read more like helpful guidance. > > On Jun 11, 2011, at 4:08 PM, Jonathan Welch wrote: > >> While testing the updated graphic I've been looking at the cautionary >> wording on the slider and am not happy with it. There is no good way >> to align the text so it looks nice in all languages and the width of >> the slider would have to be wide enough to support the longest word in >> whatever language that happens to be. >> >> I am thinking that a warning notification message could be sent if the >> draw distance is adjusted up past a certain threshold. Much more >> explanatory text could be put into this notice and it would also be >> i10n friendly. >> >> Warning: You have just set your draw distance to a large value. This >> may cause poor system response. >> ___ >> 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] DD philosophy
This could be solvable in a manner that I've seen in some other programs: having the ability to state what your preference is. I've seen games and tool have a radio button set with one entry set to "high fps" and the other to "high detail" - or related terminology. Food for thought. Ricky Cron Stardust On Friday, June 17, 2011, Nalates Urriah wrote: > To consider implementing automatic(DD) Draw Distance changes one probably > should consider all the possible ways this affects players, which is probably > not the easiest thing to do. > When shopping changing a DD probably would not be much of an issue, at least > for me. However, I tend to enter a store and then cam around. I also tend to > turn DD down when in a mall. Using 64m when things are a bit slow and even > down to 32m when they remain slow. > > However when in a combat sim I do not want the DD to change. I set the DD > depending on what is going on. I may turn off shaders to keep a high FPS. > But, changing DD when I'm in combat would really piss me off. One is already > clicking and key banging as fast as one can. Having to fight with DD to keep > it as an acceptable distance would be extremely annoying. I would change away > from any viewer that has automatic DD that degrades my combat experience. > > When I am using Kirsten's Viewer for Photography I often use maximum DD and > graphics setting and tolerate low FPS, even 2 or 3 FPS is acceptable, for the > sake of capturing a great image. An automatic DD change would also be > extremely annoying in such a scenario. Any change to my rendering settings > would be annoying. > > I'm not sure that FPS is the criteria that is most important to residents. I > like higher FPS. I think once FPS is 15 or more performance is less important > to residents and render quality becomes more important. That is rather > subjective. Before making a change like adding automatic tuning for > performance one needs to determine what people find acceptable. The blow back > from the changes made to the initial SLV2 is an example of > how irritate people. > > Changing the viewer settings at install times is reasonable. I don't hear > people complaining. We can over ride those settings. Once we do, performance > is on us. Changing my choices after that just irritates me and motivates > people to use TPV's. > > -- > Nalates Urriah > > ___ 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] Virtual Destructors
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
Re: [opensource-dev] Virtual Destructors
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
Re: [opensource-dev] Virtual Destructors
Thanks Josh! That's good to know, and thanks for the link. While I've gotten used to a fair number of languages, C++ has a LOT of territory filled with dark corners and pits. So I try to proceed cautiously. :D Ricky Cron Stardust On Fri, Jul 1, 2011 at 4:08 PM, Joshua Bell wrote: > 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
[opensource-dev] Mesh and Scripting
Just pinging to see if anyone knows the current status of such? Grepping around in JIRA I found these entries: https://jira.secondlife.com/browse/CTS-298 - Feature: Support mesh change through script commands https://jira.secondlife.com/browse/CTS-654 - Allow scripts to set a mesh by UUID However, both are closed as "Won't Finish" and I'm suspecting that the status really means "This isn't the mesh team's job." If so, then the JIRA entries should be moved to the correct team, not just shut off. I've noticed that llGet[Link]PrimitiveParams returns as a sculpt (prim type 7) on Server 11.08.22.239223, with a UUID, presumably of the mesh, and a sculpt type of 5. From some reading of rather dated office hours, (https://wiki.secondlife.com/wiki/User:Nyx_Linden/Office_Hours_Transcript_2010-09-29) I've determined that scripting support is waiting on arbitrary skeletons and scripted animation controls - which is to say a long way in the future. Or have I missed something? (Quite likely, as I get most of my SL news from this list...) I've a few suggestions for script+mesh myself, where should they go? SVC? Thanks, 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
Re: [opensource-dev] Mesh and Scripting
I'm afraid that I allowed myself to create a writeup that made it easy to conflate several independent things: 1) Scripting and meshes in general. 2) Mesh UUID flipping - VERY bad for animations, as you noted and thanks for the link, but has valid uses. 3) Where to put scripting requests - which I just found myself while looking for something else: SCR "Scripting" Thanks for the link to the wiki page. Ricky Cron Stardust On Mon, Sep 5, 2011 at 8:22 PM, Kuraiko Yoshikawa wrote: > As I understanded it there won't be support for UUID flipping and meshes > are not addressable by UUIDs > https://wiki.secondlife.com/wiki/Why_UUID_Flipping_is_Bad > > Am 06.09.2011 05:05, schrieb Ricky: >> Just pinging to see if anyone knows the current status of such? >> >> Grepping around in JIRA I found these entries: >> https://jira.secondlife.com/browse/CTS-298 - Feature: Support mesh >> change through script commands >> https://jira.secondlife.com/browse/CTS-654 - Allow scripts to set a >> mesh by UUID >> However, both are closed as "Won't Finish" and I'm suspecting that the >> status really means "This isn't the mesh team's job." If so, then the >> JIRA entries should be moved to the correct team, not just shut off. >> >> I've noticed that llGet[Link]PrimitiveParams returns as a sculpt (prim >> type 7) on Server 11.08.22.239223, with a UUID, presumably of the >> mesh, and a sculpt type of 5. From some reading of rather dated >> office hours, >> (https://wiki.secondlife.com/wiki/User:Nyx_Linden/Office_Hours_Transcript_2010-09-29) >> I've determined that scripting support is waiting on arbitrary >> skeletons and scripted animation controls - which is to say a long way >> in the future. Or have I missed something? (Quite likely, as I get >> most of my SL news from this list...) >> >> I've a few suggestions for script+mesh myself, where should they go? SVC? >> >> Thanks, >> 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 > ___ 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] Web Inspector
I've been aiming to debug a page I wrote for MOAP, and I was hoping to use the Web Inspector introduced in http://hg.secondlife.com/viewer-development/changeset/042aa5b6afd9 where I learnt that I needed to set the MediaPluginDebugging debug setting to TRUE. So I did. But on my Mac Mini, it only pops up a separate window (not a in-the-viewer dialog, but a separate OS-level dialog window) that has no content, only flat white. Are any other platforms able to use it? JIRA might be forthcoming, but I'm going to sleep on it first. Tested with 3.0.5.240927. My ultimate goal is to find out why the Javascript I wrote, that works fine under Chrome, Safari, and Firefox, doesn't run correctly in MOAP... :P Thanks for your info, Ricky Cron Stardust PS. If you don't know how, here's how to both enable and test the Web Inspector: 1: Enable the MediaPluginDebugging debug setting (Advanced > Show Debug Settings) 2: Open the Web Content Browser (Develop > UI > Web Content Browser) 3: Right-click on the page to open the context menu and select Open Web Inspector. I expected to see http://www.webkit.org/blog/41/introducing-the-web-inspector/ ___ 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] Web Inspector
Responding to myself... JIRA filed as https://jira.secondlife.com/browse/VWR-27074 "Web Inspector not operable on Mac or Linux" Ricky Cron Stardust On Thu, Sep 22, 2011 at 11:32 PM, Ricky wrote: > I've been aiming to debug a page I wrote for MOAP, and I was hoping to > use the Web Inspector introduced in > http://hg.secondlife.com/viewer-development/changeset/042aa5b6afd9 > where I learnt that I needed to set the MediaPluginDebugging debug > setting to TRUE. So I did. But on my Mac Mini, it only pops up a > separate window (not a in-the-viewer dialog, but a separate OS-level > dialog window) that has no content, only flat white. > > Are any other platforms able to use it? JIRA might be forthcoming, > but I'm going to sleep on it first. Tested with 3.0.5.240927. > > My ultimate goal is to find out why the Javascript I wrote, that works > fine under Chrome, Safari, and Firefox, doesn't run correctly in > MOAP... :P > > Thanks for your info, > Ricky > Cron Stardust > > PS. If you don't know how, here's how to both enable and test the Web > Inspector: > 1: Enable the MediaPluginDebugging debug setting (Advanced > Show > Debug Settings) > 2: Open the Web Content Browser (Develop > UI > Web Content Browser) > 3: Right-click on the page to open the context menu and select Open > Web Inspector. > > I expected to see http://www.webkit.org/blog/41/introducing-the-web-inspector/ > ___ 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] Missing details in Snowstorm development builds
Yes, the last one to note any "Changes since last good build" or "Jiras" was revision 242386 completed on Wed Oct 05 2011 16:43:20 GMT-0700 (PDT). Beyond that, void. No knowing what the changes were unless you subscribe to another list somewheres... Why is it broken? Dunno, my intuition says that it looks like some API broke. Ricky Cron Stardust On Mon, Oct 17, 2011 at 7:55 AM, Hitomi Tiponi wrote: > > I have noticed that the fields 'Changes since last good build' and 'Jiras' > on the Snowtorm Viewer development build are repeatedly showing as 'None' > for more than a weeknow - despite the fact that there are clearly changes > and responses to JIRAs being implemented. > > It is quite useful to see what a build addresses so I wondered if this was > deliberate or a bug you can fix? > > 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] FUI project just out - no more sidebar
Erm... build 243327 says that it's still in progress... Are you sure that's the version you tested against? http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/snowstorm_viewer-development/rev/243327/index.html Ricky Cron Stardust On Wed, Oct 19, 2011 at 9:48 AM, Trilo Byte wrote: > I definitely like the direction it's heading, but a few things jump out... > > 1) How do I change/edit my picks? > 2) User-definable shortcut keys would be the perfect compliment to this > (currently no shortcut for appearance, opening additional inventory windows, > etc) > 3) How about that awesome draw distance slider we tested last June as an > optional UI component? > 4) Can the position of the group/IM chiclets and notification popups be > changed (via user preferences)? > 5) Is there a preferences setting for disabling the Favorites portion of the > "LM & Favorites" toolbar? > > I also notice a 2 second delay when opening an inventory window. Opening > other windows or closing the inventory window happens instantaneously, but > opening a window has a pronounced delay. You can no longer use cmd-shift-I > (on the Mac client) to open additional inventory windows, but opening > additional windows through the gear menu also results in a delayed opening. > > Rendering performance also seems to take a hit with build 243327. Since > changelogs/JIRA lists aren't included on the build/download pages, I don't > know if this is because of some other change to the viewer, or if it's the > direct result of the user interface project. > > TriloByte Zanzibar > ___ > 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] Weird issue with mouselook flight in newer viewers
Those angle limits have been in place for many, many years. Though I agree that having them has little purpose, they have, nevertheless been there the whole time. Ricky Cron Stardust On Wed, Oct 19, 2011 at 7:11 PM, Dave Booth wrote: > Where did the limits on mouselook angle come from in the newer builds? > In current development a mouselook-steered aircraft cant pitch up beyond > 80 degrees and cant pitch down beyond 40. It's got to be in the viewer > code somewhere because using TPVs like the current Firestorm beta I can > pitch freely between +90 and -90 in the same vehicle. This is breaking a > LOT of existing content, every aircraft that uses ML steering. Any > ideas, folks? It's hard to notice without fully functional flight > instruments but its a real problem - when a flight envelope can change > just based on the version of viewer code aircraft combat is blown into a > cocked hat... > ___ > 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] Mac & Linux testers needed
Can an official build be used to test this, or does the test actually require a custom build? Ricky Cron Stardust On Sat, Nov 12, 2011 at 11:55 AM, Jonathan Welch wrote: > I need someone who has built the viewer from tip on the 11th or later > on both mac and linux to perform a quick test: can you resize your > viewer window below 1024x768? > > If so would you please comment on VWR-27482 (Unable to resize viewer > window below 1024x768)? > https://jira.secondlife.com/browse/VWR-27482 > > It is not clear that all operating systems have the same new window size > limits. > > Thank you, > > -Jonathan > ___ > 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] I could use a little help with boost and callbacks and stuff
Is something like: std::bind1st(std::mem_fun(&MyClass::MyMethod), myParameter) what you are looking for? You can see working code using that on lines 350-390 of https://bitbucket.org/kf6kjg/gsp-420-engine-design-graphics/src/120a2081bb2f/src/audio_core/AudioCore.cpp (This was code I wrote while helping out another team in one of my classes.) Boost's Bind function (http://www.boost.org/doc/libs/1_47_0/libs/bind/bind.html) generalizes the standard call I used, and so might be easier to use. Here's the same using Boost: bind(&MyClass::MyMethod, myParameter) I hope this helps, Ricky Cron Stardust On Sat, Nov 12, 2011 at 1:54 PM, Lance Corrimal wrote: > Hi there, > > > I'm banging my head against a problem here... > I want to add buttons to the toolboxes. > > The actuall adding is easy, but I have trouble figuring out what I > need to do to register some callbacks into the classes I need. > > I have two classes that I need to "buttonize"... one represents the > graphical UI for a set of new features, and that one I managed to set > up as a toolbox button just fine. > > The other one is troublesome though. I need to establish a method that > gets called (with no parameter, or a dummy), to toggle an internal > switch in my class, and I need another callback, that returns the > boolean value of that internal switch, to turn the button green or > not. Think of a simple "on/off switch". > > What I can't figure out is what I actually have to do with my class to > implement the callbacks properly, and what I have to pass to the > function that registers the callback. > > Any hints/tips for me? > > thanks, > > LC > ___ > 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] I could use a little help with boost and callbacks and stuff
IIRC that _number thing has to do with iteration. The example code I gave in the email here passes one parameter (myParameter). I'm not as strong with Boost or the Standard Lib methods as I was a couple of months ago, but I don't recall there being a no-parameter version. The count of parameters is entirely dependent upon the function/method being passed. I discovered this technique online after searching the 'net looking for how to work with functions and methods as first-class types in C++: I wanted to pass the method of a class instance off to another function (in my case, a template) so that is could call it in a centralized manner. I was able to do so this way, though it feels a bit hackish - like a lot of C++ I'm afraid. (Yes, C++ isn't my fav language, but D isn't what we are working in.) Sorry I can't help much farther: my experience is limited, and my SL viewer hacking experience is even more limited! Ricky Cron Stardus On Sat, Nov 12, 2011 at 11:51 PM, Lance Corrimal wrote: > I guess I wasn't exactly clear... > > > What I need to know is how I have to modify my classes to make them > work with boost::bind and the CallbackRegistry. > > When I try to just duplicate the way that other classes in the viewer > use to register methods in the CallbackRegistry, I get tons of boost > errors when building, all culminating from some missing function or > such that is called get_pointer... > > So I think I need to inherit some special class or something, but I > can't find which one! > > And what do I pass to the bind() call, there are several different > ways to call it, with one, two, or three parameters, and what's the > _(number) that usually gets passed last? > > > As you can see, I don't really know what I'm doing there. > > bye, > LC > > > Am Sonntag, 13. November 2011 schrieb Ricky: >> Is something like: >> std::bind1st(std::mem_fun(&MyClass::MyMethod), myParameter) >> what you are looking for? >> >> You can see working code using that on lines 350-390 of >> https://bitbucket.org/kf6kjg/gsp-420-engine-design-graphics/src/120 >> a2081bb2f/src/audio_core/AudioCore.cpp (This was code I wrote while >> helping out another team in one of my classes.) >> >> Boost's Bind function >> (http://www.boost.org/doc/libs/1_47_0/libs/bind/bind.html) >> generalizes the standard call I used, and so might be easier to >> use. Here's the same using Boost: >> bind(&MyClass::MyMethod, myParameter) >> >> I hope this helps, >> Ricky >> Cron Stardust >> >> On Sat, Nov 12, 2011 at 1:54 PM, Lance Corrimal >> >> wrote: >> > Hi there, >> > >> > >> > I'm banging my head against a problem here... >> > I want to add buttons to the toolboxes. >> > >> > The actuall adding is easy, but I have trouble figuring out what >> > I need to do to register some callbacks into the classes I need. >> > >> > I have two classes that I need to "buttonize"... one represents >> > the graphical UI for a set of new features, and that one I >> > managed to set up as a toolbox button just fine. >> > >> > The other one is troublesome though. I need to establish a method >> > that gets called (with no parameter, or a dummy), to toggle an >> > internal switch in my class, and I need another callback, that >> > returns the boolean value of that internal switch, to turn the >> > button green or not. Think of a simple "on/off switch". >> > >> > What I can't figure out is what I actually have to do with my >> > class to implement the callbacks properly, and what I have to >> > pass to the function that registers the callback. >> > >> > Any hints/tips for me? >> > >> > thanks, >> > >> > LC >> > ___ >> > 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
[opensource-dev] VD Build Page Hacking
I finally got so annoyed with the build page that I decided to do some hacking on it. Turns out that the reason why it isn't displaying changesets or JIRA entries is because the JSON format was changed without correcting the Javascript. What's more, the JSON information doesn't have the needed data anymore. So. I dug and I hacked, and I hacked and I dug, and voila, I'd mashed up a facsimile of what I think it did in the past. And yes, I used the phrase "mashed up" on purpose: the page I built taps into BitBucket's REST API to get the missing data. It's not all that pretty to go that route, but it works. Here's a demonstration: http://rwcproductions.com/~ricky/snowstorm/ And here's the patch: http://rwcproductions.com/~ricky/snowstorm/index.js.patch.txt Yes, there are some whitespace changes, and render_description() could be cleaned up further, but I tried to not affect more than the areas needed to make it "workable." Suggestions, thoughts, etc. welcome. 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
Re: [opensource-dev] Is the build machine stuck?
Yep. Haven't heard any response about it though. Ricky Cron Stardust On Sat, Nov 19, 2011 at 10:55 PM, Dave Booth wrote: > On 11/20/2011 12:41 AM, Hitomi Tiponi wrote: >> It does appear to be stuck still - it's not the first time this has >> happened. Also the problem with not showing changes in the builds has >> still not been solved when it does complete. >> > > Ricky found the issue with the latter of those.. posted it here > >> Turns out that the reason why it isn't displaying >> changesets or JIRA entries is because the JSON format was changed >> without correcting the Javascript. What's more, the JSON information >> doesn't have the needed data anymore. > > He even mocked up a fix... > ___ > 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] Changes Since Last Build problem
Yes, I noticed that some changeset id's weren't found in the V-D repository, so I had the script just display what it could for those. For reference here's the demo link: http://rwcproductions.com/~ricky/snowstorm/ It'd be better to find out why the data changed, and if was possible to get it all back, but if not then adding the repository url... Hmmm... Looks like a lot of those have the changeset URL. I could parse that for what is needed to go get the rest of the data... But that's more hacks on top of hacks just to overcome a lack of data from the original source. So some questions that'd be nice to have answered: Where else is that JSON being used? Why was it changed? Could the wanted data be added to it and not freak out whatever else is using it? If the JSON has the data needed I could scrape up some time to build a non-hacky fix. Ricky Cron Stardust On Mon, Nov 21, 2011 at 4:53 PM, Christian Goetze wrote: > The most likely reason why the build shows as "in progress" is > because there is a disparity between the state of the build scripts > or other local dependencies on the mac vs windows vs linux build > machines. If the dependencies differ, then a different build number > will be generated, and since that is what the build system is > tracking, it will wait forever for all three platforms to complete a > build with the same build number. > > Someone needs to ensure that all build machines have the same version > of all the build support repos sync'ed. This needs to be fixed if only > to ensure that all viewer builds have the same version number. > > As for the "changes since last build", the data indeed went missing - > I believe you might be able to get the changeset ids to display at > least, but it won't be very helpful because it will be missing the > info about which hg repo actually holds those ids. > -- > cg > > On Sun, Nov 20, 2011 at 9:10 PM, Ricky wrote: >> Yep. Haven't heard any response about it though. >> >> Ricky >> Cron Stardust >> >> On Sat, Nov 19, 2011 at 10:55 PM, Dave Booth wrote: >>> On 11/20/2011 12:41 AM, Hitomi Tiponi wrote: >>>> It does appear to be stuck still - it's not the first time this has >>>> happened. Also the problem with not showing changes in the builds has >>>> still not been solved when it does complete. >>>> >>> >>> Ricky found the issue with the latter of those.. posted it here >>> >>>> Turns out that the reason why it isn't displaying >>>> changesets or JIRA entries is because the JSON format was changed >>>> without correcting the Javascript. What's more, the JSON information >>>> doesn't have the needed data anymore. >>> >>> He even mocked up a fix... >>> ___ >>> 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] VD Build Page Hacking
LOL, didn't see this response before I posted the other. Like I said there, if the needed/wanted data could be added to the new data structure I'd be willing to scrape up some time to fix the page to use it. Having the data listed in http://confluence.atlassian.com/display/BITBUCKET/Changesets for each changeset would be a good list to go for. These could be appended to the objects in the changesets array in the JSON, and would provide everything needed - that I know of. Ricky Cron Stardust On Mon, Nov 21, 2011 at 4:55 PM, Christian Goetze wrote: > Nice, but it will fail for changesets referring to 3p repos and build > script changes, but I suppose that's still better than nothing. It > would be nice if the query to retrieve the expected info could be > restored server side, but... > -- > cg > > On Sun, Nov 13, 2011 at 12:46 AM, Ricky wrote: >> I finally got so annoyed with the build page that I decided to do some >> hacking on it. Turns out that the reason why it isn't displaying >> changesets or JIRA entries is because the JSON format was changed >> without correcting the Javascript. What's more, the JSON information >> doesn't have the needed data anymore. >> >> So. I dug and I hacked, and I hacked and I dug, and voila, I'd mashed >> up a facsimile of what I think it did in the past. And yes, I used >> the phrase "mashed up" on purpose: the page I built taps into >> BitBucket's REST API to get the missing data. It's not all that >> pretty to go that route, but it works. >> >> Here's a demonstration: http://rwcproductions.com/~ricky/snowstorm/ >> And here's the patch: >> http://rwcproductions.com/~ricky/snowstorm/index.js.patch.txt >> >> Yes, there are some whitespace changes, and render_description() could >> be cleaned up further, but I tried to not affect more than the areas >> needed to make it "workable." >> >> Suggestions, thoughts, etc. welcome. >> >> 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] Review Request: Allow scripts to be saved/loaded to/from files.
Interesting. On my Mac the tabs display in the Viewer's editor as single spaces. My Win7 box shows the squares. Didn't test Linux. Definitely looks like a font issue, though I think that the best solution is to just make the Viewer's editor accept tabs - maybe even have the option to specify how much indentation a "tab" gives or to even switch between using tabs or using spaces. This wouldn't be far from existing programmer-level editors. Ricky Cron Stardust On Wed, Nov 23, 2011 at 10:58 AM, Moriz Gupte wrote: > found another glitch: > I'm developing scripts in eclipse with lslforge. When I "compile" a script in > eclipse and then load it using this patch, tabstops are converted into > IDunnoWhat (it shows as little squares in the script editor). > > > This behavior is familiar to me as well. I use LSL Editor, the script > displays fine when read in the LSL Editor but within SL, I find that the > script file shows little squares. I imagine it must be an issue related to > incompatible fonts used, may be? > > > On Wed, Nov 23, 2011 at 11:36 AM, Kadah Coba wrote: > >>This is an automatically generated e-mail. To reply, visit: >> http://codereview.secondlife.com/r/516/ >> >> On November 20th, 2011, 6:53 a.m., *Lance Corrimal* wrote: >> >> found another glitch: >> I'm developing scripts in eclipse with lslforge. When I "compile" a script >> in eclipse and then load it using this patch, tabstops are converted into >> IDunnoWhat (it shows as little squares in the script editor). >> >> On November 20th, 2011, 10:29 a.m., *Ima Mechanique* wrote: >> >> I'm not familiar with lslforge, but I'll look into it. Are you sure they're >> valid tabs? I ask because it handles tabs from LSL Editor without a problem. >> >> On November 20th, 2011, 11:50 a.m., *Ima Mechanique* wrote: >> >> Looks like this is a bug I've introduced recently, as it is also affecting >> my LSL Editor created files now. :-( >> Trying to track it down, as soon as I can work out how to go back to a >> specific revision in Hg. >> >> On November 20th, 2011, 1:48 p.m., *Ima Mechanique* wrote: >> >> Damn. SL's text editing windows do not like tabs. When copy/pasting the >> tabs are converted to spaces, but not when inserting text. I'll look at >> finding a way around this. >> >> I don't remember any in-viewer text input ever liking \t particulary. It >> might be best, or at least easier or safer, to just convert them to spaces >> on import. >> >> >> - Kadah >> >> On November 22nd, 2011, 5:17 p.m., Ima Mechanique wrote: >> Review request for Viewer. >> By Ima Mechanique. >> >> *Updated Nov. 22, 2011, 5:17 p.m.* >> Description >> >> Changes to allow opened script window to save/load to/from files on the >> users computer. >> >> Testing >> >> Successfully opened and saved scripts from/to local files. >> >> *Bugs: * >> https://jira.secondlife.com/browse/storm-1708<http://jira.secondlife.com/browse/https://jira.secondlife.com/browse/storm-1708> >> Diffs >> >>- doc/contributions.txt (a1319d553db9) >>- indra/llui/lltexteditor.h (a1319d553db9) >>- indra/llui/lltexteditor.cpp (a1319d553db9) >>- indra/newview/llfilepicker.h (a1319d553db9) >>- indra/newview/llfilepicker.cpp (a1319d553db9) >>- indra/newview/llfloaternamedesc.h (a1319d553db9) >>- indra/newview/llfloaternamedesc.cpp (a1319d553db9) >>- indra/newview/llpreviewscript.h (a1319d553db9) >>- indra/newview/llpreviewscript.cpp (a1319d553db9) >>- indra/newview/llviewerfloaterreg.cpp (a1319d553db9) >>- indra/newview/skins/default/xui/en/panel_script_ed.xml >>(a1319d553db9) >> >> View Diff <http://codereview.secondlife.com/r/516/diff/> >> >> ___ >> 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 >> > > > > -- > 'Consider how the lilies grow. They do not labor or spin.' > *Rameshsharma Ramloll* PhD, *Research Associate Professor*, Idaho State > University, Pocatello, ID 83209 Tel: 208-282-5333 > Blog <http://deepsemaphore.posterous.com/>, > LinkedIn<http://www.linkedin.com/in/rameshramloll> > , Play2Train <http://www.play2train.org> > > > ___ > 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] Linden Lab's Google Calendars issue
It seems that as of some point in the last few months the publicly exported Google Calendars from Linden Labs has been set to "Anyone can: See only free/busy (hide details)" - meaning no-one out here can actually know what's going on in the little blue boxes. Here's one that's exported on the wiki: https://wiki.secondlife.com/wiki/Linden_Lab_Official:User_Groups#Calendar 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
Re: [opensource-dev] space navigator 3d on linux with viewer 3?
I just bought one (the SE edition) for my dad for use in SL. Of course I tested it immediately upon arrival! :P It worked just fine on my Mac, will be testing on Ubuntu and Windows XP shortly - after my dad gets it. I used something recent from the build server: probably a 3.2.6.somethingorother. Ricky Cron Stardust On Sun, Dec 25, 2011 at 12:48 AM, Lance Corrimal wrote: > Hi all, > > I see a *lot* of jiras about space navigator 3d support not working in > recent viewers... > ... is there anyone working on that? > Do i have to do more than plug it in to make it work with the latest > viewers? > > > bye > LC > > ___ > 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] Questions on Mesh Avatars
It depends on the mesh. The example given of around 6k tris is what I'd consider to be the max for a whole avatar mesh - including a few basic attachments. A shirt mesh would be a whole lot less. I'd recommend taking some courses, or at least hunting around on the 'net for info, on how to create low-poly characters for games. While SL doesn't (yet) have support for normal maps, you can get away with a lot in the diffuse texture that it does have. The reason to keep your tricount as low as possible is this: the more tris in a scene the worse the lag - both network lag when loading and client lag while on-screen. I can't give a number for "low as possible" because it entirely depends on what is being built and the skill of the creator. If you want to see how badly the client is currently being tortured by the prim attachments a lot of people wear, switch to wireframe mode in the viewer: you'll see every tri displayed, and I've seen many avatars almost solid with the black lines of the triangle edges they were so dense. Such avatars cause a fair amount of client lag every time they are visible - the exact amount of lag depends on the computer and the graphics card of the observer. Hope that helps, Ricky Cron Stardust On Thu, Jan 26, 2012 at 9:40 AM, Robert Martin wrote: > On Thu, Jan 26, 2012 at 10:44 AM, Stickman wrote: > > Robert, > > > > You know, I don't even know what mailing list this should go to. I > > don't think there is a "general creators mailing list" for SL. Just > > scripting. > > > the lack of a decent list for this is why i punted to the developers > general list (since this has the best chances of being seen by > somebody that can use their head for more than a hatrack) > > > > Yeah, that's how wikis tend to go, unless they have a champion. > > Technical wikis tend to work better because you get a lot of people > > who can't stand incomplete or incorrect information. > > > .. Yah folks don't like doing docs so folks have to do things like ask > in a mailing list > > > I'd recommend keeping it below 6000 tris. If you need more, you'd > > better be making something awesome and for specific rather than > > general use. > Cool beans somebody that can give a number (i take it that this would > be on a per mesh thing??) > > > -- > Robert L Martin > ___ > 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] Review Request: STORM-1793 1) Treat all mini-map altitudes above 1020 m as the same height 2) Improve z-level accuracy
A couple of questions Oz: 1. Would the client have a problem if another word was added to the message giving - duplicating the data, but allowing newer clients to choose to use the new word while older clients use the old byte? 2. Would the client have any problems if the CoarseLocationUpdate message was never sent? If not then that message could be deprecated, with a removal date set for some time in the future, while a new message that could handle much higher detail information was put in place and all newer clients were switched to it? I ask because this limitation of the message really puts a pinch in https://jira.secondlife.com/browse/VWR-27577. Ricky Cron Stardust On Fri, Jan 27, 2012 at 12:24 PM, Oz Linden (Scott Lawrence) < o...@lindenlab.com> wrote: > On 2012-01-27 13:45 , Zi Ree wrote: > > Am Freitag, 27. Januar 2012, 14:40:01 schrieb Jonathan Yap: > > > >> The SL simulator has recently been fixed so that the > CoarseLocationUpdate > >> message properly returns 255 for all altitudes above 1020 meters. > > "Properly" is a very ... unusual term for this kind of behavior. It still > > returns a wrong value, just a slightly more wrong one than before. > > 'wrong' is not really a relative term... > > The new value (255) is at least in the same direction for anyone under > the maximum coarse location altitude, which removes some silly edge > cases in which the reported altitude is rises until is suddenly becomes > zero. > > In any event... this is the change that we've decided to make, and > Jonathan appears to have done a good job of making the best of an > admittedly awkward situation. Short of a major change to the coarse > location messages (which would be completely incompatible with older > viewers), I think this is the best that can be done. > > > ___ > 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] Review Request: STORM-1793 1) Treat all mini-map altitudes above 1020 m as the same height 2) Improve z-level accuracy
It just means that having a proper clientside radar system is now truly stuck. And I did mean a finite time period for the deprecation: I agree that such things are unmaintainable in the long term. However the current state of affairs isn't viable for long either, so a plan has to be readied. Kadah's note also shows that it is something that is not able to change per-viewer, so the only viable route is the deprecation model: for a period of time, say one year, the old message AND the new message are sent to all clients. The older clients should discard any message they don't recognize, in this case the new message, while the newer clients will discard the older message for the same reason. After the deprecation period is over the old message code is purged leaving only the new message and anyone who is running an un-updated client simply no long can tell altitude differences in the minimap. As to the format, one byte is not great, but now I at least understand why it was chosen: maximum data density. Currently the message uses absolute coordinates interpreted linearly across the space in the range [0, 255] * 4 meters. This worked when the region was only 1024m high. Here is another idea, trying to keep in what I think was the original spirit of the message: switch to using dynamic scale. Use the existing packet format, therefore keeping the bulk of the code the same, but have the client and the server agree that the scale value, currently set at 4 meters per message unit, is to be computed from the size of the region. This would mean that old-school 1024-meter-high regions would have the calculation for the scalar as so: 1024 / 255 = 4, resulting in the current value that worked so well for those regions. (Yes, I know such regions no longer exist.) Current regions would have the scalar calculated as 4096 / 255 = 16. Future regions with even higher ceilings would just continue that idea, resulting in the message's number being more like a percentage. Just make sure that this math is done for X and Y as well - not just Z. Otherwise we are right back here again if in the future estates can choose to have a different region size than other estates... (And yes it could be done. A LOT of work, but it could be done.) Ricky Cron Stardust PS: I really want to be able to get rid of my lag-creating Sensor-based HUD for a pure client-side system. Hence my active commentary. On Fri, Jan 27, 2012 at 3:37 PM, Jonathan Welch wrote: > > Would the client have a problem if another word was added to the message > > giving - duplicating the data, but allowing newer clients to choose to > use > > the new word while older clients use the old byte? > > Yes, because the coarseupdate packet holds many positions, it is not > just 1 packet per avatar, but as many as can be packed into the > coarseupdate packet as will fit. So it is not possible to alter this > packets' format in any way. Doing so would break all existing viewers > that expect it to have its current format. > > > > > Would the client have any problems if the CoarseLocationUpdate message > was > > never sent? > > Yes, with a small exception, you would not know where anyone is anymore. > > > date set for some time in the future, while a new message that could > handle > > much higher detail information was put in place and all newer clients > were > > switched to it? > > This has been discussed several times at the server group meetings. > Fixing this just to have a fully correct map display is more trouble > than it is worth; having to run two packet formatters in parallel > forever, having to query the viewer what packet format it wants, etc. > is just not worth such a big effort. > ___ 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] View on Lion
Yeah, on the Intel card there seems to be a texture corruption caused by one of the atmo shaders. Really psychedelic if you tune the settings certain ways! Ricky Cron Stardust On Tue, Jan 31, 2012 at 11:22 AM, Kadah wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I've ran it on my 2011 mini mac and it runs ok, but with really bad > color distortions, which are possibly due to it only have the cheap > Intel gfx chip. > > Building the viewer (at least with Firestorm) on Lion seems to also > work without any special setups other than xcode 4.whatever and cmake. > > On 1/31/2012 10:29 AM, Lee ponzu wrote: > > Would someone be willing to give a short summary of the status of > > using the viewer on Lion. > > > > For that matter, what is the status of Lion, period. OS Xista? Or > > is it ok? > > > > lee > > > > > > ___ 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 > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJPKD9/AAoJEIdLfPRu7qE2hZEIAKBoiKrJig2xWclN26IdSn0E > Mc2Xoqev8zeORCdur+vCkanPax+E+ewh07qNS33umQl2K04C23JR2jLc4gDHKHX8 > WryjhyOiTeqcyNNcN5LudWDESgTV79NU9cHOd+yPcHbS8qdLPIsnbFdtUiHeDfud > FbW9EErKnryVZd0JKxcPZne+/S6yeidUgUlskWcZjgOTIM5vLD7kfuUOxtwMHkKP > uUS8CkSUqdfTIMEPVWrvPQT/IDyX23v8XA3wkCUzY/fWH+i13eQQFD/Zp7MgTG+U > xnAtblvgcL0D+M4so4jUUXgb5RgpGUTIe6ddVJSErZHhEVDW2mqE8/W7e/vtsIk= > =cJ44 > -END PGP SIGNATURE- > ___ > 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] Pathfinding alpha announced
>From what I can see, if mesh objects get the ability to play animations (and therefore have some form of skeleton) then NPCs-that-look-like-avatars are a distinct possibility, and would be able to move around with these new functions in a pretty "natural" (in an SL context!) manner. Of course they won't have proper name tags - though you could simulate such with a particle, just not exactly. Ricky Crons Stardust On Sat, Feb 18, 2012 at 3:32 PM, Tateru Nino wrote: > There are always future developments. :) > > I thought it was clear that we were talking about objects. The 'C' in > NPC doesn't imply that you're talking about an agent or an object in SL > terms, anyway - in many UGC-based virtual environments, NPCs are > *usually* objects rather than agents, though. > > I imagined it was kind of clear that the project was about objects, and > not agents. > > On 19/02/2012 12:24 AM, Garmin Kawaguichi wrote: > > In the blog post we find the acronym NPC > > http://en.wikipedia.org/wiki/Non-player_character > > > > I'd prefer here NPO, non playable object 8); in the video I expected to > see > > clones of Lorca Linden !! > > > > Is there going to be future developments? > > > > GCI > > > > - Original Message - > > From: "Jonathan Welch" > > Sent: Friday, February 17, 2012 6:23 PM > > Subject: [opensource-dev] Pathfinding alpha announced > > In case you did not see the announcement yesterday here it is: > > > http://community.secondlife.com/t5/Featured-News/Take-a-Sneak-Peek-at-the-Pathfinding-Experiments-Being-Conducted/ba-p/1386511 > > ___ > > 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] allowing client side AO's to swtich with outfits
As much as I'm not a fan of hacks, until there's proper server-side support this is what I suggest: Dahlia, I think I've taken a liking to your suggestion of the notecard idea, but with a twist. First, the client would create a new inventory folder named such that the likelihood of it being already in existence is extremely low. "Outfit Animations - Firestorm x.x" could be good for Firestorm, where the x's are a version code. This folder would be hidden from viewing in the client default so that it does not clutter up inventory, with an option in the client to make it visible. Inside this folder are notecards, each named after the outfit it's designed to match. These notecards contain LLSD serialized data designed to make it simple and fast for the client to pull down the animation data, update it, and store it back in the notecard. A simple GUI would be designed to make management and creation simple. Yes, this hack has the limitation that a given animation set cannot be in place for multiple outfits, but if there is a simple, easy way to clone an animation set to another outfit such would be mitigated. The ability to manually select another outfit's animation set is also an option. Ricky Cron Stardust On Mon, Apr 16, 2012 at 12:31 AM, Dahlia Trimble wrote: > The AO could be coded such that it looks at the name of the currently worn > outfit and selects the appropriate animation list for that name. I believe > the name of the currently worn outfit is sent to the viewer as it's used to > highlight it in the appearance selector menu. > > I suggested the notecard approach as an alternative that could also allow > notecards in outfits for other uses besides AO animation lists. However > given that it would likely require a server side change, it's probably much > less likely to happen than just re-coding the client-side AO. Personally I > would prefer anything that is associated with my avatar to not be client > dependant as I switch computers and clients a lot. > > On Sun, Apr 15, 2012 at 10:50 PM, Erin Mallory < > angel_of_crim...@hotmail.com> wrote: > >> Why would it need to be in the inventory taking up space when it would >> ONLY do the same thing that either of these options do? If you can link a >> client ao to activate when the outfit is equipped that would satisfy the >> need for it to automatically turn on when you equip a new outfit AND keep >> the inventory MUCH less cluttered. >> The entire reason I use Firestorm's ao is so that I could get rid of as >> many copies of aos as I could and swap between ao sets almost instantly >> even in high lag areas. Right now they do not have a way to equip >> automatically when I set an outfit, however it is two extra clicks to >> select the one I want from a dropdown. If I could have a menu option on >> the outfit folder to allow me to associate each outfit with an AO so that >> it automatically swapped when I changed outfits that would be neat and do >> the same thing you wanted it to do. If I wanted to change the association >> or dissociate it I could do so from the same command. >> What I envision would simply be another option with a menu item such as >> "Set AO" and contain a drop nearly identical to the list in the AO drop >> down menu except it would also have a "none" option. for example if I had >> an outfit folder named "feral neko" with several attachments and clothes in >> it and wanted to associate my Puli Neko AO with it then all I would need to >> do is right click the folder for "feral neko" select "set ao" and click >> "Neko Puli AO" and then until i changed the associated ao every time I >> equipped the outfit "feral neko" it would automatically switch the ao to >> the Neko Puli AO set. That way i would not need any box or notecard or >> other object to clutter my already overwhelming inventory. >> Please explain what such a system would lack that either type of object >> you are talking about could provide because I simply do not see the >> benifits or requirements to have any object in the inventory other than a >> single notecard for each ao set and a copy of each animation that is >> included in any set. >> >> >> >> > CC: opensource-dev@lists.secondlife.com >> > From: secret.arg...@gmail.com >> > Subject: Re: [opensource-dev] allowing client side AO's to swtich with >> outfits >> > Date: Sun, 15 Apr 2012 21:34:30 -0500 >> > To: angel_of_crim...@hotmail.com >> >> > >> > On 2012-04-15, at 12:13, Erin Mallory wrote: >> > > 1) Allow outfit folders and AO sets to
Re: [opensource-dev] allowing client side AO's to swtich with outfits
If that process accounts for switching between separate computers and still having access to the various AOs, then it should be good! That was why I was thinking about notecards in a hidden folder: it provides serverside storage of the AO configurations. :) Ricky Cron Stardust On Tuesday, April 17, 2012, Lance Corrimal wrote: > how about way easier: > > > the client-side AO implementation that I use in my TPV stores its setup in a > folder tree, similar to how phoenix firestorm does it (no small wonder, it's > the same AO). > > How about this: > > whenever you save an outfit, a link to the ao config folder that is active at > that time is stored in the outfit, and when you put on an outfit, the "putting > on a saved outfit" code checks if a link to a folder that is contained in the > outfit is pointing at a folder inside the AO structure, and if so, activates > that AO config. > > > no reading of notecards or serializing stuff, only two links. > > bye, > LC > > > > Am Montag, 16. April 2012, 07:01:49 schrieb Ricky: >> As much as I'm not a fan of hacks, until there's proper server-side support >> this is what I suggest: Dahlia, I think I've taken a liking to your >> suggestion of the notecard idea, but with a twist. >> >> First, the client would create a new inventory folder named such that >> the likelihood of it being already in existence is extremely low. "Outfit >> Animations - Firestorm x.x" could be good for Firestorm, where the x's are >> a version code. This folder would be hidden from viewing in the >> client default so that it does not clutter up inventory, with an option in >> the client to make it visible. Inside this folder are notecards, each >> named after the outfit it's designed to match. These notecards contain >> LLSD serialized data designed to make it simple and fast for the client to >> pull down the animation data, update it, and store it back in the notecard. >> >> A simple GUI would be designed to make management and creation simple. >> >> Yes, this hack has the limitation that a given animation set cannot be in >> place for multiple outfits, but if there is a simple, easy way to clone an >> animation set to another outfit such would be mitigated. The ability to >> manually select another outfit's animation set is also an option. >> >> Ricky >> Cron Stardust >> >> On Mon, Apr 16, 2012 at 12:31 AM, Dahlia Trimble > wrote: >> > The AO could be coded such that it looks at the name of the currently worn >> > outfit and selects the appropriate animation list for that name. I believe >> > the name of the currently worn outfit is sent to the viewer as it's used >> > to >> > highlight it in the appearance selector menu. >> > >> > I suggested the notecard approach as an alternative that could also allow >> > notecards in outfits for other uses besides AO animation lists. However >> > given that it would likely require a server side change, it's probably >> > much >> > less likely to happen than just re-coding the client-side AO. Personally I >> > would prefer anything that is associated with my avatar to not be client >> > dependant as I switch computers and clients a lot. >> > >> > On Sun, Apr 15, 2012 at 10:50 PM, Erin Mallory < >> > >> > angel_of_crim...@hotmail.com> wrote: >> >> Why would it need to be in the inventory taking up space when it would >> >> >> >> ONLY do the same thing that either of these options do? If you can link >> >> a >> >> client ao to activate when the outfit is equipped that would satisfy the >> >> need for it to automatically turn on when you equip a new outfit AND keep >> >> the inventory MUCH less cluttered. >> >> The entire reason I use Firestorm's ao is so that I could get rid of as >> >> many copies of aos as I could and swap between ao sets almost instantly >> >> even in high lag areas. Right now they do not have a way to equip >> >> automatically when I set an outfit, however it is two extra clicks to >> >> select the one I want from a dropdown. If I could have a menu option on >> >> the outfit folder to allow me to associate each outfit with an AO so that >> >> it automatically swapped when I changed outfits that would be neat and do >> >> the same thing you wanted it to do. If I wanted to change the >> >> association >> >> or dissociate it I could do so from the same command. >> >&
Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs
Hole in one! :) That's exactly what I meant: client-controlled animations with the data that drives those animations stored such that you can log in from multiple computers and still have your animation sets available and (optionally) linked with outfits. Ricky Cron Stardust PS: For the record, I'm one of those annoying people who have stuck with the "duck walk" because I couldn't care less. That said, this topic hit me in one of my favorite themes: system design - hence my participation. :) On Tue, Apr 17, 2012 at 9:36 AM, Stickman wrote: > > What kind of server-side do you (and others!) really mean? It's been > > done the way it currently is (or rather, historically has been) for so > > long that I'm actually at a loss as to what the server has to do with it > > other than telling other clients "such-and-such is playing this > > animation." It's a little difficult for me to fathom what client-server > > interaction would be required beyond this. > > > > Maybe I'm just being dense, but beyond a slightly lightened script load > > on the server I honestly can't think of any particular advantage to > > doing it client-side, or what doing it with a client-side component > > would need partner components on the server for. > > > > Maybe it's just me. > > The entire point of client side AOs is to avoid the server. So yes, it > seems odd it would use the server. > > However, if no part of the server is used, the clientside AO data is > stored clientside. Log into your account from another computer, and > you no longer have your AOs. > > What makes sense is having the client-controlled AO data be stored on > the server so it can travel around with your login. Once you log in, > it's transmitted to the computer and acts and executes on the > clientside, with all the clientside benefits, with the added advantage > of being "backed up" on the server. > > The natural continuation of this idea is having it "paired" with > existing outfits, as an inventory object or some other identifier (I > vote for a "gesture" like window where you can assign pre-built > clientside AOs to specific outfits) so when you change outfits, you > can also magically change AOs without effort. > > Did I miss anything, or is this what we're getting at with this > ridiculously huge discussion? I admit I haven't been reading > everything. > > Stickman > ___ > 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] Talk/shout circles on minimap, lost in the cracks?
LOL - maps of any kind, even in RL, are confusing! It's the nature of maps. However, for the power user they are designed to be a wealth of information. The circles, and some more of the items I reported a while ago and can no longer find on JIRA that were about making the nearby list more radar-esque, would help clarify many things if done well as well as provide a large dose of information. Ricky Cron Stardust On Tue, May 8, 2012 at 9:27 AM, Oz Linden (Scott Lawrence) wrote: > On 2012-05-08 04:34 , Stickman wrote: > > I remember someone submitted a patch a long while ago that added shout > > and talk circles had been added to the minimap, so you could see who > > was within range. > [...] > > I was wondering if this was tied up somewhere and just required > > someone to click "ship it" or if there was an actual problem? I poked > > at 3.3.1 and it doesn't have this feature yet that I can tell. > > > > No... the user experience folks decided that the minimap was confusing > enough and that the circles made it worse. As punishment, we assigned > it to them to find a better solution :-) > > In a sense, it did fall through the cracks... I should have bugged them > about it before now... I'll do that. > > ___ > 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] JIRA entries disappearing into closed projects?
A while ago (a year or so) I reported something like 10 or so JIRA feature requests as a set, all under a meta umbrella. The requests all had to do with a design for improving the Near Me list to be a fairly basic radar replacement. I had placed them all under VWR when I reported them, but when Esbee switched them to STORM they somehow got her name as the reporter - not problem, I just watched the JIRA entries so I would be alerted to changes. Then one of my suggestions was taken up and implemented: the idea of adding the minimap to the Near Me list - I was happy progress was being made. Now I go looking and NONE of them are able to be found. I was able to find some I reported that were related - however the links relating them to the missing entries are gone too. Rather disturbed that it seemed like JIRA entries were being deleted, I just searched my email instead of JIRA. That resulted in the code I was looking for: STORM-642. Once I manually entered that into JIRA I found out that it has since evolved into CHUI-17 and locked out from public access. Is there any way to be notified when JIRA entries that you are watching or are creator of gets renamed so these kinds of surprises don't happen? Thanks, 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
Re: [opensource-dev] Talk/shout circles on minimap, lost in the cracks?
Correct, but most often a thick horizontal plane centered on your avatar's altitude is considered the most critical area. This volume is supposed to be indicated by the dots being round instead of triangular, thus giving the vertical filtering while the circles give the horizontal. I admit that just changing the shape of the dots is most likely not enough - if they changed brightness, and maybe hue or alpha, as well it would be clearer who's in the same thick plane. I say "supposed to be indicated by" because of the now well-known issues with resolving coarse altitude differences above about 1km... Ricky Cron Stardust On Wed, May 9, 2012 at 5:19 AM, Zai Lynch < i_really_needed_a_new_mail...@gmx.de> wrote: > Well, I don't know either about these circles. I only read about them in > this thread, though it seems they're supposed to indicate if someone is in > chat range or not. Though a circle won't indicate that, since SL is 3 > dimensional. If someone appears to be in chat range on the mini map, they > might not be, as chat range is a sphere, not a circle. > > > > On Wed, May 9, 2012 at 2:09 PM, Lance Corrimal > wrote: > >> Am Dienstag, 8. Mai 2012, 12:27:40 schrieb Oz Linden: >> >> > No... the user experience folks decided that the minimap was confusing >> > enough and that the circles made it worse. >> >> says a lot about those folks ;) >> >> > As punishment, we assigned it to them to find a better solution :-) >> >> I like the sound of that. >> >> That being said, has anyone ever seen a member of the user experience team >> inworld? >> >> >> bye, >> LC >> ___ >> 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 >> > > > > -- > @ZaiLynch <http://www.twitter.com/ZaiLynch> > > > ___ > 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] Anyone else having this issue uploading meshes?
Just a ping to see if the problem is limited to my combination of viewer
and mesh. The error pops up as a floater when I press "Calculate Weights &
Fees" and states the following:
Mesh failed to upload: Unable to upload asset.
Upload_ServerError
See the log file for details.
The log shows the following:
2012-06-03T17:07:08Z WARNING: completed: fee request failed
2012-06-03T17:07:08Z WARNING: log_upload_error: stage: fee http status: 500
2012-06-03T17:07:08Z WARNING: log_upload_error: err:
{'identifier':'Upload_ServerError','message':'Unable to upload asset.'}
2012-06-03T17:07:08Z WARNING: log_upload_error: mesh upload failed, stage
'fee' error '', message 'Unable to upload asset.', id 'Upload_ServerError'
2012-06-03T17:07:08Z WARNING: setModelPhysicsFeeErrorStatus:
LLFloaterModelPreview::setModelPhysicsFeeErrorStatus(500 : )
2012-06-03T17:07:08Z WARNING: LLToastAlertPanel::LLToastAlertPanel: Alert:
Mesh failed to upload: Unable to upload asset. Upload_ServerError
If you can or cannot repo, let me know at
https://jira.secondlife.com/browse/SVC-7978 or via private email, thanks!
Ricky
Cron Stardust
PS: I've tested with multiple viewers, using 3.3.1, 3.3.2, and 3.3.4.258391
vintages, involving Pathfinding, viewer-dev, and release - all show the
error. So I think it's either a serverside issue, or a problem with my
mesh - though why a mesh would cause a 500 Internal Server Error
response
PPS: As an aside, the latest VD I tried (
http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/integration_viewer-development/rev/258391/index.html)
crashed on login on Mac OSX Lion, but seems to run on Snow Leopard.
___
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] Anyone else having this issue uploading meshes?
Interesting hypothesis. However, I've now attempted this on both a Friday
and a Sunday with the same results. :) Also, as the status code is an HTTP
500 "Internal Server Error" instead of, for instance, SH-3055's 408
"Request Timeout" I'm leaning more towards a bug in the server than a
timing issue - though it's certainly possible that the latter could induce
the former!
Thanks for the response!
Ricky
Cron Stardust
On Sun, Jun 3, 2012 at 12:47 PM, Nicky Perian wrote:
> I have an unproven theory. It is Sunday with lots of stau on the inet. Now
> to my theory. Let's you have your data *.dae files on a network drive or
> worse yet in dropbox folder. The write back of the *.slm file is now taking
> a bit longer because of inet traffic and the normal latency for obtaining
> file locks and the LAN overhead involved of obtaining exclusive control of
> the file open, lock, write, unlock and close processes.
>
> I had this failure on aditi a couple Sundays ago, next morning and after
> moving the files to the *.dae local file system everything worked fine
> using the same exact files.
>
> However, I was using an hacd library in the system.
>
>
> --
> *From:* Ricky
> *To:* opensource-dev@lists.secondlife.com
> *Sent:* Sunday, June 3, 2012 12:43 PM
> *Subject:* [opensource-dev] Anyone else having this issue uploading
> meshes?
>
> Just a ping to see if the problem is limited to my combination of viewer
> and mesh. The error pops up as a floater when I press "Calculate Weights &
> Fees" and states the following:
>
> Mesh failed to upload: Unable to upload asset.
> Upload_ServerError
>
> See the log file for details.
>
>
> The log shows the following:
>
> 2012-06-03T17:07:08Z WARNING: completed: fee request failed
> 2012-06-03T17:07:08Z WARNING: log_upload_error: stage: fee http status: 500
> 2012-06-03T17:07:08Z WARNING: log_upload_error: err:
> {'identifier':'Upload_ServerError','message':'Unable to upload asset.'}
> 2012-06-03T17:07:08Z WARNING: log_upload_error: mesh upload failed, stage
> 'fee' error '', message 'Unable to upload asset.', id 'Upload_ServerError'
> 2012-06-03T17:07:08Z WARNING: setModelPhysicsFeeErrorStatus:
> LLFloaterModelPreview::setModelPhysicsFeeErrorStatus(500 : )
> 2012-06-03T17:07:08Z WARNING: LLToastAlertPanel::LLToastAlertPanel: Alert:
> Mesh failed to upload: Unable to upload asset. Upload_ServerError
>
>
> If you can or cannot repo, let me know at
> https://jira.secondlife.com/browse/SVC-7978 or via private email, thanks!
>
> Ricky
> Cron Stardust
>
> PS: I've tested with multiple viewers, using 3.3.1, 3.3.2, and
> 3.3.4.258391 vintages, involving Pathfinding, viewer-dev, and release - all
> show the error. So I think it's either a serverside issue, or a problem
> with my mesh - though why a mesh would cause a 500 Internal Server Error
> response
>
> PPS: As an aside, the latest VD I tried (
> http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/integration_viewer-development/rev/258391/index.html)
> crashed on login on Mac OSX Lion, but seems to run on Snow Leopard.
>
> ___
> 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] Anyone else having this issue uploading meshes?
Negative: I've not yet tested on non-pathfinding regions. I'll see if I
can do so soon.
Ricky
Cron Stardust
On Sun, Jun 3, 2012 at 1:11 PM, Geenz Spad wrote:
> Have you attempted this on both pathfinding and non-pathfinding regions?
> Seems to manifest primarily on pathfinding regions for me.
>
> --
> Geenz Spad
> Sent with Sparrow <http://www.sparrowmailapp.com/?sig>
>
> On Sunday, June 3, 2012 at 4:08 PM, Ricky wrote:
>
> Interesting hypothesis. However, I've now attempted this on both a Friday
> and a Sunday with the same results. :) Also, as the status code is an HTTP
> 500 "Internal Server Error" instead of, for instance, SH-3055's 408
> "Request Timeout" I'm leaning more towards a bug in the server than a
> timing issue - though it's certainly possible that the latter could induce
> the former!
>
> Thanks for the response!
> Ricky
> Cron Stardust
>
> On Sun, Jun 3, 2012 at 12:47 PM, Nicky Perian wrote:
>
> I have an unproven theory. It is Sunday with lots of stau on the inet. Now
> to my theory. Let's you have your data *.dae files on a network drive or
> worse yet in dropbox folder. The write back of the *.slm file is now taking
> a bit longer because of inet traffic and the normal latency for obtaining
> file locks and the LAN overhead involved of obtaining exclusive control of
> the file open, lock, write, unlock and close processes.
>
> I had this failure on aditi a couple Sundays ago, next morning and after
> moving the files to the *.dae local file system everything worked fine
> using the same exact files.
>
> However, I was using an hacd library in the system.
>
>
> --
> *From:* Ricky
> *To:* opensource-dev@lists.secondlife.com
> *Sent:* Sunday, June 3, 2012 12:43 PM
> *Subject:* [opensource-dev] Anyone else having this issue uploading
> meshes?
>
> Just a ping to see if the problem is limited to my combination of viewer
> and mesh. The error pops up as a floater when I press "Calculate Weights &
> Fees" and states the following:
>
> Mesh failed to upload: Unable to upload asset.
> Upload_ServerError
>
> See the log file for details.
>
>
> The log shows the following:
>
> 2012-06-03T17:07:08Z WARNING: completed: fee request failed
> 2012-06-03T17:07:08Z WARNING: log_upload_error: stage: fee http status: 500
> 2012-06-03T17:07:08Z WARNING: log_upload_error: err:
> {'identifier':'Upload_ServerError','message':'Unable to upload asset.'}
> 2012-06-03T17:07:08Z WARNING: log_upload_error: mesh upload failed, stage
> 'fee' error '', message 'Unable to upload asset.', id 'Upload_ServerError'
> 2012-06-03T17:07:08Z WARNING: setModelPhysicsFeeErrorStatus:
> LLFloaterModelPreview::setModelPhysicsFeeErrorStatus(500 : )
> 2012-06-03T17:07:08Z WARNING: LLToastAlertPanel::LLToastAlertPanel: Alert:
> Mesh failed to upload: Unable to upload asset. Upload_ServerError
>
>
> If you can or cannot repo, let me know at
> https://jira.secondlife.com/browse/SVC-7978 or via private email, thanks!
>
> Ricky
> Cron Stardust
>
> PS: I've tested with multiple viewers, using 3.3.1, 3.3.2, and
> 3.3.4.258391 vintages, involving Pathfinding, viewer-dev, and release - all
> show the error. So I think it's either a serverside issue, or a problem
> with my mesh - though why a mesh would cause a 500 Internal Server Error
> response
>
> PPS: As an aside, the latest VD I tried (
> http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/integration_viewer-development/rev/258391/index.html)
> crashed on login on Mac OSX Lion, but seems to run on Snow Leopard.
>
> ___
> 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
[opensource-dev] RFQ on VWR-29159 "Add default values for ExternalEditor"
After getting annoyed with trying to guess which editor I had available on each of my systems - and what its path was - I hunted down some generic values. Please review, test the values on your system, comment your opinion on the subject, and whether the values work for you or not. https://jira.secondlife.com/browse/VWR-29159 Thank you, 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
[opensource-dev] V-D 3.4.1.263223 crashes on world-rez on Mac
Second Life 3.4.1 (263223) Aug 8 2012 09:50:39 (Second Life Development) CPU: Intel(R) Core(TM) i5-2415M CPU @ 2.30GHz (2300 MHz) Memory: 8192 MB OS Version: Mac OS X 10.7.4 Darwin 11.4.0 Darwin Kernel Version 11.4.0: Mon Apr 9 19:32:15 PDT 2012; root:xnu-1699.26.8~1/RELEASE_X86_64 x86_64 Graphics Card Vendor: Intel Inc. Graphics Card: Intel HD Graphics 3000 OpenGL Engine OpenGL Version: 2.1 APPLE-7.18.18 Last 2 lines of log file: 2012-08-12T20:11:14Z llrender/llrendertarget.cpp(540) : error 2012-08-12T20:11:14Z ERROR: copyContentsToFramebuffer: Cannot copy framebuffer contents for non FBO render targets. It's been like this for several builds now - at least one other that I tried: 3.4.1.263188. Figured someone might find it useful to know. Second Life 3.3.3 (262585) Jul 26 2012 15:53:44 (Project Viewer - viewer-http) runs fine for me for now, have not run a Beta or Release viewer in a while, so I've no ide if it's better there or not - I'm the bleeding edge type! :P 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
Re: [opensource-dev] Review Request: Put the viewer version into marker files, and report errors only when the version matches
Wouldn't it be better if the crash could be reported anyway - just marking the correct version? With this in place at least crashes won't be misreported, but they also will be not reported to the servers at all, causing statistical deviation - what I believe is the core idea to be fixed. More comments in the JIRA, Ricky Cron Stardust On Wed, Oct 31, 2012 at 6:42 PM, Oz Linden wrote: >This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/607/ > Review request for Viewer. > By Oz Linden. > Description > > In all the marker files used to detect how the viewer run terminates, record > the version. When checking the results, report errors only if the current > version matches the version in the file. This prevents errors in one version > from being reported against the subsequent version. > > Testing > > Several simulated crashes both of the modified and unmodified viewers, and > some in which the marker file was modified manually to simulate different > viewers. Launched the new viewer after different crashes (and normal exits) > and confirmed (using logging temporarily added for that purpose) that the > reported last exec event was correct - and is always reported as Normal if > the previous version and the running version were not the same. > > *Bugs: * storm-1850 <http://jira.secondlife.com/browse/storm-1850> > Diffs > >- indra/newview/llappviewer.h (3d35a13561fc) >- indra/newview/llappviewer.cpp (3d35a13561fc) > > View Diff <http://codereview.secondlife.com/r/607/diff/> > > ___ > 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] Review Request: Put the viewer version into marker files, and report errors only when the version matches
Well, all I have is anecdotal evidence from my own family of four, everyone an SL user: we all keep multiple versions of the SL viewer, and even a few TPVs, on our machines. If one viewer crashes it's more often that the person it crashes on will relog in another version or viewer - just to avoid the perceived, if possibly inaccurate, cause of the crash. We may switch viewer versions on the second or third crash, depending on the individual, but the effect is the same. Like I said, it's anecdotal. Also I can hardly take my family as typical of SL users, but it's the only population of SL users I can observe. To me it seems that if it's both possible and feasible, the viewer should report and attempt to clean up after a crash - even if it is not its own. This would eliminate any deviation from appearing from this source. Either that, or the marker files should be filename keyed to a version, in which case the next time that particular version launches it will be able to do its own report and cleanup. However this has the negative that the viewer version may not ever be launched again, leaving the keyed marker files cluttering the filesystem. Not a good picture on this logical path either - though it could be kept sane by having any markers older than X be automatically removed - if they are too old it matters little. This path of logic does keep the deviation very minimal, though not eliminated: only those viewer versions that crash and are never re-launched get their report missed. Ricky Cron Stardust On Thu, Nov 1, 2012 at 10:34 AM, Argent wrote: > Wouldn't this only be an issue, normally, for people switching from one > the viewer to another, where there was an leftover crash filer from the > older viewer? Doesn't seem like leaving these events out would cause > significant deviation. > > > On Thu, Nov 1, 2012 at 11:09 AM, Ricky wrote: > >> Wouldn't it be better if the crash could be reported anyway - just >> marking the correct version? With this in place at least crashes won't be >> misreported, but they also will be not reported to the servers at all, >> causing statistical deviation - what I believe is the core idea to be >> fixed. More comments in the JIRA, >> >> 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
[opensource-dev] Found long-standing prim rotation bug: BUG-885
Just reported BUG-885 <https://jira.secondlife.com/browse/BUG-885>, "Edge-on prim rotation snaps when snap is disabled" Patch attached. Looks like this bug has been in place for a very long time - dates back to revision 0 of the code repository, committed by James Cook (James Linden). I've been delving back into the source code after a year and a half away. I have to compliment LL, and all else involved, on the streamlined compile setup - smoother even than the old develop.py system, definitely better than the transition period when I last attempted! :D I found this bug while I was working on learning/cleaning the code structure in the LLManip* classes in preparation for reviving an old project. Imagine my surprise when I found that one of the cases didn't have a check for whether Snapping was enabled! So I took to opportunity to delve deeper and work out a fix. Enjoy! Ricky Cron Stardust PS, for Firestorm I also reported it as FIRE-8338<http://jira.phoenixviewer.com/browse/FIRE-8338> as that is where I originally found the bug - however it exists in every viewer I've looked at. Based on my research I think it's been in existence since snapping was first introduced - whenever that was! ___ 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] Found long-standing prim rotation bug: BUG-885
For a missing hyphen... :) I meant edge-on. Here's how to reproduce the issue: Rez a cube Verify that Snap is disabled Orient camera to directly face one of the prim faces Select rotate mode or hold the correct modifier key(s) Using the mouse drag on the rotate circle that is most like a line - aka it is "edge-on" Observe that as you drag along the line of circle the cube it rotates smoothly (expected) Observe that if you drag off the line - as if snapping was enabled and you wished to snap - and then again in the direction of the line that it will snap. (not expected) Hope that helps clarify Ps. Sorry for the dup email Darien, I forgot to reply all. On Sunday, November 25, 2012, Darien Caldwell wrote: > I'm a little unsure what "Edge on rotation" means. I can rotate a prim on every axis in-world with snap off, and it never snaps. At least, not unless I make it snap by engaging the Angle ring outside the circumfrence of the rotation handle. Then it snaps as it should. > > I hope your patch isn't breaking this functionality, it's intended and desirable. > > On Sun, Nov 25, 2012 at 8:23 PM, Ricky wrote: >> >> Just reported BUG-885, "Edge-on prim rotation snaps when snap is disabled" Patch attached. >> Looks like this bug has been in place for a very long time - dates back to revision 0 of the code repository, committed by James Cook (James Linden). >> I've been delving back into the source code after a year and a half away. I have to compliment LL, and all else involved, on the streamlined compile setup - smoother even than the old develop.py system, definitely better than the transition period when I last attempted! :D >> I found this bug while I was working on learning/cleaning the code structure in the LLManip* classes in preparation for reviving an old project. Imagine my surprise when I found that one of the cases didn't have a check for whether Snapping was enabled! So I took to opportunity to delve deeper and work out a fix. Enjoy! >> Ricky >> Cron Stardust >> PS, for Firestorm I also reported it as FIRE-8338 as that is where I originally found the bug - however it exists in every viewer I've looked at. Based on my research I think it's been in existence since snapping was first introduced - whenever that was! >> ___ >> 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] Found long-standing prim rotation bug: BUG-885
Yep - so sneaky it's not been noticed for years. I think it's because no-one actually uses that part of the editors functionality! Leaves me wondering about when the snap functionality was introduced... The repository doesn't go back that far! :) On Sunday, November 25, 2012, Darien Caldwell wrote: > Ahh, I see what you mean. it's acting as if the hidden snap ring is still present. A sneaky bug. :) > > On Sun, Nov 25, 2012 at 10:13 PM, Ricky wrote: >> >> For a missing hyphen... :) I meant edge-on. >> >> Here's how to reproduce the issue: >> Rez a cube >> Verify that Snap is disabled >> Orient camera to directly face one of the prim faces >> Select rotate mode or hold the correct modifier key(s) >> Using the mouse drag on the rotate circle that is most like a line - aka it is "edge-on" >> Observe that as you drag along the line of circle the cube it rotates smoothly (expected) >> Observe that if you drag off the line - as if snapping was enabled and you wished to snap - and then again in the direction of the line that it will snap. (not expected) >> >> Hope that helps clarify >> >> >> Ps. Sorry for the dup email Darien, I forgot to reply all. >> >> On Sunday, November 25, 2012, Darien Caldwell wrote: >> > I'm a little unsure what "Edge on rotation" means. I can rotate a prim on every axis in-world with snap off, and it never snaps. At least, not unless I make it snap by engaging the Angle ring outside the circumfrence of the rotation handle. Then it snaps as it should. >> > >> > I hope your patch isn't breaking this functionality, it's intended and desirable. >> > >> > On Sun, Nov 25, 2012 at 8:23 PM, Ricky wrote: >> >> >> >> Just reported BUG-885, "Edge-on prim rotation snaps when snap is disabled" Patch attached. >> >> Looks like this bug has been in place for a very long time - dates back to revision 0 of the code repository, committed by James Cook (James Linden). >> >> I've been delving back into the source code after a year and a half away. I have to compliment LL, and all else involved, on the streamlined compile setup - smoother even than the old develop.py system, definitely better than the transition period when I last attempted! :D >> >> I found this bug while I was working on learning/cleaning the code structure in the LLManip* classes in preparation for reviving an old project. Imagine my surprise when I found that one of the cases didn't have a check for whether Snapping was enabled! So I took to opportunity to delve deeper and work out a fix. Enjoy! >> >> Ricky >> >> Cron Stardust >> >> PS, for Firestorm I also reported it as FIRE-8338 as that is where I originally found the bug - however it exists in every viewer I've looked at. Based on my research I think it's been in existence since snapping was first introduced - whenever that was! >> >> ___ >> >> 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] Found long-standing prim rotation bug: BUG-885
On file for years now :) On Sun, Nov 25, 2012 at 11:48 PM, Lance Corrimal wrote: > Verified - Now I'm sticking the patch in a test build to see if it breaks > other stuff. > > Do you have CA on file? > > bye, > LC > > > Am Sonntag, 25. November 2012, 23:26:53 schrieb Ricky: > > Yep - so sneaky it's not been noticed for years. I think it's because > > no-one actually uses that part of the editors functionality! > > > > Leaves me wondering about when the snap functionality was introduced... > The > > repository doesn't go back that far! :) > > > > On Sunday, November 25, 2012, Darien Caldwell > > > > > wrote: > > > Ahh, I see what you mean. it's acting as if the hidden snap ring is > still > > > > present. A sneaky bug. :) > > > > > On Sun, Nov 25, 2012 at 10:13 PM, Ricky wrote: > > >> For a missing hyphen... :) I meant edge-on. > > >> > > >> Here's how to reproduce the issue: > > >> Rez a cube > > >> Verify that Snap is disabled > > >> Orient camera to directly face one of the prim faces > > >> Select rotate mode or hold the correct modifier key(s) > > >> Using the mouse drag on the rotate circle that is most like a line - > aka > > > > it is "edge-on" > > > > >> Observe that as you drag along the line of circle the cube it rotates > > > > smoothly (expected) > > > > >> Observe that if you drag off the line - as if snapping was enabled and > > > > you wished to snap - and then again in the direction of the line that it > > will snap. (not expected) > > > > >> Hope that helps clarify > > >> > > >> > > >> Ps. Sorry for the dup email Darien, I forgot to reply all. > > >> > > >> On Sunday, November 25, 2012, Darien Caldwell < > darien.caldw...@gmail.com> > > > > wrote: > > >> > I'm a little unsure what "Edge on rotation" means. I can rotate a > prim > > > > on every axis in-world with snap off, and it never snaps. At least, not > > unless I make it snap by engaging the Angle ring outside the circumfrence > > of the rotation handle. Then it snaps as it should. > > > > >> > I hope your patch isn't breaking this functionality, it's intended > and > > > > desirable. > > > > >> > On Sun, Nov 25, 2012 at 8:23 PM, Ricky wrote: > > >> >> Just reported BUG-885, "Edge-on prim rotation snaps when snap is > > > > disabled" Patch attached. > > > > >> >> Looks like this bug has been in place for a very long time - dates > > > > back to revision 0 of the code repository, committed by James Cook (James > > Linden). > > > > >> >> I've been delving back into the source code after a year and a half > > > > away. I have to compliment LL, and all else involved, on the streamlined > > compile setup - smoother even than the old develop.py system, definitely > > better than the transition period when I last attempted! :D > > > > >> >> I found this bug while I was working on learning/cleaning the code > > > > structure in the LLManip* classes in preparation for reviving an old > > project. Imagine my surprise when I found that one of the cases didn't > > have a check for whether Snapping was enabled! So I took to opportunity > to > > delve deeper and work out a fix. Enjoy! > > > > >> >> Ricky > > >> >> Cron Stardust > > >> >> PS, for Firestorm I also reported it as FIRE-8338 as that is where > I > > > > originally found the bug - however it exists in every viewer I've looked > > at. Based on my research I think it's been in existence since snapping > was > > first introduced - whenever that was! > > > > >> >> ___ > > >> >> 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
[opensource-dev] BUG-885/STORM-1919 up for review
Got it readied for review - let me know what you all think. Issue: https://jira.secondlife.com/browse/STORM-1919 CR: https://codereview.secondlife.com/r/608/ Repo: https://bitbucket.org/kf6kjg/storm-1919 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
Re: [opensource-dev] Serious regression in SSB-enabled regions
I know this thread has gotten completely OT, but I feel I should respond to the feeling of dissatisfaction. I contribute to help me. I know that not everything I contribute will be accepted: see https://jira.secondlife.com/browse/VWR-25739 for one I created that I suspect that LL will never swallow, but that is already in Firestorm's LGPL codebase. What I've come to understand, and I accept as I can see the logic behind it, is that open source is not the same as open decision making, nor is it the same as allowing others to make the decisions. It simply means the code is available under a permissive license for others - including us - to review, comment on, modify, and compile for ourselves. Let me re-iterate: open source is NOT community maintenance. LL has never implied or pretended that they've set up a community maintenance program - and I think they'd have major problems if they tried. My L$2, and I will not continue in this topic on this thread. If you wish to respond to me, please take it off-list. Ricky Cron Stardust On Sun, Feb 24, 2013 at 7:27 PM, Carlo Wood wrote: > On Sun, 24 Feb 2013 20:09:19 +0100 > Henri Beauchamp wrote: > > > > I'm unable to comment on SUN issues (or even make them) > > > > Gotta love the new closed JIRA !... Way to go, LL... > > I was about to type "fuck you Linden Lab" in my previous post, > but assumed they might be assholes enough to then kick me > of this list... The phrase "way to go" is inventive. It would > never have occurred to me to use that in this context. > > This whole "open source" HAHAHA project is a pathetic, lame, > grrr - I want to SPIT on it. LL should be sued for fucking > CALLING this "open" in ANY way. I hate you. > > A REAL Open Source coder, > Carlo Wood > > PS I'd add a comment HERE regarding SUN-38, but I learned years >ago already that LL doesn't listen to anyone. They are just >going to give you the finger Henri (and everyone else in SL) >but not going to fix this. I'm not even going to TRY add >a (technical) comment. Seriously, why is ANYONE still HELPING >them? Why doesn't everyone just leave this list, stop >going to their meetings, and stop giving them patches? Are >you all stupid or what? > ___ > 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] HTTP connection changes heading to Aditi in the near future
AFAIK Script -> External HTTP Server, Script -> HTTP Script Server (llRequest*URL), and external client -> HTTP Script Server (llRequest*URL) all use HTTP traffic in and out of the region server. Also, again AFAIK, many objects/textures/&c. are now being sent across HTTP to the connected viewers. The common thread here: the region handling HTTP connections. If those get throttled, anything using HTTP-based communication (viewers, scripts, &c.) all get impacted. Ricky Cron Stardust On Thu, Mar 14, 2013 at 6:46 PM, Darien Caldwell wrote: > I'm curious how a script would be expected to recover from a 'flurry of > 502/503' errors? If my HTTP enabled object is expecting to communicate with > my external-to-SL server, and instead receives an 503 error, all I could > see doing is to retry. So is hammering the server with retries really going > to improve sim conditions? > > Would this be expected when communicating with external-to-SL services, or > is this more likely to occur when a scripted service is trying to > communicate with another scripted service within the Grid? > > As well I am not sure why scripts are being included in this at all. The > HTTP issues as I understood were the number of http connections a viewer > had to handle, with another factor in that mix being the particular router > the resident uses and how well/badly it handled multiple HTTP connections. > Service to service communcations such as a script to an external server or > a script to another script shouldn't be a contributing factor in these > viewer connection problems. The connections should never be hitting any > viewer. > >- Dari > > > On Thu, Mar 14, 2013 at 5:13 PM, Monty Brandenberg wrote: > >> >> We now have three channels and a number of regions available for testing: >> >> >>- DRTSIM-203. Normal release intended to go to Agni supporting >>keepalive connections and other changes. Regions: >> - TextureTest2. High texture count, no meshes, low residency >> limit to prevent interference when doing benchmark testing. >> - (Coming soon) MeshTest2. High mesh count (many distinct mesh >> assets which all look the same), few textures. Low residency limit to >> prevent interference when doing benchmark testing. >>- DRTSIM-203H. Our 'Happy' channel with more generous limits and >>optimistic service controls. >> - TextureTest2H. Identical to TextureTest. >> - (Coming soon) MeshTest2H. Identical to MeshTest2 >>- DRTSIM-203A. Our 'Angry' channel with stricter and preemptive >>enforcement of limits (generates many 503 errors). >> - TextureTest2A. Identical to TextureTest. >> - (Coming soon) MeshTest2A. Identical to MeshTest2 >> >> >> Test regions share object and texture references so if you are trying to >> measure download rates or really exercise the network, you'll need to >> defeat caching. Typically with a restart and manual cache clear or your >> own preferred method. Aditi is also hosting some of the server-side baking >> work and you may not get a reliable avatar appearance unless you use a >> Sunshine project viewer. >> >> What we're looking for on these channels: >> >> DRTSIM-203. HTTP issues generally. HTTP texture download reliability >> and throughput. Script writers using *llRequestURL* and * >> llRequestSecureURL* should try to get an A/B comparison going between a >> normal 'Second Life Server' region on Aditi and DRTSIM-203. Particularly >> with competing traffic like large texture or mesh downloads. Scripts >> aren't getting a boost with this work but they shouldn't be adversely >> impacted. Mesh also isn't getting a boost this time but, again, negative >> impact should be avoided. Third-party viewer developers should test for >> overall compatibility with all HTTP services. >> >> We're interested in reports of regressions in any areas. We *are* >> expecting more 503 errors (0x01f70001) in log files as it will be possible >> to push requests faster than before and certain throttles will be hit. As >> long as these are recoverable, they're not a regression, they're an >> indicator of better utilization. >> >> DRTSIM-203H (Happy). Scripts and mesh do get a boost here and other >> limits are generally raised. This may increase the tendency to get 503 and >> 502 (0x01f60001) errors in some areas. Again, these aren't regressions as >> long as they're recoverable. Su
Re: [opensource-dev] Creating my own login page
>From what I remember playing around with the SL built-in browser, it is very limited. Both the JS and HTML rendering engines leave much to be desired - their just too old, and don't understand a lot of today's tools - including jQuery. :( Of course, it's been almost a year since I last played with it, so YMMV. Ricky / Cron Stardust On Fri, Jan 24, 2014 at 9:38 AM, Lance Corrimal wrote: > Hi, > > I'm trying to create my own login screen, and I'm having a bit of > trouble creating HTML that does not make llqtwebkit curl up and die > quietly in a corner. > > My page loads fine in a webbrowser, but when i build a viewer that tries > to use it, all i get is a black screen inside the viewer and loads of > errors on stdout from llqtwebkit... > > My page is here: > http://dolphinviewer-login.eregion.de/ > > Any ideas for me where I should begin? > > > Cheers > LC > ___ > 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] OSX: unsupported compiler?!
OK, so it's been a while since I've compiled the LL viewer source. Hints on how to get over the following? $ autobuild configure -c RelWithDebInfoOS -- -DPACKAGE:BOOL=FALSE -DFMOD:BOOL=TRUE $ autobuild build -c RelWithDebInfoOS --no-configure ... Unsupported compiler 'com.apple.compilers.llvmgcc42' selected for architecture 'i386' Unable to determine concrete GCC compiler for file /Volumes/Data/Development/SLDev/bug-1043/indra/cmake/cmake_dummy.cpp of type sourcecode.cpp.cpp. $ gcc -v Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) Target: x86_64-apple-darwin12.5.0 Thread model: posix Thanks, 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
Re: [opensource-dev] OSX: unsupported compiler?!
Ah, what I get for c&p from the wiki. I do have my own compiled version of FMOD 3.75 - from back when I did have this process working a few years ago. :P IIRC there's a file I have to modify so that it gets loaded from my HD, but I'll figure that out again after I can get things compiling in the first case. As an aside, FS is compiling fine on my current setup - what's holding back LL's viewer? Patch submissions? Review? Anything I can do to help since I can't test compile my patches in their source ATM? On Tuesday, February 4, 2014, Nicky Perian wrote: > -DFMOD:BOOL=TRUE > should be -DFMODEX:BOOL= most likely false unless you have access to > the updated archive. > > > > > On Tuesday, February 4, 2014 5:54 AM, Nicky Perian < > nickyper...@yahoo.com> wrote: > > I don't think anyone as successfully up ticked to xcode 5.0. > I have noticed several are working on doing that. > IMO i'ts best to rename xcode by dropping the app from the name which will > change it to a folder. (picked up from google search). > Then, install xcode 4.6.3. > > NickyP > > > On Tuesday, February 4, 2014 12:08 AM, Ricky wrote: > > OK, so it's been a while since I've compiled the LL viewer source. Hints > on how to get over the following? > > $ autobuild configure -c RelWithDebInfoOS -- -DPACKAGE:BOOL=FALSE > -DFMOD:BOOL=TRUE > $ autobuild build -c RelWithDebInfoOS --no-configure > ... > Unsupported compiler 'com.apple.compilers.llvmgcc42' selected for > architecture 'i386' > Unable to determine concrete GCC compiler for file > /Volumes/Data/Development/SLDev/bug-1043/indra/cmake/cmake_dummy.cpp of > type sourcecode.cpp.cpp. > > > $ gcc -v > Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr > --with-gxx-include-dir=/usr/include/c++/4.2.1 > Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) > Target: x86_64-apple-darwin12.5.0 > Thread model: posix > > Thanks, > 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 (u > > ___ 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] OSX: unsupported compiler?!
Ah, what I get for c&p from the wiki. I do have my own compiled version of FMOD 3.75 - from back when I did have this process working a few years ago. :P IIRC there's a file I have to modify so that it gets loaded from my HD, but I'll figure that out again after I can get things compiling in the first case. As an aside, FS is compiling fine on my current setup - what's holding back LL's viewer? Patch submissions? Review? Anything I can do to help since I can't test compile my patches in their source ATM? On Tuesday, February 4, 2014, Nicky Perian wrote: > -DFMOD:BOOL=TRUE > should be -DFMODEX:BOOL= most likely false unless you have access to > the updated archive. > > > > > On Tuesday, February 4, 2014 5:54 AM, Nicky Perian < > nickyper...@yahoo.com> wrote: > > I don't think anyone as successfully up ticked to xcode 5.0. > I have noticed several are working on doing that. > IMO i'ts best to rename xcode by dropping the app from the name which will > change it to a folder. (picked up from google search). > Then, install xcode 4.6.3. > > NickyP > > > On Tuesday, February 4, 2014 12:08 AM, Ricky wrote: > > OK, so it's been a while since I've compiled the LL viewer source. Hints > on how to get over the following? > > $ autobuild configure -c RelWithDebInfoOS -- -DPACKAGE:BOOL=FALSE > -DFMOD:BOOL=TRUE > $ autobuild build -c RelWithDebInfoOS --no-configure > ... > Unsupported compiler 'com.apple.compilers.llvmgcc42' selected for > architecture 'i386' > Unable to determine concrete GCC compiler for file > /Volumes/Data/Development/SLDev/bug-1043/indra/cmake/cmake_dummy.cpp of > type sourcecode.cpp.cpp. > > > $ gcc -v > Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr > --with-gxx-include-dir=/usr/include/c++/4.2.1 > Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) > Target: x86_64-apple-darwin12.5.0 > Thread model: posix > > Thanks, > 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 (u > > ___ 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] OSX building xcode GUI compile failure
I don't have an answer, but will note that I've never had much luck with any of the viewers I've compiled compiling from the XCode GUI - commandline yes, GUI no. I remember many months (years?) ago that I was able to get the LL viewer to compile from the XCode GUI, but only after much tweaking of the compiler settings IN the GUI. What I did, I do not know, but it was a pain, and later attempts have never worked out. I now just edit the code with TextWrangler and compile from the commandline... :P (At least I do for FS, LL's viewer is as my previous message to this board!) Ricky / Cron Stardust On Tue, Feb 4, 2014 at 3:46 PM, Nicky Perian wrote: > quicktime/Debug/libmedia_plugin_quicktime.dylib > > ld: library not found for -lexception_handler > collect2: ld returned 1 exit status > Command > /Applications/Xcode_4.6.3.app/Contents/Developer/usr/bin/llvm-g++-4.2 > failed with exit code 1 > > the viewer complies using autobuild build. > > If I use xcode gui several of the plugins have ld: library not found for > -lexception_handler error. > > What causes the gui to fail when command line compile doesn't? > > > > > ___ > 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] OSX building xcode GUI compile failure
I attach the XCode GUI debugger to the running process, FireStorm in my case, compiling with RelWithDebInfo*. Worked for my task, YMMV. Ricky / Cron Stardust On Tue, Feb 4, 2014 at 9:16 PM, Nicky Perian wrote: > I didn't knew that it couldn't be done that way. I have an issue in Kokua > that I wanted to set a trace point and determine from wince a method was > being called. > That is simple to set up on Windows using VS2010. I was hoping to the same > in xcode. > > > > >On Tuesday, February 4, 2014 5:47 PM, Nicky Perian < > nickyper...@yahoo.com> wrote: > > quicktime/Debug/libmedia_plugin_quicktime.dylib > > ld: library not found for -lexception_handler > collect2: ld returned 1 exit status > Command > /Applications/Xcode_4.6.3.app/Contents/Developer/usr/bin/llvm-g++-4.2 > failed with exit code 1 > > the viewer complies using autobuild build. > > If I use xcode gui several of the plugins have ld: library not found for > -lexception_handler error. > > What causes the gui to fail when command line compile doesn't? > > > > > ___ > 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] OSX building xcode GUI compile failure
And to add to the tale: https://developer.mozilla.org/en-US/docs/Debugging_on_Mac_OS_X shows how to set up a new project for the sole purpose of debugging an existing .app without XCode trying to "helpfully" recompile the code every time you want to run the thing. Just make sure to uncheck "Allow debugging when using document Versions Browser" in Product-->Edit Scheme .. -->Run APP_NAME.app otherwise --NSDocumentRevisionsDebugMode YES gets passed to the executable, which causes the viewer to freak out parsing the options. After that, just add the source files to the project and execute. Of course, if you want to compile a change it's off to the commandline, but for me that's OK. Maybe at some point I'll figure out how to have XCode call the command from a button. Then again, I might not. On Wed, Feb 5, 2014 at 5:00 AM, Nicky Perian wrote: > To complete the record for other that are in the baby step phase: > > > https://developer.apple.com/library/mac/documentation/IDEs/Conceptual/gdb_to_lldb_transition_guide/document/lldb-terminal-workflow-tutorial.html > > > On Wednesday, February 5, 2014 12:13 AM, Ricky wrote: > > I attach the XCode GUI debugger to the running process, FireStorm in my > case, compiling with RelWithDebInfo*. > > Worked for my task, YMMV. > > Ricky / Cron Stardust > > > On Tue, Feb 4, 2014 at 9:16 PM, Nicky Perian wrote: > > I didn't knew that it couldn't be done that way. I have an issue in Kokua > that I wanted to set a trace point and determine from wince a method was > being called. > That is simple to set up on Windows using VS2010. I was hoping to the same > in xcode. > > > > >On Tuesday, February 4, 2014 5:47 PM, Nicky Perian < > nickyper...@yahoo.com> wrote: > > quicktime/Debug/libmedia_plugin_quicktime.dylib > > ld: library not found for -lexception_handler > collect2: ld returned 1 exit status > Command > /Applications/Xcode_4.6.3.app/Contents/Developer/usr/bin/llvm-g++-4.2 > failed with exit code 1 > > the viewer complies using autobuild build. > > If I use xcode gui several of the plugins have ld: library not found for > -lexception_handler error. > > What causes the gui to fail when command line compile doesn't? > > > > > ___ > 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] OSX building xcode GUI compile failure
No problem. I've been looking for this info myself, as I do most of my work these days on either OSX or Linux. I was doing fine with gdb until I wanted to set some breakpoints and look over variable statuses, &c... So I went looking, found the above, and got it working today. I think the issue is that the XCode project files that the CMake system is creating aren't feeding XCode everything correctly for the GUI-based compilation. They are good enough for the commandline operation using the custom autobuild system, but not quite right for XCode. On Sun, Feb 16, 2014 at 3:38 PM, Nicky Perian wrote: > I was able to solve the problem using CLI. > > My misguided thinking was that Apple being famous for its user GUI would > have had a build system GUI at least as good if not better than windows > VS2010 where you just open the project file and hit run in debug mode. > From there you can set breakpoints and tracepoints. > > That works fine until the issue is present in Mac or linux. > > I tried LLDB and made a little progress. > > Thanks for the reply. > > > > > On Sunday, February 16, 2014 5:24 PM, Ricky wrote: > > And to add to the tale: > https://developer.mozilla.org/en-US/docs/Debugging_on_Mac_OS_X shows how > to set up a new project for the sole purpose of debugging an existing .app > without XCode trying to "helpfully" recompile the code every time you want > to run the thing. > > Just make sure to uncheck "Allow debugging when using document Versions > Browser" in Product-->Edit Scheme .. -->Run APP_NAME.app > otherwise --NSDocumentRevisionsDebugMode YES gets passed to the > executable, which causes the viewer to freak out parsing the options. > > After that, just add the source files to the project and execute. Of > course, if you want to compile a change it's off to the commandline, but > for me that's OK. Maybe at some point I'll figure out how to have XCode > call the command from a button. Then again, I might not. > > > On Wed, Feb 5, 2014 at 5:00 AM, Nicky Perian wrote: > > To complete the record for other that are in the baby step phase: > > > https://developer.apple.com/library/mac/documentation/IDEs/Conceptual/gdb_to_lldb_transition_guide/document/lldb-terminal-workflow-tutorial.html > > > On Wednesday, February 5, 2014 12:13 AM, Ricky wrote: > > I attach the XCode GUI debugger to the running process, FireStorm in my > case, compiling with RelWithDebInfo*. > > Worked for my task, YMMV. > > Ricky / Cron Stardust > > > On Tue, Feb 4, 2014 at 9:16 PM, Nicky Perian wrote: > > I didn't knew that it couldn't be done that way. I have an issue in Kokua > that I wanted to set a trace point and determine from wince a method was > being called. > That is simple to set up on Windows using VS2010. I was hoping to the same > in xcode. > > > > >On Tuesday, February 4, 2014 5:47 PM, Nicky Perian < > nickyper...@yahoo.com> wrote: > > quicktime/Debug/libmedia_plugin_quicktime.dylib > > ld: library not found for -lexception_handler > collect2: ld returned 1 exit status > Command > /Applications/Xcode_4.6.3.app/Contents/Developer/usr/bin/llvm-g++-4.2 > failed with exit code 1 > > the viewer complies using autobuild build. > > If I use xcode gui several of the plugins have ld: library not found for > -lexception_handler error. > > What causes the gui to fail when command line compile doesn't? > > > > > ___ > 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
[opensource-dev] Help: Possible untranslated text in viewer
As I've been working on an unrelated problem, I found a section of the code that has some hardcoded text. I'm fairly certain that this text is untranslated and currently untranslatable. Could someone who is using a non-English UI verify for me please? The text appears only briefly in white near the mouse when scaling, moving, or rotating a prim with snap enabled, and only the first 5 times in a session. Here's the text: Move mouse cursor over ruler to snap to grid Attached is a screenshot of the text for further reference. Thanks! I'll create the JIRA entry if I can get proof from someone. 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
Re: [opensource-dev] Help: Possible untranslated text in viewer
Thanks Martin! Issue created as https://jira.secondlife.com/browse/OPEN-204 I've added it to my patch queue, but if someone more familiar with the translation system, as yet I'm not, wants to crush this one, no problem here! Ricky / Cron Stardust On Sun, Mar 2, 2014 at 11:01 AM, Martin Fürholz wrote: > Hello, > > Yes that's right, the text appears in llmaniptranslate.cpp: > > > https://bitbucket.org/lindenlab/viewer-release/src/7f25eb72444a452150e06edb363abc41045d3863/indra/newview/llmaniptranslate.cpp?at=default#cl-1444 > > > > MartinRJ > > > > *Von:* opensource-dev-boun...@lists.secondlife.com [mailto: > opensource-dev-boun...@lists.secondlife.com] *Im Auftrag von *Ricky > *Gesendet:* Sonntag, 02. März 2014 06:02 > *An:* opensource-dev@lists.secondlife.com > *Betreff:* [opensource-dev] Help: Possible untranslated text in viewer > > > > As I've been working on an unrelated problem, I found a section of the > code that has some hardcoded text. I'm fairly certain that this text is > untranslated and currently untranslatable. Could someone who is using a > non-English UI verify for me please? > > > > The text appears only briefly in white near the mouse when scaling, > moving, or rotating a prim with snap enabled, and only the first 5 times in > a session. Here's the text: > > Move mouse cursor over ruler > > to snap to grid > > > > Attached is a screenshot of the text for further reference. > > > > Thanks! I'll create the JIRA entry if I can get proof from someone. > > > > 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
Re: [opensource-dev] Fw: [git] Include Jira Ticket Number in Commits, Please!
Techwolf trying to get SL on OnLive or something? An interesting idea - I wonder how badly the viewer would bog their servers with full draw distance in an avvie-loaded continent! On Thu, Jul 3, 2014 at 1:27 PM, wrote: > > > Begin forwarded message: > > Date: Wed, 02 Jul 2014 11:32:09 -0700 > From: OnLive Jira Watcher > Subject: [git] Include Jira Ticket Number in Commits, Please! > > > This notice is to remind you that you need to include valid Jira ticket > numbers in all of your Git commits! > > We encountered the following problems in your recent commits. > > Commits with no reference to any jira tickets: > > https://github.onlive.com/Engineering/ol-secondlife/commit/3a5fae14 > Clean up and rework FMOD.cmake and FindFMOD.cmake > FMOD.cmake: > Move include(Prebuilt) to prebuilt section. It is only used for > prebuilt anyway. set(FMOD_FIND_REQUIRED ON) due to FMOD variable is > use elsewhere in cmake files. This behaviour is the same as openal. > Remove redudent error messages and code due to above. Rework the > logic to be more cleaner. Clean up whitespace. > FindFMOD.cmake > Remove redudent paths as cmake allready uses them as default. > Use PATH_SUFFIXES instead. The above will result in cmake looking in > a lot more places and can handle custom build setups better. Change > FMOD to FMOD_FOUND. FMOD should not be change withen cmake. > Whitespace cleanup. -- > https://github.onlive.com/Engineering/ol-secondlife/commit/ef220319 > Allow the passing of addational fmod lib names via FMOD_NAMES from the > build envorment. This will allow one to pass via command line custom > fmod lib names. ie: -DFMOD_NAMES:STRING:"fmod-4.44" - Commits > which reference invalid Jira ticket numbers that don't exist or have > already been closed: > > https://github.onlive.com/Engineering/ol-secondlife/commit/999f782a > SNOW-746: Finished Google BreakPad cmake for standalone > (transplanted from 5a7ee78d029e973084e28d0d23a7233e0d976dca) > > --HG-- > extra : transplant_source : > Z%7E%E7%8D%02%9E%970%84%E2%8D%0D%23%A7%23%3E%0D%97m%CA -- > https://github.onlive.com/Engineering/ol-secondlife/commit/a6def839 > VWR-20893: "class Linux_x86_64Manifest" missing from viewer_manifest.py > Breaking linux 64-bit build. (transplanted from > 111a293c0e1c9062b1aa83dda7cf28aa22754930) > > --HG-- > extra : transplant_source : > %11%1A%29%3C%0E%1C%90b%B1%AA%83%DD%A7%CF%28%AA%22uI0 -- > https://github.onlive.com/Engineering/ol-secondlife/commit/5ff89857 > SNOW-599/SNOW-747: Pulseaudio should be optional on Linux. > - > > Please be more careful in future commits. > > For information about installing the local onlive git hooks, which can > help you remember, see > https://wiki.onlive.com/display/DOCS/OnLive+Git+Hooks > ___ > 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] Debugging purging a single folder from trash
Just a quickie, trying to avoid digging through the viewer code myself to be sure: When a folder that is in the trash is purged, what calls to the server does the client make? I'm debugging an OpenSim derivative, and just noticed that it seems that there's a difference in the calls when the folder being purged has children and when it doesn't. Trying to confirm that there is an actual difference or if something else in this complex system is interacting... I figure there are people on this list who have a lot more knowledge about this area of the code than I do and either already know the answer or can find it faster than I. Thanks! 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
Re: [opensource-dev] Debugging purging a single folder from trash
Henri, thank you for the detailed response. I suspected the protocol was defined that way: attempting to make the viewer responsible for managing the server's database. Bad design, but typical of early LL when everything was a single project and there was no separation between the client and server codebases. (Statement not intended to start an anti-LL flame, let's keep on topic! :) ) That explains the information I was getting: a single RemoveInventoryFolder for purging a single empty folder, and a mix of RemoveInventoryFolder and PurgeInventoryDescendents for purging a hierarchy. I was originally expecting a single PurgeInventoryFolder for purging a single folder no matter whether it had children or not, and a single PurgeInventoryDescendents upon emptying the trash. That would have been clean and simple, the serverside doing all the dirty work of cleaning up the hierarchy. Now I know what to expect, I can make sure to handle it. Anyway, thanks again! Ricky Cron Stardust On Mon, Oct 5, 2015 at 1:40 AM, Henri Beauchamp wrote: > On Sun, 4 Oct 2015 21:50:39 -0700, Ricky wrote: > > > Just a quickie, trying to avoid digging through the viewer code myself to > > be sure: > > When a folder that is in the trash is purged, what calls to the server > does > > the client make? > > > > I'm debugging an OpenSim derivative, > > I don't know what you are trying to debug, but just in case, be aware > that at least one such "derivatives", in use on OSGrid, does not obey > the purge trash messages sent by the viewer (it looks like the trash > gets emptied, but on relog, the purged items will reappear in it): > it's totally weird and IMO a pure non-sense but in OSGrid, if you want > to purge your trash, you must login into their web site and purge it > from there... > I myself lost quite some time (G !) trying to figure out why I > couldn't purge my trash (and searched pointlessly for a bug in my > viewer), till I found out this totally quirky (and unique: I didn't > encounter it on any other grid) "feature" of OSGrid. > > > and just noticed that it seems that > > there's a difference in the calls when the folder being purged has > children > > and when it doesn't. Trying to confirm that there is an actual > difference > > or if something else in this complex system is interacting... > > The relevant call in the viewer code is remove_inventory_category() > (in llviewerinventory.cpp). > When connected to a non-AISv3 (which is the case for OpenSIM), it > either sends to the server a single RemoveInventoryFolder UDP message > when the folder is empty or, for each child folder (recursively, via > the destructor of the LLRemoveCategoryOnDestroy class), a > PurgeInventoryDescendents UDP message (via purge_descendents_of()) > followed with a RemoveInventoryFolder UDP message; the process is > recursively repeated till the purged inventory folder is empty (at > which point a last RemoveInventoryFolder message is sent for the > purged parent folder). > > Henri. > ___ > 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] Windows surprise build error
Looks like http://superuser.com/questions/194529/cygwin-fatal-error-unable-to-remap-what-does-it-mean On Sun, Nov 29, 2015 at 7:02 PM, Nicky Perian wrote: > Last night everything built w/o error. > Today this is happening. > Has anyone seen this? > > 12>-- Build started: Project: lscript_compile, Configuration: Release > Win32 -- > 12> Building Custom Rule > C:/Users/Bill/398-buildcleanup/indra/lscript/lscript_compile/CMakeLists.txt > 12> CMake does not need to re-run because > C:\Users\Bill\398-buildcleanup\build-vc120\lscript\lscript_compile\CMakeFiles\generate.stamp > is up-to-date. > 12> Generating indra.l.cpp > 12>0 [main] flex 8972 C:\cygwin64\bin\flex.exe: *** fatal error in > forked process - fork: can't reserve memory for parent stack 0x60 - > 0x80, (child has 0x40 - 0x60), Win32 error 487 > 12> 522 [main] flex 8972 cygwin_exception::open_stackdumpfile: > Dumping stack trace to flex.exe.stackdump > > ___ > 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] Firewall block of media files
The issue there, I suspect, is that the files are served with the wrong MIME type, causing them to appear as generic files to be saved to disk, not played. The correct fix is to serve media files from a server that sets the correct MIME type. However, while correct, that might be a burden on some. The parcel media system has a way to specify a MIME type, but MOAP has no such ability, this is a detail specified in all web browsers: the Content-Type and Content-Disposition headers sent by the server are authoritative. As a test, what happens if you put that same URL to one of the MOV, AVI, WMV files you are testing with directly into Chrome? Does Chrome start playing it, or does it download the file? If the former it should play, barring CODEC issues like MPEG4. If the latter, the files should be put on a server intended for playing media, not sharing downloadable files. On Thu, May 19, 2016 at 9:10 AM, Nicky Perian wrote: > At one time we could play individual media files on both parcel media and > MOAP such as mov avi wmv that were stored on services such as Dropbox. > I noticed will testing viewer-release-vlc that it these are not allowed. > > There is a notice that these files cannot be downloaded to SecondLife. > > How are we supposed to test media by file type if the individual true > media files (no wrappers) cannot be downloaded into secondlife grids? > > > ___ > 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] Firewall block of media files
Agreed. On Fri, May 20, 2016 at 4:37 PM, Oz Linden (Scott Lawrence) < o...@lindenlab.com> wrote: > On 2016-05-19 09:49 , Ricky wrote: > > The issue there, I suspect, is that the files are served with the wrong > MIME type > > Close ... they are sent with a Content-Disposition header that specifies > that they be saved as a file. > > Some applications may ignore or override this. It used to be true, for > example, that IE would use a URL suffix rather than the MIME type. I don't > think we should do that; we should do whatever CEF does unmodified. > > -- > OZ LINDEN | Engineering Director, Second Life > email or hangouts: o...@lindenlab.com | Real Life: Scott > Lawrence > LINDEN LAB | Create Virtual Experiences <https://www.lindenlab.com> > > ___ > 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] Client-side scripting in Snowglobe
I suspect that there are two things being discussed here without distinction: Client scripting, and client extensions. Confusing the two is easy. Client-side scripting SHOULD be sandboxed, and in a controlled set of languages. For a close example think of javascript in web browsers. Client extensions, or alternatively named as "plugins", would be modules that can be plugged in and out of the client and run /as if/ they were a part of the client. Think of browser add-ons/plugins/extensions. Client side scripts could (read might be, could possibly, needs further thought, etc.) be given permission to be loaded in by worn items automatically. Other objects would likely need to request permission via a security warning. Client extensions would have to be downloaded and installed externally; not delivered in-world. These would truly be programs on your computer, and should be treated as such. Just my thoughts hoping for a clearer discussion. Ricky Cron Stardust On Thu, Feb 18, 2010 at 2:27 PM, Morgaine wrote: > On Thu, Feb 18, 2010 at 7:07 PM, Dahlia Trimble > wrote: > >> To me, an environment such as SL or the web in general tend to attract a >> few malicious developers, or more so, companies and individuals who are >> interested in collecting personal data and usage patterns. I'd prefer some >> level of control over what they can access without needing to understand the >> source code of any scripted extensions (if indeed source was available). >> >> > Dahlia, I agree with part of that, to the extent where it applies: > > The "malicious users" argument presupposes that scripts come from 3rd > parties, some of whom are malicious. When people write their own scripts, > which is very common in this opensource-dev community, they are not > malicious 3rd parties, and they do not generally want to be treated as such. > > Quite the opposite, they want all the power that scripting on their local > platform can give them. Therefore the "malicious users" argument applies > only to a subset of scripts, the downloaded ones, and it is perfectly valid > there. However, it does not apply to one's own scripts, nor to any other > power-users' scripts that one wishes to trust. > > This leads directly to a rather fundamental requirement: the sandbox must > be optional, applying only to the use case of unknown downloaded scripts, > and not applying when the user wishes her scripts to be used as an interface > to local facilities. > > It is considerations such as this that Lindens should be exploring together > with the community here, because it impacts on the future of Snowglobe > directly and in a colossal way. We are all affected. Designing this behind > closed doors is not adequate, nor is it appropriate in an open source > community viewer. > > > Morgaine. > > > > > > == > > > On Thu, Feb 18, 2010 at 7:07 PM, Dahlia Trimble > wrote: > >> I haven't been following this topic in any office hours so I hope my >> comments aren't too off base. >> >> Personally I'd prefer to be able to run extensions as sandboxed, and maybe >> have the option of running them unprotected on a per-extension basis. To me, >> an environment such as SL or the web in general tend to attract a few >> malicious developers, or more so, companies and individuals who are >> interested in collecting personal data and usage patterns. I'd prefer some >> level of control over what they can access without needing to understand the >> source code of any scripted extensions (if indeed source was available). >> >> Concerning Morgaine's list: while I may not fully agree with reasons 1-4, >> they appear to reflect valid concerns and are presented in a agreeable >> manner. Reasons 5 and 6 seem to imply political overtones to me, and I >> suspect any platform choice will carry some political burden with it. >> Personally I believe mono to be a reasonable choice for a scripting >> environment, especially given LL's experience with it in their servers. >> >> And now since I don't contribute to the LL viewer source, I'll shut up :) >> >> -d >> >> >> On Thu, Feb 18, 2010 at 4:57 AM, Morgaine > > wrote: >> >>> A line got lost from my post owing to finger trouble. Item 6 about Mono >>> should have read: >>> >>> >>> 6. Some parties identify other reasons for avoiding Mono in general. >>> Without getting into that subject at all, requiring Mono for client-side >>> scripting would make scripting unavailable to that portion of the user >>> base. Since
Re: [opensource-dev] Consensus? was: Client-side scripting in Snowglobe
Look good to me. As you said, a scripting engine (or three) could be written as a plugin. Then we'd only have to decide which plugin(s) get shipped with the client by default. A much more fruitful discussion I think. Ricky Cron Stardust On Sunday, February 21, 2010, Carlo Wood wrote: > It seems to me that most people still talk about untrusted, > portable, and grid-wide supported downloadable scripts when > talking about Client-side scripting (sorry Morgaine). > > So, I propose to go with that, and call anything else > "Client-extensions". > > --- > > The remainder of this post is about Client-extensions. > > I sense consensus on the following layered design: > > [current code base] > > + lots of hooks to be written > > | > | > V > > C++ API [1] > > | > | > V > > IPC API [2] > > | > | > V > > Plugin(s) > > > One or more plugins then could provide a client-side > scripting engine; either for trusted for any language, > or a secure API for an engine running the mono bytecode > that LL is working on (or whatever). > > - A scripting engine for language XYZ. > > [1] Ie, based on the yet to be written LLStateMachine class. > [2] Ie, a socket. What is more important is the protocol > that is being used here. I can imagine that this will > be LLSD, or something simular. > > -- > Carlo Wood > > PS Note that personally I'm against using mono for > clientside scripting... > > ___ > 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] The Faces Of Client-Side Code
A while back, before the 2.0 announce interrupted our conversation, I had made a post about what I saw as three different forms of client-side scripting/plugins/whathaveyou. I've since been convinced that I missed something. So here goes again, with a (hopefully) improved set of definitions: Client Plugins - Binaries compiled per-platform and placed in a special folder in the client directory by the user/admin of the client's installation. These should have no security restrictions, and should have access to any file on your computer that the system allows, and access to any internal process of the client. Provides the ability to build parts of the client without recompiling: eg. Client-side script interpreters, better joystick support, expose further public APIs via sockets or whatever, etc. Also is free to access system libraries, such as OpenGL, windowing toolkits, etc. Client Extensions - Interpreted code packages placed in a special folder in the client directory by the user/admin of the client's installation. These should run in a broad sandbox: Limited local disk access (max datastore size, etc.) to a special file in the local user folder. Eg: ~/.secondlife/slfirst_lastname/extensions/extensionname.eds (Extension DataStore) But can still access much the same client hooks as the Plugins. Provides fast prototyping, and lower entry difficulty, than Plugins, but will most likely not have the freedom to tap into a lot of system stuff. Also will not typically run as fast or in as little memory space as the binary plugins. Dynamic Client Scripts - Interpreted scripts loaded from the server via the server-side permissions system. May still need a better name... Could be stored in Notecards and a server-side script could petition, via llRequestPermissions, to be able to request that the client download the notecard named via a llLoadClientScript(string name, integer channel) or similar command. The notecard would then be downloaded by the client and the plugins/extensions that had registered as able to interpret scripts would then be queried as to their ability to understand the code, and the one that answered with the most certainty could be given the task. Some sort of first-line header in the notecard would help this process along. Executed within TIGHT sandboxing: Limited, or no access to local disk storage, and limited to tasks such as drawing on the HUD layer of the GUI, creating floaters to draw in, communicating back to the world via the predefined channel number, etc. The limits are, of course, up to the plugin/extension maker. Another potential limit would be the automatic unloading of the script when the host object is out of range, or is no longer attached. Of course the Plugin maker could decide when, or if, the user should be asked before loading the script, even if the server-side has given its permission. Provides the ability to make advanced HUDs, radars, etc. These would mostly eliminate the need for object-based HUDs, improving server speed by taking non-content load off the server, and still allow the specialized groups in SL the ability to create HUDs and tools that users could be given automatically upon entering a "role-play" area. UserScripts (Term borrowed from GreaseMonkey) - Interpreted scripts loaded dynamically into the client by the user. Function just like Dynamic Client Scripts, except the source is the user themselves opening a local text file, or opening a console window and typing commands. Provides local quick changes, and even personal never-touched-the-server HUD objects, floaters, etc. Lowest entry difficulty of the whole set of ideas. Note that should the Client Plugins be implemented, all the rest, and more, could and would be implemented in droves. Also any security restrictions, or lack thereof, would be created by the plugin designer. The above security restrictions would then be only guidelines. These seem to cover the whole range of what has been discussed so far. Morgaine's interpreted client scripts/plugins communicating via sockets would be considered Client Extensions and would be implemented starting with a really generic Client Plugin. This is assuming that I've understood Morgaine's idea correctly! :) Yes, I've been mulling this over and over in my brain since the previous conversation was interrupted I had just gotten to the point where I was enjoying the back and forth of problem solving! 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
Re: [opensource-dev] The Faces Of Client-Side Code
Carlo, both you and Morgain make very good arguments as to why various parts I separated are, technically, the same. However, while I understand that Dynamic Scripts (loaded from serverside) and UserScripts are completely the same thing (just like in a browser, the JavaScript loaded from the server-side alongside the web page, and GreaseMonkey UserScripts are both just seperate views of the same thing,) they are made distinct in the terminology here due to the fact that a user will see a difference. I also understand how you would see the Extensions and Plugins as also being nothing but the same thing. Setting up an IPC layer in the C++ is absolutely required, but I don't think that we need to put /multiple/ ways of connecting plugins into the code hooks. I'd prefer the most direct method of using a form of dynamically loaded shared library that implements a common object Interface that the client then calls. This provides the most direct, most capable interface. It is also not very abstract, as the underlying code could easily change in such a way as to break the interface, but that is a common enough problem for any of the plugin designs I've met with. As I mentioned before, one of the first of these plugins could easily be one that exposes a socket based interface for a more abstracted system, a la Morgaine's design. Note that while most users may not explicitly notice a difference between Plugins and Extensions, as they can easily blur use-cases, they are hugely different in the back-end. Consider Plugins to be ways of writing a "patch" that provides a new feature to the client. Extensions could do the same, but are out on a distinct abstraction layer provided by a variety of plugins. For Dynamic scripts and UserScripts users will see a distinct boundary, even though there is no such boundary in the back-end. One is for the server-side coder to do things to my client, while the other is a way for me to easily do things to my client. Again, these can be provided by various plugins/extensions. And while I put no sandbox restriction upon the Plugins, that shouldn't be considered to mean that the plugin designer couldn't decide to sandbox their own code. I'd love to see the Shared Media re-factored into a plugin that provides a sandboxed environment for connecting to and displaying the media. One big point there is that with these different layers of capability, there could exist a free market of competing Plugins, competing Extensions, Dynamic scripts providing more engaging interaction while reducing server load, and easy customizability with UserScripts. Each has its purpose, and each has its userbase. I know my dad, who is a fairly good scripter, would not be interested in writing a plugin or extension, but would love to be able to write dynamic client scripts. I'd love to have the opportunity to dig as deep as I'd like in the code, but to be able to start in a much cleaner environment, such as implementing a plugin, or even easier, an extension. They would be much cleaner to build than a patch, and easier to distribute! Ricky On Sun, Mar 7, 2010 at 6:20 AM, Carlo Wood wrote: > On Sat, Mar 06, 2010 at 11:19:43PM -0800, Ricky wrote: > > Client Plugins > > Ok, although I'd prefer if-- for example-- media plugins run in a sandbox; > think about the recent mention of the quicktime exploit. > > > Client Extensions - Interpreted code packages placed in a special folder > in the > > client directory by the user/admin of the client's installation. > > These should run in a broad sandbox: Limited local disk access (max > datastore > > size, etc.) to a special file in the local user folder. Eg: > ~/.secondlife/ > > slfirst_lastname/extensions/extensionname.eds (Extension DataStore) But > can > > still access much the same client hooks as the Plugins. > > Provides fast prototyping, and lower entry difficulty, than Plugins, but > will > > most likely not have the freedom to tap into a lot of system stuff. Also > will > > not typically run as fast or in as little memory space as the binary > plugins. > > > Dynamic Client Scripts - Interpreted scripts loaded from the server via > the > > server-side permissions system. > > Since this and Client Extensions are both interpreted code, these are > basically the same-- just with different permissions. I don't think we > should at this point make a difference between scripts based on their > source or permissions, but only based on their implementation layer. > > > May still need a better name... > > Could be stored in Notecards and a server-side script could petition, > via > > llRequestPermissions, to be able to request that the client download the > > notecard named via a llLoadClientScript(string name, integer
Re: [opensource-dev] The Faces Of Client-Side Code
I agree 100%. Yet, as this topic is about the different faces of client code, having the terms well-defined will help in the future. We are both agreed that there are sandboxed and non-sandboxed parts, and each has it's purpose. I just wanted to establish common terms, with some generic examples, so that we can further discuss how to implement each piece in another topic. But on the topic of sandboxing, I believe that some local storage could be allowed and still have a sandbox. The plugin implementor would create a special file in the profile directory that creates a virtual filesystem that has constraints such as limited total size and limited I/O per unit time, and would then limit all file I/O calls to it. But that is plugin design, which is orthogonal to what I believe the next discussion should be of how to design the plugin system. I'll post in just a few on that topic. I like how this discussion has progressed. Ricky On Sun, Mar 7, 2010 at 12:16 PM, Morgaine wrote: > User perceptions are completely orthogonal to the engineering issues here > though, Ricky. We could certainly make all use cases look entirely uniform > from a user perspective if we wanted to, but we don't advocate that because > the security and responsibility issues are so different in the two (and only > two) cases. > > This is why we separate this area into wholly sandboxed and wholly > non-sandboxed parts. > > The non-sandboxed "viewer extensions" are always "run at your own risk". > They are acknowledged to be inherently dangerous because they are powerful, > just like every other native platform executable. You bear the full and > explicit responsibility of deciding whether to trust them or not when you > install them or accept them, and this applies regardless of how > transparently they arrived and/or are installed (eg. Firefox add-ons are > fairly transparent). And just as with any other executable that you > download off the net and choose to execute, if the program sells your spouse > and kids into slavery and exchanges your house for 500 Britney Spears > albums, the responsibility for having misplaced your trust is yours and > nobody else's. > > In contrast, sandboxed programs would implement "world extensions" within > the viewer without needing to touch local PC facilities. Because they don't > need local access they can easily be sandboxed with a good degree of > confidence in the strength of the sandbox walls, *bugs and exploits > excepted*. To some extent (but not fully), this means that trust in > sandboxed code can be assigned automatically by those who do not possess a > well developed sense of risk and of program frailty, nor an awareness of > programmer fallibility and human malevolence. It also means that if the > designers of the sandbox imply that it is strong and that your trust can be > given automatically to sandboxed scripts, then you might well have recourse > against them when your 500 Britney Spears albums arrive. > > In practice, these two categories are hugely different in human impact, > even if implemented using common infrastructure plus an optional sandbox. > Of course it's possible to find subclasses within each of them and it's > possible to find commonality between them, but this serves little purpose, > and if it obscures the risk differences then it becomes highly dangerous. > > > Morgaine. > > > > > === > > On Sun, Mar 7, 2010 at 5:09 PM, Ricky wrote: > >> Carlo, both you and Morgain make very good arguments as to why various >> parts I separated are, technically, the same. However, while I understand >> that Dynamic Scripts (loaded from serverside) and UserScripts are completely >> the same thing (just like in a browser, the JavaScript loaded from >> the server-side alongside the web page, and GreaseMonkey UserScripts are >> both just seperate views of the same thing,) they are made distinct in >> the terminology here due to the fact that a user will see a difference. >> >> I also understand how you would see the Extensions and Plugins as also >> being nothing but the same thing. Setting up an IPC layer in the C++ is >> absolutely required, but I don't think that we need to put /multiple/ ways >> of connecting plugins into the code hooks. I'd prefer the most direct >> method of using a form of dynamically loaded shared library that implements >> a common object Interface that the client then calls. This provides the >> most direct, most capable interface. It is also not very abstract, as the >> underlying code could easily change in such a way as to break the interface, >> but that is a common enough pr
[opensource-dev] Client Plugin System Design
So far, barring any LL concepts, we have (as far as I know so far!) two designs of plugin system: 1: Socket-based plugins - as suggested by Morgaine. 2: D-Bus or similar existing IPC tool. 3: C++ Dynamically Shared Objects - my suggestion. Morgaine's design has a couple advantages that I can think of: Namely, a distinct lawyer-approved separation of code allowing the plugins to be released under different licenses, and a fairly stable target to design around, meaning the socket API wouldn't typically change a lot across releases, plugins also could be built into other external packages that interface with the socket API to provide massive amounts of integration. However, it's disadvantages come along: Networking code in every plugin just to connect to the client, separate processes that have to be launched by something - presumably the client code, but not always... I'm not too sure about the D-Bus design, there hasn't been much discussion, other than it seems a lot like Morgaine's suggestion to me, just an available existent re-usable tool. That can be a good thing, as we wouldn't have to worry about the protocol, it would be already done. The last option is one I've seen references to across the 'net. All that would be written in the client software is one or more Interface Objects (those familiar with polymorphic design are very familiar with these,) and then a list or two of these for different tasks. For instance, one list could be for those that have registered themselves as Dynamic Script interpreters. These Interfaces would then be implemented by all plugins, depending on what tasks the plugin was spec'd to handle. Plugins would then be located in the plugins directory in the main install, and/or in a plugins directory under each profile. They would be loaded automatically upon startup of the client, and their functions would be called upon event. The event could be as simple as the last step in the render/update loops, or as detailed as when the user clicks or touches a keyboard button. They also are given access to various commands they can call in the client. The more the merrier. The advantages are that these marry right up to the client giving full-speed access, along with the ability to get into the nitty-gritty of the client's underpinnings. Also an easier way to code for a lot of programmers (like myself) who, while having a passing familiarity with networking code, are not terribly interested in writing plugins as clients to the client Disadvantages are a potential lock-in to the client's license, although I'm not sure about that, and the API could be easily changed while patching some other part of the client code. Each has it's pro's and con's. And my listing of such is by no means comprehensive! I want to see this hashed out and the best over-all design get implemented: Client capabilities would soar fast, and be done in a very modular way improving SL massively. 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
Re: [opensource-dev] New topic: Snowglobe 2.0 way forward?
On the subject, I WANT the silver theme BACK. I'm severely annoyed that we had to take a step backward into only having a single theme without selection. With the silver theme I could actually read the text on my screen, and was one of the first things I changed when getting a new viewer. Themes need to be selectable, and the current theme is even darker than the old dark and dull theme! Now, on a more reasonable tone, I am actually in favor of the sidebar's "squishing" of the screen. Although I would like to be able to _optionally_ dock floaters in and out, ala VWR-17013. The "squishing" is a lot better than sliding over the screen cutting off the right 3 inches of my render area, hiding HUDs, etc. And power users know how to use the Debug Settings to deactivate features they don't want to see: Like the silly walk and camera mouse controls. Why do I need a 4th way to move my character? (1: AWSD, 2: Arrow Keys, 3: Click-and-drag on the avvie, 4: floater controls) I've been scripting since my 2nd day in SL, over 3 years ago. Not as long as many on this list, and only a month younger than you, Henri, although I don't yet have the skill you have in reworking the client. I'm just saying that not all of us of this SL age are against all the changes. Some of them need serious refinement, and for those who don't like the way LL is guiding the mainline viewer, that why we have good coders like you capable of create TPVs for those who want something different. Ricky Cron Stardust On Wed, Mar 10, 2010 at 4:49 PM, Henri Beauchamp wrote: > On Wed, 10 Mar 2010 12:13:23 -0600, Argent Stonecutter wrote: > > > On 2010-03-10, at 11:48, Tigro Spottystripes wrote: > > > IMO the 2.0 interface looks way more like a "developer's interface" > > > than 1.*'s > > > > Which brings this thread back onto topic for this list. :) > > > > I agree. The browser has become a familiar interface, but it was > > largely developed by developers for developers, and for an application > > things like the address bar and bookmarks and sidebars are distracting > > and divert attention from the content (the page you're viewing, or the > > world your avatar is in). Which is why web applications are allowed to > > remove those decorations when creating a new window. > > > > The 2.0 interface looks like something a web developer would like to > > use, not something someone IN SL needs. The address bar, toolbar, side > > panel, and all the new highly decorated chat boxes and message boxes > > should at the very least be made optional. > > Here is my take on v2.0. It is an extract of a message I wrote in reply > to Nyx Linden yesterday, but since there's nothing secret or private in > it, here you go: > > NL> Any specific feedback on how we can tweak the 2.0 viewer to get it > NL> to an acceptable state for power users would be appreciated! > > I already took the survey. Basically, the whole new UI is a nightmare > for the old timer, the power user, and the role-player (and since I > "play" in the three categories, it's the worst kind of nightmare as > far as I am concerned: to be frank, I *refuse* to use v2.0 as it is > and should I be forced to use it, I'd quit SL immediately !). > > Old timers have to relearn everything and waste their time adapting > their "muscle memory" to the new UI (when at all possible, see below > about the pie menu), while if you provided them with an old-style > skin/UI it would make it so much simpler for them to migrate to v2.0... > > Power users miss the ability to freely open and move floaters around, > arranging their layout and size as *they* want it to be. > In this respect, the side bar is *catastrophic* as it imposes a single > layout, eats up an enormous amount of screen space when open and is not > resizable at all (forcing you to close it to actually enjoy the view, > while, for example, a friends floater could be left open all the time > on v1.xx without impairing the 3D world view), and can only display > the equivalent of *one* floater (and even half a floater given how much > fewer info is available at a glance without having to click again to get > the info which was presented in v1.23 floater: the friends list is > *horrible* in this repect: can't see or change the rights without > clicking three more times, and this for each friend !). > > Role-players *scream* at the ridiculously small chat input line, at > the enormous, non-transparent chat console, at the needless, impossible > to hide voice button (role-players don't use voice !) and at the real > life tab forced under their nose when they look at an *avatar* profile > (everything that
Re: [opensource-dev] Fixing the 2.0 chat bar focus problem?
I tend to use both wasdec and the arrow keys+pg up/dwn. Depends on what I'm doing. I remember fighting the chat bar all the time in SG1.3, where it kept stealing focus and getting filled with wwwasssswwee... etc. while I was trying to pilot my vehicles I was scripting and while I was occasionally chatting (when my voice wan't working) with my group of testers. Having the chatbar always taking focus would be just as much a disaster for me as it seems it is for you to have it releasing focus so much... Although, for me it seems to be perfect the way it is, as I haven't been fighting it in 2.0: it seems to work the way my mind expects it to. If there seems to be an issue, then it sounds like a debug setting is in order. If enough people seem interested, that can be later exposed in the UI somewhere. Ricky Cron Stardust On Tue, Mar 16, 2010 at 4:21 PM, Glen Canaday wrote: > Maybe it's *my* bias. I personally know of no gamers who'd use wasd who > have stayed in SL longer than a couple of months at best. > > Most of the people I have known in SL shop, go to clubs, create, RP, and > hang out, most of which requires chatting without an extra step to > switch focus. Leaving the chat bar with focus kills wasd movement, but I > can name no one who doesn't use the arrow keys for that. > > Survey? > > On 03/16/2010 07:10 PM, Tigro Spottystripes wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > that's new to me... > > > > perhaps my sample is biased due to me hanging around people with similar > > interests (i do like to play computer/video games) > > > > On 16/3/2010 19:41, Glen Canaday wrote: > > > >> That's an annoyance I'd like to specifically target in snowglobe 2. The > >> majority of resis in SL were never gamers so never got used to wasd > >> movement. > >> > >> --GC > >> > >> On 03/16/2010 03:42 PM, Argent Stonecutter wrote: > >> > >>> OK, here's a design problem in the new viewer that maybe can be > >>> figured out here. > >>> > >>>From the Jira, I missed this response to one of my comments, some > >>> time ago. Apologies, I forgot to "watch" the item: > >>> > >>>From Q Linden: > >>> > >>> > >>>> Argent: the focus problem differs this time because the chat bar is > >>>> always present; we have no mechanism to make it go away, so if we > >>>> always gave it focus it would block normal keyboard use. Personally, > >>>> I'm an AWSD movement person, so I actually find this works really > >>>> well for me. It's not quite as obviously wrong as you seem to think. > >>>> However, I understand the use case and we'll talk about it internally. > >>>> > >>>> > >>> This is exactly the same problem that we had the last two times. This > >>> is exactly the same discussion we had the last two times. There are > >>> many many people who never use any of the keyboard accelerators in SL, > >>> and always have the chat bar up and in focus. The chat bar focus NEVER > >>> goes away. For us, normal keyboard use does not involve anything the > >>> chat bar blocks. > >>> > >>> So, how could this be fixed in the 2.0 viewer without causing > >>> discombobulation? > >>> > >>> An option "chat bar is the default focus"? > >>> > >>> What would that actually break? > >>> ___ > >>> 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 > >> > >> > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v2.0.12 (MingW32) > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > > > iEYEARECAAYFAkugD9sACgkQ8ZFfSrFHsmWe2ACfWXcGjN7TjfQ1jDslHQa4Pav1 > > kLsAn3I6rUdVhWj1hZaGQk7fzZ0dOE4V > > =0jWI > > -END PGP SIGNATURE- > > ___ > > 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
