Ну была вечная версия , назовём её 1.0. Версией 1.1 она стала после добавления фиксов из твоего поста.

Спасибо ;)
Да, ini с твоей помощью на английском будет.

Это не решит проблему c "infinite free running". Движок не телепат, он не знает для чего реальный игрок нажал клавишу "A" или кликнул на оружие — действительно для сражения (нажатие "A"/клик на оружие не вводит игрока в "настоящий" бой и именно поэтому можно нажать Enter и завершить бой. Настоящий бой начинается после агрессивного действия со стороны игрока — у жертвы есть переменная who_hit_me и в неё заносится кто обидчик) или эксплоита с передвижением (потому что в пошаговом режиме скрипты потенциальных противников не обрабатываются).

Подойти/подкрасться на расстояние удара и рвануть в бой, не? :-p
Непонятно почему такой сыр-бор из-за FakeCombatFix, отключить его (= 0) и делов-то.

Понятно. Ладно, тема закрыта.
Кстати, ты github собираешься юзать или пока все через fallout.ru и дропбох?

Позже.

Весьма непросто, разве только полностью будильник в пипбое переписать. И всё равно останется проблема отображения опций, потому что нет строчек в pipboy.msg.

Добавил фикс из F2-версии — BlackSkilldexFix (по умолчанию включён). Если проблема не исчезнет, то предоставь пожалуйста сейв игры.

Спасибо проблема исчезла.

Посмотрю ;)

Отправлено: 8 июл 15 01:30
Для F1-версии добавил SaveInCombatFix и SuperStimExploitFix.

Так-то я сделал — секция Frms в Elevators.ini с переменными Image#. Но кажется мне что вполне сработала бы замена на свои frm с указанием в Image правильного номера лифта (frm которого будут использованы).

Drobovik

Так взять твою компиляцию (readme_rus.txt) или пройтись по теме и повыдёргивать изменения с датами?

СПС. Попробую. Потом напишу удачно или нет)

Нет! Я добавляю новые FRM в lst, а оригинальные frm тоже используются. Лифтов то по дефолту всего 24, а картинок то меньше.

А, тогда мне надо допилить чтобы больше было, сейчас 24, сделаю 50 как и количество лифтов.

Кстати я так и не вдуплил как добавлять больше чем 24 лифта, ведь скриптовая команда Elevator(x) не принимает параметр типа больше чем 23.

И еще не большое требование к ddraw.ini
Делай небольшой разграничение твоих добавленных настроек от оригинальных, раньше ты писал на русском комменты, а теперь уже на забугорском, и понять где ты добавил свои настройки сложно, ибо я переношу новые настройки в свой ini. В общем добавь сепаратор чтоб не путаться :)

Кстати вот эти настройки ты добавил, или они по дефолту в сфале были?
QuestsScrollButtonsX=220
QuestsScrollButtonsY=229

Можешь от readme_rus.txt исходить

Можно Notepad++'ом или Winmerge'ом сравнить с оригинальным 3.6 ddraw.ini и добавить строки;)

Если работает, то не буду добавлять — уж больно там хлопотно.
Но даже сейчас можно делать хитрые комбинации:

Полагаю что ограничение в 23 для Elevator(x) снимается (= 50) после подключения Elevators.ini.

Добавил по твоей просьбе :-p
В ini новые команды, если они есть, добавляются в конец своей секции.

Нельзя, разве только делать версию sfall для маппера.

Drobovik

Ok, как прокнет ;)
Сделал, кстати, свои гиты. А то зашёл через другой комп незареганным и не могу попасть в свои форки, wtf.

т.е. если новые добавить не в свою секцию sfall их не увидит?

В принципе да, это боле надежно)

Если, к примеру, DontTurnOffSneakIfYouRun перенести из секции [Misc] в секцию [Input], то да — не увидит.

Ну раз такое дело, может можно еще подвигать полоску отображающую количество патронов на панели интерфейса — это мой маленький каприз. :))

Может кто сможет мне внятно объяснить, что делает, и для чего эта ерунда в sfall'e?

Не-не, в создании тех кнопок я принимал участие ;) Тут же неизвестно что, и может возникнуть конфликт с High Resolution Patch — там можно с помощью ALTERNATE_AMMO_METRE изменить вид полоски. Может чуть позже, особенно если напомнишь :-p

Drobovik

Вроде того, в основном для лучшей "читаемости" кода. Но сейчас есть небольшие изменения: из ddraw.ini удалены переменные BlackSkilldexFix и DodgyDoorsFix, а в F2-версии ещё JetAntidoteFix и SpecialUnarmedAttacksFix — это чистые багфиксы, их постоянное включение не вызывает побочных эффектов, а потому существование переменных в ini-файле бессмысленно. Теперь они перманентно включены. Надо будет ещё подобные фиксы проверить...
И в архивы добавились русские ченжлоги, у каждой версии свой ;)

