Request for advice/assistance: Elevator at high altitude.

Hi everyone. I've created a sky build in Cowell and have a total of four elevators in or serving it. They are very slightly modified versions of Hank Ramos' excellend PD elevator (I've only altered the channels they listen to, the floor heights, and the various floor messages).

The problem I'm experiencing is that three of these elevators frequently become unresponsive, both to commands spoken by me and by the various call buttons. In other words, they get stuck.

The three that are unresponsive all have at least 3 "floors" while the one that I've never had a problem with only has two. Additionally, the floors on the problem elevators are separated by much greater distances than the happy elevator.

A simple "elevator reset" command always restores the problem elevators to full functionality.

My first question: is this a problem with all elevators at altitude, or do other scripts not exhibit this problem?

My second question: is altitude always a problem for scripts? I've noticed that my visitor tracker doesn't seem to have any problems up there... perhaps it's just physical objects (?).

The more important question, however, is: what's the best way to deal with the problem? My non-programmer-mind kludge would be to have the elevators issues themselves a silent "elevator reset" command once an hour (or whatever time period is appropriate).

This seems to be an effective and easy answer that won't tax the server too much, but I recognize that there's the easy way and the right way and rarely are they the same thing.

SO. If the easy way isn't the right way, what would the right way be? I'm no programmer, so assistance would be welcomed. I can pay a small stipend for elevator repair work. =-)

But I would also like to know the right way, so that I might learn more about scripting future items for use at altitude.

This is probobly a symptom of llMoveToTarget limitations. llMoveToTarget doesnt "like" moving to places greater then a certain number of meters away from the current position of the object (60 meters, I think). What Hanks script probobly does is use moving_end or at_target to determine when the elevator gets to the specified floor. Since llMoveToTarget refuses to move to such a distance, the script hangs there.

The reason "elevator reset" works, is since listen is a seperate event, it can process it concurrently during the movement. The reason the elevator refuses to take any commands from the buttons when in the unresponsive state, is because Hank probably switches to a seperate state without a listen handle for such messages.

The only solution would be to modify Hank's script so it makes smarter use of llMoveToTarget or, as you said, reset it if it becomes unresponsive.

Of course, this is all theoretical. I havent seen Hank's script, so I cant be *totally* sure. I just have a good amount of experiance with elevatore
==Chris

/me needs to revamp the elevator kit! Too tired, must sleep...

Thanks for the response, Chris.

What's interesting to me is that the elevators seem to go "offline" almost entirely when I'm not logged in. I never have a problem with them once I've logged in and reset them, even with more than an hour between trips (e.g. I'm off exploring the world, come back, and they work just fine).

Ok, so the easy way is to have them automatically reset themselves and the right way is to deal with the limitations of the move to target commands.

Guess it's time to trek off to the wiki.

If anyone has more to add, please do. I'm still at the point in scripting where I don't even know what questions to ask.

I would try for something simpler.

Remove the listens and make it operate on touch (you loose the elegance of the call buttons this way though.)

Maybe consider one elevator to get to the sky build, then spiral torus-based ramps to get between floors.