RayTwitty

В 2011 году тоже собирал: http://rghost.ru/private/7n9M2Mvll/004e266ebaecce66608b5ef30bc1bd05

Включи игру, загрузи сейв, например с утренней погодой. Потом загрузи ночной сейв (сама секция погоды должна быть той же) и посмотри, что получится. В некоторых случаях она либо не обновится, либо обновится частями. После повторной загрузки сейва ночи, погода нормально обновится. З.Ы. если продолжить играть с криво-загруженной погодой, то можно наблюдать довольно интересные сочетания, самое смешное, иногда эти сочетания получаются довольно удачными: http://www.gameru.net/forum/index.php?autocom=gallery&req=si&img=44233 Скрин сделан именно в такой момент. При нормальной работе погоды, такого часа просто бы не существовало.

У меня нет установленного ЧН, так что проверять только вам

Дело в том, что измениться оно может только в очень специфичных случаях (например какой-то дебаговый спавн, в штатном режиме как я пониманию, ничего просто так не появляется), но самое главное - лист не перезагружается после перемещений между поясом\слотами и рюкзаком Если вы конечно не сделали это принудительно. Впрочем, наверно это зависит от мода - где-то требуется, где-то нет. В самом деле, там только флажки ставим, плюс-минус вызов не напрягает. На счет правки солнца - понятно. Значит придумать, как исправить баг, а эту правку в топку. З.Ы. посмотрел в исходниках репозитория xp-dev и что-то не нашел упоминания о правке. Получается её до сих пор не сделали? Всегда думал, что солнце уже исправлено и даже не обращал внимание на его отсутствие. Провел анализ кода - в этой правке (не считая проверки флага g_ignore_game_state_update, который в оригинале не влияет) ты просто убрал вызов GamePersistent().Environment().Invalidate() (call ds:CEnvironment__Invalidate). Собственно, солнце у меня восстановилось и в исходниках, после того как я закомментировал вызов. Но вместе с солнцем "восстановились" и баги)) Будем думать дальше.

На счет косяков не знаю, я скорее про структуру и количество вызовов говорил. В частности, обновление флагов для предметов достаточно делать в трех случаях - на событиях take\drop (при открытом окне обыска\торговли) и при открытии окна инвентаря\обыска\торговли для всех предметов сразу. Да, проверил - теперь всё нормально работает. Кстати, остался нерешенным вопрос с правкой 0x102AC460 5 ; jmp game_cl_GameState__net_import_GameTime_dbg_fix она как я понял, восстанавливает солнце, но вместе с этим, наблюдаются и баги (совершенно точно они происходят из-за этой правки): 1) зависание обновления погоды; 2) необновление каких-то элементов погоды (например свет и флары меняются, а скайбокс нет и наоборот); 3) странное поведение погоды между перезагрузками сейвов (загрузили другой сейв, а погода и час остались теми же). В общем, что-то с апдейтом там. Возможно, как-то связано с функцией set_ignore_game_state_update() которая вызывается в OGSE, но непонятно для чего.

Кто-нибудь может поделиться папкой textures\intro из последнего DMX MODa (1.3.5)? Сейчас под рукой просто нет его.

Перепроверил. Последняя ревизия, правки включены в движке. В скриптах убрал включение глобальных флагов (т.е. дб по нулям), убрал вызовы относящиеся к фиче, результат: http://rghost.ru/private/7H827RrkP/bfe541d734f5a2b1855c5cebed4d10a4 А как бы сделал ты? Я про скрипт говорил. А в движке без исходников не сильно чего придумаешь.

@dsh, А я ведь я писал об этом, чем вы читаете - неизвестно. Не правда, конкретно эта правка без скриптовой обвязки ведет к неправильному отображению списка в окне торговли\обыска. Если правка отключена - она либо недоработана, либо требует вмешательства в геймдату, либо слишком специфична (например "смерть от первого лица"). Если я правильно понял идею проекта, то его главная особенность именно в скриптовых расширениях, а уже потом в каких-то точечных геймплейных правках, которые зачастую, нужны только определенному моду. Скриптовые правки, как правильно было замечено, не требуют каких-то лишних телодвижений - они есть и всё, каждый использует то, что ему нужно. Их никто не трогал.

Это было бы неплохо, как собственно и создать нормальные общие батники, которыми могли бы пользоваться простые смертные. Кстати, ничего там не изменилось с правовым статусом link.exe и ml.exe? Может всё-таки стоит добавить их в репозиторий? У людей постоянно возникают проблемы, они не могут ничего скомпилить, ибо далеко не у всех есть VS и masm. Ситуация осложняется ещё и тем, что не все версии этих исполняемых файлов (по твоим же словам) подходят для линковки кода. Также, для работы всего этого требуется наличие установленных рантаймов, о чём тоже неплохо бы где-то упомянуть.