Тогды не надо.
Ибо если сдвинуть при помощи sfall'а, а кто будет сдвигать в HRP?... исходников то нет.

Дабы избежать потенциальных проблем для юзеров, незнакомых с sfall'ом

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

Блин, я как раз .txt в .ru поменял предполагая что может повиться и .en (не моими усилиями) :-p

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

Отправлено: 12 июл 15 08:18
Исправил невозможность продажи счётчика Гейгера и стелсбоя если ими хоть раз воспользовались.
По задумке авторов если определённые вещи хоть раз использовали, то продать их потом нельзя. Что вполне логично для, к примеру, фонарика, но для счётчика/стелсбоя спорно (и просто раздражает). При этом в F2-движке есть (а в F1 нет) кусочек кода, который должен позволить продавать использованный счётчик, но он настолько криво написан, что никогда не сработает.
Может нужна переменная для этого дела?

Для F1-версии добавил возможность подключения внешнего файла, с помощью которого можно получить доступ к таблице квестов в движке и таким образом сделать видимыми в пипбое свои квесты. Только их ещё в pipboy.msg нужно будет добавить. Но думаю это новшество может заинтересовать только Sduibek'а :)

А цена тоже уменьшается?
По задумке наверное авторы не хотели заморачиваться со стоимостью б/у предметов при продаже, вот и выключили возможность их продавать. мое предположение.

хз какие у вас там квадратики — никогда таких их не наблюдал при разрешении более 800х600. Используйте HRPatch для смены разрешения.

Фуу, быдловатая школота...

Ты бы для начало нормально настроил Sfall & HRP.
Не ну если тебе нравится играть с замыленным изображением этих квадратиков, то это твое право. У каждого свои вкусы. :)

Во первых мне уже тридцатник. Во вторых что можно настраивать в Sfall & HRP? В первом можно только режим 8бит и ДХ9 выбирать, ну и размер окна, а второй тупо "растягивает" картинку. Ну а "замылевают" изображение ВСЕ современные игры.

Я просто высказал пожелание. Сраться со всякой

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

Судя по твоим скринам нужно в sfall'e вырубить растягивание картинки, и использовать только HRP.
У меня при разрешении в игре 1024x768 и разрешении монитора как у тебя 1280x1024, картинка игры выглядит намного лучше твоего скрина с HRP, да и не замыленно так сильно как при sfall'e c TextureFilter.

Crafty
В двиге F2 есть один незначительный баг.
Может замечал такое — если зайти в локацию и побегать по картам локации, то после выхода на глобал.карту маркер игрока на мировой карте немного сдвигается по диагонали в низ, и иногда так получается что сдвигается аж за пределы круга города.
В общем это на твое усмотрение фиксить это или нет.

Ну, я имел в виду changelog.ru.txt), а потом будет changelog.en.txt

Я думаю нужна. Тут явно пахнет несогласием некоторых игроков по этому пункту.

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

Да я уже такого намудрил что и не отследить — поменял конструкции вида "ds:[0x6610B8]" на "ds:[_obj_dude]" и подобные. И переименовал процедуры в исходниках на движковые названия из IDB-базы.

Не могу ответить (да и прочитать, хорошо хоть мыло пришло) на гитхабе — тестировал визуально пока менял названия, потом ещё раз уже с помощью "git log -p" (отличная штука).

Отправлено: 15 июл 15 08:16
alexandert

В ГлобалМоде очень старая версия (2.1a?). С хайрез патчем же лучше (хотя бы ради увеличенного размера карты), а без него это 640x480 растянутые до границ экрана и фильтр поэтому нужен — размазывать квадратики.

Отправлено: 15 июл 15 08:26
Fakeman

Нет.

Так и задумано, и нормально что за пределы круга сдвигается — фактически границы города на карте мира ограничены не кругом, а квадратом, в котором этот круг находится.

Отправлено: 15 июл 15 08:29
Drobovik

Будет CanSellUsedGeiger.

Странная какая-то задумка, интересно что курили разработчики)))
Он же сдвигается так долеко что после выхода уже в локацию не попадаешь и приходится заходить в круг, вот о чем я.
Может по задумке маркер должен был сдвигаться в центр этого квадрата, но в коде ошибка?.

Не согласен. Массивы в старом стиле потенциально опасны и замусоривают сохраненки. И какие многие моды их используют? Из всех тех что я видел, почти никто не использует, за исключением временных массивов (temp_array), которые данная настройка не касается.

Ну так для этого есть сообщество, мог бы спросить. Я форки юзал, проблем вроде не было, такой же репозиторий, отличие в том что он ссылается на корневой. И помоему только с форков можно делать merge-pull request, но я не уверен.

