в логе у нас появляется такая последовательность:

critter_attempt_placement в маппере работает корректно только при первом заходе на карту, в самой игре нет.
critter_attempt_placement/override_map_start — работает если их применять только в map_update.
это тесты для DUDE, для криттеров с critter_attempt_placement вроде проблем с этим нет.

а set_map_start — вообще какой-то не рабочий что-ли (тупо не меняет координаты карты еще и в дебаг-логе ошибку выдает) или я не понял как и где его можно правильно применить.

Отправлено: 13 мая 17 18:25
Вот еще тест с использованием добавочного криттера.

скрипт карты тот-же только без critter_attempt_placement
Просто заходим на карту из другой карты на координаты 11000, лог такой:

Вот о чем я говорил, не можем получить в map_enter_proc координаты игрока при заходе на карту, также сразу не можем получить и в map_update_proc, а только со второго прохода.
Можно с этим что-то сделать, или это специфика работы такая? — и нафига нужен этот двух проходный map_update может один удалить :P
а еще у криттеров обработчик start тоже всегда два раза под ряд выполняется.

И кстати заметил что стартовые координаты всегда открывают на авто-картах кусочек карты, как будто игрок там уже побывал — видимо по причине того что игрок всегда заходит на стартовые координаты, а потом его перемещает куда нужно.

Вот пример с переопределением координат при первой загрузке и при заходе через храм (если заходить через деревню, то используются координаты сетки), artemple.ssl:

Всё верно.

tile_num(dude_obj), не? Если значение по адресу 0x631D30 не равно 0, то гг будет перемещён в это место.

Я же специально привёл пример с уже готовыми отладочными строчками — достаточно добавить и проверить (начать новую игру, зайти в храм, потом выйти), чтобы на выходе получить (с настроенным map_update):

а чего делал этот apply_heaveho_fix
и как ты исправил перк? :)

Чего там за баг такой был при подсчете в item_count_ ?
вроде как проблем с подсчетом не замечал, фильтр нормально работал и без фикса, единственное с сумками проблема.

Ну вот видишь можешь, а говорил про какой-то несовместимый int

Мелкими улучшениями занимаюсь :-p

Описание для F1 звучит так:

А для F2 более развёрнуто:

В данных перка есть защита от его взятия если сила превышает 8, однако с помощью эксплоита химии/радиации можно (при 10 силы) понизить до 4 и взять 3 уровня перка, получив при этом 16 силы (после окончания действия химии) для расчёта дальности. Сама же дальность считается как 3 гекса за 1 очко силы. Поэтому можно сделать дальность броска равной 48 гексам и это при том, что дальность у снайперской винтовки равна 50, а у другого оружия так и меньше. Что за нафик олимпийский метатель? Всё равно обычная дальность метательного оружия не превышает 15 гексов (максимум у святой гранаты = 20).
Теперь есть проверка и урезание силы до 10, а значит и максимальная дальность 30 гексов (но оружия такого всяко нет).

Масло маслянное — убирал защиту от значения силы для взятия перка и менял формулу расчёта дальности с "дальность = (сила + (уровень_перка * 2)) * 3" на "дальность = ((сила * 3) + (уровень_перка * 6))".

Функция используется в destroy_object, rm_mult_objs_from_inven, destroy_mult_objs и при торговле. Вот с сумками это и проявлялось — неправильный переход в функции приводил к продолжению "подсчёта" несуществующих вещей ещё и в сумке, а потом сбрасывал количество ранее найденных вещей в 0, что в конечном итоге приводило к проблемам:

С скриптовыми командами хлопотно заморачиваться, есть более простой способ для проверки бага — сумка и вещь, открыть с кем-то торговлю и перетащить на стол обмена сначала сумку, а потом вещь и нажать Esc (отмену торговли). Снова открыть торговлю — вещь и сумка вернулись в наш инвентарь. Теперь перетащить сначала вещь, а потом сумку и нажать Esc. Открыть торговлю — добро тю-тю.

Да там полная анархия :(

не понял, тут у формул результат "дальность" один и тот же.
это две одинаковые формулы только написаны по разному.
в чем тут прикол?)

Вот в том и прикол — масло ;) Не считая конечно снятия ограничения на силу для получения перка. Что всё равно лишено смысла из-за отсутствия подходящего метательного оружия и абсурдности с дальностью в 48 гексов при максимуме.
Описание:

DialogueFix.

Так называемый CityLimit patch.

DialogPanelAnimDelay.

Это "другой способ проверки целостности данных". Если экзешник (даже не сам экзешник, а код/данные в памяти) подправлен в нужном нам месте, то "патч" не накатывается, чтобы не возникли проблемы.
Не опасно если это "not important" — ну только что-то перестанет, как DialogPanelAnimDelay, работать, да и в faq придётся это отметить ;-p

Но можно вернуть данные в экзешнике на оригинальные (конечно там где возможно).
А вообще я наверное потом подправлю код чтобы сократить подобное (но не везде это выйдет, да и смысл проверки целостности данных теряется).

