Секция 2 из 3 - Предыдущая - Следующая
Все секции - 1 - 2 - 3

    Shockrifle: projectile 55, shot 40, superexplosion (combo) 165
    Enhanced shockrifle: 1000
    Ripper: razorblade 30, explosive razorblade 34 (?)
    Biorifle: small glob 20, large glob 75
    Rocketlauncher: rocket 75, grenade 80
    Flackcannon: flakshell 70, chunk 16
    Redeemer: 1000

  Следовательно, датчик с DamageThreshold = 999 может быть активирован с
  помощью Redeemer, но если DamageThreshold = 1001 Redeemer не поможет;

  Message - это текст, появляющийся в текстовом поле Вашего HUD в момент
  активации датчика;

  RepeatTriggerTime - если у Мувера установлено значение Message, указывает
  сколько секунд будет повторяться это послание пока Вы находитесь в радиусе
  действия датчика. 0 означает что Message отобразится на экране только один
  раз без последующих повторений;

  ReTriggerDelay - если значение отлично от 0, Вы сможете активировать датчик
  только по истечении времени, указанном в TriggerDelay;

  TriggerType - указывает, что может быть причиной активации датчика:

    TT_PlayerProximity - активация происходит при попадании игрока в радиус
    действия датчика;

    TT_PawnProximity - активируется при попадании в радиус действия pawn
    (ракета, ящик, любая декорация);

    TT_ClassProximity - действие вызывается при активации датчика только
    актером (by actor) выбранного класса (class). Пока не работает;

\ дополнение - автор не говорит ничего о ClassProximityTipe, но об этом
  упоминает ниже, описывая Elevator Trigger. Там автор дает ссылку на эту
  главу, но так как здесь ничего нет... Замкнутый круг, кто-то ошибся -
  либо автор, либо 32 Pistoleta (переводчик). Работае это так - при выборе
  TT_ClassProximity необходимо указать в строке ClassProximity тот
  класс, который должен действовать на триггер. Другое дело, что сопряжено
  это с определенным извратом, кнопка Use не всегда работает. \

    TT_AnyProximity - объединяет первые две опции: активируется как игроком,
так и при помощи pawn;

    TT_Shoot - действие возбуждается при нанесении повреждения, и при этом урон
    превышает значение, указанное в DamageThreshold;

\ дополнение - автор ничего не сказал про строку bInitiallyActive, однако
  это очень интересная весч. Если указать в ней False, то триггер не будет
  реагировать на любой "раздражитель". В принципе, это не важно, такой
  триггер явно не несет полезной нагрузки, это как будто его и нет, если
  не знать, что из этого состояния его можно вывести другим триггером,
  связав аналогично примеру с мувером. И переключить обратно. Такая штука
  уже позволит реализовать, вкупе с Dispatcher'ом довольно сложную логику.
  Правда, актуально это скорее в сингле.\
_______________________________________________________________________________
_______________________________________________________________________________

Муверы и освещение
__________________

Муверы имеют несколько настроек, связанных с освещением. Их можно найти в
пункте Mover, окна Mover Properties.

  bDynamicLightMover - если установлено в значение true, освещение будет
  динамически расчитываться для каждого движения мувера, например, если лифт
  находится в темной комнате, а затем поднимается в более освещенную - свет
  коснется и его.  о сильно этим не увлекайтесь, если хотите, чтобы Ваш уровень
  шустро летал и на слабых машинах;

  BrushRaytraceKey - если Вы не воспользовались опцией bDynamicLightMover, то
  можете указать здесь номер кадра-ключа, для которого все же Вы хотите
  просчитать динамически освещение;

  WorldRaytraceKey - если Вы не воспользовались опцией bDynamicLightMover, то
  можете указать здесь номер кадра-ключа при котором все же будет просчитано
  динамическое освещение окружающего пространства (например, тень от лифта);

\ примечание - автор путает динамический свет и статический на лайтмапах.
  Raytrace ключи к динамическому свету отношения никакого не имеют. Это
  ключи в которых указывается как будет трассироваться свет при расчете
  (компиляции уровня). В Brush случае - номер ключа, в котором для мувера
  будут считаться лайтмапы с учетом окружающей геометрии, для World -
  номер ключа, в котором будет на окружающую геометрию падать от мувера тень \

Пример эффекта WorldRaytraceKey показан на скринах ниже. Мувером является лифт
с двумя кадрами-ключами: Key0(base) - в нижнем положении и Key1 - в верхнем.
Cледует помнить, что это сработает только при bDynamicLightMover равном false:

WorldRaytraceKey = 0

\ картинка - тень лежит точно под мувером \

WorldRaytraceKey = 1

\ картинка - тень отбрасывается, как если бы мувер стоял в 1-м ключе \

Вторая тень вычислена для лифта в верхнем положении. Вы также можете
использовать это для изготовления искусственных теней.
_______________________________________________________________________________
_______________________________________________________________________________

Зацикленные муверы (Looping movers)
__________________________________

Зацикленные муверы - это муверы, движение которых беспрерывно. Такой мувер все
же необходимо один раз активировать. Есть несколько способов создать
зацикленный мувер. Здесь будет рассмотрено три из них. У каждого способа есть
свои недостатки и преимущества, и соответственно различные результаты.

The DualDispatcherMethod (Thanks to Wanderer): необходимо иметь два диспетчера
(dispatchers) и датчик. При активации датчика один диспатчер начинает "цепную
реакцию", представляющую из себя бесконечное движение мувера между различными
кадрами-ключами.

Итак, приступим. Сперва добавим в уровень обычный мувер с необходимым
количеством кадров-ключей, перейдем в его свойства (Movie Properties). В пункте

Objects изменим InitialState на TriggerToggle. Также в разделе Events дадаим
ему имя (Tag), например, loopingmover. Теперь добавим два диспетчера (они
находятся в Браузере Актеров (Actor Browsers), в разделе Triggers).

Лезем в свойства одного из диспетчеров, в раздел Events, находим поле Tag и
вписываем сюда имя, например, Dispatcher1. В разделе dispatcher зайдем в
настройку OutEvents. В поле [0] впишем имя (Tag) мувера, в данном случае
loopingmover, а в поле [1] - вводим dispatcher2.  е забудьте в свойстве
OutDelays в поле [1] указать время (в секундах), необходимое для полного
открытия/закрытия. Узнать время не трудно: если MoveTime мувера равен 2, и у
него 4 кадра-ключа, ему понадобится 6 секунд для открытия/закрытия, а не 8
секунд: 4 кадра-ключа подразумевают движение из Key0(base) в Key1, затем из
Key1 в Key2, и наконец, из Key2 в Key3, т.е. три промежутка по 2 секунды. Итого
6 секунд.

Теперь то же самое проделаем и для второго диспетчера: имя (Tag) дадим ему
dispatcher2, а OutEvent[1] - dispatcher1:

\ 2 картинки - описывать их нет смысла и так ясно, что делать \

 а данном этапе осталось сделать одну вещь - добавить датчик (trigger) где-то в
уровне. При запуске карты мувер будет неподвижен, т.к. сперва нужно
активировать диспетчер. Если Вы хотите моментальной активации поместите датчик
где-то недалеко от места старта, где его кто-то точно включит, даже не
подозревая об этом.

После установки датчика не забудьте в свойcтве Events, в поле Event указать
либо Dispatcher1 либо dispatcher2 (в данном случае не имеет значения какой из
них будет являться первым).

The LoopMover Вообще в едиторе различают несколько видов муверов. Посмотреть
типы можно нажав правой кнопкой мыши на кнопке Добавить Мувер (Add Mover). В
развернувшемся списке Вы увидите все типы муверов. Самый верхний (Mover)
используется по умолчанию. Теперь же выберем LoopMover.

Классы муверов
______________

После непосредственного сконструирования самого мувера (ну и, естественно,
нескольких кадров-ключей), стоит залезть в его опции (Mover Properties). Затем
заходим в Objects, в пункт InitialState. Как Вы видите, здесь появилось новое
свойство - LoopMove. Это единственное свойство заставляющее работать мувер
бесконечно. Поэтому выберем его.

Единственный недостаток в том, что LoopMover не начнет движение сам. Его нужно
активировать. Для этого добавьте где-нибудь датчик (Trigger) и в его свойствах
в поле Event введите имя (Tag) Вашего LoopMover. Теперь при старте уровня,
мувер начнет движение как только кто-то попадет в радиус действия датчика. Если
же Вы покинете радиус действия, то и движение мувера прекратится в положении
ближайшего кадра-ключа.

Если же Вы хотите, чтобы мувер продолжал свое движение вне зависимости от того
находитесь ли Вы в радиусе действия датчика или нет, нужно позаботится о том
чтобы датчик был активирован все время. Вам понадобится кто-то или что-то для
активации датчика, но при этом им не должен являться игрок. Естественно это
что-то должно находится все время в радиусе действия Вашего датчика. К счастью
большинство pawns подходит для этой роли. Итак, выставляем опцию TriggerType в
положение TT_PawnProximity. Идеальный pawn для таких вещей - это  алийский
кролик (Nali Rabbit). Он находится в Браузере Актеров (Actor Class Browser) -
смотри скрин внизу.  о перед тем как Вы добавите кролика, Вам понадобится
комната размером, скажем, 256*256*256 за пределами Вашей карты. Сюда же воткнем
датчик. В данном случае здесь никто не сможет пристрелить кролика, да и убежать
ему будет некуда.

\ картинка - открыт браузер классов, кде выделена строка
     Pawn\FlockPawn\NaliRabbit    \
                    ^^^^^^^^^^
Скорее всего Вы подумаете, что нужно всего лишь закинуть этого кролика поближе
к датчику и все будет ОК.  о спешу Вас огорчить - не все так просто. В едиторе
есть баг - когда кто-то находится в радиусе действия датчика при старте уровня,
датчик не активируется. Для реальной активации Вам придется именно "зайти" в
радиус действия. Выход из этой ситуации - поместить кролика над датчиком, так
чтобы при падении он попал в радиус его действия. После того как Вы добавили
кролика в нужное место (над датчиком), нужно выставить его физику для падения.
Сделаем это, открыв его свойства, пункт Movement. Здесь в списке Physics
выберем PHYS_Falling.

По некоторым причинам, падение работает только в том случае, если Вы поместили
сначала кролика на пол, а затем подвинули его наверх с помощью мышки.  е
устанавливайте его сразу на потолок. Еще по другим причинам, при изменении
чего-либо на уровне, после того как Вы установили Вашего кролика, весь механизм
с ним может не заработать. Поэтому кролик - последнее, что должно быть
добавлено к Вашей карте перед ее сохранением.

Также Вы должны быть уверены, что кролик находится точно над пространством
действия датчика (если помните - то это цилиндр) и что он не разобьется при
падении. При использовании комнаты размером 256*256*256 поместите датчик ровно
по центру, примерно на высоте 64 юнита. Теперь перейдите в его свойства, раздел

Collision. Здесь установите CollisionHeight равный 64, а CollisionRadius
сделайте 200. Теперь смело добавляйте кролика. Вы можете посмотреть как это
выглядит на скрине ниже. Красный прямоугольник - не что иное, как радиус
действия датчика (его видно, потому что установлена Radii View):

\ картинка - комната с кроликом над зоной коллизий триггера \

 у и последняя вещь о которой стоит упомянуть - в свойствах мувера, в списке
MoverEncroachType выберем ME_IgnoreWhenEncroach, в противном случае мувер
остановиться навсегда при прикосновении к нему одним из игроков.

Если же Вы хотите избежать подобных проблем, Вы можете воспользоваться
комбинацией двух вышеописанных методов: DualDispatcherMethod и LoopMover. В
данном случае установите OutDelay[1] равным MoveTime Вашего мувера, вместо
указания времени полного открытия/закрытия.

