This should fix 'Received 302 (Moved Temporarily) for responder
"AgentStateResponder" which has no followRedir().
Some responders want to deal with redirections themselves, I checked if
this (new, pathfinder related) responder wants that in viewer-release,
but it doesn't. Turning this on requires to also keep track of cookies,
so it's a bit slower and therefore left at the old default: to not let
curl follow redirections. Optionally we would turn it on by default and
explicitely off for those responders that want to deal with 302's
themselves and for those that really don't need it and are used most
heavily.
https://code.google.com/p/singularity-viewer/issues/detail?id=848
If advance_state is called, then the state is NOT changed (only
sub_state_w->advance_state is set), but sub_state_w->skip_idle is set to
true in order to ignore the next call to idle (if the state machine is
already in the middle of executing a state). Therefore, this assert
would trigger. The solution is to not trigger when skip_idle is set.
The const LLRelationship* info was likely null at times, or names weren't looked up, we just failed silently and played the start IM sound as though nothing had happened, this won't happen anymore.
https://code.google.com/p/singularity-viewer/issues/detail?id=679
Instead of making the cursor just always an arrow, I changed the
'working' cursor from a watch to an arrow + hour glass. Note that the
BMP of the 'wait' cursor was exactly the same as the 'working' cursor,
so if anywhere 'working' should NOT have an arrow, then that should be
replaced with the UI_CURSOR_WAIT to restore the old cursor.
Obviously, the blinking is fixed too - cause that is what this all was
about.
Conflicts:
indra/llappearance/llwearable.h
indra/llui/llcombobox.h
indra/newview/jcfloaterareasearch.cpp
indra/newview/jcfloaterareasearch.h
indra/newview/llpanelgrouproles.cpp
indra/newview/llpanelgrouproles.h
indra/newview/llviewermenu.cpp - Plugged in new MenuFloaterDict for AssetBlacklist and SoundExplorer in menu_viewer.xml and removed the old listeners for them.
indra/newview/skins/default/xui/es/floater_inventory.xml
Compile Fixes:
indra/llcommon/llstl.h - error: expected nested-name-specifier before ‘const’
indra/llui/llmultisliderctrl.cpp:283:12: error: ‘caller’ was not declared in this scope
indra/llui/lltexteditor.cpp
- error: operands to ?: have different types ‘const LLPointer<LLTextSegment>’ and ‘long int’
- error: passing ‘const LLPointer<LLTextSegment>’ as ‘this’ argument of ‘LLPointer<Type>& LLPointer<Type>::operator=(const LLPointer<Type>&) [with Type = LLTextSegment]’ discards qualifiers
indra/newview/llfloaterpermissionsmgr.cpp - Silly Shyotl, boost bind, not std bind.
indra/newview/llfloaterproperties.* - error: ‘LLInstanceTracker<LLFloaterProperties, LLUUID>’ is an inaccessible base of ‘LLFloaterProperties’
indra/newview/llgivemoney.cpp - Again, boost::ref, not std::ref
indra/newview/llpreviewscript.cpp - no known conversion for argument 1 from ‘std::vector<const LLPointer<LLTextSegment> >’ to ‘std::vector<LLPointer<LLTextSegment> >&
Fixes a possible ASSERT(!(need_new_run && !mYieldEngine &&
sub_state_r->run_state == run_state)).
When over all multiplex_impl functions and this is the only case that I
found where it could return without changing the state and without
calling either idle() or yield().
Two real changes: 1. Don't tell the user we're counting scripts when they just want them gone; 2. When deleting a script, counter-iterate to avoid a crash
Adds a bit more debug spew commented out, helped me out with this.
Thanks to Sentinel for catching this early!
Moves the "We have a real utterance now" block back above the concatenation of names and verbs and the message.
Maybe italicize should be tied to a separate setting for bubble chat, but for now let's see if it is fine in its current state.
Don't add names that haven't been looked up yet to the group roles list, wait for them to be looked up, then check them against the filter.. this avoids unrelated names getting turned up in the list under a filter.
Also diverged a bit from upstream to filter using the displayed names, since people who are only having Display Name shown will get inconsistent names turned up by the filter, otherwise. (Searching "Inusaito Kanya" would turn up "Aur'a Færs" in the results, which obviously isn't what they're looking for... maybe this should be done with complete name, but logically you should see what you searched in your results)
