09e3f1872e
GetNextScreen -> GetNextScreenName (makes return type more clear in Lua)
2007-08-25 03:13:16 +00:00
7f08da77f1
set all lights modes in metrics (except for a couple programmatic ones
...
for now)
2007-06-14 13:38:26 +00:00
9a41d096ef
controllable LightsMode
2007-06-11 19:00:47 +00:00
743421f88f
some MENU -> GAME
2007-05-10 17:59:13 +00:00
352067b509
EndCommand
2007-04-17 17:53:36 +00:00
2663f35be8
kill first draw after BeginScreen
2007-03-26 22:52:54 +00:00
eb68cd72bb
split out CodeSet
2007-03-16 23:56:10 +00:00
1189f94ede
generalize CodeNames
2007-03-16 23:33:41 +00:00
1faeb65a40
per-screen RepeatRate, RepeatDelay
2007-03-16 06:00:06 +00:00
a0dfa4d06a
Do this in metrics instead.
2007-02-19 04:25:07 +00:00
8f18ee731d
Stacked screens do not have a PrevScreen, they get popped. Fixes dialog box popping up after pressing escape at ScreenTextEntry.
2007-02-19 03:36:51 +00:00
fcf121feb0
add PlayCommandNoRecurse to fix PlayCommand hack
2007-02-10 05:42:25 +00:00
ef3b1b7218
MenuTimer is in SWME; move SM_MenuTimer there, too. (Screen no longer
...
needs GAMESTATE.)
2006-11-21 20:04:51 +00:00
7ef6009567
Screen::JoinInput -> GameState::JoinInput
2006-11-21 19:57:58 +00:00
d591926ff7
Don't play sounds in JoinInput; let the caller do that.
...
Localize "only play start sound for the 2nd player who joins"
hack into ScreenSelect.
2006-11-21 19:52:18 +00:00
39c60364be
remove global
2006-11-02 04:54:39 +00:00
d879e4802a
Move LoadingScreen to a global.
...
LoadingScreen is a variable that should be available to all loading
definitions. Param does this currently, but I'm redesigning that, and this
particular case doesn't fit. Conceptually, it really is a global (though
perhaps should be tucked away with an environment or something).
2006-10-14 02:37:15 +00:00
45c85f0ebb
unused
2006-10-01 00:04:02 +00:00
c690fdcfe4
unify registration
2006-09-29 00:01:32 +00:00
4002071bea
simpler Lua boilerplate
2006-09-27 19:47:52 +00:00
3f40f6c796
unneeded
2006-09-15 06:06:36 +00:00
ad24ecb82c
remove old
2006-09-15 05:29:16 +00:00
47ef4873fb
remove MenuX(pn)
2006-09-14 21:28:29 +00:00
c7dfb9f2ec
MenuInput -> MenuButton
2006-09-14 20:52:34 +00:00
f1cd95828e
remove MenuInput.IsValid(); if invalid, the button is simply MenuButton_INVALID
2006-09-14 20:31:46 +00:00
ad809ec5fa
simplify interface
2006-09-14 08:14:22 +00:00
2b5cbe811f
check the button press in the caller of JoinInput (so we
...
don't have to construct a fake input message in
ScreenSelectMaster::MenuStart)
2006-09-14 08:11:58 +00:00
aeb0c1be0b
unwrap
2006-09-14 08:08:09 +00:00
26a773d983
no need to MenuI.IsValid before comparing
2006-09-14 08:06:22 +00:00
93844f840f
simplify
2006-09-14 08:05:40 +00:00
3157bb77d4
consolidate "delayed back" logic
2006-09-14 07:55:34 +00:00
3fe68d7f7d
simplify
2006-09-14 05:18:40 +00:00
754f2edb0f
JoinInput(MenuInput ) -> JoinInput(InputEventPlus)
2006-09-14 03:23:17 +00:00
c9c88f26c2
input.MenuI.player -> input.pn
2006-09-14 03:18:16 +00:00
c71d8f7425
IET_SLOW_REPEAT -> IET_REPEAT
2006-09-13 02:59:05 +00:00
d03db0c4f9
remove IET_FAST_REPEAT
2006-09-13 02:55:19 +00:00
c9ae1296d1
Add BeginCommand.
...
There are several initialization commands; they all serve distinct purposes.
InitCommand is run exactly once; it sets initial state, typically state which
never changes for the lifetime of the actor. Copied actors will not call
this command again; they'll simply inherit the state from the original.
BeginCommand is run from BeginScreen, and is intended to set the actor up
for that run of the screen, as BeginScreen does for the screen. This
includes setting text or graphics based on current game state; eg.
"settext,GAMESTATE:GetCurrentSong():GetDisplayFullTitle()".
OnCommand is also run from BeginScreen, and begins the actor's on tween.
BeginCommand are mostly equivalent; they're run from the same place. BeginCommand
is intended to be used from base XML actors; OnCommand is set by derived XML
actors (explanation of this out of scope). Also, OnCommand is run inconsistently,
at least in implementation, until the GenericTweenOn() transition is complete.
BeginCommand is not.
(As with all commands, this can be declared for the screen itself by using the
"ScreenBeginCommand" metric--untested.)
2006-07-01 05:33:49 +00:00
ec91c4030a
remove OVERRIDE_LOCK_INPUT_SECONDS, LOCK_INPUT_SECONDS; handle "tiny lock" generally; don't move "lock by tween time" just yet
2006-06-27 23:15:56 +00:00
0d10d38035
bind lockinput
2006-06-27 23:07:11 +00:00
5795d2b5f6
merge m_fLockInputSecs's
2006-06-27 22:51:43 +00:00
33d89da000
bind GetNextScreen
2006-06-25 20:06:06 +00:00
3a10111e99
bleh. Too much doesn't use the standard StartTransitioning/Cancel paths; this needs to be transitioned. Don't need m_sPrevScreen, though.
2006-06-25 18:14:42 +00:00
b0055b0853
simplify. Don't separate "next" and "cancel" as much: to cancel, set the next screen to PREV_SCREEN, and use SM_GoToNextScreen.
2006-06-25 18:11:09 +00:00
c4835e0adb
Revert. Reloading is a hack and shouldn't be part of the API.
2006-03-18 13:26:01 +00:00
2dcdea5467
Add ReloadScreen().
2006-03-18 11:02:20 +00:00
84226e5d27
cleanup
2006-03-14 02:23:45 +00:00
1c3d8baeeb
Screen:PostScreenMessage
2006-02-24 01:09:42 +00:00
0ad99bffc2
switch -> if
2006-02-24 00:20:41 +00:00
ce1526fcd9
tab fixup
2006-02-03 19:24:14 +00:00
7f821e8cfc
CString -> RString
2006-01-22 01:00:06 +00:00
Chris Danford