Это ты правильно сделал, я хочу это изменение перенести в нашу версию. Но вот вопрос, каков твой дальнейший план по рефакторингу? :)

PS: филосовский вопрос, а почему бы не использовать больше С++ для работы с движком фола в sfall чем ASM? (я имею ввиду юзать структуры, полученные реверсингом, работать с нормальными массивами, полями структур и т.п. вместо смещений). И вижу что были удалены некоторые Wrapper-ы движковых функций...

Насколько далеко? Вот здесь, если кликнуть по треугольнику, я попадаю в Дыру.

Phobos

Что-то поменять, что-то поправить, но конкретных планов нет :-p

Так я же понимаю C[++] на простейшем уровне, а ASM уже достаточно вспомнил. Мне так проще ;)

Поэксперементируй со small & medium радиусами кружков, с large проблем вроде как не было.

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

Я считаю больших кусков кода на ASM в принципе не должно быть в sfall, в идеале его нужно весь заменить на С++ с использованием структур/переменных/процедур движка.

Не подскажешь, где в коде эти фиксы?

Нашел вот это, но сходу не понять, что именно они фиксят:

По поводу

Твой фикс не лечит баг. Тут на самом деле не в уровне дело. Повторяется легче:
1) даем любому напарнику 2 одинаковых брони
2) просим надеть один из комплектов
3) просим снять броню через диалог, но внезапно(!) броня не снимается
4) просим второй раз, со второго раза снимется, но статы снизятся 2 раза. Не только класс брони, но и все остальные (DT/DR и проч.)
Проверял через f2se редактор сейвов.

Почему это расценено как баг? Просто окно диалогов вмещало лишь 8 строк с ответами. Больше похоже на фичу.

Что делает этот "фикс" и почему он в Bugs.cpp ?

У Drobovik'а же в Fallout Database можно скачать. Добавлю ссылку в первый пост...

Отправлено: 19 июл 15 15:59
Fakeman

Как-то так ;):

Отправлено: 19 июл 15 16:57
Phobos

item_d_check_addict_hook меняет оригинальную процедуру, которая всегда использует данные игрока, на использование данных настоящих персонажей при проверки зависимостей.
item_d_take_drug_hook снимает зависимость после использования противоядия, ну а item_wd_process_hook делает зависимость к винту вечной (до принятия противоядия).

Это описание бага "множественного снятия брони сопартийца через диалог, если у него в сумке есть такая же броня". Фикс для него в correctFidForRemovedItem_hook из Inventory.cpp.

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

Перерисовываемый участок обмена равен 64 пикселя, для выводимой строки с весом вместо 64 используют 80, что в определённых ситуациях (измени в INVENTRY.MSG строку #30 на что-то вроде "Вес вещей") может привести к мусору на участке обмена.

Отправлено: 19 июл 15 19:20
Исправил вывод в окне монитора количества полученных очков опыта с учётом бонуса от взятого перка 'Прилежный ученик' после убийства врагов, кражи или случайных встреч на карте.
Исправил баг превращения сопартийцев в тыкву контейнер, ну и добавил переменную CanSellUsedGeiger для контроля возможности продажи "Счетчика Гейгера"/"Невидимки" после использования.

Для F2-версии из ddraw.ini удалил переменную WieldObjCritterFix, причина аналогична удалению BlackSkilldexFix и ко.

В оригинальной функции я вижу была работа с глобальными переменными. Если не ошибаюсь, движок проверяет есть ли зависимость по значению глобальных переменных игры.
Правильно ли я понимаю, что для отслеживания зависимостей в движке предусмотрена некая структура данных для каждого персонажа? Ты сделал так что она теперь используется всегда, тогда как раньше в некоторых местах проверялись только глобальные переменные? Но они по прежнему используются?

И кстати, в чем отличие от JetAntidoteFix?

А зачем? В оригинале она не вечная?

Может стоит перенести в Bugs.cpp?

Зачем был выпилен весь предыдущий код из PartyControl.cpp? До этого хотя бы было очевидно как все это работает и человек со стороны мог что-то поменять. Теперь остались только стены ASM кода с комментариями на русском... Понятно что могло быть хуже (запутанный ASM код, 0 комментариев), но зачем удалять то что работает?

К слову о коде, в чем отличие между

И простым

?

На все вопросы ответ — да ;)

Фикс для возврата true из процедуры если использовалось противоядие, чтобы оно было удалено из инвентаря.

Нет, там через GVAR создавалась видимость вечности.

Там общая процедура с армор модом, лень разбивать.

Беспредельщик же ;-p

3 байта против 5 :-p

Отправлено: 20 июл 15 19:42
Drobovik

Спасибо большое :)
Добавь ещё в начало файлика благодарность себе, что-то вроде "Большое спасибо Drobovik'у за перевод на английский :)"