Всем привет! Есть желание под GZDoom написать стандартненький такой файлик MAPINFO (для Doom), для "карт-сборок" (например одиночные карты собрать в одном ваде) что бы запускались по порядку все 36 карт. Но вот посмотрел разные образцы файла MAPINFO и есть вопрос. Что означают эти параметры...
Есть парочка вопросов, но перед их формулировкой с распишу конечные цели (так как если мои цели решаются более эффективными методами, то вопросы могут отпасть).
Цели:
1) Сделать так, чтобы 3D модели конкретно взятых акторов (например модель оружия, которое валяется на полу) "смотрели строго на игрока а-ля спрайты" (как по вертикали, так и по горизонтали), не используя декорейт (ACS использовать можно)
2) Сделать так, чтобы 3D модели конкретно взятых акторов (например статуя из еретика, которая является индикатором того, что дверь (или другой объект) можно открыть/активировать строго ключем того цвета, который у шарика над статуей) смотрели строго спиной к объекту (например двери). Интересует решение как с декорейтом так и без (ACS использовать можно)
Как я вижу решение первого вопроса на ACS:
Скрытый текст:
#library "RotateModels" // Name of the library
#include "zcommon.acs"
3) Как узнать TIDшники всех экземпляров конкретно взятого актора на карте? Например TIDшники двустволок
4) Как адекватно сделать, чтобы скрипт выполнялся вечно? В вышеприведенном примере я это сделал через костыль, но меня интересует более "корректное" решение
5) Я так понял, что "Delay (1)" это слишком расточительное использование процессора. Какое значение задержки вы посоветуете для вышеприведенной цели (чтобы модель смотрела лицом на игрока а-ля спрайт) ?
Подскажите как исправить. в MAPINFO написал вот такой фрагмент текста.
map e1m1 "Level 1"
music d_e1m1
next e1m2
sky1 SKY1 0.0
map e1m2 "Level 2"
music d_e1m2
next e1m3
sky1 SKY8 0.0
map e1m3 "Level 3"
music d_e1m3
next e1m4
secretnext e1m9
sky1 SKY7 0.0
Все бы ничего, но есть проблема, теперь фоном звучит тема D_INTER (у меня мелодии в .mp3), причем звучит как то по особенному, не смотря ни на конец уровня, ни на переход на следующий уровень... как бы ни на что "не обращает внимания", просто звучит фоном и всё ("живет своей жизнью"). Подскажите как исправить этот глюк, может еще чего надо дописать в MAPINFO?
Чтобы крутить конкретно змейки - нужно к каждой такой модели(а она в здуме АКТОР) иметь прямой конкретный доступ. Легче тупо сделать карты-патчи с нормально выставленными поворотами этих самых змеек(что скорее всего сделано в думсдей).
С одной стороны - ну не верится что декорейт и acs настолько убоги, что не умеют перебирать все запертые ключем двери, определять их угол поворота, таким же образом найти змеек и поворачивать их на этот же угол (или сканировать местность рядом со змейкой на предмет двери (например определив координаты змейки, перебрать все акторы соответствующих типов с ближайшими координатами) ). Неужели таких простых действий декорейт и ацс не умеют?
С другой стороны: как сделать простейшее действие "перебрать все объекты на карте, и отфильтровать из них те, которые являются акторами заданного типа, получив список (или массив) требуемых объектов, в котором можно узнать их TID" (и соответственно, когда TID распознаны, уже к ним применять ACS команды) - такое надеюсь реально на ACS сделать?
4) Как адекватно сделать, чтобы скрипт выполнялся вечно? В вышеприведенном примере я это сделал через костыль, но меня интересует более "корректное" решение
5) Я так понял, что "Delay (1)" это слишком расточительное использование процессора. Какое значение задержки вы посоветуете для вышеприведенной цели (чтобы модель смотрела лицом на игрока а-ля спрайт) ?
А где костыль-то? Все правильно делаешь, у тебя там не мегаскрипт, который прям-таки жрет CPU. Без задержки совсем нельзя - здум убьет шкрипт по ранауту.
theleo_ua :
С одной стороны - ну не верится что декорейт и acs настолько убоги, что не умеют перебирать все запертые ключем двери
А кто умеет? А вообще, можно было бы, если бы кое-кто добавил бы индивидуальный доступ к секторам и линиям. Но графу и Ко. так приебались эти отрицательные тиды, что они решили, что это важнее индивидуального доступа. Возрадуйтесь!
theleo_ua :
С другой стороны: как сделать простейшее действие "перебрать все объекты на карте, и отфильтровать из них те, которые являются акторами заданного типа, получив список (или массив) требуемых объектов, в котором можно узнать их TID" (и соответственно, когда TID распознаны, уже к ним применять ACS команды) - такое надеюсь реально на ACS сделать?
По факту: в heretic.wad, да и в других ивадах, вадах под бум порты тиды у всех акторов нулевые, если кто-то не заменит конечно. Если не лень лепить костыли, то под спойлером решение:
Скрытый текст:
Раздать тиды акторам таки можно, но придется сделать сначала одну вещь в декорейте:
Actor NewTest : Test replaces Test //замени тест на что нужно
{
States
{
TNT1 A 0 //в самом первом фрейме экшены не работают, enjoy bydlorate
TNT1 A 0 ACS_ExecuteAlways("TIDSetter")
goto Super::Spawn
}
}
После получения каждым уникального тида можешь развлекаться как хочешь уже.
А еще мегарешение: берешь такой heretic.wad и вручную расставляешь углы!
И да, "определить их угол поворота". Ты считаешь, что это так просто? Особенно, учитывая, что сторона двери может состоять из больше, чем одной линии.
С одной стороны - ну не верится что декорейт и acs настолько убоги, что не умеют перебирать все запертые ключем двери, определять их угол поворота, таким же образом найти змеек и поворачивать их на этот же угол (или сканировать местность рядом со змейкой на предмет двери (например определив координаты змейки, перебрать все акторы соответствующих типов с ближайшими координатами) ). Неужели таких простых действий декорейт и ацс не умеют?
Увы как говорится - придётся поверить, что декорейт и АЦС хоть и богаты, но порой некоторые элементарные вещи решить не могут.
Начнём по порядку.
theleo_ua :
1) Сделать так, чтобы 3D модели конкретно взятых акторов (например модель оружия, которое валяется на полу) "смотрели строго на игрока а-ля спрайты" (как по вертикали, так и по горизонтали), не используя декорейт (ACS использовать можно)
Без декорейта на сколько знаю никак, точнее как "никак", можно конечно использовать в АЦС циклы, которые по формулам тригонометрии будут поворачивать конкретно взятые акторы лицом к игроку, но зачем? Ведь в декорейте это решить в стократ легче.
theleo_ua :
Как узнать TIDшники всех экземпляров конкретно взятого актора на карте? Например TIDшники двустволок
Опять же ещё раз повторюсь - в здуме НЕТ прямого доступа к КОНКРЕТНЫМ акторам. Чтобы управлять одним объектом, нужно чтобы у него был указатель, чего по моему в думовском движке как раз нет.
Однако есть небольшие хитрости. Например - временная смена тида, один на другой. Однако всё равно нужно применение декорейта(нужно вызывать скрипт из актора). Алгоритм таков:
- Пишем в переменную оригинальный тид активатора.
- Присваиваем ему отличный от всех ТИД.
- Производим нужную манипуляцию.
- Меняем ТИД активатора обратно на старый, который записан в переменную.
Что это даст? Не нужно ломать голову по поводу прямого доступа к актору и не нужны никакие километровые массивы, но обязательно использование декорейта, увы.
theleo_ua :
4) Как адекватно сделать, чтобы скрипт выполнялся вечно? В вышеприведенном примере я это сделал через костыль, но меня интересует более "корректное" решение
5) Я так понял, что "Delay (1)" это слишком расточительное использование процессора. Какое значение задержки вы посоветуете для вышеприведенной цели (чтобы модель смотрела лицом на игрока а-ля спрайт) ?
Так и делать. Вечный цикл в АЦС прост:
While(true)
{
Бла бла бла;
Delay(1); //Чтобы не терминировало движком здума
}
Делаешь счётчик и в самом цикле проверяешь значение. Если условие выполняется, ставишь инструкцию Terminate(выходит из цикла и завершает скрипт).
А на счёт Delay(1), скажу, что больно оно процессор не кушает, по крайней мере я на старом компе пробовал, а он достаточно слабоват был в плане ЦП. Сам движок порой куда больше съедает мощности.
TNT1 A 0 //в самом первом фрейме экшены не работают, enjoy bydlorate
Уже более-менее исправлено, если конечно принципиально требуется использовать именно первый фрэйм:
State keywords:
NoDelay (New from 2.7.1)
Forces the action function associated to the state to be executed during the actor's first tic. This is only useful for the first state in an actor's spawn sequence.
Не, тут понятно, что ничего лучше пока нет, но я удивлен, что они разработали сложный механизм скриптов и не добавили туда простейшие вещи
LEX SAFONOV :
Увы как говорится - придётся поверить, что декорейт и АЦС хоть и богаты, но порой некоторые элементарные вещи решить не могут.
ок
ChaingunPredator :
Если не лень лепить костыли, то под спойлером решение:
Спасибо, если не найду лучшего решения чем костыли, тогда придется их использовать
ChaingunPredator :
А еще мегарешение: берешь такой heretic.wad и вручную расставляешь углы!
1) Слишком геморное решение
2) Ивады и другие НЕдекорейтовые (и\или НЕздум-ацсные) вады не интересуют, так как на них я играю в думсдей. Так что только декорейтовые/здум-ацсные Пвады, только хардкор
ChaingunPredator :
И да, "определить их угол поворота". Ты считаешь, что это так просто? Особенно, учитывая, что сторона двери может состоять из больше, чем одной линии.
Ну я предполагал, что дверь это актор (или аналог актора), "запертая желтым ключем" - проперти, и что у этого актора есть проперти "угол". Если это не так, тогда да, посложнее будет.
LEX SAFONOV :
Скрытый текст:
Без декорейта на сколько знаю никак, точнее как "никак", можно конечно использовать в АЦС циклы, которые по формулам тригонометрии будут поворачивать конкретно взятые акторы лицом к игроку, но зачем? Ведь в декорейте это решить в стократ легче.
Опять же ещё раз повторюсь - в здуме НЕТ прямого доступа к КОНКРЕТНЫМ акторам. Чтобы управлять одним объектом, нужно чтобы у него был указатель, чего по моему в думовском движке как раз нет.
Однако есть небольшие хитрости. Например - временная смена тида, один на другой. Однако всё равно нужно применение декорейта(нужно вызывать скрипт из актора). Алгоритм таков:
- Пишем в переменную оригинальный тид активатора.
- Присваиваем ему отличный от всех ТИД.
- Производим нужную манипуляцию.
- Меняем ТИД активатора обратно на старый, который записан в переменную.
Что это даст? Не нужно ломать голову по поводу прямого доступа к актору и не нужны никакие километровые массивы, но обязательно использование декорейта, увы.
Так и делать. Вечный цикл в АЦС прост:
While(true)
{
Бла бла бла;
Delay(1); //Чтобы не терминировало движком здума
}
Делаешь счётчик и в самом цикле проверяешь значение. Если условие выполняется, ставишь инструкцию Terminate(выходит из цикла и завершает скрипт).
А на счёт Delay(1), скажу, что больно оно процессор не кушает, по крайней мере я на старом компе пробовал, а он достаточно слабоват был в плане ЦП. Сам движок порой куда больше съедает мощности.
понял, спасибо
Добавлено спустя 7 минут 4 секунды:
ChaingunPredator :
YURA_111
Спасибо, не знал. Все еще не особо понимаю смысла всей это клоунады, правда...
theleo_ua
Вобщем что хочу посоветовать, с помощью ацс и декорейт можно вертеть твои модели и даже больше, мне сейчас вникать в это дело лень, занят своим модом, но тебе надо как минимум знать как называется актор который надо вертеть, что бы сделать Replaces(в звики должно быть описание или посмотри в самом Wad архиве хексена как-то.)
Actor новая статуя : старая статуя replaces старая статуя (Ид тебе не нужен т.к. ты заменяеш стандартного актора на своего)
{
States
{
Spawn:
TNT1 A 0 ACS_NamedExecute("TurnModel1",0) //как только начнется выполнять spawn: ацс повернет твою модель и застынет на modl a -1
MODL A -1
Stop
}
}
В АЦС
Script "TurnModel1" (VOID)
{
SetActorAngle (0, GetActorAngle (0) - 0.5); \\тут само определит у кого надо брать угол(GetActorAngle в этом поможет, а ид 0 потому что будет брать ид активатора, тоесть актора которого ты заменишь), тебе лишь надо выставить в какую сторону его повернуть, а именно -0.5 (тут выставь свой угол)
}
Скрипт простейший, я его не проверял и не продумывал полностью, может он и рабочий, но примерно так должно работать если я правильно понял что тебе надо..
Как работают статуи в хексене не знаю, наверно лучше с этого начал объяснять что хочешь сделать
Добавлено спустя 8 минут 49 секунд:
theleo_ua :
1) Сделать так, чтобы 3D модели конкретно взятых акторов (например модель оружия, которое валяется на полу) "смотрели строго на игрока а-ля спрайты" (как по вертикали, так и по горизонтали), не используя декорейт (ACS использовать можно)
А чем decorate не угодил? Я же тебе писал как такое сделать только декорейтом, и ИМХО лучше делать это именно декорейтом, особенно если твой мод запустить на гоззе 2х (которая зарекомендовала себя в моих глазах как шустрая, но с кучей проблем версия..)
Да и помоему только через ацс не сделать так, все равно придется юзать декорейт.
Добавлено спустя 5 минут 59 секунд:
theleo_ua :
Если же ты имел в виду "вращать модели независимо от игрока (разово при старте карты)", тогда следующий вопрос: каким образом через ACS определить, с какой стороны от модели находится "запертая ключем" дверь ?
Не совсем понял, но зачем тебе это? В вики глянь углы, да верти наздоровье, правда я определял где в игре север, юг и т.д. методом тыка, но вариантов не так много.
Ацс повернет модель туда куда пропишешь.
А если тебе надо что бы когда у игрока есть ключ статуя смотрела постоянно на игрока, вобщем что бы не гадать, писать не буду, но думаю можно сделать и так. Я со всякими Switchable акторами не дружу из-за ненадобности, но в такой статуе скорее всего это использовано.
Добавлено спустя 24 минуты 14 секунд:
Кстати по поводу поворота, можно обойтись и без ацс: Читай тут. Там очень хороший пример и как раз использовано Replaces.
Ну я предполагал, что дверь это актор (или аналог актора), "запертая желтым ключем" - проперти, и что у этого актора есть проперти "угол". Если это не так, тогда да, посложнее будет.
Если бы все так просто было, я б тебе написал решение уже давно. Двери - это тоже сектора. В акс, насколько я помню, обработка координат секторов отсутствует
theleo_ua :
не только я применяю костыли
В данном случае костыли лепят сами разработчики. Такое ощущение, что нельзя просто взять пофиксить, но нет, надо запилить какую-то приписульку для усложнения задачи.
Как раз таки читал, и не один раз и не могу понять в чем сложность или не возможность?
Может надо модель вертеть по особенному как-то (если дверь открыта, модель смотрит на игрока, если закрыта на стену или еще куда-то)?
Скрипт простейший, я его не проверял и не продумывал полностью, может он и рабочий, но примерно так должно работать если я правильно понял что тебе надо..
За пример спасибо, возможно такое понадобится в будущем, но сейчас я хотел немного не то
alekv :
Да и помоему только через ацс не сделать так, все равно придется юзать декорейт.
Да, я уже это понял, придется или декорейтом (в комбинации с ацс, там где декорейт бессилен), или забить
alekv :
А если тебе надо что бы когда у игрока есть ключ статуя смотрела постоянно на игрока
Кстати, а какой командой проверяется наличие ключа у игрока? И можно ли (при условии прямого доступа к актору через декорейт (например с TID читом, который посоветовали выше) ) определить координаты актора на карте? Каким методом обычно определяют координаты акторов? У самого игрока можно такие координаты определить?
alekv :
Кстати по поводу поворота, можно обойтись и без ацс: Читай тут. Там очень хороший пример и как раз использовано Replaces.
Спасибо, попробую потом
ChaingunPredator :
Если бы все так просто было, я б тебе написал решение уже давно. Двери - это тоже сектора. В акс, насколько я помню, обработка координат секторов отсутствует
В декорейте тоже?
alekv :
Как раз таки читал, и не один раз и не могу понять в чем сложность или не возможность?
В том, что:
ChaingunPredator :
Двери - это тоже сектора. В акс, насколько я помню, обработка координат секторов отсутствует
А если я не знаю, с какой стороны от статуи "запертая ключем дверь-сектор", то я не знаю, куда вращать модель актора статуи. Единственное, что тут можно попытаться начитерить, это вспомнить тот факт, что такие статуи в большинстве случаев (имеется в виду, если рядом с ней запертая ключем дверь, остальные ситуации пока опустим) расположены по 2 штуки рядом друг с другом (одна слева от двери, вторая справа от двери), но тут уже все упирается в возможности ACS/декорейта, мое понимание этих возможностей и фантазию. Пока идеи в голову не пришли.
alekv :
Может надо модель вертеть по особенному как-то (если дверь открыта, модель смотрит на игрока, если закрыта на стену или еще куда-то)?
Надо "спиной к запертому ключем-объекту". Иными словами, если запертый ключем объект смотрит под углом X на незапертую область, и 1-X на запертую область, то статуи надо повернуть, чтобы они смотрели на угол X. В большинстве случаев таких статуй по 2 штуки рядом.
Кстати, а какой командой проверяется наличие ключа у игрока? И можно ли (при условии прямого доступа к актору через декорейт (например с TID читом, который посоветовали выше) ) определить координаты актора на карте? Каким методом обычно определяют координаты акторов? У самого игрока можно такие координаты определить?
Вот координаты взятого актора проверить можно. Метод прост - использование в АЦС для этого конкретных функций. Их там три на данный момент, каждая берёт свою координату согласно осям X, Y и Z.
Вот тебе примерчик:
int MyX = GetActorX(0);
int MyY = GetActorY(0);
int MyZ = GetActorZ(0);
Стоит опять же учесть, что нуль обозначает взять координаты активатора(а если ты вызовешь их через декорейт в коде игрока, то активатором будет естественно игрок). Для других акторов будет действовать, но если хочешь чтобы алгоритм не тупил, то нужно перед манипуляциями временно поменять тид активатора, чтобы хоть как то иметь к нему персональный доступ. Да и под конец замечу ещё один факт того, что в думе координаты содержатся в fixed-типе поэтому применяй ещё функцию сдвига >> 16 когда пишешь координаты в переменные(это даст их более читабельный вид).
На счёт ключей не помню, но на сколько помню, что есть функция CheckInventory("Inventory") в АЦС. И по моему для пазл-акторов тоже пашет(ключ же по сути тоже итем, который поднимается и наличие которого в памяти обозначается как число 1)
theleo_ua :
Надо "спиной к запертому ключем-объекту". Иными словами, если запертый ключем объект смотрит под углом X на незапертую область, и 1-X на запертую область, то статуи надо повернуть, чтобы они смотрели на угол X. В большинстве случаев таких статуй по 2 штуки рядом.
Сложность заключается в том, чтобы вычислить X.
А ты опирайся не на запертый сектор(данные которого в АЦС никак ща не получишь), а на то, что статуй 2 штуки рядом.
А теперь вернемся к теме "сабмоделей" в декорейте - вобщем если для фласка в еретике http://zdoom.org/wiki/Classes:ArtiHealth отключить флаг +FLOATBOB, то вот как будет выглядеть 3D модель фласка с прозрачночтью (на скрине 10 значений прозрачности для стекла (от alpha 0.1 до alpha 1.0)):
Скрытый текст:
Так вот, если же я включаю +FLOATBOB заново, то сабмодели спавнятся вразнобой. Если же делать как вы говорили, что спавнер (актор, который ArtiHealth Replaces ArtiHealth) спавнит первую модель, а первая модель постоянно спавнит вторую, то получается, что вторая модель не будет колебаться в стиле FLOATBOB, а будет постоянно висеть снизу
Вот мой текущий код декорейта:
Скрытый текст:
//Glass
ACTOR ArtiHealth_Glass : ArtiHealth 5002
{
//BASE MODEL
ACTOR ArtiHealth_BaseModel : ArtiHealth 5001
{
//
//-FLOATBOB
}
//SPAWNER
Actor ArtiHealth_Spawner : ArtiHealth replaces ArtiHealth
{
States
{
Spawn:
PTN2 A 0
PTN2 A 0 A_SpawnItemEx("ArtiHealth_BaseModel",0,0,0,0,0,0,0)//,SXF_NOCHECKPOSITION)
PTN2 A 0 A_SpawnItemEx("ArtiHealth_Glass",0,0,0,0,0,0,0)//,SXF_NOCHECKPOSITION)
Stop
}
}
Такой код дает вот такой результат:
Скрытый текст:
Скрытый текст:
Самое смешное, что перезапускаем порт, и результат уже другой (если внимателньо присмотритесь, то даже здесь видно, что есть сдвиг):
Скрытый текст:
Скрытый текст:
Т.е. кроме того, что есть рассинхрон "координат" моделей, есть еще рандомность степени этого рассинхрона.
Как эту проблему пофиксить?
И еще вопрос: в моем коде я юзал DoomEd Number-ы 5002 и 5001. Какие диапазоны номеров вы посоветуете юзать, чтобы с наименьшей вероятностью они перекрыли те номера, которые в большинстве случаев юзают мапперы в своих вадах/модах (а также чтобы избежать других потенциальных глюков) ? Или у мапперов нет "негласных" правил касательно нумерации, и тут не угадаешь, соответственно придется подстраивать свой мод под каждый вадник, и чекать, что за номера там автор заюзал?
Т.е. кроме того, что есть рассинхрон "координат" моделей, есть еще рандомность степени этого рассинхрона.
Как эту проблему пофиксить?
И еще вопрос: в моем коде я юзал DoomEd Number-ы 5002 и 5001. Какие диапазоны номеров вы посоветуете юзать, чтобы с наименьшей вероятностью они перекрыли те номера, которые в большинстве случаев юзают мапперы в своих вадах/модах (а также чтобы избежать других потенциальных глюков) ? Или у мапперов нет "негласных" правил касательно нумерации, и тут не угадаешь, соответственно придется подстраивать свой мод под каждый вадник, и чекать, что за номера там автор заюзал?
Просто смысл в том, что флаг FLOATBOB двигает не только саму модель, но и ещё её коализию... Вдобавок эти модели у тебя обе основаны на ArtiHealth и будут летать в разнобой всё время с этим флагом. Нужно применять немного другой алгоритм:
Расскажу на примере.
Допустим у тебя есть 2 модели. Одна суб-модель и главная.
С главной то проблем никаких, основываешь её на ArtiHealth и всё.
Нужно разобраться конкретно с суб моделью. Она у нас состоит из нескольких кадров, верно? Делаешь не один суб-актор(суб-модель), а несколько однотипных, не основанных на ArtiHealth акторов, которые будут отличаться лишь наличием конкретного кадра из нашей суб-модели(без флага FLOATBOB!). Кадр как правило длинной в 1-2 тика, что ничтожно мало)(оно то нам и нужно).
Вернёмся к нашей главной модели. Она в спавн стейте должна будет по 1 тику на кадр каждый раз заспавнивать конкретный суб-актор(ясен пень именно тот, который должен работать синхронно с главной моделью).
Что такой алгоритм даст? Суб акторы будут жить ничтожно мало и мы не будет шибко замечать, что они якобы не летают, наоборот, будет возникать обман зрения из-за того, что летает конкретно главная модель, она же и спавнит ведь. Как то так. Если всё равно не понятно, то пришли полный код, я попробую подредачить.