Сообщений в теме: 1246

[Fakeman]

Можно! но это скорее не мод, а надстройка к движку.

[Foxx]

Del

Это сообщение отредактировано Foxx - 2 декабря 2016 | 15:58

[Tdv]

@Crafty

Просьба #1.
Добавить в "ddraw.ini" новую опцию (RetroactiveStats=[0/1]), которая бы делала влияние статов (ST, EN; IN) на производные статов (HitPoints/level; SkillPoints/level) ретроактивным, то есть имеющим обратную силу.

Причины:

• основная — с ретроактивными статами исчезает необходимость их наискорейшего повышения (постоянного, а не временного), если игрок не хочет потерять в очках здоровья/навыков только потому, что не сразу увеличил Силу/Выносливость/Интеллект;
• дополнительная — небольшое повышение полезности Выносливости (например, можно будет создать персонажа с нечётным показателем EN, а после поднять её на 1, не потеряв при этом в HP).

Одноразовые прибавки при постоянном увеличении характеристик (например, через перк или квестовую награду):

CODE

• ST+1 = +1 HP • EN+1 = +1*(Level-1) HP [только если новый показатель EN чётный] • IN+1 = +2*(Level-1) SP

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

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

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

CODE

• [было]  HP per level = EN/2+2 • [стало] HP per level = EN

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

CODE

• [было]  EN+1 = +1*(Level-1) HP [только если новый показатель EN чётный] • [стало] EN+1 = +1*(Level-1) HP [при любом показателе EN]

Это сообщение отредактировано Tdv - 17 декабря 2016 | 02:53

[Fakeman]

Tdv
Просьба №1 какая-то не совсем понятная.

Второая просьба решается скриптово, в глобальном скрипте сфалла,
но я так понимаю для тебя это непостижимая наука, и хочется просто оперировать простыми цифрами в конфигах?

QUOTE

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

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

[Tdv]

QUOTE (Fakeman)

Просьба №1 какая-то не совсем понятная.

Увеличение 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):

CODE

#1:        LK+2  #2:  IN+1, LK+1

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

CODE

#1:  10 IN (25 SP/lvl); 8 LK  #2:   9 IN (23 SP/lvl); 9 LK

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

CODE

#1:  25*(12-1) = 275 (SP)  #2:  23*(12-1) = 253 (SP)

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

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

QUOTE (Fakeman)

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

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

QUOTE (Fakeman)

хочется просто оперировать простыми цифрами в конфигах

QUOTE (Nordan)

mod_skill_points_per_level просто изменяет значение получаемых скиллопоинтов на значение операнда, в нее нельзя записать именно "формулу"

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

Это сообщение отредактировано Tdv - 17 декабря 2016 | 02:55

[Fakeman]

QUOTE

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

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

QUOTE

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

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

QUOTE

Новое значение HP per level влияет только на последующие уровни, на предыдущие уровни оно не влияет.

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

QUOTE

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

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

QUOTE

— если бы характеристики влияли на свои производные ретроактивно, то после получения награды (IN+1) на 12 уровне персонаж #2 сразу бы получил причитающиеся ему 24 SP.

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

QUOTE

— если не спешить и получить награду позже, то упущенная выгода будет ещё больше, то есть Experience (Очки Опыта) становятся вредны для игрока, что само по себе уже нонсенс;

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

QUOTE

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

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

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

QUOTE

в итоге, хоть у обоих персонажей к 12 уровню будут абсолютно идентичные характеристики (10 IN, 10 LK), упущенная выгода персонажа #2 составит (25-23)*12 = 24 (SP)

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

Это сообщение отредактировано Fakeman - 14 декабря 2016 | 18:33

[Tdv]

QUOTE (Fakeman)

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

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

QUOTE (Fakeman)

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

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

QUOTE (Fakeman)

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

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

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

QUOTE (Fakeman)

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

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

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

QUOTE (Fakeman)

с ретроактивностью стат ты ломаешь фоловскую систему прокачки игрока, и на выходе мы получим тупо буст к SP и HP.

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

QUOTE (Fakeman)

