Re: [opensource-dev] simconsole is available for experimentation

[Opensource Obscure]

On Mon, 11 Oct 2010 16:03:22 -0700, Andrew Meadows
 wrote:

> To open the console type:  CTRL + SHIFT + `  (CTRL + SHIFT + backtick)

this sounds awesome! :))

sorry to be picky about suck a trivial detail - in future releases,
could you 
please change the shortcut  to something I can type on my non-US
keyboards?

Backtick is not available on Italian keyboards, and I suspect this is
true for
other keyboard layouts as well.

CTRL + SHIFT + J is available, as well as CTRL + SHIFT + U,
and they're universal.

Opensource Obscure
___
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] Translate hotkey?

[Opensource Obscure]

On Mon, 11 Oct 2010 16:26:13 -0700 (PDT), miss c 
wrote:
> Is there a translate hotkey, command or setting in the viewer that will 
> translate note cards into your viewer language?

AFAIK no (not yet?) - the only translation system used in official
viewers 
is about realtime translation of chat.

Opensource Obscure
___
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] tos acceptance issues

[Opensource Obscure]

Hi Erin

I'm sure you realize yourself that LL may not be going to work 
on that, if they don't have detailed jiras and precise direct links 
to those jiras.

I could look for those jiras myself, then post the answer to the list, 
I'm not affected by this issue and my time is limited, so I'm going
to pay attention to other bugs. Hopefully someone more directly 
concerned by this issue will do that. 
That's what I'd suggest you to do, by the way.

Opensource Obscure

On Mon, 11 Oct 2010 20:34:41 -0400, Erin Mallory
 wrote:
> theres already jiras about it yes. I do not have the numbers on hand,
> though i think somone else might have already mentioned the jira
> numbers.
> 
>> From: akanev...@productengine.com
>> Date: Mon, 11 Oct 2010 15:57:22 -0700
>> Subject: Re: [opensource-dev] tos acceptance issues
>> To: angel_of_crim...@hotmail.com
>> CC: opensource-dev@lists.secondlife.com
>>
>> Erin,
>> Is there a JIRA that details which builds and which versions of 2.x
>> presented this problem? Repro steps? Which accounts were and were not
>> allowed to accept TOS?
>>
>> Thank you,
>> Anya
>>
>> 2010/10/8 Erin Mallory :
>> > As a user, it would be nice if the 2.x versions of SL would allow ALL
>> > accounts to accept the new terms of service instead of denying that option
>> > to all/some of them.
>> > Depending on the build, some versions of 2.x do not allow any accounts to
>> > accept tos even after cancel and reattempt.  Some allow only some accounts
>> > to do so.  this is like the third time this bug has resurfaced.  can we
>> > please fix it so everyone can log 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

[opensource-dev] LLTextbox ETA?

[miss c]

Is there an ETA on when LLTextbox will work in the official viewer?  It only 
works in the Phoenix viewer.

Thank you

Miss



  ___
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] LLTextbox ETA?

[WolfPup Lowenhar]

Here is the relevant LL jira:

 

https://jira.secondlife.com/browse/STORM-138

 

There you can see that the work has been done for the most part there it
just needs to go through the final steps.

 

From: opensource-dev-boun...@lists.secondlife.com
[mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of miss c
Sent: Tuesday, October 12, 2010 4:07 AM
To: opensource-dev@lists.secondlife.com
Subject: [opensource-dev] LLTextbox ETA?

 

Is there an ETA on when LLTextbox will work in the official viewer?  It only
works in the Phoenix viewer.

Thank you

Miss

 

  _  

No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1136 / Virus Database: 422/3191 - Release Date: 10/11/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

[opensource-dev] Don't fork Beta

[Oz Linden (Scott Lawrence)]

  Unless you are working on an issue that has already specifically been 
marked to be fixed in Beta, please don't use a clone of the viewer-beta 
branch; doing so makes it more difficult to cleanly pull your changes 
into viewer-development.

___
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] Oz office hour change...

[Oz Linden (Scott Lawrence)]

  I've moved my Monday office hour back (earlier) by a half hour - it's 
now 07:00-08:00.

The wiki calendar links and feeds have been updated.

___
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] simconsole is available for experimentation

[Henri Beauchamp]

I was curious about this new feature, but since I'm not using viewer 2
I just bacported it...

You'll find attached to this message a patch which is a backport of the
sim console to v1.23.5 (will also work with Snowglobe v1: there's one
reject in CMakeList.txt but you can ignore it safely since it deals
with the list of XML UI files which doesn't exist any more in SG1's
CMakeList.txt file).

The floater was also made resizable and the shortcut was changed
to CTRL SHIFT C. The menu entry for opening the console is in
Advanced -> Consoles.

Note that for now, this feature seems pretty useless (only one variable
available and you can't even change it). Type "help" in the console to
get the list of commands and variables from the server.

Henri.

On Mon, 11 Oct 2010 16:03:22 -0700, Andrew Meadows wrote:

> As mentioned in my office hours, and Oskar Linden's office hours last
> week:
> 
> Thanks to Brad and Falcon Linden the SL simulator will soon support a
> very simple command line interface (CLI) console we're calling "simconsole".
> The motivation for it was primarily for debug and prototyping, and
> the list of commands available is currently very short, but we'll add
> some more soon and maybe it will become a useful tool for intrepid
> Residents.
> 
> The simulator support is currently on the beta grid (aditi).  It was just
> promoted to the "Second Life Beta Server" channel today so is on most of
> the regions there.  It was previously on just four regions using the
> "andrew-maint-server" channel.
> 
> In order to play around with the simconsole you need viewer UI support.
> I've just created a bitbucket clone of lindenlab/viewer-development with
> the simconsole UI added for those who want to build and play around with
> it.  Clone or pull from here:
> 
> http://bitbucket.org/andrew_linden/viewer-development
> 
> To open the console type:  CTRL + SHIFT + `  (CTRL + SHIFT + backtick)
> 
> I think there is a "help" command, but otherwise there isn't any
> documentation yet.
> 
> You'll have to be an LL admin or estate manager to run any of the
> commands that change anything.
> 
> - Andrew