Теперь рассмотрим некоторые отличия этих двух методов. Основное отличие состоит
в порядке движения между кадрами-ключами в случае если их больше чем 2. К
примеру, возьмем мувер с тремя кадрами-ключами.  ормальный мувер будет
двигаться так: из Key0(base) в Key1, из Key1 в Key2, после этого вернется в
Key1 и, наконец, в Key0(base).

LoopMomer будет вести себя несколько иначе: из Key0(base) в Key1, потом в Key2,
но после этого мувер кратчайшим путем вернется в Key0(base).
Поэтому в зависимости от Ваших потребностей используйте либо первый либо второй
метод.

TriggerPound: этот метод использует специфическое значение InitialState вашего
мувера: TriggerPound. То есть после изготовления мувера и нескольких
кадров-ключей не забудьте установить это значение в InitialState. В принципе
TriggerPound это то же самое что и InitialState равный LoopMove при
использовании LoopMover, с той лишь разницей, что в данном случае мувер будет
двигаться как в DualDispatcherMethod. Для активации мувера воспользуйтесь той
же схемой с кроликом.

Преимущество этого метода состоит в том, что Вы можете регулировать время
задержки мувера перед началом закрытия (последний кадр-ключ), а также время
задержки перед открытием (исходное положение). Для этого перейдем в свойства
мувера (Mover Properties), в раздел Mover. Для задержки перед открытием
воспользуйтесь полем StayOpenTime, а перед закрытием - OtherTime.

\ примечание - во всей истории с инициализацией луп-мувера непонятно одно -
  нафига нужен кролик? предлагаю еще два решения:
  1. возле PlayerStart поставить триггер, на который игрок по любому
  наступит и активирует один раз.
  Триггер связать с мувером, расположенном над уровнем и уже
  к нему приаттачить еще один триггер настроенный на любое воздействие и
  с параметром TriggerControl. Механика такова - игрок запускает первый
  триггер и мувер опускается (туда, где его не будет видно) и не возвра
  щается больше. Второй триггер детектит игрока (этот триггер должен
  покрывать зоной своего воздействия весь уровень) и пускает нужный
  луп-мувер. Так как детектить он будет постоянно, то луп-мувер будет
  постоянно двигаться.
  2. надо взять триггер, который сработает автоматически при запуске уровня,
  например Stohastic Trigger, естественно ему надо настроить соответствующим
  образом минимальное и максимальное время срабатывания.\
_______________________________________________________________________________
_______________________________________________________________________________

Связанные муверы (AttachMovers)
_______________________________

Существует особый вид муверов - связанные муверы (AttachMover). Смысл их
заключается в том, что они привязаны к другому муверу и в точности копируют их
движения.  а самом деле для тех же целей намного легче, да и надежней
использовать нормальные муверы, если Вы хотите, чтобы объект двигался вместе с
мувером.

Для начала создайте нормальный мувер, дайте ему имя (Tag), например,
AttachMover. Теперь добавьте любой объект: оружие, декорацию, свет и т.д. в Ваш

уровень. Откройте окно свойств объекта, и перейдите в пункт Movement. Здесь в
поле AttachTag впишите имя (Tag) мувера, в данном случае AttachMover. После
этого в разделе Advanced установите следующие значения: bMovable равный true,
bNoDelete равный false и bStatic тоже в положение false:

\ картинка - окно Light Properties с раскрытой строкой Advanced. \

Теперь "привязанный" объект будет в точности повторять движения мувера, не
зависимо от каких-либо внешних помех - даже будет проходить сквозь стены.

Если Вы все же хотите воспользоваться классом AttachMover, то нажмите правой
кнопкой мышки на иконке Add Mover и выберете его в списке. После этого откройте

свойства связанного мувера (AttachMover Properties). Дайте ему имя связного :)
(AttachTag). Теперь все объекты, имеющие такое же имя будут двигаться вместе в
ним.

Получается, что единственная разница между использованием AttachMovers и
обычного мувера лишь в том, что при использовании последнего Вы указываете
одинаковое имя (Tag) в поле AttachTag объекта и в поле Tag самого мувера, а в
другом случае наоборот: в поле AttachTag мувера и в поле Tag объекта.
_______________________________________________________________________________
_______________________________________________________________________________