Имхо закон ретроактивности вообще лишняя заморочка.

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

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

Это сообщение отредактировано Tdv - 17 декабря 2016 | 02:58

[Fakeman]

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

CODE

...  test [ecx+0x74], eax                      // Уже подсвечивается?  jnz  nextObject                           // Да  // проверить ObjSubItem=1 - если этот item равен контейнеру то подсвечивать его серым  push eax  mov  eax, ecx  call item_get_type_  cmp  eax, item_type_container             // item_type_container?  pop  eax  jnz  checkNoHighlight                     // Нет  cmp  TurnHighlightContainers, eax         // Подсвечивать контейнеры?  je   nextObject                           // Нет                      cmp  word ptr [ecx+0x64], PID_CAR_TRUNK   // исключить pid багажника из подсветки  je   nextObject  shr  edx, 2                               // светло-серый  jmp  Highlight checkNoHighlight:  test [ecx+0x25], dl                       // Установлен NoHighlight_ ?  jnz  nextObject                           // Да - не подсвечивать item если у него установлен флаг Highlight:  mov  [ecx+0x74], edx nextObject:  ...

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

Это сообщение отредактировано Fakeman - 21 декабря 2016 | 15:10

[Foxx]

Crafty, а можно сделать поддержку gl_***.int и hs_***.int скриптов у sFall1?

[Phobos]

@Tdv:

QUOTE

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

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

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

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

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

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

QUOTE

конечного пользователя вроде меня, а не для разработчиков sfall'а

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

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

QUOTE

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

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

Это сообщение отредактировано Phobos - 26 декабря 2016 | 08:36

[agris]

Извините за мой бедный русский, я носителем английского языка, который использует translate.google.com.

Я пытаюсь настроить мой Fallout 1, как мой Fallout 2: окно, занимающей весь мой рабочий стол (1920х1200) рендеринга Fallout 1 в 960x600, чтобы сохранить внешний вид искусства. Для Fallout 2 / Воскресением 1.5, это легко.

ddraw.ini устанавливается на:

CODE

[Graphics] ;Set to 0 for 8 bit fullscreen ;Set to 4 for dx9 fullscreen ;Set to 5 for dx9 windowed ;A dx9 mode is required for any graphics related script extender functions to work (i.e. fullscreen shaders) ;Modes 1, 2 and 3 are no longer supported Mode=5 ;If using a dx9 mode, this changes the resolution ;The graphics are simply stretched to fit the new window; this does _not_ let you see more of the map ;If set to 0, use fallout's native resolution GraphicsWidth=1920 GraphicsHeight=1200 ;Set to 1 to do the palette conversion on the gpu ;Set to 2 to do the palette conversion on the cpu ;Set to 0 to pick automatically ;GPU is faster, but requires v2.0 pixel shader support GPUBlt=1 ;Set to 1 to allow using 32 bit graphics for talking heads ;Requires graphics mode 4 or 5, and gpublt set to 1 Use32BitHeadGraphics=0

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

в f1_res.ini

CODE

[MAIN] ; Affects Windows Vista/7/8 and above. Allows hi-res patch settings to be changed without admin privileges ;  if installed in the "Program Files" directory. ; When UAC_AWARE=0 the hi-res patches settings will be stored in the game folder as usual. ; When UAC_AWARE=1 the hi-res patches settings will be stored in the users roaming app data folder. ; For Vista this is usually "C:\Documents and Settings\'your user name'\Application Data\Fallout". ; For Windows 7/8 this is usually "C:\Users\'your user name'\AppData\Roaming\Fallout". UAC_AWARE=0 ; Set GRAPHICS_MODE=0 to enable Basic mode which supports resolution change only. ; Set GRAPHICS_MODE=1 to enable Direct Draw 7 mode. ; Set GRAPHICS_MODE=2 to enable DirectX9 mode. GRAPHICS_MODE=0 ; Set SCALE_2X=1 to scale the game x2. ; Note: This will increase the minimum resolution to from 640x480 to 1280x960. SCALE_2X=0 ; Set the Fullscreen resolution here. SCR_WIDTH=960 SCR_HEIGHT=600 ; Set the Fullscreen colours here. ; 8 for 8bit colour output (original) ; 16 for 16bit colour output (set only if your not using Sfall with graphics modes 4 or 5) ; 32 for 32bit colour output (set only if your not using Sfall with graphics modes 4 or 5) COLOUR_BITS=8 ; Set the Fullscreen refresh rate here. ; Set REFRESH_RATE=0 for driver default. REFRESH_RATE=0 ; Set WINDOWED=1 to enable windowed mode. WINDOWED=0 ; Set WINDOWED_FULLSCREEN=1 to play fallout in a borderless fullscreen top level window.(requirers WINDOWED=1) WINDOWED_FULLSCREEN=0

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

