Не плохо было бы. Ещё лучше, если бы можно было на клавишу повесить переключение между спрайтом и моделью, когда они поглощают друг друга. Был бы виден предел размеров спрайта, чтобы не выходить далеко за его границы.
Итак, первый шаг будет простой: ты качаешь мой гздум полностью, пускаешь батник и пробуешь, устраивает ли тебя то что есть. Если устроит, тогда буду рассказывать, как это дело подрубить тебе в порт (чтобы юзал не мою, а свою гоззу) и как это сделать для остальных твоих моделей (это, к слову, самое сложное будет)
Если хочешь другую кнопку вместо O, то пишешь в консоли: bind КНОПКА "summon aivar242_toggle" (например bind U "summon aivar242_toggle" или bind kp_5 "summon aivar242_toggle" )
Это первый шаг. Если такое поведение не устраивает, пиши, почему, будем исправлять. Если же такое поведение устраивает, тогда пробуем то же самое, но уже на твоей гоззе:
В общем всё работает с твоими файлами в архиве. Когда я попытался в авхив MODELS_TEST.pk3 вставить свои модели с своим файлом Modeldef, то при нахождении возле того же Green Armor и нажатии клавиши O на клавиатуре, порт пишет "Unknown class aivar_toggle". Я так понял, что возможно всё дело в файле DECORATE, который в архиве? Как мне сделать, чтобы я мог закидывать свои 3D модели в этот архив, со своим путём к моделям и чтобы всё работало? Желательно чтобы при нажатии клавиши O, все модели на левеле переключались в спрайты и обратно в модели. Можно так сделать?
Да, но как я и говорил, это самое сложное и для этого понадобится 6-7 комментариев
aivar242:
Я так понял, что возможно всё дело в файле DECORATE, который в архиве?
Да, дело в нем, но этот файл тебе придется модифицировать самому (а также дефиниции моделей временно модифицировать), чтобы для твоих моделей был тот же эффект, и собственно это мы сейчас и начнем обсуждать. Поехали:
Скрытый текст:
1) Файл MODELS_TEST.pk3 где-нибудь оставь себе (он все еще доступен по ссылке в прошлых каментах, но оставь его себе где-нибудь). Данный файл - живой пример, как надо модифицировать (в данном случае "создать", но не суть) файл decorate и сами дефиниции моделей, чтобы конкретно зеленая и синяя броня начали себя вести как тебе нужно. В случае проблем с будущими моделями, возможно тебе придется обратиться к этому паку, чтобы глянуть на работающий пример таких модификаций
С этим ясно, едем дальше
2) Теперь собственно про Decorate: decorate - это способ описания логики акторов (актор - это внутриигровой объект, например предмет инвентаря, оружие, монстр, патрон, факел и т д, в современных играх такое называют ассетами) в здуме и гздуме. Этим способом описаны как уже существующие акторы, так и те, которые создают моддеры (например если я хочу добавить в игру огнемет, то мне придется создать такой актор в декорейте и описать внутри него поведение выстрела огнем)
Соответственно, если я хочу изменить уже существующие акторы (например сделать, чтобы броня реагировала на мои нажатия клавиш, и становилась то моделью то спрайтом), то это тоже делается через декорейт
3) Что такое decorate, выяснили. Теперь самое интересное (и самое сложное/длинное): надо понять основной принцип работы decorate, и как с ним работать. Поэтому, для начала, я приведу пример декорейтовского описания зеленой брони, расписав, что какая строчка в нем значит.
Чтобы такое описание узнать, есть 2 способа: 1) найти это внутри gzdoom.pk3 2) найти это на zdoom wiki
Я обычно пользуюсь вторым. Чтобы найти на zdoom wiki описание зеленой брони, мы:
ACTOR GreenArmor : BasicArmorPickup { Radius 20 Height 16 Inventory.PickupMessage "$GOTARMOR" // "Picked up the armor." Inventory.Icon "ARM1A0" Armor.SavePercent 33.335 Armor.SaveAmount 100 States { Spawn: ARM1 A 6 ARM1 B 7 Bright Loop } }
Распишу построчно что там что значит/делает:
Скрытый текст:
ACTOR GreenArmor : BasicArmorPickup эта строка говорит нам о том, что мы создаем нового актора "зеленая броня (GreenArmor)" на базе уже существующего актора "базовый актор для брони (BasicArmorPickup)". Как выглядит базовый актор для брони, можно глянуть здесь: http://zdoom.org/wiki/Classes:BasicArmorPickup
Radius 20 Height 16 Inventory.PickupMessage "$GOTARMOR" // "Picked up the armor." Inventory.Icon "ARM1A0" Armor.SavePercent 33.335 Armor.SaveAmount 100
эти строки описывают параметры объекта, я не буду сейчас рассказывать подробно, скажу лишь, что для конкретно твоего случая они в 99% случаев не нужны, поэтому пока игнорируй их
States { Spawn: ARM1 A 6 ARM1 B 7 Bright Loop }
а вот это самое интересное. Блок states описывает состояния актора. Пройдемся конкретно по каждому:
Spawn:
это состояние, в которое переходит актор, когда либо спавнится на уровне, либо его призывают командой summon в консоли. Вот например ты стартуешь первый уровень в думе, в нем сразу спавнятся все предметы и оружия, валяющиеся на полу, монстры, элементы декора и игрок. Соответственно, все эти объекты переходят в состояние Spawn
ARM1 A 6 ARM1 B 7 Bright
для начала давай разберемся, что такое ARM1 A и ARM1 B. Открываем в slade файл doom2.wad и находим там ARM1, примерно так:
Скрытый текст:
Т.е. мы видим, что ARM1 A - это спрайт зеленой брони
теперь давай глянем следующий за ним ARM1 B:
Скрытый текст:
Как видишь, тот же самый ARM1 A, только более темный вариант. Если вспомнишь, то спрайт брони в думе мигает туда-сюда, соответственно ARM1 - это спрайт зеленой брони, а A и B - это 2 его фрейма, которые периодически мигают туда-сюда
Теперь вернемся к нашему коду состояний:
ARM1 A 6 ARM1 B 7 Bright
эти 2 строки значат, что сначала 6 тиков (35тиков это 1 секунда) показывается фрейм A спрайта ARM1, а потом 7 тиков показывается фрейм B спрайта ARM1 в режиме "яркий (Bright)"
после этого в коде идет строка:
Loop
это значит, что стейт Spawn (ну так как строка Loop идет конкретно в стейте Spawn в нашем примере) будет зациклен. Т.е. покажется 6 тиков фрейм А, потом 7 тиков фрейм B, и потом заново покажется 6 тиков фрейм А, потом 7 тиков фрейм B и так до бесконечности
Соответственно, когда ты играешь в дум и видишь броню на полу, она будет мигать до тех пор, пока ее кто-то не подберет
Для начала этого хватит, отпиши, что непонятно, потому как дальше мы будем рассматривать, как это дело модифицировать, чтобы броня реагировала на наши нажатия кнопок строго так, как нам надо
Пока всё понятно. Можно продолжать. Насколько я усвоил урок - DECORATE - это состояние акторов (вещей, предметов, монстров) в запущенной игре. Параметры в основном для всех спрайтов в игре.
Надо было это в предыдущем каменте отписать, но лучше позже чем никогда. Планы будут такие:
Скрытый текст:
Шаг 1: Краткое введение в Decorate Шаг 2: Объяснение, как сделать простейшую модификацию зеленой брони, чтобы она сама переключалась то на модель то на спрайт (пока без нажатия кнопки) Шаг 3: Ты пытаешься повторить шаг 2 (пока на той же зеленой броне) Шаг 4: Ты пытаешься повторить шаг 2 (на синей броне) Шаг 5: Объяснение, как сделать шаг 2 на другой модельке Шаг 6: Ты пытаешься повторить шаг 5 (на любой модельке) Шаг 7: Объяснение, как к этому всему прикрутить, чтобы модель менялась на спрайт (или наоборот) - не сама, а только по нажатию кнопки Шаг 8: Ты пытаешься повторить шаг 7 (на любой модельке)
Первый шаг я уже сделал в предыдущем каменте, а в текущем мы проделаем шаги 2 и 3. Поехали:
Скрытый текст:
Значит у нас есть декорейт код зеленой брони:
Скрытый текст:
ACTOR GreenArmor : BasicArmorPickup { Radius 20 Height 16 Inventory.PickupMessage "$GOTARMOR" // "Picked up the armor." Inventory.Icon "ARM1A0" Armor.SavePercent 33.335 Armor.SaveAmount 100 States { Spawn: ARM1 A 6 ARM1 B 7 Bright Loop } }
Мы берем, и создаем файл DECORATE в своем паке моделей (т.е. ты берешь свой пак моделей, и создаешь там файл DECORATE (просто имя, без расширения) ) и пишем там:
Скрытый текст:
ACTOR GreenArmor : BasicArmorPickup { Radius 20 Height 16 Inventory.PickupMessage "$GOTARMOR" // "Picked up the armor." Inventory.Icon "ARM1A0" Armor.SavePercent 33.335 Armor.SaveAmount 100 States { Spawn: ARM1 A 6 ARM1 B 7 Bright Loop } }
а теперь будем менять этот код как нам надо. Распишу построчно:
Скрытый текст:
ACTOR GreenArmor : BasicArmorPickup
эту строку мы заменяем на следующую: ACTOR GreenArmor_Model : GreenArmor
т.е. мы создаем нового актора GreenArmor_Model на базе уже существующего актора GreenArmor
но есть одна загвоздка: наш актор просто будет создан "в воздухе", т.е. гздум будет знать, что такой актор есть, но в игре он сам по себе не появится. Чтобы исправить это досадное недоразумение, изменим нашу строку вот так:
ACTOR GreenArmor_Model : GreenArmor replaces GreenArmor
вот теперь вся стандартная зеленая броня в думе (тобишь GreenArmor) будет автоматом заменяться на нашу переделанную зеленую броню (тобишь GreenArmor_Model)
С этим понятно, идем дальше:
Radius 20 Height 16 Inventory.PickupMessage "$GOTARMOR" // "Picked up the armor." Inventory.Icon "ARM1A0" Armor.SavePercent 33.335 Armor.SaveAmount 100
это все мы тупо удаляем. Чтобы ты понимал на будущее, когда ты в декорейте создаешь актор А на базе актора Б, то все состояния и свойства актора Б автоматом копируются тебе в актор А. Т.е. например параметр "Radius 20" уже скопирован в наш актор GreenArmor_Model уже на стадии строки "ACTOR GreenArmor_Model : GreenArmor", соответственно все эти 6 строчек
Radius 20 Height 16 Inventory.PickupMessage "$GOTARMOR" // "Picked up the armor." Inventory.Icon "ARM1A0" Armor.SavePercent 33.335 Armor.SaveAmount 100
мы просто удаляем, так как они уже "активированы" (а менять мы их не собираемся).
На будущее я буду предполагать, что этот нюанс тебе понятен, соответственно если в будущем я буду говорить "вот эти строки или состояния мы удаляем", то буду иметь в виду, что "они уже унаследованы из предыдущего класса (GreenArmor в данном случае)" (ну кроме отдельных случаев, когда я явно буду указывать обратное).
дальше идем:
States { Spawn: ARM1 A 6 ARM1 B 7 Bright Loop }
так как мы хотим изменить состояние Spawn, то эти строки мы оставляем, но будем редактировать. Значит сейчас у нас 6 тиков показывается фрейм А спрайта ARM1 и 7 тиков показывается фрейм Б спрайта ARM1.
Мы хотим сделать, чтобы после спрайта ARM1 показывалась модель (столько же тиков). Код будет выглядеть вот так:
States { Spawn: ARM1 A 6 ARM1 B 7 Bright ARM1 C 6 ARM1 D 7 Bright Loop }
ты скорее всего спросишь: а что это за фреймы C и D, ведь в slade их нет? Все верно, в slade их нет, но так как мы хотим отображать модель, причем чтобы модель переключалась на спрайт и обратно, то нас как раз устроят такие "свободные фреймы", которые не заняты спрайтами в slade
остается последний вопрос: каким образом гозза сообразит, что на стадии ARM1 C 6 ARM1 D 7 Bright надо именно модель отображать?
Очень простым: идем в modeldef нашей зеленой брони. Изначально там был такой код:
Скрытый текст:
Model greenArmor { Path "Models\Items\Armour" Model 0 "arm1.md2" Skin 0 "arm1.png" Scale 1.0 1.0 1.0
FrameIndex ARM1 A 0 0 FrameIndex ARM1 b 0 0 }
мы его меняем на такой:
Скрытый текст:
Model greenArmor_Model { Path "Models\Items\Armour" Model 0 "arm1.md2" Skin 0 "arm1.png" Scale 1.0 1.0 1.0
FrameIndex ARM1 C 0 0 FrameIndex ARM1 D 0 0 }
т.е. строку Model greenArmor
мы меняем на Model greenArmor_Model (это надо потому, что вместо стандартного актора GreenArmor у нас теперь будет измененный актор GreenArmor_Model, ведь мы его переопределили в декорейте)
а строки FrameIndex ARM1 A 0 0 FrameIndex ARM1 B 0 0
мы меняем на
FrameIndex ARM1 C 0 0 FrameIndex ARM1 D 0 0
теперь гозза знает, что на фреймах A и B надо отображать спрайт, а на фреймах C и D - модель
напомню, код фреймов в декорейте у нас следующий:
Spawn: ARM1 A 6 ARM1 B 7 Bright ARM1 C 6 ARM1 D 7 Bright Loop
теперь давай я отпишу, какой у нас должен получится результирующий код в decorate:
Скрытый текст:
ACTOR GreenArmor_Model : GreenArmor replaces GreenArmor { States { Spawn: ARM1 A 6 ARM1 B 7 Bright ARM1 C 6 ARM1 D 7 Bright Loop } }
впиши это себе в DECORATE, потом отредактируй modeldef для зеленой брони, чтобы там было вот так:
Скрытый текст:
Model greenArmor_Model { Path "Models\Items\Armour" Model 0 "arm1.md2" Skin 0 "arm1.png" Scale 1.0 1.0 1.0
FrameIndex ARM1 C 0 0 FrameIndex ARM1 D 0 0 }
после этого запусти гоззу с подключением этого пака, и зеленая броня должна будет отображаться пол секунды спрайтом, пол секунды моделью
Теперь, попробуй весь этот комментарий проделать сам, чтобы результат у тебя работал (работал в стиле "зеленая броня отображается пол секунды спрайтом, пол секунды моделью") и ты понимал, какие изменения ты внес и для чего.
Если получится, то повтори все то же самое для синей брони
Если что-то непонятно или понятно, но не работает, отписывай. Если все работает и понятно, тогда продолжим дальше
Попробовал, всё работает. Осталось толкьо понять, как кнопку назначить.
theleo_ua:
ты скорее всего спросишь: а что это за фреймы C и D, ведь в slade их нет? Все верно, в slade их нет, но так как мы хотим отображать модель, причем чтобы модель переключалась на спрайт и обратно, то нас как раз устроят такие "свободные фреймы", которые не заняты спрайтами в slade
Какой slade ты имеешь ввиду?
Зная Декорейт и всё остальное, напрашивается вопрос - а почему ты сам не перегнал модельки из других портов в Гоззу, ведь они многим нужны в этом порте? Лично я только недавно подсел на этот порт, ввиду потери фаворита в лице Doomsday. (Не смог заставить 1.8.6 версию показывать адекватную картинку в 16:9, и медленная работа новых версий порта). Сразу захотелось увидеть думсдеевские модельки в Гоззе.
Скрытый текст:
Гозза в этом смысле преуспела. Очень быстра даже с включенным вСинком. Включение вСИнк в последних Doomsday - смерти подобно. Может там мощное железо чуть и спасает ситуацию, но на слабом всё очень не шустро. Можно только представить, как Гозза будет работать на том же мощном железе.
Тогда едем дальше: теперь попробуем аналогичным образом сделать коробку пуль:
Скрытый текст:
Находим ее код на здум вики:
Скрытый текст:
ACTOR ClipBox : Clip { Inventory.PickupMessage "$GOTCLIPBOX" // "Picked up a box of bullets." Inventory.Amount 50 States { Spawn: AMMO A -1 Stop } }
Мы видим, что здесь новая, доселе нам не известная структура состояния Spawn. Поясню:
Stop обычно значит что актор заканчивает свою работу и самоликвидируется. Но если перед Stop у нас идет строка, которая длится "минус один тик", в таком случае при состоянии Stop актор как бы ставится на паузу, и теперь будет бесконечно отображать тот спрайт/фрейм, на котором был "минус один тик". Обычно такое используют на трупах, но как видишь, не только на трупах, а иногда и на предметах.
В нашем текущем случае такой расклад нас не устраивает, так как циклическое поведение "то модель то спрайт" мы не сможем реализовать в рамках одного актора с состоянием Stop. Поэтому мы поменяем этого актора вот так:
Скрытый текст:
ACTOR ClipBox_Model : ClipBox replaces ClipBox { States { Spawn: AMMO A 1 Loop } }
теперь актор готов к нашей обработке, поэтому добавим ему фрейм модели:
Скрытый текст:
ACTOR ClipBox_Model : ClipBox replaces ClipBox { States { Spawn: AMMO A 1 AMMO B 1 Loop } }
но такой актор будет очень быстро мигать, поэтому давай замедлим в 35 раз:
Скрытый текст:
ACTOR ClipBox_Model : ClipBox replaces ClipBox { States { Spawn: AMMO A 35 AMMO B 35 Loop } }
вот теперь актор должен секунду показывать спрайт и секунду модель. Осталось лишь modeldef подредактировать - делаем по аналогии с зеленой броней:
Model ClipBox меняем на Model ClipBox_Model
а FrameIndex AMMO A 0 0 меняем на FrameIndex AMMO B 0 0
вот теперь коробка пуль должна мигать "то спрайт то модель" по аналогии с зеленой броней
Повтори вышеописанный спойлер с коробкой пуль, а после этого возьми любую модель (кроме зеленой/синей брони и коробки пуль) и попробуй с ней тоже проделать такой же трюк, чтобы после этого она мигала в стиле "то спрайт то модель"
Если все окей, давай теперь рассмотрим, как прикручивается нажатие по кнопке:
Скрытый текст:
Есть как минимум 2 способа это сделать:
1) Один актор, много состояний (такой способ используется в models_test.pk3 который я тебе кидал выше. Достоинство способа - в некоторых случаях бывает так, когда надо чтобы актор был один) 2) Два актора, одно состояние (достоинство способа - его проще как использовать, так и объяснить как работает. Также одно из достоинств способа - не надо париться о "свободных фреймах C и D", т.е. фреймы в моделдефе остаются такие как и были (в нашем случае с зеленой броней - A и B))
Соответственно, я тебе буду объяснять на примере способа 2, а ты потом ради интереса глянешь в models_test.pk3 и посмотришь, как там реализован способ 1
Значит будет примерно так:
Шаг 1: сначала рассмотрим, как реализовать, чтобы 2 актора адекватно взаимодействовали друг с другом (пока без кнопки) Шаг 2: потом рассмотрим, как в шаге 1 прикрутить кнопку
Поехали - взаимодействие акторов:
Скрытый текст:
Вернемся к нашей любимой зеленой броне - вот какой код у нас был:
Скрытый текст:
ACTOR GreenArmor_Model : GreenArmor replaces GreenArmor { States { Spawn: ARM1 A 6 ARM1 B 7 Bright ARM1 C 6 ARM1 D 7 Bright Loop } }
теперь давай рассмотрим вот такой код:
Скрытый текст:
//SPRITE ACTOR GreenArmor_Sprite : GreenArmor replaces GreenArmor { States { Spawn: ARM1 A 6 ARM1 B 7 Bright ARM1 B 0 A_SpawnItemEx("GreenArmor_Model") Stop }//States }//ACTOR GreenArmor_Sprite : GreenArmor replaces GreenArmor
//MODEL ACTOR GreenArmor_Model : GreenArmor { States { Spawn: ARM1 A 6 ARM1 B 7 Bright ARM1 B 0 A_SpawnItemEx("GreenArmor_Sprite") Stop }//States }//ACTOR GreenArmor_Model : GreenArmor
Если вкратце, то механизм работы следующий: сначала на уровне спавнится спрайтовая версия брони (актор GreenArmor_Sprite), в рамках данного актора 13 тиков отображаются спрайтовые фреймы, потом актор самоликвидируется (исчезает) и спавнит на своем месте другой актор - модельную версию брони (актор GreenArmor_Model), которая по такой же схеме, сначала 13 тиков отображает модельные фреймы, а потом самоликвидируется и спавнит на своем месте спрайтовый актор GreenArmor_Sprite, и так до бесконечности
Давай построчно рассмотрим ключевые нюансы:
ACTOR GreenArmor_Sprite : GreenArmor replaces GreenArmor { } ACTOR GreenArmor_Model : GreenArmor { }
как ты видишь, у нас есть 2 актора, каждый из которых унаследован с актора обычной зеленой брони GreenArmor. Причем replaces используется только для одного из них (ведь достаточно переопределить только один актор зеленой брони, а дальше, когда он уже отспавнился на уровне, можно делать что угодно (в нашем случае - циклически ликвидировать текущий актор и спавнить следующий))
ARM1 B 0 A_SpawnItemEx("GreenArmor_Model")
данная строчка делает следующее: она спавнит на своем месте (тобишь "внутри себя") актор GreenArmor_Model, тобишь модель зеленой брони
Stop
Данная строка самоликвидирует текущий актор, т.е. актор после этого исчезает
Теперь еще раз посмотри на результирующий код декорейта, и убедись, что понимаешь, что там и зачем:
Скрытый текст:
//SPRITE ACTOR GreenArmor_Sprite : GreenArmor replaces GreenArmor { States { Spawn: ARM1 A 6 ARM1 B 7 Bright ARM1 B 0 A_SpawnItemEx("GreenArmor_Model") Stop }//States }//ACTOR GreenArmor_Sprite : GreenArmor replaces GreenArmor
//MODEL ACTOR GreenArmor_Model : GreenArmor { States { Spawn: ARM1 A 6 ARM1 B 7 Bright ARM1 B 0 A_SpawnItemEx("GreenArmor_Sprite") Stop }//States }//ACTOR GreenArmor_Model : GreenArmor
теперь заходим в моделдеф дефиницию зеленой брони - она выглядела так:
Скрытый текст:
Model greenArmor { Path "Models\Items\Armour" Model 0 "arm1.md2" Skin 0 "arm1.png" Scale 1.0 1.0 1.0
FrameIndex ARM1 A 0 0 FrameIndex ARM1 b 0 0 }
а мы ее меняем вот так:
Скрытый текст:
Model greenArmor_Model { Path "Models\Items\Armour" Model 0 "arm1.md2" Skin 0 "arm1.png" Scale 1.0 1.0 1.0
FrameIndex ARM1 A 0 0 FrameIndex ARM1 b 0 0 }
т.е. строку Model greenArmor меняем на Model greenArmor_Model
но фреймы A и B оставляем как есть. Скорее всего у тебя возникнет вопрос, а как гозза знает, что на одних и тех же фреймах A и B надо то модель отображать, то спрайт? А очень просто: в декорейте у тебя 2 актора:
ACTOR GreenArmor_Sprite ACTOR GreenArmor_Model
а в моделдефе у тебя прописана дефиниция только для GreenArmor_Model: Model greenArmor_Model
соответственно, раз для актора GreenArmor_Sprite модел-дефиниции нет, он будет отображаться спрайтом
Повтори вышеописанный спойлер с зеленой броней, потом с синей броней, и потом с коробкой пуль. Если все окей (т.е. мигают в стиле "то спрайт то модель"), идем дальше:
начинаем прикручивать кнопку:
Скрытый текст:
для начала расскажу идею. В здуме и гздуме есть такое понятие предмет. Это не обязательно видимый предмет, который валяется на полу (как например зеленая броня), а может быть просто невидимым предметом, который ничего не делает, никакого профита в виде "+100 брони" не дает и т д. Но у такого предмета будет 4 достоинства:
1) его может дать кто угодно (например игрок) 2) его может получить кто угодно (например зеленая броня). Да, в здуме и гздуме предметы может "собирать" даже броня 3) в декорейте можно проверить наличие такого предмета у тебя "в кармане" 4) передачу такого предмета можно забиндить на кнопку клавиатуры
Скорее всего ты уже понял, в чем заключается идея с прикручиванием кнопки, но на всякий случай распишу:
1) Сначала зеленая броня спавнится, и отображает спрайтовые фреймы, периодически проверяя "а нет ли у нее предмета под названием aivar242_item?" 2) потом игрок подходит к этой броне, и нажимает кнопку O 3) так как у игрока на кнопку O забинден призыв актора aivar242_toggle, соответственно рядом с игроком спавнится невидимый актор aivar242_toggle 4) актор aivar242_toggle передает всем объектам (например зеленой броне) в радиусе действия предмет aivar242_item, после чего самоликвидируется 5) Вспоминаем шаг 1: зеленая броня периодически проверяет "а нет ли у нее предмета под названием aivar242_item?", как вдруг такой предмет у нее появляется 6) раз предмет у нее появился, она самоликвидируется, и спавнит на своем месте актор "модель зеленой брони" 7) теперь происходят те же самые шаги 1-6, но уже для модельного актора вместо спрайтового 8) и так до бесконечности
Идея надеюсь понятна (если непонятна, пиши что конкретно непонятно), осталось расписать, как ее реализовать. Значит здесь следует указать ключевой момент: код декорейта у нас будет разбит на 2 логические части:
1) код описания предметов aivar242_item и aivar242_toggle 2) код, где ты переопределяешь сами "модели" (например код зеленой брони, синей брони, коробки пуль, синей бутылки и т д)
И суть в том, что код описания предметов aivar242_item и aivar242_toggle у нас в декорейте будет только 1 раз. Соответственно, когда ты скопипастишь себе в декорейт этот код, смотри чтобы ты его не скопипастил туда несколько раз, иначе могут глюки возникнуть.
Следовательно, когда ты в свой декорейт будешь добавлять новые модели (например модель бфж), то добавлять в этот декорейт ты будешь только код самого бфж, но никак не aivar242_item/aivar242_toggle, ибо aivar242_item и aivar242_toggle у тебя в декорейте уже есть.
С этим понятно, теперь собственно код декорейта и пояснения. Сначала код aivar242_item и aivar242_toggle:
Скрытый текст:
//-------------------------------------------------------------- //ACTOR FOR KEY BINDING
ACTOR Aivar242_Toggle { States { Spawn: TNT1 A 0 TNT1 A 0 A_RadiusGive("Aivar242_Item", 2000, RGF_ITEMS | RGF_OBJECTS, 1) Stop }//States }//ACTOR Aivar242_Toggle
//ITEM FOR RADIUSGIVE ACTOR Aivar242_Item : Inventory { Inventory.MaxAmount 1
States { Spawn: TNT1 A -1 Stop }//States }//ACTOR Aivar242_Item : Inventory //--------------------------------------------------------------
можешь не вникать "какая строчка что там делает", просто скопипасти это себе в начало декорейта и всё. Только не забудь, что чтобы кнопка работала, надо ее забиндить, тобишь прописать себе в autoexec.cfg (или в консоли) следующее:
bind o "summon aivar242_toggle"
С этим понятно, теперь осталось самое важное - код собственно для зеленой брони:
Скрытый текст:
//SPRITE ACTOR GreenArmor_Sprite : GreenArmor replaces GreenArmor { States { Spawn: ARM1 A 6 ARM1 B 7 Bright ARM1 B 0 A_JumpIfInventory("Aivar242_Item", 1, 2) ARM1 B 0 A_Jump(256, "Spawn") ARM1 B 0 A_SpawnItemEx("GreenArmor_Model") Stop }//States }//ACTOR GreenArmor_Sprite : GreenArmor replaces GreenArmor
//MODEL ACTOR GreenArmor_Model : GreenArmor { States { Spawn: ARM1 A 6 ARM1 B 7 Bright ARM1 B 0 A_JumpIfInventory("Aivar242_Item", 1, 2) ARM1 B 0 A_Jump(256, "Spawn") ARM1 B 0 A_SpawnItemEx("GreenArmor_Sprite") Stop }//States }//ACTOR GreenArmor_Model : GreenArmor
он почти не отличается от того, что мы рассматривали выше (когда броня сама мигала то срайтом то моделью), за исключением двух строчек. Рассмотрим их:
ARM1 B 0 A_JumpIfInventory("Aivar242_Item", 1, 2) эта строка проверяет, есть ли у данного актора предмет Aivar242_Item. Если он есть, то следующая строка ARM1 B 0 A_Jump(256, "Spawn") пропускается, а если предмета нет, то следующая строка ARM1 B 0 A_Jump(256, "Spawn") выполняется
ARM1 B 0 A_Jump(256, "Spawn") эта строка принудительно начинает выполнять состояние Spawn с самого начала, т.е. строка ARM1 B 0 A_SpawnItemEx("GreenArmor_Sprite") проигнорируется в данном случае
Stop это понятно: самоликвидация (исчезание) актора
распишу на примере, как будут выполняться строки в случае если предмета Aivar242_Item нет (т.е. игрок не нажал кнопку O) и в случае если предмет Aivar242_Item есть (т.е. игрок нажал кнопку O)
Если игрок не нажимает кнопку O, то строки кода у нас будут выполняться в такой последовательности:
Скрытый текст:
ARM1 A 6 ARM1 B 7 Bright ARM1 B 0 A_JumpIfInventory("Aivar242_Item", 1, 2) ARM1 B 0 A_Jump(256, "Spawn") ARM1 A 6 ARM1 B 7 Bright ARM1 B 0 A_JumpIfInventory("Aivar242_Item", 1, 2) ARM1 B 0 A_Jump(256, "Spawn") ARM1 A 6 ARM1 B 7 Bright ARM1 B 0 A_JumpIfInventory("Aivar242_Item", 1, 2) ARM1 B 0 A_Jump(256, "Spawn")
и так до бесконечности. Теперь давай рассмотрим, как будет в случае в нажатием кнопки. Значит пока игрок не нажал кнопку, у нас происходило вот так:
Скрытый текст:
ARM1 A 6 ARM1 B 7 Bright ARM1 B 0 A_JumpIfInventory("Aivar242_Item", 1, 2) ARM1 B 0 A_Jump(256, "Spawn") ARM1 A 6 ARM1 B 7 Bright ARM1 B 0 A_JumpIfInventory("Aivar242_Item", 1, 2) ARM1 B 0 A_Jump(256, "Spawn") ARM1 A 6 ARM1 B 7 Bright ARM1 B 0 A_JumpIfInventory("Aivar242_Item", 1, 2) ARM1 B 0 A_Jump(256, "Spawn")
А теперь игрок нажимает кнопку О - происходить теперь будет вот так:
Скрытый текст:
ARM1 A 6 ARM1 B 7 Bright ARM1 B 0 A_JumpIfInventory("Aivar242_Item", 1, 2) ARM1 B 0 A_SpawnItemEx("GreenArmor_Model") Stop
соответственно, спрайтовый актор GreenArmor_Sprite у нас самоликвидируется, и на него месте появится актор GreenArmor_Model, для которого начнет выполняться следующее:
Скрытый текст:
ARM1 A 6 ARM1 B 7 Bright ARM1 B 0 A_JumpIfInventory("Aivar242_Item", 1, 2) ARM1 B 0 A_Jump(256, "Spawn") ARM1 A 6 ARM1 B 7 Bright ARM1 B 0 A_JumpIfInventory("Aivar242_Item", 1, 2) ARM1 B 0 A_Jump(256, "Spawn") ARM1 A 6 ARM1 B 7 Bright ARM1 B 0 A_JumpIfInventory("Aivar242_Item", 1, 2) ARM1 B 0 A_Jump(256, "Spawn")
и так до бесконечности. На всякий случай напомню, что modeldef дефиниция для брони у нас должна быть такая:
Скрытый текст:
Model greenArmor_Model { Path "Models\Items\Armour" Model 0 "arm1.md2" Skin 0 "arm1.png" Scale 1.0 1.0 1.0
FrameIndex ARM1 A 0 0 FrameIndex ARM1 b 0 0 }
Повтори вышеописанный спойлер с прикручиванием кнопки (напомню, его надо сделать 1 раз, также не забудь забиндить себе кнопку O (или любую другую)), потом попробуй прописать себе код декорейта, в котором уже работает кнопка, для зеленой брони, потом синей брони, коробки пуль, синей бутылки и всего остального, что тебе надо. Если все окей (т.е. меняются по кнопке как надо), то делай это для всех моделей что тебе надо
Будут вопросы, задавай
aivar242:
а почему ты сам не перегнал модельки из других портов в Гоззу
1) У меня сейчас приоритет на еретик и хексен, до дума не добрался еще 2) У меня нет цели "перегнать все модели", я перегоняю только те, которые мне нравятся 3) Моделей во-первых много, а во-вторых они постоянно появляются новые (либо появляются новые моды, для которых уже существующие старые модели становятся актуальными), соответственно "перегнать все модельки" попросту нереально, и гораздо лучше "научить людей перегонять самим", чем каждый раз париться самому 4) Я сейчас не успеваю делать даже то что мне нужно (например еретик/хексен), соответственно делание того что мне не нужно (например перегонять модели, которые сам не буду использовать) сам понимаешь, на какой задний план уходит
Помочь кому-то научиться перегонять самому могу (в этом есть определенный интерес), а делать за него всю работу не интересно
Попробовал, работает. Конечно, слишком много букофф, и уже тяжеловато стало. Ради бинда столько строк... Мне в принципе этот бинд больше для интереса интереса познания работы скрипта нужен. Теперь вот пришёл к выводу, что лучший вариант, это чтобы спрайт находился внутри модели, чтобы 3D модель поглощала его, для видимости габаритов обоих моделей. Хорошо бы, чтобы 3D модель (текстура) ещё имела полупрозрачность, на том же бинде - вкл-выкл. "Поглощение" как я понял легко сделать. Иногда и бинд нужен, чтобы оценить детали модели или спрайта. Всё нужно.
theleo_ua:
Помочь кому-то научиться перегонять самому могу (в этом есть определенный интерес), а делать за него всю работу не интересно
Я делаю для себя как и для всех. Модельки выбираю лучшие из лучших (в моём понимании).
самый простой способ: врубаешь консоль, там пишешь:
summon greenarmor_sprite summon greenarmor_model
тогда спрайт и модель призовутся точь в точь в одной точке. Если хочешь, можешь себе бинд сделать в стиле
bind u "summon greenarmor_sprite; summon greenarmor_model"
и тогда при нажатии U возле тебя появится спрайт брони внутри модельки брони
aivar242:
Хорошо бы, чтобы 3D модель (текстура) ещё имела полупрозрачность
в параметры актора (перед его состояниями) пишешь:
renderstyle translucent alpha 0.5
где 0.5 - степень прозрачности (от 0.0, когда модель вообще не видно, до 1.0, когда прозрачности нет)
aivar242:
на том же бинде - вкл-выкл
В предыдущем каменте я тебе отписал, как сделать, чтобы бинд переключал между двумя акторами, один из которых спрайтовый, второй модельный. По такой же логике сделай, чтобы один актор был прозрачной моделью, второй непрозрачной моделью, и бинд их переключал
aivar242:
Я делаю для себя как и для всех. Модельки выбираю лучшие из лучших (в моём понимании).
Когда мои моды будут готовы для выкладывания в инет, я выложу их в инет. Пока не готовы
Я вот что думаю, может и не надо в 2 актора скрипт создавать? Может хватило бы одного, как с мигающими спрайтами и моделями, но заменить команду Replaces, на другую, скажем Add, или Adding - может есть что-то подобное? Мне конечно этот способ с двумя понравился, так как более доходчив, и я виижу оба работающих актора, да и дописывание новых фреймов тоже слегка путает в одиночном акторе. Но - я всегда был преверженцем минимализма, с чётким утверждением, что - если код короче и работает так же как длинный код, то короткий - это идеал программы.
theleo_ua Если что с недавних пор добавили новую фичу в модельдеф
SurfaceSkin model-index surface-index skin-file (development version only)
Defines skin to use for the specified MD3 surface index on model-index model. This can only be used on MD3 files, otherwise it gets ignored.
Как ей пользоваться я не знаю.. но думаю она очень полезна для динамической смены текстуры 3д модели или для анимации на модели..
Я вот что думаю, может и не надо в 2 актора скрипт создавать? Может хватило бы одного, как с мигающими спрайтами и моделями, но заменить команду Replaces, на другую, скажем Add, или Adding - может есть что-то подобное?
Мне конечно этот способ с двумя понравился, так как более доходчив, и я видижу оба работающих актора, да и дописывание новых фреймов тоже слегка путает в одиночном акторе. Но - я всегда был преверженцем минимализма, с чётким утверждением, что - если код короче и работает так же как длинный код, то короткий - это идеал программы.
Я могу объяснить (не длинным текстом, а парой тройкой абзацев), как работает одноакторный метод, который у тебя в models_test.pk3 (да собственно ты и сам можешь открыть DECORATE файл из models_test.pk3 и посмотреть), но проблема в том, что он не рассчитан на прозрачность и "спрайт внутри модельки". Если ты хочешь "спрайт внутри модельки" - тебе в любом случае придется делать как минимум 2 актора (один спрайт и второй модель). А если ты хочешь прозрачность - то для одноакторного способа мне придется еще тебе объяснять что такое ACS скрипты (а в двуакторном методе это легко делается без ACS, я выше описывал как конкретно).
aivar242:
Но - я всегда был преверженцем минимализма, с чётким утверждением, что - если код короче и работает так же как длинный код, то короткий - это идеал программы.
Здесь надо четко расставить приоритеты:
1) "Стоимость" минимализма. Одно дело, когда ты сам полностью шаришь в декорейте, и можешь себе позволить потратить больше своего времени на минимализацию кода, а другое, когда тебе это должен объяснять я или кто-то другой. Т.е. затраты на дополнительное твое обучение не совсем адекватны полученному результату (будет куча новых комментариев с длинным текстом ради всего-лишь минимализации кода, который и так вполне себе минимален). Это с одной стороны. А с другой, ты должен понимать, что тебе такой код писать самому для других моделей, т.е. приоритет на то, чтобы ты понимал, как это делать и смог это сделать, а не на то, чтобы код был на 2 строчки меньше (и не факт, что это будет лучше, кстати)
2) Далеко не факт что одноакторный метод сделает меньше кода (особенно, если туда еще и прозрачность применить). Посмотри в models_test.pk3 и глянь какой там код, он не намного меньше двуакторного
3) Пожалуй самый главный аргумент против минимализма в твоем случае: давай ответим на вопрос - зачем тебе переключение спрайта на модель и переключение прозрачности? Тебе это нужно навсегда или временно? Если цель "подогнать оптимальные значения Scale после чего этот код можно выкинуть (отключить) и использовать модели стандартным способом (вообще без decorate кода), так как размеры уже подогнаны", то зачем париться о минимализме такого кода?
Я понимаю, если бы у тебя был мод, где переключение моделей по кнопке было фишкой мода, которая так навечно в этом моде и останется, но твой мод же "замена спрайтов моделями, причем постоянная, без необходимости туда-сюда переключать", т.е. после всех подгонок там decorate вообще не будет нужен
Соответственно, мне непонятно, зачем вообще париться над минимализмом в твоем случае. Париться надо чтобы тебе было понятно, как делать аналогичный код для остальных моделей
Добавлено спустя 11 минут 31 секунду:
alekv:
theleo_ua Если что с недавних пор добавили новую фичу в модельдеф SurfaceSkin model-index surface-index skin-file (development version only) Defines skin to use for the specified MD3 surface index on model-index model. This can only be used on MD3 files, otherwise it gets ignored.
Как ей пользоваться я не знаю.. но думаю она очень полезна для динамической смены текстуры 3д модели или для анимации на модели..
Прикольно, но меня больше парит ограничение 4 сабмодели на модель (как для md2/dmd так и для md3). Кроме того, md3 в последних версиях частично сломан (куча md3 отображалось в 1.5.6 и не отображается в 2.1.1, хотя некоторые md3 отображаются).
Но вообще это круто, что модельный код гоззы развивается, глядишь, и ограничение в 4 сабмодели уберут (или добавят возможность разных углов/скейлов/оффсетов для сабмоделей)
Да, по сути код мне нужен только чтобы выровнять 3D модели, по отношению к спрайтам. Ты говоришь что зачем это нужно, вроде как модели уже все выровнены, заскейлены, а вот не тут-то было, оно в разных портах не совпадают по скейлу, это первое, а второе что любители реализма, заскейлили некоторые предметы по своему усмотрению, то есть меньше размерами чем нужно. Моя идея, это донести как можно большее разрешение и 3D современность в Doom, вот и всё. Мечта - это 4К, зная то, что эта игра больше не выйдет никогда настолько успешной. Тем не менее твой код будет применяться для того, чтобы сопоставить модели между собой, мигая, или когда я нажимаю забинденную клавишу.
Тем не менее, у меня ещё будет много вопросов к тебе, по переносу моделей.
Да, по сути код мне нужен только чтобы выровнять 3D модели, по отношению к спрайтам. Ты говоришь что зачем это нужно,
Я говорю не "зачем нужно выравнивать", а "зачем нужно париться о минимализме кода, когда он временный"
Представь что у тебя есть 2 версии твоего мода: бета версия и релиз. Бета версию ты постоянно обновляешь, колбасишь, меняешь скейлы, с разных сторон смотришь на спрайты и модели, чтобы размеры совпадали и т д. В релизную версию ты играешь на прохождение, для удовольствия. Допустим появилась новая модель, например бфж, она попадает тебе в бета версию, ты ее колбасишь декорейтом, подбираешь размеры, чтоб совпадало с оригиналом и т д, и когда убеждаешься, что размеры подобраны, кидаешь эту модель в релиз с уже подобранными правильными размерами. Соответственно, в бета версии у тебя есть decorate, а в релизной версии нет.
Вопросы:
1) Зачем в бета версии париться о минимализме кода? 2) Зачем в релизной версии париться о коде, которого в ней вообще не будет?
З.Ы.
aivar242:
Да, по сути код мне нужен только чтобы выровнять 3D модели, по отношению к спрайтам. Ты говоришь что зачем это нужно,
Если бы я не понимал, зачем нужно скейлить модели, я бы не расписывал тебе простыни текста, как это сделать, логично? Вместо этого я 8 комментариев назад (ну или сколько там комментариев назад начался разговор про скейлинг, не суть) задал бы тебе соответствующий вопрос
Добавлено спустя 50 секунд:
aivar242:
Тем не менее, у меня ещё будет много вопросов к тебе, по переносу моделей.
без проблем, главное чтобы не про минимализацию кода
без проблем, главное чтобы не про минимализацию кода
Нет, не про это. Это было как бы вопросом "может возможно покороче"? Но если нелья, то нельзя. Для начинающего это трудоёмкий процесс, осознавать и помнить что написано вверху декорейта, (порой уже выше границы) читая уже внизу. Так же когда текст короче то больше предметов одновременно видишь и осознаёшь их работу.
theleo_ua:
1) Зачем в бета версии париться о минимализме кода? 2) Зачем в релизной версии париться о коде, которого в ней вообще не будет?
Я всё делаю в рабочем, единственно порте. Так можно избежать путанницы и желания продолжать вперёд. Иначе, иногда просто будет лень перекидывать из порта в порт (у многих) и есть возможность забрасывания работы. Тут всё на психологическом уровне, нельзя чтобы что-то сдёрнуло с ключка. Если это случится, очень трудно вернуться в работу назад.)
Когда закончу с моделями предметов, то скину тебе потестить их, на твоём 4:3 экране. Интересно, всё ли будет в порядке?
Это было как бы вопросом "может возможно покороче"?
посмотри models_test.pk3, там пример варианта с одним актором
aivar242:
Но если нелья, то нельзя
может это и можно сделать короче, если использовать IF-ы, но я еще не добрался до их изучения + насколько я понял их еще нет в 2.1.1
является ли вариант с одним актором короче и проще для тебя, или нет, оценивай сам по файлу models_test.pk3 который я тебе давал 8 комментариев назад
aivar242:
Для начинающего это трудоёмкий процесс, осознавать и помнить что написано вверху декорейта, (порой уже выше границы) читая уже внизу. Так же когда текст короче то больше предметов одновременно видишь и осознаёшь их работу.
Есть вариант каждый предмет писать в своем файле (например в одном файле зеленую броню, в другом коробку пуль и т д). Делается так:
т.е. грубо говоря разбить файл DECORATE на куски поменьше. Можно даже эти куски кидать в подпапки, например если ты их кинешь в подпапку DECORATE_SCRIPTS, тогда код файла DECORATE будет такой:
Я всё делаю в рабочем, единственно порте. Так можно избежать путанницы и желания продолжать вперёд. Иначе, иногда просто будет лень перекидывать из порта в порт (у многих) и есть возможность забрасывания работы. Тут всё на психологическом уровне, нельзя чтобы что-то сдёрнуло с ключка. Если это случится, очень трудно вернуться в работу назад.)
Моя мысль в том, что когда оптимальный размер конкретно взятой модели подобран, то всё, декорейт код для этой модели больше не нужен, и его можно либо удалить, либо отключить (перед кодом поставить /* и после кода поставить */ что заставит гоззу игнорировать этот код)
Моя мысль в том, что когда оптимальный размер конкретно взятой модели подобран, то всё, декорейт код для этой модели больше не нужен, и его можно либо удалить, либо отключить (перед кодом поставить /* и после кода поставить */ что заставит гоззу игнорировать этот код)
Зачем его удалять? Он пригодится многим, не только мне, чтобы править модельки или что другое на левеле. Я его закину в архив с ресурсами для Дума, может пригодится. Потом будет трудно всё что нужно вспомнить если что. Хотя это всё можно будет и здесь найти, но всё же... Есть тенденция, что раз в много лет серваки падают. Так что...
theleo_ua:
возможно это упростит тебе моддинг
Да, код вроде попроще и покороче. Действие как я понял то же. Будем пробовать. Вообще-то уже подумывал об отдельных файлах Декорейта - да, так как список слишком длинный получается, если в основном файле всё расписывать.
Зачем его удалять? Он пригодится многим, не только мне, чтобы править модельки или что другое на левеле. Я его закину в архив с ресурсами для Дума, может пригодится. Потом будет трудно всё что нужно вспомнить если что. Хотя это всё можно будет и здесь найти, но всё же... Есть тенденция, что раз в много лет серваки падают. Так что...
я ж там же написал:
theleo_ua:
либо отключить (перед кодом поставить /* и после кода поставить */ что заставит гоззу игнорировать этот код)
т.е. ставишь две обратные косые черты в начале строки, и вся строка игнорируется, следовательно если поставить 2 косые перед #include...blue_armor.TXT, то файл blue_armor.TXT, а следовательно и код внутри него, проигнорируется (т.е. даже сам файл blue_armor.TXT модифицировать не надо)
Соответственно, когда ко всем моделям уже будет подобран размер, код файла DECORATE будет выглядеть примерно так:
theleo_ua Там возможно и нет ограничения, я как-то вычитал что можно делать так: Model test { .....//тут пишем что надо.. FrameIndex MODL A 0 0 }
Model test//потом просто еще раз пишем такую же модель!!! Только уже другие кадры { .....//тут пишем что надо.. FrameIndex DDDD A 0 0 } а в декорейте просто 1 актер с именем Test.. Я не пробовал юзать этот вариант для большего кол. саб моделей т.к. в принципе ими не пользуюсь вообще
alekv, мне надо, чтобы на один спрайтовый фрейм было 6 моделей
alekv:
FrameIndex MODL A 0 0
alekv:
FrameIndex DDDD A 0 0
разные спрайтовые фреймы же. Попробуй такое же провернуть, когда оба фрейминдекса будут для фрейма MODL A, у меня не сработало
Единственный рабочий метод, что я знаю, это синхронизировать 2 актора, но попробуй такое провернуть для HUD (я пока не придумал, как адекватно синхронизировать 2 актора для HUD оружия, особенно если там длинные интерполяции)
Правила 
Поиск
