Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0008219opensim[REGION] OpenSim Corepublic2017-07-27 06:442019-02-06 11:29
Assigned ToLotek 
PlatformLinuxOperating SystemUbuntuOperating System Version16.04LTS
Product Versionmaster (dev code) 
Target VersionFixed in Versionmaster (dev code) 
Summary0008219: Newly made clothing/bodypart missing after creation
DescriptionAfter making a new wearable, it is shown as missing when worn. This is especially noticable on a second viewer which does not have the new item cached, OR by clearing cache, relog and then wear the item.

* This is NOT a robust bug but a simulator 0.9 bug
* Only happens in OpenSim 0.9, in OpenSim 0.8 all is OK
* Especially triggers when chosen a texture to use on a clothing layer. It could be the item was succesfully created, but it is reported as missing because the UUID's of the used textures are not properly retrieved.
* Also happens to non-clothing system layers: shape, skin etc - they will be replaced by the Ruth shape/skin/etc
* Does not happen with newly copied/aquired objects, only wearables
Steps To Reproduce1) In inventory, create a new shirt
2) Give the shirt any texture. Can be from the default library or an uploaded texture.
3) Unwear it and log out

4) Either clear cache and relog
   Relog using a different viewer (in which the new item is not cached)
5) Try wearing the item (it will fail)
6) Observe the blue viewer popup. Messages:
   * Replaced missing clothing/body part with default
   * Failed to find clothing named x in database
   The new item is not worn and replaced by a generic plain white clothing (or ruth body part)
Additional InformationThis is an issue that I wrote about on the OsGrid forum also but it appears not to be limited to OsGrid, it happens on any 0.9 simulator: [^]
TagsNo tags attached.
Git Revision or version number8739ceb00f34c618634983b25330a21f60eafe6d
Run Mode Grid (1 Region per Sim)
Physics EngineubODE
Script Engine
EnvironmentMono / Linux64
Mono VersionNone
ViewerAll viewers
Attached Fileslog file icon viewer creation undershirt.log [^] (444,599 bytes) 2017-07-27 18:01
log file icon viewer wearfail undershirt.log [^] (430,569 bytes) 2017-07-27 18:01

- Relationships

-  Notes
UbitUmarov (administrator)
2017-07-27 11:14

You need to own the textures and have Modify, Transfer and Copy rights
Library items may not work correctly, make a copy to your own inventory.
and do
1) In inventory, create a new shirt
3) change it
4) save it
aiaustin (developer)
2017-07-27 14:15
edited on: 2017-07-27 14:23

Were there some changes to not persist textures in objects? Would this apply to wearables too? Could this be a root cause of the change in behaviour between 0.8.x and 0.9.0 dev master?

UbitUmarov (administrator)
2017-07-27 14:16
edited on: 2017-07-27 14:18

... yes.. changes on 0.9

aiaustin (developer)
2017-07-27 14:23
edited on: 2017-07-27 14:24

@Ubit... surely full perms on an applied image and need to change a wearable should not be required? Just creating it should be sufficient for it to persist. And adding any image you have in inventory to a wearable and saving should work and persist even if its not removed and reworn?

UbitUmarov (administrator)
2017-07-27 14:38

we are not supposed to create for example a wearable using textures without rights, and get a full rights wearable.
this restrictions do address that, possible not the best way.
Lotek (reporter)
2017-07-27 18:04
edited on: 2017-07-27 18:11

Since the simulator doesn't log anything of use, I attached two viewer session logs:

First session is the creation of a new undershirt, then unwear, then logoff
I total cleared the viewer cache at this point
Second session I try to wear (and fail to wear) the undershirt

aiaustin (developer)
2017-07-28 00:59
edited on: 2017-07-28 02:00

It would make sense to create the wearable properly and have it inherit the most restrictive permission on any texture used.

Surely that would be needed anyway if a wearable has a change of texture that is partial perm?

melanie (administrator)
2017-07-28 01:40

Even creating a restricted wearable would allow the creator to wear it, which is infringing already. Textures to be used on wearables must be full perm. This restriction is enforced by the vanilla SL viewer but LL never enforced it serverside. TPV have been dropping this enforcement and so now allow to drop a texture with lesser perms.

At the time this serverside restriction was written, the viewerside restriction was still in place across TPV, so the only time this was supposed to trigger was in the case of copybot uploads.

Now, that this can be triggered by users, of course a more nuanced approach and notification is required. However, the end result must be that a non-full perm texture is not applied to the item.
aiaustin (developer)
2017-07-28 01:59

Thanks for that background @Melanie. That's useful to know. So the issue seems to be that for users of viewers like Firestorm they appear to be able to do something but the change is not persisted and they don't get a warning or message to correct them.
Lotek (reporter)
2017-07-28 05:02

I only tried this with full perm textures, either self-uploaded or the ones from the Default Library. In the viewer logs above the texture applied to the undershirt is a fullperm texture I uploaded.

