EnCore Mayne

unanimous? caught me looking that one up.

hmmm, a cheap way of having the bedspread simulate movement would be to script an incrementally larger portion of the existing mesh to be transparent. so you start with 100% showing and end up with 20% or so over a sufficient amount of magical movement time. not sure it can be done scriptwise, but someone in the scripting forum would know.

anyone know what this is all about? came up after i tried to log into JIRA.

split off a small portion of your parcel and configure that for a separate location from your main landmark.

if you want to simulate a bedspread you'll need a number of models representative of various states of animation. the single full perm example you have illustrated here won't work.

not sure if anyone's still watching the original issue but apparently, from the one instance i've just experienced, the lab has managed to revert the email notifications to their previous glory. Oh Lindens should the commoners not have some sort of way to acknowledge your fixes outside of the Jira's current "CLOSED No Comments Allowed"? might the coder's pseudonym be attached to the fix aussi? or is everything inside the lab pretty much sealed up from human interaction? (asking for a friend)

if the LabRats could be made to concentrate on gradually fixing all the problems accumulating in the Jira i'd be more confident of hiring a marketing techniphobe.

looks like your submission duplicating mine have both been accepted, recognized, triaged, & resolved (closed) by the Lindens. "We've since identified the issue and have a fix underway, which we're hoping to release soon!" -Shrike Linden cudos to the labrats. now if we could get them to order my outfits window.

https://jira.secondlife.com/browse/BUG-232062

thanks Lucia. didn't check that blackhole of customer relations metric.

resolved: it was the region. for whatever reason, and it certainly wasn't what's stated in the error message, i'm able to tp to it without a hitch now.

i can understand that usecase Marianne. unfortunately, in this particular circumstance, i'm getting this error message for a specific region: http://maps.secondlife.com/secondlife/Yakuza/62/137/2502 (Asteria mainstore). it's not the frequency attempts. i just logged in after hours offline. first attempt brought up the error.

in all the time in SL i've never seen this one before. i've seen Teleport Failed before but never with a limit. funny thing (not funny haha), i'd been shopping for some length of time (more than a minute) on one region and had not teleported at all and when i did this error came up. more hilarity later, i relogged and got the same thing.

you have got to be kidding me!

one word: Torley

heard about SL from a TWiT podcast in 2006. fudged joining right away since i didn't have the system requirements. got a brand new EuroCom laptop for school, signed up, and never looked at the world the same.

gotcha, i will suspend with the accolades. no need for resolving the issues i was having. i've addressed what anomolies i encountered to my awefilled delight. (repressed admiration blurb here.) if anyone else runs into this thread i should say that the Earth's spherical texture was a real bugaboo. seems those prims have to be painted with the X axes as the poles. your code has the Earth's Z axis as the poles. believe me, i coulda used a shoulder to cry on. but i figured it out. changing: rotation year_to_earth_orientation(float t) { return llAxisAngle2Rot(<1,0,0>,t*365.24*TWO_PI) * // daily rotation. llAxisAngle2Rot(<0,1,0>,-66.5*DEG_TO_RAD); // axial tilt. } hit me up inworld if my "buttering-up" turns into reciprocal generosity. i'm good for somethings, you just have to find out what.

thanks for spending your time helping Tessa. i'm not quite sure how you would classify it on the productive scale, but it's really really benefitted me. if i recall, weren't you looking for someone to aid you in developing some code to get an .anim importer working? i've got plenty of .anim files should you ever need them just holler. now, in the hope that i don't bore you or fail to challenge your astute abilities i put your code to work and came away with a couple of issues. i haven't toyed with it much, so i'll get back to fiddling with it, but i'm absolutely certain i can't make it do what i want with what you've shared. if you come back i'll give you some details.

that looks absolutely devine Tessa. i knew it might turn out complicated, but trigonometry! i never! having a quick look over, i'll give it a go laterz, i can't suss exactly why it is there needs to be 3 prims. don't tell me you can get a moon working too. (a hush blankets the audience) as to the daily revolution of the earth, if indeed it's within the code to accomplish said feat, i'm sure i can alter some of the bits to simulate a pleasing, if not totally accurate rendition.

