Footstep effect scripting?

[Rachel1206]

1 hour ago, MajorCooke said:

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.

 

Try and use llPreloadSound(  UUID ) to minimize any sound delays, even more important if you want to change the running sounds given for example the surface.

Notice, llTriggerSound() will not stop llPlaySound() - I assume this is intentional.

Also the simple usage of the boolean delay, I  would store a variable like integer nState and then depending on the value of nState do the different llSetTimerEvent()

[Coffee Pancake]

27 minutes ago, Rachel1206 said:

Try and use llPreloadSound(  UUID )

It's worth using, however from my own atmospheric sound scripts I was never 100% sure it actually worked as intended. <10 second audio clips can be very small.

[Wulfie Reanimator]

1 hour ago, Rachel1206 said:

Try and use llPreloadSound(  UUID ) to minimize any sound delays, even more important if you want to change the running sounds given for example the surface.

Notice, llTriggerSound() will not stop llPlaySound() - I assume this is intentional.

Also the simple usage of the boolean delay, I  would store a variable like integer nState and then depending on the value of nState do the different llSetTimerEvent()

Explicitly preloading the sound is most likely unnecessary in this case. Walking is an action people tend to trigger quite often (or not at all), so after the first attempt to walk when the sound would load and be out of sync, it would become synced soon as the avatar stops and starts walking again (since the sound has now had time to load).

 

11 hours ago, Mollymews said:

The main obstacle is that we can't make our script run in constant time on the server. Best we can do is try to ameliorate matters by knowing the server dilation time (how slower than the standard 1.0 is the server running). http://wiki.secondlife.com/wiki/LlGetRegionTimeDilation. 1.0 dilation equates to 45 server frames a second

our walking animation is running client side in constant time (30 frames a second typically). Lag caused by network data traffic excepted. Nothing can be done from LSL about network lag  

Proceeding then some arithmetic: 1.0 / 30 * 45  = 1.5.  Or more simply 2 client side animation frames for every 3 server side frames

There's a lot  here but I don't know if it's going anywhere.

• The "server framerate" is up to 45/s. That part is correct.
• Animation playback is "constant," as in, in dependent of viewer framerate.
  • Animations in SL can have 1-45 keyframes per second, depending on how many frames the creator... created.
  • If the viewer's framerate is higher than the animation's, the viewer will create fake "in-between" frames. (interpolation)
• Time dilation has no effect on animation speed, though.
• Network lag has no effect on animation speed, either.

 

The most ideal situation is to have the animation file, so you can create a looping sound that matches the pace. Then you simply start both at the same time. Realistically, you probably don't have the animation or can't predict what animation will play, and in that case you might create multiple looping sounds with different paces to choose from. And this is how you would detect "if owner is walking" every 0.1 seconds:

default
{
    state_entry()
    {
        llSetTimerEvent(0.1);
    }

    timer()
    {
        if(llGetAgentInfo(llGetOwner()) & AGENT_WALKING)
        {
            llLoopSound("walking", 1);
        }
        else
        {
            llStopSound();
        }
    }
}

 

Edited May 1, 2019 by Wulfie Reanimator

[Rachel1206]

1 hour ago, CoffeeDujour said:

It's worth using, however from my own atmospheric sound scripts I was never 100% sure it actually worked as intended. <10 second audio clips can be very small.

It does work - but if you like me have sound cache enabled and check-marked Don't delete unpacked DSF ( I'm using FS), we hardly notice the difference under normal circumstances.

And other factors like delayed script execution or slow download from asset server are more likely to cause delays in sounds.

 

[Mollymews]

4 hours ago, MajorCooke said:

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.

 

you're onto it. Varying the length of the timer event period for each specific circumstance puts you on the right path

[Mollymews]

7 hours ago, MajorCooke said:

 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?

personally I have always used time dilation. My typical approach to these kinds of problems is to go with trying to convert the rate at which the server is running to constant time on the client. Its doable to use llGetRegionFPS tho for sure  

Edited May 1, 2019 by Mollymews
hmm

[Mollymews]

2 hours ago, Wulfie Reanimator said:

There's a lot  here but I don't know if it's going anywhere.

my thought was to get a conversation going about what a possible solution might be, rather than continue conversations about what doesn't work. So the conversation then went more in the solutions direction

[Kyrah Abattoir]

There is one real issue though that one has to consider when speeding up timers to compensate time dilation:

The time dilation is happening because of a script overload. Which begs the question whether firing your events faster is actually solving anything.

Lastly if the region dilation dips below a certain threshold, it will simply begin dropping a % of script events to save time.

[Mollymews]

@Kyrah Abattoir.  Yes what you said is all true

putting it into another context

over the street ages ago now there was a discussion about scripters needing to be cognisant that our scripts are running in a shared environment. That we should be collaborative and cooperative in a share the love kinda way

then a old-time creator joined the conversation and I paraphrase what they said: "Thats true and we all do that in the main. However as a professional creator I am also in competition with my peers. When the server turns to mud and my scripted products continue to deliver to my customers, and my competitor's products stall on their customers in the same situation, then my competitor's customers will take another look at who they buy stuff from. There are lots of things that we can do where the benefit in isolation is very marginal. The marginals do add up though across a store's inventory of product when we are competing for customers"

[Coffee Pancake]

I have never bought anything specifically because it aggressively fought for region resources.

No one buys anything because of clever script gymnastics to gain a 10th of a second advantage. HIGH LAG was never a selling point.

Back when I owned a region, if an object was full of tiny hamsters going full tilt just to make sure it "won". It went in the bin .. along with everything else that creator had made. If a tenant had bought an object that did that, we would refund them the purchase price in exchange for them removing it and then source alternatives.

With one notable exception (T&T products) we never had to police visitor script usage in anyway, no counters, no mem checkers, did not matter one bit. 

 

[Kyrah Abattoir]

9 hours ago, Mollymews said:

then a old-time creator joined the conversation and I paraphrase what they said: "Thats true and we all do that in the main. However as a professional creator I am also in competition with my peers. When the server turns to mud and my scripted products continue to deliver to my customers, and my competitor's products stall on their customers in the same situation, then my competitor's customers will take another look at who they buy stuff from. There are lots of things that we can do where the benefit in isolation is very marginal. The marginals do add up though across a store's inventory of product when we are competing for customers"

That creator needs to read up on the  tragedy of the commons.

Actually a lot of creators need to read about it since the concept is not limited to scripting in general and despite the aparent lack of limits put in place, they very much exist from a practical and useability standpoint.

[Mollymews]

a apples to apples script comparison

suppose we have a queue that can hold 10 events

suppose there are 10 scripts each firing a timer at 1.0 second, all showing the same visual effect on the client screen

the queue by script no. [1,2,3,4,5,6,7,8,9,10];

[1] gets processed. queue now [2,3,4,5,6,7,8,9,10,1]. [2] gets processed. queue now [3,4,5,6,7,8,9,10,1,2] and so on.

we are script no. 9. We are happy with this when the server is running at 1.0

then the server starts to lag for reasons nothing to do with these 10 scripts. Say the time dilation is now 0.9

so we adapt our event time to 0.9 and the other scripts don't. The cumulative effect of this is:

[1,2,3,4,5,6,7,8,9,10]
[1,2,3,4,5,6,7,9,8,10]
[1,2,3,4,5,6,9,7,8,10]
and so on.

our No 9 script is getting in ahead of the script immediately in front of us on each round, while at the same time the others still have a slot in the queue

the outcome of this is that the other 9 scripts are now showing the client side effect at about 1.11 average. While our client side effect continues to be shown at around 1.0 average

when all the scripts are adapting then they are all at about 1.09 average
 

another situation where time dilation management is useful is vehicles. A inworld example, yacht racing. The server starts to lag. Some yachts continue to move smoothly across the water on the client screen, while other yachts are stuttering. The yachts that continue to move smoothly on the client's screen are factoring time dilation into their linear and angular motors

the customers on the stutter boats think this is not good, and go buy smooth yachts ever after

[Kyrah Abattoir]

Allright, so tell me what happens when the only boats on the market are smooth yachts?

To clarify, i'm not saying that you shouldn't compasate for time dilation. I'm saying that it's not necessary to have that in every timer, a lot of timers are not "time sensitive" so to speak, and in many cases it is better to simply let the server decide when is a good time to process it.

Edited May 3, 2019 by Kyrah Abattoir

[Mollymews]

i agree that not every situation needs to be tweaked to pieces. The general approach we all take is close enough is good enough. OP for example, after a conversation about all the things that could be done, went with a solution that was close enough to be good enough for them OP.  I think the basic philosophical rule is that which makes us happy enough

i added the racing yachts example as its a pretty common occurrence. Two boats racing, both using the same weather system and running on the wind at 10 knots say

