abramcumner

Судя по переписке нет Для конвертации лок ЧН нужен префикс "cs:" Там тебе приводили настройки. Вот в них: И отвечают за те самые кусты и фейки.

krovosnork и не только, последние конвертеры должны без ошибок конвертировать локи финалок и большинства билдов. Если нашли ошибку пишите сюда, например: что за лока, как вызывали конвертер и что не нравится в результатах. Разбор фейков вообще настраивается через конфиги конвертера.

Не совсем. Минимум нужно 2 ХОМа. Если ты стоишь перед ХОМ1, и ХОМ1 полностью загораживает ХОМ2, то содержимое ХОМ2 не рисуется. ХОМы идеально работают для целых параллепипедов. А если в нем есть внутренние помещения и окна, то ХОМом закрывать нельзя же, иначе в окна ничего видеть не будешь. Так что порталы и ХОМы прекрасно дополняют друг друга. Когда-то собирался сделать такую фишку в исходниках: в игре жмешь на спец. кнопку и фиксируется камера для всяческих окклюдингов, потом можно было бы полетать деморекордом и посмотреть, что рисуется, а что нет. Может когда-нибудь и соберусь... А может кто и раньше сделает.

Не так. Не прорисовывается содержимое ХОМов, которые закрыты другими ХОМами.

Это извращение, а не нормальный декомпил. При декомпиле с соотвествующим профилем кривых фейков быть не должно.

Там же есть кнопка "Export to Github". Уже нажимали на нее?

Да, данные биндера не сохраняются при уходе в оффлайн. точнее они очищаются при выходе в онлайн. Тут только движок править. Сохранять признак заюзанности и прочие данные в нет-пакете НПЦ, например.

@Malandrinus, необязательно куча анимаций нужна. Можно обойтись 3 костями, добавленными в существующие анимации по аналогии с прицелами, и только новыми анимациями переключения. Пусть П1, П2, П3 - кости для каждого положения переключателя, они зафиксированы и просто добавлены в существующие анимации. И ПА - кость собственно для анимаций переключения. Предположим сейчас переключатель в положении П1, тогда кости П2, П3 и ПА скрыты. Хотим переключить в положение П3: кость П1 скрывается, ПА показывается, запускается анимация 1-3. Как анимация отыграет, кость ПА скрывается и показывается кость П3. Теперь мы будем бегать с переключателм в положении П3.

По-хорошему да. Возможно можно обойтись 1-2,2-3 и 3-2,2-1. И запускать по очереди в случае, если надо. Это надо по анимациям смотреть. Нету никакого положения костей, точнее оно есть, но это свовершенно не важно. Потому что все время играется какая-либо анимация. Закончится анимация с рычажком, будет играться идловая анимация. Конкретно с рычажками, нужно будет добавлять ко всем анимациям еще версии с различным положением этого самого рычажка. Ну или добавить 3 кости под каждое положение рычажка и скрывать/показывать нужные.

Не ограничены и не уберут. Можно смело катать или не катать

@V92, запаковка в архивы поможет. Там нормально перечисление файлов сделано.

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

@BFG, это гейм-вертексы, а нужны левел-вертексы. Wlad777, попробуй эту программку: https://yadi.sk/d/eu8KahnrejCTB Перетаскиваешь на окошко level.ai, выводится диапазон левел-вертексов. Нужен .net framework

Конечно записывают. Malandrinus и предлагал почитать описания ревизий: А зачем верить, надо брать и делать самому. Как делали xray-tools, xray-extensions, да и просто моды. А народ подтянется. Конечно, проект первичен. От него и надо плясать - нужны ли правки движка, какие если нужны. Единственное, что вся разработка должны быть открыта - так и прогресс виден и люди всякого не навыдумывают. Такое у меня сейчас ощущение

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

@V92, dotPeek + Visual Studio. Можно еще попробовать сделать actor.ltx "только для чтения". Может конфигуратор и не вылетит.

Это у map - бинарный поиск. У хешмепов время поиска ключу - константа.

Хмм... Не хилое такое заявление про хешмап и перебор.

Вся эта функция целиком должна быть в share.h template<typename... Args> void test(string name, Args... args) { printf(name.c_str(), args...); } Пост malandrinus`а годится и для твоего случая: main.cpp компилируется отдельно, test.cpp отдельно.

Его в on_drop и удалили. А половина модулей об этом не оповещена. Есть в этом нечто забавное - остановить ивент, а потом вместо него посылать новые. Хотя вполне возможно - оставшейся части посылать уже не on_drop, а on_release. Но тогда модулям придется обрабатывать 2 ивента вместо одного. Вообще "концепция ивентов" на мой взгляд включает следующие 2 пункта: - локальность подключения к системе ивентов - иначе можно и через bind_stalker подключаться, - и гарантированность доставки события(не важно как это будет сделано с пометкой, что предмет удален или даже переносом удаления из коллбека на апдейт или еще как, но сообщение должно дойти до всех подписчиков). Пример с инвентарем привел из-за явной симметрии on_take/on_drop и такого же явного ее нарушения. А так это может быть маленький квестовый модуль, который следит за каким-то предметом и обновляет статус побочного квеста. Явно же это не тот модуль, который надо регистрировать первым и в специальном реестре. Просто маленький иногда подглючивающий квест

А не получится так, что за ним шел коллбек, который у себя вел учет предметов в инвентаре(на on_take добавлял в словарик, на on_drop удалял из словарика). А тут до него коллбек не дошел и предмет так и остался висеть не удаленным. Ну и наоборот.

@Andrey07071977, неа. Вроде как надо убрать в коде ограничение на виртуальный радиус ламп(можно в xp-dev поискать коммит по этому ключевому слову), и в модели перенести источник света внутрь лампы.

Не миф. Это идеал, к которому надо стремиться. Не бывает 100% самокоментируемого кода, как не бывает 100% безглючного кода или 100% ооп кода. Но к ним можно стремиться К примеру твой кусок кода вполне самокомментируемый: for id=0,65535 do local cobj = level.object_by_id(id) if cobj and cobj:is_stalker() and is_bandit(npc) then if distance_between(db.actor, cobj) < 20.0 then remove_head(cobj) end end endА вот наличие комментариев только усложняет его модификацию. Увеличил радиус поиска бандитов - надо править в двух местах: в коде и в комментарии Хорошо было бы конечно забацать итератор по онлайновым объектам... Тогда было бы вообще, как в комментариях: for _, cobj in pairs(level.objects) do if is_bandit(cobj) and distance_between(db.actor, cobj) < 20.0 then remove_head(cobj) end end end

И не нужен. Каждый ведет свой проект. Понравилась фишка - вытаскиваешь к себе из другого проекта. Это уже давно обдумано. Потерялись авторы - делаешь форк и спокойно вносишь свою правку. Если авторы появятся и захотят, заберут правку обратно.

Звучит как http://xkcd.ru/927/