Поправил (наверное) это (и только это). Проверить толком не могу — сейвы не исправить (вообще можно — так не_толком проверял), а начинать новую игру и искать карту (двигаясь по сюжету) где появляется, к примеру, корень брока в столе/ящике/etc нет времени.

в частности интересует Player(<stat/attribute/skill/etc.>)
действительно ли можно задавать условия ну например на скиллы, или это так -написали без реализации... как-то сомнения есть что реализовали, потому как кроме проверка игрока на уровень там ничего больше и не проверяется.

Вообще это видно будет не вооруженным глазом в коде движка? — или там без спец оборудования не обойтись)

Открываешь в Иде окно строк (Shift-F12), потом фильтруешь (Ctrl-F) по hurt_too_much, переходишь по адресу и через ссылки (X) попадаешь в кусок кода где это используется. Обращаешь внимание на функцию parse_hurt_str_, заходишь в неё и видишь _matchHurtStrs с вариантами.

Видимо хотели, но не доделали — wmParseSubConditional_ обрабатывает rand, global, player(level), days_played, time_of_day и enctr(num_critters).

Посмотрел где в дальнейшем (конкретнее wmEvalSubConditional_) это проверяется — "_" не используется, также как " ", "and" и "or".

Вот OR там ни где нет, это точно что он не реализован?

Не, речь о другом.

Если смотреть на список условий _wmConditionalOpStrs, то к нему можно случайно добавить ещё 3 условия из _wmConditionalQualifierStrs (поскольку на него нет ссылок) и предположить, что если бы варианты Player(<stat/attribute/skill/etc.>) были полностью реализованы, то вполне возможно в условии можно было бы делать проверку конкретного флага (или наверное атрибута).

С rand, global, player(level), days_played, time_of_day и enctr(num_critters) можно использовать только "==", "!=", "<" и ">".

Так-то AND и OR конечно используются:

КАТЕГОРИЧЕСКИ не советую пользоваться версией 1.7.31r3 (и меньше) ;)

Например? DebugEditorKey — это много? ;)

В сишном коде куча проблем.

Это главная программулина сфалла, без нее даже играть и не хочется)
вот еще DontDeleteProtos вырезал)

Та ну не больше чем машинных мнемониках. :)
Сам то подумай где легче всего ошибиться.
Кстати давно не запускал мнемоневкую версию, может там новые ошибки посыпятся)

Я говорю о уже существующих ошибках, а не о возможных из-за выбора языка.

Будто есть отличие технических ошибок от влияющих на игру, а впрочем мне всё равно — я предупредил ;-p

Ничего вообще не говорил, к тому же не понимаю о чём речь и как это воспроизвести (сходил к королю Крыыс, ближайшей мультихекс животинке).

+ если такому мобу дать метательное оружие он будет попадать сам в себя)

если будешь править то желательно чтоб с исходником правки, чтоб я в это 31 версию это встроил)

CountWrite8 0xEB,0x42A153,0x42A17C

Не проверял, также как и мультихекс атакует мультихекса. Мне воссоздать такую ситуацию весьма сложно (искать энкаунтер вроде "кентавры нападают на кротокрысов"), в наличии были только ГГ и король Крыыс.

В принципе да.

Тому, кто этим занимается :-p

Тю, так делай сразу нужную artemple.map карту и кидай ссылку.

Тогда те два адреса здесь не помогут.

Отправлено: 23 июн 17 00:40

Поправил эту пичальку ;)

Маппер вроде не такая уж и высокая наука. :)
У меня только оригинальная artemple.map, может все-же пустую тебе сделать?

да я уже посмотрел что там только на движения.

Не интересно :-p

Да без разницы, главное чтобы её достаточно было скопировать в data\maps\ и запустив новую игру получить нужный энкаунтер.

Этот способ. Вообще-то он всегда и существовал, но в оригинальном варианте если нашли dat-файл, то файлы читались только из него. Если не нашли — из каталога.
Когда переписывал хиромод так подправил обработку чтобы обрабатывалось содержимое каталога, а затем и dat-файла. Удобно для мультиязычных вариантов.

Отправлено: 25 июн 17 20:06
У всех персонажей в игре постоянно и очень-очень часто вызывается скриптовый обработчик critter_p_proc (конечно если определён) внутри которого как правило происходит проверка видимости ГГ, и если этот персонаж "видит/слышит" ГГ, то может совершать разные сюжетные действия — атаковать, к примеру ;)

Видимость и слышимость персонажа зависят от его восприятия — для видимости это восприятие*5 когда цель находится перед лицом, а для слышимости равна восприятие*1 не_в_бою или восприятие*2 в_бою. Результаты могут быть меньше в зависимости от некоторых факторов (у цели включён стелсбой или режим скрытности), но они не существенны для понимания и их опустим.

Есть две скриптовые функции для проверок: obj_can_see_obj и obj_can_hear_obj. В нормальной реализации они должны были бы использоваться в обработчике critter_p_proc вместе, примерно как "if obj_can_see_obj(source,target) or obj_can_hear_obj(source,target) then source_видит_ИЛИ_слышит_target", а их содержимое упрощённо выглядело бы примерно так:

