Well i'll be damned. Would any of you believe that this change fixed this problem? http://dolphinsource.eregion.de/dolphinviewer3-beta/commits/9d50f4af1158b49364cfb0d38090c7947db56f03
*facepalm* How is one supposed to apply logic to stuff like that. 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