another boat enters the region with a group of party-goers loaded down with scripts.  One boat adapts to this and maintains closer to 10 knots, the other doesn't.  The sailor on the boat that is adapting and maintaining closer to 10 knots is pretty happy in this close enough is good enough way.  The sailor on the other boat is not happy at all - the weather system says 10 knots and they are falling behind in the race

when both boats are adapting then they are still racing at par. Both sailors are happy with this

ps. add for completeness

in the situation where both boats are adapting then they are queue-jumping the party-goers scripts, not each other 

Edited May 3, 2019 by Mollymews

[Kyrah Abattoir]

Two ways of thinking:

Ensure the script's impact on the region is minimal.
VS
Ensure the script performs as it should, at the expense of everything else.

[Coffee Pancake]

 

At the expense of everything else also tends to be locked to the current service as provided, and if nothing else, the service will always evolve to punish techniques that try to game the systems provided.

[Kyrah Abattoir]

Wasn't there a talk at some point for LL to move to a fair queuing system or something?

[Mollymews]

12 hours ago, Kyrah Abattoir said:

Two ways of thinking:

Ensure the script's impact on the region is minimal.
VS
Ensure the script performs as it should, at the expense of everything else.

we are getting deeper into the philosophicals now

yes life would be a whole lot simpler if we could reduce everything down to a binary choice, where one is good and the other bad. When we do however apply this wider to all situations then it can in many cases become quite limiting, restricting diversity in some situations, causing suffering in others, etc

a philosophical conversation topic. Most organised religions are reductive in this way. Actions are either good or bad. There is no between or beyond. That when we choose bad then salvation lies in penitence and always taking the proscribed good path ever after

consider the binary choice in the racing yachts scenario. The sailors would see the party-goers as bad. The sailors would not see themselves as bad, the region was running fine until the party goers showed up, script-loaded up to party

the sailors wonder why the party-goers choose to wear such a volume of scripts that it lags the region. Wonder also why LL does not script-limit agents? Grumble mumble and then take action. Take back time from the party-goers. As the sailors see it they are not taking time, they are taking back time, even though the pratical outcome is the same. The viewpoint has shifted from what is good|bad, to who is good|bad.   

the proscribed binary "what is good" path for the sailors is to do nothing and suffer the binary "what is bad" path chosen by the party-goers. From a philosophical pov, this is another tenet of some religions. Suffering brings us closer to purity  
 

[Mollymews]

8 hours ago, CoffeeDujour said:

 

At the expense of everything else also tends to be locked to the current service as provided, and if nothing else, the service will always evolve to punish techniques that try to game the systems provided.

yes, this is typically how it goes.  When particular actions start to impact region performance then throttles get introduced

[Kyrah Abattoir]

This isn't going anywhere and I agree that it's not a binary problem I'm just pointing the two extremes and see way too many (greed tend to magnify this) scripters asking themselves whether they can do something and never if they should.

In an ideal environment none of this would matter because as a user you would simply not be given more ressources than your fair share, so in the absence of rules, trying to minimize your script's impact is a good idea since it leads to a better collective experience.

@MajorCookesorry if things veered off topic, none of this matters much for the kind of script you are writing but i figured it wouldn't hurt to give that perspective, hope the help I gave you inworld was more relevant.

[Mollymews]

good on you Kyrah for helping out Major inworld

[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.

Edited May 4, 2019 by MajorCooke

[Ivanova Shostakovich]

   Until I read through his thread, I'd always assumed those footstep sound makers used a collision event in each shoe, or foot attachment. That's probably a lot less efficient though.

[Wulfie Reanimator]

2 hours ago, Ivanova Shostakovich said:

   Until I read through his thread, I'd always assumed those footstep sound makers used a collision event in each shoe, or foot attachment. That's probably a lot less efficient though.

As cool as that might be, it's actually impossible. Your feet/shoes (or any visible part of your avatar, in fact) can't collide with anything. Your avatar has a single invisible "hitbox" that represents where the avatar, roughly, exists in the world.

[Ivanova Shostakovich]

1 minute ago, Wulfie Reanimator said:

As cool as that might be, it's actually impossible. Your feet/shoes (or any visible part of your avatar, in fact) can't collide with anything. Your avatar has a single invisible "hitbox" that represents where the avatar, roughly, exists in the world.

   Yes, this does seem in line with other lsl functions involving the avatar and it's position.