Sleep StayOpenTime on every Mover's KeyNum
Sleep StayOpenTime on every Mover's KeyNum
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?
"Multiple exclamation marks," he went on, shaking his head, "are a sure sign of a diseased mind." --Terry Pratchett
Re: Sleep StayOpenTime on every Mover's KeyNum
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.
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.
Binary Space Partitioning
- FraGnBraG
- Inhuman
- Posts: 930
- Joined: Sun Jun 13, 2010 5:13 pm
- Personal rank: Good news everyone!
- Location: Canada
- Contact:
Re: Sleep StayOpenTime on every Mover's KeyNum
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...
Re: Sleep StayOpenTime on every Mover's KeyNum
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.
"Multiple exclamation marks," he went on, shaking his head, "are a sure sign of a diseased mind." --Terry Pratchett
Re: Sleep StayOpenTime on every Mover's KeyNum
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.
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.
Binary Space Partitioning
Re: Sleep StayOpenTime on every Mover's KeyNum
You will need to code a new state into the mover, what's the current initial state?
Re: Sleep StayOpenTime on every Mover's KeyNum
I already had a look at the code, but I was not really sure how to implement the behaviour I want.
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.
"Multiple exclamation marks," he went on, shaking his head, "are a sure sign of a diseased mind." --Terry Pratchett
Re: Sleep StayOpenTime on every Mover's KeyNum
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.
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.
Binary Space Partitioning
Re: Sleep StayOpenTime on every Mover's KeyNum
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.
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.