Перевёл из локального смещения (9F947) в глобальное (0x4AF547).

Используется всеми персонажами при критических попаданиях для расчёта какая таблица критических эффектов будет использована:

random(1, 100) + get_critter_stat(source, STAT_better_crit)

А что там новенького? ;)

Нельзя, int же возвращает. Возвращает "sfall2".

ну тебе ж виднее)

какая разница преобразуй в стринг, в скриптах нет понятия типа данных)

почему тогда у всех персонажей там всегда нуль?

Что в pro'шнике прописали, то и получили (base_stat_better_criticals + bonus_stat_better_criticals).

Выглядит хлопотно... :-p

Это которые в define_extra.h описаны как CFLG_*? Так через изменение pro'шника (как в твоём примере с CFLG_BARTER) — в памяти они не хранятся и движок использует pro'шник.
Или так:

Нет, это не эти. Вот эти PROTO_IT_FLAG (0x14) (в define_extra оно не определено взял по смешению из итемов.)
оно точно в памяти хранится или в карте для каждого объекта на карте,
в общем нужен бит прозрачности. :)

Инициализируется начальными битами всё так же из pro'шника именно по смещению 0x14 (одинаково у всех объектов).

hs_keypress на F11:

Только не забывай что бит прозрачности используется "Невидимкой" и при установленном значении видимость врагов уменьшается в 2 раза.
А ещё попробуй бит энергии (0x80000) вместо бита стекла (0x20000) :)

Да ладно. Действительно, полная анархия.
sfall_ver_build теперь возвращает 509 "sfall2" (без кавычек).

да блин, мне не у DUDE флаг нужен.

Это Не верно!
Если поставить на карту объект, то потом хоть как ты меняй флаг в pro, он на карте так и останется с таким каким его туда поставили, так же с текущими жизнями у криттера и их FrmID.

Ну нету же там понятия String или Integer.
Там же переменные на подобие как в старом VisualBasic

чего значит это 509? -это твое счастливое число, почему не 404)

Отправлено: 24 сен 16 21:14
так стоп

То есть вместо dude можно подставить другой указатель на объект?
что-то я не понял.

Вот и используй нужный тебе ObjectPtr вместо dude_obj.

Инициализируется начальными битами всё так же из pro'шника именно по смещению 0x14.

Потом — да.

Да ладно :-p

lex.h:

Типа того, и 404 тоже весёленькое.

Верно.

Так это тип который возвращается функцией, мы же когда определяем переменную в скрипте не пишем какого типа данные она будет содержать.
ну во общем, я так понял там с твоей стороны тех.проблемы преобразования из инт в стринг.
509 — т.е. это константа?

Отправлено: 25 сен 16 19:45

var:=true;
var:=1;
if var...
там в движке между boolean и int есть какая либо разница в использовании?

Но компилятор генерирует код исходя из типа обрабатываемых данных. И движок потом обрабатывает переменную исходя из её текущего типа.

Глупости-то какие :-p

lex.c:

По моему, при прицельном выстреле в любую часть тела (даже торс) — дается 5% шанс нанести критическое повреждение. Или я не прав?
Хотел ещё спросить: кроме torso в ddraw.ini есть ещё BodyHit_Uncalled — это что за часть тела?)

О выборе части тела для НПС писал выше, для ГГ же, если его атака прицельная, то возвращается та часть тела, в противном случае Body_Uncalled. Далее (некоторые детали я пропущу):

Пример: у ГГ 8% шанс на крит, 33% шанс попадания в глаза (штраф -60):
min = 33, max = 8 — (-60) = 68.
"тип попадания" = roll_check(33, 68) = 3 = ROLL_CRITICAL_SUCCESS.

Вот из-за второго пункта по-хорошему BodyHit_Uncalled нужно удалить из ini, потому что если его значение не совпадает с BodyHit_Torso, то это не торт.

PS. На всякий, вот так определяется "тип попадания" (roll_check(min, max)):

С помощью переменной RemoveCriticalTimelimits можно отключить проверку первого дня.

А есть что-то подобное, только для криттера/карты?

Для криттера:

Для карты попробуй:

о а я не и додумался флаг ставить пред сменой фида, спасибо за подсказку.

Может еще вот это глянешь, или там все сложно).

Не улавливаю суть, давай попроще на примере Вика (у меня с ним сейв есть, убиваю пару гекко и он апается) ;)

а где находится его базовый прошник?
может это уже исправили, или вообще это миф)
нафига тогда RP упаковывает прошки в дат?