I set my viewer 'Default upload permissions' settting to full perm for any kind of new inventory and always advise others to do the same (at least for textures) so the final object/clothing perms aren't messed up. There are a lot of freebies in OpenSim that are nocopy/nomod.. just because the textures they used in it are by default (after uploading) nocopy/nomod.
UbitUmarov (administrator)
2017-07-28 09:53

changed code on master.
Users should now get a notification when the operation is refused, and it should be aborted not creating a damaged item, like happened before.
Lotek (reporter)
2017-07-28 10:25

@Ubit: looks like your new commit in master fixed this bug :)
Will do some more extensive testing and then mark this fixed
UbitUmarov (administrator)
2017-07-28 10:27

well it should had not changed use of full rights textures as you reported
guess updating did change also something else
aiaustin (developer)
2017-07-28 10:55

One typo in that last commit @Ubit... in the error message.... "enought" should be "enough"
aiaustin (developer)
2017-07-28 10:59

I wonder if this could explain frequent messages I get on assets broken or not found on some grids for AOs and attachments with scripts. If the textures, gestures, animations, scripts, etc in those do not have (mostly will NOT have) FULL perms but they will allow for copy, modify, etc.. but perhaps no transfer or export.
UbitUmarov (administrator)
2017-07-28 11:10

this check is new on 0.9
there are many other reasons for that to happen :(
Lotek (reporter)
2017-07-28 11:28

The problem I had in this particular bug is gone now. However:

When reading your commitdiff I think it was supposed to give an error when picking a nonfullperm texture, based on Melanie's information above.

That new part isn't working; i can use the picker to choose any nomod+nocopy+transfer texture and won't get an error.

The resulting new clothing will be fullperm (or whatever default new perm you have set up for wearables).
UbitUmarov (administrator)
2017-07-28 11:30

no.. checks are on the upload process only
picks etc are viewer side, viewer sends us a new asset when you do save
till then we see nothing, so can't so nothing.
UbitUmarov (administrator)
2017-07-28 11:32

err those checks are the ones Melanie said viewers used to have..
Lotek (reporter)
2017-07-28 11:58

Ok everything is working now. Thank you Ubit :)
BillBlight (developer)
2019-02-06 11:29

Marked as Resolved but never closed, can be reopened if needed.

- Issue History
Date Modified Username Field Change
2017-07-27 06:44 Lotek New Issue
2017-07-27 06:54 Lotek Severity major => minor
2017-07-27 06:54 Lotek Reproducibility always => sometimes
2017-07-27 11:14 UbitUmarov Note Added: 0032187
2017-07-27 14:15 aiaustin Note Added: 0032188
2017-07-27 14:16 UbitUmarov Note Added: 0032189
2017-07-27 14:17 aiaustin Note Edited: 0032188 View Revisions
2017-07-27 14:18 aiaustin Note Edited: 0032188 View Revisions
2017-07-27 14:18 aiaustin Note Edited: 0032189 View Revisions
2017-07-27 14:23 aiaustin Note Added: 0032190
2017-07-27 14:23 aiaustin Note Edited: 0032188 View Revisions
2017-07-27 14:24 aiaustin Note Edited: 0032190 View Revisions
2017-07-27 14:38 UbitUmarov Note Added: 0032191
2017-07-27 18:01 Lotek File Added: viewer creation undershirt.log
2017-07-27 18:01 Lotek File Added: viewer wearfail undershirt.log
2017-07-27 18:04 Lotek Note Added: 0032194
2017-07-27 18:11 Lotek Note Edited: 0032194 View Revisions
2017-07-28 00:59 aiaustin Note Added: 0032198
2017-07-28 01:40 melanie Note Added: 0032199
2017-07-28 01:59 aiaustin Note Added: 0032200
2017-07-28 02:00 aiaustin Note Edited: 0032198 View Revisions
2017-07-28 05:02 Lotek Note Added: 0032201
2017-07-28 09:53 UbitUmarov Note Added: 0032202
2017-07-28 10:25 Lotek Note Added: 0032203
2017-07-28 10:27 UbitUmarov Note Added: 0032204
2017-07-28 10:55 aiaustin Note Added: 0032205
2017-07-28 10:59 aiaustin Note Added: 0032206
2017-07-28 11:10 UbitUmarov Note Added: 0032207
2017-07-28 11:28 Lotek Note Added: 0032208
2017-07-28 11:30 UbitUmarov Note Added: 0032209
2017-07-28 11:32 UbitUmarov Note Added: 0032210
2017-07-28 11:58 Lotek Note Added: 0032211
2017-07-28 11:58 Lotek Status new => resolved
2017-07-28 11:58 Lotek Fixed in Version => master (dev code)
2017-07-28 11:58 Lotek Resolution open => fixed
2017-07-28 11:58 Lotek Assigned To => Lotek
2019-02-06 11:29 BillBlight Note Added: 0034425
2019-02-06 11:29 BillBlight Status resolved => closed

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker