[opensource-dev] feature suggestion: make "doubleclick navigation" more "immersive"

[Lance Corrimal]

Hi all!

Here's a feature idea that I just had, and I thought I'd float it past here 
before I post a feature request on the jira.

As a user I would like to see a third option for doubleclick navigation 
inworld: "pathfinding - immersive"

With that option turned on, the viewer would determine if the point the user 
clicked on is within draw distance, and if so, use pathfinding "navigate to" 
to walk there. If the point was outside of drawdistance, the viewer would use 
whatever else the user had configured for normal doubleclick navigation (i.e. 
teleporting or "go here").

any thoughts?

I'd believe that would need some server code, so that the viewer could ask the 
server for a list of waypoints to walk from A to B, the user being a character 
type A.


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

Re: [opensource-dev] feature suggestion: make "doubleclick navigation" more "immersive"

[Dahlia Trimble]

If you want to request a server mod, perhaps a mod to the autopilot
functionality to be able to use pathfinding. A potential problem with using
a waypoint list is the path may become obstructed or otherwise modified
while traversing the path.

-d

On Fri, Sep 21, 2012 at 12:17 AM, Lance Corrimal
wrote:

> Hi all!
>
> Here's a feature idea that I just had, and I thought I'd float it past here
> before I post a feature request on the jira.
>
> As a user I would like to see a third option for doubleclick navigation
> inworld: "pathfinding - immersive"
>
> With that option turned on, the viewer would determine if the point the
> user
> clicked on is within draw distance, and if so, use pathfinding "navigate
> to"
> to walk there. If the point was outside of drawdistance, the viewer would
> use
> whatever else the user had configured for normal doubleclick navigation
> (i.e.
> teleporting or "go here").
>
> any thoughts?
>
> I'd believe that would need some server code, so that the viewer could ask
> the
> server for a list of waypoints to walk from A to B, the user being a
> character
> type A.
>
>
> 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] feature suggestion: make "doubleclick navigation" more "immersive"

[Jonathan Welch]

As I recall from some months ago we were told at a PF UG meeting this
idea had been discussed but was thought to be too
confusing/non-intuitive.  Maybe if it were an option there would be
more chance of it being approved.
___
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] feature suggestion: make "doubleclick navigation" more "immersive"

[Argent Stonecutter]

User story: I would love to be able to set waypoints like in Everquest for 
mouse navigation. It's not too confusing, I don't know how many people played 
Everquest but they were all able to figure it out.
___
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] feature suggestion: make "doubleclick navigation" more "immersive"

[Lance Corrimal]

Am Freitag 21 September 2012, 01:24:30 schrieb Dahlia Trimble:
> If you want to request a server mod, perhaps a mod to the autopilot
> functionality to be able to use pathfinding. A potential problem with using
> a waypoint list is the path may become obstructed or otherwise modified
> while traversing the path.


and walking a straight line from A to B withoiut even paying attention to 
obstacles is better?

That is what the viewer does now when you do a "go here" by clicking on the 
ground twice.


bye,
LC

> 
> -d
> 
> On Fri, Sep 21, 2012 at 12:17 AM, Lance Corrimal
> 
> wrote:
> > Hi all!
> > 
> > Here's a feature idea that I just had, and I thought I'd float it past
> > here
> > before I post a feature request on the jira.
> > 
> > As a user I would like to see a third option for doubleclick navigation
> > inworld: "pathfinding - immersive"
> > 
> > With that option turned on, the viewer would determine if the point the
> > user
> > clicked on is within draw distance, and if so, use pathfinding "navigate
> > to"
> > to walk there. If the point was outside of drawdistance, the viewer would
> > use
> > whatever else the user had configured for normal doubleclick navigation
> > (i.e.
> > teleporting or "go here").
> > 
> > any thoughts?
> > 
> > I'd believe that would need some server code, so that the viewer could ask
> > the
> > server for a list of waypoints to walk from A to B, the user being a
> > character
> > type A.
> > 
> > 
> > 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] feature suggestion: make "doubleclick navigation" more "immersive"

[Dahlia Trimble]

I was *not* suggesting using the autopilot as it currently exists. I was
suggesting a newer autopilot-like function provided by the simulator that
can use live pathfinding to move the agent. I was suggesting it because a
waypoint list can become obsolete between the time it's generated and the
time the path is traversed. A *pathfinding capable* autopilot function
could update the waypoint list while in route in case the original path
becomes obstructed.

-d

On Fri, Sep 21, 2012 at 9:32 AM, Lance Corrimal
wrote:

> Am Freitag 21 September 2012, 01:24:30 schrieb Dahlia Trimble:
> > If you want to request a server mod, perhaps a mod to the autopilot
> > functionality to be able to use pathfinding. A potential problem with
> using
> > a waypoint list is the path may become obstructed or otherwise modified
> > while traversing the path.
>
>
> and walking a straight line from A to B withoiut even paying attention to
> obstacles is better?
>
> That is what the viewer does now when you do a "go here" by clicking on the
> ground twice.
>
>
> bye,
> LC
>
> >
> > -d
> >
> > On Fri, Sep 21, 2012 at 12:17 AM, Lance Corrimal
> >
> > wrote:
> > > Hi all!
> > >
> > > Here's a feature idea that I just had, and I thought I'd float it past
> > > here
> > > before I post a feature request on the jira.
> > >
> > > As a user I would like to see a third option for doubleclick navigation
> > > inworld: "pathfinding - immersive"
> > >
> > > With that option turned on, the viewer would determine if the point the
> > > user
> > > clicked on is within draw distance, and if so, use pathfinding
> "navigate
> > > to"
> > > to walk there. If the point was outside of drawdistance, the viewer
> would
> > > use
> > > whatever else the user had configured for normal doubleclick navigation
> > > (i.e.
> > > teleporting or "go here").
> > >
> > > any thoughts?
> > >
> > > I'd believe that would need some server code, so that the viewer could
> ask
> > > the
> > > server for a list of waypoints to walk from A to B, the user being a
> > > character
> > > type A.
> > >
> > >
> > > 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] feature suggestion: make "doubleclick navigation" more "immersive"

