Added a constraint to ensure that the avatar's height (with offset)
does not go below 0.1 meters. Camera was getting confused since the avatar's
effective height was negative.
Note the avatar is mostly underground/contorted even at 0.1 meters, but
most users setting values this low will be making ultra-tinies and would
be hiding the avatar mesh. Camera stays above ground when height is at 0.1.
Conflicts:
indra/llappearance/llavatarappearance.cpp
Instead of focusing the chat bar when the chat history floater is visible, focus it onFocusReceived
This avoids the floater grabbing focus when returning from mouselook.
We were getting the texture ID from the type,index couple, but were not
passing in index, which defaulted to 0. texture ID is available from the
texture object itself, so using that and removing the index parameter
to prevent future confusion.
Conflicts:
indra/newview/llvoavatarself.cpp
If log_path is empty, we shouldn't setChatLogsDir to it.
In fact, this may have been the cause of something Nomade Zhao brought up.
Also, InstantMessageLogPathAnyAccount was accidentally being set as a PerAccount
All HTTP timing is done by AIHTTPTimeoutPolicy.
Inside LLTextureFetchWorker::doWork when mState == SEND_HTTP_REQ,
mCanUseHTTP is true, throttling is not in effect and mURL is not empty,
mLoaded is set to FALSE, mState is set to WAIT_HTTP_REQ and
LLHTTPClient::request is called that starts the download by curl.
A call back to LLTextureFetchWorker::callbackHttpGet is guaranteed,
which causes mLoaded to be set to TRUE (HTTPGetResponder::completedRaw
calls LLTextureFetchWorker::callbackHttpGet which sets mRequestedSize to -1
(if there was an error) and mLoaded to TRUE).
Being in state WAIT_HTTP_REQ, once mLoaded == TRUE (and mRequestedSize
is -1), the different timeout errors are handled.
This reverts commit 63dcd7ba32.
That commit is nonsense and only shows that Liru has no clue what he is
doing when it comes to the snapshot stuff :/.
And no, I wasn't even AWARE he made this commit, I was just happily
exploring and wanted to make a few snapshots when I suddenly noticed
that several things were BROKEN: the aspect that the fullscreen preview
was shown with was wrong, and when I wanted to limit the aspect of my
feed upload that wasn't possible anymore ?!?!?? WTF
Please don't screw up the hard work of others without at LEAST first
consulting them.
This fixes
https://code.google.com/p/singularity-viewer/issues/detail?id=714
The problem was a typo in AIStateMachine::sleep, >= should have been <=
which caused a state machine that uses yield_ms() to never run anymore
when next run it already should have run again. AIFilePicker is the only
state machine that currently uses yield_ms and I hadn't spotted this
because I don't have plugin messages on by default which made my viewer
just that much faster that it the yield never expired the first run
already (causing it to expire immediately).
The rest of the changes in this commit are just minor improvements /
conformation to the EXAMPLE_CODE in aistatemachine.cpp.
This fixes https://code.google.com/p/singularity-viewer/issues/detail?id=705
Adds 'bool redirect_status_ok(void) const { return true; }' to LLIamHere,
because it's ok to receive a 302 status there. Likewise added to LLIamHereVoice,
because that has the same comment in its error() method.
Also fixes the problem that if two redirects occur on a row, then the
upload_finished detection asserted because it would detect the third
time that libcurl turned off writing to the socket as a failure (the
second time wasn't a problem because mUploadFinished was reset upon
receiving the first 302 header, but not upon receiving the second
header).
Now that a call to cont() can schedule a run of the statemachine, we
need this change to make it robust (the comment that cont() does never
access mRegisteredStateMachines no longer holds).
This is now necessary since the curl thread no longer syncs with the
main thread: it is possible that a request finishes after a texture
fetch thread was shot down but before curl was stopped, and curl
calling BufferedCurlEasyRequest::processOutput while objects that the
responder uses were already destructed (most notably
LLTextureFetch itself).
Doing this resulted in a 404 on Aditi, and although that was a server
bug; it still doesn't seem to make much sense to do the request in the
first place.
