[opensource-dev] someone get the blindfold off me please - where in the sourcecode is the spot where a "parcel full" message is created?

Lance Corrimal Lance.Corrimal at eregion.de
Wed Aug 6 12:51:44 PDT 2014


Am Mittwoch, 6. August 2014, 21:45:52 schrieb Lance Corrimal:
> Well i'll be damned.
> 
> Would any of you believe that this change fixed this problem?
> http://dolphinsource.eregion.de/dolphinviewer3-beta/commits/9d50f4af1158b493
> 64cfb0d38090c7947db56f03
> 
> *facepalm*
> 
> How is one supposed to apply logic to stuff like that.

...and even more fun: now it also works in my previous builds that do not have 
that "fix".

*doublefacepalm*

> 
> 
> Cheers
> LC
> 
> Am Mittwoch, 6. August 2014, 21:13:18 schrieb Lance Corrimal:
> > Hi,
> > 
> > 
> > the part that I really don't get is where I see that that part of the
> > code has not been changed in my viewer (comparing with viewer-release)
> > but still behaves so differently...
> > 
> > Cheers
> > LC
> > 
> > Am 06.08.2014 um 20:38 schrieb Henri Beauchamp:
> > > On Wed, 06 Aug 2014 17:49:24 +0200, Lance Corrimal wrote:
> > >> Am Dienstag, 5. August 2014, 16:11:11 schrieb Darien Caldwell:
> > >>> I'd suspect that the viewer simply makes a rez request to the Server,
> > >>> and
> > >>> the server makes the determination it can't be completed, and why.
> > >>> LIkely
> > >>> the server just sends back the error message via some sort of generic
> > >>> callback. In short the message wouldn't be in the viewer. I may be
> > >>> wrong
> > >>> though.
> > >> 
> > >> That's exactly my problem here, I see a "missing string" error in my
> > >> logfiles, but I can't find the missing string in the original
> > >> strings.xml or notifications.xml of the development viewer... And I
> > >> can't find the creation of the message itself, either, but in the
> > >> original viewer i do get a "parcel full" error at the appropriate
> > >> moment.
> > >> 
> > >> I frankly do not know where to look 0.o
> > >> 
> > >> Help!
> > > 
> > > Look inside indra/newview/llviewermessage.cpp, process_alert_core()
> > > function. My *guess* (not having this problem, here, with v1-style
> > > notifications), is that you reach one of the
> > > std::string new_msg =
> > > LLNotifications::instance().getGlobalString(message);
> > > lines in that function, and there's no corresponding "global string" for
> > > that particular message, so the translation fails... Which is not
> > > surprising, because many server-side initiated messages don't have a
> > > template in notifications.xml neither any translation string in
> > > strings.xml.
> > > 
> > > The v1 viewers were not attempting to translate such messages at all
> > > cost,
> > > so they just display them in plain English and without error.
> > > 
> > > I suppose you could add a method in LLTrans that would allow you to
> > > check
> > > for the existence of a given string before actually calling
> > > LLTrans::findString (which errors out when the translation does not
> > > exist). If the translation doesn't exist, then just display the message
> > > "as is".
> > > 
> > > To confirm my diagnosis, just put a few llinfos in process_alert_core()
> > > and
> > > see what happens...
> > > 
> > > 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



More information about the opensource-dev mailing list