Муверы, связанные между собой
_____________________________

 икто Вам не запрещал привязывать один мувер к другому. Делается это абсолютно
точно также как и с привязкой объекта. При таком раскладе у Вас появляется
возможность создания мувера у которого промежуточные положения могут не
совпадать с заданными кадрами-ключами. Предположим мувер (А) привязан к другому

муверу (В). Мувер А будет двигаться в соответствии со своими кадрами-ключами,
но в случае движения мувера В, он также будет копировать его движения. Поэтому,
если мувер В двигается в другом направлении отличном от траектории движения
мувера А, непосредственно сам мувер А будет совершать движение по двум
направляющим: его собственная и направление мувера В.

Мувер В, в свою очередь можно спрятать где-то на карте, так что игроки будут
видеть только мувер А!

Если Вы захотите чтобы мувер был привязан к нескольким муверам, необходимо
будет создать цепочку: мувер А привязан к муверу В, а мувер В к муверу С и т.д.

 а данном этапе могут возникнуть непредвиденные ситуации: мувер, привязанный к
другому муверу имеет свои кадры-ключи (например движение влево), а мувер В, к
которому он привязан, совершает движение вверх. Следовательно мувер А будет
двигаться влево и вверх одновременно. Если же теперь муверу А нужно будет
вернуться в исходное положение (справа), то он автоматически опустится вниз,
даже если мувер В все еще наверху. В случае движения мувера В в свое исходное
положение (вниз), мувер А сдвинется еще ниже и уйдет в пол!

Основное использование такой техники - это лифты с внутренними дверями. В этом
случае двери будут опускаться и подниматься вместе с лифтом.

Кручение может не работать, хотя иногда встречаются рабочие.

Используя привязки муверов друг к другу Вы увидите, что это направление имеет
огромный потенциал. С помощью привязки Вы сможете делать поразительные вещи, не
прибегая к помощи скриптов!
_______________________________________________________________________________
_______________________________________________________________________________

События муверов
_______________

 иже описано несколько полезных событий муверов.

Первый тип событий - это когда что-то или кто-то запускает мувер. В разделе
Movers окна свойтсв (Mover Properties) есть две опции: BumpEvent и
PlayerBumpEvent.

BumpEvent - событие возникающее каждый раз при запуске мувера
кем-либо (игроком, объектом и т.д.), в то время как событие PlayerBumpEvent
возникает в следствие запуска только игроком.

Второй тип событий - те же что использовались для датчиков (Triggers). В окне
свойств, выберем пункт Events. Когда Вы введете в поле Event имя события, оно
будет вызвано при достижении мувером своего последнего кадра-ключа. С помощью
этого Вы можете создать кнопочку, являющуюся мувером, которая заезжает в стену
при нажатии, и как только кнопка достигнет своего последнего положения
откроется дверь. В данном случае датчики не понадобятся.

При использовании некоторых типов муверов, таких как GradualMover и
AssertMover, Вы можете указать различные события для каждого кадара-ключа. Это
будет объяснено ниже.
_______________________________________________________________________________
_______________________________________________________________________________

Лифтовой мувер (ElevatorMover)
______________________________

ElevatorMover, наверное, является самым продвинутым мувером, т.к. он
предоставляет Вам возможность контролировать каждый кадр-ключ. Пример: если у
Вас мувер с четырьмя кадрами-ключами, Вы можете поставить 4 лифтовых датчика
(ElevatorTriggers) на уровне - один для Key0(base), второй для Key1, третий для
Key2 и четвертый для Key3.

Чтобы добавить мувер этого класса просто нажмите правой кнопкой мыши на иконке
AddMover и в списке выберете ElevatorMover. Организуйте для него 4 кадра-ключа.

Откроем свойства мувера (ElevatorMover) и в разделе Objects установим
InitialState в положение ElevatorTriggerGradual. Затем в пункте Events дадим
муверу имя (Tag), например, ElevatorMover.

