RayTwitty

Конечно, только многие пока шкерятся по приватным свн

В 179 ревизии я эту правку кстати немного доделал. В ХЕ по идее, должно всё так же выглядеть, хотя я детально там код не разбирал. https://xp-dev.com/sc/204486/HEAD/

Без индивидуальной настройки ламп в СДК (их виртуального радиуса) не имеет смысла. По дефолту там всегда 0.1, а при таком значении тень будет уродливая (если речь идет об аварийной лампе, из-за которой в своё время всё и затевалось).

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

@Malandrinus, в любом случае, придется делать под каждый мод свой бранч, ибо всё универсализировать нельзя, да оно и не нужно. Яркий пример - текущее, вроде как "общепринятое" репо на xp-dev - там сделан огромный экспорт всего и вся в скрипты, хотя по моему мнению, очень много можно делать прямо в движке, не парясь с экспортом. Так что это не просто "по-другому экспортировать", а вообще пересмотреть всю техническую часть мода. Например, в OGSE 655 скриптов - отсюда вытекает, сколько времени уйдет на "правильную" реализацию всего и вся.

В level нет подходящего прототипа, так что никак. Ну, пофиксь и потом сюда кинь код правок или в лс - залью.

@НаноБот, если никаких изменений/дополнений по этим правкам не планируется, могу добавить в проект.

С помощью него можно писать "сложные" эффекторы по типу тех, которые создавали разработчики для монстров в движке (контролер, пси-собака etc). А почему никто не применил до сих пор - да просто потому, что для повседневных задач хватало экспортированных в пространство level методов (add/set/remove_effector).

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

Ну так я и не говорил, что в скриптах мы будем видеть какой-то класс, всё создается внутри движка и там используется. Передаю внутрь функции, которая будет вызвана после отработки первой функции.

У себя уже давно использую оригинальный пысовский метод level.add_call() - как раз для таких "быстрых" таймеров. Каждый новый вызов этого метода, по сути и является созданием экземпляра класса и всё действо помещается в одну строку луашного кода. Но при такой компактности, конечно, и наворотов меньше чем у malandrinus'a - например из входных параметров только: имя таймера, время (таймаут), функция, которая будет вызвана по окончанию таймера и аргументы, переданные в эту функцию. То есть это именно таймер, с одним лишь условием - временем. Сохранение между сейвами так же не предусмотрено, но лично для моих нужд, пока этого хватает.

Там вроде бы не только про set_ignore_game_state_update было. По первому линку - 2 вопроса, по второму - 3 набора методов, один из которых (uint cast_ХХХ()) используется в OGSE.

Ещё не факт, что быстрые слоты реализованы с учетом всех экспортированных в скрипты функций. Можно сделать так, чтобы в пределах движка работало, а в скриптах всё осталось по старому (хотя, я не вникал, как там реализовано). Но по дефолту, в той функции, которая ставит предмет в слот, идет проверка на указанный слот в конфиге. Соответственно, надо указать "slot = 2" например. Или "slots = 1,2,3" - вроде так теперь работает. А может в слоте уже есть аптечка... Либо он банально как-то не так вызывает... У меня иногда бывало и такое: функция лежит в одном скрипте, а пытаюсь вызвать функцию из другого скрипта (с похожим названием) и потом полчаса, проклиная всех разработчиков сталкира, выясняю в чём дело И это, давайте без перехода на личности. Человеческий фактор, как я уже заметил выше, никто не отменял.

Ну, при изменении скелета (а добавление кости это изменение скелета), надо переделывать и анимации. Точнее, заставить двигаться новую кость вместе с этими анимациями. Уже не знаю, надо ли переделывать всю анимацию, но вроде есть способ по подстройке нового скелета под эту анимацию (но это наверняка шаманство - моделлеры точнее ответят). И что на счет вопросов? Я уже не знаю куда тебе писать - в личку не отвечаешь, тут тоже игноришь... Я конечно понимаю, мб времени нет и всё такое, но чиркнуть пару предложений - вполне можно. В xray-extensions нет этого. Без исходников там очень много править бы пришлось.

Покажешь код на с++?

http://www.amk-team.ru/forum/index.php?showtopic=10339&p=910319 Там как раз про это есть (Класс game_object->Хак для изменения значений в памяти объектов). На исходниках такой хак сделать в принципе нельзя... Но, с другой стороны можно понаделать любое количество методов и экспортировать чуть ли не все классы. Чем собственно и занимается alpet. Уже сейчас там почти все параметры актора можно в скриптах заиметь и многое другое. Но, по этому функционалу инфы вообще никакой нет, разве что самому лезть в сырцы и смотреть, где чего экспортировано.

