Jump to content

Frankie Rockett

Resident
  • Posts

    71
  • Joined

  • Last visited

Reputation

6 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi It happened to me some years ago that a then-current edition of Firestorm opened it's World Map for me, minus the 'Legend' section to the right side of the window. So it was all just 'map'. No filters, no text / search fields. Just all map. It took me a mountain of trawling the 'net to find a solution, which I think was probably a key combination or somesuch, and hey presto, the Legend and it's UI appeared! I never had to do it again thankfully. The full World Map was always there from then on. Now I'm helping a noobie and his World Map has the same problem. Except this time I can no longer find the fix. It's certainly not mentioned on the Firestorm site in the 'World Map' section, which is especially annoying. Do any of the resident experts and assorted denizens of these pages know the phenomenon I am describing, and it's solution? Thank you for your thoughts.
  2. Tessa. Thank you for that tip. Yes I see the problem. I won't go down that road I think. Quistess! Excellent! This is the answer I've been searching for then. And I tested it and it works well in terms of volume. However, it's intruduced a majot problem. I notice that the sound slices (each 9.9 seconds long, and I have 27 of them), start to intruduce an audible 'thump' at the join points, which, over time, gets worse, revealing itself as an audible gap before we're half way through the piece. This wasn't happening with llTriggerSound, so I'l guessing it's a llPlaySound artefact (or bug?). I am using llSetSoundQueueing(TRUE); to stop things bumping into each other. I also use LlPreloadSound in a loop, 27 times, omne for each piece of sound. Actually on re-re-testing, since switching to llPlaySound, it now inserts large gaps, say 6 seconds, then re-plays the last section again, then resumes on the last-but-two, threby missing a piece out. It does this consistently. To put that visually, it will be playing say, part 9, then it behaves like this: part 9 part 10 (silence) part 10 part 12 ...and so on. Any ideas? Footnote: I 'may' not be able to respond until the New Year at this point, but I shall follow your thoughts and respond soon!
  3. Hi A quickie this I suspect. We all know the strange swirling 'snow' around an object with an executing script in it but I wonder if there's any way to suppress it / remove it entirely? I am preparing a kind of show in which I'd like certain prims to fade from transparent to visible (and back), but the smooth fades are rather ruined by snowstorms as it happens - see attached illustration for added clarity: I hope this isn't an effect that can only be controlled the viewer Here's hoping it's scriptable. I didn't really want a White Christmas; can anyone help clear the drive? Thank you!
  4. Thank you both Quistess and Fenix. Quistess, it sounds (definitely no pun intended) like llPlaySound will conquor the movement effect I was seeing/hearing. Do you think attaching it anywhere in particular will maximise the sound volume? That was my main hurdle here.
  5. Hi All I currently have an audio file (cut as required into plenty of 9.9 sec long pieces!). If I play it in-world and fix my camera up close to the object that contains it, I get the best audio experience. That is - loudest volume. However I would like the object with the audio to attach to the avatar and maintain the best possible volume as the avatar walks around. Think 'museum audio guide' kind of function. While I have it all working - triggered by wearing, I find two undesirable and very disappointing effects: 1) as soon as the avatar walks, pulling the camera back and above the avatar, the volume drops off markedly, as we distance our view from the Av and it's attachment a little. Attaching to the HUD is no better, for while it doesn't make the volume rise and fall, it's pitched at some mid-way point - a lot quieter than camera-ing close on the attached object. 2) I notice that the sound seems tied to a particular place. If I 'teleport to click position' in a region, I leave the last 9.9 second portion of audio back where I was standing, and it's not till the next 9.9 section piece enters that the volume returns. All in all the audio seems like a mess! Is there any way or ideal attachment point that I can play the audio constantly at maximum achievable volume )for any given viewer-volume setting)? Thank you!
  6. Thank you Qie. You are clearly correct. Doh! It is time not distance!! And the 0.1 - my error. No idea how that crept in but changed to 0.0 now. I corrected the use of 1/45 and tried again. No change to performance though (unless I didn't really correct it?). Still quite jittery. After observing it several times I note two things about the jitter. 1. The avatar's seated position varies slightly during the journey, as if the cube it's sat on is trying to pull away, out from under his bum. 2. After repeat viewings, I can confirm that during the transit of the prim, my own camera jitters and shakes to a disturbing degree. This is regardless of whether I fix my viewpoint on the movement or look somewhere else entirely, or even change my focus from place to place. Whether the prim too is shaking during transit I cannot say. I'd need to log in an alt and watch from that point of view to be certain, but for the 'first person' it's horrible, and not, I note, an effect duplicated with llMoveToTarget. Here's where I'm up to with it. integer speed = 1000; // Less is faster! rotation NormRot(rotation Q) { float MagQ = llSqrt(Q.x*Q.x + Q.y*Q.y +Q.z*Q.z + Q.s*Q.s); return <Q.x/MagQ, Q.y/MagQ, Q.z/MagQ, Q.s/MagQ>; } default { state_entry() { llSetLinkPrimitiveParamsFast(LINK_ROOT, [PRIM_PHYSICS_SHAPE_TYPE, PRIM_PHYSICS_SHAPE_CONVEX, PRIM_LINK_TARGET, LINK_ALL_CHILDREN, PRIM_PHYSICS_SHAPE_TYPE, PRIM_PHYSICS_SHAPE_NONE]); speed = (integer) (speed * 0.022222222222222); } touch_start(integer total_number) { vector ownPosition = llGetPos(); rotation ownRotation = llGetRot(); vector detectedPosition = llDetectedPos(0); rotation detectedRotation = llDetectedRot(0); llSetKeyframedMotion( [<0.0, 250.0, 0.0>, NormRot(ownRotation), speed], []); } }
  7. Hi Qie! Thank you for confirming your test worked. I re-tried it, making sure that it was set to run. It was. Then something strange, inexplicable, happened. I hit Esc as you suggested - Bam! It worked!! One hit of Esc only. Fabulous! I stood, and tried again. Second time it worked as it should - no need for Esc. A third and fourth time and it continued to work. I should say by 'work' I mean it still won't bother to give me a Permissions dialogue, but it does move the camera as intended. Unfortunately in the grand scheme this hasn't solved the failure to generate a Permission dialogue but honestly, I'm happy to live with that at this stage. Every problem has a cost/benefit calculation and this one has exceeded it's own budget! You and and Quintess have given so much of your time energy and wonderful insights to this problem. Between you have got it WORKING! - never mind the nicety of permissions at this point. If any user is unhappy and wouldn't have given permission, they can just stand up again! Also I have to bow out of this forum (for now) due to RL pressures around Christmas RL, so sincerely - thank you. If you do feel interested in sharing further thoughts or comments, I will see them and respond in the New Year. So for now - thank you, and have a Happy Christmas/Holiday!
  8. Hi! Thank you for that important piece of fine tuning information Rolig! Well, after a little play with the new (to me) function, I am disappointed. A main reason and a picky, secondary reason. Picky one first. The drift happened even when dividing distance by 45. I made a simple prim to sit on and moved the prim each time I clicked it. Over some 250m I found the prim drift upwards by 2m. Changing the incremental distance traveled on each click from 12 to 100m, I found the upward drift to be much less. I conclude that drift isn't a function of overall distance traveled but the number of discrete steps to achieve that distance. Whether that's correct or not is, I guess, academic (to me). Now the main reason for disappointment is because movement really was quite jerky - in a region to myself with nothing else going on. Slowing the speed down only made the jitters more evident. I felt there wasn't a lot to choose between this keyframe approach and calling llSetPos repeatedly for a short distance in a loop (to control speed). Just to make sure this isn't due to my clumsy coding (I must admit I have cobbled this together from looking at examples!). rotation NormRot(rotation Q) { float MagQ = llSqrt(Q.x*Q.x + Q.y*Q.y +Q.z*Q.z + Q.s*Q.s); return <Q.x/MagQ, Q.y/MagQ, Q.z/MagQ, Q.s/MagQ>; } default { state_entry() { llSetLinkPrimitiveParamsFast(LINK_ROOT, [PRIM_PHYSICS_SHAPE_TYPE, PRIM_PHYSICS_SHAPE_CONVEX, PRIM_LINK_TARGET, LINK_ALL_CHILDREN, PRIM_PHYSICS_SHAPE_TYPE, PRIM_PHYSICS_SHAPE_NONE]); } touch_start(integer total_number) { vector ownPosition = llGetPos(); rotation ownRotation = llGetRot(); llSetKeyframedMotion( [<0.0, 12.0, 0.1>, NormRot(ownRotation), 30/45.0], []); } } Thank you for your thoughts.
  9. Thank you for the very compact re-write of my own rather verbose and inefficient original code Qie. After that things went downhill though. Not only does it continue not to put up the Permission dialogue, but also, it doesn't work at all. It doesn't move the camera anywhere. It doesn't execute any functionality. Yet you said "something like this seems to work". Have you tried it?? If so, how did your test differ from my own? I just rezzed a prim in a sandbox, put your code in and then sat on the prim. Nothing happened. What did you do that was any different? Thank you for trying anyway. It's much appreciated.
  10. Wow! Thank you Gang! There's a lot here for me to get into. I confess I have never ever played with llSetKeyframedMotion so I am very grateful to Fenix for introducing it and to Rolig et al for elaborating on it. People mention 'drift' and without experimenting I don't know how severe that is. I do know I plan to run several objects towards the viewer from a range of about 256m away, so I hope it can stick to a straight line for at least that long. Meanwhile I am very excited to go play with this key framed function and find out what it can do. Thank you - all! Frankie.
  11. Hi Quintess. Thank you for that. Yes, I wondered the same thing - that a now standing Avatar would return NULL_KEY. Thank you for confirming that. I don't follow/understand your second sentence though. " the permission requests in the functions themselves should be superfluous". Do you mean I can stop worrying about trying to get the explicit Permission request dialogue box up and just count this as 'working' after all? Thank you.
  12. Hi I am trying to send a physical object from A to B in a horizontal straight line, which is easy enough and I have that part working. However, I also want to be able to fully control it's rotation during movement. By 'fully' that means I may want a single 'barrel roll' during movement, or I may want it to rotate several times - independent control of all axis, so if wanted I can create a one or more axis 'tumbling' rotation during movement, too. Here's what I have so far: default { state_entry() { vector pos = llGetPos(); vector offset = <5, 0, 0>; // Move 5m 'east'. pos+=offset; llSetStatus(STATUS_PHYSICS, TRUE); llLookAt(llGetPos()+<0.0, 0.0, 1.0>, 1.0, 0.1); // Ignore - an experiment to prove to myself that I can force a rotation during movement. llSleep(3.0); // Not sure why a Sleep is needed but wont work without it. llMoveToTarget(pos, 1.0); llSetStatus(STATUS_PHYSICS, 0); } } Your thoughts are very welcome! Thank you.
  13. Hi Thank you Quintess. I tried your code (after adding back in the function calls!) and it executes as it did prior to your intervention, ie it works, sans any permission check. I did find that on the 2nd pass through the 'Changed' portion, the error message "Unable to find specified agent to request permissions" was generated, but this was ONLY generated upon standing - not sitting - on the prim! So I looked hard at the assignment "agent = llAvatarOnSitTarget();" and wondered if it was getting over-written between the stand and the sit? There's no way it can be, but that didn't stop me tying myself in knots trying to ensure that fact! Actually I assigned an opening vale of "00000000-0000-0000-0000-000000000001" to 'agent' (notice the trailing '1') so that I could later test as follows: if (agent == NULL_KEY || agent == "00000000-0000-0000-0000-000000000001") agent = llAvatarOnSitTarget() (Crazy huh? - but that's what this is doing to me!), and the resulting error message changed to: " Camera control currently only supported for attachments and objects on which you are sitting."!!!! If that's not a throw your hands up in the air moment, I don't know what is! So it looks like the only way this (theoretically) simple bit of script will run is if I ignore the fact that it doesn't ask for permissions, despite there being every reason in the world why it should. Very, very frustrating!!! Thank you for your very best endeavors though. The main thing is I have it working at all of course, and for that I am sooo grateful - to both of you!
  14. You are essentially echoing my own concern Qie - but admittedly much more articulately so! So the question remains; what should I do about it? If I check for permissions as you suggest, the check will fail and the camera won't move anywhere. It seems I have to find a way to really force the permission check, but I've tried everything I can imagine to force that already and it won't happen. How can I definitely force the permission check?
  15. Hi Gang! Thank you Quistess (and also Qie) for mentioning 'Disable Camera Constraints'. Actually I have that disabled by default so it's not an issue but thank you for your forensic attention to detail in helping nail this. I have success! But success bound up with mystery. Here's what happened. My test-bed was based on avatar touch to initiate perms request, and a second touch to move the camera. It was a pain and the only way to cancel the effect was to delete the prim and re-rez the prim. So I set about changing it to work 'on-sit'. Except nothing I did would trigger the permissions request this time. I tried moving the permissions request around so many times I was exhausted. In the end with them moved to a pretty obscure position, everything worked as intended - even taking the camera up to a height of 1000 meters. Yaay! Except one weird note - it no longer actually asks for permissions, it just... works. No permissions dialogue box pops up. Yet it works anyway. Here's the script: // Camera Controller // December 2022 key agent; take_camera_control(key agent) { llOwnerSay("Taking Camera Control"); // say function name for debugging llRequestPermissions(agent, PERMISSION_CONTROL_CAMERA); llSetCameraParams([CAMERA_ACTIVE, 1]); // 1 is active, 0 is inactive } release_camera_control(key agent) { llOwnerSay("Releasing Camera"); // say function name for debugging llSetCameraParams([CAMERA_ACTIVE, 0]); // 1 is active, 0 is inactive llClearCameraParams( ); } test_cam() { llOwnerSay("Changing Viewpoint"); // say function name for debugging llClearCameraParams(); // reset camera to default llSetCameraParams([ CAMERA_ACTIVE, 1, // 1 is active, 0 is inactive // CAMERA_BEHINDNESS_ANGLE, 0.0, // (0 to 180) degrees // CAMERA_BEHINDNESS_LAG, 0.0, // (0 to 3) seconds // CAMERA_DISTANCE, 3.0, // ( 0.5 to 10) meters CAMERA_FOCUS_LOCKED, TRUE, // (TRUE or FALSE) CAMERA_FOCUS, <500, 12, 1000>, // region relative position // CAMERA_FOCUS_LAG, 0.0 , // (0 to 3) seconds // CAMERA_FOCUS_THRESHOLD, 4.0, // (0 to 4) meters // CAMERA_PITCH, 30.0, // (-45 to 80) degrees CAMERA_POSITION_LOCKED, TRUE, // (TRUE or FALSE) CAMERA_POSITION, <500, 6, 1000> // region relative position // CAMERA_POSITION_LAG, 0.0, // (0 to 3) seconds // CAMERA_POSITION_THRESHOLD, 0.0 // (0 to 4) meters // CAMERA_FOCUS_OFFSET, <0, 0, 1.5> // <-10,-10,-10> to <10,10,10> meters ]); } default { state_entry() { llSay(0, "Script running"); rotation rot = llEuler2Rot( <0.0, 0.0, 270.0> * DEG_TO_RAD ); llSitTarget(<0.0, -0.3, 0.37>,rot); } changed(integer n) { // STANDING if(n & CHANGED_LINK) { agent = llAvatarOnSitTarget(); if(agent!=NULL_KEY) { take_camera_control(agent); } else { // llSetAlpha(1,ALL_SIDES); release_camera_control(llDetectedKey(0)); } } } run_time_permissions(integer n) { // SITTING test_cam(); } } I am very tempted to conclude "if it ain't broke don't fix it" but this not asking for Permissions thing haunts me slightly, like it might break under some viewers perhaps? Thoughts, or am I home and dry? Lastly, I tried calling the move cam function twice with a 0.5 sec pause as you suggested Quistess, but ultimately I took it out again as, once the Permissions request was sidelined, it worked without need of the pause.
×
×
  • Create New...