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

Прозекторская


Рекомендуемые сообщения

"Вскрытие показало, что больной умер от вскрытия."

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

Изменено пользователем Dennis_Chikin
Ссылка на комментарий

модераторское:

 

дискуссия слегка переместилась в эмоциональную сферу, а предложения оппонентов, на сколько я вижу, читаются невнимательно. Ну и сами предложения эти несколько неконкретны.

 

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

Предлагаю внимательно перечитать хотя бы СОБСТВЕННЫЕ тексты, и попробовать сформулировать более четко и доходчиво. Я через некоторое время напишу, как именно понял.

 

2 Murarius: не совсем так. В некоторых случаях код не нужен. Или его еще нет. А вот описание в этих случаях желательно бы как можно более однозначное.

Изменено пользователем Dennis_Chikin
Ссылка на комментарий

 

 

  Карлан писал(а):
попробуй приведи код того что ты предлагаешь, а то я себе по своему вижу, ты по своему, а там может че и порешим

Вот именно. А то вы тонете в общих рассуждениях. Я вообще представлял себе посты в этой теме так: Утверждение -> Теоретическое обоснование (если требуется) -> Код.

Уверен, Денис тоже хотел что-то подобное наблюдать.

Самодисциплинируйтесь, пожалуйста.

Ссылка на комментарий

Вроде, 20 минут выкроил, выполняю обещанное.

 

Итак, мне вот тоже не нравятся работы с состояниями. Не нравятся тем, что получается слишком много букв, и очень трудно контролировать все это глазами. Буквально пару дней назад описка с 0 вместо 1 - и пол дня на то, чтоб ее найти.

Простыни получаются преразвесейшистые.

 

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

 

Из собственно же методов борьбы с развесистыми простынями вижу два простых (в смысле, скриптовых, не дожидаясь, пока с неба свалится экзешник, чтоб сам кофе варил, и за пивом бегал):

 

1. Развернуть часть текущего ужаса и кошмара в плоские таблицы (все равно xr_gulag в итоге именно их хочет, и формирует). То есть, не вот вставка в переданную таблицу, и не проверка на каждый чих "подходящести", а отдать готовые. При некотором усилии можно эти работы со стейтами записывать так, что просто скользя глазом замечаешь отличия. И руками можно посчитать. А потом валидатор напустить, в сомнительных моментах. Этот код я вкладывал в более специализированной теме, ссылку давал, примеры давал, повторять смысла не вижу. Кому надо - найдет/посмотрит.

 

2. Перейти, вот как я понял прозвучавшие здесь предложения, к системе один смарт - несколько гулагов в нем.

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

То есть, для каждого стейта - один гулаг, в смарте - по гулагу для каждого стэйта.

 

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

При покидании смарта - запустили "сборку мусора".

 

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

 

То есть, если коротко, то оно вот как-то так в итоге выглядит:

local g_comms = {

["atp_brigada"] = "stalker", -- 14.08, Калинин

["atp_fabrika_bandit"] = "bandit",

-- ["atp_stalk"] = "stalker", -- допа 2011

...

 

local g_jobs = {

 

["atp_fabrika_bandit"] = { -- Бандиты на АТП

{ section = "logic@atp_fabrika_bandit_walker1",

idle = 0, prior = 10, state = {0}, in_rest = "", out_rest = "" },

{ section = "logic@atp_fabrika_bandit_walker2",

idle = 0, prior = 10, state = {0}, in_rest = "", out_rest = "" },

...

 

local t_states = {

["esc_blokpost"] = esc_blokpost,

["esc_lager"] = esc_lager,

["esc_bridge"] = esc_bridge,

["esc_fabrika_bandit"] = esc_fabrika_bandit,

["esc_dogs_to_fox"] = esc_dogs_to_fox,

["esc_specnaz"] = esc_specnaz,

["esc_boars_dogs"] = esc_boars_dogs,

["esc_killers"] = esc_killers,

["esc_dogs_swarm"] = esc_dogs_swarm,

["esc_stalker_camp"] = esc_stalker_camp,

["esc_corps"] = esc_corps,

["esc_assault"] = esc_assault }

 

function load_states( gname, type ) -- стэйта нет - значит, всегда 0

return t_states[type]

end

 

function checkStalker( npc_community, gulag_type, npc_rank, obj )

local c = g_comms[gulag_type]

if c then return c == npc_community end

return ( obj["profile_name"] and obj:profile_name() == g_names[gulag_type] ) or false

end

 

function checkMonster( npc_community, gulag_type )

local c = g_comms[gulag_type]

if c then return c == npc_community end

if gulag_type == "esc_boars_dogs" then

return npc_community == "dog" or npc_community == "boar"

end

return false

end

 

Ну вот как-то так, да. Это "дополнительный", альтернативный формат записи. Но все еще один смарт - один гулаг. С несколькими - в 2 раза сокращается количество строк, и сами строки упрощаются (от них в основном только секции логики и нужны)

 

 

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

Изменено пользователем Dennis_Chikin
Ссылка на комментарий
  Карлан писал(а):
сейчас-то что мешает стейты внутрь логики засунуть (пусть даже по вашему человекопонятному)? кондлист доступен абсолютно для всего, для чего не доступен - сделать доступным. профит, не?

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

 

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

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

  Описание работ в gulag_***.script (Показать)
Изменено пользователем Полтергейст
Ссылка на комментарий

prior = 5 - это нужно, когда есть работы, на которых должен быть кто-то конкретный, или когда нужно, чтобы из всех возможных заняты были именно эти.

 

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

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

 

Избавились.

 

сквады - имеет смысл менять динамически, раз пошла такая пьянка.

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

 

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

 

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

 

 

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

Ссылка на комментарий

 

 

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

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

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

 

 

 

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

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

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

 

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

 

 

 

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

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

 

 

 

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

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

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

Ссылка на комментарий

Ох, похоже тут опять мифы обсуждают. job_position_threshold - это расстояние, при котором считается, что моб в оффлайне пришел к месту работы и ему можно назначать логику. Если это расстояние сделать слишком маленьким, то логика мобу не будет назначена. В качестве примеру приведу Барьер на Складах и значение 120 из ОП-2 (из Солянки, полагаю, тоже). К этому нужно заметить, и это, похоже, все то-ли не знают, то-ли упускают из вида. Мобы в оффлайне про логику и пути понятия не имеют. Это все только в онлайне работает. А в оффлайне моб всегда идет на точку смарт террейна. Его туда движок гонит. Вот для этого и используется упомянутое выше расстояние. Что бы xr_gulag мог определить, что моб дошел. Так вот, про Барьер и ОП-2 (вероятно и про Солянку). Идя на Барьер мобы прекращают свое движение на расстоянии большем, чем 120 метров от смарта. Это приводит к тому, что соотв. логика мобам не назначается и когда игрок подходит к свободовцам, что там стоят, все мутанты вываливаются в онлайн на этом месте. На самом же деле, мутанты должны быть около перехода на Радар и атаковать свободовцев оттуда, а не сваливаться им на голову.

 

Далее, can_choose_alife_task() не запрещает мобу идти к месту работы. Оно вообще к работам и логике прямого отношения не имеет. Эта функция управляет тем, будет-ли движок пытаться определить данного моба в какой-нибудь смарт террейн или нет. Если разрешено, то движок пойдет в цикле по всем смартам и каждый будет спрашивать: этого возьмешь? На самом деле не так прямо, но в данном случае это не важно. И вот когда движок закрепит моба за каким-то смартом, моб пойдет на точку этого смарта. И только дойдя до туда и выйдя в онлайн, ему xr_logic назначит онлайновую работу. Как только моб уйдет в оффлайн, движок опять погонит его на точку смарта и т.д.

Ссылка на комментарий

Этот "миф" дан вполне в ощущениях.

 

Вот так оно блин там сделано: да, когда дошел - считается заступившим, назначается логика и т.д.

 

А вот пока НЕ дошел - регулярно вызывается self:free_obj_and_reinit(), и вот только тогда моб каким-то загадочным образом может сдвинуться с места.

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

 

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

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

Изменено пользователем Dennis_Chikin
Ссылка на комментарий

Продолжаем разговор про xr_logic:

 

  Показать

 

Сорри за неряшливый вид. Однако: sw1: 2691772.75 sw2: 7585235

 

Есть в этом нечто удивительное, правда ?

И, кстати, оно таки ЖРЕТ. Реально жрет. Пара десятков рестрикторов и десяток неписей - очень даже ой.

И, кстати, здесь можно этот самый аппетит еще поурезать вполне.

Изменено пользователем Dennis_Chikin
Ссылка на комментарий

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

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

Я про съемку координат речь веду, если что. В моей подписи как раз есть ссылка на тему где можно посмотреть видео про "Пушку мододела" - инструмент для снятия координат в игре. Координат для чего? Ну в данном варианте для путей работ в гулагах, а вообще-то для чего угодно.

Как оно работает: на стороне игры через всякие там интерфейсы задаем настройки, что мы хотим поставить, потом отлавливается выстрел, и в момент выстрела берутся координаты актора и с этими всеми настройками записываются эдаким пакетом информации в лог. И собственно все, на стороне игры работа инструмента закончилась.

Потом на стороне Windows, рядом с логами игры лежит одна программа которую я сам для себя написал. Она открывает файл логов, находит там все эти пакеты данных с координатами, оставленные скриптом, обрабатывает и создает "текст" который можно уже вставлять в файлы распакованного аллспавна и компилировать в игру с помощью acdc.

т.е. на стороне windows все что я делаю - открываю свою программу, тыкаю в ней кнопку, открываю созданный ею файл, нажимаю Ctrl+C, открываю файл распакованного спавна - Ctrl+V. запускаю батник компиляции спавна. все.

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

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

Кому надо и интересно - можно взять и заточить под свои нужды.

 

  код Pascal (Показать)
  • Нравится 2

Мод, где не бывает одинаковых путей - Судьба Зоны. (Лучшее, что у меня получилось на X-Ray) На базе модифицированного движка OGSR Engine.

Бывший мододел на X-Ray / Начинающий игродел на Unreal Engine. Программист.

AMD Ryzen 9 7950X (16 ядер, 32 потока, 5.75 ГГц); RTX 3080; 128 ГБ DDR5; Arctic Liquid Freezer II-420; 3 ТБ SSD PCIe 4.0; 4ТБ HDD.

Ссылка на комментарий

@Zander_driver, гайд по выкладыванию чего-либо :)

Ведь не сложно же было выложить еще и dpr и dfm, чтобы дельфевый проект можно было собрать без приседаний.

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

 

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

  • Нравится 1
  • Согласен 1
Ссылка на комментарий

 

 

  abramcumner писал(а):
дельфевый проект

Я же говорил что там минимум :)

  dpr (Показать)
  • Нравится 1

Мод, где не бывает одинаковых путей - Судьба Зоны. (Лучшее, что у меня получилось на X-Ray) На базе модифицированного движка OGSR Engine.

Бывший мододел на X-Ray / Начинающий игродел на Unreal Engine. Программист.

AMD Ryzen 9 7950X (16 ядер, 32 потока, 5.75 ГГц); RTX 3080; 128 ГБ DDR5; Arctic Liquid Freezer II-420; 3 ТБ SSD PCIe 4.0; 4ТБ HDD.

Ссылка на комментарий

:offtopic:Zander_driver,

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

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

Такую полезную штуку все же лучше в "Сборочный цех".

Изменено пользователем aromatizer
  • Нравится 1

Отношения между людьми- главная ценность в человеческом обществе.
Любая полученная информация- это только повод для размышлений, а не побуждение к действию.
Это должен знать каждый: уроки боевой подготовки Дяди Саши https://yadi.sk/d/60Ec2B06goLAE
Накопано и накнопано:https://yadi.sk/d/mzVY5jQEspwpt

Ссылка на комментарий

 

 

  aromatizer писал(а):
очень нужная и полезная работа.

Я тоже так считаю.

 

 

 

  aromatizer писал(а):
... "ракета" все переварит. Однако, у подавляющего большинства людей компьютер далеко не "ракета" ...

Ну я видел несколько жалоб от людей с очень хорошими и дорогими компьютерами на фризы/лаги именно в этих же ситуациях в различных модификациях. Так что предпологаю, что и "ракета" - не поможет. А вот Zander_driver - очень помог этой своей работой.

 

 

 

  aromatizer писал(а):
Такую полезную штуку все же лучше в "Сборочный цех".

И я тоже так считаю, а то тут в Прозекторской на неё не многие наткнуться, как мне кажется.

Перенести свои изменения в оптимизированный файл - совсем не трудно, а польза то - большая. Хорошо бы, чтоб все модмейкеры использовали эту наработку; особенно, если в их моде есть толпы похожих/идентичных нпс, находящихся рядом в одном гулаге и т.п..

  • Нравится 1
Ссылка на комментарий

А я все же думаю пока оставить это дело тут. В "Сборочном цехе" есть свои правила, которые я сам же писал, и нарушать их не намерен. А эта работа в те правила не вписывается.

  • Полезно 1

Мод, где не бывает одинаковых путей - Судьба Зоны. (Лучшее, что у меня получилось на X-Ray) На базе модифицированного движка OGSR Engine.

Бывший мододел на X-Ray / Начинающий игродел на Unreal Engine. Программист.

AMD Ryzen 9 7950X (16 ядер, 32 потока, 5.75 ГГц); RTX 3080; 128 ГБ DDR5; Arctic Liquid Freezer II-420; 3 ТБ SSD PCIe 4.0; 4ТБ HDD.

Ссылка на комментарий

Тогда, пожалуйста, добавь эту революционную наработку себе в подпись. Я уже адаптировал ее к ТТ2: полет нормальный.

Изменено пользователем aromatizer
  • Спасибо 1
  • Нравится 1

Отношения между людьми- главная ценность в человеческом обществе.
Любая полученная информация- это только повод для размышлений, а не побуждение к действию.
Это должен знать каждый: уроки боевой подготовки Дяди Саши https://yadi.sk/d/60Ec2B06goLAE
Накопано и накнопано:https://yadi.sk/d/mzVY5jQEspwpt

Ссылка на комментарий

Вы мне так подпись взорвете :( она же не резиновая.

Мод, где не бывает одинаковых путей - Судьба Зоны. (Лучшее, что у меня получилось на X-Ray) На базе модифицированного движка OGSR Engine.

Бывший мододел на X-Ray / Начинающий игродел на Unreal Engine. Программист.

AMD Ryzen 9 7950X (16 ядер, 32 потока, 5.75 ГГц); RTX 3080; 128 ГБ DDR5; Arctic Liquid Freezer II-420; 3 ТБ SSD PCIe 4.0; 4ТБ HDD.

Ссылка на комментарий

Создайте аккаунт или авторизуйтесь, чтобы оставить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

Создать аккаунт

Зарегистрировать новый аккаунт в нашем сообществе. Это несложно!

Зарегистрировать новый аккаунт

Войти

Есть аккаунт? Войти.

Войти
  • Недавно просматривали   0 пользователей

    • Ни один зарегистрированный пользователь не просматривает эту страницу.
×
×
  • Создать...