[#VWR-434] HUD textures are attaching but not being seen

1. Second Life Viewer - VWR

HUD textures are attaching but not being seen

Created: 12/Apr/07 04:21 AM Updated: 29/Jul/08 01:23 AM

Return to search

Component/s:

Graphics, Scripting

Affects Version/s:

1.14.0.x, 1.17.0.x, 1.18.3 Release Candidate, 1.18.2.0, 1.18.4 Release Candidate, 1.18.5 Release Candidate

Fix Version/s:

1.19.1.4

File Attachments:

None

Image Attachments:

1. Bad HUD pic.jpg (184 kB)	2. Good HUD pic.jpg (164 kB)	3. HUD Issue.jpg (26 kB)
4. Hud issues.jpg (58 kB)

Environment:

Windows XP pack 2, Mac OS X 10.4

Issue Links:

Duplicate

This issue is original of duplicate:

~~VWR-884~~ HUDs attached directly from inworld are invisible

Relates

This issue is related to by:

MISC-1416 Meta-Issue: Textures

Linden Lab Issue ID:

SL-42521

Description

« Hide

When an object attaches to the HUD, and it starts at total 100% transparency then supposed to slowly becomes more visible, the HUD stays invisible. This never happened before.

However, if the person logs off and logs back on the HUD becomes visible properly and works normally.

It can be duplicated if you make an item with a child item linked together.
Give the child item a texture with an alpha channel and start it at total transparency.
Put in a script so the person touches the item, it asks permission to attach
Have the use touch the item so both prims attach to the HUD center or anywhere in the HUD.
Slowly let it fade from transparency to full opaque.

It will never show up, even if you change it's texture, even if you teleport, even if you "view transparent". (And as I just found out, even if it's NOT transparent, it will not show up)

The only way to see it properly is to log off and log back on.

UPDATE: I've just experimented. Even the texture attaches at no transparancy and with a texture that has no transparancy - once it goes to a tranparent texture or goes to 100% transpancy, it cannot be seen again unless the user logs off and logs back in.

More testing: The bug seems to occur when the script calls for a permission to attach. If the avatar just attaches it to their HUD via a menu, no problem. However, take the same prim or prims and add the permission to add the item, attach it, it just disappears. It's in the inventory as there and it's bold, but it can't be seen. You have to log off and log on in order for it to show up.

Further testing: If someone goes into their inventory, detaches then wears the item, it works perfectly.

Also, if someone uses a previous version of the SL viewer, it works exactly as designed: no need to log or detach/wear.

Please help with this

Thanks.

All

Comments

Change History

Sort Order:

[ Permlink | « Hide ]

Simone Sautereau added a comment - 03/May/07 06:41 AM

Some work fine, others do not. It seems in my case to be dependant on the new HUD updates. Most will work when moved and attached manually to center HUD, but then I can end up with a visual stuck in the middle of your field that should not show.

[ Permlink | « Hide ]

Delerium Hannibal added a comment - 11/May/07 03:03 AM

I've noticed this funky behavior as well, and for me it was much more simple. I had a hud I was building on the ground, and I clicked "Attach to HUD/top left" and all the sudden it went invisible. the WHOLE thing. When I clicked drop it was still invisible. I then picked it up and did the same thing, "Attach to HUD/top left" and again, invisible. Once I detached it I tried something new. Since it had it's position already memorized, I clicked "Wear" and it showed up fine. For some reason it went invisible when I specified an attachment point from the ground. Not too sure on all of this since it was a one time occurance, and I didn't think much to test it out. I'll post more if I get a chance to test it more, but for now I'm voting for this issue.

[ Permlink | « Hide ]

feelgood tripp added a comment - 01/Jun/07 02:41 PM

I have had this bug myself. Seems any object attached to HUD via script turns invisible. Really annoying!

[ Permlink | « Hide ]

luna cartier added a comment - 15/Jun/07 04:09 PM

I can remove and replace the HUD and then it is visible. which is quicker than the relog, but still very annoying for creating visual effects. Kind of a buzz kill for drugs, lol.