PID_VIC = 16777278 (00000062.pro), PID_VIC_STAGE1-PID_VIC_STAGE6 = 16777589-16777594 (00000373.pro-00000378.pro).

У меня Вик второго уровня, ну я подсунул в data\proto\critters\ вместо 00000375.pro переименованный 00000378.pro и с атрибутом read-only — при апе получаю статы 6 уровня. Вот и не улавливаю суть проблемы ;-p

Чтобы не заморачиваться с установкой read-only, не? ;)

RP упаковывает только начальные (базовые) прошки напарников, которые редактировались:
00000079.pro
00000089.pro
00000107.pro
00000502.pro
00000503.pro
00000504.pro

Разобрался, формулировка сбила с толку.

На примере Вика суть такова: его базовый прошник 00000062.pro (и он всегда используется из-за PID_VIC=16777278), а уровни хранятся в 00000373.pro-00000378.pro (но у них другие pid'ы). При получении уровня новые данные (все статы и скиллы) копируются в базовый прошник заменяя собою старые и сохраняя новый базовый прошник в master_patches (data\proto\critters\00000062.pro), а при записи игры в сейвслоте (data\savegame\slot#\proto\critters\00000062.pro), ну а при загрузке восстанавливается в master_patches. Соответственно, если в master_patches есть базовый прошник с read-only, то новые данные не сохраняются и всегда используются из этого базового прошника (потому что движок сначала ищет в master_patches, а потом в master_dat). И уровень не сбрасывается, потому что данные о уровне сопартийцев хранятся в другом месте, а не в их базовых прошниках.

Вывод:

Каким образом это можно побороть?)
А если эти измененные базовые прошки упаковывать в patch.dat, двиг его от туда будет брать, или все равно из master.dat?

patch.dat — высший приоритет же имеет.
если это не так то может поправишь чтоб хобя из patch.dat брал.
хотя фиг его знает, нужна ли эта поправка или нет.

Будет брать там, где найдёт первым. Эффект от базовых прошек в patch###.dat такой же как и от этих прошек в master_patches с атрибутом read-only, то есть после левелапа будет откат на базовые статы и скиллы.

Пример для старой версии с patch001.dat, patch002.dat (но без использования NumberPatchLoop) и подключённым HRP, который добавляет в цепочку каталогов/dat-файлов f2_res.dat и каталог "data\" (Предположение что master_patches всегда указывает на "каталог_игры\data\"? А если будет, к примеру, "левый_каталог\data1\"...).
После инициализации цепочка выглядит так:

Очень даже нужна, и именно так и должен был быть сделан способ с patch###.dat.
Сейчас в новой версии после инициализации цепочка с примером выше выглядит так:

Ну и бонус — если critter_patches и master_patches одинаковые, то critter_patches из цепочки будет удалён.

Шрифт, да и не смертельно :-p

Почему откат, ведь если

в patch.dat у файлов нет никаких read-only и двиг же должен его распаковать в master_patches(т.е в DATA) и записать данные в него, или он напрямую в patch.dat пишет?
и что если patch.dat является папкой, а не архивом?

Сделай вывод, а то ничего не понятно)
Ладно я уже понял, что ты исправил это дело.
а как на счет того чтобы сфалл свои скрипты брал из папки на которую указывал master_patches, а то он всегда берет из Data.

Ээээ, тут как бы бессмысленно использовать разные пути.

В оригинальной формулировке patch.dat не упоминался и его использование конечно же вносит дополнительные требования. Примерно так для оригинальной игры:

Движок может только читать файлы из .dat-архива.

Базовый прошник партийца, у которого повышаются уровни, НЕ ДОЛЖЕН быть в master_patches\proto\critters\ с атрибутом read-only, а должен быть упакован в patch###.dat или master_dat (при этом версия в patch###.dat приоритетнее версии в master_dat). Иначе статы и скиллы будут всё время сбрасываться до базового прошника.

Ага, надо будет поправить, и для gl* и для hs_*.

Речь о другом ;) Без этого "бонуса" новая развёрнутая цепочка выглядит так (для простоты без patch.dat и HRP):

И при поиске, к примеру, 00000062.pro, который есть только в master_dat, файл дважды будет искаться в "D:\Games\Fallout2\data".
В оригинале так и происходит:

А нет, приврал — в движке уже есть проверка на одинаковые имена.

Переменные critter_patches и master_patches используются только при инициализации движка для создания цепочки каталогов/dat-файлов и поэтому "critter_patches из цепочки будет удалён" © не несёт никакой угрозы :-p