Посмотри ogse_trade_precondition.script. Не самая идеальная реализация, тем не менее суть понять можно: 1) Для каждого инвентарного предмета добавили параметры закраски, группировки и торгуемости. 2) Создается таблица (для закраски): индекс цвета = код цвета. 3) При открытии инвентаря, изменяем новые параметры так, как нам надо и получаем результат. Например, задаем закраску тех предметов, которые в слотах.

@Malandrinus, 1. Можно ли использовать уже существующие дефайны, которые лежат в defines.asm (например OGSE_BUILD), для corrections_list? 2. Я думаю, имена дефайнов должны быть написаны, хотя бы с разделением на слова: DLGDISTFIX -> DLG_DIST_FIX. Первый вариант совершенно не воспринимается. 3. Наверно, стоит убрать файлы конфигов в подпапку configs (3312_shoc_10006\configs\), дабы не искать постоянно их в списке всех файлов. Такого метода в проекте нет. Для окна торговли и обыска есть правка, которая управляет заливкой (можно например сделать, чтобы предметы в слотах подсвечивались зеленым). Для этого, правку нужно активировать и написать скриптовую обработку закраски. А что касается окна инвентаря - в моде LWO (который использует тоже ХЕ) есть закраска патронов для выбранного оружия (как в ЗП) - сделано достаточно заморочено, но разобраться можно. Насколько я помню, там во время заполнения инвентаря вызывается колбек, в который передается указатель на объект иконки (окна) и самого объекта, после чего с ними можно нормально работать (перекрасить, приаттачить что-нибудь или даже заменить текстуру). Полный хак кароче.

Там есть. Можешь спокойно использовать.

Если стоит xray-extensions, можно попробовать получить текущий стейт аномалии, он хранится в m_eZoneState класса CCustomZone. Если аномалия выключена, стейт будет равен eZoneStateDisabled. Не сделает, объект партикла не получить таким образом. Тут либо получать из движка (как написал я), либо эмуляция (по сути дублирование стейт-системы движка) через скриптовый биндер.

Лучше ничего не трогать и использовать дефолтную конфигурацию из официального репозитория. В твоем что-то опять понахреначили, поди разбери. https://github.com/KD87/xray-extensions/archive/master.zip

Нашел тут у себя архив sky4ce_r3_fixes.rar, в котором лежат шейдеры r3\lmodel.h и r3\rain_patch_normal.ps. Очевидно, они фиксят кривое намокание вертикальных поверхностей на DX10. В OGSM это включено (лень читать всё ридми)? З.Ы. если что, архив могу залить. Ссыль: http://rghost.ru/private/7LCHPGbb9/53077058bbd415d0591d579b662f2f50

Разбиндить кнопки передвижения?..

Требуется небольшая помощь Существует условие: if (!a || (a && (!b || (b && c))))a,b,c - булевые переменные. Необходимо это условие максимально упростить. У меня пока получилось это: if (a && (b && c || ! || !a)больше пока идей нет. Мб кто подкинет?)

Мерцание травы (исчезание-появление) и кривые подергивания травы от "ветра аномалий" - два разных бага. Собственно, для первого есть фикс в ХЕ, а второй лечится, очевидно, выключением ветра в конфигах.

Пару мыслей о параметре direction в спавне. Как оказалось, это совсем не тот direction, который обычно возвращает скриптовая функция (одна из строк матрицы XFORM), а полноценный вектор с направлениями в радианах. Намного правильнее было бы назвать этот параметр angle (как собственно он назван в движке), во избежание диссонанса с direction. З.Ы. или по аналогии с СДК - "rotate" в градусах.

Залью как будет время.

@Ghost-2142, перед вызовом script_death_callback идут два пуша с ecx-регистром. Замени их на esi.

Посмотрел - там в обоих аргументах будет nil всегда. По идее, если добавить в car_fix.asm в 15 строку вот это: call CGameObject__lua_game_object mov esi, eaxа два пуша заменить на: push esi push esiто в обоих аргументах будет объект машинки (тот же самый self.object, только костыль в скрипте не понадобится).

А разве нельзя сделать в более привычном виде - SetColor(GetARGB(a,r,g, )? Для совместимости кода, в первую очередь... @Ghost-2142, тогда принудительно задай victim в начале функции - victim = self.object З.Ы. никогда не понимал, зачем этот аргумент вообще нужен, ибо клиентский объект в биндере всегда определен.

@Ghost-2142, а лог-то какой?

Это не косяк ХЕ - просто для машин добавили колбек на смерть, из-за чего, при самоподрыве вместо victim передается пустота. Вангую, что если написать: printf("_bp: generic_physics_binder:death_callback: obj='%s'", victim and victim:name() or self.object:name())то будет все ок.