Редактирование движка X-Ray

[Полтергейст 37]

В скриптах он уже не упоминается - ни в регистраторе классов, ни в lua_help. Так что, скорее всего нет.

Изменено 2 Марта 2011 пользователем Полтергейст

[Полтергейст 37]

Это чисто скриптовый класс (точнее комбинация двух классов, или сет

Да, точно, что-то я туплю. Классы ce_smart_zone и cse_alife_smart_zone остались на месте, значит восстановить можно.

[Полтергейст 37]

Пробовал создавать артефакты на клиентском классе CBlackGraviArtefact (имя скриптового сета - AF_BGRAV) и столкнулся с неприятной проблемой: каждый раз на месте перехода арта в онлайн отыгрывается зацикленный партикл anomaly\galantine, отыгрыш которого вшит в движок (это можно увидеть даже "блокнотом"). Кто-нибудь с этим сталкивался? Этот скриптовый сет в оригинальной игре нигде не используется, возможно в билдах есть.

Изменено 17 Июня 2012 пользователем Полтергейст

[Полтергейст 37]

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

Во-первых, в файле alife_monster_movement_manager_script.cpp надо исправить экспорт метода path_type.

 

Во-вторых, в файле alife_monster_patrol_path_manager.cpp надо добавить метод

 

void CALifeMonsterPatrolPathManager::path(CPatrolPathParams *params)
{
    path(params->m_path);
    start_type(params->m_tPatrolPathStart);
    route_type(params->m_tPatrolPathStop);
   use_randomness(params->m_bRandom);
}

 

 

 

и экспортировать его в Lua, прописав в файле alife_monster_patrol_path_manager_script.cpp. Существующий (тот, что принимает строку как аргумент), наоборот, надо убрать из экспорта. Если он больше нигде не используется, его можно совсем убрать из кода. Также из экспорта можно убрать методы start_type, route_type и use_randomness (те, что работают на запись), т.к. эти параметры считываются из переданного объекта CPatrolPathParams.

 

В-третьих, в файле alife_monster_brain.cpp нужно поставить проверку на can_choose_alife_tasks() до вызова select_task, а не внутри него. И если can_choose_alife_tasks() вернёт true, то делать как есть сейчас (вызывать select_task и далее), а иначе сразу переходить к movement().update(). Как-то вот так:

 

[spoiler=CALifeMonsterBrain::update]

void CALifeMonsterBrain::update ()

{

     if (can_choose_alife_tasks())

     {

          select_task ();

          if (object().m_smart_terrain_id != 0xffff)

               process_task ();

          else

               default_behaviour ();

     }

     movement().update ();

}

 

 

это нужно для того, чтобы установленный из скрипта тип пути не сбрасывался.

Для передвижения в оффлайне этого должно быть достаточно, но надо проверять.

[Полтергейст 37]

В дополнение к своему посту про правки, касающиеся оффлайн-передвижения. Во-первых, забыл дописать кое-что - в void CALifeMonsterPatrolPathManager::path надо делать проверку параметра на null. 

void CALifeMonsterPatrolPathManager::path(CPatrolPathParams *params) {

    if (params == null) {

        m_path = null;

        m_actual = false;

        return;

   }
    path(params->m_path);
    start_type(params->m_tPatrolPathStart);
    route_type(params->m_tPatrolPathStop);
   use_randomness(params->m_bRandom);
}

 

 

 

Во-вторых, напишу свои мысли по поводу исправления синхронизации онлайн и оффлайн передвижения.

 

В файлах xrGame/stalker_alife_task_actions.cpp и xrGame/ai/monsters/states/monster_state_smart_terrain_task* прописано прямое обращение к методу task, возвращающему объект CALifeSmartTerrainTask. Метод этот вызывается из объекта smart terrain. Это плохо тем, что полученный task не будет синхронизирован с данными оффлайн-передвижения, если используется передвижение по путям . Чтобы это исправить, надо, чтобы в классе CALifeMonsterDetailPathManager вместо

params m_destination;

было

CAlifeSmartTerrainTask *m_destination;

при этом реализацию класса CAlifeSmartTerrainTask надо брать из исходников ЗП (чтобы можно было создать CAlifeSmartTerrainTask для произвольной точки). Затем надо внести соответствующие изменения в код класса CALifeMonsterDetailPathManager, чтобы ничего не "поломалось" после изменения типа m_destination. В него же надо дописать что-то примерно такое

public CAlifeSmartTerrainTask * CALifeMonsterDetailPathManager::get_destination() {
      return m_destination;
}

и далее в файлах xrGame/stalker_alife_task_actions.cpp и xrGame/ai/monsters/states/monster_state_smart_terrain_task* заменить вызовы метода task из smart_terrain на вызов CALifeMonsterDetailPathManager::get_destination(). Это значительно исправит синхронизацию онлайн и оффлайн передвижения.

Где-то ещё остался баг, из-за которого старый способ управления npc (game_object.command) конфликтует с новым (motivation_action_manager) по вопросу "куда идти" - в smart terrain task или туда, куда указано через game_object.command. Как-нибудь попозже и про него напишу.

 

 

Изменено 11 Августа 2015 пользователем Полтергейст

[Полтергейст 37]

Нашёл кусок кода в файле /xr_3da/xrGame/ai/stalker/ai_stalker.cpp (ТЧ), который удаляет все патроны для active_item. Он находится в самом конце метода

void CAI_Stalker::Die(CObject* who)

и начинается ПОСЛЕ строки

inventory().SetSlotsUseful(false);

Было бы очень желательно его удалить, т.к. такое поведение иногда мешает, а в некоторых случаях будет приводить к вылету e_parent && e_entity. Кому понадобиться это удаление восстановить, могут сделать его через скрипты.

[Полтергейст 37]

Попытался найти в исходниках что-нибудь по этой проблеме

http://www.amk-team.ru/forum/index.php?showtopic=6185&page=276#5505

но так и не понял, чем она может вызываться. transfer_enemy работает только между монстрами (причём это определяется явно не по строке species), а CHitMemoryManager я не вижу передачи информации о хитах другим игровым объектам. И куда тут копать?

[Полтергейст 37]

Возник вопрос насчёт использования smart_cast. Если ли заменить такую конструкцию

CGameObject *GO = smart_cast CGameObject*(O);
CInventoryItem *pIItem = smart_cast CInventoryItem*(GO);

на

CInventoryItem	*pIItem = smart_cast CInventoryItem* (O);

будет ли оно работать? Видно, что 2 строки идут подряд и существование объекта O не проверяется, и он дальше нигде не используется. Может это надо для самого smart_cast?

Код взят из метода CBaseMonster::OnEvent.

P.S. угловые скобки после smart_cast "съелись" форумным парсером.

Изменено 26 Августа 2015 пользователем Полтергейст

[Полтергейст 37]

abramcumner, я уже разобрался. Работать будет, т.к. в этом же классе делается smart_cast из CObject в CInventoryItem напрямую. Вообще в клиентских классах приведение типов как-то странно используется. Например, в net_Spawn можно увидеть приведение типа к самому себе.

 

 

Нашёл один баг, связанный с записью killer_id и game_death_time в серверные объекты. В существующем варианте она делается через клиентский класс CEntity, то есть только тогда, когда объект в онлайне. Если же серверный коллбек on_death вызывается в оффлайне, то ничего не записывается. Намного лучше было бы дописать такой метод

 

 

void CSE_ALifeCreatureAbstract::on_death(CSE_Abstract *killer)
{	m_game_death_time = alife().time_manager().game_time();
	if (IsGameTypeSingle())	{
		NET_Packet P;
		u_EventGen(P,GE_ASSIGN_KILLER,ID);
		P.w_u16(u16(killer->id));
		u_EventSend			(P);
	}
}

 

и вырезать из класса CEntity целую кучу кода, которая отвечает за то же самое. Оставить можно разве что смену модели на corpse_visual, но если благодаря правкам будет (или уже) реализована смена модели из скрипта, то и это не имеет смысла.

Изменено 27 Августа 2015 пользователем Полтергейст

[Полтергейст 37]

 

 

Сначала-бы наверное стоит разобраться в ценности кэллбэка на смерть в офф-лайне... Хотя-бы начиная с того, как вообще возможно кого-то в офф-лайне убить ? Не релизнуть, а именно "убить".

Прямо так взять и вызвать on_death у "убиваемого" серверного объекта. Перед этим желательно установить ему здоровье в 0 через update-пакет, но вроде как не обязательно.

[Полтергейст 37]

В файле stalker_movement_manager.cpp есть такие строки

VERIFY					((m_target.m_mental_state != eMentalStateFree) || (m_target.m_body_state != eBodyStateCrouch));
...
VERIFY2	((m_current.m_mental_state != eMentalStateFree) || m_current.m_body_state != eBodyStateCrouch,*object().cName());

они приводят к вылету, который возникает при попытке вызвать

game_obj:set_mental_state(anim.free)
game_obj:set_body_state(move.crouch)

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

[Полтергейст 37]

В том же файле (stalker_movement_manager.cpp) есть строки, приводящие к вылету при недоступности пути. По-хорошему в этой ситуации лучше просто сбрасывать путь и вызывать скриптовый callback, оповещающий об этом.

 

 

если я правильно помню, то код этот там вообще не доделан.

Что именно не доделано?

[Полтергейст 37]

 

 

ри ошибке функция ничего не делает, просто скидывает инфу в лог об ошибке

Для скриптовых вызовов это полезно, но что будет, если подобное произойдёт при чтении параметров движком из system.ltx?

[Полтергейст 37]

 

 

тут часто этот вопрос проскакивал, вроде неплохо было-бы в движке сделать, ну вот пусть сделают, а практика покажет лучше это или хуже того что есть

Ничто не мешает сделать эти функции под другими именами. Оставить оригинальный r_float, а добавить не вылетающий r_float_safe.

[Полтергейст 37]

Есть ли среди проектов по изменению движка такой, где только исправляются баги того функционала, который есть, без добавления нового? Такой,  чтобы на выходе был обычный "чистый" движок с исправлением вылетов, подвисаий, визуальных дефектов в UI и т.п.

Изменено 23 Мая 2019 пользователем Полтергейст

[Полтергейст 37]

@Expropriator, не очень понял это сообщение. Разве в оригинальном (релизном) движке нет багов?

 

[Полтергейст 37]

@Expropriator

По существу же понятно о чём я спросил? Ищу проект модификации движка ТЧ, где из изменений есть только исправление вылетов, зависаний, фризов, глюков рендера и UI. Без добавления нового функционала, без геймплейных нововведений, без экспорта новых функций (кроме тех, которые были экспортированы в ЧН и ЗП). Наиболее похожий это OpenXRay, но он на движке ЗП. На движке ТЧ нет таких проектов?

[Полтергейст 37]

@Expropriator, в существующих проектах модифицированных движков от ТЧ такие исправления есть, только кроме них там ещё много всякого нового, не всем нужного.