Лифтовые муверы не работают с нормальными датчиками. Вам необходимо будет
использовать специальный вид датчиков - лифтовые датчики (ElevatorTriggers).
Ясное дело, что у таких датчиков есть свои, присущие только им, настройки.
Кстати, ElevatorTrigger находятся в Браузере Актеров (Actor Class Browser) в
разделе Triggers.

Добавьте 4 таких датчика (каждый для соответствующего кадра-ключа), и перейдите
в их настройки. В разделе Events в поле Event введем ElevatorMover. Теперь Вы
увидите красные линии, проведенные из датчиков к муверу.

Затем, выберете один из лифтовых датчиков (ElevatorTriggers), откройте окно
свойств, пункт ElevatorTrigger.

Здесь находятся следующие настройки:
  bTriggerOnceOnly - датчик одноразовый (после одной активации больше работать
  не будет);

  ClassProximityType - используйте в совокупности с TT_ClassProximity. Более
  подробно смотрите в главе Муверы с датчиком (Triggered Movers);

  GotoKeyFrame - это и есть то уникальное свойство присущее только лифтовым
  датчикам: при активации подобного датчика, он не только активирует мувер, но
и указывает ему к какому кадру-ключу ему нужно двигаться, тем самым,
  указывая, что он контролирует этот кадр-ключ;

  MoveTime - если больше чем 0, указывает скорость Лифтового Мувера
  (ElevatorMover), но, судя по всему, эта фишка пока не работает;

  TriggerType - указывает, кто или что может быть причиной активации датчика.
  Более подробно описано в главе Муверы с датчиком (Triggered Movers);

Установим свойство GotoKeyFrame для каждого датчика соответственно равным 0, 1,
2 и 3.

Если теперь запустить карту, и Вы активируете один из датчиков, мувер
переместиться в положение кадра-ключа, номер которого Вы указали в опции
GotoKeyFrame данного датчика.  е имеет значения, с какого кадра-ключа мувер
начал движение - он всегда переместиться в нужное положение!

Этот тип мувера называется Лифтовой мувер, но, тем не менее, его можно
использовать для других вещей. Для всего, что требует фиксации в разных
кадрах-ключах, может быть использован этот класс муверов. Яркий пример этому -
поезд, перемещающийся между различными станциями. Также, если Вы задумаете
использовать мувер с двумя кадрами-ключами, но с отдельными датчиками для
каждого положения - воспользуйтесь Лифтовым Мувером.

Что касается звуков: для Лифтовых Муверов (ElevatorMover) никогда не
используйте зацикленные звуки - они останутся звучать вечно.

И еще одна вещь, вернее баг: если мувер был заблокирован при движении, он
остановиться и не будет слушаться кнопок (датчиков). Единственный выход -
установить опцию MoverEncroachType в положение ME_IgnoreWhenEncroac
_______________________________________________________________________________
_______________________________________________________________________________

AssertMover
___________

Этот тип муверов будет находиться в открытом состоянии до тех пор пока Вы
находитесь в радиусе действия датчика. Когда Вы покинете пределы досягаемости
датчика мувер остановиться и "подождет" в ближайшем кадре-ключе на своем пути,
а затем закроется. Это означает, чем дольше Вы находитесь в радиусе действия
датчика, тем больше мувер откроется.  у, естественно, если у него есть больше
двух кадров-ключей.

Сделать этот мувер просто: на кнопке Add Mover нажмите правый батон мыши и в
списке выберете AssertMover. сделайте для него более 2 кадров-ключей, например
4. В его свойствах укажем InitialState равный AssertTriggerOpenTimed. И дадим
ему имя (Tag) - например AssertMover. Затем добавим датчик с таким же именем в
поле Event.

Откроем окно свойств мувера (AssertMover Properties), и воспользуемся
настройками в разделе AssertMover.

  bOnceOnlyStopOpen - если установлено в положение true, то мувер останется
  навсегда открытым по достижении последнего кадра-ключа;

  CloseTimes - в отличии от нормальных муверов, которым можно задать время
  закрытия между соседними кадрами-ключами (и это время будет относиться ко
  всем кадрам-ключам), для этого класса муверов есть возможность указания

  времени закрытия для каждого промежутка между кадрами-ключами. CloseTime[0] -
