Malandrinus

@Zander_driver, серверный класс | клиентский класс | clsid (скриптовая| class | (С++) | (С++) | таблица) | (ltx) | CSE_ALifeItemAmmo | CWeaponAmmo | wpn_ammo_vog25 | A_VOG25 | Граната для подствольника "Костёр" CSE_ALifeItemAmmo | CWeaponAmmo | wpn_ammo_og7b | A_OG7B | Заряд для РПГ CSE_ALifeItemAmmo | CWeaponAmmo | wpn_ammo_m209 | A_M209 | Граната для натовского подствольника CSE_Temporary | CExplosiveRocket | wpn_grenade_fake | G_FAKE | ВрЕменная граната

В masm32 старая версия ассемблера. Нужен от последних версий Visual Studio.

@*Shoker*, то, о чём ты говоришь, - называется перспективной проекцией. В пространстве задаётся сектор, который как раз и задаётся тем самым FOV. Изображение на экране формируется центральной проекцией. Примерно как на этой картинке. Видно, что то, как труба будет спроецирована на экран, зависит как раз от FOV. Чем FOV будет меньше, тем перспективное искажение тоже будет меньше.

Господа, просьба как-то прояснить ситуацию с багом с получением позиции костей. Есть этот баг или нет - вопрос надо окончательно закрыть. Как уже говорил, я ничего не вижу, но это не значит, что бага нет. Меня уверяют, что эффект от бага видно невооружённым взглядом, там и здесь что-то работает неверно. Если так, то убедительная просьба как-то это продемонстрировать: скрин, результаты конкретных измерений, что-то, что можно предметно анализировать.

, для начала, позиция не одинаковая. bone_omni смещена от колбы наружу и довольно прилично смещена. Второй момент, а насколько рандомная позиция? Эта лампа - одна из немногих, которые находятся под физической схемой ph_oscillate, т.е. их раскачивает как маятник и значит положение костей постоянно меняется. В данном случае несильно меняется, в первом-втором знаке после запятой, но тем не менее значение будет на самом деле разное в разные моменты времени.

@Real Wolf, функция radius по идее должна работать только для объектов с визуалом, а те, у которых шейп (любой, а не только сфера) - зоны, аномалии и т.п., визуала не имеют, поэтому вероятно и вылет. Функция эта, совместно с точкой - физическим центром объекта используется движком в алгоритме проверки касания. Т.е. когда физический центр объекта находится ближе чем этот радиус от внешнего края составного шейпа, значит объект касается зоны. Насчёт некорректной работы функции bone_position. Я не вижу никаких сбоев, у меня она работает как часы. Проверьте, не передаёте ли этой функции неверное имя кости, в этом случае возвращаемый вектор походу содержит случайный мусор. Но это однако не баг, а так и должно быть. Особенно это может касаться ламп. Лампы могут не иметь визуала и соответственно костей. Что в этом случае вернёт эта функция - я даже затрудняюсь сказать. Может как раз из-за этого и странности.

Стилистика описания хромает, как и логическая связность. Модификация не разгадывает тайны, тайны разгадывает игрок в лице главгероя. В первом предложении говорится о "легендарном" сталкере, в следующем - что игрок будет "обычным сталкером". Сюжет позволит стать сталкером... Не сюжет позволяет, а игра. А про сюжет говорят: "по сюжету игрок будет тем-то и тем-то". ...со множеством целей и загадок. Сталкер со множеством загадок... это как? ГГ будет ходить и загадывать загадки? Множество целей... Вроде выше говорилось об одной цели, разгадке тайны ЗО. Будет ещё множество целей не меньшего калибра? Это не считая того, что описание - типичный случай: "новый сюжет, всё будет круто" + стандартный набор фишек + скрины ни о чём. Ну сколько можно? Если будет новый сюжет, то почему бы вместо рекламных заявлений не дать пару параграфов завязки? Это бы дало больше, чем всё что сейчас в шапке вместе взятое.

@Stalkersof, инфопорции же не просто так выдаются. Их наличие/отсутствие влияет на всю игру, и самое главное - сложно заранее предсказать как именно влияет. Чтобы предсказать, надо уверенно и досконально знать их все и что каждая делает: как влияет на диалог каждого непися, как влияет на работу рестрикторов и логики. Кроме того, многие рестрикторы не просто выдаются, а что-то при этом делают: срабатывает какой-то код в частности, который спавнит какие-то объекты, удаляет что-то, меняет отношения и т.п.. Есть большая вероятность, что при выдаче всех инфопорций разом будут вылеты, поскольку подразумевается, что ГГ находится при этом где-то в конкретном месте на другом уровне, а не на Кордоне. Реально проще и надёжнее сделать так, чтобы этого всего не происходило вовсе, т.е. просто удалить источник сюжета как таковой: диалоги, рестрикторы с логикой, неписей целиком. Я как-то пару раз пробегался по игре, используя читовый телепорт. Т.е. прямо из коморки Сидора уходил гулять прямо до Припяти. Где-то конечно срабатывают сюжетные триггеры, и неписи что-то хотят по сюжету, но в принципе видно, что если это убрать, то как раз и получается почти фриплей.