slviewer-0-v12350-FloaterSimConsole.patch.bz2
Description: Binary data
___
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] Missing capabilities.

[Henri Beauchamp]

Hello,

There are, in my opinion, missing capabilities for the new viewer 2
features, namely the capabilities dealing with inventory item links
support, multiple attachments per point support, and multiple clothing
layers support.

Without the correpsonding capabilities, it is impossible for the viewer
to adapt its sets of tools to the servers in OpenSim grids. Of course,
I could just make the assumption that these features are only available
in SL and then disable them for OpenSim, but I'm pretty sure they will
appear in the latter, sooner or later...

So, either LL implements the corresponding new capabilities in their
server (and future viewer versions), or we would need OpenSim server
developpers to "reserve" the capabilities (so that the viewer developpers
may simply test for either the SL grids or the presence of the
capabilities to decide whether the corresponding features should be
enabled or not after login).

It's also a bit worrying to see that LL doesn't seem to care much any
more about backward compatibility (and therefore about OpenSim
compatibility)...

Any thought on this ?

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

Re: [opensource-dev] Missing capabilities.

[Kelly Linden]

I'm confused on this. While the term 'capability' is a bit vague, in SL
development / programming it is very specific. It is not a flag that
indicates the availability of a feature - it is an access point to access
features. It has the great side benefit of being able to indicate the
availability of those features by the presence of the capability. However
not all features are new capabilities.