Однако вместо этого их содержимое частично объединили в одну универсально-урезанную движковую функцию:

И стали её использовать внутри obj_can_see_obj и obj_can_hear_obj, при этом вторая функция просто вызывает is_within_perception_ и более ничего не делает, а первая теперь выглядит примерно так:

Для проверки наличия преград есть несколько движковых функций, но используется та, в которой объект является преградой если у него сброшен флаг NoBlock и это элемент интерьера (стол, стул), персонаж (у живых флаг сброшен, а у мёртвых нет) или стена (ну тут понятно что флаг должен быть сброшен).

В 99.9% используется только obj_can_see_obj, ну и последствия реализации видны, к примеру, тут:

obj_can_hear_obj практически не используется — слепого повара можно не учитывать, да и без проверки на слепоту он вообще круче зрячего.

Но и это не всё ;) Функция is_within_perception_ используется самим движком в бою для оповещения собутыльников об агрессивных действиях. Без проверки на преграды! Ну ладно, слышимость через стены ещё можно принять (да и другого способа нет) — допустим из-за эволюции или радиационных мутаций слышимость в бою трансформируется в сверхчувствительность по отношению к собутыльникам, но видимость...! Абсурдно же, когда напали на персонажа, а его собутыльник в десяти+ метрах этого не слышит только потому что стоит спиной. В то время как другой собутыльник, стоящий лицом на расстоянии в два раза большем и с несколькими стенами в качестве преграды, ломится к обидчику.

Что представляет из себя CanSeeAndHearFix? Изменяет is_within_perception_ на что-то вроде:

В obj_can_see_obj не будет вызова проверки преград (зачем второй раз вызывать), в obj_can_hear_obj source временно становится слепым перед вызовом is_within_perception_, а после восстанавливает состояние зрения.

После включения (CanSeeAndHearFix=1) source может не видеть, но слышать (особенно когда он слепой), нормально работает obj_can_hear_obj. Некоторые бои могут стать легче (в Реддинге в бою с королевой несколько собутыльников не прибегает с другого конца карты).

Добавил в example_mods\is_within_perception_\ скрипт с оригинальной F2-реализацией функции. Можно включить CanSeeAndHearFix и в бою посмотреть кто перестал видеть ГГ.

Помню такое, сам удивлялся ;-p
Посмотрел скрипты: при первом заходе на карту создаётся случайное количество добрых (4-7, PID_GECKO_SMALL) и злых (1-3, PID_TOUGH_GECKO_SMALL) гекко, но визуально они все одинаковые. Первые, если их не бить, сами не нападают, а вот вторые агрессивные и напав на ГГ могут "сообщать" первым о враге. Если ГГ сам нападает, то гекко его запомнит и увидев, даже если это добряк, нападёт сам (ГГ ударил, убежал с карты, а затем вернулся).

Подтвердить не могу, у меня при загрузке/перезаходе поведение остаётся прежним.
Но если прошли сутки с последнего создания криттеров, то будет повторная генерация — может добавится злой гекко, или если ранее всех убили, то будет новое случайное количество и в случайном порядке (если раньше в одном месте был добрый гекко, то теперь может оказаться злой).

Читаешь Формат содержимого файла critter.dat.
И на примере (отключи хиромод) стартовой модели ГГ (hmwarr), заглянув в critter.dat выясняешь что ГГ умеет пользоваться только копьём (hmwarrG?), а ты хочешь чтоб он ещё мог ножиком пользоваться. Значит нужно создать анимацию hmwarrD? и добавить в critter.dat или в data\art\critters\. Однако вместо создания анимации с нуля можно пойти на хитрость и использовать уже существующую анимацию для дикаря (nmwarr) и скопировать nmwarrD? в hmwarrD?, а потом подправить где нужно (бошка).

Отправлено: 27 июн 17 17:25

Ай-ай, действительно сломал всем зрение не в бою (у них восприятие=2, потому только слышали) :(
Спасибо, поправил.

Спасибо за ответ, но столкнулся с проблемой — фоллач( первый, если что) не видит распакованный critter.dat. А найти работающий паковщик для дат файлов первого фоллаута у меня не получилось( установил плагин для тотал коммандера, но он выдает ошибку при попытке добавить файлы в архив).

И сразу спрошу, можно ли использовать анимацию другого действия для той же модели, но для нужного мне действия?

Нет, Невада "определяется по размеру файла", а у тебя размерчик не тот ;) Но я обнаружил в exe'шнике маркер ("FALLOUT:NEVADA 1.0 ") и уже поменял способ определения на маркерный.

Видит, вероятно неправильный путь — содержимое critter.dat нужно распаковать в указаный в critter_patches каталог (скорее всего это будет fallout\data\).

Да их достаточно, я F1/2 DAT-files packer/unpacker (DAT2) использую и вот для F1-dat файлов ему нужно опцию -s указывать.

Конечно.