Можно убрать выдачу записей из инфопорций. Других способов нет, поскольку для записей в журнале нет никаких скриптовых средств. Вопрос такой. Под "вырезанием" сюжета ты вероятно имеешь в виду "ускоренную промотку". Я бы не сказал, что это вообще годный способ для вырезания сюжета, поскольку выданные инфопорции имеют далеко идущие последствия. Да и какой смысл? Проще перебрать сюжетных неписей и удалить у них сюжетные диалоги (или их самих). Ну ещё убрать в аллспавне сюжетные рестрикторы. Таким образом ты уберёшь все возможные источники выдачи сюжетных заданий, что собственно и уберёт сюжет. На мой взгляд, это проще и работы меньше, нежели собрать информацию о всех инфопорциях.

Может кто-то уже знает, а я только сейчас раскопал вот какую штуку. Оказывается можно без проблем искать в аллспавне объекты для их последующего спавна с помощью функции alife():create(spawn_id). Здесь spawn_id - это порядковый номер секции в аллспавне. Секции эти тасуются при каждом изменении аллспавна, поэтому этот идентификатор меняется, и спавнить таким образом вроде как считалось нецелесообразным. Однако, как выясняется, этот номер можно определить. Для этого есть специальная метка, во многом схожая с использованием story_id, которая называется spawn_story_id. Это поле можно задать в секции в аллспавне совершенно точно также, как задаётся story_id, для номеров можно завести строковые обозначения, которые регистрируются в файле game_spawn_story_ids.ltx и соответственно попадают в таблицу spawn_story_ids. Нумерация там не пересекается со story_ids. В оригинале игры это всё вообще не используется. Теперь, если таким образом пометить какой-то объект в аллспавне, то его spawn_id можно найти с помощью alife():spawn_id(spawn_story_id). Т.е. задаём число - получаем число. Что важно, что объекта при этом может и не быть. Работает это таким образом, что при старте игры все помеченные таким образом объекты сохраняются в отдельной базе данных (точнее, сохраняются их spawn_id) и эта база затем в неизменном виде сохраняется в сейве. В итоге, можно организовать с малыми хлопотами следующий алгоритм. Допустим, нам нужен переход, который должен появиться по условию (или даже появляться и исчезать много раз по условию), и мы хотим этот переход сделать с помощью аллспавна. Поступаем так: 1. Создаём переход в аллспавне как обычно. 2. Метим его одновременно метками spawn_story_id и story_id. Пусть это будут story_ids.some_level_changer и spawn_story_ids.some_level_changer. Обращаю внимание. Я здесь дал меткам похожие имена, но это разные числа, никак друг с другом не связанные. 3. При запуске игры объект удаляем (к примеру, если не хотим иметь его с самого начала игры). Для удаления нам нужен реальный серверный объект, ищем его так local lc = alife():story_object(story_ids.some_level_changer) и удаляем как обычно alife():release(lc, true) 4. Далее, при наступлении какого-то условия, когда нужно создать этот переход обратно, поступаем так: local spawn_id = alife():spawn_id(spawn_story_ids.some_level_changer) alife():create(spawn_id)

@Zander_driver, не знаю, имеет ли это значение в этом конкретном случае, но напомню, что диалог таким образом формируется не просто в момент вызова этой функции generate_dyn_dialog, а строго при первом вызове этой функции. При всех последующих вызовах вплоть до выхода из программы (т.е. в том числе и после загрузки другого сейва) будет использоваться уже сформированный диалог. Я об этом расписывал подробнее здесь (там в примечаниях под спойлером). Это так на всякий случай напоминаю, поскольку этот факт является причиной ошибок, когда люди ожидают динамического формирования диалога всякий раз, а он на самом деле не меняется.

xuyc, 1.1 "фикс оффлайнового движения неписей" закомменчено, а значит либо не работает либо был экспериментальный фикс. По-любому, уже не помню что это и зачем. 1.2 В функции CUIComboBox::SetListLength стояла проверка на аргумент и происходил вылет при любых ненулевых значениях. Очевидно, что должно быть с точностью до наоборот, нулевая длина списка не имеет смысла и должна вызывать вылет. 2. По идее должно работать. Насколько стабильный вылет?

@Rosad, В Lua как таковом нет таких возможностей. Lua предназначен для встраивания в хост-программу, которая уже и должна делать такие вещи, как например отлавливать нажатия клавиш. Вот как это делается к примеру в движке сталкера: движок ловит нажатия, дальше уже вызывается скриптовый колбек. Если же надо сделать это в Lua в его самостоятельном варианте, то придётся добавлять туда такие возможности самому. Причём это будет разумеется делаться по-разному для каждой платформы. Под виндой надо будет сделать Lua-обёртку над функциями API типа GetKeyState.

