Sleep StayOpenTime on every Mover's KeyNum

[Barbie]

The subject tells it: a Mover should go to KeyNum 1, stay there for *StayOpenTime*, then forward to KeyNum 2, stay there for *StayOpenTime*, and so on. On closing the same should happen. I wasn't able to realize it with one of the stock movers. Did I miss anything or do I really have to code such by myself?

[Red_Fist]

I think it's the "last" frame for it to "stay open". I do not believe on closing it has a ,stay open time, I think there is a delay setting that each frame pause before it gets moving again, back to frame zero.

I would have to test what you are doing, but it seems when they close, there is nothing else it wants to do other than get back to key frame zero.

[FraGnBraG]

.. I wasn't able to realize it with one of the stock movers. ...

Movers with multiple keys is discussed here Lode's movers...

It seems like you should be able to do that... edit: you can do this with gradual or elevator mover... they have events at each keyframe (possibly also in reverse direction) you'll need to look at triggers/dispatching for your desired behaviors, like wait time... i would be a bit surprised if you can't do this...

[Barbie]

Thanks for replies. Yes, an approach is possible with a gradual mover: set an event for every KeyNum and assign a Dispatcher that waits some seconds before it raises the event for the next KeyNum. Unfortunately on the way back events are not risen.

[Red_Fist]

That is why you don't start on key frame zero. seeing as how they strive to get back to frame zero, you need to offset the key frame as if key zero is like key 3 or 4 or 2, so when it does go back to zero, you could send another event to make it hang out on another frame as if it was zero.

Fuzzy logic and is very confusing to do, like you need to give a second event to make it go wait at another key frame. Or a very tiny move, 1 unit that is going back to zero will also work. And that depends on the track the mover is on, like a loop cycle so it don't snap across the map going back to zero.

[Higor]

You will need to code a new state into the mover, what's the current initial state?

[Barbie]

You will need to code a new state into the mover

I already had a look at the code, but I was not really sure how to implement the behaviour I want.

what's the current initial state?

It is GradualTriggerOpenTimed.
Mover's DelayTime seems to be ignored at least in that state. And MoveAmbientSound is played all the time between first and last KeyNum, although the mover stops and pauses at a KeyNum.

[Red_Fist]

I am checking things out, and will have a test map.

But what I would do is mess with the section of code that , has the , MV Glide by time.

Shove a delay function in that, I am trying several movers, if you use MovebyTime, you can see the built in times you enter shows the speed and not the stopping a lot more.
When I use the glidebyTime, it will pause a lot longer at the keyframes.

I have all three movers in one map and you will see what I mean. I am setting up the mixmover and see how it reacts compared to the others.

[Higor]

By initial state I mean... if the mover ALREADY had the described behaviour, what would the state be?
BumpOpenTimed, StandOpenTimed, TriggerOpenTimed, TriggerToggle, TriggerControl?

The mechanism is extremely easy to implement, but it has to be done using one of the above states as blueprint.