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 _______________________________________________ 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
