Adding a flag to hint to the sim that this viewer knows how to handle
AvatarAppearance messages for self in SSA-enabled regions.
Upstream patch: 5fdc790f6d
This also makes the viewer immune for grids that send the FetchInventory2 et al
capabilities regardsless of whether we requested them (in fact, we always
request them now: we need them when someone switches in the middle of a session).
Note that (I tested that) textures could already be switched between
HTTP and UDP without relogging.
Adds support for GamingData cap, and flags: PF_GAMING, DFQ_FILTER_GAMING, REGION_FLAGS_GAMING, and REGION_FLAGS_HIDE_FROM_SEARCH
Adds GamingCheck to floater_about_land.xml
Adds filter_gaming checkboxes to floater_directory* xmls
Adds "is gaming" and "hide from search" checkboxes to floater_god_tools.xml
Conflicts:
indra/newview/llmeshrepository.cpp
Added /* */ around the 'virtual' keyword in two places
that collided with changes in meshupload from lightdrake.
Conflicts:
indra/newview/llfloateravatarpicker.cpp - Includes to v-d style, since plain alphabetical just won't cut it. Shyotl's changes for name system, here.
indra/newview/llpanelgroupinvite.cpp - Shyotl's changes for name system, here.
Also corrected new README to have less typos and be slightly more accurate.
Note: Large groups still don't load?!
SimConsole cap is needed for Sim Console, won't work without it, keeping it in!
..But it should work with the new ASync one? Maybe needs tweaks, first?
Also switches opening IMs to the gCacheName->getFullName(id, name) system mentioned earlier, my connection has improved!
And makes the Avatar Picker show display names! Yay! (Rearranged the includes there, alphabetical~)
Also fallback to gCacheName->getFullName(id, name) if getting name fails in the new system.. hopefully this will combat occasional big failures.. but it may not work anyway.. maybe my connection is just awful again
Note: These changesets removed the some caps in llviewerregion.cpp, I have made a note of these, but left them in.
Please take a look at the Singu Note:'s and Singu: TODO:'s when working on this.
* Moved Responder stuff to LLHTTPClient.
* Renamed LLHTTPClient::Responder to LLHTTPClient::ResponderWithResult.
* Deleted LLHTTPClientAdapter and LLHTTPClientInterface.
* Renamed AICurlInterface::TransferInfo to AITransferInfo and moved it
to llhttpclient.h
* Removed 'CURLcode code' argument from completed_headers.
* Removed LLCurlRequest and replaced it's last usage with LLHTTPClient API calls.
* Deleted dead code.
* Renamed all the get4/post4/put4/getByteRange4 etc, back to their
original name without the '4'.
Introduces AIHTTPTimeoutPolicy objects which do not just
specify a single "timeout" in seconds, but a plethora of
timings related to the life cycle of the average HTTP
transaction.
This knowledge is that moved to the Responder being
used instead of floating constants hardcoded in the
callers of http requests. This assumes that the same
timeout policy is wanted for each transaction that
uses the same Responder, which can be enforced is needed.
I added a AIHTTPTimeoutPolicy for EVERY responder,
only to make it easier later to tune timeout values
and/or to get feedback about which responder runs
into HTTP errors in debug output (especially time outs),
so that they can be tuned later. If we already understood
exactly what we were doing then most responders could
have been left alone and just return the default timeout
policy: by far most timeout policies are just a copy
of the default policy, currently.
This commit is not finished... It's a work in progress
(viewer runs fine with it though).
This is basically the changes in viewer 3 to this file,
except that I left alone:
1) We still have a cloud layer (mCloudLayer)
2) LLViewerRegion::regionFlagsToString still adds comma's
and a lot more flags.
3) We still have the extra accessor LLViewerRegion::getNetDetailsForLCD()
4) The actual capabilities requested in LLViewerRegionImpl::buildCapabilityNames
have been left alone and still request the same caps as before.
5) LLViewerRegion::meshUploadEnabled and LLViewerRegion::meshRezEnabled
have been left alone. They seems to do more work in our case,
checking if we have the capability SimulatorFeatures, and doing
something smart when that is not the case.
