Не, плана нет ;) Был todo файлик, но сейчас он уже пустой (только что ещё добавил в код с FreeWeight изменение цвета текста на красный при перегрузке).

В Far'е всё делаю, какую он определил — в той и пишу , даже не обратил внимание :-p
Поменял на win.

пусть учат русский)))

Как бы и без Sfall'a модальность окон частично решается скриптово.

Теоретически с помощью имеющихся команд AddRegion и AddRegionProc сделать скрипт и использовать reg_anim_clear(dude_obj) то выходит оно никуда не побежит. хз не проверял надобности не было

В том то и дело что "частично". Про решение с reg_anim_clear я в курсе, оно во всех модах и используется, но заставляет героя "дернутся" повернувшись в сторону курсора. Было бы неплохо вообще заблокировать нажатие на сетку.

А что дает отключение интерфейса и курсора?

Добавил в sfall параметр SkipSizeCheck (в секцию Debugging), последний билд: https://yadi.sk/d/mTRKFKsMexSa2

Если интересно, прошу проверить будет ли работать с модами меняющими ЕХЕшник. Нужно будет еще добавить CRC измененного файла в ExtraCRC.

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

я так понял надо дописать в ini SkipSizeCheck=1 ?
тогда правильнее было бы сразу и crc отрубать, если стоит SkipSizeCheck=1
Проверил все работает.

О, ну это круто тогда.. Но только для модальных окон которые как бы блочат весь интерфейс. Для панелек типа как в некоторых модах это не проканает же? (они всегда доступны, когда доступна обычная панель) Плюс насколько знаю game_ui_disable Отрубает клавиатуру, то есть ты не сможешь закрыть свое окно клавишей Escape или прикрутить к нему другие клавиши.

CRC все равно нужен. На случай если игрок заменит ЕХЕшнит каким-нибудь несовместимым. То есть моддер (или игрок) должен убедится что ЕХЕшник совместим и сознательно вбить его CRC. Так мы избегаем непонятных баг репортов о вылетах на форумах модов...

Ну ды, тут только химичить с AddRegion с "дерганным" героем.
Пойду попробую скриптану с использованием этой связки, скажу потом о результате.

а ну да. все правильно)

Отправлено: 2 мар 15 01:46
Phobos
В общем с AddRegion в связке с game_ui_disable и MouseShape решается вся проблема и нет никакого "дерганья" героя. Так что решение полностью рабочее, даже работает если регион пересекается с кнопкой окна т.е. срабатывает и событие кнопки, правда не совсем разобрался как правильно размер региона задавать оно там как то по хитрому сделано. ладно суть скрипта получается такая(подумаю поймешь)
AddRegionProc("window_reg", none, none, game_ui_disable, game_ui_enable)
а MouseShape нужен для того чтобы вовремя нажатия по окну не пропадал указатель мыши.

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

Кстати ты не в курсе как он задавал размеры региона, я вчера сидел тыкал-мыкал так и не смог правильно создать регион по размеру окна.
AddRegion reg_name {x, y, x, y, x, y, ...} вот и как тут понимать какие x/y куда относятся.

да ну юзаем reg_anim_clear и чихать что оно дергается)

Судя по коду — компилятор принимает любое количество пар координат, т.е. сколько угодно точек. Видимо многоугольник.

хук в официалке будет?

спс разобрался.

Он там давно уже был, старая фича. Если очень интересно, можно выпросить код у Джима.

Вышла 3.6 официалка.

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

то Phobos: в sfall есть небольшой баг тянется наверное еще с древних версий 2х, в общем суть такая если сменить разрешение в игре(hires) без перезапуска и начать игру то sfall не правильно определяет разрешение т.е. функции get_screen_width(), get_screen_height() возвращают не правильные размеры экрана. во такие дела)

Готово ;) Это "релизная" версия dll, но в ней оставлены SkipSizeCheck и ExtraCRC из секции [Debugging].

И теперь баги кликабельности в пипбое исправляются независимо от значения переменной UseScrollingQuestsList.
Само собой ReloadWeaponHotKey удалена.

Update: Поправил оригинальный подсчёт квестов на страницу, к примеру 21 квест раньше показывался на первой странице 1-10, на второй 10-19, на третьей 19-21. Сейчас 1-10, 11-20, 21.

Что-то не очень удачная позиция кнопок...

Такое предложение -вывести настройки x,y для положения кнопок в ini-файл сфала, чтобы можно было настроить под любой мод с измененной картинкой pip-boy.

Почему? Для оригинала отлично, и даже в Неваду вписались. Для Олимпа согласен — не подходит, ну так там кнопки и не нужны если судить по настройкам ini-файла. А какие ещё есть моды со своей картинкой пипбоя?
Были варианты поместить кнопки в 4 и 5 части.

Честно — лень ;)

вот место 4 так и просится на кнопки, но что-то как-то высоковато

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

это пока не нужны.
так что давай не ленись)

Не вписывается в концепт — зачем на сетке кнопки прокрутки :-p И для Невады будет неочень.

Если судить по обсуждениям на форуме Олимпа, то "Олимп 2" будет на новом движке.
И будем честными — вероятность появления нового серьёзного проекта на движке F2 стремится к нулю...

Организационные вопросы мучают — как назвать переменные для ini-файла (QuestsScrollButtons[X|Y]?), какой угол брать за стартовую точку (нижний левый?). А ведь можно вообще каждую кнопку отдельно размещать. Дуристика это :-p

а что на бордюре экрана вписывается в концепт? :D
ну если ты мерил по невадскому пипбою тогда ладно...

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

вот сам же и ответил на вопрос — QuestsScrollButtonsXY=123,346

Не спорю. Но как говориться — "надо вася..."

Конечно, провода же вписываются :-p

Хлопотно, строку разбирать :)
Две переменных — QuestsScrollButtonsX и QuestsScrollButtonsY, с границами 0-618 для X и 0-434 для Y. Всё равно размер окна пипбоя (640x480) зашит в движке.

Перенёс обработку горячих клавиш для кнопок управления пипбоя (1-4) в другое место, а то ранее работали только при UseScrollingQuestsList=1.

Так что-то мне опять не нравится :)
а нельзя ли сделать цвет шрифта веса зеленым а не белым?
и расположить веса не в слотах для предметов, а под картинками чюза и объекта, по мне такое расположение выглядело бы логичнее)

А можно еще оставить и возможность DebugMode ?

Можно, но всё равно нечётко в окне торговли/обмена с сопартийцем.

Не, нельзя — место под картинкой объекта используется для кнопок прокрутки по объектам если их несколько (трупы в одном месте).

Нет смысла, проще сразу отладочную версию собрать — кинул в архив в \debugging.

не, ты не понял я имел ввиду вот так

Спасибо то что мне нужно!
Ну а цвет веса при бартере можно было оставить и белым ибо с зеленый шрифт не сочетается с доской.

Просто ты проверяешь на маленьком шкафе, а ведь есть и более крупные (навскидку сразу могу сделать скрин как раз из Невады — Солт-Лейк, завод ядер-колы, здание с верстаком напротив офиса, полки во второй комнате) и там текст накладывается точно на картинку, а не серый фон. Ещё и придётся дописывать свою процедуру перерисовки части экрана. И опять же следуя стилю нужно и при торговле/обмене с сопартийцем выводить свободный вес не на доске, а под картинками персонажей.

Общая процедура для вывода текста свободного веса, потому цвет меняется везде.
Белый тоже сливается, всегда напрягало. В каком-то старом варианте я менял на чёрный (ну не совсем), выглядело намного лучше.

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

Кушать не просит, почему бы и не показывать :-p
В F2 в качестве временных хранилищ я использовал шкаф в доме Гришэма в Модоке, шкафчик во второй комнате мастерской дочери Вика в Городе Убежище и ещё кучу подобных мест, особенно до появления машины.

Мой рассказ таков, что без бутылки и не понять ;)

В общем, с каждой картой связано 5 типов скриптов (s_system, s_spatial, s_time, s_item, s_critter).
Для активной в данный момент карты каждый тип скриптов хранится в памяти в таком виде:

FirstBlock — указатель на первый блок, а LastBlock — на последний блок скриптов этого типа.
BlockNums — количество блоков скриптов этого типа.
Если BlockNums = 0, то FirstBlock и LastBlock равны 0 и скриптов этого типа нет. Если BlockNums = 1, то LastBlock равен FirstBlock.

В свою очередь каждый блок скриптов (Block_1...Block_3) хранится в памяти в таком виде:

Когда в игре для карты добавляется новый скрипт, то добавляется он в конец последнего блока (увеличивая количество скриптов в этом блоке) или если количество скриптов равно 16 в этом блоке, то создаётся новый блок и скрипт добавляется в него.

При смене карты её состояние записывается в имя_карты.sav, который потом будет использоваться при записи игры (для текущей карты файл этой карты перезаписывается в момент записи игры). Важно то, что записываются все скрипты (каждого типа скриптов) связанные с картой, но сначала блоки чистятся от "неактивных" скриптов (я не стал разбирать структуру скриптов и точно не знаю почему некоторые скрипты не записываются, поэтому называю их "неактивными" они связаны с игроком) с помощью обмена содержимого "неактивного" скрипта с первым доступным "активным" скриптом из конца списка. Само собой подсчитывается количество записываемых "активных" скриптов, но не трогается содержимое остальных блоков скриптов — количество скриптов в блоках и указатели на следующий блок (указатели после записи карты будут нужны для освобождения памяти).

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

Лучше на примере — есть 3 блока скриптов, в 1 и 2 по 16 скриптов, в 3 один скрипт. Всего 33 скрипта, которые после чистки 4 "неактивных" скриптов станут 29. Движок должен записать первый блок, изменить количество скриптов во втором блоке и затем записать его.
В действительности, поскольку не был изменён указатель на последний блок, движок записывает два блока, затем обнаруживает что в третьем блоке "неактивный" скрипт и нигде не изменяя количество скриптов завершает обработку скриптов этого типа.
Что приводит к некритической ошибке (с поправкой на то, что в действительности представляют из себя "неактивные" скрипты). Если проверить любой из своих сейвов, то с большой вероятностью найдётся несколько некритических результатов этого бага (но карта будет рабочая). Если воспользоваться утилитой TooManyItemsBug:

Ошибка становится критической когда количество "неактивных" скриптов сдвигает список на один или более блоков и до чистки блоков было больше двух. Для нашего примера пусть будет 20 "неактивных" скриптов — должен быть записан только первый блок с 13 скриптами, но движок запишет ещё второй блок (ведь указатель на последний блок не поменялся), который и будет являться причиной зависания при загрузке этой карты. Для TooManyItemsBug:

Update: "Неактивные" скрипты — это скрипты связанные с игроком (ну там скриптовые вещи в инвентаре).

А вот описание бага на английском:

© Per Jorner, The Nearly Ultimate Fallout 2 Guide v1.2

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

Не совсем понял что-ты сделала с окошком... ты что его убил :'(

Вроде того :-p
Окошко вызывается когда количество коробок патронов больше 1 и возвращает введённое количество в диапазоне 1-макс.количество коробок. Вместо вызова окошка сразу возвращается макс.количество коробок.
Естественно это только при перетаскивании патронов в оружие — в остальных случаях (сумка, багажник или торговля) окошко вызываться будет.

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

Это ты зря!!!
Ты не подумал о ситуации когда у игрока допустим есть 3 пачки патронов, 2 из них он захочет зарядить в пулемет(магазин 3 пачки), а одну оставить, так как у него во второй руке пистолет с тем же калибром патронов который потом в бою нужно будет перезарядить, а нечем!!!! сечешь)

Притянуто за уши, но разумно (ох уж эти любители создавать себе проблемы) ;)

Поправил — если макс.количество пачек патронов больше значения переменной ReloadReserve (по умолчанию = 1), то возвращает "макс.количество пачек минус ReloadReserve", или 1.

Не :-p