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

[Crafty]

QUOTE (Fakeman)

С чем связанно именно 16348 а не 65535? для чего 1 бит оставлять, в качестве знака что ли?

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

CODE

00se iiii iiii iiii seii iiii iiii iiii

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

[Fakeman]

QUOTE

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

там легко карту для теста подготовить (даже прошки не надо делать), 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 не может содержать элементов аля массив, и если значение больше просто берет значение с начала массива.

Это сообщение отредактировано Fakeman - 24 октября 2016 | 00:13

[Crafty]

QUOTE (Fakeman)

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

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

[Fakeman]

QUOTE

Пересобрал отладочную версию

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

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

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

Это сообщение отредактировано Fakeman - 24 октября 2016 | 01:29

[Crafty]

QUOTE (Fakeman)

Да работает! спасибо) и я могу эти все правки сделать и для маппера(разумеется по другим адресам) и он тоже будет показывать тайлы?

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

QUOTE (Fakeman)

в tiles.cpp это все правки которые ты сделал или есть еще?

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

QUOTE (Fakeman)

А что насчет HRP есть соображения по этому поводу?

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

QUOTE (Fakeman)

(я так понимаю HRP — работает по такому-же принципу как и библа ddraw?)

Да.

QUOTE (Fakeman)

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

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

[Fakeman]

QUOTE

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

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

QUOTE

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

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

Это сообщение отредактировано Fakeman - 24 октября 2016 | 02:19

[Phobos]

@Crafty:

Давно мучает вопрос. Зачем переписывать код sfall-а весь на ASM? Мне правда любопытно, какая причина может сподвигнуть на такое решение

[Foxx]

QUOTE (Phobos)

Зачем переписывать код sfall-а весь на ASM?

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

QUOTE (Crafty)

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

[Phobos]

QUOTE

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

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

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

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

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


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

Это сообщение отредактировано Phobos - 24 октября 2016 | 13:20

[Fakeman]

QUOTE

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

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

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

[Phobos]

QUOTE

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

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

QUOTE

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

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

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

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


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

Это сообщение отредактировано Phobos - 24 октября 2016 | 14:56

[Fakeman]

QUOTE

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

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

QUOTE

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

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

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

CODE

mood учитывается только если не используется говорящая башка (head = -1).

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

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

[Phobos]

А почему в Party control заблокировали кнопку PRINT и возможность красться во время контроля NPC?

А как вам такая идея, коллеги. Что если добавить новый опкод такой который позволит добавлять новые скриптовые функции в sfall без необходимости менять компилятор/декомпилятор?
В частности это позволит вам добавлять новые команды в свой форк так что мы сможем их у вас потом выборочно скомуниздить При этом конфликты маловероятны, т.к. вместо порядкового номера опкода в памяти будет использовать строковое имя.

Это сообщение отредактировано Phobos - 24 октября 2016 | 18:56

[Fakeman]

QUOTE

А как вам такая идея, коллеги. Что если добавить новый опкод такой который позволит добавлять новые скриптовые функции в sfall без необходимости менять компилятор/декомпилятор?

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

[Phobos]

QUOTE

не страдай фигней) -не ну и нафига?)

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

QUOTE

лучше сделайте в sfall аналог HRP

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

[Foxx]

QUOTE (Phobos)

Если еще копировать функционал с туманом войны

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

[Crafty]

QUOTE (Fakeman)

Хранятся? это те карты которые сохраняет игра .sav?

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

QUOTE (Fakeman)

жаль что человек не оставил исходники сего творения.

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

QUOTE (Phobos)

Давно мучает вопрос. Зачем переписывать код sfall-а весь на ASM?

QUOTE (Foxx)

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

This :-p

QUOTE (Phobos)

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

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

QUOTE (Phobos)

Еще не понятно почему бы не продолжать использовать github?

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

QUOTE (Phobos)

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

QUOTE (Fakeman)

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

Согласен.

QUOTE (Fakeman)

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

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

QUOTE (Phobos)

А почему в Party control заблокировали кнопку PRINT и возможность красться во время контроля NPC?

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

[Phobos]

Crafty, почему бы тебе не освоить C/C++? Всяко по жизни пригодится А коллегам по цеху будет большой профит.

А насчет Github ты зря. Никто же не заставляет каждые пару строк комитить. Ты можешь делать коммиты с такой же частотой как заливаешь в дропбокс.

А что ты думаешь по поводу универсального опкода?

Это сообщение отредактировано Phobos - 24 октября 2016 | 19:53

[Fakeman]

QUOTE

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

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

QUOTE (Phobos)

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

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

Это сообщение отредактировано Fakeman - 25 октября 2016 | 12:49

[Drobovik]

QUOTE

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

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