В этом и был смысл — увеличить скорость времени без увеличения скорости анимации, чтобы действия в игре выглядели реально по игровому времени — пробежался от дома к дому за 10 секунд игрового времени, а не за 1 секунду.
Мобы не дёргаются даже при 1000, разговаривают как и раньше через определённый промежуток игрового времени. И да, по сути TimeScale и SpeedMultiInitial — масло масляное ;-p

В F2 это 07desert.

А как ещё можно ускорить время не затрагивая тики, если последние и являются временем.
Прочитал оригинал:

И сделал так же.

Так и есть.

Ну я как Профессионал с большой буквы в этом деле)) скажу, что нужно сделать переменную в которой тики будут вычисляться по формуле: Tics X TimeScale = NewTics
(но я так понимаю будет переполнение переменной раньше времени)
NewTics — это тики которые нужны будут для времени в пип-бое. (не в курсах как там эти тики преобразуется в формат ЧЧ:ММ ДД/МM/ГГГГ).
При этом функции game_time_hour/get_day/get_month должны по видимому брать тики из новой переменной.

Еще вариант поковырять код который преобразует тики в формат времени для пип-боя и сделать там множитель равный TimeScale.

при 100 скриптовые у которых перемещение связанно через тики на таймере дергаются как под током))
и чтобы это исправить нужна проверка на AnimBusy

Имя параметру логичнее было бы дать TikcsSpeedMulti :)

Не понимаю что в итоге должно выйти, причём тут пипбой и что ты ожидал увидеть. Приведи практический пример.

Тики содержатся в целочисленной беззнаковой (unsigned int, [0, +4 294 967 295]) переменной (_fallout_game_time) и десять раз в секунду увеличиваются на единицу. В понятный формат времени тики преобразуются простейшими делениями из расчёта значений:

Потом к году прибавляется 2241, к месяцу 6 и к дню 24.

Не обязательно, посмотри как в том же ECBDYGRD.SSL сделан 11 sequence.

Ожидал увидеть, что скорость тиков останется такой-же, а время будет будет идти быстрее.
Смотри сейчас 1 сек равна 10 тикам соответственно у нас есть возможность влиять на время без увеличения скорости тиков, просто меняем константу которая указывает сколько в секунде тиков. (в движке же это заложено, не с потолка же они взяли 10 тиков).
К примеру ONE_GAME_SECOND равна 5 тикам, получаем прирост времени х2 при тех же количествах тиках в переменной _fallout_game_time а один игровой час(ONE_GAME_HOUR) должна будет равняться 18000 тикам.

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

"А как ещё можно ускорить время не затрагивая тики, если последние и являются временем."
Твой способ требует ненужных усилий по изменению движка и дополнительной правки скриптов (game_time + ONE_GAME_SECOND) при каждом изменении TimeScale, а единственный, помимо увеличения скорости течения времени, "профит" от всего этого — увеличение лимита игрового времени (13*TimeScale). И это всё равно автоматически не решает проблему с анимацией в скриптовых сценках.

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

разве должны быть какие-то проблемы, скорость и количество тиков(10:1) в скриптах остается такой же.

Ладно завязываем эту тему)

Так даже с этой позиции в разы проще использовать вариант с увеличением частоты прироста тиков, при этом один раз скомпилировать существующие скрипты с дополнительными проверками на anim_busy, чем каждый раз при изменении TimeScale перекомпилировать всё.

Поэтому вопрос, возможно ли расширить указатель на индекс lst до полных 2-x байт (16 бит) для Тiles (реально не хватает 4к изображений :) )
Сам формат карт вроде как поддерживает сохранение в нем 16-битого указателя на индекс фрм'ки.

Но в движке и маппере не учитывает эти 4 бита и показывает нам черную дырку в плитке если значение указателя больше 0FFF, можно это починить? (ну и соответственно в маппере то-же самое.)

Я тут пытался кое чего поискать — но сам понимаешь ассемблер это не моя стихия) Вот есть такое очень похожее на нашего пациента

логическая операция И, сдвиг на 12 бит и проверка результата — если пациент здоров то по видимому рисуем тайл.
потом ниже кодом идете обнуление старших 4 битов

Я убил jnz выше nop'пами — тайлы пола появились, но старшие 4 бита все равно не учитываются. (и как позже выяснилось, тайлы пола все равно не дает рисовать HRP с ним черная дыра).
Крыша кстати изначально показывается, но 4 бита где-то обнуляются и показывается тайл начиная с первого индекса ну ты понял, а изменение кода на and edx, FFFFh не помогает. если в режиме отладки проверить рег. edx то там как раз то число что записано в карте вида RRTT.
Я там все что нашел по исправлял(исправлял прямо в exe) а толка никакого) в общем нид хелп!
И как быть с HRP?

Не очень хочу заниматься DirectX'овскими плюшками, в общем не в приоритете это... :-p

mood учитывается только если не используется говорящая башка (head = -1).
У башки реакция хранится в нулевой локальной переменной её скрипта, и настроение вычисляется с помощью local_var(0) из скрипта цели:

Посмотрю сначала у себя, там дофига менять... Если выйдет, то будет 16384 вместо 4096. Ну и HRP может всё похерить.

Я вас понял. :) вот это конечно новость для меня. как кирпич на голову.

С чем связанно именно 16348 а не 65535? для чего 1 бит оставлять, в качестве знака что ли?
вот эту надо функцию надо копать
004B2ACF call floor_draw_
я не смог в ней нормально разобраться где там обнуляются 4 бита.
пред ее вызовом в eax содержится значение вида 0400TTTT (это после правки art_id_)
что делает функция art_id_ ? — я так понял что она общая для всех да?

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

Движок использует первый бит (e) из оставшихся четырёх для своих нужд (флаг использования???). Ещё в одном месте есть проверка и второго бита (s), но я не вижу где он используется и это меня беспокоит-напрягает. Поэтому сдвигаю эти два бита наверх и верхняя граница индекса (i) таким образом становится равна 0x3FFF вместо 0xFFF.

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

там легко карту для теста подготовить (даже прошки не надо делать), art\tiles.lst надо расширить до 4096+ просто дублируя строчкy с reserved.frm и на каком-нибудь номере например 4100 поставить любой из используемый в игре frm-тайла как контрольный. зайти в маппер димса и понатыкать этот тайл на пустую карту сохранить и уже в игре по контр-R грузить и тестировать.

Ты внес изменения в отладочную версию сфала? -ничего не изменилось, вернее тайлы пола показываться стали(hpr все равно блокирует), но опять таки графика тайла соответствует началу по индексу листа.
мне кажется ты еще забыл правку сделать в art_id_
00419D46 and eax, 0FFFh
но я ее менял по твоему методу и без разницы.
проанализируй лучше floor_draw_ / roof_draw_ я думаю там что-то.

---
я вот тут подумал, а ничего что самих то прото-файлов нет на такое количество тайлов, я вот проверяю 4109 frm-тайл но самой то прохи нет) в коде случаем нигде не проверяется? :)
пойду сделаю прохи... да нет без разницы.

и еще вопрос как вообще движок работает с art tiles.lst может он в памяти тоже ограничен по fff и больше чем 4096 не может содержать элементов аля массив, и если значение больше просто берет значение с начала массива.

Так конечно проще ;) Пересобрал отладочную версию и добавил требование наличия переменной MoreTiles=1 в [Misc] секции. У меня работает, если отключён HRP.

Да работает! спасибо) и я могу эти все правки сделать и для маппера(разумеется по другим адресам) и он тоже будет показывать тайлы?
в tiles.cpp это все правки которые ты сделал или есть еще?
Маппер димса я то поправил что б тоже показывал, но хочется еще и игровой маппер в нем тестить быстрее)