[Lance Corrimal]

Am Freitag 21 September 2012, 12:43:29 schrieb Dahlia Trimble:
A *pathfinding capable* autopilot function
> could update the waypoint list while in route in case the original path
> becomes obstructed.

basically, after reaching a waypoint it would request the list of remaining 
waypoints again? that sounds like a good plan.


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

Re: [opensource-dev] Review Request: patch potential memory leak in llgl.h

[Boroondas Gupte]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/603/#review1270
---



indra/llrender/llgl.h


Why did you place two exclamation marks in the comment?

Also, I think "destructor" was actually the correct term while "destroyer" 
isn't.


But as Carlo already mentioned: This explanation would better be placed in the 
commit message than the code. While even experienced programmers might forget 
to write a virtual destructor where needed, we can probably expect them to know 
why it's got to be there when they see one.

If you feel there needs to be an in-code comment anyway, how about something 
short like:
// needed because class has virtual methods

- Boroondas Gupte


On Sept. 20, 2012, 6:15 p.m., Gistya Eusebio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/603/
> ---
> 
> (Updated Sept. 20, 2012, 6:15 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Description
> ---
> 
> In llvertexbuffer.cpp we call: delete mFence;
> 
> mFence is an instance of class LLGLSyncFence which is a sub-class of 
> LLGLFence, which is defined in llgl.h.
> 
> However, class LLGLFence should have a virtual destructor because it's the 
> base class. This patch fixes that potential memory leak, adding a virtual 
> destructor to class LLGLFence. The virtual destructor ensures that the 
> destructor for the derived class also gets called when we call "delete 
> mfence;".
> 
> To quote Björn Pollex, "If you have a class that is supposed to be usable 
> polymorphically, it should also be deletable polymorphically." 
> 
> (Unless I'm missing something...!)
> 
> NOTE: I notice that related code is commented in methods "void 
> LLVertexBuffer::placeFence() const" and "void LLVertexBuffer::waitFence() 
> const" -- maybe we commented it out because this memory leak was unresolved? 
> Perhaps it can be uncommented now? I haven't tried yet. There was no note as 
> to why the code is commented out.
> 
> 
> Diffs
> -
> 
>   indra/llrender/llgl.h UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/603/diff/
> 
> 
> Testing
> ---
> 
> I did compile this with OS X 10.8 as a build target successfully. I made 
> other changes too, so while my FPS seems improved, it could be from any 
> number of issues. I did notice that any llCharacters that are moving around 
> don't get rendered properly by my build, but I don't know if it's because of 
> this code revision or something else. I need to do further testing on that.
> 
> 
> Thanks,
> 
> Gistya Eusebio
> 
>

___
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: patch potential memory leak in llgl.h

[Boroondas Gupte]

- Boroondas


---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/603/#review1268
---


On Sept. 20, 2012, 6:15 p.m., Gistya Eusebio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/603/
> ---
> 
> (Updated Sept. 20, 2012, 6:15 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Description
> ---
> 
> In llvertexbuffer.cpp we call: delete mFence;
> 
> mFence is an instance of class LLGLSyncFence which is a sub-class of 
> LLGLFence, which is defined in llgl.h.
> 
> However, class LLGLFence should have a virtual destructor because it's the 
> base class. This patch fixes that potential memory leak, adding a virtual 
> destructor to class LLGLFence. The virtual destructor ensures that the 
> destructor for the derived class also gets called when we call "delete 
> mfence;".
> 
> To quote Björn Pollex, "If you have a class that is supposed to be usable 
> polymorphically, it should also be deletable polymorphically." 
> 
> (Unless I'm missing something...!)
> 
> NOTE: I notice that related code is commented in methods "void 
> LLVertexBuffer::placeFence() const" and "void LLVertexBuffer::waitFence() 
> const" -- maybe we commented it out because this memory leak was unresolved? 
> Perhaps it can be uncommented now? I haven't tried yet. There was no note as 
> to why the code is commented out.
> 
> 
> Diffs
> -
> 
>   indra/llrender/llgl.h UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/603/diff/
> 
> 
> Testing
> ---
> 
> I did compile this with OS X 10.8 as a build target successfully. I made 
> other changes too, so while my FPS seems improved, it could be from any 
> number of issues. I did notice that any llCharacters that are moving around 
> don't get rendered properly by my build, but I don't know if it's because of 
> this code revision or something else. I need to do further testing on that.
> 
> 
> Thanks,
> 
> Gistya Eusebio
> 
>

___
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] feature suggestion: make "doubleclick navigation" more "immersive"

[Dahlia Trimble]

I guess it could be prototyped  by using
http://wiki.secondlife.com/wiki/LlGetStaticPath  in an attachment that the
viewer can communicate with, but (assuming the wiki is accurate) it looks
like it doesn't deal with the obstructed path problem so requesting a new
path upon reaching a waypoint probably wouldn't do much good.


On Fri, Sep 21, 2012 at 1:58 PM, Lance Corrimal
wrote:

> Am Freitag 21 September 2012, 12:43:29 schrieb Dahlia Trimble:
> A *pathfinding capable* autopilot function
> > could update the waypoint list while in route in case the original path
> > becomes obstructed.
>
> basically, after reaching a waypoint it would request the list of remaining
> waypoints again? that sounds like a good plan.
>
>
> 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