Народ, а чего это вы здесь оффтоп развели? Какое отношение кровососы и аптечки имеют к проекту x-ray extensions?

Храни состояние в кастомдате. Кастомдату можно записать нетпактетами, а читать можно даже без нетпакетов. При записи кастомдаты можно не заморачиваться на перевод в оффлайн/онлайн. Клиентский объект не заметит этих манипуляций с серверным объектом. Только не используй чтение кастомдаты из клиентского объекта, поскольку она не будет синхронизироваться с серверным.

, там действительно текстура с "дырками". Альфа-каналом это называть достаточно громко, поскольку там всего лишь маска. Я бы не сказал, что это оптимизация "в кавычках". Сейчас там всего лишь бокс с натянутой текстуркой, что потенциально даёт всего 12 треугольников. На полную же геометрию нужно много десятков, если не сотен треугольников. Но что касается тумана, то не видно особенных причин, чтобы эта геометрия исключалась из затуманивания. Это совершенно нормальная геометрия для шейдера отложенного затенения (поскольку здесь нет прозрачности, а именно что просто маска). Скорее всего по недосмотру у шейдера не включён флажок тумана или возможно выбран неверный шейдер.

Понятия не имею. Надо смотреть в скрипт. Если вообще что-то начисляется, то либо во фразе диалога, где задание сдаёшь, либо в скрипте, который выполняется при сдаче задания (тег задания function_complete)

VVV32768, не совсем понятно, с чем ты не согласен. Если игрок уже находится на уровне и этот скрипт уже сработал, то второй раз он не сработает, пока не уйдёшь с уровня и не вернёшься на него ещё раз. С этим не согласен?

Откуда взяли? И тогда делали бы уж и новые скрины с ними.

Мне кажется или там лучи от солнца?

AndreySol, 1. Репутация - это отдельное число, собственно репутация ГГ в глазах общественности. Ближайшим аналогом является карма в фоллауте. Благосклонность - это смотря что ты имеешь в виду. Есть personal goodwill, это личное отношение одного персонажа к другому. Есть community goodwill, соответственно отношение группировки к конкретному персонажу, есть ещё отношение группировки к группировке. Всё это плюс добавка от ранга складывается в одно число - итоговое отношение. Если оно больше нуля - персонаж "позеленеет", меньше - "покраснеет" и станет атаковать. Ноль - будет серый. Загляни в этот файл. config/creatures/game_relations.ltx Там в комментах разрабы написали полную формулу и там же все таблички, по которым вычисляются части этой формулы. 2. По-моему, любой эффект от задания надо прописывать в этом задании явно, как собственно эффект или эффект от фразы при сдаче задания. Впрочем, наверняка этого утверждать не буду, поскольку с заданиями и особенно с гулагами почти не разбирался. Заход на уровень - это попадание туда любым способом. Не помню только наверняка, сработает ли при повторном заходе. Вроде как сработает тоже. Но если уже находишься на уровне, то загрузка на этом уровне не приведёт к повторному срабатыванию. В общем неудобная и бесполезная штука - эти скрипты уровня.

Скрипты уровня использовали сами разрабы, но для специфических целей. Судя по остаткам отладочного кода в ТЧ, этот способ использовался для отладки сюжета, когда ты скачешь на уровень, а в этом скрипте выдаются все нужные инфопорции, чтобы продолжить игру с нужной точки. Вероятно, это использовалось в связке с вырезанной консольной командой перехода на другой уровень. В обычной игре от этой фишки в целом мало толку. Мне по крайней мере это ни разу не пригодилось. В самом деле, что такого может потребоваться делать при каждом заходе актора на какоё-то уровень? Да и как правильно здесь замечали, нынче много способов сделать это без таких извращений.

А, я значит недопонял. Да, размазанных источников света в x-ray нет, только точечные. В ЧН/ЗП на детекторах кстати есть источник света, освещает его когда моргает лампочка. На мой взгляд, этого здесь было бы вполне достаточно, поскольку метка имеет небольшой размер. К сожалению, прикрутить к оружию свой источник света без влезания в движок тоже не выйдет. P.S.: Коллиматор вообще-то не должен освещать. Демаскирует же, освещая морду стреляющего. А на картинках на одной явно рекламный фотошоп, а на другой просто размытая метка.

Прошу прощения за оффтоп, но не могу не спросить. Что же за сияние такое от текстуры исходит? Пиксели на мониторе начинают излучать нечто отличное от RGB цвета?

@topdog, такой рак надо банить за грубость и хамство, а не потакать, выкладывая ссылки. Уже....