Можно узнать смещение этого значения, хочется увеличить до х3, а то некоторые с низким ВС стоят в сторонке и курят.

Что именно ты там изменил с перк.ини ?

Отправлено: 1 окт 16 16:46
и еще по армор ини

вот эти вот Metal/Leather...
нельзя просто заменить на явные номера PID итемов? т.е. чтоб не было никакого хардкодинга.
или же оставить как есть, но добавить возможность вписывать кастомные пиды.

Отправлено: 1 окт 16 16:59

а всякие временные прохи и worldmap.dat которые создает двиг все равно создаются в DATA?

0x42BACA, но не поможет из-за способа "умножения" — сложения.

Там скорее всего причина в другом...
Можешь попробовать добавить в секцию [Misc] переменную SmarterAI=1.

Без этого изменения нельзя нормально поменять эффект gain* перков через perks.ini, потому что +1 к стату всё равно добавляет движок.
В perks.ini пропиши:

Возьми перк "Добавить выносливости" и посмотри на результат (ну и чтобы выносливости было меньше 9).

Пока нельзя:

Отправлено: 1 окт 16 17:06

Другое поменял — в исходниках были зашиты пути с фиксированным "data\".

т.е там типа ADD EAX,EAX, а нельзя сменить на MUL — или она не влезет в размер.

0x42BACA — дай лучше которое в файле.

явно видно что из-за расстояния ставишь два криттера с разным ВС тот у которого больше бежит.
хотя да тут в чем-то другом дело, видимо другой алгоритм есть
типа ВСx2 потом еще что прибавляется где-то в коде + учитывается куда зырит(повернут) криттер.
вот пример расстояние до тестируемых критеров 35+ гексов тот который с 8 ВС бежит, рядом стоит с ВС 7 не бежит, пока ближе не подойдешь — разумеется это все в режиме боя.
ладно забей на это.

SmarterAI=1 — что это за недокументированная опция?
попробовал без разницы.

Да, и в размер не влезет и на mul нельзя поменять (требует подготовки регистров). К тому же это меняет восприятие целей которые стоят за спиной. Восприятие умножается на 5, если цель перед глазами.
0x1BECA.

Ну вот кусок движка:

Мои эксперименты с улучшением AI.
Ну так сразу разницу и не заметишь. Там дофига описывать оригинальный алгоритм и что я поменял. Лень и никому не интересно.

а понятно — ну дерзай, дерзай! :)

ну вот тут как раз бы и надо увеличить, а то эти вообще злоядлые курильщики — с восприятием 6-7 (15 гексов) резня у них за спиной происходит, а они отдыхают)

Тогда все сходится с ВС=7 как раз не и доставал до тех гексов.

Там не только завязка на "видимости", ещё куча условий отбора цели... К примеру, то, что сейчас меняет SmarterAI можно заметить если есть сопартийцы — их просто выносить будут очень быстро если они бегают далеко от ГГ.

Так это не сфалл — это ассемблер.

Да, да.

Нет, а поэтому её нужно будет выполнить в твоей вставке. И размер вызова твоей вставки равен 5 байтам.

Если true, то это вызов функции (call) и возврат из функции будет через retn на addr+5, а если false то это переход по адресу (jmp) и возврат нужно будет указать в твоей вставке.

Если речь о умножении на 3, то с последней версией это не сработает — я переписал оригинальную функцию с дополнениями.
Используй хуковый скрипт, не? Вот аналог оригинальной движковой is_within_perception_ в F2, hs_withinperception.ssl:

Хз, искать лень. Может и нет и единственное отличие в анимации. Думаю в вики/etc это уже описано.

Да просто стало интересно, поставил IDA и залез в движок, ты там idb базу не обновлял?

Почему не через ini изменения вносишь, или в отладочную версию бы вносил.

Что-то ничего там нету по этому поводу... хотя может не нашел.

Все нашел. Цитата:

Не обновлял, в старой всё что нужно есть...

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

Функция is_within_perception_ используется в скриптовых функциях obj_can_see_obj и obj_can_hear_obj. Опуская предварительные проверки на наличие цели, одинакового уровня карты и прочее (исправление рассмотрели тут) эти функции выглядят так:

В самом движке функция используется, к примеру, при оповещении сопартийцев (и введении их в бой) что ГГ в бою и для этого используется вариант obj_can_hear_obj.
Сама же реализация is_within_perception_ (опять же, опустив всякие дополнительные проверки на скрытность, стелсбой и прочее) всегда при 10 восприятия проверяющего подразумевает что слышит он в радиусе 10 гексов, а если цель перед его лицом так слышит(!) и видит на все 50 . Но что если проверяющий слепой или между его целью есть препятствие, которое сводит на нет его зрение. Вот я и расширил строчку:

Действительно нужна переменная CanSeeAndHearFix?

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

Персонаж (ГГ или НПЦ), которого обидели, после получения урона запускает процедуру в которой все сопартийцы (team_num) в пределах is_within_perception_ которых находится обиженный входят в бой. При этом игнорируются любые преграды вроде стен, а если обиженный находится перед лицом обрабатываемого сопартийца, то последний видит в 2.5 раза дальше. Дополнительная проверка на sight убирает этот бонус к расстоянию, если обиженного не видно глазками (есть преграда в виде Scenery/Wall без флага LightThru (через объект проходит свет)).
Чтобы объяснить "слышимость" персонажей сквозь стены/etc можно считать что у всех слух развился в телепатию и они "слышат" чужие мысли в радиусе своего восприятия (в бою *2).

Что касается проверки на слепоту — настоящий слепой, вроде повара с базы Наварро (а он действительно такой — подробнее в CCCOOK.SSL/map_enter_p_proc), не будет слышать так же как видит зрячий только из-за того, что цель располагается перед его лицом.

Добавил... :-p

PS. Поправил объяснение.

Непонятно! последний это конкретно кто?)
и X*2.5=?
X=?

Понятно)
Но! тогда нужно сделать некое исключение для НПЦ которые находятся на небольшом расстоянии от ГГ или обиженного НПЦ.
Вот к примеру, есть дом где в одной из комнат ГГ мучает НПЦ резиновой дубинкой) и получается что НПЦ стоящий в соседней комнате с тем же team_num не среагирует на БОЙ, -да? или он услышит визги)
Вообще что-то не особо понятно с этим obj_can_hear_obj, как они там слышат.

Отправлено: 5 окт 16 22:17
И это.

В ванили(в мапере проверил) через уст.флаг LightThru, все равно НПЦ не могут видеть ГГ, так как на объекте есть блокиратор (не уст.флаг NoBlock).
И вроде как в сфалл не фиксит это дело, чтобы НПЦ видели через LightThru, только через ShotThru.
или LightThru может пропускать "звук" для obj_can_hear_obj, да?

Сопартиец.

X=10, но поскольку есть обиженный, то это бой и X=10*2=20.
10*2*2.5=50.

Угу, или "услышит" чужие мысли.

Не зацикливайся на скриптовой obj_can_see_obj, проверка на LightThru нужна в основном чтобы избежать движкового абсурда вроде "видимости" обижаемого на расстояние 40 гексов через кучу стен только потому что сопартиец случайно смотрит в его направлении.

эээ, а причем тут сопартийцы ГГ, и зачем ему(Сопартийцу ГГ) видеть на 10*2*2.5=50 гексов -еще больше стало непонятно)))

Для любого персонажа другой персонаж с такой же team_num является сопартийцем.

это что движковая гвара? — для каких целей она обрабатывается.

Круто)
Теперь бы еще научить мышку цеплять трупы, если он упал за какой-нибудь объект.

какие такие sound files, такие разве есть?

Не в курсе для чего эти??? — у тебя кстати их нет в конфиге.

Сколько не пытался так, и не увидел и не понял в чем конкретно заключается твой фикс, они как бегали на расстояние ВС х 2 х 2.5 = гексов через стенки так и продолжают.
Можешь на словах описать как должны стоять НПЦ, кто на кого должен смотреть, через стену или нет, чтоб хотя бы на живом примере увидеть это.
или же скрином из маппера.

Не это слишком сложно) тем более когда ты уже все сам там сделал, я просто добавлю немного водички :)

У тебя в Changelogе не все исправления и добавления написаны. Не хватает.
Исправление сдвига положения курсора ГГ на глобальной карте, при выходе из локации.
Что-то там со скриптовой анимацией Amin в бою.
Исправление минусовых очков SPECIAL при создании персонажа.
Исправление obj_can_see_obj и obj_can_hear_obj
Исправление неправильной инициализации очков действия в начале каждого хода.

Кстати вот это зачем в ТRACE поместил, вроде нормальный баг исправляет.
// Исправление вызова damage_p_proc при промахах если цель не_персонаж

К этой бы тоже переменную замутил. Вроде не сложно.
// Исправление видимости предмета только в активной руке игрока для critter_inven_obj

Кстати combat_is_starting_p_proc очень даже пригодился мне.

это что сфалл головы PNG формата поддерживает?!!!
или что он такое делает с этими PNG файлами.