for some odd reason i've yet to fathom, i'm using llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_ROT_LOCAL, quaternionchange * quaternionangle]); for the sun's rotation. it's set for a touch event that increments the rotation quaternionchange using a clever snippet that i have where i can input human sensible angles (floats) into a code that requires the dreaded rotation. as such: quaternionchange = llEuler2Rot(<-newangle, 0.0, 0.0> * DEG_TO_RAD); the newangle is currently set for 22.5° so i can see visually how the set appears in testing. i've attempted several forgettable failures to get the Earth's axial tilt to stay put while the sun (and attached earth) wheel merrily about. each one ending with more weirdness than the last. essentially, as the idea stands now, i'm sending a llMessageLinked to the earth everytime the set is touched. that's handled in the Earth's code to maintain its orientation by using: llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_ROTATION, stable ] ); the stable variable is initiallized in the state_entry as stable = llGetLocalRot(); unfortunately, that doesn't work to reset the Earth prim's orientation back to the original rotation (as it has in other funtime playthings i've created). anyone have any ideas to achieve the intended stablility of the Earth prim? as far as using a llGetTime() i'm not sure real time's gonna work for this simulation. i was thinking a full "yearly" rotation could be discernable to a user's given moment of attention.

i'm not sure whether it's possible, so where best to ask...? i'm thinking of crafting a simulation of the Earth's rotation around the Sun. simple enough if the Earth's polar rotation isn't considered. i can do that much. however, i'm also considering having the Earth's proper 23.5 degree axial tilt maintained too. in that lies the rub. is there some code to lock the Earth prim's orientation while being attached to the rotating Sun? (as i have it so far, i've got an animated texture on the Earth that simulates daily rotations but no way to ensure the north pole is always at a fixed orientation.)

excellent results from all of you, once again. i thank the community for its wealth of knowledge. i now perfectly understand the addressed phenomenon. i am your humble servant. for anyone still wondering, i crafted this routine to automate the setcamera vectors. it works for that so i'm saved from the indomitable brain crushing mathematics of figuring them out manually. thinking that i had a world changer for healing (heeling?) the backwards default camera pose position (who thought of that?) will have to wait. explaining the potential wild behaviour to a prospective user would inevitably have them weighing convenience against complicated incomprehensible details. nonetheless, i'm happy with what i hath wrought. if my life's made happier, isn't everyone's? btw, cudos to the nameless faceless entity who's corrected the wiki formatting. have the gatekeepers been vanquished? might normal people be given the privilege to add/edit pages next?

you coulda just said it was a pile a poo, Jenna. how do i verify the camera control perm? in the conditional? [> if (perm) <] should be more specific? having the crucial camera settings in the listen is a no no? i threw in llClears in just about every event there was. note futility. this is for a single avatar.

i physically reset the script from the button in the contents tab. there's no llResetScript() ... yet. as to the requests on sit, i have trigger_animation, track_camera, and control_camera. in my run_time i put in a conditional for whether the camera had or had not been set. if it had been set it just passes through (only animating). if it hasn't been set, the camera is set at a default position in front of the poseball and a dialog comes up providing a button to Save the camera where the user positions it. that all works fine in testing except the earlier setting (made before resetting) persists. so, to make it work i have to sit twice. on the second sit, the default camera setting i put into the code works. i'd rather not have the next user have their camera go wild if they're in another region. if it helps, here's the rough layout i'm working with: dialog (key av) { "Save" button } state_entry() { camera setting = FALSE; llClearCameraParams();//this may speak of my futility } changed(integer change) { if (change & CHANGED_LINK) { if (llAvatarOnSitTarget() != NULL_KEY) { llRequestPermissions(llAvatarOnSitTarget(), PERMISSION_TRIGGER_ANIMATION | PERMISSION_TRACK_CAMERA | PERMISSION_CONTROL_CAMERA); } else { llStopAnimation(llGetInventoryName(INVENTORY_ANIMATION, 0)); llClearCameraParams(); } } } run_time_permissions(integer perm) { if ( perm ) { llStopAnimation("sit"); llStartAnimation(llGetInventoryName(INVENTORY_ANIMATION, 0)); //this is where the dialog on first sit comes up //BUT //somehow, it only sets correctly if i unsit and sit again. //first sit has the last setting saved. if (set == FALSE) { llClearCameraParams(); llSetCameraEyeOffset( <2.5, 0.0, 0.0> ); llSetCameraAtOffset( <0,0,0> );//looking at selections(llGetPermissionsKey()); } } } listen() { if (message == "Save") { llClearCameraParams(); camera settings voodoo camera setting = TRUE; } }

i'm working on an animation script that sets the camera parameters from a dialog. aside from all the usual insanity of trying to script anything, i've managed to get close to what i intended. of course, close isn't what i wanted. i actually wanted to clear the camera parameters on resetting the scripts. i've got llClearCameraParams() at a number of places, unsitting, state_entry, listen, changed, and run_time_permissions. if there were other events, i'd put llClear.. in that too. unfortunately, on resetting the script, the earlier setting remains on first sit then it's cleared on the second sit. any hints as to why that might be? i don't have a workaround. is there something funky about llClearCameraParameters() i'm missing? can i clear it so it's cleared on a reset of the scripts?