Доброго времени суток! Народ, кто может подсказать как в ДумБилдере сделать движение текстуры на 3Д-Флоре ? Не можем понять какая функция за это отвечает
К сожалению не очень понятно как именно это сделать. Есть несколько 3Д платформ одна над другой - нужно чтобы у средней скролилась текстура... Я не нашел способа - хоть мы и обошлись и без этого, но все равно хотелось бы знать.
Наверное, у меня вопрос банальный, но всё же. Делаю вад для Doom 2, использую в качестве основного источника ресурсов doom2.wad, добавил немного новой графики и музыки. И тут захотелось использовать текстуры из Doom 1, которых нет в Doom 2. Можно ли как-то быстро перекинуть все недостающие текстуры внутрь моего вада? Знаю, что уже есть текстурпак, где эти текстуры содержатся, вот он:
но нормально скопировать у меня пока не получилось. Если, например, с помощью Slade просто скопировать содержимое текстурпака в мой вад, то возникает ошибка, связанная, по-видимому, с лампом TEXTURE1, и текстуры отображаются криво. Пробовал удалить свои старые TEXTURE1 и PNAMES, а потом скопировать аналогичные лампы из текстурпака, но это не решает проблему.
Michael63, вроде бы всё вместе компилируется, запускается. Текстуры из того сборника + "Khorus" на копии Doom 2 MAP01:
Скрытый текст:
Сам файл-пример, в нём добавил всё из "d1gfxd2.wad", а также текстуры маски "K_BLD01*" из Khorus. Добавлял через ПКМ -> "Graphics" -> "Add to TEXTUREx", Slade v3.1.12:
то возникает ошибка, связанная, по-видимому, с лампом TEXTURE1, и текстуры отображаются криво
Ошибка в каком-либо логе описывается, или это просто визуальный баг? И отображаются криво как именно -- некоторые типичные ошибки, вроде расположения не в том WAD Namespace, выявляются по характеру сбоев.
Ошибка в каком-либо логе описывается, или это просто визуальный баг?
Визуальный, прикладываю скриншот. Я вроде разобрался, в чём было дело. В моём ваде была лишняя копия лампа PNAMES (то есть, после копирования всего содержимого из d1gfxd2.wad оказалось аж три PNAMES, и один из двух лишних я вчера не удалил). При удалении этот баг исчезает.
Возможно ли в GZDoom сделать актор, хитскановые попадания в который LineTracer-ом не проверяются по оси Z? Мне интересно прежде всего регистрировать хитсканы, "пролетающие" ниже хитбокса актора (такое может быть, если он стоит на наклонном полу). Могут ли как-то в этом помочь SetXYZ и UnlinkFromWorld?
По моим проверкам, сам актор без посредников -- нет.
Скрытый текст:
class HitscanTest_Base: Actor {
const GRAY = TEXTCOLOR_GRAY;
const DARK = TEXTCOLOR_DARKGRAY;
Default {
+SOLID;
+SHOOTABLE;
+BUDDHA;
+NOGRAVITY;
Health 0x7FFFFFFF;
Mass LARGE_MASS;
Height 56;
}
override int TakeSpecialDamage( Actor inflictor, Actor source, int damage, Name damagetype ) {
String inflictorName = ( inflictor? inflictor.GetClassName() .. "" : "<NULL>" );
String sourceName = ( source? source.GetClassName() .. "" : "<NULL>" );
console.printf( DARK .. "%s::TakeSpecialDamage(). inflictor " .. GRAY .. "%s" .. DARK .. ", src " .. GRAY .. "%s" .. DARK .. ", damage = " .. GRAY .. "%i" .. DARK .. ", dmgtype = '" .. GRAY .. "%s" .. DARK .. "'.",
GetClassName(), inflictorName, sourceName, damage, damagetype );
return Super.TakeSpecialDamage( inflictor, source, damage, damagetype );
}
override bool CanCollideWith( Actor other, bool passive ) {
console.printf( DARK .. "%s::CanCollideWith(). other " .. GRAY .. "%s" .. DARK .. ", passive == " .. GRAY .. "%i" .. DARK .. ".",
GetClassName(), other.GetClassName(), passive );
return Super.CanCollideWith( other, passive );
}
States {
Spawn:
TROO A -1;
Stop;
}
} // of class HitscanTest_Base: Actor {}
class HitscanTestCANPASS: HitscanTest_Base {
Default {
+CANPASS;
}
}
class HitscanTestCanCollideTrue: HitscanTest_Base {
override bool CanCollideWith( Actor other, bool passive ) {
Super.CanCollideWith( other, passive );
return true;
}
}
class HitscanTestCanCollideFalse: HitscanTest_Base {
override bool CanCollideWith( Actor other, bool passive ) {
Super.CanCollideWith( other, passive );
return false;
}
}
class HitscanTestACTLIKEBRIDGE: HitscanTest_Base {
Default {
+ACTLIKEBRIDGE;
}
}
class HitscanTestDONTOVERLAP: HitscanTest_Base {
Default {
+DONTOVERLAP;
}
}
class HitscanTestISMONSTER: HitscanTest_Base {
Default {
+ISMONSTER;
}
}
class HitscanTestMonsterCombo: HitscanTest_Base {
Default {
Monster;
}
}
Однако можно попробовать создавать второй актор, связанный с первым и расположенный ниже него, а затем через манипуляции с +ALLOWTHRUBITS/+ALLOWTHRUFLAGS добиваться нужного эффекта (с ними не разбирался, так что тут конкретнее ничего не скажу. Вроде как для работы нужны собственные BulletPuff-типы). В коде под спойлером все акторы блокируют хитскан-атаки, но это не показатель, в нём я и пытался добиться определения столкновения.
"SetXYZ()" просто не обновляет несколько внутренних структур -- самыми заметными из них будут BLOCKMAP и RenderList (а "UnlinkFromWorld()" банально вычищает все ссылки на вызывающего актора из этих же структур). В случае нарушения работы первой актор будет считать, что он находится в другом секторе и другой BLOCKMAP-ячейке относительно фактических; в случае порчи второй более дальние акторы могут начать отрисовываться поверх более близких.
JSO x Спасибо за ответ! Я не совсем правильно выразился, SetXYZ мне был нужен, чтобы попробовать переместить актора под пол.
Дело вот в чём, модели танков из этой темы у меня должны иметь возможность менять все три своих угла Эйлера, и при этом все хитскановые попадания (у меня не BulletPuff) по модели должны регистрироваться. Сейчас меняется только рыскание (angle), и с регистрацией всё нормально, но если поменять крен (roll) или тангаж (pitch), то произойдёт вот такое:
то есть попадания по красной части регистрироваться не будут (а должны).
Поэтому мне нужен либо способ избавиться от проверки Z в хитскане вообще, либо способ утопить нижнюю часть актора в пол с сохранением -NOBLOCKMAP, чтобы его видели хитсканы (и переместить (0,0,0) модели в центр этого актора по вертикали):
Утопить у меня его тоже не получается,
ни к чему не приводит (актор остаётся на месте), хотя на странице SetXYZ написано, что после LinkToWorld вызывать FindFloorCeiling нужно самостоятельно. Я добавил ему +NOGRAVITY и +NOCLIP, но на результат это не повлияло.
Теоретически, я вот подумал, чего-то подобного можно было бы достичь с помощью A_Explode с флагом OLDRADIUSDMG, но как это отразится на производительности?.. Надо потом проверить.
Поэтому мне нужен <...> либо способ утопить нижнюю часть актора в пол с сохранением -NOBLOCKMAP, чтобы его видели хитсканы (и переместить (0,0,0) модели в центр этого актора по вертикали):
По-моему, только +NOINTERACTION позволяет одновременно оставлять актор видимым в мире и позволять ему находиться ниже пола/выше потолка, 3D-полы в расчёт не берём. Но этот флаг, естественно, напрочь отключает все коллизии.
Не, они ниже уровня пола опустить актор не помогут. Тот же игрок при активном noclip не проваливается сквозь поверхности (насколько помню, там чуть разные ветки обработки, но в целом вызывается один и тот же метод).
<...>, либо способ избавиться от проверки Z в хитскане вообще
А не получится ли заменить хитскан/LineTrace на проджектайл? Потому что они совершенно точно учитываются доброй половиной акторов из кода в моём предыдущем сообщении (в том числе и вне хитбокса сверху/снизу). Но класс "FastProjectiles" довольно прожорливый, хотя его можно оптимизировать под конкретный проект. Если не удастся -- то "A_Explode()", скорее всего, будет действительно быстрее.
Ещё есть вариант написания собственной системы проверки столкновений, например, через квадро- или октодеревья -- и работать она будет крайне быстро, даже при множестве танков и снарядов.
Поэтому, собственно, функции вроде "Actor::AddZ()"/"Actor::SetZ()" и реализованы элементарным прямым присвоением координаты -- и используются в коде без каких-либо дополнительных проверок (на примере Ревенанта или Д'Спарила).
а какие проверки обычно делаются при изменении X и Y (кроме секторов и blockmap) ? И не затруднит кинуть примеры таких проверок в коде?
Z-координата актора меняется без проверок на то, должен ли измениться актор внутри каких-либо из тех внутренних структур (собственно, "SetXYZ()" делает это же, но по всем трём координатам). Я прошёлся поиском по gzdoom.pk3 -- вот статистика за исключением объявления функций в "actor.zsc":
1) "SetXYZ()" использовался в трёх файлах. Дважды для изменения стартовой точки вылета снаряда без проверок на вместимость (она чуть дальше проверялась), один раз для и так отлинкованной от мира "MovingCamera".
2) "SetZ()" и "AddZ()" -- в 18 файлах.
3) "SetOrigin()" -- в 11 файлах. Собственно, везде, где нужно глобально и на постоянной основе изменить позицию актора в мире. Кстати, в C++ телепортация тоже использует его же.
А вот код "P_ZMovement()", вызываемый внутри "AActor::Tick()": видно, что, несмотря на обилие кода, никаких перелинковок к секторам/BLOCKMAP-сетке/render-списку не производится.
а какие проверки обычно делаются при изменении X и Y (кроме секторов и blockmap) ?
Не-не, все необходимые для нормальной жизни движка проверки производятся под C++-капотом. Для программиста на ZScript чаще всего можно обойтись либо "TestMobjLocation()" (например, в "Actor::InitSpawnedItem()" и "PlayerPawn::UndoPlayerMorph()"), либо, в более редких случаях, "BlockLinesIterator" (примеров в gzdoom.pk3 вообще нет, но тоже может использоваться. Я так для Auto-Ambient Doom хотел сделать динамическую имитацию флага +FIXMAPTHINGPOS).
Вопросs есть. Буду признателен если ответите.
1) Новые текстуры для doom могут любые имена иметь? (те что в папке #.pk3/textures) а не обязательно принятые для doom,doom2?
2) Что нужо сделать, чтобы добавить в игру новые "Things" например из категории "decoration" (не язык скриптов, а украшения на карте типа деревьев tre1, tre2 и прочего).
camper Раз в вопросе присутствует название pk3, правильно я полагаю, что речь идёт о ZDoom/GZDoom?
1) Да, любые, в том числе длиннее 8 символов. Кроме того, можно использовать несколько разных текстур с одним названием файла, если они лежат в разных папках. Для того чтобы их различать, в UDB нужно поставить галку "Use long texture names" при загрузке карты.
2) В каком смысле "добавить"? Чтобы можно было их ставить на карту? В любом случае не обойтись без описания актора в Decorate/ZScript, если его нет, то его нужно написать самостоятельно, благо что для декорации это очень просто (чтобы этому научиться, можно переделывать описания акторов с ZDoom Wiki). Например, вот страничка с кодом на Decorate одной из стандартных декораций. Она анимированная, если нужна статичная декорация с одним спрайтом, который называется, например, "XYZWA0.png", то строчку после Spawn нужно заменить на "XYZW A -1" (-1 означает бесконечную длительность фрейма).
После этого нужно дать декорации номер (DoomEdNum), не совпадающий с этими (без этого можно будет только спаунить в игре её командой summon, а не ставить на карту). Вписать номер нужно после названия:
Actor EvilEye 41 { ... }
В ZScript так делать нельзя, DoomEdNum нужно указывать в MAPINFO.
После этого можно уже ставить актора на карту, но в редакторе он будет отображаться в отдельной категории User-defined ближе к концу списка. Чтобы переместить её в Decorations, нужно добавить в Decorate вне стейтов строчку типа //$Category "Decorations/Tech" (см. список читаемых DB типов комментариев). С другой стороны, может иметь смысл завести свои отдельные категории для новых акторов.
Раз в вопросе присутствует название pk3, правильно я полагаю, что речь идёт о ZDoom/GZDoom?
Это для k8vavoom, форка vavoom. Сейчас готовится выход нового билда, который способен запускать ipk3 без использования ресурсов оригинальных игр id на idtech1. k8vavoom не использует zscript, но поддерживает decorate. Я собрал тестовый ipk3 в основном на основе ресурсов карты lest.wad (Cartoteka&Vector) для демонстрации и экспериметов, подобный этому https://forum.zdoom.org/viewtopic.php?p=1169284#p1169284 Но движок позволяет играть в мультиплеер (по крайней мере по локалке) уже сейчас. Сейчас дошлифую до какого-то состояния и хочу опубликовать к новому билду движка, с разрешения всех авторов контента.
k8vavoom не использует zscript, но поддерживает decorate.
Насколько знаю, у него собственный язык. "VavoomScript" или как-то так. Более низкоуровневый в сравнении с ZScript -- то есть позволяет писать некоторые вещи, которые в защищённом со всех сторон API ZScript, в теории, сделать нереально. Однако это заставляет платить цену совместимости модификаций -- поэтому сделать сборку на k8vavoom (а иногда и просто заставить работать два мода вместе) куда труднее, чем на GZDoom.
Насколько знаю, у него собственный язык. "VavoomScript" или как-то так. Более низкоуровневый в сравнении с ZScript -- то есть позволяет писать некоторые вещи, которые в защищённом со всех сторон API ZScript, в теории, сделать нереально. Однако это заставляет платить цену совместимости модификаций -- поэтому сделать сборку на k8vavoom (а иногда и просто заставить работать два мода вместе) куда труднее, чем на GZDoom.
Это Vavoom-C , но ketmar (автор проекта k8vavoom) против широкого его использования и настаивает на использовании decorate. По мнению многих использование zscript ограничивает моддинг только для gzdoom.
Decorate сам по себе хорош для модификаций обыкновенной направленности -- если нужно сделать что-то, выходящее за рамки управления стейтами, то им одним никак не обойтись. ACS для своих целей (в основном для управления уровнем) неплох, однако тоже ограничен. А вот Vavoom-C и ZScript такие рамки отодвигают куда дальше.
Также стоит рассмотреть вопрос оптимизации кода; предупреждаю, далее речь пойдёт про семейство портов *ZDoom с 2016-го года, которое я более-менее изучил.
Так вот, ни Decorate, ни ACS в этом плане не могут потягаться с обоими языками -- я знаю, так как проводил несколько бенчмарков (сравнений скорости разных реализаций; прилагаю пример-скриншот подобной проверки) и немного изучал JIT-компиляцию ZScript (более того, информацию об этом флаге на ZDoom Wiki тоже добавил я). Вкратце:
1) ZScript компилируется в мнемоники Ассемблера целевой платформы, что при грамотном использовании априори является наибыстрейшим способом исполнения кода;
2) ACS -- в опкоды собственной VM, а именно "ACSThinker" (базовый класс "Thinker", кстати, тоже находится в юрисдикции API ZScript. До "ACSThinker" добраться можно, однако с ним количество действий уже резко ограничено);
3) Decorate, DeHackEd, DECOHack и другие подобные вещи изменяют конфигурацию стейтов. Опять же, система их внутриигровой смены, за исключением вызова кодпоинтеров, полностью написана на ZScript.
Вывод? В этом плане оба языка -- и ZScript, и Vavoom-C, вероятнее всего, написанный с тем же прицелом -- вне конкуренции. Мне, с моим слабым железом и жаждой создания добротных оптимизированных модификаций, связки Decorate + ACS катастрофически не хватает.
Правила 
Поиск
