Шило на мыло же (я пробовал и без "==1"), и я как раз и говорил о том что && возвращает ТРУ для любого не нулевого значения, мне же надо чтобы ТРУ возвращалось ТОЛЬКО если оба значения из диапазона.
Да, конструкция вызывается из снаряда, в итоге хочу чтоб последний "слепил" игрока если тот поймает этот снаряд прямо в лицо (эдак в конусе fov под 120-160 градусов). Офк можно тупо прописать A_JumpIfTargetInLOS в самого игрока но я бы не хотел выводить код за пределы актора снаряда.
Возможно я туплю но разве флаги не меняют поведение просчёта угла и точки отсчёта?
GAF_RELATIVE: Normally this function returns the absolute angle of the line from the caller to the pointer (i.e., relative to facing due east). This flag has the function return the angle relative to the caller's angle instead.
GAF_SWITCH: Checks the line going from the pointer to the angle instead. If used with GAF_RELATIVE, will also be relative to the pointer's angle not the caller's.
ЭДИТ:
Полагаю что это элементарно лечится через вывод 1\0 посредством SetResultValue, но проблема в том что оная робит только со скриптами.
Поэтому вопрос сводится к: "можно ли на декоре записать возврат конкретного значения инт-ф-ции как ТРУ\ФАЛЬС?"
Что не так работает в моём коде? Тебе нужна проверка на "dist < 40", "angle > -60" и "angle < 60" одновременно, так? Тогда так, как я скидывал выше, должно работать правильно.
Я, честно говоря, часто не понимаю твоего способа выражения мыслей. По-моему, иногда части твоего сообщения противоречат друг другу, а иногда и вовсе не относятся к делу и выглядят как случайно добавленные строки.
Actor Blinder : CustomInventory
{
+INVENTORY.ALWAYSPICKUP
Inventory.MaxAmount 0
States
{
Spawn:
TNT1 A 1
Loop
Pickup:
TNT1 A 0 A_SetBlend("00 07 03",1.00,350)
Stop
}
}
Actor Blinder выдаётся всегда; выходит что анон ф-ция возвращает всегда ТРУ. И похоже что поведение условия работы оператора полностью укладывается в примечание к оному (любое значение отличное от 0 всегда рассматривается как ТРУ).
Что-то всё ещё непонятно?
И похоже что поведение условия работы оператора полностью укладывается в примечание к оному (любое значение отличное от 0 всегда рассматривается как ТРУ).
Это означает, что если ты напишешь "3 && 60", то результат будет "1", то есть true.
Но ты не пишешь 3 && 60, ты пишешь (GetDistance(...) <= 60), то есть ты через && объединяешь результаты сравнений таким образом, чтобы все из них проходили.
В этой части у тебя всё верно.
Скорее всего неверна у тебя логика, то есть вызываемые функции возвращают не то, что ты думаешь. Попробуй добавить Console.Printf() или A_Log() с целью залоггировать результат GetAngle или GetDistance.
JSO x, ZZYZX Ох, ребьзь, простите идиота... ну конечно, я же сравниваю значения а не тупо вывожу их. Да, вариант ДЖСО работает и похоже косяк где-то в ином месте.
А не подскажете куда именно вписать A_LogFloat() и что указывать внутри неё?
Почему MageStaffFX2 (aka звезда Bloodscourge посоха) будучи ударенной Disc of Repulsion немедленно записывает игрока в свой трэйсерфилд и соответственно мгновенно перенацеливается на стрелка?
Есть какое-нибудь рациональное объяснение сему феномену или этот баг зарыт где-то глубже на уровне кода?
Вот я мало ковырялся в хексене и его мутных специализированных фичах, поэтому могу фигню сморозить.
Насколько я понял, диск оптом меняет поинтеры у всего, что попало в радиус действия: текущий таргет пишется в трасерфилд, игрок пишется в таргетфилд. Сделано это для того, чтобы условный ревенант получил по морде своим же A_SeekerMissile, который наводился бы на ревенанта, будучи как бы переиспущенным игроком.
Другое дело, если игрок сам стреляет чем-то A_SeekerMissile. Такая ракета, попав в радиус действия, мгновенно записывает текущий таргет (игрока) в трасерфилд, и его же в таргетфилд. Получается казус: ракета, испущенная игроком, на него же и нацеленная. Такая ракета будет летать вокруг него (и сквозь него) как назойливая муха, пока не лопнет. Что мы и наблюдаем на видео. (Звезда юзает модификацию A_SeekerMissile: A_MStaffTrack, которая, если трасера изначально нет - с вероятностью 20% попытается получить его в пределах 10 пунктов.)
Загадка тут в другом. Disc of repulsion срабатывает только на снаряды с флагом CANBLAST, а у MageStaffFX2 этого флага в оригинале нет. (На видео есть характерные искорки BlastEffect, которые совершенно точно говорят нам о срабатывании диска.) Значит одно из двух: либо какого-то лешего этот флаг у звезды появился, либо проверка на CANBLAST сломалась где-то на уровне движка (или зскриптовых воздействий на движок).
Ну касаемо того почему наворачивает круги это-то понятно, я же сразу уточнил что в трэйсерфилд снаряда записывается игрок, при этом не переставая быть в таргетфилде также.
Насчёт CANBLAST полагаю что для снарядов флаг по умолчанию "+" если явно не прописан "-", но при этом почему-то скрыт. Просто все снаряды без явно прописанного CANBLAST всё равно отбрасываются.
Причина же записи игрока в трэйсер снаряда по-прежнему не ясна, хотя версия с диском меняющим поинтеры была интересна.
По результату тестов получается что баг хардкодед где-то в самой MageStaffFX2: снаряд унаследованный от снаряда но БЕЗ флагов И БЕЗ вызова A_MStaffTrack ведёт себя так же; при этом вторым условием является необходимость вызова A_SeekerMissile.
P. S.
Если это не починят то открываются довольно интересные перспективы. Например запил оффенсив-шилдов. P. P. S.
А стоит ли вообще репортить на гоззу?
Насчёт CANBLAST полагаю что для снарядов флаг по умолчанию "+" если явно не прописан "-", но при этом почему-то скрыт. Просто все снаряды без явно прописанного CANBLAST всё равно отбрасываются.
Вот не должно быть этого. Projectile combo для дума и хексена немножко разные, но этот флаг туда не входит. По крайней мере если верить здум вики.
Косяк может быть в трёх местах:
1. Если переписал что-то в ZScript virtual function. (Проверяется отключением зскрипта).
2. Если переписал что-то в самой MageStaffFX2. (Проверяется пулянием чего-то на 100% свежего и ниоткуда не унаследованного).
3. Если в билде гоззы что-то отвалилось.
Вообще рекомендую провести эксперимент. По-быстрому скрафтить тестовую пушку, пуляющую девственный RevenantTracer, который ко всему этому хексену вообще не имеет отношения. Если диск сработает и на него - значит точно косяк гоззы. Для надёжности стоит проверить на какой-нибудь старой версии здум.
Если это не починят то открываются довольно интересные перспективы. Например запил оффенсив-шилдов.
Да в общем-то не имеет значения, починят или нет. Можно просто прописать снарядам, чтобы они сразу после спауна копировали таргет в трасерфилд, и тогда они будут до бесконечности виться вокруг выстрелившего. А ещё можно замутить моднейшее ёба-оружие, чтобы фаерболы дооолго накапливались, летая вокруг игрока, как вокруг зловещей анимешной девочки, а потом внезапно по мановению переключающей трасер волшебной палочки разом всей кучей летели в цель. Пафоса будут просто полные штаны!
Вот не должно быть этого. Projectile combo для дума и хексена немножко разные, но этот флаг туда не входит. По крайней мере если верить здум вики.
Monsters with the BOSS or DONTBLAST flags are normally unaffected; as well as any actor that isn't a monster, player, or projectile, unless they have the CANBLAST flag.
Видимо всё же КЭНБЛАСТ это какой-то "крипто"-флаг, не входящий в комбо, нигде явно не прописанный но по умолчанию активный для нон-босс монстров, игрока и снарядов. Ну или на вики его банально забыли упомянуть в комбо. ;|
Ваще-т это вполне себе ванильный баг (я это отметил в описании под видео), но при этом "успешно" портированный. :| Просто я предположил что воспроизведение бага при портировании оного могло оставить след где-то на поверхности, на уровне декора.
Так что 3 вариант исключается как первопричина, а про 1 и 2 я не в курсе, тем более что лично я ничего не менял. И да, не уточнил выше но, тем не менее актору не родственному СтаффМиссилю не удаётся воспроизвести аналогичное поведение даже при копировании всех параметров за исключением натив A_MStaffTrack, ну и собс-но наследования. Возможно не вполне тщательно экспериментировал.
А вот за идею лайкушечку! ^_^
EDIT:
Наверное что-то типа:
Actor SeekerShieldMissile
{
+SEEKERMISSILE
Projectile
States
{
Spawn:
TNT1 A(AAA) 1 //Чтобы успели вылететь на некоторое расстояние от стрелкА для формирования радиуса "орбиты" вокруг него, коррелирует со скоростью снаряда
TNT1 A 0 A_RearrangePointers(AAPTR_DEFAULT,AAPTR_DEFAULT,AAPTR_TARGET)
ChargeUp:
TNT1 A 0 A_JumpIfInTargetInventory("SeekerCounter",<ко-во снарядов>,"PreRelease")
ABCD ABCDEFG № A_SeekerMissile(х,у) //"Косметические" значения наведения
TNT1 A 0 A_SpawnItemEx("SeekerShieldMissile",-5,0,0,0,0,0,0,SXF_ABSOLUTEVELOCITY|SXF_NOCHECKPOSITION)
TNT1 A 0 A_GiveToTarget("SeekerCounter")
Loop
PreRelease:
TNT1 A 0 A_RearrangePointers(AAPTR_DEFAULT,AAPTR_DEFAULT,AAPTR_NULL)
TNT1 A 0 A_TakeFromTarget("SeekerCounter") //Обнуляем счётчик снарядов игрока\монстра
//TNT1 A 0 A_Warp(AAPTR_TARGET,0,0,Height/2,0,WARPF_NOCHECKPOSITION|WARPF_COPYINTERPOLATION|WARPF_BOB) //Опционально можно собрать в кучку перед залпом
Release:
ABCD ABCDEFG № A_SeekerMissile(х,у) //"Науськивание" всех снарядов в одну цель ИЛИ
//ABCD ABCDEFG № A_SeekerMissile(х,у,SMF_LOOK,256,100) //Роспуск всех снарядов в свободную охоту
Loop
<...>
}
}
Возможно ли на декоре сделать так чтобы монстры реагировали на абстрактный актор (ну пускай даже на монстра) как на игрока?
Т. е. чтобы при обнаружении (хотя бы визуально) такого актора сразу на него агрились, но при этом оный не мешал бы потенциальному инфайтингу между монстрами.
Детали проблемы:
Скрытый текст:
Дело в том что столкнулся с серьёзной проблемой шилда для убер-волыны: он работает как часы... за исключением милишников, - они по-прежнему пытаются ломать лицо игроку игноря шилд. Причём проблема не в безопасности игрока а в том что при таком раскладе шилд будет перманентно неуязвим против мили атак вместе с игроком.
Кароч нужно как-то заставить монстров таргетить именно шилд, но юзать Thing_Hate не хотелось бы (бо тид + сразу поднимет на уши всех в радиусе) а A_AlertMonsters к сожалению не пашет на тех у кого уже есть цель.
Коть, ты повторяешься. Без обид, но это уже раздражает.
Я прекрасно понимаю возможности зскрипта, но если бы я умел в него то таких вопросов бы не задавал.
Ок, отвечу по другому, на декоре это сделать нельзя. Теперь ты без щита в жертву декору. Стало лучше?
Я пишу про зскрипт ("повторяюсь") не потому, что мне по приколу. А потому что тебе по сути нужно сделать две фичи одновременно: общий счётчик здоровья для всего щита (кусают одну часть, ослабляется весь щит), и поведение вида - если любого монстра ударило щитом, насильственно переставить ему таргет. Или переделать проджектайлы щита таким образом, чтобы они не были проджектайлами и не были связаны с игроком (потому что это такая логика у монстров, что если их дамажит проджектайлом то они будут атаковать именно игрока). Ещё на зскрипте можно определять дамаг по игроку и переносить его на щит. DamageMobj если что. Ни первое, ни второе сделать на декоре невозможно.
Вообще монстры агрятся на любое + FRIENDLY, но сомневаюсь что тебе это поможет, там по идее всё равно игрок в приоритете, будут баги.
Мог бы сразу вынести вердикт касаемо декора, а не снова приплетать зскрипт. )
Про здоровье не понял. Мой шилд это 1 актор с единым запасом хп со всех сторон. И более того, на данный момент он никому не отвечает поскольку я ещё не решил какова должна быть в итоге реакция шилда на входящий урон.
и поведение вида - если любого монстра ударило щитом, насильственно переставить ему таргет.
Это-то НЕ проблема, проблема в том что просто так шилд НЕ кусают а таргетятся на игрока; если же скрыть игрока инвиз флагом например, то мобы вообще перестанут кого бы то ни было чейсить.
Я ставил рефлектив флаги щиту и в этом случае мобы с комбо атаками переагривались непосредственно на щит, но это совершенно не работает с пинки например, плюс надо постоянно соблюдать дистанцию чтобы монстр с комбо-атакой не подобрался через щит слишком близко к игроку.
Ещё на зскрипте можно определять дамаг по игроку и переносить его на щит. DamageMobj если что.
Хороший костыль, да и виртуально возможный на декоре с помощью алгоритма Смертоносца. Вот только:
а) придётся править самого игрока, что совсем не труЪ для единичной волыны. :/
б) это не труЪ редирект урона, а только эмуляция.
Про здоровье не понял. Мой шилд это 1 актор с единым запасом хп со всех сторон. И более того, на данный момент он никому не отвечает поскольку я ещё не решил какова должна быть в итоге реакция шилда на входящий урон.
а. Я думал много маленьких. Тогда сделай много маленьких, и пусть щит естественным образом угасает при столкновении с монстрой или ракетами ) По частям.
Правила 
Поиск
Да, вариант ДЖСО работает и похоже косяк где-то в ином месте.
Причём проблема не в безопасности игрока а в том что при таком раскладе шилд будет перманентно неуязвим против мили атак вместе с игроком.