What I'm getting at is that we shouldn't add dummy capabilities to indicate
the presence of a features that doesn't use a capability. It sounds like we
need some ability to indicate the availability of specific features - either
some feature map or versioning on specific capabilities. If we extended the
ability of an existing capability, perhaps we should have included a version
in some way when we did so. If the feature did not use capabilities (the
inventory is still a mix of legacy, event poll and capabilities isn't it?) -
then perhaps there is another way to determine if the feature is supported.

Or did I misunderstand the problem?

 - Kelly

On Tue, Oct 12, 2010 at 8:25 AM, Henri Beauchamp  wrote:

> Hello,
>
> There are, in my opinion, missing capabilities for the new viewer 2
> features, namely the capabilities dealing with inventory item links
> support, multiple attachments per point support, and multiple clothing
> layers support.
>
> Without the correpsonding capabilities, it is impossible for the viewer
> to adapt its sets of tools to the servers in OpenSim grids. Of course,
> I could just make the assumption that these features are only available
> in SL and then disable them for OpenSim, but I'm pretty sure they will
> appear in the latter, sooner or later...
>
> So, either LL implements the corresponding new capabilities in their
> server (and future viewer versions), or we would need OpenSim server
> developpers to "reserve" the capabilities (so that the viewer developpers
> may simply test for either the SL grids or the presence of the
> capabilities to decide whether the corresponding features should be
> enabled or not after login).
>
> It's also a bit worrying to see that LL doesn't seem to care much any
> more about backward compatibility (and therefore about OpenSim
> compatibility)...
>
> Any thought on this ?
>
> 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] Missing capabilities.

[Henri Beauchamp]

On Tue, 12 Oct 2010 08:37:42 -0700, Kelly Linden wrote:

