У меня это дает только сообщение "unknow script "doom_forever"
Ну а в ACS у тебя есть такой скрипт? Там в декорейте просто вызывается ACS скрипт который должен быть прописан, для этого тебе и нужна компиляция скрипта.
alekv Конечно есть. Может я его, конечно, как-то не так компилирую/что-то другое. Хотя, что там можно не так сделать. Я просто указал путь к компилятору acc.exe в слейде и нажал в текстовом файле кнопку "compile acs"
По моему лучший вариант проверка дистанции, только не тот пример что в вики, он мне лично не подошел т.к. когда много акторов вызывающих функцию Distance, игра начинает лагать т.е. надо туже функцию из вики переписать в простой скрипт типа: Script "Distance" (int dist) и в декорейте уже вызывать по такому принципу TNT1 A 0 A_JumpIf(CallACS(Distance) > 256, "LowPar")
Спасибо за мнение
alekv:
А еще лучше делать так когда игрок далеко от объекта, лучше вообще вырубать всякие партикли, динлайты и прочее.. (если юзаешь 3д модели, то и их тоже) Но это лично моё мнение..
Я согласен, а есть какие-то простые способы временного, но моментального вырубания/врубания 3дмодели, или придется долбаться с фреймами (например фрейм А спрайтовый, а фрейм B - тот, на который навешана модель в моделдефе, соответственно при большой дистанции jump туда где B, при маленькой где А), где либо на каждый тик навешивать проверку на дистанцию до игрока, либо ловить глюки несвоевременного возврата модели?
Тот же вопрос и про динлайты
alekv:
Врятли есть быстрее чем скрипт distance, но именно скрипт, а не функция из вики
Кстати, я не понял, что ты имеешь в виду, ставя разницу в вызове скрипта или функции напрямую. Если мне надо вызвать проверку из декорейта, я вызываю скрипт, который вызывает эту функцию, а если мне надо проверить внутри ACS (например у меня вызван скрипт, который спавнит акторы на требуемых координатах пока выполняются спец условия), тогда проверка делается напрямую функцией. В чем разница, если внутри скрипта вызывать эту функцию не напрямую, а через обертку в виде скрипта?
Или ты имеешь в виду, что если вызывать через скрипт, тогда вызывается реже, и следовательно лагает меньше?
alekv:
Да никакими.. TID меняешь когда захочешь. Можно и старый вернуть, можно новый дать, тут дело не в проблемах, а в том где и зачем будешь это юзать и там где юзаешь просто указываешь новый TID игрока если его вообще надо указывать) Вот я сколько скриптую(ну ты видел мою игру про зайца) я там игроку TID не менял вообще, а вся игра построена на Thing-ах
В маппинге часто мапперу приходится проверять TID игрока для скриптов? Имею в виду простейшие скрипты типа "убил монстров таких-то, открылась стенка такая-то, игрока телепортануло туда-то". Я просто свой мод делаю как дополнительный для маппаков (в первую очередь тех, которые используют декорейт и ACS)
alekv:
Ну а в ACS у тебя есть такой скрипт?
Кстати, про ACS. Я столкнулся с некоторыми проблемами и неудобствами, и в результате понял, что целесообразно делать строго одну ACS библиотеку на 1 мод (т.е. делаешь один ACS файл, в котором через include добавляются все остальные).
Вопрос следующий: какие выгоды дает нам разбивание скриптов не несколько библиотек? Какие проблемы нам дает объединение в одну?
По моему лучший вариант проверка дистанции, только не тот пример что в вики, он мне лично не подошел т.к. когда много акторов вызывающих функцию Distance, игра начинает лагать т.е. надо туже функцию из вики переписать в простой скрипт типа: Script "Distance" (int dist) и в декорейте уже вызывать по такому принципу TNT1 A 0 A_JumpIf(CallACS(Distance) > 256, "LowPar")
Это потому, что начиная с 2.7.1 нужно юзать встроенную функцию VectorLength. У меня ничего не лагает, например. Как-то так:
function int VectorLength3(int dx, int dy, int dz)
{
return VectorLength(dz, VectorLength(dx, dy));
}
function int fdistance(int tid1, int tid2)
{
return VectorLength3(GetActorX(tid2)-GetActorX(tid1), GetActorY(tid2)-GetActorY(tid1), GetActorZ(tid2)-GetActorZ(tid1));
}
У меня есть карта, где эта функция используется приблизительно 320 раз за тик, и ничего не лагает. У меня есть другая карта, где эта функция используется приблизительно 500 раз за тик, и опять же ничего не лагает.
theleo_ua:
1) Что даст большую производительность - A_RadiusGive + CheckInventory или FDistance ? Напомню, что RadiusGive в гоззе 2.0.05 (а я делаю именно под нее) не умеет в "список акторов кому гивать"
Я лично использую комбинацию A_RadiusGive + ACS_ExecuteWithResult в итеме. Таким образом один раз написанная библиотека ACS вполне может быть использована для вызова произвольного скрипта по радиусу с заданными флагами в текущем кадре, при этом активатором будет актор который попал в радиус и флаги.
Но вообще всё зависит от того, сколько акторов на карте и скольким необходимо проверять инвентарь. Если нужно опросить большое количество акторов (например, всех монстров в радиусе 1024 юнитов), то использовать надо A_RadiusGive. Если нужно определить только игроков, то проще пройти по игрокам и каждому вызвать fdistance (только главное по примеру выше, а не по тому что в вики).
theleo_ua:
Есть ряд акторов, которые до определенного стейта (а некоторые всю жизнь) спавнят партиклы (в качестве партиклов свои кастомные акторы, т.е. функция A_SpawnParticle не используется). В целях оптимизации производительности, решил ограничить спавн партиклов по условию "дистанция до игрока больше X".
У меня для этой цели используется этот актор: http://pastebin.com/P2kMFVkw У него из ацс можно проверять условие !!GetUserVariable(tid, "user_visible"). Если true, то актор виден хотя бы одному игроку на карте. В остальном актор идентичен MapSpot'у. Этот актор оптимизирован конкретно для ацс, если ты спавнишь партикли/акторов в декоре, то просто продублируй подход у себя. Ключевые слова +LOOKALLAROUND и A_Look, после чего в See необходимо указать что делать если есть игроки в зоне видимости, вернуться в Spawn и вызвать A_ClearTarget (чтобы опять с нуля игрока искало).
Насколько я знаю, в том же брутале используется нечто подобное.
Есть вопрос на засыпку: Мы знаем, что в Decorate можно легко заменить имеющегося монстра на другого. И эта замена будет возникать всегда. А можно ли сделать, чтобы на определенном уровне внезапно спавнился совсем другой монстр?
К примеру, Map07 второго Дума. Вот есть Манкубус. Поменяли его на какого-нибудь серо-бурмалинового рыцаря Ада. И он всегда встречается вместо Манкубусов, НО вот на map07 должен быть не он, а какой-нибудь кирпичный Арчвайл. Это возможно? В обычном Decorate весьма сомнительно, надо по-любому подключать ACS в дело, но наверняка не знаю, поэтому решил спросить.
Это потому, что начиная с 2.7.1 нужно юзать встроенную функцию VectorLength. У меня ничего не лагает, например.
Про вектор не знал.. спасибо, это мне поможет, я думал нагрузка из-за того что в декорейте вызвался скрипт который вызывал функцию distance и чекал дистанцию.
theleo_ua:
Я согласен, а есть какие-то простые способы временного, но моментального вырубания/врубания 3дмодели, или придется долбаться с фреймами (например фрейм А спрайтовый, а фрейм B - тот, на который навешана модель в моделдефе, соответственно при большой дистанции jump туда где B, при маленькой где А), где либо на каждый тик навешивать проверку на дистанцию до игрока, либо ловить глюки несвоевременного возврата модели?
Я когда искал способы, не нашел. Но себя отлично проявил скрипт:
Script "Distance" (int EnterDist)
{
Int Thing_X = GetActorX(0) >> 16;
Int Thing_Y = GetActorY(0) >> 16;
Int Thing_Z = GetActorZ(0) >> 16;
SetActivator(0,AAPTR_PLAYER1);
Int Play_X = (GetActorX(0) >> 16);
Int Play_Y = (GetActorY(0) >> 16);
Int Play_Z = (GetActorZ(0) >> 16);
Int X = Thing_X - Play_X;
Int Y = Thing_Y - Play_Y;
Int Z = Thing_Z - Play_Z;
EnterDist = sqrt(X*X + Y*Y + Z*Z);
SetResultValue(EnterDist );
}
и у меня в моде этот скрипт вызывает почти каждая 3д модель или прожорливый thing(в плане скрипта) И примерно так чекает каждый тхинг дистанцию до игрока (спс Lex_Safonov... помню помог мне чуть) Spawn: MODL A 0 MODL A 0 A_JumpIf(CallACS("Distance") > 2048, "Off") MODL AAA 1 Loop LOD: NULL A 2 //собс-но когда игрок дальше от thinga чем 2048 мап пикселей, просто ничего не рендерится.. Goto Spawn И такой вот способ реально убрал лаги у меня в игре.. без такой проверки все подтормаживало из-за большого кол. 3д моделей. Я не вникал, но может способ у ZZYZX лучше..
theleo_ua:
Кстати, я не понял, что ты имеешь в виду, ставя разницу в вызове скрипта или функции напрямую. Если мне надо вызвать проверку из декорейта, я вызываю скрипт, который вызывает эту функцию, а если мне надо проверить внутри ACS (например у меня вызван скрипт, который спавнит акторы на требуемых координатах пока выполняются спец условия), тогда проверка делается напрямую функцией. В чем разница, если внутри скрипта вызывать эту функцию не напрямую, а через обертку в виде скрипта?
Да я имел ввиду что скрипт дистанцию лучше юзать в декорейте, а функцию в ACS скриптах(у меня она там не лагала), но ZZYZX объяснил в чем было дело..
theleo_ua:
В маппинге часто мапперу приходится проверять TID игрока для скриптов? Имею в виду простейшие скрипты типа "убил монстров таких-то, открылась стенка такая-то, игрока телепортануло туда-то". Я просто свой мод делаю как дополнительный для маппаков (в первую очередь тех, которые используют декорейт и ACS)
Ну тут дело такое, как правильнее я не знаю, но я стараюсь делать так что бы активатором скрипта всегда был thing с которым мне нужно манипулировать, я меняю ему TID и назначаю активатором игрока функцией SetActivator или SetActivatorToTarget зависит от случая и в таком случае я всегда знаю что TID игрока это 0.. Но конечно если надо менять можно и поменять. В общем все зависит от конкретного случая.
theleo_ua:
Вопрос следующий: какие выгоды дает нам разбивание скриптов не несколько библиотек? Какие проблемы нам дает объединение в одну?
Выгода.. чище в мап скриптах проблема объединения бардак в скриптах По моему это только для этого и сделано.. что бы все основные функции константы переменные и т.д. которые часто используем и которые не привязаны к уровню были где-то далеко и не мешали скриптовать в мап скриптах. Опять же ИМХО
A_CheckProximity такую вот функцию увидел.. первый раз, еще не пробовал, но что-то там с дистанцией связано, может можно как-то заюзать.
Где-то я уже приводил пример скрипта, сравнивающего текущую карту с заданным номером, для использования с CallACS(). Но да, только ацс. Сравнивать StrParam(n:PRINTNAME_LEVEL).
Напишите пож. как правильно прописать в menudef эпизоды? Собс-но проблема, когда захожу в меню\новая игры\открывается меню эпизодов, там можно юзать текст в качестве названия или картинку.. но курсор у меня заходит на текст, решил сделать названия эпизодов картинками, но там та же проблема, в общем мне надо знать как можно отдалить друг от друга 2 названия эпизода. Вот как к примеру в общем меню делается такое:
Position 180, 119//Это позиция где будет показываться моя картинка PatchItem "Graphics/Menu/APlay.png", "d", "StartGameMenu"// какая картинка будет показываться и что надо делать когда на нее нажали
В Episode Menu все тоже самое можно прописать, но что надо делать когда нажали на картинку эпизода? Ведь в пред. случае была команда открыть меню новой игры.. а у эпизода такого нет что делать???
MAPINFO не подходит т.к. там можно только указать текст или картинку, но позицию прописать нельзя... Курсор менять, не вариант, меню стилизованное и не обычное. Возможно попробую еще выход из такой ситуации с помощью шрифта с большой буквой размером 64х64.. такой шрифт можно прописать в эпизоде и по идее получится, но это черезжопный вариант.
Я еще покопался в исходниках, в надежде там что-то найти.. но безрезультатно.. Вот еще этот же вопрос но по другому PatchItem "Graphics/Menu/ASetup.png", "w", "Episodemenu" //такая функция открывает меню выбора эпизода которые прописаны в MAPINFO, а мне надо что бы было что-то такое EpisodMenu_MyEpisode т.е. что бы по нажатию на нее загрузился MyEpisode прописанный в мапинфо.. выручайте пож. ) Может кто знает как в исходниках это дело прописать и скомпилить версию?
Я еще добавил +seeinvisible, ибо без него врубаешь невидимость и партиклов начинает спавнится в 20 раз меньше.
Кстати, какой максимальный радиус действия у a_look?
А так да, метод норм, вроде работает как надо (единственное где возникнут проблемы, это если понадобится к монстрам применять, но у меня пока монстры без партиклов).
ZZYZX:
Это потому, что начиная с 2.7.1 нужно юзать встроенную функцию VectorLength
понял, спасибо
ZZYZX:
Но вообще всё зависит от того, сколько акторов на карте и скольким необходимо проверять инвентарь. Если нужно опросить большое количество акторов (например, всех монстров в радиусе 1024 юнитов), то использовать надо A_RadiusGive. Если нужно определить только игроков, то проще пройти по игрокам и каждому вызвать fdistance (только главное по примеру выше, а не по тому что в вики).
В моем случае это разбросанные по карте предметы инвентаря, патроны и элементы декора (например статуя с огнем, где огонь партикловый), а игрок всегда строго один. Количество предметов/патронов - стандартное для маппаков со сложностью "выше среднего" (статуи тоже в количестве, близком к среднестатистическому). Далеко не факт, что этим все будет ограничено, но на данный момент не вижу других акторов для применения "вечных" кастомных партиклов.
ZZYZX:
вызвать fdistance (только главное по примеру выше, а не по тому что в вики).
Кстати, а в чем ключевое отличие кода Vectorlength от fdistance с вики, не в курсе? Просто интересно, почему он быстрее, что там изменили
Добавлено спустя 23 минуты 54 секунды:
alekv:
NULL A 2 //собс-но когда игрок дальше от thinga чем 2048 мап пикселей, просто ничего не рендерится..
чем NULL отличается от TNT1 и "####" ?
alekv:
И примерно так чекает каждый тхинг дистанцию до игрока (спс Lex_Safonov... помню помог мне чуть) Spawn: MODL A 0 MODL A 0 A_JumpIf(CallACS("Distance") > 2048, "Off") MODL AAA 1 Loop LOD: NULL A 2 //собс-но когда игрок дальше от thinga чем 2048 мап пикселей, просто ничего не рендерится.. Goto Spawn И такой вот способ реально убрал лаги у меня в игре.. без такой проверки все подтормаживало из-за большого кол. 3д моделей. Я не вникал, но может способ у ZZYZX лучше..
для предметов и декора такое вполне приемлемо, а вот с монстрами придется париться насчет "не изменять геймплей" и "моментально восстановить модель при телепортации игрока в локацию рядом с монстром, причем восстановить строго текущий фрейм монстра". Также монстр, будь он хоть в 10 километрах от игрока, должен бегать туда-сюда (ну как обычные монстры в думе), и не останавливаться по причине "надо вырубить модель", ибо это изменение геймплея
Поэтому мне пока непонятно, как при обозначенных мной условиях реализовать отключение модели.
И да, не увидел ответа на вопрос, а как динлайты отключать для конкретного актора? И что, кроме модели, динлайтов и партиклов, есть еще ресурсоемкого у акторов, что целесообразно отключать?
alekv:
Да я имел ввиду что скрипт дистанцию лучше юзать в декорейте, а функцию в ACS скриптах
Функции разве можно вызывать напрямую из декорейта?
alekv:
Выгода.. чище в мап скриптах проблема объединения бардак в скриптах По моему это только для этого и сделано.. что бы все основные функции константы переменные и т.д. которые часто используем и которые не привязаны к уровню были где-то далеко и не мешали скриптовать в мап скриптах. Опять же ИМХО
не, это понятно, я вел речь о скриптах, которые не привязаны к конкретной карте, а должны работать "на любой карте на любом ваде". Вот допустим, ты хочешь сделать модели, партиклы и т д (с целью, чтобы с этими моделями играть на чужих картах), и у тебя есть несколько ACS файлов:
и именно в таком случае есть 2 противоположных варианта (это не все варианты, но я рассматривал строго их):
вариант 1: создаем новый файл main___my_super_mod.acs, и в нем через include перечисляем все остальные ACS-ки вариант 2: каждая ACS-ка - отдельная библиотека
а то, что мап скрипты целесообразно в отдельных файлах, я согласен
alekv:
проблема объединения бардак в скриптах
не очень понял понятие "бардак в скриптах". У тебя ж разные ACS-файлы (т.е. бардака нет, все читабельно), просто компилиться все будет в один результат
ZZYZX:
Где-то я уже приводил пример скрипта, сравнивающего текущую карту с заданным номером, для использования с CallACS().
Это наверное лучше не у меня спрашивать т.к. я точно не знаю.. Но есть догадки что TNT1A0 это прозрачная картинка, а NULLA0 это просто пустота, 0, ничего нет.. к такому выводу я пришел из-за такого случая: Spawn: NULL A 0 //если NULL будет первым кадром гозза ругнется и не загрузится TNT1 A 0 //гозза не ругается если tnt1 будет стоять первым кадром..
Может я не прав, впрочем никогда особо не задумывался, я время от времени юзаю NULLA0 в разных случаях как мин. из-за подсветки в слейде3 а разница между "####" вообще не знаю(т.к. по моему никогда не юзал это), самому интересно было бы знать)
theleo_ua:
для предметов и декора такое вполне приемлемо, а вот с монстрами придется париться насчет "не изменять геймплей" и "моментально восстановить модель при телепортации игрока в локацию рядом с монстром, причем восстановить строго текущий фрейм монстра". Также монстр, будь он хоть в 10 километрах от игрока, должен бегать туда-сюда (ну как обычные монстры в думе), и не останавливаться по причине "надо вырубить модель", ибо это изменение геймплея Поэтому мне пока непонятно, как при обозначенных мной условиях реализовать отключение модели.
Да, мне это тоже не понятно, т.к. у меня в моде еще нет монстров(1 только тестовый..) потому я не задумывался, но как время придет думаю буду копать в стороне SetActorProperty(APROP_RenderStyle).. т.е. скрипт acs будет чекать дист. от монстра до игрока и если игрок далеко, то вырубать ему рендер если близко опять включать. Но это мои догадки, в этой стороне я буду искать в 1ую очередь когда дело дойдет до монстров. А вот к примеру у меня есть объект который летает по горизонтали, вертикали, по зигзагу и т.д. средствами декорейта, я ему сделал вырубание путем спавна тхинга пустышки как точки с которой он начинает движение и когда игрок далеко, объект вырубается скриптом distance, как я писал выше, объект перестает летать, рендерится, а когда игрок подходит ближе объект начинает движение с тхинга пустышки.. в принципе движение не сбивается, нормально работает, но для монстров хз.. наверное такое не очень подойдет.
theleo_ua:
И да, не увидел ответа на вопрос, а как динлайты отключать для конкретного актора? И что, кроме модели, динлайтов и партиклов, есть еще ресурсоемкого у акторов, что целесообразно отключать?
Динлайты выключаются путем переключения стейтов(в таком случае испускать свет должен 1 кадр или больше, как это делается описал на пред. странице или в вики посмотри GLDEf) либо просто подменяем актора испускающего дин. лайт на пустышку когда игрок далеко. Что еще отключать.. я не знаю. Вот если бы можно было отключать 3д полы и слопы когда игрок далеко, вот это да.. было бы круто.. но тогда может и лагало бы сильнее хД
theleo_ua:
и именно в таком случае есть 2 противоположных варианта (это не все варианты, но я рассматривал строго их): вариант 1: создаем новый файл main___my_super_mod.acs, и в нем через include перечисляем все остальные ACS-ки вариант 2: каждая ACS-ка - отдельная библиотека а то, что мап скрипты целесообразно в отдельных файлах, я согласен
Я же писал мое мнение что это сделано для того что бы модер кодер не путался в собственной писанине. Удобнее же спрятать разные скрипты такие как дистанция в отдельной либе и просто подключать это все дело когда надо строчкой инклюде.. а бардаком я называю когда в 1ом файле все скрипты мода\игры.
думаю буду копать в стороне SetActorProperty(APROP_RenderStyle).. т.е. скрипт acs будет чекать дист. от монстра до игрока и если игрок далеко, то вырубать ему рендер если близко опять включать. Но это мои догадки, в этой стороне я буду искать в 1ую очередь когда дело дойдет до монстров.
Идея интересная, но возникают вопросы:
1) Renderstyle "none" дает 3дмодели полное отсутствие загрузки железа? Т.е. по уровню освобождения ресурсов это полная копия TNT1 A 1 ?
2) Если толпе объектов добавлять скрипты, которые постоянно (и каждый тик) чекают дистанцию до игрока, это не вызовет глюков? Т.е. у нас один и тот же скрипт будет вызван и "вечно" запущен кучей объектов
alekv:
Динлайты выключаются путем переключения стейтов(в таком случае испускать свет должен 1 кадр или больше, как это делается описал на пред. странице или в вики посмотри GLDEf)
ага, я забыл что динлайты привязываются к фреймам, тогда да, решение очевидно
alekv:
Что еще отключать.. я не знаю. Вот если бы можно было отключать 3д полы и слопы когда игрок далеко, вот это да.. было бы круто.. но тогда может и лагало бы сильнее хД
1) Renderstyle "none" дает 3дмодели полное отсутствие загрузки железа? Т.е. по уровню освобождения ресурсов это полная копия TNT1 A 1 ?
Тут еще не знаю, это будет видно при тестах и как мне кажется что это не копия TNT1)
theleo_ua:
2) Если толпе объектов добавлять скрипты, которые постоянно (и каждый тик) чекают дистанцию до игрока, это не вызовет глюков? Т.е. у нас один и тот же скрипт будет вызван и "вечно" запущен кучей объектов
Думаю врятли.. мне кажется гозза больше тратит на рендер вертексов 3модели и ее текстуры чем какой-то ацс скрипт. Тем более вот ZZYZX писал:
ZZYZX:
У меня есть карта, где эта функция используется приблизительно 320 раз за тик, и ничего не лагает. У меня есть другая карта, где эта функция используется приблизительно 500 раз за тик, и опять же ничего не лагает.
Пытаюсь сделать кастомное меню, которое можно вызывать (или вызывается само) посреди игры. К примеру, инвентарь (двух типов), интерактивная рация, меню "конец игры". Честно говоря, кроме желания, на этом все. Нет никаких примеров, не от чего отталкиваться. У кого нибудь есть наглядный пример меню, пункты в котором добавляются/удаляются в зависимости от наличия или отсутствия предметов в инвентаре у игрока? Или мне стоит забыть про MENUDEF, и работать только через ACS скриптинг?
Пытаюсь сделать кастомное меню, которое можно вызывать (или вызывается само) посреди игры. К примеру, инвентарь (двух типов), интерактивная рация, меню "конец игры". Честно говоря, кроме желания, на этом все. Нет никаких примеров, не от чего отталкиваться. У кого нибудь есть наглядный пример меню, пункты в котором добавляются/удаляются в зависимости от наличия или отсутствия предметов в инвентаре у игрока? Или мне стоит забыть про MENUDEF, и работать только через ACS скриптинг?
Про MENUDEF можешь сразу забыть, его кастомизация близка 0, там кроме как написать свой текст да поменять его место ничего толком нельзя да и то не везде это можно сделать.. ну и картинку в main menu можно свою поставить с маленьким разрешением онли.
Вот в ацс больше шансов, но опять без функции вызова консольных команд(или что подобного) нельзя закончить игру, начать новую, открыть окно сохранения и т.д. но теории можно сделать переключение уровня и завершение игры путем переключения на спец. левелы.. ну и все в таком духе, тут уже зависит от того что тебе надо. Про рацию вообще не понял.
Пример - система "кодек" в играх серии Metal Gear Solid. Посередине частота, которая в этом режиме изменяется, к примеру, кнопками управления. И, в зависимости от условий, происходит определенный диалог (тут уже не важно, через страйфовскую систему диалогов, или же анимированный сиквенс сделанный через ACS)
Правила 
Поиск
