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

[dsh 3 820]

 

 

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

 

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

[dsh 3 820]

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

 

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

[dsh 3 820]

@Zander_driver, мне кажется, полезно будет сделать

snd_ini = system_ini()

вместо

snd_ini = ini_file("misc\\script_sound.ltx")

В самом script_sound.ltx добавить определенный префикс ко всем секциям. Я использую "script_sound.". Конечно не забыть этот ltx за-include-ить в системные конфиги. А в самом скрипте добавить этот префикс везде, где используются имена секций. Какой смысла загружать script_sound.ltx при загрузке каждого сейва, если это можно сделать один раз, при первом запуске игры.

 

Это, на мой взгляд, полезно сделать вообще для всех таких конфигов, типа death_generic, treasure_manager и т.п.

Изменено 1 Мая 2016 пользователем dsh

[dsh 3 820]

Две минуты. 40 секунд. Во первых, это же зависит от кол-ва загружаемого, да? А во вторых, насколько я вижу, основное время тратиться в npc:add_sound() и что-то я не вижу никакого способа это ускорить. Ведь ему нельзя передать уже загруженный звук. Да и не имеет это смысла. Насколько я вижу в исходниках, он сам звуки кэширует и не загружает с диска уже загруженный звук. Что касается скрипта, так у меня, к примеру, он не дал никакого ускорения. Как было около 14 секунд на звуки при холодном старте, и примерно 4 при повторной загрузке сейва (в Баре), так и осталось. Мне собственно не понятно даже, а как там что-то может ускоряться. Насколько я вижу, по сути, скрипт кэширует результаты check_prefix() и чтение ltx-а. Ни первое, ни второе кэшировать нет смысла. Первое - это string.sub() и второе такое же движковое. Миллисекунды максимум. Совершенно не в обиду сказано. Может я чего не заметил? Тогда ткните меня носом, где именно там ускорение должно происходить?

[dsh 3 820]

 

 

Именно так. По-этому, перекладываем одинаковые звуки по соответствующему пути, и прописываем им тип 2 или 3. В результате - одинаковые звуки читаются один раз.

 

Ну вот, собственно. Самая лучшая оптимизация - это разгребание этих самых звуков, как ты и писал про конюшни.

[dsh 3 820]

 

 

Наверное тестов моих не заметил. Там цифры какие-то есть, и они почему-то разные.

 

Не, ну я не знаю, что там у тебя раньше было-то. Может предыдущий скрипт, ltx в цикле каждый раз заново читал или еще что-нибудь подобное. Я вижу только то, что есть сейчас, а в нем ничего ускорительного не нахожу. Вот и пишу, может у меня взгляд замылился и я чего-то в упор не замечаю. Ты словами и конкретными строками поясни, в чем именно ускорение? И это я не просто что-бы поспорить, а что бы понять.

 

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

[dsh 3 820]

@Dennis_Chikin, да работает оно там. Не по человечески, но работает. Не работает у тех, кто в логике пишет combat_ignore_cond, не указав combat_ignore в [logic], что в Солянке сплошь и рядом. Ах да, еще же там в кондишне используют странные функции, которые сравнивают неизвестно что, с неизвестно чем. Ну так кривые руки не правятся. Изменено 1 Февраля 2017 пользователем dsh

[dsh 3 820]

 

 

Неписи же, которые либо упорно лезут в аномалии

 

Вот на этот счет, у меня есть одно подозрение. Сразу после выброса создаются новые аномалии и blowout_scheme отпускает неписей. В этот момент они начинают работать под предыдущей схемой, которая их куда-нибудь пошлет, к костру например. Но ограничения по новым аномалиям в них еще, скорее всего, не загружены. Или загружены, но не во всех. Дальше мои предположения. Движок их посылает на какой-то вертекс, который он считает свободным, т.к. ограничений по аномалиям еще не установлено. И тут обновляется обход аномалий и загружает ограничения. Но эта информация уже не используется, т.к. непися уже послали в аномалию. У себя я добавил условие, что бы blowout_scheme отпускал неписей через freq * 3 секунды (в моем случае, через 3), после окончания выброса. За это время во всех будут уже загружены новые ограничения.

[dsh 3 820]

флаг - не видеть аномалии