> I'm confused on this. While the term 'capability' is a bit vague, in SL
> development / programming it is very specific. It is not a flag that
> indicates the availability of a feature - it is an access point to access
> features. It has the great side benefit of being able to indicate the
> availability of those features by the presence of the capability. However
> not all features are new capabilities.
> 
> What I'm getting at is that we shouldn't add dummy capabilities to indicate
> the presence of a features that doesn't use a capability. It sounds like we
> need some ability to indicate the availability of specific features - either
> some feature map or versioning on specific capabilities. If we extended the
> ability of an existing capability, perhaps we should have included a version
> in some way when we did so. If the feature did not use capabilities (the
> inventory is still a mix of legacy, event poll and capabilities isn't it?) -
> then perhaps there is another way to determine if the feature is supported.

Be it by a "fake" capabilty (in the SL acception of the term) returning
(for example) a simple "true" string, or by another mean (a map of flags
returned by a new server message ?... But then we'd need to know if that
server message is supported or not on the grid we connect to...), there
is indeed a need for the viewer to know whether or not the servers (and
this includes the assets server in the particular case of inventory links)
can or cannot support the new features.

The failure to know this and to take it into account in the viewer is one
of the reasons why viewer 2 is incompatible with OpenSim grids (other
reasons being viewer 2's inability to use asset server tiles for the
world map, or hard coded URLs in the code, for example).

So, yes, something should be done to correct this problem.

Another nice thing to have would be to be able to determine on login
whether the viewer connects to SL or to an OpenSim grid, since with the
TPV policy and the differences between the existing grids TOS, the viewer
may or may not use some features depending on the grid it connects to (so
far I detect SL grids based on their URI (IP or plain text URI), but this
is not as reliable as a returned value from the grid servers would be).

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

Re: [opensource-dev] simconsole is available for experimentation

[Matthew (Falcon) Breindel]

Hi Opensource,

The console is also available under the 'Develop' menu (ctrl+alt+Q). It
seems to keep moving around, but in the build I'm looking at it's under
Develop | Network | Region Debug Console. In other builds I think it's in
Develop | Consoles | Region Debug Console.

I'll look into changing the shortcut anyway, though.

Cheers,
Falcon

On Tue, Oct 12, 2010 at 12:43 AM, Opensource Obscure wrote:

> On Mon, 11 Oct 2010 16:03:22 -0700, Andrew Meadows
>  wrote:
>
> > To open the console type:  CTRL + SHIFT + `  (CTRL + SHIFT + backtick)
>
> this sounds awesome! :))
>
> sorry to be picky about suck a trivial detail - in future releases,
> could you
> please change the shortcut  to something I can type on my non-US
> keyboards?
>
> Backtick is not available on Italian keyboards, and I suspect this is
> true for
> other keyboard layouts as well.
>
> CTRL + SHIFT + J is available, as well as CTRL + SHIFT + U,
> and they're universal.
>
> Opensource Obscure
>
___
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] Daily Scrum Summary - Tuesday, Oct 12

[Anya Kanevsky]

Date: Tue Oct 12

== GENERAL NOTES ==
* Merge Monkey of the Day:  Merov ... again
* Beta fixes should be done on a beta branch
* With rare exceptions when we need to stabilize and release a beta,
beta fixes should merged into Beta asap.

== DAILY SCRUM ==

=== Merov ===
PAST
* STORM-365 (né SH-277) "Attachments are visible in mouselook mode" :
Took that one on, created patch, got it reviewed by davep, merged into
beta
* STORM-137: Got code review and tweaks from Techwolf. Merged in my
dev branch. Builds on TC. Testing that on Linux and Windows before
calling it done.
* Merge monkeying on viewer-beta

FUTURE
* STORM-137: Test and ask for review (again) before integration (in v-d)
* Beta monitoring and merge monkey-ing (merges, try to identify bugs I
can contribute to)
* OH
* STORM-105 : Perf decompression: put new data out, check the work
done by opensource-dev community on similar tests.
* STORM-104: kdu upgrade

IMPEDIMENTS
* None


==Oz Linden==
PAST
* Proposed budget for open build service & code review system
* Even more process review...
* Pulled together lots of build changes, built and tested viewers

FUTURE
* Start updating develop.secondlife.com
* Get the build fixes checked in to viewer-development

IMPEDIMENTS
* none


=== Q Linden===
PAST
* HR (annual reviews) - finally done
* Process work and long meetings
* Accessibility meeting

FUTURE
* 2.2 Release
* Unit test working

IMPEDIMENTS
* Antialiasing bug? (This is probably resolved - we need to get it to
viewer-development)


=== Esbee Linden
PAST
* Viewer release process review
* VWR triage
* Systems requirements research
* Accessibility meeting

FUTURE
* VWR triage
* Discuss status of next beta release w/Q
* Systems requirements analysis
* Viewer 2.2 Release

IMPEDIMENTS
* None


=== Paul ProductEngine===
PAST:
* STORM-211 Fade timer is reset for all toasts displayed in the
notifications channel
** Today while testing found one case in which behavior is wrong.
Investigating. Estimate ~ 4 hours.

FUTURE:
* STORM-211 Fade timer is reset for all toasts displayed in the
notifications channel

IMPEDIMENTS:
* none

=== Seth Productengine ===
PAST:
* BUG (STORM-294) Selection goes out of Favorites overflow list if
scroll it by keyboard
** WIP. Currently fixed for only one scrolling direction.

FUTURE:
* BUG (STORM-294) Selection goes out of Favorites overflow list if
scroll it by keyboard
** Estimated: 2-3 hours.

IMPEDIMENTS:
* none

=== Andrew Productengine ===
PAST:
* Critical bug STORM-310 (crash after setting sound preferences)
** Tested on different builds and closed as cannot reproduce.
* Bug  STORM-301 (Camera view remains on Edit Appearance mode after
undocked 'My Appearance' tab was minimized while being in 'Edit
Outfit' mode)
** Fixed and sent for review.

FUTURE:
* STORM-362 ([HARD CODED] ALL LANGS: Unlocalized keyboard keys under
Advanced menu > Shortcuts (French viewer)).

IMPEDIMENTS:
* none

=== Vadim Productengine ===
PAST:
* Bug STORM-298 (My Landmarks panel scrolls down while deleting a
landmark from Favorites bar):
** Fixed.

FUTURE:
* Bug STORM-290 (Home SP is white and does not contain any information
after clearing Viewer settings on PC)
** ETA 3h.
* Subtasks of STORM-304 (disable URL higlighting in various places) -- ETA 4h
** STORM-358 (... in the nearby chat toasts)
** STORM-359 (... in the llGiveInventory dlg)
** STORM-360 (... in Message Well window)

IMPEDIMENTS:
* none

=== Andrey Productengine ===

=== Grumpity ===
PAST
* crashhunters
* viewer release process
* QA synch notes & followup
* Split STORM-315 (Changes to environment editor) into 3 new issues in VWR

FUTURE:
* ooo 11am - 1pm
* STORM-313 (pending Esbee's office hour wednesday)
* STORM-182 (Uninstaling beta deletes logs) - needs a home
* STORM-316 (inventory debug settings)

IMPEDIMENTS:
* none
___
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] Broken Rubber Bands

[Kelly Linden]

If anyone is interested his code is here:
http://bitbucket.org/simon_linden/viewer-dev

cc'ing the opensource-dev list as this seems appropriate for that list at
this point.

 - Kelly

On Tue, Oct 12, 2010 at 8:27 AM, Kelly Linden  wrote:

> Actually one of my coworkers has been working on some features along these
> lines. The two parts I'm aware of prevent flying into the horizon if there
> is no neighbor sim and some attenuation of movement if it has been too long
> since getting an update from the sim. He was also working on some region
> crossing specific bits to try and improve the prediction logic and reduce
> rubber banding, however he was getting mixed results on that front.
>
> I've forwarded him your email just so he has another data point, and I'll
> see if I can't find his repo to share should anyone want to give his patches
> a try.
>
>  - Kelly
>
> On Tue, Oct 12, 2010 at 7:35 AM, annma...@slfbi.com wrote:
>
>>  Border crossing rubber-banding, especially when riding a vehicle, can
>> vary from zero to annoying to purgatory to re-boot depending on the
>> severity.
>> My current SLURL is sim Sunell, <60902, 26106???, -136289?> which
>> puts me at least 13 billion meters below ground on my way to SL hell.
>> It will require a re-log to recover.
>>
>> DUH.  The client side viewer would not have to be very smart to figure
>> out something was wrong and discontinue stretching a rubber band that is
>> obviously broken.
>>
>> Why cannot the viewer and server have a simple uplink command that says
>> "I'm totally lost, please put me back at the last known vector"?  It
>> could even have a popup to explain you have been restored to an earlier
>> valid location.
>>
>> ___
>> Click here to unsubscribe or manage your list subscription:
>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
>>
>
>
___
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] Broken Rubber Bands

[Simon Linden]

Hi -

Yes, I updated that repository with my first attempt at improving the viewer
prediction code.   The changes are:

* Configurable settings for tapering off viewer-side motion prediction
* Limit predicted motion at region edges based on adjacent regions
* Bug fixes around region crossing timers and object positions

I just spent some time looking into the server code, however, and see that
the viewer needs more refinement.

The server expects the viewer motion prediction code to follow the velocity
and acceleration it sent to the viewer, so my new taper-off code should not
kick in unless the simulator stops sending updates (which would indicate a
bad lag event, rather than no updates due to constant motion).

Some of my changes should help, however.  The viewer will check the edge of
the region, and if there is no neighbor region, stops the object motion.
Normally the simulator will send down another update quickly as the object
bounces off the edge, but this prevents the sail-into-the-sunset effect when
the simulator lags badly.   Predicted object motion is also pinned to the
allowable underground distance and top of the region.

I did some experiments with region crossings and attempts to predict some
lag but didn't find a solution that worked well.As AnnMarie mentioned,
vehicle crossings seem to be the worst and I'll be looking into that next.
The viewer can probably be more intelligent on how it predicts region
crossings, perhaps allowing for a bit of lag with normal objects and
possibly accounting for the re-seating of AVs on vehicles, but I haven't
worked out the details yet.

 - Simon Linden




On Tue, Oct 12, 2010 at 2:06 PM, Kelly Linden  wrote:

> If anyone is interested his code is here:
> http://bitbucket.org/simon_linden/viewer-dev
>
> cc'ing the opensource-dev list as this seems appropriate for that list at
> this point.
>
>  - Kelly
>
> On Tue, Oct 12, 2010 at 8:27 AM, Kelly Linden  wrote:
>
>> Actually one of my coworkers has been working on some features along these
>> lines. The two parts I'm aware of prevent flying into the horizon if there
>> is no neighbor sim and some attenuation of movement if it has been too long
>> since getting an update from the sim. He was also working on some region
>> crossing specific bits to try and improve the prediction logic and reduce
>> rubber banding, however he was getting mixed results on that front.
>>
>> I've forwarded him your email just so he has another data point, and I'll
>> see if I can't find his repo to share should anyone want to give his patches
>> a try.
>>
>>  - Kelly
>>
>>  On Tue, Oct 12, 2010 at 7:35 AM, annma...@slfbi.com 
>> wrote:
>>
>>>   Border crossing rubber-banding, especially when riding a vehicle, can
>>> vary from zero to annoying to purgatory to re-boot depending on the
>>> severity.
>>> My current SLURL is sim Sunell, <60902, 26106???, -136289?> which
>>> puts me at least 13 billion meters below ground on my way to SL hell.
>>> It will require a re-log to recover.
>>>
>>> DUH.  The client side viewer would not have to be very smart to figure
>>> out something was wrong and discontinue stretching a rubber band that is
>>> obviously broken.
>>>
>>> Why cannot the viewer and server have a simple uplink command that says
>>> "I'm totally lost, please put me back at the last known vector"?  It
>>> could even have a popup to explain you have been restored to an earlier
>>> valid location.
>>>
>>
___
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] Broken Rubber Bands

[Dale Innis]

On Tue, Oct 12, 2010 at 5:38 PM, Simon Linden  wrote:

> Some of my changes should help, however.  The viewer will check the edge of
> the region, and if there is no neighbor region, stops the object motion.

>  Predicted object motion is also pinned to the
> allowable underground distance and top of the region.

These will be major, and very welcome, changes to the SL experience!

(Not to mention giving us oldbies one more class of "In my day..."
stories to tell...)
___
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] Broken Rubber Bands

[Dahlia Trimble]

Could checking to see if a user is still pressing a movement key fit into
the algorithm? It seems it could be a useful input to help determine if the
user really wants to continue along a dead-reckoning path.

On Tue, Oct 12, 2010 at 2:51 PM, Dale Innis wrote:

> On Tue, Oct 12, 2010 at 5:38 PM, Simon Linden  wrote:
>
> > Some of my changes should help, however.  The viewer will check the edge
> of
> > the region, and if there is no neighbor region, stops the object motion.
>
> >  Predicted object motion is also pinned to the
> > allowable underground distance and top of the region.
>
> These will be major, and very welcome, changes to the SL experience!
>
> (Not to mention giving us oldbies one more class of "In my day..."
> stories to tell...)
> ___
> 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] quick smoke test (was: Remaining build issues for 64bit linux standalone out-of-source (without unit tests))

[Boroondas Gupte]

 On 10/11/2010 07:04 PM, Oz Linden (Scott Lawrence) wrote:
> On 2010-10-06 18:41, Boroondas Gupte wrote:
>> [...]
>>
>> VWR-23047  (aka
>> SNOW-512 / SNOW-287): PIC required for standalone
>> [...]
>> STORM-222 : expat.h not
>> found on STANDALONE
>> [...]
>> VWR-23296 : missing
>> LL_TEST conditions (i.e. SNOW-651
>>  *+* SNOW-654
>> )
>> [...]
>> STORM-275  (a.k.a.
>> VWR-20893): "class Linux_x86_64Manifest" missing from
>> viewer_manifest.py Breaking linux 64-bit build.
>> [...]
>
> I've posted a build made with all of the above except VWR-23296
> (global switch to disable tests - see my other reply to this thread) at:
> http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_viewer-review1/rev/211764/index.html
>
> All platforms built, and since that's what these changes were about
> it's probably good.  The Mac version appears to be working fine - if a
> few people could do a quick smoke test of the other platforms and
> report all clear, then I'll push these changes into viewer-development.
Looks good, I guess. While testing I noticed that STORM-312
 / VWR-19643
 (spacenavigator not
working with recent Linux kernels) is still broken in LL builds. But
this isn't related to these changes and affects all other LL builds,
too. LL should upgrade libndofdev on Linux (no code changes needed and
new lib version will work fine with old kernels, too.)

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] Broken Rubber Bands

[Nexii Malthus]

Yeah, that is true. It should be able to detect the very source that causes
most movements. There might be issues on scripts that influence an avatars
movements via control events though, while that could be avoided by checking
if control events have been taken, it might misidentify scripts that take
controls but don't act on physics, such as AOs.

I think the simulator could have a much better prediction system itself as
well, it shouldn't all fall on the client.

For example if an avatar presses forward, the simulator should "jump" the
avatar forwards as if the avatar had pressed forwards back in time by their
average ping time. This would make it appear as if the sim is more
responsive. The client could also then simulate the forwards movement
instantenously.

Modern FPS games have even smarter methods for synchronizing and predicting
physics accurately, such as tracking the recent positions of all players and
then 'correcting' recent collisions based on the players' connections in
realtime.

- Nexii

On Wed, Oct 13, 2010 at 12:29 AM, Dahlia Trimble wrote:

> Could checking to see if a user is still pressing a movement key fit into
> the algorithm? It seems it could be a useful input to help determine if the
> user really wants to continue along a dead-reckoning path.
>
>
> On Tue, Oct 12, 2010 at 2:51 PM, Dale Innis wrote:
>
>> On Tue, Oct 12, 2010 at 5:38 PM, Simon Linden 
>> wrote:
>>
>> > Some of my changes should help, however.  The viewer will check the edge
>> of
>> > the region, and if there is no neighbor region, stops the object motion.
>>
>> >  Predicted object motion is also pinned to the
>> > allowable underground distance and top of the region.
>>
>> These will be major, and very welcome, changes to the SL experience!
>>
>> (Not to mention giving us oldbies one more class of "In my day..."
>> stories to tell...)
>> ___
>> 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] Broken Rubber Bands

[Kelly Linden]

It is true - the server could use improvements and they could both do with
working better together. And this is something we want to do, eventually.

However these specific changes are about addressing some of the worst
offenders - the blatently horrible cases where you fly off into the sunset
because the sim or network hiccups or maybe even prevent you from spiraling
into the ground when you drive across a border.

Lets avoid designing or re-designing full-on client side physics and
movement prediction here, for now. :)

 - Kelly

On Tue, Oct 12, 2010 at 4:46 PM, Nexii Malthus  wrote:

> Yeah, that is true. It should be able to detect the very source that causes
> most movements. There might be issues on scripts that influence an avatars
> movements via control events though, while that could be avoided by checking
> if control events have been taken, it might misidentify scripts that take
> controls but don't act on physics, such as AOs.
>
> I think the simulator could have a much better prediction system itself as
> well, it shouldn't all fall on the client.
>
> For example if an avatar presses forward, the simulator should "jump" the
> avatar forwards as if the avatar had pressed forwards back in time by their
> average ping time. This would make it appear as if the sim is more
> responsive. The client could also then simulate the forwards movement
> instantenously.
>
> Modern FPS games have even smarter methods for synchronizing and predicting
> physics accurately, such as tracking the recent positions of all players and
> then 'correcting' recent collisions based on the players' connections in
> realtime.
>
> - Nexii
>
>
> On Wed, Oct 13, 2010 at 12:29 AM, Dahlia Trimble 
> wrote:
>
>> Could checking to see if a user is still pressing a movement key fit into
>> the algorithm? It seems it could be a useful input to help determine if the
>> user really wants to continue along a dead-reckoning path.
>>
>>
>> On Tue, Oct 12, 2010 at 2:51 PM, Dale Innis wrote:
>>
>>> On Tue, Oct 12, 2010 at 5:38 PM, Simon Linden 
>>> wrote:
>>>
>>> > Some of my changes should help, however.  The viewer will check the
>>> edge of
>>> > the region, and if there is no neighbor region, stops the object
>>> motion.
>>>
>>> >  Predicted object motion is also pinned to the
>>> > allowable underground distance and top of the region.
>>>
>>> These will be major, and very welcome, changes to the SL experience!
>>>
>>> (Not to mention giving us oldbies one more class of "In my day..."
>>> stories to tell...)
>>> ___
>>> 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
>
___
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] LL_TESTS for standalone out-of-source builds (was: Remaining build issues for 64bit linux standalone out-of-source (without unit tests))

[WolfPup Lowenhar]

On the subject of the reason for killing test here is another reason that I
have attached this is from a full build I did today. The error listed in the
file is actually coded around and in visual studio you have to set that test
to not treat warnings as errors so that it will not fail!

 

From: opensource-dev-boun...@lists.secondlife.com
[mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Boroondas
Gupte
Sent: Monday, October 11, 2010 6:10 PM
To: opensource-dev@lists.secondlife.com
Subject: [opensource-dev] LL_TESTS for standalone out-of-source builds (was:
Remaining build issues for 64bit linux standalone out-of-source (without
unit tests))

 

On 10/11/2010 10:12 PM, Boroondas Gupte wrote: 

In fact, my plan for the time after having gotten all build fixes I need
with LL_TESTS set to FALSE into viewer-development (which I hope will be
soon) was to set LL_TESTS back on TRUE and hunt down the change(s) needed to
build like that. (We already had these fixes in Snowglobe 2. I hope nothing
new got broken regarding unit tests, since then.)

Looks like Aleric's
  patch from SNOW-756 (which still applies  :-) ) is all that's
needed, so I moved that to VWR-23385
  and will daggify that fix
ASAP.
With this change, all tests succeed on my machine.


YAY!! \o/


Cheers,
Boroondas

  _  

No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1136 / Virus Database: 422/3191 - Release Date: 10/11/10

ÿþ<html>

<head>

<META HTTP-EQUIV="Content-Type" content="text/html; charset=utf-16">

</head>

<body>

<pre>

<table width=100% bgcolor=#CFCFE5><tr> <td> <font face=arial size=+3>

Build Log

</font></table><table width=* cellspacing=0 cellpadding=0><tr><td width=0 bgcolor=#EDEDF5>&nbsp;</td><td width=0 bgcolor=#FFFFFF>&nbsp;</td><td width=*><pre>

<h3>Rebuild started: Project: INTEGRATION_TEST_m3math, Configuration: Release|Win32</h3>

</pre></table><table width=100% bgcolor=#DFDFE5><tr><td><font face=arial size=+2>

Command Lines

</font></table><table width=* cellspacing=0 cellpadding=0><tr><td width=0 bgcolor=#EDEDF5>&nbsp;</td><td width=0 bgcolor=#FFFFFF>&nbsp;</td><td width=*><pre>Creating temporary file "d:\HG\viewer-development-sandbox\indra\build-vc80\llmath\INTEGRATION_TEST_m3math.dir\Release\BAT0002A15180548.bat" with contents

[

...@echo off


&quot;C:\Program Files\CMake 2.8\bin\cmake.exe&quot; -HD:/HG/viewer-development-sandbox/indra -BD:/HG/viewer-development-sandbox/indra/build-vc80 --check-stamp-file D:\HG\viewer-development-sandbox\indra\build-vc80\llmath\CMakeFiles\generate.stamp


if errorlevel 1 goto VCReportError





if errorlevel 1 goto VCReportError


goto VCEnd


:VCReportError


echo Project : error PRJ0019: A tool returned an error code from &quot;Building Custom Rule D:/HG/viewer-development-sandbox/indra/llmath/CMakeLists.txt&quot;


exit 1


:VCEnd

]

Creating command line """d:\HG\viewer-development-sandbox\indra\build-vc80\llmath\INTEGRATION_TEST_m3math.dir\Release\BAT0002A15180548.bat"""

Creating temporary file "d:\HG\viewer-development-sandbox\indra\build-vc80\llmath\INTEGRATION_TEST_m3math.dir\Release\RSP0002A25180548.rsp" with contents

[

/

[opensource-dev] Local Lights

[Ann Otoole]

When is the last time anyone checked on local lights. I recall that 7 limit was 
removed a ways back and then during a discussion people were still saying there 
was a limit of 7. So I decided to test it.

This is the current LL SLv2 Beta with ultra and everything settable in the UI 
maxed: http://annotoole.com/images/256locallightsonLLbeta.png

This is in Kirstens S20(39) with the lighting on: 
http://annotoole.com/images/256locallightsonkirstensS20%2839%29.png

Yes that is two hundred and fifty six local lights on in that screenshot.

In the SLv2 Beta only 2 local lights worked at all.

Any reason why the capabilities of the LL viewer keep being ratcheted down? 



  ___
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