время движения (при закрытии) из Key1 в Key0(base), CloseTime[1] - время
  движения (при закрытии) из Key2 в Key1 и т.д. не забывайте использовать эти
  настройки вместо свойства MoveTime. Если оставить эту опцию равную 0, то Ваш
  мувер будет двигаться  еРеально быстро;
  OpenTimes - OpenTime[0] - время необходимое муверу для движения при открытии
  из Key0(base) в Key1, OpenTime[1] - из Key1 в Key2 и т.д.

   еудобно, что CloseTimes и OpenTimes работает только в случае если
  InitialState мувера установлено в AssertTriggerOpenTimed. Если Вы используете

  другой InitialState, то для указания времени мувер использует MoveTime. Если
  Вы все же хотите управлять временем перемещения мувера для каждого
  кадра-ключа, но не используете AssertTriggerOpenTimed, Вы можете симитировать
  его, привязав датчик к муверу (см. главу Связанные муверы (AttachMovers));
  WaitUnAssertTime - это время задержки перед началом закрытия, в случае если
  Вы покинули радиус действия датчика;
_______________________________________________________________________________
_______________________________________________________________________________

GradualMover
____________

Этот тип муверов по достижении каждого из своих кадров-ключей меняет свое имя
(Tag). Поэтому в положении, соответствующем кадру-ключу 0 (Key0), мувер будет
"слушаться" одного датчика, в другом положении (например, в Key1) - уже
другого. Также у Вас есть возможность указать разные события для каждого
кадра-ключа мувера. Добавим такой мувер и зайдем в его свойства (GradualMover
Properties).

  CloseTimes - то же самое что и CloseTimes для AssertMover;

  Events - событие, вызываемое мувером для каждого из первых 6 кадров-ключей.
  Вы можете использовать это, например, для открытия дверей на разных этажах, в
  зависимости от того, на каком находится GradualMover;

  OpenTimes - то же самое что и OpenTimes для AssertMover;

  Tags - имя для каждого кадра-ключа мувера (возможно указание только для
  первых 6 кадров-ключей). Если для Tag[0] введено А, а для Tag[1] - В, то в
  положении Key0(base), мувер придет в движение только при возбуждении события
А,и никак не отреагирует при возникновении события В. Если же мувер  находится
в Key1, то он активируется событием В. Событие А на него, в данном  случае,
никак не подействует;

Зайдя в пункт InitialState в разделе Object свойств мувера, Вы заметите 3 новых
значения для InitialState:

  GradualTriggerToggle - при активации датчика соответствующего Tag[0], мувер
  сместится в последний кадр-ключ и останется в этом положении до следующей
  активации именно тем же датчиком, что вызовет возврат в исходное положение.
  Мувер не будет останавливаться в промежуточных кадрах-ключах, и Вы не можете
  использовать различные имена (Tags) - в данном случае работать будет только
  Tag[0]. Тем не менее, различные события для каждого положения все же будут
  иметь силу;

  GradualTriggerPound - очень непонятный мувер. При тестировании он действовал
  так: при попадании игрока в радиус действия датчика первый раз, мувер
  открылся и затем закрылся. Когда игрок покинул радиус действия - мувер
проделал то же самое, т.е. открылся и затем закрылся.  о после этого он вдруг
  начал действовать как GradualTriggerOpenTimed мувер, описанный ниже.
Упоминаемый здесь датчик соответствует Trigger0 в примере ниже;

  GradualTriggerOpenTimed - это единственное значение InitialState, при котором
  мувер реально использует различные имена (Tags). Если мувер закрыт и при этом
  Tag[0] равен А, Tag[1] равен В, Tag[2] равен С, а соответствующие датчики
  имеют те же самые события (Events), то Датчик0 (Trigger0) переместит мувер в
  Key1. В этом положении он останется ждать активации Датчика1 (Trigger1).
  Затем мувер сдвинется в Key2. В этом примере это последний кадр-ключ, поэтому
  здесь мувер задержится на время, указанное в StayOpenTime, и вернется затем в
  Key0(base). Если Вы используете 6 кадров-ключей, у Вас будет мувер, который
  достигнет своего последнего кадра-ключа в случае предварительной активации 5
  датчиков в определенной последовательности (для последнего кадра-ключа датчик
  не понадобится). Плюс ко всему, Вы можете указать для каждого положения
  различные события (Event) мувера для активации чего-нибудь еще;
