Disable Player Input - easy/graceful way?

[Mouser]

I've got a 'cutscene' with a lot of evented character movement with dialog interspersed here and there. If the player touches the keyboard though and moves the character at the wrong time, the whole thing goes to pot pretty quickly.

I can see a way to do it (I think) by overriding move_by_input in Game_Player (and there's another place that looks like I could 'intercept' commands), but I'm wondering if there isn't a switch or command already in place that simply 'locks out' the keyboard/controls until you turn them back on.

While the move event is running all is good (although disabling <esc>/<ins> wouldn't be bad there to prevent formation changes or other such problems) - it's the little gaps of time between those events and the dialog where the problem can arise.

I can think of loads of other places it would be helpful, so I'm hoping there's already a graceful way to handle this that someone knows and can tell me.

 

[Alexander Amnell]

I'm assuming you are using a parallel process to run said cut-scene, change the trigger to 'auto-run' and the player will not be able to perform normal actions until after said event is over, even during wait periods.

 

[Mouser]

Very Nice.

Thanks  BD

 

[Andar]

just one more tip:


A cutscene should be controlled by a single autorun event, all other events should only be content-less sprites controlled by the autorun event (which will contain all commands for dialogues, texts, movement, etc. what happens during the cutscene.


Spreading the control and content over several events will often cause a lot of bugs in timing and controlling...

 

[Mouser]

just one more tip:

A cutscene should be controlled by a single autorun event, all other events should only be content-less sprites controlled by the autorun event (which will contain all commands for dialogues, texts, movement, etc. what happens during the cutscene.

Spreading the control and content over several events will often cause a lot of bugs in timing and controlling...

That part I figured out pretty early, even with the parallel processes   I've got one part I have to put in a short frame delay for everyone to 'catch up', and then move on, but other than that it runs pretty smoothly. The only hitch was those brief moments when the player could control the character.

 

[Archeia]

There are moments where you have events that activate on touch and player movement is still inputtable, I mean technically you can make it an autorun and such on the next page. But just in case you don't want that hassle, I recommend this script.