EnCore Mayne

sounds like an unfortunate development cycle. oopsie. i have no idea how the lab communicates, produces, releases, and maintains features. (please don't suggest JIRA's an element for more collective interaction.) i'm sure the dev ignorance isn't unique to just me. the more of us distanced from the who, what, where, when, and why the farther separation there is between the actual users from the codersgods.

amazing. i really have to keep up. matterafact, where and when did this new feature hit the pipe? was there ever any announcement or community feedback on record? i'm always the last to know.... i suppose if one's not aware of the feature one can't complain when it doesn't work or when the rug's pulled out mid stream. sigh.

i'm seeing a heightened frequency of this error. can someone explain what this means? i tried it on a body point and couldn't tell if anything was happening. as much as i can figure the "rigged" term indicates it's been weighted, no? i'm at a loss as to why someone would include a rigged mesh item in their HUD. attaching a rigged mesh to a HUD doesn't show up at all. aside from the warning everything else of the design is visible and functional. is this a designer mistake or are there other reasons for doing this? even experienced designers are doing this? is this an error or undocumented feature?

if i interpret your language properly, you've made prim based HUDs for an invite that plays .wav files and detaches on touch. now you'd like to know how to animate the user using a mesh based HUD design? if that's right, firstly mesh won't affect the HUD's scripted performance unless you have to associate its "faces" for any events. being this is the scripting forum i'm assuming your difficulty is in animating the user. you'll need permissions for that llRequestPermissions(willing participant, PERMISSION_TRIGGER_ANIMATION). what event that request goes is up to you. start_event, touch_start, on_rez, change, ..., etc. in your run_time_permissions event check for perms granted, put an llStartAnimation(name of animation) in there et voila, you got them dancing, yeah.

not reasonable. but effective.

get.more.ram. 32g minimum.

you are probably referring to AVsitter. it's far from simple but if you follow the instructions it gets easier every time you make one.

happening for https://forums-archive.secondlife.com/ too. i put a report into JIRA about it. edit: the JIRA was closed by "Spidey Linden" with the rational that it was a duplicate. the referenced duplicate (created after mine) was closed due to it being a duplicate of mine. you can't make this sh*t up. any wonder why they are letting their certs lapse?

good luck ever matching various designers head body skins. the key is full body/head skin from the same designer.

one of those coalesced objects may have had permissions that lead to your cluster never being able to be rezzed again at all forever.

could depend on your body's AO. Maitreya has a switch to turn off hand animation in their tabs somewhere. it might have something to do with your priorities too. i set all my bone priorities to 5.

the usual practice for edit mode inspection is do it twice. first time won't show anything, twice is the charm. a more efficient manner is to use right click>Object Profile. it'll give you links to owner/creator. right click>Inspect will give you finer details on all the subcomponents of the object. only the edit mode will give you the guts in the Contents if that's what you're looking for.

if i had known that at the get go i wouldn't have had to endure the infamous SL learning curve. thank you arton.

bit a fiddling in zooooooom and it's all together. only 2LI. so how come uploading the whole thing won't work?

if there's no solving this issue it might come down to it.

the problem is i get random results with the exact same .dae. i've tried many uploads. nothing consistent. i've tried parenting the left and right items to the main too, but it doesn't change anything. the key i've learned is to ensure the distinct objects within the whole design (geometry) are named alphabetically so that the root is always A of an A,B,C design. no matter where each part is in the outliner tree, the root selection is the mostest primaryest letter alphabetically. A as opposed to Z. A is higher than Z? or is that lower? sheesh, these computers, i tell ya.... i've left a "multiple test.dae" file over on the Firestorm JIRA if anyone's keen to wrack their brain on the issue. https://jira.firestormviewer.org/browse/FIRE-32832

i have a multipart design that the Uploader keeps associating random root placements to it. i never paid much attention before, not having done many multipart designs, but in this one there's distinct rotational axes applied on each part. it's important that the root is associated correctly to the mesh inworld. as it stands now, the Uploader has no consistency in how it determines which part it decides is going to be root. one time (done on the Beta grid) it'll be correct then the next it'll rename the geometry's name given in Blender2.79 and associate that part as the root. next time it'll be the opposite part, etc. nothing i can trust to upload onto the main without incurring disastrous expense. i wrote up a bug report at FS'd JIRA but the handler over there pawned it off to LL since "he said" they copy/pasted LL's uploader code so it's their problem. that leaves me kinda dead. anyone know what's happening or what i'm doing wrong to get such odd results?

we bear such an arduous burden upon our freedoms... nonetheless, i thank you for your compromises to the man.

my expectations are for NOW. if i have to rtfm it's for a problem i've encountered from not wading through excessive mumbo jumbo to get to the solution. BTW: "seriously should considering" should be "seriously should consider". my language skills are far better than my appreciation for most technical instructions written by non literate techies. really, most coders don't have any idea what they're talking about or how to explain things to their end users. if it's not intuitive yer doing it wrong.

maybe cause it's an attachment? i'm using Firestorm. could be the uploader too. things were a bit wonky in the beta grid. or just my lack of concentration. i can try again but i'm fairly sure it wouldn't take without the triangle with a normal.

a single pixel used for the extension to precisely place the pivot point (origin) does not work. three vertices (without having a face) does not work. 3 verts with a face works. and, for anyone beating their heads on their desks, if there's more than one pivot point, as my example has, don't reapply a rotation once any part has been set. each part requires reorientation in the 3D view window for the rotation to be applied to that specific part. live and learn....

read the Pre-Download Page? hahahahahahaha. you have to be kidding. no one's got time for that. there's an encyclopedia hiding behind those links. i just know it. i aint gonna go there. gimme the executable now! my mistake doesn't relieve you of responsibility ya know.......[sarcasm].

seriously. it's not a good look. for a casual user it's probably a dead end. if i hadn't skimmed through your Discord's voluminous array of problem solvers i would have had no idea these files were above your skills to put into your setup installer. NSIS is script-based and allows you to create the logic to handle even the most complex installation tasks. Many plug-ins and scripts are already available: you can create web installers, communicate with Windows and other software components, install or update shared components and more. do you need someone to look into getting this done?

why not install the redistributables in the BD install?