MajorCooke

I think I'm pretty satisfied with how I ended it. Even if it still desyncs, it's still better than how it used to be by far. Thank you all for your help.

Okay, so after doing a lot of experimentation, what I came up with is a lot more feasible. float timerevent = 0.5615; float sleeper = 0.2; float vol = 0.8; float delaytime = 0.30; integer delay = TRUE; default { on_rez(integer start_param) { llResetScript(); } state_entry() { integer agentinfo = llGetAgentInfo(llGetOwner()); llSetTimerEvent(sleeper); delay = TRUE; } timer() { integer agentinfo = llGetAgentInfo(llGetOwner()); if (agentinfo & AGENT_WALKING) { // Add a small delay because it takes this long for the foot to make // contact with the ground when transitioning from normal to this. if (delay) { llSetTimerEvent(delaytime); delay = FALSE; } else { if (agentinfo & AGENT_ALWAYS_RUN) { llTriggerSound("6559cdbf-a664-d93c-184e-42d95a965104", 1.0); } else { // Since the object is an attachment, play is fine. llPlaySound("6559cdbf-a664-d93c-184e-42d95a965104", vol); //llTriggerSound("4c19068e-38ae-f3a9-21a3-630a59d62a31", 0.4); } llSetTimerEvent(timerevent); } } else { delay = TRUE; llSetTimerEvent(sleeper); } } } Something amusing I found out... llTriggerSound is susceptible to a small delay - and this is primarily a guess, but after having worked with some game engines in the past, I think it's safe to say: because it spawns a temporary object. At least, that's what the engine I fiddled around with the most did. It spawned an object to play the sound, and then destroyed itself immediately afterwards which means it's subjected to more networking stuff than that of llPlaySound. Considering this is an attachment at any rate doing the sound playing, I don't need to worry about occupying the objects sound channel - in fact it's wide open for use. Furthermore, using llSetTimeredEvent definitely seemed to help a little as well, and while it's still not perfect, it at least won't go completely out of whack in more populated areas and won't screw up the rest of the timing, which apparently llSleep was doing for the script. Not perfect, but still a LOT better than what it used to be. I'll continue expanding upon this as time goes on.

Okay. Stepping back and thinking about this for a moment, it's not so much the desyncing happening between animation and sounds that bothers me, so much as the sounds themselves. There's a lot that could be fixed here. I am not caring so much about syncing it with the animation directly, so much as playing them without them being delayed rather sporadically. I think, if I addressed this issue, then that could make enough of a difference.

I was just about to ask you, actually, what would you use in place of llSleep? Just llSetTimerEvent? Also, the animation I have is not controlled by speed. Where can I view some of those footstep gadgets? And, is it possible to change the AO I have to work based on velocity?

Yeah. I get that much, which is why I was considering having some form of change to the script where instead of the body itself doing the animation when walking/running, a script detects if moving and letting that both change the animation and do the playing sound... if that's at all possible. Then at least it can try to be a little more concise. Is that possible? Or as a last resort, I upload a custom looping variant of the steps that I loop and monitor for possible desyncing and, every X seconds, stop the loop and restart it in order to bring it back in line using the dilation @Mollymews suggested. I've already tweaked the audio to Hell and back to ensure it's as consistent as possible so that part's been taken care of, as I recorded the character strolling and used Premiere Pro to align the audio clips. But I certainly want that to be a last resort because that requires using lindens. While I have some, I cannot afford mistakes. @Mollymews Also, should I be using http://wiki.secondlife.com/wiki/LlGetRegionFPS as part of it? Since that can certainly have an effect, I've been told by a friend, do you recommend I plug that in for the 45 of your code?

Okay, @Mollymews I get the last part but I don't know how to write it for SL. I've been trying to learn it but this is syntax I've never worked with before, and I thought LUA was rough. Would you mind helping me adapt the current code I have for it? As for the what you wrote above, I take it I can just put that in my code and replace the current SetTimerEvent I have already? I clocked the animation stride to be roughly 0.55 seconds between the steps. @CoffeeDujour Understandable, but the folks I hang out with, they rather enjoy it. Quite a lot of them.

Then that's what I'd like to do. How would I go about doing this? Particularly I'd like to start with the walking animation. I should note I learn best by examples with explanations.

Like I said, it was sent to me by someone else. I know very little about scripting. As for the stopping and restarting, I could try and measure when the animation stops and starts, but I have no idea how to script that in properly. Can someone help me out there? Anything to get it as close as possible would be appreciated.

I've seen people with a footstep effect before, but I've always been at a loss on how to recreate this ability, except for a script someone gave me. However, unfortunately it tends to go out of sync, so I'm wondering if there's a better way to perform this? float timerevent = 0.40; float sleeper = 0.25; float vol = 1.0; integer running = FALSE; default { on_rez(integer start_param) { llResetScript(); } state_entry() { integer agentinfo = llGetAgentInfo(llGetOwner()); llSetTimerEvent(timerevent); } timer() { integer agentinfo = llGetAgentInfo(llGetOwner()); if(agentinfo & AGENT_ALWAYS_RUN) { running = TRUE; } if(agentinfo & AGENT_WALKING) { if(running == TRUE) { //llStopSound(); llTriggerSound("6559cdbf-a664-d93c-184e-42d95a965104", vol); llSleep(sleeper); } else { //llTriggerSound("4c19068e-38ae-f3a9-21a3-630a59d62a31", 0.4); llTriggerSound("6559cdbf-a664-d93c-184e-42d95a965104", vol); llSleep(sleeper); } } else { running = FALSE; llStopSound(); } } } I have an object attached to the feet already, but depending on how intensive the place I'm at will definitely slow it down, since animation speeds and the like are not synced together. I was considering using http://wiki.secondlife.com/wiki/LlGetPos by getting the distance from the avatar, but unfortunately, the caveat of object position with avatar animation being invisible to the simulation means I cannot get it based on that. Does anyone have a better idea on how to do this?

The whole point of this is to avoid modifying the prim, actually. No point in doing a note card when you can just copy/paste the settings from one to the other.

That's actually what I would like. If I cannot have a /refresh command of some sort then I'll be happy to do a HUD. Anything to reduce the amount of updating to just 1 place. So, do I still follow the HUD links you posted? Simply put I thought it might be easier if it could snatch up the copy of the script from the inventory that way instead of needing to read in the details.

Okay. What I'd like to try and do is edit the main script itself, save it, then type in a command like... /refreshparticles so it could replace the current instance of the script with a new copy from the main inventory. I did have an idea on how to do that, thanks to the particle removing script. Is it possible to fetch the main script from my inventory after listening to that chat command using llGetInventoryName or similar? The way I'm imagining this is if there's a listening script on the parts and they pick up the chat message, they will remove the previous version of "$Burning Particles" that's within the content, grab a copy from the main inventory and immediately execute it. Or will I have to do this another way?

Actually I was aware that everything is instantiated. I just had a very bad way of stating how I wanted to get around it. Whoops! Anyway, I'll take a look into that.

Okay, let me back up a bit to (try to) clarify. Is there a way to call another script? Because if I could use that 'on attach' method, then I could simply refresh the particles by having it call the particle remover script, and then initialize the particles once again. In order for me to update the particles currently, I have to go through and apply the particle remover onto the parts, along with deleting the currently running Burning Particles scripts that's on them. Then, I have to drag a copy onto their Content tab. So I'm wondering, is it possible by any chance where I could just hook up a simple script which calls the Burning Particles script upon the mesh itself? I'm not seeking a toggle ability but I will keep that in mind.

Each time I log in and the body loads, or yes, attaches. So, I should put that on the emitting object then? My main concern is that it won't auto-update from the script in the inventory, that the script itself will not be up to date each time its called. Is there some sort of function to call upon a specific script from inventory?

Ah, that should be handy. Thanks for that trick! Anyway, to clarify what I'm trying to accomplish: Okay... SO what I have here on each hoof is an object called "Flaming Hoof Ring", which is the little attachment in blue highlighting (ignore the actual glowing hoof shoe itself - that's not a prim, it's a part of the mesh) Right now I have four of these (two per each pair of legs) that have different sizes. I will undoubtedly have to make a second script for the bigger variant, until I learn how to get the scale of a prim (it's just a half circlet). I would like to make is so each time I recompile the script (if possible), it automatically applies the new particle system to those parts, i.e. compiling directly from inventory and effectively refreshes it. @Rolig Loon Yeah, well, these two are the exact same for the sake of simplicity for this edition so I was thinking they could both be applied one, using that code indeed. Now I'm curious as to how this automatically starts up every time? Or at least how to do so.

Unfortunately I'm unfamiliar with how to use LinkParticleSystem. Someone gave me the script and while I know how to modify it, I don't know how to properly change it because it gives me a compiler error about the first integer. default { state_entry() { llParticleSystem([ PSYS_PART_FLAGS, PSYS_PART_EMISSIVE_MASK|PSYS_PART_INTERP_COLOR_MASK|PSYS_PART_INTERP_SCALE_MASK, PSYS_SRC_PATTERN, PSYS_SRC_PATTERN_ANGLE, PSYS_SRC_BURST_RADIUS, 0.200000, PSYS_SRC_ANGLE_BEGIN, -2.5, PSYS_SRC_ANGLE_END, 2.5, PSYS_PART_START_COLOR, <1.00000, 0.70000, 0.00000>, PSYS_PART_END_COLOR, <1.00000, 0.50000, 0.00000>, PSYS_PART_START_ALPHA, 1.000000, PSYS_PART_END_ALPHA,0.000000, PSYS_PART_START_SCALE, <0.20000, 0.20000, 0.00000>, PSYS_PART_END_SCALE, <0.01000, 0.01000, 0.00000>, PSYS_SRC_MAX_AGE, 0.000000, PSYS_PART_MAX_AGE, 1.000000, PSYS_SRC_TEXTURE, "e6c7b1f4-5428-04fd-4c4f-42a789f08625", PSYS_SRC_BURST_RATE, 0.000000, PSYS_SRC_BURST_PART_COUNT, 999, PSYS_SRC_ACCEL, <0.00000, 0.00000, 0.75000>, PSYS_SRC_BURST_SPEED_MIN, 0.500000, PSYS_SRC_BURST_SPEED_MAX, 0.500000 ]); } } How do I get the link ID? Please bear in mind I'm very new to this. So this is going to take some real explaining on how to work this out.

So here's the deal... Right now I have an object attached to a body part that's linked together and emits particles from its location, since you cannot offset the particle system via the code. At least, not via origin point. The trouble is, I have to rez both limbs out, delete the particle systems via dragging a particle removing script and reapply the main particle script upon it, then link them all up once more and reapply them to the body. This can be quite the annoyance especially as the object in question is invisible, so selecting it is very difficult. I would love to cut out that part so all I have to do is recompile the script, and those two objects have their particles changed without needing to take apart my character all over again. How would I do this?