I felt this statement warranted a respectful and honest answer. What can be summarized in a few lines of English often takes dozens of lines of complex coding to properly execute.Christine Nyn wrote: ↑Fri Mar 26, 2021 10:09 pmAn alternative approach might be to calculate the distance from A to B before starting, figure out how many individual steps at a given speed it would take to complete the move (we'll ignore the method of movement here) and then allow a timer to regulate the implementation of each move towards completion.
Yes, one can do what is described above. Instead of using a standard loop structure (which would be the go-to method in almost any language), instead in LsL we have to:
1. Take the initial position
2. Identify the relation of the destination location
3. Perform multiple distance calculations, depending on the direction that destination happens to be
4. Calculate how long, at the current movement speed, the vehicle will take to travel that distance
5. Determine if that is longer than the 30 seconds the Opensim system allows before Event timeouts
6. Divide that distance into smaller distances that fall well under 30 seconds so that we have wiggle room in case of unforeseen lag
7. Make several moves instead of one single move
8. To make this all work, design an alternative to the timer() event, because that event pauses script operation 1/2 second every time it's called
... just to make a basic concept work correctly so it doesn't crash the script.
Many caveats that exist within LsL will require similar work-arounds to accomplish the desired goal. We wind up with a script that's more complex than it would have to be under standard coding conditions. You should see the FakeSleep() and FakeTimer() subroutines I had to write to side-step those major issues.
So yes, a competent coder can write alternative code to accomplish the goal desired, and we do-- regularly. But it does tend to make the code significantly more complex.