Очень жаль, что проект загнулся... Хорошее было начинание, здравое - дать разработчикам возможность подобрать для своих идей наиболее оптимальное сочетание новых возможностей. Нас, например, устраивает нынешний набор функционала на 98%. Просто хотелось бы еще добавить продвинутую работу с предхитом из ОГСЕ, но без тепловизоров, дополнительных слотов и т.п. И не помешал бы доступ к главному игровому окну из NLC, но только это и ничего больше... Но надежда никогда не умирает в сердце сталкера. Авось, на нашем веку еще найдутся энтузиасты и продолжат это благое для всех дело.

Да, Да, есть такое дело, но это мелочи, украшательство. Есть, имхо, две вещи, которые могли бы существенно повлиять на дальнейший ход разработки всех модов на базе продвинутого двигла: 1. Решение вопроса получения и подмены указателя на "обидчика" в коллбеке предхита. Дало бы шанс избавиться от читерных "именных" пуль. 2. Функция получения объекта главного игрового окна. Чтобы получить доступ к элементам худа главного окна (миникарта и т.д.). Вот это было бы действительно мощным функционалом, толчком для для дальнейшего развития, имхо...

Это я вижу на примерах, а вот обратная задача почему-то не решается. А проблема "именных пуль" на самом деле была и остается весьма актуальной, имхо. Ибо это абсурд, когда не успеешь чихнуть, а вся Зона уже в курсе... Но если технически это невозможно запатчить, то придется и дальше терпеть это читерство. В ОГСЕ была функция получения указателя на объект в памяти, по всей видимости. write_memory_int(db.actor:cast_game_object(), p_s_hit, hit_offset.who) Хорошо бы что-то подобное cast_game_object() вмонтировать в текущий xray-extensions-master-portable.

@dsh изменение whoID ни на что не влияет. Полагаю, что нужно изменить who по смещению +24 = pointer на обидчика. О чем я выше и написал. Во всяком случае, это единственное, что не удалось подменить... Ибо не ясно на что, собственно, менять.

@dsh Спасибо, такой функции у меня нет, но с горем пополам мне удалось вычитать и даже менять параметры хита в 152-м коллбэке. Всё чудесно, но поставленной цели добиться всё же не удалось. А цель была примерно следующая - подменить параметры хита таким образом, чтобы он наносился якобы от другого лица. Есть ситуация когда актер - изменился в лице, сделал пластику, вселился в чужое тело (нужное выбрать) - словом, ну никак не могут окружающие знать, что это именно ГГ нанес удар. Так вот, менять параметры предхита удается любые, но это не возымело желаемого эффекта. Единственный параметр who по смещению +24 = pointer на обидчика, судя по всему. Вот не соображу как его перенаправить с актера на саму жертву или еще на кого-нибудь. Заранее благодарен за любую информацию по данной теме.

Всем доброго времени суток. Возникли вопросы по использованию callback["before_hit"] = 152 callback["npc_hit"] = 153 В первый, похоже, передаются два указателя. Во второй - один указатель. Заранее благодарен за информацию по методам дальнейшей обработки информации в этих коллбеках.

Нет, ребята. Это аномалия, которая по маршруту летает. Такая в классике в Х-18 летает, огненная.

Всем приветик, коллеги! Может вопросик и не в тему, но мне кажется, что это радиус алайфа так работает. Одним словом, имеем торрид. На близкой дистанции он бодро летает и всё фигачит на своем пути. Но стоит отойти чуток и он практически останавливается и начинает рывками двигаться. Вопрос в следующем - а можно ли на этот радиус как-то влиять? У нас алайф гораздо шире и торможение выглядит удручающе. Заранее благодарен.

С бартером, как обычно, вопросов больше чем ответов. Некоторые мысли посещают, но до стройной и, главное, обоснованной системы они не доходят. И тут не в оформлении вопрос, а в целесообразности. Привычные товарно-денежные отношения более гибкие. Посмотрим, что вы там надумали. А вдруг? Извини, но это полная глупость. В канале ствола действует "симметрия формы" пули, а после выхода из канала начинает работать больше "симметрия массы". Это значит, что в стволе пуля будет двигаться вдоль и проворачиваться нарезами независимо от расположения ее центра масс. А вот по вылету, смещение центра масс от оси геометрической симметрии(сопротивление воздуха) вызывает прецессию, как у любого неидеального волчка. Поэтому, хвостовая часть пули в полете описывает окружность, а ее полет происходит по очень вытянутой спирали. Чем точнее выдержана симметрия формы к симметрии массы, тем меньше эта прецессия волчка и, соответственно, меньше торможение и точнее стрельба. Пуля, у которой центр масс находится по оси геометрической симметрии совсем чуть-чуть впереди центра ее лобового сопротивления в воздухе, будет лететь стабильно. Но при переходе в более плотную среду, центр лобового сопротивления резко смещается вперед и та самая "неидеальность" заставит ее начать кувыркаться.

Всем доброго дня! Пишу сюда, может не для меня одного этот вопрос актуален... Есть жгучее желание и потребность подключить к модернизированному движку в его текущей редакции библиотеки расширений LUA (io, os, package,XML...) и библиотеки OGSE, но знаний и понимания не хватает. Разместил библиотеки Lua_extensions и OGSE у себя и честно пытался в _g.script инициализировать их по образу и подобию. Мои танцы с бубном вокруг этой темы в лучшем варианте закончились примерно так: Чтобы дальше не заниматься шаманством, прошу людей сведущих дать развернутые инструкции по подключению этих библиотек и оформлению "шапки" _g.script. Заранее благодарен.

Дополнительная проверка показала, что в сейв ложатся левел- и гейм-вертексы нижнего уровня, а координаты верхнего. Выходит, "падение" происходит еще до или в сам момент сохранения.

Всем привет, коллеги! Обозначилась такая проблема. На наземной локации есть подземелья. Сетка проложена везде. Сетка без ошибок. Графпойнты везде расставлены. Верхние ноды не имеют связи с нижними 100%. Но при сэйв/лоаде неписи, находящиеся на локации вверху (на земле), иногда проваливаются в подземелья. Потом они спокойно идут на ту точку, откуда "упали". Такое же было замечено в х16 в главном многоэтажном зале. В теме по SDK было выдвинуто предположение, что в движке объектам назначаются ноды, лежащие ниже объекта. Если позиция объекта окажется ниже координаты ноды, то назначится нижележащая нода. Отсюда к вам, уважаемые, вопрос - можно ли добавить правку в движок, чтобы задавал не нижележащую ноду, а ближайшую по высоте. Или при расчете ноды дать больший "допуск" по высоте? Платформа ТЧ 1.006 с x-ray extensions.