Malandrinus

sapsan, косяков может быть два: исправимый и неисправимый =) Исправимый. Если в цитате показано всё, что есть в биндере, то там не хватает ещё прописывания колбека (скорее всего должно быть в __init). Типа такого: self.object:set_callback(callback.hit, self.hit_callback, self) и потом ещё не забыть его отписать. Без этого метод inventory_box_binder:hit_callback останется просто методом. Неисправимый. Однако, если ящик не генерирует колбек на хит, то это не поможет (и скриптами никак это не решить). Как например для актора. Всем бы хотелось, чтобы для актора ловился хит, но вот нету.

Rolan, Кстати, а где? Сколько можно по ушам то ездить? =) Rolan, Ага =) Как там в одной книжке... Насовал нам фиалок за уши, а теперь отмазки лепит, админов понимаешь ли боится.

SkyLoader, переходи на движок ЗП. Там визуал можно в любой момент менять простой функцией. А с этой методой у тебя всегда будут проблемы с переводом в оффлайн, затем в онлайн. Кроме того, что это для разных сталкеров по разному работает, так тебе ещё придётся ловить момент ухода в оффлайн (и только после этого менять), что неудобно и как правило тормозит игру.

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

Stalk15, Kolmogor, с изменением story id через нетпакеты есть ещё одна неприятность. Для объекта то он меняется, а вот в разных внутренних структурах не прописывается. Т.е. скажем искать по свежеизменённому story id получится не раньше, чем после перезагрузки.

_Призрак_, в hex виде из контекстного меню выбери "Data format" -> "Single Float (32 bit)". Затем можешь редактировать прямо число с плавающей запятой. Но только учти, что IDA никогда не меняет файл. То, что ты таким образом "изменил", можно сохранить в виде файла отличий "*.dif" через "File" -> "Produce File". Затем уже нужно применять этот файл к исходной dll с помощью утилиты "bpatch", которая понимает эти файлы и которую можно найти в сети.

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

sabir, Не надоело еще? У меня все три игры установлены. Ни в одной из них библиотеки движка не защищены никакими защитами и никак не зашифрованы. Основной загрузчик может и (был) защищен, но он никому и не интересен.

Министр, Так transfer_item и меняет. Но только он его меняет каким-то извращенным способом через посылку сообщения серверу. И работает это только в онлайне и для инвентарных объектов. Что только для инвентарных объектов - это правильно, а вот что только в онлайне - по всей видимости тяжелое наследие сетевого движка. Ну а в оффлайне - либо нетпакетами, либо ковырять движок.

vodkin6804, это расстояние - ровно три игровых метра и прописано прямо в коде. Изменить можно, но придётся править исполняемые файлы.

GEDRO, назначать детекторам худ можно только в ЧН и ЗП. В ТЧ такой возможности нет в принципе.

Обсуждения такого рода вполне уместны в ковырялке для соответствующей версии. История повторяется. Создана тема с узкоспециальным назначением, причём по этому самому назначению её никто не использует (и не будет использовать). В лучшем случае тема уйдёт по списку вниз, и о ней благополучно забудут. В худшем - получится ещё одна микроковырялка. И зачем! У форума, к примеру, есть неприятная особенность "отписывать" рассылки от тем, где долго никто не пишет. Да и следить гораздо лучше за тремя темами, а не за десятком.

Shadows, это если и ускорит, то не загрузку игры, а запуск программы, поскольку system.ltx читается и парсится только один раз в самом начале. Да и ускорение будет копеечное. Собственно, и не будет его совсем, поскольку парсить надо будет практически столько же.

Ярослав, Ну допустим переделаешь ты гильзы. Но затвор ведь останется слева. А это только модель менять.

ALEX BOY, Смотри тему "справочник". Там смотри про диалоги - вроде как все ответы должны быть. По п.1 ответ должен быть в части 3 "диалогов". таймеры АМК IQDDD, Сохрани значение в pstor актора. При загрузке прочитай его обратно и поменяй тайм-фактор.

Garry_Galler, Всё же самое главное использование идентификаторов для модостроителя - это указание с их помощью диалогов в профилях персонажей. В указанных функциях их можно использовать тогда, когда одна функция используется для нескольких диалогов. Типа оптимизация. Есть некая функция в одном диалоге и в другом. Очень похожи, но отличаются на пару строк. Объединяем в одну, а разницу реализуем в зависимости от имени диалога. Как-то так. Вообще, чтобы понять задумку разрабов в полной мере надо смотреть их примеры. Обычно сразу становится ясно, за каким им потребовалась та или иная странная фишка. Вот к пример скриптовые диалоги они сами использовали для того, чтобы создавать диалог на базе информации из файла ltx. Но проблема бывает в том, что фишка могла быть сделана для какого-то билда, который давно ушёл в историю, и примеров использования не сыскать, и не актуально это давным-давно. А мы тут сидим, умные разговоры ведём =)