А что насчет HRP есть соображения по этому поводу?
(я так понимаю HRP — работает по такому-же принципу как и библа ddraw?)

и еще меня очень смущает art_id_ и подобные функции в которых участвуют не только фрм-тайлов, как допустим это отразится на работе для фрм-scenary, что по сути для их изменилось?

Попробуй, хотя скорее всего в маппере ещё где-то нужно что-то подправить.

Все, касающиеся этого вопроса.

Пока никаких, да и без HRP пока эта штука из разряда "прикольных".

Да.

art_id_ позже подправлю на проверку тайлов, art_get_name_ только что поправил.
Но тут проблема в другом — на карте тайлы хранятся с установленным первым битом (e) и, возможно, вторым (s) где нужно и потому после загрузки таких карт (а они все такие) будут неприятности. В общем надо копать дальше...

Хранятся? это те карты которые сохраняет игра .sav? — ибо в обычном map формате эти 4 бита всегда равны нулю. каково предназначение этих 2 бит?

Ну тайлы потолка показывает, значит буду перемещать потолки за пределы 4к
надо другие версии попробовать, вдруг это что-то связанное с лишним функционалом HRP — может из-за тумана войны.
жаль что человек не оставил исходники сего творения.

Мне кажется ему так легче работать с кодом.

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

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

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

Еще не понятно почему бы не продолжать использовать github? Или имеет место некое желание быть единоличным владельцем кода? (которое мне, опять же, как фанату open-source, не понять)


PS: кстати а тут есть у кого-нибудь мнение по поводу интеграции LUA в sfall?

А как же движок со сложным названием на букву F, на который ты бросил все свои силы?

А что подразумевается под интерацией луа?

Да я давно им не занимался. Тоже надо бы время найти.

Возможность подключения глобальных и хук скриптов (а в перспективе и полная альтернатива SSL для объектов тоже) на Луа. Для всех высокоуровневых функций ВМ пробросить биндинги и вперед.

Преимуществ перед SSL масса:
- известный любому геймдеву или опытному мододелу язык с кучей готовых библиотек и решений
- не нужно ничего компилировать (соответственно отпадает надобность в поддержке редактора скриптов, компилятора и декомпилятора)
- новые опкоды можно будет прописывать напрямую в sfall без необходимости обновления компиляторов, кроме того отпадет проблема конфликтов (например если 2 человека независимо друг от друга добавляют новый опкод следующий по номеру — получается 2 варианта языка SSL...) — биндинги будут не по порядковому номеру а просто имя функции
- поддержка современных парадигм программирования, таких как ООП

Сложности которые я вижу:
- а будут ли юзать?)
- все-же кто-то будет продолжать юзать SSL скрипты (например для модов к оригинальной игре или старым TC, без создания игры с нуля) и захочет новые опкоды — соответственно проблема поддержки sslc/int2ssl никуда не денется и теперь придется каждую новую функцию в трех местах прописывать (не считая редактор скриптов, документацию и т.п)
- вызов опкодов из луа, понадобится какой-то фейковый scriptProgram (но это не проблема по идее)


Вообще натолкнули меня на это размышления о том как бы сделать в фалауте конфиги такие же удобные как в STALKER. В принципе уже сейчас можно для этого юзать функции для работы с INI (пусть они коряво реализованы, но работают). Вариант использования — расширить прототипы игры, вынести туда например новые параметры оружия, которые будут использоваться в хук-скриптах просчета атаки, урона и т.п. Сейчас чаще всего просто прописывают для каждого мода прямо в скрипты PID оружия через кучу уродливых IF.. В общем ничего хорошего и никакой расширяемости.
Подобные конфиги позволят сделать мод расширенного функционала для оружия, брони и т.п. который потом любой без знания скриптов сможет адаптировать для любого мода.

