Просьба #2.
Добавить в "Stats.ini" возможность поменять формулу ещё двух производных характеристик:

• HP per level (Очки Здоровья за уровень; в оригинале = EN/2+2);
• SP per level (Очки Навыков за уровень; в оригинале = IN*2+5).

Если данные производные будут добавлены, то в просьбе #1 значения прибавок должны будут зависеть не от оригинальных производных, а от новых, если они будут прописаны в "Stats.ini". Например, если изменить формулу:

То ретроактивная прибавка тоже должна рассчитываться по новой формуле:

Там можно ознакомиться > Изменение формулы расчета скилл поинтов

Увеличение ST (Силы) повышает значение Hit Points (Очки Здоровья) только при генерации персонажа. Во время игры изменение ST не влияет на HP. Иными словами, в оригинальной игре влияние ST на HP не ретроактивно (не имеет обратной силы).

Увеличение EN (Выносливости) повышает значение производной характеристики HP per level (Очки Здоровья за уровень) [в оригинальной формуле — только в случае с чётными значениями EN]. Новое значение HP per level влияет только на последующие уровни, на предыдущие уровни оно не влияет. Иными словами, в оригинальной игре влияние EN на HP per level не ретроактивно (не имеет обратной силы).

Увеличение IN (Интеллекта) повышает значение производной характеристики SP per level (Очки Навыков за уровень). Новое значение SP per level влияет только на последующие уровни, на предыдущие уровни оно не влияет. Иными словами, в оригинальной игре влияние IN на SP per level не ретроактивно (не имеет обратной силы).

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

Наглядный пример в Fallout 2:
- есть 2 взаимоисключающих квестовых повышения характеристик (z-scan):

- допустим, нам одинаково важны как IN, так и LK, то есть с точки зрения бонусных характеристик обе награды идентичны;
- поэтому есть 2 варианта создания персонажа:

- допустим, если поспешить, можно получить данную награду на 12 уровне;
- тогда к данному уровню персонажи накопят разное кол-во SP:

- в итоге, хоть у обоих персонажей к 12 уровню будут абсолютно идентичные характеристики (10 IN, 10 LK), упущенная выгода персонажа #2 составит (25-23)*(12-1) = 22 (SP), потому что IN не имеет обратной силы на SP per level;
- если не спешить и получить награду позже, то упущенная выгода будет ещё больше, то есть Experience (Очки Опыта) становятся вредны для игрока, что само по себе уже нонсенс;
- если бы характеристики влияли на свои производные ретроактивно, то после получения награды (IN+1) на 12 уровне персонаж #2 сразу бы получил причитающиеся ему 22 SP.

Надеюсь, этого примера достаточно, чтобы понять недостаток данной игровой механики.

К сожалению, два но:

Было бы гораздо проще (для конечного пользователя вроде меня, а не для разработчиков sfall'а, конечно) изменить 2 необходимых формулы в "Stats.ini". С возможностью, как и для других производных, установить значения HP per level и SP per level равными константе (например, 0 и 15, соответственно).

В формуле HP per level значение силы не задействовано.

Ну формула такая. :)

Т.е. по твоему(по закону обратной силы) должен быть пересчет всех очков HP начиная с первого 1 ур для нового EN?
Не жирно ли для игрока?)

см. комментарий для EN

не хилый такой буст для игрока получается)

Ну не знаю, не знаю. думаю с этим все в порядке.

Да ну, какой еще недостаток, такая система).

Добавить в stat.ini изменения для формул HP per level / SP per level (для не понимающих в сриптенге) еще можно, но вот с ретроактивностью стат ты ломаешь фоловскую систему прокачки игрока, и на выходе мы получим тупо буст к SP и HP.

Все правильно, что игрок #2 потеряет 24sp, потому как он раньше был тупой и получал меньше балов, логично? Да!
Имхо закон ретроактивности вообще лишняя заморочка.

Я и не говорил, что ST влияет на HP per level. Я сказал, что ST влияет на HP только во время создания персонажа: Начальные HP = 15+ST+EN*2. При повышении ST во время игры HP не увеличивается.

В том предложении я говорил о ретроактивности формулы, а не о самой формуле.

