Перейти к контенту

Полтергейст

Опытные
  • Число публикаций

    318
  • Регистрация

  • Последнее посещение

  • AMKoin

    30 [Подарить AMKoin]

Сообщения опубликованы Полтергейст

  1. @Expropriator

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

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

    • Сомнительно 1
  3. @AndreySol, данные, необходимые для любых функций классификации (IsMonster и тому подобных). Туда же можно сохранить значение stype (modules.stype_чтонибудь). Да много всего можно там хранить, чтобы каждый раз не делать свою табличку для классификации.

  4. А никто ещё не переписывал скрипт  class_registrator так, чтобы в нем хранились все таблицы с данными для регистрации классов и классификации объектов?

    В оригинале данные просто используются один раз при старте игры и не хранятся нигде, что неудобно.

  5. @Dennis_Chikin, могу точно сказать, что по smart terrain есть ещё кучка движковых граблей.

    Чтобы NPC шёл в смарт, надо чтобы все эти проверки вообще вызывались движком. А это происходит не всегда. ЕМНИП, для NPC должен быть выставлен флаг Interactive, без которого всё это работать не будет. Как минимум, в оффлайне.

    Так же, надо чтобы can_choose_alife_tasks было выставлено в true. По умолчанию это так, и в оригинале оно нигде не меняется. В модах может и по-другому быть.

    Например, я таким образом отключал поиск смартов для "эксклюзивных" NPC, чтобы задавать им id смарта в явном виде.

     

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

     

  6. После выхода игры Pokemon GO и шумихи вокруг неё появилась одна "идея на миллион"... ну вы поняли. :D

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

    Вопрос у меня такой. Имеет ли смысл сейчас создавать тему об игре, создание которой скорее всего ещё даже не начато, и которая неизвестно когда выйдет? И если это кому-то интересно, то в каком разделе создавать такую тему?

  7. расстояние, при котором считается, что моб в оффлайне
    Не обязательно "в оффлайне". Просто проверяется, дошёл ли. В онлайне это тоже можно наблюдать - сначала идут медленно (работает action_alife_planner), а потом с определённого расстояния немного меняет маршрут и идёт быстрее. Потому что в этот момент задействуется логика, скрипты, состояния в state_mgr.На запрет идти к месту работы в оффлайне параметр job_position_treshold вообще никак не влияет.Насчёт can_choose_alife_tasks надо смотреть исходники движка.

     

    в оффлайне про логику и пути понятия не имеют
    Тоже не совсем верно. В оригинальном ТЧ идут к первой точке пути, от неё же и считается расстояние, из которого делается вывод - дошёл или не дошёл. Хотя при определённых переделках скрипта можно посылать их не в первую точку, а последовательно в 1, 2, 3 и т.д.
  8.  

     

    Вот что я не понял в звучавших предложениях - это заворачивать КАЖДУЮ работу в "псевдообъект". Подозреваю, что имелось в виду нечто иное.

    Не заворачивать, а преобразовывать. Все данные из таблицы работ перекинуть в объект, потом получить имя пути и сам путь, и сохранить в объект.

    В класс можно перенести целую кучу методов, отвечающих за всякие проверки и назначения работ. Для человекочитаемости это точно пойдёт на пользу.

     

     

     

    position_threshold - это интересная такая штука... Смысл - надо ли в офлайне бежать к начальной точке пути.

    Разве? По-моему смысл другой. В оригинале это расстояние, ближе которого в онлайне персонажу устанавливается логика (setup_logic_что-то-там). Дальше этого расстояния логика не работает. Полезность - сомнительна. Некоторые схемы могут подглючивать, если они активируются далеко от первой точки пути. Но это проблема или реализации этих схем, или криво написанной логики.

    То, что отметка о начале работы (beginJob) устанавливается, можно не принимать во внимание. Просто устанавливать её при достижении первой точке пути и не заморачиваться.

     

    Запретить NPC идти к месту "работы" можно или установкой object_flags, или вызовом can_choose_alife_tasks(false) (но не абы-как и абы-где), или установкой ему нулевой скорости передвижения в оффлайне. Position_treshold не влияет ни на что из этого.

     

     

     

    capacity - нужно для текущего формата, если используешь условия в работах.

    Условия - это predicate что ли? Ну разве что для тех случаев, когда надо вытеснять кого-то из смарта, когда кто-то другой занял работы "с условиями"... но всё равно не вижу в этом смысла. Такой параметр больше подходит для самих работ, чтобы можно было назначить нескольким NPC одну и ту же логику, не создавая для этого несколько работ (это одна из причин для хранения работ в виде объектов, а не таблиц).

     

     

     

    Кондлисты - мне не нравятся. Медленные, и читаются плохо. Лучше иметь возможность задавать явно.

    Что читаются плохо - это дело привычки. Да и всё равно от них не уйти уже, используются везде.

    Задавать явно возможность остаётся - написать {=вызов_функции} и в самой функции уже расписывать все подробности.

  9. Мой вариант (одна функция, работающая и в online, и в offline).

    function has_alife_info(info_id)
           if not (sim and info_id and info_id:len() > 0) then
                 -- ругаемся в лог
           end
           if actor then -- online
                 return actor:has_info(info_id)
           end
           -- offline
           return sim:has_info(0, info_id)
    end

    Для избавления от лишних проверок сделать немного по-другому - написать 2 разные функции для online и offline проверке, и в биндере игрока написать что-то такое

    _G.has_alife_info = has_info_online -- пишем в net_spawn
    _G.has_alife_info = has_info_offline -- в net_destroy
    • Нравится 1
  10. сейчас-то что мешает стейты внутрь логики засунуть (пусть даже по вашему человекопонятному)? кондлист доступен абсолютно для всего, для чего не доступен - сделать доступным. профит, не?

    Так я об этом и пишу. Если специально не создавать на каждый чих новый gulag type с собственным condlist'ом (вместо использования логики там, где это возможно), то большой простыни из кучи секций и длинных condlist'ов не будет. И как раз получится, что вместо простыней из load_states станет достуен condlist.

     

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

    В смысле, показать как должны выглядеть конфиги и описание работ?

    local t = {

    section = "logic@walker_1_logic",

    in_restr = "level_prefix_in_restictor1", out_restr = "level_prefix_out_restictor1", 

    squad = squad, group = groups[1],

    predicate = function(...) return true end,

    prior = 5, -- вот это руки чешутся убрать, но пока не знаю, как лучше это сделать

    position_threshold = 50, -- от этого со временем тоже надо избавиться

    state = {0, 1}  -- оставить обработку стейтов для совместимости, но в описании работ их стараться не использовать

    }

     

     

    [smart_terrain]

    type = general_lager

    squad = 0

    groups = 1,2,3,4

    capacity = 5 -- Не нужно. Ёмкость определяется количеством работ

    cond = {+info1}

    communities = dolg, freedom, monolith --Можно записать в виде condlist'а

     

     

    [smart_terrain]

    type = general_lager_normal, general_lager_alarm

     

    [general_lager_normal]

    squad = 0

    groups = 1,2,3,4

    cond = {+info1 !gulag_has_alarm}

    accept_npc_cond = {=npc_community(dolg:freedom:monolith)} --вместо checkStalker/checkMonster

     

    [general_lager_alarm]

    squad = 0

    groups = 1,2,3,4

    cond = {+info1 !gulag_has_alarm}

    accept_npc_cond = {=npc_community(dolg:freedom:monolith)}

     

     

    Это пока набросок, тут ещё есть куда стремиться и что исправлять. В частности, возможности этих самых condlist'ов используются не оптимально, хотя и лучше, чем было.

     

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

    Это подойдёт только туда, где список работ неизменен и заранее известен.

    В том же gulag_general подобное не прокатит.

  11. Ага, и упрощение тут где? Ну против например того что я эти смарты буду спавнить тогда когда мне надо, еще до кучи учитывая сценочные уникальные смарты с их заменой на универсальный потом если надо (далеко не всегда).

    Упрощение - в наглядности. С номерными state не сразу понятно, что они значат, надо их для каждой работы прописывать, надо искать, где и как они считаются. К тому же все эти 'if type == "gulag_1" then ... elseif type == "gulag_2" then' выглядят не очень красиво.

    А так сразу видно, какие работы и при каких условиях доступны, всё собрано в одном конфиге. Нет разделения на несколько смартов.

     

    Именно вот в данный конкретный момент для меня, когда я не смогу сидеть и переделывать все что есть под о великое.

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

     

    И расшифруй все же что ты вкладываешь в понятие тип работы, работа смарта или работа схемы, я никак не догоню

    Работа смарта - то же, что и раньше. То, что хранится в таблице Jobs.

    Тип работы, gulag type - то, что в конфиге пишется в строке type.

     

    И вот эта простыня что ниже приведена - это теперь на каждый гулаг вот такое городить?

    При правильной организации самой логики (logic@что-то_там) чтобы получить такую простыню, надо очень постараться. Часть условий просто уйдёт внутрь логики. Вместо переключения gulag type будет привычное переключение секций логики персонажей. Сюжетные условия редко включают в себя что-то кроме инфопоршней, и больше двух-трех type вряд ли потребуют для себя. Те единичные случаи, где условия будут выглядеть слишком длинно и непонятно, можно засунуть в функцию в xr_conditions и вызывать оттуда.

     

    И вбивать туда условия одни и те же для всех смартов?

    Если там условия реально одни и те же, можно через #include ссылаться на типовые конфиги там, где это требуется.

     

    писать под каждый смарт простыню конфига, под каждый gulag_type свой gulag_xxx.script

    Как раз можно будет избавиться от написания loadStates и уменьшить эти самые файлы.

    В принципе, можно и с checkStalker/checkMonster также поступить, но тогда или строка cond разбухнет ещё больше, или потребуется делать ещё один condlist в конфиге. Тут пока ещё есть над чем думать.

     

    И вообще любую проблему можно решить, написав тонну конфига. Ну, или попытаться. Просто попробуйте представить объемы этих простыней... попробуйте представить их редактирование рядовым мододелом

    Оттого, что это всё будет не в виде одной простыни, а раскидано по параметрам путей, конфигам и скриптам, меньше всё равно не получится. Можно конечно пытаться делать "самособирающуюся" из путей логику, но обобщить и "сжать" всё - не получится. Где-то всё равно это придётся писать, особенно для сюжетной логики.

  12.  

     

    при таком переключении нужно убедиться, что распуская по условию один смарт, все неписи из него пойдут именно в тот смарт, который предполагается следующим

    Для отдельных NPC порядок посещения смартов определяется в секции smart_terrains из customdata. На него эти правки вообще не влияют.

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

  13. Чем вам не угодили стейты, почему от них надо избавляться?

    Потому что вместо них можно использовать несколько gulag type. В конфиге это будет выглядеть примерно так:

     

     

    [smart_terrain]
    type = general_lager, esc_fabrika_bandit_normal, esc_fabrika_bandit_alarm
    ;больше в этой секции ничего не надо писать
    
    [general_lager]
    cond = {+esc_kill_bandits_quest_done}
    ;Пишем условие не для смарта целиком, а для каждого типа отдельно. Использовать вместо state.
    
    [esc_fabrika_bandit_normal]
    cond = {-esc_kill_bandits_quest_done !gulag_has_alarm}
    groups = 1,2,3,4 ;это просто для примера
    squads = 5,6,7,8 ;это тоже
    
    [esc_fabrika_bandit_alarm]
    cond = {-esc_kill_bandits_quest_done =gulag_has_alarm}
    groups = 1,2,3,4 ;это просто для примера
    squads = 5,6,7,8 ;это тоже

     

    Вместо использования состояний, тип esc_fabrika_bandit разделён на esc_fabrika_bandit_normal и esc_fabrika_bandit_alarm. А general_lager здесь для того, чтобы не делать отдельный несюжетный смарт esc2_st_fabric.

  14. Но в том и дело, что оригинал - не сохраняется. Его уборщик убирает. Теоретически. Тут бы надо кому-то в исходники глянуть.

    Я так понимаю, копия нужна для защиты оригинала от изменения.

    После вызова obj:command( act, false) действие добавляется в очередь. А вот какие странности будут, если попытаться изменить его после добавление в очередь

    local new_act = action_first(obj, что-то_там)
    new_act:set_action(что-то_ещё)
    

    - можно только догадываться.

     

    И кстати переменную act лучше переименовать, т.к. есть одноимённый экспортированный класс.

  15.  

     

    еще одно нагромождение совершенно не нужное, когда надо и так разгружать то что имеется

    Это и будет то, что имеется, просто методы будут вызываться не из смарта, а из самой работы. Один раз при загрузке работ преобразовывать их из таблиц в объекты, объединяя при этом работы с одинаковой секцией логики в один объект. Все эти объекты занести в индексированную таблицу (которая self.Job) и в хеш-таблицу, в которой ключом будет имя секции. Вот, собственно, и всё.

     

     

     

    а еще надо будет учитывать динамические лтх, и, прости хоспаде, стейты.

    А что их учитывать? Для каждого типа работ сделать промежуточный объект, в котором будет храниться вся инфа о типе работ (имя ltx и ссылка на него, ссылка на gulag_***.script, текущий state), и пропускать все обращения к gulag_***.script через него.

     

     

    если ты сделаешь объединение разных типов работ, от этого резко упадет наглядность

    Во избежание путаницы не использовать несколько типов работ и переключение state в одном смарте. От последнего со временем вообще лучше избавиться.

     

     

     

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

    Как тогда быть с путями, логикой и именованием этих "укрытий"? Да и рельеф на других уровнях (где игрок не был ещё) вряд ли можно просчитать...

  16. Как и заворачивания работ каждую в отдельный псевдообъект. Мороки много, толк - сомнителен.

    При правильном подходе толк будет.

    Во-первых, вместо хранения кучи таблиц, описывающих работы с одинаковой логикой, достаточно всего один раз их преобразовать в объекты. Так, чтобы на одну секцию логики приходился только один объект  работы. В этих же объектах хранить табличку NPC, назначенных на эту работу. Сокращение количества записей о работах может увеличить производительность. Да и на каждый чих дёргать работы из таблицы уже не нужно будет.

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

     

    Для реализации поддержки нескольких "gulag type" потребуется как-то объединять работы разных типов. Возможно потребуется делать ещё один класс, хотя можно попробовать обойтись и обычной таблицей. Если бы не было номерных состояний и списка группировок в строке communities, то этого можно было бы вообще не делать.

  17. Касательно допиливания smart_terrain'ов напильником. Я так думаю, лучше все работы завернуть в класс с соответствующими методами. Т.е. чтобы каждая работа была не табличкой, а объектом класса. Для объединения работ с одним "gulag type" создать ещё один класс, в который засунуть проверку условий приёма NPC и всякие атавизмы типа номерных состояний.

     

    • Полезно 1
  18. Итак, в момент, когда актор оказывается перед глазами стоящего под мостом, он же оказывается в памяти "телезрителя", находящегося за 500 метров. Но в принудительном онлайне.

    Если, затем, подойти на 300 метров к телезрителю, сохраниться, и загрузиться - телезритель сорвется в бой, и пойдет в сторону актора с недобрыми намерениями.

    Я делаю так - в биндере на этапе reinit принудительно очищаю все запомненные объекты через enable_memory_object, и отключаю неписям зрения (enable_vision). Включаю обратно только после того, как игра загрузилась полностью (т.е. игрок уже не видит экран загрузки). Помимо этого прописал в enemy_callback и схеме xr_danger игнорирование всех врагов и опасностей до того, как игра загрузится. Частично это помогло. Во всяком случае почти исчезли ситуации, когда никем не обнаруженный игрок сохранился где-то спрятавшись за углом, а потом загрузился и все сразу его заметили.

    Насколько это влияет на это "дальновидение" - не знаю, специально не проверял, т.к. принудительный оффлайн намертво отключил. Можно ещё попробовать вызвать skip_transfer_enemy(true), но вроде бы это только для зверей...

    • Полезно 3
  19. Причем, при внимательном изучении оказалось, что по npc:best_danger() он постоянно получает этот самый danger с типом attack_sound, источником является он сам.

    Похоже на какие-то косяки в реализации скрипта xr_danger.

    Evaluator для stalker_ids.property_danger должен возвращать false, если источником опасности является сам объект, или он далеко, или опасность была давно. Помимо этого можно для "просроченных" или неуместных опасностей дописать удаление объекта из памяти (через enable_memory_object). В оригинале, насколько я помню, такое удаление происходит только для игнорируемых врагов.

    Хотя определять тип звука по ogg-комментарию, а не по событию, вызывающему этот звук - это как-то... странно.

  20.  

     

    npc:set_mental_state( anim.free ) npc:set_body_state( move.crouch ) - вылет error in stalker with visual actors\novice\green_stalker_4 В куда копать ?

    Это движковый вылет, я его уже описывал. Вылечить без ковыряния движка нельзя. Просто надо учитывать, что сочетание anim.free и move.crouch недопустимо.

    • Полезно 1
  21.  

     

    имя гулага. то самое, что gulag.name. И оно как бы, для каждого гулага уникально как мы знаем.

    Я бы проверил на предмет того, откуда берётся gulag.name. Если НЕ из strn:name() (где strn - объект smart_terrain), то тогда всё понятно. Вероятно, туда каким-то образом попадает type вместо name.

AMK-Team.ru

×
×
  • Создать...