On February 25, 2020 at 2:17:16 PM, Henri Beauchamp (sl...@hotmail.com) wrote:
On Tue, 25 Feb 2020 10:48:03 -0500, Oz Linden (Scott Lawrence) wrote: > *As we mentioned at the last Third Party Viewer meeting, Oh yes, those meetings a non-English speaking developer cannot follow because they are held in voice chat... How nice and practical a way of communication ! Agreed. Even as a native English speaker, the meetings are not accessible to those without access to voice. Summaries of the meetings on third party blogs don’t really suffice for api breaking updates. > Why are there changes? > > The viewer currently has some messages and costs hard coded They are _*NOT*_ hard-coded. The cost is modified after login on receiving the EconomyData message (the process_economy_data() callback is implemented in indra/newview/llviewermessage.cpp). By the way, that's how OpenSIM grid can (and always could) deal with different costs than in SL. Agreed on this point. When I implemented some of these same features in an OpenSim grid, it was by extending the EconomyData message combined with simulator cap. Won’t go into implementation issues with the way it was done because it’s already been done, outside of mentioning the rampant singletons-calling-singletons-calling-singletons pattern is problematic. :) Sadly, you used an LLSD sub-array into the LLSD map, and "old" viewers (i.e. all viewers not based on LL's v3 viewer code for the XML RPC part) do not know what to do with such an array (they can only deal with simple key/value pairs, not with key/arrays); this was the case of my viewer (but I thankfully and by pure "luck" noticed the issue a few weeks before LL did stealthily modify the login server on the main grid, because the beta grid already had the changes which caused me to fail to login in it at that time, and I could diagnose and fix the issue). Lost a day out of my weekend diagnosing and resolving this in LibreMetaverse/Radegast-ng. It really is a death blow to the unmaintained OMV library. Heads up before this kind of deployment would be very appreciated. > 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. This particular usage is useless and redundant, since EconomyData/ process_economy_data() already can change that value in real time (and in fact, it could even occur on a per-sim basis if needed, and not just at login !). Very true. It also handles the case where a customer changes premium levels while logged in. They would only need a balance refresh not completely exiting the viewer and logging back in (including an out of sync state where an account is downgraded while the agent remains online.) > Where are the changes? > > The changes are in the 'DRTVWR-481 > <https://bitbucket.org/lindenlab/viewer/branch/DRTVWR-481>' branch in > the viewer git repository. A viewer built from that branch will be > available as a Release Candidate soon. It would have been nice to give a sufficient forewarning to avoid breaking the login process on the main grid for many viewers (or viewer versions): Radegast, my viewer (all versions before v1.26.24.2 are unable to login in SL any more), OMV, etc, etc, etc. Seconded. Always appreciated when API changes are documented on the wiki as well. I am (yet again) extremely disappointed with LL: - No communication (a message in this list should have been posted even before the change would have gone live on Aditi !), - No forewarning (it's already too late for Agni as well !), - No anticipation of the problems induced by the planed change, - Not even a sane, simple, trivial precaution, such as respecting LL's own viewer protocols design (here via the requested_options mechanism) for something as essential as the login process ! Agreeing with this. There’s a wealth of knowledge that can be tapped into via this mailing list that could have prevented some of these compatibility issues. Remember that many of us have been blackboxing the API and extending features without any access to the server side code for over a decade now. Those of us with that breadth of experience rarely attend the inworld meetings due to language, accessibility, and geographic constraints.
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