Нет. Справедливо. Что жирно — так это наличие кучи халявных очков навыков в виде книг. Или возможности абсолютно бесплатно поднять рукопашку до 100%. Или украсть любую вещь с 10% кражи после сотни перезагрузок, потому что результат небоевых навыков абсолютно рандомный. Но это уже другая тема.

Дело не в том, что это жирно или не жирно. А в том, что ретроактивная игровая механика справедлива. И это не говоря о том, что все производные характеристик, за исключением HP per level и SP per level, и так ретроактивны.

Нет, не логично. Я так же могу ответить, что персонаж стал умнее и переосмыслил свои прошлые действия (знания), получив в награду заслуженные SP.

То же самое и с EN — повысив выносливость, персонаж стал здоровее (на все свои уровни), а не частично здоровее (начиная с n-го уровня). Хотя тут стоит добавить, что было бы справедливо, чтобы при уменьшении EN (временно или постоянно) здоровье персонажа (вместе со всеми HP/level) тоже уменьшалось.

А без ретроактивности мы имеем несправедливый nerf (ослабление) игрока, если не брать награды/перки на повышение EN/IN как можно быстрее, игнорируя другие награды/перки.

В таком случае, то же самое можно было бы сказать и о, например, "Отключении абуза отрицательных эффектов от наркотиков" [усложнение игры]. Или о "контроле персонажей в бою" [упрощение игры].

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

Исключен багажник и если у предмета стоит флаг NoHighlight то не подсвечивать его.

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

Что за менталитет — "Добавьте параметр FeatureIWant=1" ?

Ты просишь зашить очередной мод внутрь sfall. Проблема в том что sfall один и в нем нет модульности (системы плагинов). А описанное выше видение как должны работать статы не является единственным верным. Встраивать в единый для всех sfall фичу которую будет использовать один человек не есть правильно.

Плагины тоже не нужны, т.к. sfall просто является "мостом" к движку (+ багфиксы и "движковые" фичи вроде изменения частоты случаек). Модульность достигается при помощи глобальных скриптов с использованием функции register_hook_proc и т.п.

Плюсы написания такого мода в виде глобального скрипта:
- Можно легко встраивать в любой глобальный мод, использующий sfall (причем версия sfall не будет иметь значение, при условии что нужные скриптовые функции там есть).
- Люди будут тебе благодарны за вклад в развитие моддинга.
- Не придется ждать пока Crafty или кто-то еще напишет специально для тебя версию sfall с новой "фичей".
- Не придется никому доказывать или объяснять что конкретно ты хочешь и почему. Просто запиливаешь логику как тебе надо... И уже на рабочем примере сможешь продемонстрировать крутость своих формул.

А какая связь между разработкой sfall и реализацией конкретной фичи для конкретного мода?

sfall это набор расширений для движка. Не нужно воспринимать его как кучу разных модов склееных в одну DLL...

Совершенно верное замечание. Многое из того что сейчас реализовано в sfall в идеале нужно заменить на скриптовое решение в виде отдельных модов. Как контроль персонажей.

Это устанавливает окно визуализации размера, _not_ окно просмотра игры визуализации. Вторая часть, чтобы сделать игру на самом деле делают в 960x600, но занимают это окно весь 1920х1200, сохраняя первоначальный вид искусства и игру, давая лже-полноэкранный вид.

в f1_res.ini

В результате окно (который я использую другое приложение, чтобы сделать весь экран без полей), который выглядит следующим образом: http://i.imgur.com/OBASfmy.jpg

Я написал более подробное описание здесь: http://www.rpgcodex.net/forums/index.php?t...109858/page-11# пост-4650361

Проблема заключается в том, когда я пытаюсь сделать это с Fallout 1, с использованием TeamX 1.3.5 (с или без RP мод Wasteland Призрака), sfall Умейки 1.7.6 и High Rez 4.1.8 мод, высокое разрешение мод не работает правильно ,

Почему я размещения здесь? Потому что я отследил проблема sfall 1.7.6. Используя метод, описанный выше, я могу сделать 1920x1200 окна, но только несколько резолюций игры оказываются в высоком разрешении пластыря (640х480) является одним.

