А, я смотрю ты тоже до этого дошёл, что для каждого "Спрайт Фрейма", не нужно дублировать строчки. То есть вполне хватает указания AB в одной строчке. Я вчера это понял, когда изучал Декорейт. Там всё время в сточку Спрайт Фреймы пишутся. Решил попробовать это в Modeldef - удивительно, но работает.) Теперь не надо будет создавать массивы с одинаковыми записями. Хочу попробовать то же и с Спрайт Фреймами и с Фреймами модели. То есть например: ABС 012 123 может заработает...
Изучил твои записи, тут открылось странное дело, котороя я заметил. В FrameIndex, если в паке несколько моделей, всегда указывается - на каком фрейме спрайта, сколько будут отображаться моделей, то есть AB 0 ; AB 1. Я, чисто ради интереса, убрал вторую строчку - FrameIndex BAR1 AB 1 0, оставив только FrameIndex BAR1 AB 0 0. Самое интересное, что Гозза автоматом нашла, и подхватила вторую модель. Так что, насколько я понял - не надо указывать другие модели, а только главную, основную (надо ещё убедиться на многомодельных паках).
Вообщем, - с этим кодом всё понятно, он простейший, а вот что дальше?
Я, чисто ради интереса, убрал вторую строчку - FrameIndex BAR1 AB 1 0, оставив только FrameIndex BAR1 AB 0 0. Самое интересное, что Гозза автоматом нашла, и подхватила вторую модель
такого не должно быть, баг гоззы видимо
aivar242:
Вообщем, - с этим кодом всё понятно, он простейший, а вот что дальше?
для начала глянь код думсдей и твой моделдеф код внимательно. Ты понял, по какой логике создается такой моделдеф код как у тебя сейчас?
В принципе - да, понял. В Doomsday.ded - сначала указывается State Definition модели, то есть - то что относится к ваду Дума, определение люмпов спрайта, а вторая часть - это Model Definition модели - где уже указан путь к модели, и текстурам, фреймы анимации, фреймы модели.
В Modeldef - в принципе то же самое, только проще всё. (Пока) Возможно в дальнейшем будет сложнее, потому что в Modeldef - указываются параметры только модели, не более. В Doomsday.ded - указываются - параметры спрайта, модели, частиц, освещения, то есть, всё в одном месте, что довольно удобно.
Не знаю, может показалось, что-то Гозза при добавлении новых моделей начала вести себя нервно, подёргиваться. Хм. Ну да ладно, будем надеяться что это у меня нервный тик. Очень бы не хотелось бы, чтобы изучая все тонкости этого дела, получить на пол пути тормозистор. Большой расчёт на Гоззу, так как я заменяю ею целый Doomsday!
Экран у меня 1080р и держать планку в 60fps, да ещё с vSync, - даже с такой игрой как Doom, встроеной нашлёпке Intel HD 4600, сложновато.
для начала - запусти думсдей с этой моделькой бочки и сделай мне скрины ее взрыва (скрины в думсдее делаются кнопкой print screen либо той которая забиндена в опциях (сами скрины ложатся в папку Run\jDoom если думсдей 1.8.6 и C:\Users\имя юзера\Documents\Doomsday Frontend\runtime если 1.15.х)
мне надо несколько скринов, чтобы я смог по скринам примерно понять как выглядит у тебя анимация (т.е. можешь сделать скрины в несколько проходов, на нескольких бочках)
Может есть какая прога, где можно посмотреть анимацию md2 моделей? Там бы я анимационную гифку бы сделал.
ты не сможешь это посмотреть (и не спрашивай почему, так как через 6-7 комментариев сам поймешь, почему)
просто сделай мне скрины взрыва бочки из думсдея (вот если взрыв происходит например 6 секунд, то сделай скрин первой, 3-й и 5-й секунды (не обязательно с такой точностью, просто чтобы я увидел начало, середину и конец анимации взрыва) )
и еще раз повторю: в редакторе моделей ты это не посмотришь, так как эту анимацию думсдей рендерит сам, ибо она прописана в DED дефинициях, а редакторы моделей не умеют читать DED дефиниции
В принципе - да, понял. В Doomsday.ded - сначала указывается State Definition модели, то есть - то что относится к ваду Дума, определение люмпов спрайта, а вторая часть - это Model Definition модели - где уже указан путь к модели, и текстурам, фреймы анимации, фреймы модели.
Забыл еще сказать: State Definition в думсдей - это аналог decorate гздума. Model Definition в думсдей - это аналог modeldef гздума. Particle definition - это некий гибрид decorate/ACS и modeldef гздума.
Начнем по порядку:
1) State Definition.
Скрытый текст:
В гздуме это реализовано следующим образом: вот эти дефинишны уже прописаны в самой гоззе, но если ты хочешь что-то изменить - то ты в своем моде пишешь новый decorate код для твоих объектов.
В думсдее такой же принцип: все стандартные State Definition уже прописаны в файле objects.ded думсдей (этот файл ты можешь найти в Defs\jDoom\Objects.ded для 1.8.6 и data\jdoom\libdoom.pk3\defs\jdoom\objects.ded в 1.15.х), и только если они тебя чем-то не устраивают (например процесс смены оружия включает в себя 2 стейта, а ты хочешь чтобы 5) пишется новый state definition для конкретной модельки
Грубо говоря, то что в гздуме называется спрайтовым фреймом, в думсдее называется состоянием объекта (state). Т.е. в гздуме фреймы модели привязываются к фреймам спрайтов, а в думсдее фреймы модели привязываются к состояниям (стейтам) объекта
Зачастую наличие State Definition в думсдеевской ded-дефиниции для конкретной модели подразумевает, что при конвертации этой модели в гоззу придется педалить decorate код, чтобы "сымитировать думсдеевские состояния в гоззе", но в случае с твоей бочкой тебе видимо повезло, и все заработало без декорейта (я сейчас не про взрыв)
2) Model Definition.
Скрытый текст:
Здесь ты в думсдеевском ded должен находить следующее: путь к модели и имена файлов модели, Scale (если он есть), Offset (если он есть), имена фреймов (если они есть, а если нет, то просто использовать число ноль вместо фрейма)
Как я выше уже писал, в думсдее связываются состояния объекта с фреймами модели, а в гздуме спрайтовые фреймы с модельными фреймами, следовательно тебе надо понять логику связи состояний объекта с фреймами моделей в DED дефиниции думсдей, потом глянуть декорейт код объекта в гздуме (вот пример для бочки) и сообразить, каким образом надо связывать фреймы модели со спрайтовыми фреймами в гздуме (попробуй проделать этот абзац для бочки (без взрыва), чтобы убедиться, что ты понял как это делается )
Вот это самое сложное. Во-первых - я сам только частично в общих чертах разбираюсь, как это работает (т.е. мне понятно, какая цель закладывается в этот код и что примерно должно получиться на выходе, но если надо наоборот, когда процесс работы партиклов у меня в голове, а надо написать код, чтобы думсдей отрендерил то что у меня в голове, я так не смогу (для этого надо курить вики по думсдеевским генераторам партиклов, я пока не добрался до этого) ).
Во-вторых - синтаксис и принцип работы думсдеевского генератора частиц и гздумных методов реализации аналогичных процессов - отличаются кардинально. И далеко не всегда есть возможность повторения в гздуме того, что происходит в думсдее.
Соответственно, алгоритм копирования генераторов частиц (как например взрыва твоей бочки) из думсдей в гздум примерно следующий:
Скрытый текст:
Шаг 1: запускаем думсдей и смотрим, как это происходит там
Шаг 2: запускаем гздум и смотрим как это происходит в гздуме со спрайтами
Шаг 3: смотрим декорейт код гздума
Шаг 4: смотрим DED дефиницию в думсдей
Шаг 5: делим DED дефиницию в думсдей на составные части, и поочередно врубаем каждую из частей отдельно от остальных, чтобы примерно понять, какая часть за что отвечает
Шаг 6: теперь, с одной стороны, у нас в голове есть понимание, какой код в DED дефиниции думсдей что конкретно рендерит, а с другой, у нас собственно есть этот код думсдея
Шаг 7: теперь берем вот эти статьи с думсдеевской вики: http://tinyurl.com/gmebszu http://tinyurl.com/hp89qxm и пытаемся понять, по какой логике тот код, который мы наблюдаем в думсдеевской DED дефиниции, создает то, что мы наблюдаем на шаге 5
На самом деле шаг 8 тебе не обязательно сейчас читать, так как на начальных стадиях я тебе помогу (плюс я сам делал подобные вещи, т.е. примерно понимаю, как часть думсдеевских эффектов можно сымитировать в гздуме), но суть в том, что рано или поздно тебе все равно придется понять механизм работы гздумных скриптов и их возможности, а также, где задавать возникающие вопросы конкретно по гздумным скриптам, ибо за тебя твой код никто писать не захочет
Да, я понимаю, что слишком сложно, но другого варианта нет
aivar242:
Какой у тебя монитор? Хочу знать, под какое разрешение записывать.
BEXP A 5 Bright BEXP B 5 Bright A_Scream BEXP C 5 Bright BEXP D 5 Bright A_Explode BEXP E 10 Bright TNT1 A 1050 Bright A_BarrelDestroy TNT1 A 5 A_Respawn Wait } }
modeldef:
Скрытый текст:
Model ExplosiveBarrel_Model //Exploding Barrel(Doom) { Path "Models\Decor\T-Barrel" //!!! ТУТ ПИШЕШЬ КОРРЕКТНЫЙ ПУТЬ !!!
Model 0 "Barrel.dmd" Skin 0 "Barrel.png"
Model 1 "Barrel_Nukage.dmd" Skin 1 "Barrel_Nukage.png"
Scale 1.16 0.94 1.16
FrameIndex BAR1 AB 0 0 FrameIndex BAR1 AB 1 0 }
Model Barrel_Particle1 { Path "Models\Decor\T-Barrel\Particles" //!!! ТУТ ПИШЕШЬ КОРРЕКТНЫЙ ПУТЬ !!!
Model 0 "Barrel_Bit1.dmd" Skin 0 "Barrel_Bits.png"
BEXP A 5 Bright BEXP B 5 Bright A_Scream BEXP C 5 Bright BEXP D 5 Bright A_Explode BEXP E 10 Bright TNT1 A 1050 Bright A_BarrelDestroy TNT1 A 5 A_Respawn Wait } }
и тоже запиши видео взрыва бочек (modeldef код оставляй какой есть). И большая просьба: старайся делать на видео только то что касается контекста (т.е. показывай только бочки и их взрывы - не надо заходить в комнаты где нет бочек и показывать другие модели).
Если хочешь продемонстрировать все твои модели - то делай отдельный ролик "демонстрация всех моделей" и показывай их там
aivar242:
Честно говоря - улыбнуло, что ради всплеска из трёх осколков, надо было записать кучу кода.)
в думсдей 160 строк DED-кода посвящено спецэффектам взрыва бочки
С новым фичами гоззы можно попробовать сократить код Я не тестил т.к. лень, но должно работать по идее.. А если чего-то не будет работать, то можно по экспериментировать с тиками к примеру в стейте Death, может если там 1 надо вместо 0.. тут уже пока привыкнешь к новому
Скрытый текст:
ACTOR ExplosiveBarrel_Model: ExplosiveBarrel replaces ExplosiveBarrel
{
var int User_i;
States{
Spawn: BAR1 AB 6
Loop
Death: TNT1 A 0 {for (A_SetUserVar(user_i, 70); user_i > 0; A_SetUserVar(user_i, user_i - 10))
{A_SpawnItemEx("Barrel_Particle1", 0, 0, User_i, random[Barrel_Death](-128, 127)*0.03125, random[Barrel_Death](-128, 127)*0.03125,10+random[Barrel_Death](0, 255)*0.015625, 0, SXF_ABSOLUTEVELOCITY);}}
BEXP A 5 Bright
BEXP B 5 Bright A_Scream
BEXP C 5 Bright
BEXP D 5 Bright A_Explode
BEXP E 10 Bright
TNT1 A 1050 Bright A_BarrelDestroy
TNT1 A 5 A_Respawn
Wait
}}
ACTOR Barrel_Particle1: EttinMace
{
States{
Spawn: BAR1 A 1
Loop
Crash: BAR1 B -1 {A_SetAngle(random(0,359));A_SetPitch(random(0,358)-179);A_SetRoll(random(0,359));A_QueueCorpse;}
Stop
}}
ACTOR Barrel_Particle2: Barrel_Particle1
{
//
}
ACTOR Barrel_Particle3: Barrel_Particle1
{
//
}
Это из старого ) Новый спойлер не увидел сразу что-то.. тут в скрипте уменьшается на 10 высота спавна..
Да и мне не понятно что это > random[Barrel_Death](0, 255)? Откуда тут Barrel_Death?
Добавлено спустя 7 минут 47 секунд:
Если строки идентичны то проще использовать цикл, так и редактировать проще. Но вот не знаю нужен там 1 тик или 0 прокатит, надо пробовать
var int User_i;
Death:
TNT1 A 0 {for (A_SetUserVar(user_i, 0); user_i < 12; A_SetUserVar(user_i, user_i - 1)){
A_SpawnItemEx("Barrel_Particle1", 0, 0, 5, random[Barrel_Death](-128, 127)*0.03125, random[Barrel_Death](-128, 127)*0.03125,
10+random[Barrel_Death](0, 255)*0.015625, 0, SXF_ABSOLUTEVELOCITY); }}
1) Там разные акторы участвуют: Barrel_Particle1, Barrel_Particle2 и Barrel_Particle3, посмотри код внимательно 2) В 2.1.1 такое еще не сработает, верно? 3) Но все равно спасибо за идею
alekv:
Да и мне не понятно что это > random[Barrel_Death](0, 255)? Откуда тут Barrel_Death?
Посмотри как тут юзается random при spawnitemex. Насколько я понял, это нужно для того, чтобы рандом для текущего актора (партиклы бочки в нашем случае) не влиял на другие рандомы (например рандом выстрела бфж), и наоборот, чтобы другие рандомы не влияли на целевой
alekv:
С новым фичами гоззы можно попробовать сократить код
aivar242 - несмотря на то, что alekv прав, пока не обращай внимания на его код, так как он во-первых с вероятностью 99% не будет работать в 2.1.1, а во-вторых, alekv проморгал важные нюансы. Так что пока пробуй только мой код (выложишь видео с моим кодом)
alekv:
Если строки идентичны то проще использовать цикл, так и редактировать проще. Но вот не знаю нужен там 1 тик или 0 прокатит, надо пробовать
и да, я в курсе, что проще использовать цикл (даже тот цикл, который работает в 2.1.1), просто мы сейчас не на той стадии, чтобы об этом париться
alekv:
Если строки идентичны
нет, там разные акторы спавнятся
alekv:
Но вот не знаю нужен там 1 тик или 0 прокатит, надо пробовать
с 1 тиком точно не вариант, нужно чтобы спавн был в момент взрыва, и спрайт не мигал
По поводу взрыва хотел сказать, что мне Думсдеевский, зелёный хлопок, в принципе не нравится. Он не по Думовски взрывается. По Думовски, это огненное облако, как на спрайте, как в боевиках. Так и надо его делать, только в 3D.
Кстати - как в Doomsday 1.8.6 прыгать по уровням? Через консоль можно?
Кстати - как в Doomsday 1.8.6 прыгать по уровням? Через консоль можно?
чит кодом idclevXX где XX номер уровня
aivar242:
Програсс заметен
теперь попробуй так (меняешь decorate код на новый):
Скрытый текст:
ACTOR Barrel_Particle { States { Spawn: TNT1 A 0 TNT1 A 0 A_Jump(256, "Spawn1", "Spawn2", "Spawn3") Spawn1: TNT1 A 0 A_SpawnItemEx("Barrel_Particle1") Stop Spawn2: TNT1 A 0 A_SpawnItemEx("Barrel_Particle2") Stop Spawn3: TNT1 A 0 A_SpawnItemEx("Barrel_Particle3") Stop } }
ACTOR Barrel_Particle1: EttinMace {
States { Spawn: BAR1 A 1 Loop Crash: TNT1 A 0 A_SetAngle( random(0,359) ) TNT1 A 0 A_SetPitch( random(0,358) - 179 ) TNT1 A 0 A_SetRoll( random(0,359) ) BAR1 B 1 A_QueueCorpse BAR1 B -1 Stop } }
ACTOR Barrel_Particle2: Barrel_Particle1 { // }
ACTOR Barrel_Particle3: Barrel_Particle1 { // }
ACTOR ExplosiveBarrel_Model: ExplosiveBarrel replaces ExplosiveBarrel {
Var Int User_I; Var Int User_J;
States { Spawn: BAR1 AB 6 Loop Death: BEXP A 5 Bright BEXP B 5 Bright A_Scream BEXP C 5 Bright BEXP D 5 Bright A_Explode
TNT1 A 0 A_SetUserVar("User_J", random(1, 30) ) TNT1 A 0 A_SetUserVar("User_I", 1 ) 001___FOR_I_from_1_to_J: TNT1 A 0 A_SpawnItemEx("Barrel_Particle", 0, 0, 5, random[Barrel_Death](-128, 127)*0.03125*2, random[Barrel_Death](-128, 127)*0.03125*2, random[Barrel_Death](0, 255)*0.015625, 0, SXF_ABSOLUTEVELOCITY) TNT1 A 0 A_SetUserVar("User_I", User_I+1 ) TNT1 A 0 A_JumpIf(User_I < User_J+1, "001___FOR_I_from_1_to_J")
BEXP E 10 Bright TNT1 A 1050 Bright A_BarrelDestroy TNT1 A 5 A_Respawn Wait } }
а в modeldef коде увеличь размер (Scale) каждого Barrel_Particle1/2/3 в 2 раза
и тоже выкладываешь видео с бочками, в том числе и на мап23, причем на мап23 покажи так, чтобы на экран попали все бочки, т.е. ты стоишь в начале уровня, и смотришь вдоль всего коридора, где вдали виднеется дверь, за которой есть телепорт в другую комнату (перед взрывом бочек вводи код на бессмертие, так как твоя смерть и красный экран портят мне всю полезность видео)
Да, при выходе из игры, Гозза зависла на экране выхода, с окном посередине. Закрыл через диспетчер задач.
Второй видос не писал, потому что муторно довольно переключаться между ВАДами в Гоззе. Это надо переключиться с одного на другой, потом запустить его, потом выйти, потом запустить BATик того Дума. Можно конечно сделать нужный BATник для этого, но я не знаю что в нём писать, чтобы запустился сразу Дум2 с левелом 23.
Да, попробовал оба кода - действие одинаковое, то есть как и было - осколки опадают в кучку. Пока лучший всего выглядит 2-ой способ, с насыщенным разлётом осколков. Но в Doomsday, они разлетаются как бы без траектории падения, не фонтанчиком, а просто в стороны, что более реально я считаю.
Хотя и первый способ тоже катит, так как в момент взрыва не столь важны осколки от бочки, сколько качество самого взрыва и переизбыток осколков может даже испортить картину в целом, заслоняя собой сам взрыв, при взрыве.
Если все работает как надо (включая отсутствие зависания гздума после выхода из игры), говори любые свои претензии к тому, как оно происходит и чего не хватает (или наоборот, что лишнее). Если осколков слишком мало/много, это тоже изменяемо
aivar242:
Но в Doomsday, они разлетаются как бы без траектории падения, не фонтанчиком, а просто в стороны, что более реально я считаю
я сейчас сделал этот момент по рандому, оно то вбок то вверх то вбок и вверх одновременно
aivar242:
Хотя и первый способ тоже катит, так как в момент взрыва не столь важны осколки от бочки, сколько качество самого взрыва и переизбыток осколков может даже испортить картину в целом, заслоняя собой сам взрыв, при взрыве.
в общем посмотри сейчас очень внимательно, проверь раз 50 (так как там рандом и по разлету и по количеству осколков), и если что-то не будет устраивать, то записывай видео, и отписывай тайминги в стиле "0:05 видео, вот там слишком много осколков, я бы уменьшил в 2 раза, 0:25 видео, здесь все норм, 0:55 видео, а тут не хватает того-то"