Home   Help Search Login Register  

Author Topic: disableuserinput behaviour...  (Read 1053 times)

0 Members and 2 Guests are viewing this topic.

Offline bedges

  • Administrator
  • *****
    • OFPEC The Editing Center
disableuserinput behaviour...
« on: 26 Feb 2005, 18:38:36 »
as in, sometimes it fully locks up the keyboard, sometimes only the movement is restricted and the player can look about, access the map...

what's going on? i'm not changing anything in the script, so what's causing the difference in behaviours?

scooter24

  • Guest
Re:disableuserinput behaviour...
« Reply #1 on: 26 Feb 2005, 20:31:34 »
Hey bedges!
I've never come accross this code before. It might be worthwhile posting the script so that an experianced OFPEC member can examine where you might be going wrong.
     As I see it, when you want to disable user input via the disableUserInput command, make sure you end it with false. Eg: disableUserInput false. Once your cutscene has finished, replace false with (i assume) true.
     If all else fails, make a trigger with a time property equal to that of your cutscene and place in the 'On Activation' field: disableUserInput true, just as a back-up. Good luck!
scooter24.
« Last Edit: 26 Feb 2005, 21:11:43 by scooter24 »

Offline macguba

  • Former Staff
  • ****
    • macguba's operation flashpoint page
Re:disableuserinput behaviour...
« Reply #2 on: 26 Feb 2005, 20:58:03 »
disableUserInput true should mean that you can't do anything until

a) a disableUserInput false command turns up

or

b) your electricity is cut off

So I venture to suggest that sometimes your command is happening, and sometimes it isn't:  but when it isn't, something else in the script is causing the other effects.

It's only a theory.

@scooter24 -  the disable/enable part is confusing in the comref.   disable/enable won't do anthing - you need to use true or false, or something that is equivalent to true or false.
Plenty of reviewed ArmA missions for you to play

scooter24

  • Guest
Re:disableuserinput behaviour...
« Reply #3 on: 26 Feb 2005, 21:14:19 »
Hey macguba!
Thanks for the notice, i've editted my suggestion so no one gets confused and posted this so that no one assumes you've gone crazy and are seeing things in other people posts that aren't really there  :P!
     Like I said, it's probibally worthwhile posting the script so that someone (if anyone) who is a veteran at using this code can help. Good luck!
scooter24.

Offline bedges

  • Administrator
  • *****
    • OFPEC The Editing Center
Re:disableuserinput behaviour...
« Reply #4 on: 26 Feb 2005, 22:22:49 »
i have rechecked the script. there are calls to other scripts from within it, but none of those contain any disableuser commands. i've just run a separate check in a blank mission, and disableuserinput works as it should every time, completely disabling all input.

as for the script...

there's a disableuserinput true at the very start.
there's a disableuserinput false at the very very end.
there are no other references to it anywhere else.

there is a showcinemaborder false command, as this script contains a cutscene, but that can't be it....

and as for it sometimes being executed and sometimes not... the command isn't dependant on any other variables. it's just there, at the start of the script, which always runs start to finish, i've put in hints to check.

meh. i'll figure something out. thanks anyway.

EDIT - okay, now i am a bit freaked out.... i have not changed ANYTHING in the script, and now it works. every time.

i swear ofp has a mind of its own sometimes... nice flashpoint. good flashpoint.

Offline macguba

  • Former Staff
  • ****
    • macguba's operation flashpoint page
Re:disableuserinput behaviour...
« Reply #5 on: 26 Feb 2005, 22:50:32 »
Oh yes, it does that kind of thing all the time.   Well, occasionally.
Plenty of reviewed ArmA missions for you to play