RayTwitty

К чему\кому такие вопросы? 1) гуглокод был закрыт; 2) перенос на гит осуществлял не я; 3) переносить проект svn->svn только потому, что там "трафик хорошо экономит" очень сомнительно; 4) какой трафик? Проект в zip весит 500кб. 500кб, Карл!

А что их выкладывать? С гитхаба скачать намного проще чем с гуглокода - вон кнопочка "Download ZIP". https://github.com/KD87/xray-extensions На гуглокод можете забить уже сейчас, его окончательно дропнут после НГ. Да.

В официальном репозитории ревизии уже за 240-ую перевалили, почему-то бы не зарегаться там и не коммитить нормально? Вроде бы можно, но как - не могу сказать. Следует подождать авторов, они точнее ответят.

Да, только там не во всех местах перед дефайнами написано "detector". Надо смотреть куда ведут метки. В 269 строке надо тоже дефайн поправить. Поставить ifndef OGSE_BUILD например.

Мое имхо по поводу открытых прицелов - либо их делать как в GUNSLINGER mod, но для этого понадобятся хорошие, многополигональные модели, либо не делать вообще. Но, открытым прицелам есть неплохая альтернатива - закрытые. Могу отметить работы @GeeP_85 в этом направлении, лучше я пока ничего не видел.

@phorumer, по дефолту никак не называется, просто пиши 138.

@phorumer, да, 138 колбек ставится актору - http://code.google.com/p/xray-extensions/wiki/new_collbacks аргумент - машина которую юзаем.

Ну, судя по описанию правки, колбек должен вызываться только при юзе без посадки. Либо правка некорректна, либо неправильно применяете. Т.е. тут надо не запутаться - в оригинале есть колбек на юз для машины, а в ХЕ добавился колбек на юз машины для актора. Расстояние до дверей + замороченный алгоритм определения, что смотрим именно в зону нахождения двери. А проверять, то что актор не сел, у меня получалось путем вызова not db.actor:get_current_holder() после отработки стандартного колбека на юз для машины.

Так как непонятно, к кому обращается @Dennis_Chikin (неплохо было бы использовать цитирование), но вроде как ко мне, отвечу: info_id ~= "" and alife():has_info(0, info_id)по твоему это не булевое?)) Если как ты говоришь, актор почти всегда есть и ты его не проверяешь, то зачем нужна проверка алайфа? В каких случаях есть алайф, но нет актора?)) Почему ты так уверен? А если строка генерируется не вручную, а каким-нибудь генератором? Мало ли какие сбои. Если в lua правильно сделано сравнение строк, то никаких внутренних затрат на сравнения не потребуется, функция почти сразу выйдет с результатом.

Это когда такие случаи были? До загрузки игры? Не имею возможности сейчас посмотреть места вызовов конктруктора и деструктора симулятора, но скорее всего, он доступен даже когда актор в оффлайне. function has_alife_info(info_id) return info_id ~= "" and alife():has_info(0, info_id) end Неявно может быть и пустая строка. Такое вполне вероятно, по крайней мере намного вероятнее, чем вызов из главного меню до загрузки игры

@Dennis_Chikin, function has_alife_info(info_id) local sim = alife() return info_id ~= "" and sim and sim:has_info(0, info_id) endХотя смысла лишний раз проверять наличие симулятора по большому счету и нет.

Обнаружил два колбека с одинаковыми номерами: debug_fixes.asm 185 строка - CALL_ACTOR_CALLBACK_INT_INT 153, edx, eax по умолчанию не вызывается, используется в OGSE. stalker_fix.asm https://code.google.com/p/xray-extensions/source/diff?spec=svn152&r=152&format=side&path=/trunk/3312_shoc_10006/stalker_fix.asm вызывается, используется вроде бы в модификации Lost World. Не критично, так как первый закомментирован, но все-таки не мешало бы поменять номер у дебагового, мало ли что. З.Ы. вообще, надо было наверно с самого начала проекта в отдельный файл выписывать дефайны с номерами используемых колбеков, чтобы каждый раз не гадать, какой номер свободен.

Итого, примерно двое суток потребовалось для выяснения причины отсутствия солнца в ТЧ. Как выяснилось, в ЗП game_cl_GameState::net_import_GameTime вообще не вызывается, следовательно -> нет вызова GamePersistent().Environment().Invalidate() -> нет сброса текущего стейта флара. Путем отладки было также выяснено, что Invalidate() в ЗП отрабатывает ТОЛЬКО при вызове CEnvironment::SetWeather (а это именно та функция, которая экспортирована в level.set_weather), следовательно Invalidate() в ЗП вызывается только из скриптов и только вполне определенное количество раз (а не на апдейте, как в ТЧ). Таким образом, выпиливание вызова из net_import_GameTime - это правильный шаг, правка абсолютно корректна. Но для этой правки требуется скриптовая доделка, в виде установки погоды из скрипта после загрузки сейва (очевидно, в ЗП эту функцию выполняет система динамической погоды), однако у меня нормально погода устанавливается только на первом апдейте актора, на спавне почему-то не хочет. Собственно, в OGSE и не было проблем потому, что там идет полное управление погодой из скрипта. З.Ы. на счет net_import_GameTime - можно было конечно поступить как в ЗП, убрать вообще вызов этой функции (а точнее убрать экспорт), но это уже серьезные вмешательства в работу системы клиент-сервера, неизвестно к чему это приведет - в ЗП все-таки там основательно все переделали...

Пока и в исходниках не получается)) Убил вчера весь день, но так и не понял как исправить. Причина не появления флара ясна - при вызове GamePersistent().Environment().Invalidate() сбрасывается стейт флара в none, процесс начинается сначала и так на постоянном обновлении. В то же время, в ЧН\ЗП код такой же, однако всё работает. Так же, как колбек на юз.

В 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 (который использует тоже ХЕ) есть закраска патронов для выбранного оружия (как в ЗП) - сделано достаточно заморочено, но разобраться можно. Насколько я помню, там во время заполнения инвентаря вызывается колбек, в который передается указатель на объект иконки (окна) и самого объекта, после чего с ними можно нормально работать (перекрасить, приаттачить что-нибудь или даже заменить текстуру). Полный хак кароче.