Симптомы проблемы включают в себя: игровое окно не визуализируется правильно, он смещен вправо и "обтекает" на левой стороне экрана. Или игра вылетает мгновенно при запуске, в зависимости от разрешения.

Когда я удалить ddraw.ini и ddraw.dll sfall файлы, высокое разрешение патч работает отлично. Я думаю, что sfall Умейки не играет хорошо с разрешением пластыря. Я изменил ExtraCRC = 0xf60e71e2,0xf290ac8f как для поддержки регулярных 1.3.5 и RP мод Wasteland Призрака.

Любая идея, как я могу сделать Sfall1 и патч работы High Rez хорошо вместе?

Моя установить порядок является следующим:

Я сделал так, чтобы "установить" высокого разрешения патч (через f1_res_Config) перед запуском sfall и модифицирование проверку CRC.

Спасибо за чтение, пожалуйста, дайте мне знать, если я могу предоставить более подробную информацию.

Оригинальная английская версия:

Sorry for my poor Russian, I'm a native English speaker who is using translate.google.com.

I'm trying to configure my Fallout 1 like my Fallout 2: a window occupying my entire desktop (1920x1200) rendering Fallout 1 in 960x600 to preserve the look of the art. For Fallout 2 / Resurrection 1.5, this is easy.

ddraw.ini is set to:

This sets the window render size, _not_ the game's viewport render. The second part is to make the game actually render in 960x600, but take up that entire 1920x1200 window, preserving the original look of the art and the game while giving a faux-fullscreen look.

in f1_res.ini

The result is a window (that I use another app to make borderless fullscreen) that looks like this: http://i.imgur.com/OBASfmy.jpg

I wrote a more detailed description here: http://www.rpgcodex.net/forums/index.php?t...11#post-4650361

The problem is when I try to do this with Fallout 1 using TeamX 1.3.5 (with or without Wasteland Ghost's RP mod), Crafty's sfall 1.7.6 and the High Rez 4.1.8 mod, the high resolution mod doesn't work correctly.

Why am I posting here? Because I've tracked the problem to sfall 1.7.6. Using the above method, I can make 1920x1200 windows, but only a few game resolutions are rendered by the high res patch (640x480 being one).

Symptoms of the problem include: the game window not being rendered correctly, it is offset to the right and 'wraps around' to the left side of the screen. Or the game crashes instantly at launch, depending on the resolution.

When I remove the ddraw.ini and ddraw.dll sfall files, the high resolution patch works perfectly. I think Crafty's sfall is not playing nice with the resolution patch. I changed ExtraCRC=0xf60e71e2,0xf290ac8f to both support regular 1.3.5 and Wasteland Ghost's RP mod.

Any idea how I can make Sfall1 and the High Rez patch work well together?

My install order is:

I've made sure to 'install' the High Resolution patch (through f1_res_Config) before running sfall and modifying the CRC check.

Thanks for reading, please let me know if I can provide more information.

По дефолту, кому надо и включит и значение нужное выставит.

F2-версия пока заморожена.

Время покажет ;)

Try latest version.

До весны как потеплеет? :)
А кто баги твои будет фиксить?)
Список багов от Хитрого:

Надо бы вернуть как было.

После каких-то там правок с BodyHit_Uncalled, BodyHit_Torso перестал давать бонус/штраф к прицельной стрельбе по телу.
Т.е. теперь дает штраф/бонус ко всем не прицельным атакам.
Раньше же было все правильно зачем это поменял?

Всегда трактовал перевод как "Искусный" :-p

Наличие пипбоя определяется переменной, которая "включается" после проигрывания ролика. Эта же переменная отвечает за использование стартовой или базовой модели ГГ. Иными словами: пипбой — это голубая пижама.
Но в отличии от пипбоя (где эта переменная проверяется конкретно в момент попытки его использования) смена модели ГГ происходит при загрузке карты.

Оригинальная реализация PipBoyAvailableAtGameStart=1 имеет логическую ошибку — переменная включается после загрузки карты в начале игры. Поэтому ГГ (уже с пипбоем) имеет стартовую модель (MaleStartModel), но если зайти в храм (загрузка другой карты), то модель меняется на базовую (MaleDefaultModel). В принципе на это можно было бы закрыть глаза, но при включённом хиромоде при создании персонажа всегда используется стартовая модель независимо от значения переменной PipBoyAvailableAtGameStart.