Зачем нетпакет, если можно читать/писать значения прямо в память? 2015 год жи.

Слишком много переделывать, хотя, даже не много, а всё. Авторам вики может не понравиться, что я всё ихнее снесу и запихну своё... Так что на счёт вопросов?

А, вот оно что. Теперь понятно. Насколько я понял, речь идет о CCameraBase? Просто желательно иметь точную информацию для FAQ. И ещё небольшой вопрос по поводу глобального метода set_ignore_game_state_update() - он у вас используется в ogse_sleep_mgr.script. Насколько я понял, он связан с апдейтом погоды и применяется в фиксе восстановления солнца. Хотелось бы узнать поподробнее про этот метод, ибо в оригинале (оригинальной игре с библиотеками из ХЕ) наблюдаются проблемы с обновлением погоды между перезагрузкой сейвов, а иногда и зависанием текущего часа. Предполагаю, что как-то связано с этим методом (точнее, с его неприменением).

@Malandrinus, есть вопрос по поводу одного куска кода: ogse_car_control.script local cam_cur_addr = car:get_car_int(nil, 1320) car:set_memory_float(nil, lim_yaw_min, sum_args(cam_cur_addr, 40)) car:set_memory_float(nil, lim_yaw_max, sum_args(cam_cur_addr, 44)) car:set_memory_float(nil, lim_pitch_min, sum_args(cam_cur_addr, 48)) car:set_memory_float(nil, lim_pitch_max, sum_args(cam_cur_addr, 52))Собсно, а что делает функция sum_args? Посмотрел в движке - просто суммирует два параметра. Так почему просто не написано cam_cur_addr+40? И вопрос по поводу функции изменения значений в памяти - set_memory_float, в каком объекте эти значения правятся?

http://www.amk-team.ru/forum/index.php?showtopic=10339&p=910319 Составил описание некоторых методов, которые добавляет ХЕ, в частности по game_object... Хотя, с некоторыми функциями даже я не разобрался В частности, методы для инвентарных предметов по созданию источника света (насколько я понял, чтобы создать свечение как от артефакта). Пробовал применять таким образом (смотря на аптечку, которая была на полу): local obj = level.get_target_obj() if obj then obj:create_light01() obj:set_light01_range(5) obj:set_light01_angle(120) obj:set_light01_enabled(true) obj:set_light01_shadow(false) obj:set_light01_pos(vector():set(0,0,0)) obj:set_light01_color(vector():set(1,1,1)) obj:set_light01_type(12) log1("light created") endНо после вызова у меня скрипт тупо виснет. Печалька. Да и метод для машин bool get_car_shift() у меня постоянно возвращает фальс (и при движении, и при стоянии на месте). Остальное более менее понятно. upd: 23/01/2015, 17:50 ах да, ещё мифические uint cast_car() uint cast_game_object() uint cast_hud_item() uint cast_inventory_box() uint cast_inventory_item() uint cast_weapon()

Агрессия (от лат. aggressio — нападение) — мотивированное деструктивное поведение, противоречащее нормам сосуществования людей, наносящее вред объектам нападения, приносящее физический, моральный ущерб людям или вызывающее у них психологический дискомфорт. Википедия. Ознакомьтесь. Если я пишу пару раз, это не значит миллион раз, это значит именно пару раз. Опять для вас использую bb-код, не заметили? Подсчитать количество палок колбасы для квеста Сидора и постоянный подсчет предметов для отображения например на худе - две абсолютно разные задачи, которые решаются разными способами.

Читали бы хоть внимательнее или постоянно bb-коды для вас использовать? Пруф?

Можно итерацию, можно ловить на колбеках take/drop. Всё зависит от задачи, если пару раз за игру надо узнать - можно и итерацией ограничиться.

А если просто по этой таблице итерироваться, зачем while? Насколько я понял, в таблице лежат айдишники аномалий, который ушли в оффлайн - вот только их и надо переводить обратно. Хотя, конечно вопрос был не в этом и вопрос интересный... Попробуй посмотреть, как сделано управление кострами в последнем OGSE - там совершенно точно они прямо перед ГГ разжигались.