Я написал более подробное описание здесь: http://www.rpgcodex....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 хорошо вместе?

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

QUOTE

Fallout 1.0 manual install from CD Team X 1.2.1 Team X 1.3.5 Fallout 1.3.5 NPC Mod [optional] no armor mod [optional] exclusive of below, Wasteland Ghost RP mod, includes below plus more content [optional] Wasteland Ghost invation mod (FO1RMp1v10b2), doesn't contain pt2 in above's readme Fallout High Resolution Patch 4.1.8. sfall1_v1.7.6_unofficial_by Crafty -> requires modifying ddraw.ini line ExtraCRC=0xf60e71e2 when using RP mod

Я сделал так, чтобы "установить" высокого разрешения патч (через 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:

CODE

[Graphics] ;Set to 0 for 8 bit fullscreen ;Set to 4 for dx9 fullscreen ;Set to 5 for dx9 windowed ;A dx9 mode is required for any graphics related script extender functions to work (i.e. fullscreen shaders) ;Modes 1, 2 and 3 are no longer supported Mode=5 ;If using a dx9 mode, this changes the resolution ;The graphics are simply stretched to fit the new window; this does _not_ let you see more of the map ;If set to 0, use fallout's native resolution GraphicsWidth=1920 GraphicsHeight=1200 ;Set to 1 to do the palette conversion on the gpu ;Set to 2 to do the palette conversion on the cpu ;Set to 0 to pick automatically ;GPU is faster, but requires v2.0 pixel shader support GPUBlt=1 ;Set to 1 to allow using 32 bit graphics for talking heads ;Requires graphics mode 4 or 5, and gpublt set to 1 Use32BitHeadGraphics=0

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

CODE

[MAIN] ; Affects Windows Vista/7/8 and above. Allows hi-res patch settings to be changed without admin privileges ;  if installed in the "Program Files" directory. ; When UAC_AWARE=0 the hi-res patches settings will be stored in the game folder as usual. ; When UAC_AWARE=1 the hi-res patches settings will be stored in the users roaming app data folder. ; For Vista this is usually "C:\Documents and Settings\'your user name'\Application Data\Fallout". ; For Windows 7/8 this is usually "C:\Users\'your user name'\AppData\Roaming\Fallout". UAC_AWARE=0 ; Set GRAPHICS_MODE=0 to enable Basic mode which supports resolution change only. ; Set GRAPHICS_MODE=1 to enable Direct Draw 7 mode. ; Set GRAPHICS_MODE=2 to enable DirectX9 mode. GRAPHICS_MODE=0 ; Set SCALE_2X=1 to scale the game x2. ; Note: This will increase the minimum resolution to from 640x480 to 1280x960. SCALE_2X=0 ; Set the Fullscreen resolution here. SCR_WIDTH=960 SCR_HEIGHT=600 ; Set the Fullscreen colours here. ; 8 for 8bit colour output (original) ; 16 for 16bit colour output (set only if your not using Sfall with graphics modes 4 or 5) ; 32 for 32bit colour output (set only if your not using Sfall with graphics modes 4 or 5) COLOUR_BITS=8 ; Set the Fullscreen refresh rate here. ; Set REFRESH_RATE=0 for driver default. REFRESH_RATE=0 ; Set WINDOWED=1 to enable windowed mode. WINDOWED=0 ; Set WINDOWED_FULLSCREEN=1 to play fallout in a borderless fullscreen top level window.(requirers WINDOWED=1) WINDOWED_FULLSCREEN=0

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....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:

QUOTE

Fallout 1.0 manual install from CD Team X 1.2.1 Team X 1.3.5 Fallout 1.3.5 NPC Mod [optional] no armor mod [optional] exclusive of below, Wasteland Ghost RP mod, includes below plus more content [optional] Wasteland Ghost invation mod (FO1RMp1v10b2), doesn't contain pt2 in above's readme Fallout High Resolution Patch 4.1.8. sfall1_v1.7.6_unofficial_by Crafty -> requires modifying ddraw.ini line ExtraCRC=0xf60e71e2 when using RP mod

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.

[Crafty]

QUOTE (Fakeman)

И это зачем закомментил, или это по дефолту так выключено? я тут 32 поставил так звуки не прерываются если их одновременно много проигрывается

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

QUOTE (Fakeman)

Все забывал тебе написать про еще один неприятный баг связанный с multihex криттерами

QUOTE (Tdv)

Добавить в "ddraw.ini" новую опцию (RetroactiveStats=[0/1])

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

QUOTE (Foxx)

а можно сделать поддержку gl_***.int и hs_***.int скриптов у sFall1?

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

QUOTE (agris)

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

Try latest version.

[Fakeman]

QUOTE (Crafty)

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

До весны как потеплеет?

[Crafty]

QUOTE (Fakeman)

Список багов от Хитрого

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

QUOTE (Fakeman)

QUOTE (Foxx) Заметил такую вещь, если добавить "pip-boy" в самом начале игры PipBoyAvailableAtGameStart=1, то ГГ сразу одет в голубую пижаму Надо бы вернуть как было.

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

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

QUOTE (Fakeman)

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

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

CODE

1. Определить "шанс_попадания" в часть тела с учётом штрафа от Body_Uncalled. 2. Замена Body_Uncalled на Body_Torso. 3. min = "шанс_попадания", max = get_critter_stat(source, STAT_crit_chance) - штраф от Body_Torso.

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

[Fakeman]

QUOTE

При разных значениях Body_Uncalled и Body_Torso и неприцельном выстреле будет погрешность, не очень заметная, но будет:

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

QUOTE

Оригинальная реализация PipBoyAvailableAtGameStart=1 имеет логическую ошибку — переменная включается после загрузки карты в начале игры.

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

Это сообщение отредактировано Fakeman - 2 февраля 2017 | 17:15

[Crafty]

QUOTE (Fakeman)

Тогда нужно было оставлять Body_Uncalled вместо Body_Torso(они же там друг на друга завязаны) чтоб в заблуждение не вводило.

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

QUOTE (Fakeman)

И сопутствующий вопрос эти модификаторы действуют только для игрока, или для партийцев тоже?

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

QUOTE (Fakeman)

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

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

QUOTE (Fakeman)

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

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

QUOTE (Pyran)

Все знаем, что в игре, гг в костюме 13-го, но ни как это не обосновывается (на сколько я знаю). Так вот, используя sFall это легко правится. И в обычном sFall (от Timeslip) все хорошо, а вот у Crafty, при выставлении "пипбой на старте игры", гг при любом раскладе будет одет в костюм 13-го

Во-1:

QUOTE

;disabled to work with Resurrection ;PipBoyAvailableAtGameStart=0

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

[Fakeman]

QUOTE

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

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

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

Это сообщение отредактировано Fakeman - 3 февраля 2017 | 01:15

[Crafty]

QUOTE (Fakeman)

я думал оно только для гг, выходит пользоваться ими в ini особо и нельзя.

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

QUOTE (Fakeman)

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

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

QUOTE (Fakeman)

или вообще отрубить этот задник(но я как полагаю что будет оставаться шлейф от крутящегося гг).

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

[Fakeman]

спс за адреса.

QUOTE

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

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

[Crafty]

QUOTE (Fakeman)

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

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