_______________________________________________________________________________
_______________________________________________________________________________

Группа возврата (ReturnGroup)
_____________________________

Группа возврата (ReturnGroup) - неизвестная большинству мапперов, но играющая
очень важную роль для муверов, настройка. Используется для разбиения муверов с
одинаковыми именами (Tags) на подгруппы.

Если у мувера при движении возникло препятствие, то в зависимости от настроек,
мувер либо остановиться, либо вернется, либо проигнорирует препятствие, либо
просто-напросто раздавит препятствие (игрока) - в данном случае не имеет
значение какое поведение выбрано (см. настройку MoverEncroachType). Итак,
допустим, у Вас имеется несколько муверов с одинаковыми именами (Tags), и один
из них был каким то образом заблокирован при движении. В этом случае все муверы

соответствующей группы либо остановятся, либо вернуться, либо.... Во избежании
подобного поведения единственный выход распределить каждый мувер в отдельную
группу возврата (ReturnGroup). Теперь все муверы одной группы (т.е. с
одинаковыми Tags, активирующиеся одним общим датчиком, и.т.д) не будут при
блокировке одного из них реагировать на поведение своего "брата".

Предупреждение: когда Вы добавляете мувер, вне зависимости от их количества,
имя устанавливаемое по умолчанию будет Mover. Это означает, что все муверы
будут иметь один и тот же Tag (ну если Вы, конечно, не поменяли имя вручную), и
соответственно будут членами одной группы. Поэтому, если Вы очень удивлялись
странному поведению, скажем, дверей при блокировке лифта на одном уровне,
причина кроется именно в группе возврата.

 екоторые классы муверов, такие как GradualMover будут также останавливаться и
возвращаться вместе, даже если у них разные имена (Tags). В данном случае Вам
просто необходимо будет распределить их по разным группам возврата. Если Вы, к
примеру, соорудили головоломку, используя GradualMover, то ее работа может не
соответствовать задуманному Вами сценарию, из-за неадекватного поведения
муверов. Здесь также выручит использование различных ReturnGroup для каждого
мувера.

При наличии нормальных муверов с различными именами (Tags), но имеющих
одинаковую группу возврата, они также будут останавливаться и возвращаться
вместе.
_______________________________________________________________________________
_______________________________________________________________________________

Еще некоторые свойства муверов
______________________________

 иже перечислены все свойства муверов, которые не рассматривались ни в одной из
вышеприведенных глав:

  bDamageTriggered - мувер активируется при нанесении ему повреждения,
  количество которого устанавливается в поле DamageThreshold. Работает только
  при InitialState установленном TriggerOpenTimed или TriggerToggle. Чтобы
  узнать урон, наносимый оружием в Unreal Tournament, а также узнать больше об
  InitialState, веринесь к главе Муверы с датчиком (Triggered Movers);

  bSlave - делает текущий мувер "рабом" другого мувера. Еще один способ
  привязки муверов друг к другу. Эффект при этом тот же что и при использовании
  AttachTag мувера;

  bUseTriggered - скорее всего эта фишка была задумана для активации мувера
  путем нажатия кнопки на клавиатуре, как это сделано, например, в Half-Life.
  о в финальной версии Unreal, от ее реализации отказались;

  DamageThreshold - укажите здесь количество повреждения, необходимое для
  активации мувера (имеет смысл только при bDamageTriggered равном true);



_______________________________________________________________________________

Часть III
_______________________________________________________________________________
_______________________________________________________________________________

Дверь, открывающаяся при нажатии кнопки
_______________________________________

Это будет обычная дверь, которая открывается при нажатии кнопки. Кнопка, в свою

Секция 2 из 3 - Предыдущая - Следующая

© faqs.org.ru