[ Permlink | « Hide ]

Ultralite Soleil added a comment - 16/Jun/07 04:51 AM

Just to be clear, the fading in from translucency is not a factor with this bug. I have a HUD that occasionally attaches as invisible, but all the llSetTexts do show up. If I drop and reattach it usually fixes itself. Upvoted.

[ Permlink | « Hide ]

Toneless Tomba added a comment - 29/Jun/07 12:01 PM

It would be nice to be able to somehow give priority to hud object than to items in world or make it a option. I think in general most people want to see their hud first then the land around them.

[ Permlink | « Hide ]

Lulu Ludovico added a comment - 05/Jul/07 07:04 PM

This bug also manifests itself like so:

1. rez an HUD object.
2. attach to HUD. It will become invisible. Turning on Ctrl-Alt-T will not highlight it.
3. Detach and attach. It becomes visible again.

I believe this is highlighted (and duplicated) in ~~VWR-884~~

[ Permlink | « Hide ]

Lulu Ludovico added a comment - 06/Jul/07 07:55 AM

ok scratch previous post - I can't seem to reproduce the bug consistently with a single-prim.

However, tried the following and it reproduced the bug.
1. write a script like so:
default
{
state_entry()

{ llSetText("Here I am",<1,1,1>,1); }

attach(key id)
{
if (id != NULL_KEY)

{ llSetScale(<0.1,0.1,0.1>); llSetTexture("0874cdea-a610-07e4-d9a4-b13c29c923aa",1); //invisible texture. llSetAlpha(0,1); }

else

{ llSetScale(<1,1,1>); llSetTexture("62fc60c0-d497-7803-84b8-646d4329cfd4",1); //white blank texture. llSetAlpha(1,1); }

}

touch_start(integer total_number)
{
if (llGetAttached() == 0)

{ integer perm = llGetPermissions(); if (perm & PERMISSION_ATTACH) llAttachToAvatar(37); else llRequestPermissions(llGetOwner(),PERMISSION_ATTACH); }

}

run_time_permissions(integer perm)

{ if (perm & PERMISSION_ATTACH) llAttachToAvatar(37); }

on_rez(integer i)

{ llSetScale(<0.1,0.1,0.1>); llSetTexture("0874cdea-a610-07e4-d9a4-b13c29c923aa",1); llSetAlpha(0,1); }

}

2. Rez a fresh sphere and drop the script into the sphere.
3. Rez a cube, and link cube to the sphere so that sphere is the root prim.
4. Wear the object on HUD (bottom).
5. Drop sphere on ground. Sphere will expand.
6. Click sphere on ground and it will jump back to HUD and contract (it may ask for perms the first time round).
7. Repeat 5 and 6. Eventually what will happen is:
a. when in HUD, the sphere remains visible even though it's supposed to be invisible.
b. the cube is invisible, even though it's supposed to be visible all the time. Doing ctrl-alt-T does not show up the cube. BUT you can right-click the cube, and in doing so, it will appear.

More information:
1. I'm using an nVidia 6800 GT card
2. The objects I've rezzed have UUID that are NULL_KEYS for some strange reason (I've sent in a support ticket separately).
3. Consequently, the debug console returns the following warning when the object is being worn from the ground:

WARNING: LLInventoryModel::accountForUpdate: No category found for update 00000000000-0000-0000-0000-000000000000

4. As reported earlier, if I rightclick the sphere on the ground and wear, the cube is seen. But if I do it via permissions and script, the cube is invisible.

[ Permlink | « Hide ]

Gigs Taggart added a comment - 09/Jul/07 02:43 AM

More minimal repro:

Make a stack of 30 small cubes, any size is fine, it's not important, smaller is better so it doesn't cover your whole screen when you attach it.

Link the pile of cubes.

Drop this script into the root prim:

default
{
state_entry()

{ llSetText("Here I am",<1,1,1>,1); }

touch_start(integer total_number)
{
if (llGetAttached() == 0)

{ integer perm = llGetPermissions(); if (perm & PERMISSION_ATTACH) llAttachToAvatar(37); else llRequestPermissions(llGetOwner(),PERMISSION_ATTACH); }

}

run_time_permissions(integer perm)

{ if (perm & PERMISSION_ATTACH) llAttachToAvatar(37); }

}

Touch the linkset. It will either be partially visible, visible, or completely invisible.

If it seems fully visible, then right click and "drop", then touch it. Repeat this and eventually it WILL screw up and part or all of the linkset will be invisible.

[ Permlink | « Hide ]

Gigs Taggart added a comment - 09/Jul/07 02:46 AM

I should note there are other issues, there is another issue here where things that are supposed to go invisible don't. My repro is a minimal case for one part of it, that things go invisible when they shouldn't.

(Note that repro above also throws my camera about 20 meters sometimes... probably a third bug).

[ Permlink | « Hide ]

Lulu Ludovico added a comment - 09/Jul/07 03:08 AM

After more testing with Gigs Taggart, we have more clues:

1. Gigs was able to repro the bug "in openjpeg on linux too so it's not just a texture rendering problem in KDU"
2. I have a hunch that the more complex the object (i.e. more prims), the bug gets more severe. I have seen a variation of the same bug on a much larger object where the ball was dropped on the ground from HUD (it was invisible in HUD), and the alpha immediately set to 1, but it remained invisible (and cannot be seen by Ctrl-Alt-T, nor right-clicked). In the 2-prim example, the ball did render the texture but only after a pause. Also, Gig's separate repro only worked reliably with 30 prims, but not less.
3. As a variation to Gig's repro above, I added:

attach(key id)

{ if (id != NULL_KEY) llSetAlpha(0.0,ALL_SIDES); }

now the root prim attaches and is invisible (but ctrl-alt-t does not show it), and all child prims are visible. Rightclick root prim, and it becomes visible, even though it's supposed to be invisible.

4. Seems that right-clicking the disappearing prim when it's in HUD causes the prim to re-appear, whether or not it's supposed to have alpha=0 or 1. i.e. the disappearing prim does not appear to be linked to llSetAlpha(). However, in the case where the prim disappears on being dropped on the ground directly from the HUD, the prim/object is NOT clickable at all (and of course is not visible on ctrl-alt-t).

[ Permlink | « Hide ]

Lulu Ludovico added a comment - 10/Jul/07 05:58 AM

Just a quick update. The bugs are still here in the optional viewer 1.17.3(1).

[ Permlink | « Hide ]

Simil Miles added a comment - 16/Aug/07 04:53 PM

I noticed that single prims are not affected, the bug appears with linked prims.

[ Permlink | « Hide ]

Lulu Ludovico added a comment - 18/Aug/07 05:50 AM

I believe I managed to repro the bug with a single prim a while back, but it was inconsistent. It seems that if the single prim had enough busy scripts in it, it would also trigger the bug. Perhaps it has something to do with memory management?

[ Permlink | « Hide ]

LadyStar Cosmos added a comment - 29/Sep/07 10:26 AM

Mines done this for months even after creatorreplaced huds... PLEASE FIX SOON!!!!!!!!! cant use 1/2, my avies due to it

[ Permlink | « Hide ]

meade paravane added a comment - 01/Oct/07 01:59 PM

I think there's either more than one variant of this bug or the test cases might have more in them than necessary. Lately, I've been seeing all but the root prim of a HUD I made vanishes about 50% of the time on sim crossings. A right-click on it brings the whole thing back.

HUD is 8-10 prims or so, no alpha or texture stuff in it- it's just an llSetText on a timer and an llSay on touch in the root prim.

[ Permlink | « Hide ]

Monica Balut added a comment - 13/Nov/07 04:40 PM

I consistently reproduce this bug with a single prim object just using a blank texture with 0% transparency as long as I call llAttachToAvatar from a rezzed object. In other ways it behaves exactly as described above.

[ Permlink | « Hide ]

oryx tempel added a comment - 24/Nov/07 04:01 PM

Consistent recurrence with the I Am Legend HUD.

Choose the Infected avatar and HUD. HUD randomly fades. Says it's still worn in Inventory but the Titler can't see it, and I can't detach it from myself.

Also consistent recurrence with the SEmotion AO HUD. The HUD in question has only two buttons and the upper most button, "Show" seems to randomly fade, regardless of use/non-use. Most often fades after multiple successive transports.

[ Permlink | « Hide ]

oryx tempel added a comment - 18/Dec/07 05:57 AM

I've attached 2 additional pics; "Good HUD pic" shows what my HUD should look like. "Bad HUD pic" shows what it looks like after multiple rapid teleports.

[ Permlink | « Hide ]

oryx tempel added a comment - 18/Dec/07 05:58 AM

Oh, adding this comment to remark that multiple rapid teleports were practiced using Search/All (the new one) and not with Landmarks. Dunno if this makes a difference.

[ Permlink | « Hide ]

oryx tempel added a comment - 18/Feb/08 06:53 PM

Update on this issue: Occurs specifically at sim crossings. Was recently in Grendal's Children, walking from one sim to another (Avaria to Avaria Tor) and half the HUD disappeared. This is a complex dragon HUD so was instantly noticed upon sim boundary crossing.

[ Permlink | « Hide ]

Torley Linden added a comment - 22/Feb/08 05:56 AM

This should've been fixed in WindLight 1.19 (80044), see: http://blog.secondlife.com/2008/02/15/new-small-update-windlight-viewer-80042/

But, I note your comment, Oryx – do you have a more reliable/solid repro for this? I'll keep the issue open for now.

[ Permlink | « Hide ]

Beezle Warburton added a comment - 07/Mar/08 12:51 AM

The blog claims this is "Fixed" in 1.19.1 RC0

"~~VWR-434~~: HUD textures are attaching but not being seen"

I will be posting a screencap that show otherwise. The textures do show up after clicking on the HUD, as shown.

Unfortunately, this is random – it can occur either after a TP, sim crossing, or initial attachment of the object.

[ Permlink | « Hide ]

oryx tempel added a comment - 22/Apr/08 12:21 PM

Thanks Torley, I haven't noticed it lately, but I'll keep my eyes open and see if I can get a solid repro. Seems to happen most often at sim crossings, rather than inner-sim teleporting.

[ Permlink | « Hide ]

Ramzi Linden added a comment - 24/Jul/08 03:36 PM

Internally, we have been tracking this bug as fixed in 1.19.1.
I know it has been re-opened once, but we will need more information about how to reproduce it, in order to make any additional progress addressing this issue.

[ Permlink | « Hide ]

Roberta Messerchmitt added a comment - 29/Jul/08 01:23 AM

I have a variant of this bug that is so far 100% reproducible. Any time i use the 'attach to hud' menu selection to put a hud anywhere besides the default location it fails to appear on the screen. It is in the inventory as worn, but it is not anywhere on the screen (even zoomed out, it is not attached outside the visible area) and clicking around where it should be does not do anything using the release candidate viewer. It does this in both windows and linux. One hud (an rp weapon control hud) had a scanner option that was not turned on when i took it down to move it and when i put it in center it failed to appear like the others but the scanner namelist appeared all jammed into one line in the center of the screen and clicking did not do anything as above and even edit would not find it (and i grab invisible objects all the time inworld to edit so i know it works on normal invisible objects).
As an experiment i downloaded the current version of the realXtend viewer (which is based in part on the regular viewer from what i heard) to see if the bug was there too. When i attempted to attach a (copyable) hud to an alternate location a featureless blue rectangle of about the same size and color (but different rotation) as the hud base appeared where it should be on the screen and clicking on it in either the realeXtend or Linden viewer activates it though the menu will not come up to set the options (it acts like everywhere on the block is the activation button) which also seems to indicate the hud is at the location, just not functional.
The viewer i have is the current 1.20 rc version for windows and the equivalent one for linux. I have a dual core amd64 system with nvidia chipset and an nvidia 7300 video card if that makes any difference.