Вопрос по поводу ZDoom декалей. Возможно ли наложение Thing'a "Decal" с помощью какого-либо метода наложения, аля "умножение", "перекрытие". У меня есть декали с чёрным фоном просто. А метод наложения устраняет ненужный фон и иделально накладывается на текстуру
svl Если тега "нет", то он нулевой. Поэтому будет телепорт на место некоторой teleport destination, стоящей в секторе с нулевым тегом. На место какой именно — не спрашивай, это зависит от порта. В классических, кажется, на ту, у которой номер thing наименьший, а в zdoom, кажется, наоборот.
svl Либо ты путаешь номер сектора с тегом (номера сектора уникальные, теги могут быть одинаковые у разных секторов), либо я чего-то не понимаю. В сектор с нулевым тегом, а не в нулевой сектор (кстати, они не с единицы случайно в GZDB?..).
Как сделать на ZScript возможно проще и быстрее актор, подобный скуллтаговским спаунерам случайных вещей (такие точно были на третьей, что ли, их карте invasion, это та, которая переделана из Mt. Erebus; да, наверное, и вообще на всех)? Идея такова: на карте лежит какая-то вещь (патроны или какой-нибудь арморбонус), игрок её подбирает, через некоторое время на том же месте респаунится какая-то другая вещь. Но пока игрок не подберёт вещь, она респауниться не будет. В скуллтаге ещё вроде есть какие-то дополнительные ограничения в стиле "не более 5 подборов предмета на волну", но мне можно и без этого, лишь бы работало.
Я попробовал добавить RandomSpawner'у флажок +ALWAYSRESPAWN, но RandomSpawner, кажется, сразу удаляется после того, как отработал (то есть, выбрал актора и заспаунил). Поэтому напрямую так не получится; однако хотелось бы воспользоваться синтаксисом "DropItem <ActorName>[, probability[, amount]]", не копипастя весь код RandomSpawner из gzdoom.pk3 (синтаксис удобен и позволяет избавиться от кучи if-ов).
Всех с наступающим/наступившим!
Нет, мне не совсем то нужно. -random — это же параметр к запуску экзешника. Он обрабатывается на низком уровне, и поэтому он вообще про все item-ы. Мне же хочется сделать однин класс с таким поведением (чтобы поведение остальных не менялось).
В любом случае, в zdoom он, судя по wiki, не реализован. Пойду лучше сам навешаю костылей Edit: да, успешно перекостылил скопипастил ChooseSpawn() из кода RandomSpawner и поменял его так, чтобы он сохранял в спаунере указатель на заспауненную вещь. Потом он просто каждые n тиков проверяет, не забрана ли она.
Народ, какая функция позволяет сделать следующее:
Заспавненный игроком дружественный монстр мог атаковать противника только в том случае, если игрок видит этого противника?
Заспавненный игроком дружественный монстр мог атаковать противника только в том случае, если игрок видит этого противника?
Если по-хорошему, то через AAPTR_PLAYER_GETTARGET разве что, но это касается только противника непосредственно под прицелом.
Если по-плохому, то игрок должен непрестанно срать перед собой хитсканами (на весь телесный угол зрения), не наносящими урон, но как-либо помечающими монстра с последующим автосбросом метки через некоторую задержку. Проще всего по идее через выдавание итема, но я хз, работает ли стейт "Pickup" при получении итема монстром (для автосброса), а проверить сейчас нет возможности. В таком случае френдли монстр будет перед атакой проверять A_JumpIfInventory и сбрасывать таргет, если у таргета нет итема.
В чём смысл писать только на декоре под последний гздум?
Мод очень большой, все монстры (их штук 300 или больше - я уже потерял счет) написаны на декоре у которых один парент. Переводить все на ЗСКРИПТ сейчас в планах нет (пока). Если можно оставить монстра на декоре, а его атаку проверять через ЗСКРИПТ - тогда я только рад, но понятия не имею как.
С другой стороны обновления принесли кучу исправлений и добавлений новых флагов и функций - иначе бы вообще не обновлял...
Если можно оставить монстра на декоре, а его атаку проверять через ЗСКРИПТ - тогда я только рад, но понятия не имею как.
Можно. Базу монстра делаешь на зскрипте, наследуешься от него в декоре и дальше пишешь код на декоре. Унаследовать монстра от декора вроде не получится, к сожалению.
Если у тебя все монстры откуда-то уже наследуются — то самого главного актора наследуешь от зскрипта. Таким образом добавляемая функция попадёт во всех акторов которые есть.
Добавлено спустя 1 день 20 часов 33 минуты 58 секунд:
Функция A_PlaySound уже депрекейтыд - вместо нее теперь A_StartSound. Интересно сколько еще можно будет пользовать "безболезненно" функицю A_Playsound, пока ее окончательно не ёкнут...
Спасибо конечно за инфу, но у меня че то особо ниче не получилось. Суть в том, чтобы с лифтом синхронно двигались лайты, его освещающие; и акторы типа "эмбиент саунд". Вместе и синхронно, по команде ACS скрипта. Есть предложения?
DOOMGABR "Ничего не получилось" --- это как? Какие именно проблемы возникают? Или акторы вообще не движутся при работе скриптов?
Если проблема в отсутствии синхронизации, нужно подобрать скорости лифта и акторов; дело в том, что секторы движутся (по крайней мере, по вертикали) относительно "octic"-ов (частота 8 Гц), а акторы и ACS работают с обычными тиками (35 Гц). Так что если лифт движется со скоростью 16, то это будет 128 мапюнитов в секунду, что эквивалентно ThrustThingZ со скоростью ("силой"...) где-то на 3,66 каждый тик. Это нехорошо: даже если ACS позволит здесь задать дробную скорость, она всё равно получится неточная. Аналогично с SetActorVelocity (есть и такая функция тоже).
Поэтому решение другое, нужно использовать SetActorPosition(tid, GetActorX(tid), GetActorY(tid), GetSectorFloorZ(liftsectortag) + C); (где C --- изначальный оффсет динлайта или саунда) в бесконечном цикле с Delay(1) (например, в отдельном скрипте, запущенном хоть с начала уровня). Этим ты заодно избавишься от необходимости мучительно придумывать багфиксы на случай, если кто-нибудь обратит внимание на уезжающие по текстуре динлайты, если платформа лифта застряла
Правила 
Поиск
Спасибо
