After a user spend three days trying to find out why certain
textures looked red (as if they had alpha and you pressed
control-alt-T, but not all of them were like that); and nothing
helped, not relogging, not clearing cache, not even reinstalling
the viewer... I decided to take this bug serious. Note that,
according to Shyotl, there have been more users every now and
then that reported this problem.
The problem (after doing a research for 1 hour) turned out
to be that she had beacons on, highlighting prims with scripts.
The immediate bug is, of course, that this was persistent over
a relog. Upon further investigation, this bug exists because
a Debug Setting had a double meaning: it meant both "beacon
floater is visible", which you want to be persistent, and it
was later renamed and given the meaning "Keep beacons when
closing the floater". Digging deeper it turned out that there
was a REAL mess with regard to the beacons: A non-finished
floater with immature comments (called "dingdong floater") was
half-created and replaced the original floater which, according
to the comment was "so fucked over and over" (== commented out
in several places), but then everything was commented out and
replaced with a menu (because they couldn't get it to work?).
The floater simply didn't exist anymore! That reduced the
meaning of the Debug Setting to "Show beacons", although you
now could only set it in the menu by clicking on "Beacons Always On"
where 'Always' refers to also on when the floater isn't there.
I nuked the immature dingdong code, brought back the original
floater as it was in snowglobe (and still is in Imprudence),
fixed it up a bit with a nicer layout (indentation and spacing)
and disabling (graying out) when needed, and added a new checkbox
that will allow people to still keep/see the beacons after closing
the floater.
In the end this requires THREE Debug Setting variables:
ShowBeaconsFloater : TRUE when the floater is visible, FALSE when not.
This is persistent, so the floater is still
there if you relog with the floater open.
BeaconsKeepVisible : TRUE when the new checkbox is checked.
Also persistent.
BeaconsVisible : TRUE when the beacons are rendered, FALSE otherwise.
This is NOT persistent: we don't want unsuspecting
users to try and get rid of the weird 'red prims'
by relogging and failing at that.
Call AIFilePicker::create() instead of new AIFilePicker.
Renamed deleteMe() to kill() and bs_deleted to bs_killed.
Only default to auto destruct when created with create(true),
otherwise kill() has to be called explicitely.
This fixes the bug that if you Quit while in the Singularity -> Pose
Stand, then you are permanently hovering over the group until you go
into Advanced -> Debug Settings and reset AscentAvatarZModifier.
It also fixes that before, when you changed AscentAvatarZModifier
in Advanced -> Debug Settings then you saw no effect (until the
viewer would sent an AvatarAppearance message.
After this patch, changing any of the AscentAvatar*Modifier settings
has immediate visible effect, and a pose stand (Z-offset) is reset
when quitting.
Allows to save the .llm of all mesh objects, and
all morphs of each as .obj (Wavefront OBJ File),
for import in, for example, blender.
You can also load .obj files, but of course they
will only affect what you see locally.
Also upgrade the file picker filters with the new extensions found
in the orginal file picker code of Singularity.
Also improve AIFilePicker a bit: added hasFilename() and now
deleting the statemachine automatically by default: it's no longer
needed to call deleteMe from the callback.
Patch from 2010-10-20/22. Didn't apply cleanly so I redid it
manually and tested/checked it. There was only one difference
with imprudence: for some reason Singularity tries to see
if the "teleport history" floater is visible while initializing
the menu's, something that imprudence doesn't do. For the rest
the patch is basically the same. Nevertheless, I left all code
exactly as it was in Singularity (the only thing that this
commit changes is the intend of the original patch: in debug
mode, fail with an assertion when LindenUserDir is called while
it is not initialized; and then fix everything to make it work
again.
Original commit message:
The LindenUserDir (~/.imprudence/first_last/) cannot be initialized
before the user logged in. However, several singletons (that only can be
initialized once) depend on this directory for initialization. Therefore
we have to take care not to instantiate those singletons until after the
user logged in.
With regard to webit, this fixes the browser_profile (cache and cookies)
directory that the builtin browser uses.
Most the changes are due to InventoryObjectList* changing to LLInventoryObject::object_list_t*, LLInventoryItem::II_FLAGS* changing to LLInventoryItemFlags::II_FLAGS* and also const'ing.
Certain perms for certain asset types(callcard&landmarks) have been laxed, as per LL's V2.
LLInventoryType now does lookups mostly though new lldictionary class.
LLLandmark using boost for callbacks, instead of custom class structure.
Need to test:
localassetbrowser
preview related floaters
hgfloatertexteditor
maps
media textures! Currently very hacky
web browser
alpha masks on avatars
bumpmaps
Are all sky components appearing?
LLViewerDynamicTexture (texture baking, browser, animated textures, anim previews, etc)
Snapshot related features
Customize avatar
vfs floater
UI textures in general
Texture priority issues
