Re: [opensource-dev] Viewer changes for Premium changes

[Henri Beauchamp]

On Thu, 19 Mar 2020 21:24:10 +0100, Henri Beauchamp wrote:

> All you need to change is to add in LLLoginInstance::constructAuthParams():
> requested_options.append("agent_appearance_service");

Of course, I meant:
requested_options.append("account_level_benefits");

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] Viewer changes for Premium changes

[Henri Beauchamp]

On Thu, 19 Mar 2020 15:29:01 -0400, Oz Linden (Scott Lawrence) wrote:

> On 2020-03-19 11:58 , Henri Beauchamp wrote:
> > However, a couple of things are confusing. Would you please care to explain
> > them:
> >
> > - So far, on login, the only "account_level_benefits" parameters returned
> >by the server are: "additional_listing_cost" and "num_free_listings",
> >which are not even parsed for/used in your code !
> >No parameter dealing with upload costs, creation group cost, attachments
> >limit or picks limit, while your new code relies on them: is it normal
> >(i.e. not yet implemented server-side) or is it a problem with my SL
> >accounts (one premium and several normal/free accounts, all showing the
> >same set of "account_level_benefits" parameters, and just different
> >values) ?
> Where are you logging in? 

Anywhere in Agni or Aditi...

> When I log in I get a great deal more than that.

Strange, to say the least... O.O

I got debug messages for user auth XML RPC data reply in my viewer,
and I don't see anything else than "additional_listing_cost" and
"num_free_listings" under "account_level_benefits"...

> > - There is a "ViewerBenefits" capability requested by your new code, but
> >that capability is never used... Is it normal, or is something missing
> >there ?
> 
> That's there as a flag to inform the simulator that the viewer 
> understands the new benefits mechanism. As far as I know we have not 
> used it for anything, but it's there so that if we discover a 
> backwards-compatibility problem serious enough we can modify messaging 
> or make some other accomodation.

You won't need this "flag" with the "normal" login protocol consisting
for the viewer to request the data associated with that feature on login,
i.e. a viewer implementing or not the "benefits" feature can be flagged
as such as soon as at the login request, while the capabilities (for the
login region) are requested much latter in the login process (and need to
be re-requested at each new region connection, with potential race
condition issues during the long "connect to region" -> "wait for seed" ->
"send caps request" process).

All you need to change is to add in LLLoginInstance::constructAuthParams():
requested_options.append("agent_appearance_service");

Then, when the login server receives the above option request, it flags
the agent/viewer as benefits-aware (no need any more for the unused
capability) and sends the corresponding parameters (and by not sending
them when not requested, you also restore the login compatibility with
old viewers).

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] Viewer changes for Premium changes

[Oz Linden (Scott Lawrence)]

On 2020-03-19 11:58 , Henri Beauchamp wrote:

However, a couple of things are confusing. Would you please care to explain
them:

- So far, on login, the only "account_level_benefits" parameters returned
   by the server are: "additional_listing_cost" and "num_free_listings",
   which are not even parsed for/used in your code !
   No parameter dealing with upload costs, creation group cost, attachments
   limit or picks limit, while your new code relies on them: is it normal
   (i.e. not yet implemented server-side) or is it a problem with my SL
   accounts (one premium and several normal/free accounts, all showing the
   same set of "account_level_benefits" parameters, and just different
   values) ?

Where are you logging in?  When I log in I get a great deal more than that.

- There is a "ViewerBenefits" capability requested by your new code, but
   that capability is never used... Is it normal, or is something missing
   there ?


That's there as a flag to inform the simulator that the viewer 
understands the new benefits mechanism. As far as I know we have not 
used it for anything, but it's there so that if we discover a 
backwards-compatibility problem serious enough we can modify messaging 
or make some other accomodation.


--
OZ LINDEN | VP Second Life Engineering
email: o...@lindenlab.com  | Scott Lawrence 


LINDEN LAB | Create Virtual Experiences 
___
Policies 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] Viewer changes for Premium changes

[Henri Beauchamp]

On Thu, 19 Mar 2020 10:46:27 -0400, Oz Linden (Scott Lawrence) wrote:

> The DRTVWR-481 branch has been promoted to the default viewer and pulled 
> to the master branch.

Sadly, there is no corresponding commit to be found: the only commit 
between the master branch and DRTVWR-481 (which is now gone and cannot
be browsed any more) is the opposite one, i.e. the merge of the release
viewer branch into DRTVWR-481, prior to the promotion of the latter...

So, I downloaded a diffed the master and the v6.3.8 release tags to diff
them but, surprise, they only differ by their version number (only one
diff in the sources, dealing with the version increment from 6.3.8 to
6.3.9) !

In fact, to get the full batch of changes between the former release
tag and the merged DRTVWR-481 branch, I has to diff the sources for
the release tags of 6.3.7 and 6.3.8...

What a mess !


> TPVs will save their users confusion and reduce support questions by 
> getting as many users as possible onto viewers with this support by the 
> time we change the Premium offerings. I don't have a target date for it 
> I can share, but it's not that far off.

I already implemented most of the changes (in my own way, to keep things
OpenSim-compatible, i.e. keeping also the old economy-based process), and
did not find much added changes in the new diff.

However, a couple of things are confusing. Would you please care to explain
them:

- So far, on login, the only "account_level_benefits" parameters returned
  by the server are: "additional_listing_cost" and "num_free_listings",
  which are not even parsed for/used in your code !
  No parameter dealing with upload costs, creation group cost, attachments
  limit or picks limit, while your new code relies on them: is it normal
  (i.e. not yet implemented server-side) or is it a problem with my SL
  accounts (one premium and several normal/free accounts, all showing the
  same set of "account_level_benefits" parameters, and just different
  values) ?

- There is a "ViewerBenefits" capability requested by your new code, but
  that capability is never used... Is it normal, or is something missing
  there ?

Regards,

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] Viewer changes for Premium changes

[Oz Linden (Scott Lawrence)]

The DRTVWR-481 branch has been promoted to the default viewer and pulled 
to the master branch.


TPVs will save their users confusion and reduce support questions by 
getting as many users as possible onto viewers with this support by the 
time we change the Premium offerings. I don't have a target date for it 
I can share, but it's not that far off.



**

*As we mentioned at the last Third Party Viewer meeting, the upcoming 
changes to Premium levels will require some viewer updates to maintain 
full compatibility.*


*

Why are there changes?

The viewer currently has some messages and costs hard coded that will 
need to be sensitive to the account type of the user. Rather than just 
telling the viewer the users’ account level (which we will also do) 
and then putting code into the viewer to adjust based on that type, we 
have built a more general solution. A new key ('benefits') in the LLSD 
map returned by login identifies a map whose keys are "benefit tags" 
and whose values are what that benefit level is for the logged-in user.


For example, one of the benefit tags is "texture_upload_cost"; its 
value is the number of L$ required for this user to upload a texture. 
The viewer displays that cost in the upload dialog so that dialog must 
be modified to use the value returned in the tag rather than the L$10 
that is currently hard coded.


Where are the changes?

The changes are in the 'DRTVWR-481 
' branch in 
the viewer git repository. A viewer built from that branch will be 
available as a Release Candidate soon.


When can we release these changes?

We strongly encourage you to integrate these changes as soon as 
possible. You are free to begin incorporating the changes and 
releasing them any time (but please watch for updates to them).


The login servers should already be returning the benefits information 
(the values are the same as those currently in the viewer; they'll 
change when we make the new Premium Plus level available and introduce 
other changes to Premium).


The simulator support for benefits is still being finalized and 
deployed; they are just beginning to use the benefits information from 
login in the same way this new viewer branch does. In practice, both 
should arrive at the same numbers since the current benefits 
information from login matches the old hard coded values. If your 
testing shows any discrepancies, please report them via Jira as 
quickly as possible.


What will happen with unmodified viewers when the Premium changes go 
into effect?


Most Second Life usage should be fine without the updates, but there 
may be subtle problems. For example, an unmodified viewer may have the 
wrong cost for some action; if the viewer expects the cost to be lower 
than the simulator does, the simulator will reject the request.


*



--
OZ LINDEN | VP Second Life Engineering
email: o...@lindenlab.com  | Scott Lawrence 


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