ну я так посмотрел активности там маловато — в плане написания кода.
сразу вам скажу, что не стоит делать ограничение в 4095 картинок
а то смотрю там код и вижу такую хренатень(
auto baseId = FID & 0x00000FFF;

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

Crafty Еще раз по поводу start_gdialog.

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

не страдай фигней) -не ну и нафига?)
лучше сделайте в sfall аналог HRP :)

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

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

Не понимаю зачем его вообще сделали в HRP — ну не подходит "туман" к этой игре (или он просто криво реализован).

При записи игры сохраняется бит (e), а при загрузке он сбрасывается. Добавлю сбрасывание перед записью чтобы избежать проблем при MoreTiles=0.

HRP своим аналогом подменяет движковую square_render_floor_. Добавил проверку на HRP 4.1.8 и нужные исправления.

This :-p

Так это справедливо и для меня — я не могу нормально поддерживать написанный на C[++] код.

Меня напрягает добавление в ченжлог, потому что нужно коротко и понятно, а гитхаб вообще адок — поменял пару строчек кода и нужно отчитываться почему и для чего. В какой-то момент я понял что трачу больше времени на заливку изменения и выдумывания для него описания. Суета сует... :-p
Исходники всяко есть в архиве.

Согласен.

Угу, такой сюр :(
Отношу это к багам и исправляю — теперь значение параметра mood всегда учитывается, но дополнительно может быть равно -1 — в этом случае mood будет рассчитываться с помощью нулевой локальной переменной этой башки.

О PRINT не знаю (да и что это?), скрытность заблокирована из-за очереди событий — обрабатывается только ГГ и использование скрытности сопартийцами после выхода из боя будет менять состояние у ГГ. Сейчас подумал и да, это в принципе можно обойти. Не шибко много профита (у сопартийцев нет перков/трейтов), и к тому же индикатор скрытности сейчас используется для имени.

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

Тут как раз Крафти накопал ряд полезных функций из движка которых нет в сфалле, например вот.
write_int(ptr_obj+(0x24), flags) / read_int(ptr_obj+(0x24), flags)
позволяет получить и записать флаги объекта(криттера) непосредственно расположенного на карте.
там еще есть пару полезных вещей если полистать тему.
вот можете скомуниздить т.е. добавить себе)

А вот это мне интересно..)

В маппер2.exe так

ничего что в нех отличается код от игрового на 10h, в чем вообще разница? -не пойму. (в игре получается ограничение на 16384, а в мапппере 16400)

и как мне поступить с art_id_ и art_get_name_ ?
может сделать call в неиспользуемую область типа таблицы перков и там код написать? или так нельзя делать)

Описаны в MODREACT.H:

Так я не против.

Не спеши, я уже сделал базовую версию (кодовое название sfallM, keke).

Почему не надо? Ты в маппере играешь?

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

ну раз такое дело то поправь еще процедуры типа tile_place и tile_place_at чтоб "новые" тайлы можно было размещать.
я их правил но чтот не заработало как всегда)

эта всегда сбрасывается в -3 когда криттер походил(поучаствовал) в бою. и вроде как даже если нпц из другой криттерской команды (не из стой с которой гг в бою).

О том и разговор — изменений из F2-версии недостаточно.
Ссылка в первом посте, а здесь патчик для простенькой проверки. BIS'овский маппер по-другому обрабатывает список доступных тайлов — использует proto\tiles\tiles.lst и в отличии от маппера димса фокус с art\tiles\tiles.lst не прокатывает. Поэтому я взял из чистого F2 содержимое art\tiles и proto\tiles, добавил в art\tiles новые файлы из RP, потом из Невады и добил Олимпом. С добавлением в art\tiles\tiles.lst новых файлов. Создал в proto\tiles недостающие *.pro и добавил их в proto\tiles\tiles.lst.
Патчик распаковать в master_patches или скопировать его в каталог F2/маппера (в ddraw.ini проверить отсутствие PatchFile, отсутствие master_patches\art\tiles\tiles.lst и master_patches\proto\tiles\tiles.lst), в ddraw.ini добавить MoreTiles=1 (нужно бы какое-то описание придумать). Загружать artemple.map (в F2 Ctrl-R или новая игра, а в маппере Alt-O).