Неправильно, рассказывал тут. Для штрафов важны 1-3 пункты. При разных значениях Body_Uncalled и Body_Torso и неприцельном выстреле будет погрешность, не очень заметная, но будет:

Если сильно надо могу пример с цифрами.

Тогда нужно было оставлять Body_Uncalled вместо Body_Torso(они же там друг на друга завязаны) чтоб в заблуждение не вводило.
И сопутствующий вопрос эти модификаторы действуют только для игрока, или для партийцев тоже?

с оригинальной логической ошибкой, все вроде как нормально работало. )
в общем там какие-то не стыковки в Ressurection с твоей версией наблюдались.

Ага, с BodypartHitMod# так всё прозрачно было.

Вообще на всех.

Потому что мало кто знал (или понимал), что "пипбой — это голубая пижама" в реализации движка. И почему-то при включённом пипбое на старте игры после захода в храм не "замечал" смену модели ГГ.

Вот это и посты дальше?

Во-1:

а во-2 эта правка будет работать только в пещере, после выхода из неё (загрузка другой карты) будет смена модели на DefaultModel (костюм 13-го).

Ты серьезно? Вот это обломище)
я думал оно только для гг, выходит пользоваться ими в ini особо и нельзя.
пойду скрипты исправлять...

Можешь мне еще подсобить в одной задачке, в интерфейсе картинки INVBOX.frm или USE.frm в окошке где отображается крутящаяся картинка гг, его задний фон прямоугольника берется из картинки LOOT.frm надо найти и изменить (сдвинуть его влево) координаты прямоугольника заднего фона.
я пытался найти это место в исходниках но нифига не смог разобраться там, можешь ткнуть меня носом где эти координаты там записаны.
или вообще отрубить этот задник(но я как полагаю что будет оставаться шлейф от крутящегося гг).

Ну Torso (он же Uncalled) конечно лучше не трогать, а остальные части почему бы и нет — вероятность прицельного выстрела у остальных ну очень слабая (та история с "единица, Карл!" и AI_Called_Freq_Div).

Там координаты выбираются в зависимости от режима использования инвентаря (I, использование сумки и т.д). 0x4708CC (0x60CCC), 0x4708DF (0x60CDF), 0x4708F9 (0x60CF9), 0x47090C (0x60D0C).

Верно, при отрисовке каждого фрейма крутящегося ГГ старый фон сначала полностью перерисоывается оригинальным прямоугольником из loot.frm.

пипец раньше извращались программисты.
в буфер-обмена что ли нельзя было скопировать картинку под гг) а потом перерисовывать. копи-пасте замечательно работает))

loot.frm в памяти конечно.

Видимо лень было писать код для чтения из разных оригиналов (invbox.frm, use.frm и т.д.), потому используется loot.frm.

Придумал как сделать пипбой независимым от модели ГГ (костюма 13-го).

Заморозка же :-p

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

Если файлы ещё есть — давай, пусть пока полежат.

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

Где это ты такой неадекватный сюжет надыбал)

да брось, пусть на NMA чинят — не такая уж и нужная вещь.

Да прям, вполне годный сюжет — сломался и нужно найти детали :-p (зачем тогда вообще set_pipboy_available добавили).

ну если только в начале квест, при старте — находишь железячку и надо целую лампу-генерации найти — mmm хорошая идея... :)

Отсюда:

Действуют модификаторы вроде combat_taunts из fallout2.cfg и chance из data\data\ai.txt. Была пара странных багов — копирование без завершающего нуля (будет ой если длина имени 8 символов) и всё так же всплывающий текст, но уже с именем файла (указал SAYFLEE в качестве звукового файла и он будет проигран, а также имя появится в текстовом сообщении).
В отладке поможет переменная Test_ForceFloats, но она не изменяет/форсирует chance.

Почему спрашиваю? Может здесь подобная фигня:

Не, там проверка конкретно на оружие и использование типа патронов по умолчанию.
Проблема в разных obj.id (изменяется при создании объекта) при одинаковых obj.pid.

Есть у меня в списке todo, хоть меня и напрягло в своё время нестаканье вещей после смерти (дать собутыльнику две одинаковых брони — одну одеть через меню "поведение", на вторую посмотреть просто открыв бартер, потом грохнуть собутыльника и обшарить: две брони не в стаке). В общем не смертельно, но надо бы будет исправить (у самого сейвы Невады с разными стаками корня ксандера и пустыми шприцами).

Еще в разных уст. флагов у предмета.

В ddraw.ini
WorldMapDelay2=66
чем меньше значение тем быстрей перемещение.

Поставил 1, стало лучше, но все равно не так как без sfall вообще.

Отключается через WorldMapFPSPatch=0, но если включён dx9 режим (Mode не равен 0), то визуально не шибко заметна разница.
Включённый dx9 режим также влияет на PipboyTimeAnimDelay.

Почему такая взаимосвязь.

Догадываюсь, но углубляться в изучение этой проблемы нет желания (овчинка выделки не стоит), а потому короткий ответ — не знаю ;)

можешь мне растолковать это примечание на движковом уровне,
т.е. эти объекты будут лежать и сохранятся на карте, до тех пока их не уничтожить да?
И если по указателю удаленных объектов добавить эти объекты в другой инвентарь add_mult_objs_to_inven(ObjectPtr who, ObjectPtr obj, int count)
Те объекты которые лежат на карте уничтожатся(переместятся) или так и останутся лежать там всю игру? — как там вообще на движковом уровне функционирует этот ADD_
я просто переживаю насчет скопления там большого количества объектов не приводит ли это к глюкам в игре?.

Всё верно, такие себе бесхозные скрытые объекты.

Переместятся.

На NMA в теме сфала есть ссылка на sourceforge.net там обычно и качают.
чего ты вообще поперся на гитхаб)

hs_inventorymove с arg1 равным 5, не?

Так навскидку можно проверять содержимое _curr_stack (0x59E96C) и _target_curr_stack (0x59E948) — для main backpack равно 0, для container равно 1-9 (уровень вложений).

Есть container_exit_ (0x476394) с двумя параметрами: первый равен 2500 для _curr_stack или 2501 для _target_curr_stack, второй указывает режим — 0 (INVENTORY), 1 (INTFACEUSE), 2 (INTFACELOOT) и 3 (BARTER).

не не то, а чего за 5, про такого не написано.
arg1 — Target slot (0 — main backpack, 1 — left hand, 2 — right hand, 3 — armor slot, 4 — weapon, when reloading it by dropping ammo)
ну да ладно, оно все рано не срабатывает когда открываешь сумку, только когда предмет перемещаешь.

ух ты замечательно закрывает) а с проверкой вложености _curr_stack наверное можно в цикле все разом закрыть.
я выбрал проверку на вложенность.

Отправлено: 13 фев 17 23:02
и еще можно ли через двиг выводить текст во время бартера в окно торговли где текст нпс печатается?

Та ладно

И в hookscripts.txt это отражено.

Или можно сделать _curr_stack = 1 и закрыть один раз. Я так здесь сделал:

gdialogDisplayMsg_ (0x445448) с одним параметром указывающим на строку.

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

а такой нет, чтобы сразу принимал текст.

Тогда опаньки, call_offset_v* принимает только int параметры и если указать что-то вроде:

то второй параметр будет скомпилирован как строка и в обработчике будет признан как illegalarg.

Не, попроси Фобоса чтобы через новую sfall_funcX добавил.

Это типа в теории) — а на практике это не работает.
а любое инт число вываливает игру.

Ты кстати в свой эту sfall_funcX переносить будешь?

Вот потому на практике и не срабатывает, что обработчик call_offset_v* понимает только int параметры. Но его можно научить дополнительно понимать и string (просто в вызываемую функцию он будет передавать указатель на неё). Конечно эта "учёба" актуальна если у компилятора скриптов нет жёстких ограничений (он может компилировать такой код).

Да, но пока заморозка же :-p

чего это возвращает — текущий размер заполнения контейнера?

Да.