Расскажи пожалуйста, какой именно флаг за это отвечает?

что их туда послали просто установив вертекс

Не, ну против лома же нет приема. Нужно же npc:accessible() проверять, что бы прямо в аномалию не посылать. Я же описывал ситуацию, когда аномалия где-то на пути непися, а не когда его прямо в аномалию посылают.

[dsh 3 820]

@lsclon, это, похоже, сброшенный flInteractive

 

Есть возможность редактировать олспавн

 

Ну зачем сразу all.spawn. Можно и в нетпакете же поправить. А совет да, правильный. Нефиг так выеживаться. А то понаделают всяких, кому запрещено в оффлайн переходить, к примеру. Руки бы оторвал.

Ох екарный бабай, да таких полный all.spawn в ОП-2, со сброшенным flInteractive. И главное, не понятно, а нафига. Что бы они имели возможность убиться в аномалии что-ли?

Изменено 6 Февраля 2017 пользователем dsh

[dsh 3 820]

Избавление от лютого и бешеного поиска по карманам особого смысла не имеет. Я вчера замерял - это примерно 20 микросекунд на одного сталкера. Не стоит эта овчинка выделки. Если только из любви к искусству. И кстати, то, что ты вот тут понаписал, тоже особого смысла не имеет. Рассадить сталкеров вокруг костра - это не рокет сайнс. Все там нормально рассаживается и все там нормально сидят, если голову приложить.

[dsh 3 820]

@Romann, я же не зря написал про голову. Приложить голову - это означает переделать xr_kamp. Но для нормальной рассадки пути не обязательны. Собственно говоря, пути - это всего-лишь еще один способ расчета вертексов, куда посадить сталкеров. Можно для каждого костра сделать конфиг и там, через запятую написать вертексы. Это будет тоже самое. А можно просто рассчитать. И это даст такой же результат, но будет гибче. В том, что у тебя, оригинальный расчет, который так себе. Вот тут переделанный расчет: https://github.com/dsh2dsh/op2ogse/blob/master/gamedata/scripts/xr_kamp.script

[dsh 3 820]

@Dennis_Chikin, правильно не веришь. 0.3 от центра - это все тот же вертекс, т.ч. туда ни одного не посадить. Тем более, что в случае костра он накрыт аномалией костра, в которую сталкерам низя. Да и про 0.3 - это ты написал. Я на числах не зациклен и мне нужно, что бы сталкеры сидели около костра равномерно, не слишком близко и не слишком далеко. А будет это от центра 1.5, 2 или 2.5 - не имеет значения.

[dsh 3 820]

@Капрал Хикс, ну вот глянь, что у меня там изменено: https://github.com/dsh2dsh/op2ogse/blob/master/gamedata/config/dsh/l11_pripyat.ltx

По названиям думаю разберешься и cond-ишены поймешь. Сразу другое дело, а не бессмысленно и беспощадно.

[dsh 3 820]

@Капрал Хикс, там просто переопределяются "cond" смартов из all.spawn. Ты можешь сделать это в all.spawn и получится тоже самое. Смысл большинство переопределений в том, что бы в определенные моменты выключать/включать определенные смарты, что бы одновременно на локации находилось меньше народа. Когда они все там - начинается лагодром. А некоторые смарты, большинство wave к примеру, вообще выключаются после первого прохода по локации, т.к. далее они бессмысленны. Ну какой смысл во всей этой толпе, которая бесконечно сидит на крышах и стреляет. Другие смарты с помощью проверок в cond включаются попеременно. Т.е. если на входе у нас имеются сталкеры, значит за углом не будет монолитовцев и наоборот и т.д. Ну и отдельно у меня рейды выключены для этих смартов, когда те же сталкеры в начале локации ломятся вперед, снова и снова. Ну не в петле времени же они живут. Да и нехорошо это. Я иду за ними и подбираю лут. Двойная выгода, и лут наберу на продажу и врагов они всех выкосят. Нехорошо.

Изменено 26 Февраля 2017 пользователем dsh

[dsh 3 820]

@Dennis_Chikin, ты какими-то загадками говоришь или с кем-то другим. У меня тоже есть такая картинка: https://yadi.sk/i/bGpoGx2u3Ehscv

И что в ней такого?