Движково ГГ должен обижать криттера, каждая любая обида устанавливает в -3 (на мой взгляд должно быть "накопление").

Круто DebugMode прямо в маппере.
Надо было еще и ProsessorIdle перенести а то маппер проц грузит как современная игра)

Ну ради 3 режима оставил, так-то он в маппере есть, и, возможно не все знают, для переменной mode из mapper2.cfg кроме значения environment (настройка режима вывода через DEBUGACTIVE) можно использовать gnw (окошко Debug), log (создание debug.log), screen и mono. Последние два не шибко юзабельны в современных реалиях.

У меня 50%, но добавил.

Все-же это окошко очень мешает, оставил на 2 варианте.
Я как то пытался его включить в маппере но что-то не так делал, и подумал что тоже патчик нужен чтоб оно появилось.

Phobos
У дверей есть для этого специальный флаг walk...что-то там.

Трупы уже подсвечиваются. Надо еще что бы трупак можно было подхватить если он валяется за каким либо объектом.

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

Я тут думал над твоим луа, мне кажется что он сложнее в освоении чем ssl
Все равно чел. придется читать мануал по функциям движка, остальное основа програмирования if then else / while do / переменные и работа сними вычитание/сложение/присвоение, этих без базовых знаний в программировании чел не сможет написать скрипт как в луа, так и в ссл.
Поповоду не нужно будет компилировать — ну не знаю не испытываю проблем с компиляцией нажал кнопочку скрипт ушел на компиляцию и в папочку скрипт.
Не нужено будет делать декомпиляцию — ну тут да плюс, но тогда придется хранить и всякие свои левые include файлы.
А как же всякие препроцессорные фигни с указанием ключей аля release/debug — тоже классная штука.

Просто на дворе 2016 год и сейчас никто не компилирует скрипты руками))) Кроме нас, олдфагов. Как минимум есть JIT-компиляция, которую я кстати подумывал тоже реализовать. Достаточно слинковать compile.dll с sfall также как это сделано в редакторе скриптов и вызывать в нужные моменты компиляцию.. Но тут появляется большая проблема работы с файлами.. В игре используется плоская структура — все скрипты в одной папке-помойке. А в исходниках по другому, т.е. игра должна знать в какой папке искать исходники... В общем дофига гемора.

А насчет того что сложнее в освоении — хз. Для не-программиста может SSL покажется в чем-то проще (потому-что он нихрена не может и сложного кода на нем нет), а вот для программеров однозначно лучше Lua.

В общем идею не поддержали, добавлю пару новых опкодов в SSL и возможно в будущем подумаю еще насчет ООП... На самом деле некое подобие классов можно реализовать процедурно... А также нужно активно юзать экспорт процедур. Это позволит сделать глобальный скрипт-библиотеку со всеми функциями мода, которую ты просто используешь везде. Понадобилось поменять какой-то общий код, и достаточно перекомпилить один скрипт...

Это в каком контексте сообщение? Если речь про мою базу, то там мало что интересного. Она в подметки не годится той что я когда-то давно скачал от Crafty — там размечены реальные названия ВСЕХ функций. Я до сих пор не понимаю как ему это удалось :)

Сделал скриптовую функцию аналог critter_inven_obj но без проблемы с неактивным слотом. По новой технологии, вот как раз пример добавления новый скриптовых функций.

Проще некуда :)

Разглядывал, пока ничего не сделал.

Нет, и это, кстати, можно будет отнести к зашитому сложному моду, меняющему интерфейс игры :-p

Комбат, не.

Не вижу смысла, а то так дойдёт и до автоматических диалогов и боёв.

Ни для чего не работала (наследие оригинала). Исправил.

Пока только та, что в начале темы.