Gonarh, Все события попадания неписей в рестрикторы завязаны на периодическую проверку либо в апдейте непися (если логика у непися) либо в апдейте актора (если логика у рестриктора). Так что и для болта не видно другой альтернативы. Делаем ему биндер и проверяем в нём попадание. В общем-то можно даже попробовать применить к нему стандартную логику попадания в рестриктор. Не помню там ничего специфического именно для неписей. Правда story_id к болту не прикрутить (или можно? не знаю точно), но простая правка позволяет сделать проверку не по story_id, а скажем по имени.

Rolan, у меня нет ссылки. Помню только, что я принимал участие в этом обсуждении. Попробуй по моим постам пошарить в ковырялках за последние 5-6 месяцев.

Garry_Galler, Нельзя. Принцип работы системы такой. Там внутри есть нечто вроде хранилища - массив инициализированных диалогов. Все диалоги при старте игры не грузятся, грузятся они по первому запросу, при этом инициализируются и помещаются в это хранилище, откуда при дальнейших запросах выбираются по ключу (идентификатору диалога). При этом способ инициализации (через XML или скриптом) принципиально не важен. Диалог (или точнее граф диалога) по-любому создаётся один раз. Это хранилище инициализированных диалогов не принадлежит какой-либо конкретной сохранённой игре. Время его жизни - сеанс работы программы. Относительно графа диалога. Я разумею под ним полный граф, включающий все возможные фразы (игнорируя предусловия). Представьте себе лабиринт с дверями. В какие-то двери войти можно, в какие-то нельзя. Это предусловия. А сам лабиринт - это граф. Граф менять нельзя, а предусловия можно. Мы же его указываем в профиле персонажа. Для этого и нужен, чтобы ссылаться на диалог. Или я не понял вопроса?

Rolan,Серый Волк, насчёт навешивания кнопок на движковые окна. Можете поискать на форуме. Здесь (или в одной из соседних тем) было обсуждение на эту тему и приводился код, как это сделать устойчиво без вылетов после перезагрузки.

Garry_Galler, ок, надеюсь, ты внимательно прочитал вот этот комментарий из первой части

Добавлено через 77 мин.: Garry_Galler Там это всё есть в первой части. В части про скриптовые диалоги я просто ссылаюсь на ранее описанные теги. А зачем тебе потребовались скриптовые диалоги? Они же не дают практически никаких преимуществ по сравнению с XML. Я об этом писал. Они скриптовые, но ни разу не динамические. А вся динамичность в равной степени доступна как при скриптовом создании, так и при использовании XML. Кстати, в описании тега action у меня была ошибка. Заметил и исправил благодаря твоему посту. Спасибо!

Nevada47, одного NPC другому - это как? Неписи друг с другом не общаются. // Он имел в виду дублирование диалогов одного НПСа другому, т.е. что бы у них они были одинаковы. Министр.

Arhara, вот здесь есть разъяснение про разницу между DXT1,3,5. Если кратко: - текстуры рисуются прямо из упакованного состояния, поэтому их размер на диске - это то место, которое они займут в видеопамяти. - Цвет во всех трёх форматах хранится одинаково и разницы в качестве нет. Разница есть только в хранении канала прозрачности. - Между DXT3 и DXT5 разница весьма незначительна, а размер одинаков. Вроде как DXT5 чуть-чуть лучше (для канала прозрачности только, помните?). - в DXT1 канал прозрачности однобитный, т.е. просто маска. При этом размер этих текстур в два раза меньше. Выводы. Для самого общего случая предпочтительный формат - DXT5, как все и рекомендуют. По поводу DXT1. Я специально изучал слои прозрачности иконочных текстур. Очень-очень редко когда видел, чтобы в канале прозрачности были полутона. Чаще всего принцип примитивный: есть цвет - непрозрачная, нет цвета (чёрный фон) - прозрачная. И в оригинале чаще всего так. Так что в целом можно использовать DXT1 для текстур худа (плоского) и всяких иконок. Их ведь не так уж и мало. Можно сэкономить некое количество памяти. Ничто не мешает посмотреть сперва на слой прозрачности. Если он выглядит "чёрно-белым" без всяких полутонов, то можно смело сохранить как DXT1. Если вдруг там есть "серые" пятна, то нужно думать. Канал прозрачности часто генерируют на основе канала RGB и серые участки получаются просто автоматически. При этом ничуть не хуже было-бы, если бы там просто была однобитная маска. По поводу mipmap слоёв. Они всё-таки совершенно лишние для иконок, окошек и текстур плоского худа. Хуже с ними не отрисовывается, но они просто занимают память и при этом никак не используются.

Насчёт порчи текстур при пережатии. На мой взгляд, есть только одна-единственная текстура, для которой это актуально - файл инвентарных иконок ui_icon_equipment.dds. Его-то уж до дыр затёрли. А все остальные... Ну не знаю. Пробовал я раз пять перепаковать текстуру - никакой визуальной разницы не заметил. Тоже самое, когда несколько раз перегнал из DXT5 в DTX3 и обратно. Может быть, народ просто не обращает внимание на настройки качества при сохранении.