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

[Dennis_Chikin 3 658]

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

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

Изменено 30 Января 2015 пользователем Dennis_Chikin

[Zander_driver 10 166]

 

 

Ни в каком не в подполье

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

 

 

ничего там интересного нет.

Категорически не согласен. Да и вообще Денис интересно рассказывает, я бы почитал с удовольствием дальше, даже если бы это было "бояном". Но для меня повторюсь, это новое. По всяким подпольям и потайным углам я не любитель лазить.

[Карлан 1 049]

Хорошим тоном было бы объяснить чем она интересна. Это абсолютно типовая схема, смотри sr_no_weapon, sr_cutscene и т.п. В ней нет ничего хитрого и заумного, она такая, какая есть (в отличие от sr_tip, например). Вывод по этой схеме один, и что в ней можно обсуждать я не понимаю. Плацдарм для работ абсолютно очевиден, но работы здесь граничат чуть ли не с полной переделкой, а эта полная переделка кроме ЧСВ все равно ничего не даст.
 
По поводу оптимизаций, годичный коммент:

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

И так, к слову, отцепление от апдейта с sr_idle@nil - мертвому припарка. И опять же, к слову, коммент - не руководство к действию, он хороший, но совершенно не применимый к реалиям, в реалиях идти нужно от частного.

 

В любом случае как хотите, возможно я один чего-то не понимаю. Как начнете sr_tip разбирать, позовите.

[Dennis_Chikin 3 658]

Ну, во-первых, про апдейт рестрикторов вообще я писал, и измененные файлы выкладывал, просто в более другой теме, ибо могу говорить за АМК и "солянкоклоны", но не за все моды.

И, знаете, вынести несколько ДЕСЯТКОВ рестрикторов (от 30 до 80 в зависимости от локации и фанатизма мододела) из лютого, бешеного апдейта во всю мощь процессора  - на сколько способен - все в туда и ухнет - смысл вполне имеет. http://www.amk-team.ru/forum/topic/8830-narodnaia-2010-razrabotka/?p=1021981

Как говорится, включите лог, и проникнитесь.

 

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

 

И, да, сорри, за то, что начав разговор, пропал в самом интересном месте, но обещаю исправиться.

 

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

[Dennis_Chikin 3 658]

Что-то у меня на счет "ниумерла" как-то двойственно выходит, так что вот вам сразу файлик, а по мере сил начну разбор. https://dl.dropboxusercontent.com/u/27871782/sr_psy_antenna.script

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

 

Соглашения обычные: актор живет в _G, там же происходят все манипуляции со временем, и туда же кладутся результаты, в частности в game_time_ms - время от старта игры. В апдейт по времени что-либо добавляется через bind_stalker.task_add(), логи выводит каждый кому как нравится.

Обращения к внешним функциям на 100500 символов длиной заменены на короткие.

 

С другой стороны, все имена переменных и вызовы, доступные извне, сохранены на случай, что мало ли у кого что к чему привязано. Это пусть любители "защит от читеров" все перименовывают в 100 других скриптах, и все true на false везде меняют. Авось им и получится в очередной раз оттянуть выход какого мода из "подполья" еще на пару-тройку лет.

 

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

 

 

local dbst = db.storage
...
 
local state_outside = 0    -- актер снаружи
local state_inside = 1    -- актер внутри
local state_void = 2    -- неизвестный статус

class "action_psy_antenna"

function action_psy_antenna:__init( sr, st )
    self.object = sr
    self.st     = st
    self.name = sr:name()
    log( "info", "(%s)action_psy_antenna:__init...", self.name )
    local pstor = dbst[sr:id()].pstor
    self.pstor = pstor
    if loaded and pstor.inside then
        self.state = state_inside
        log( "info", "in zone" )
    else self.state  = state_void    -- еще не ясно, в зоне он, или нет
    end
end

 

 

Получили ссылку на объект рестриктора и ссылку на сторэйж схемы, и у себя их сохранили.

А вот дальше сразу, внимание, начинаются изменения. У рестриктора, как, в принципе, и любого другого "честного" объекта, есть pstor. Это такая табличка, которая сохраняется при сохранении игры, и загружается при загрузке, как ни странно. Хотя у тех объектов, которые могут перeключаться on/offline, это скорее не работает, чем работает, остаются как раз актор, то, что у него в инвентаре, и - рестрикторы.

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

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

 

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

Так что когда после создания схемы у нее вызывается

function action_psy_antenna:reset_scheme()
    if self.state == state_inside then self:zone_leave() end
end

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

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

 

Ну и, наконец, апдейт:

 

function action_psy_antenna:switch_state()
    if self.state ~= state_inside then
        if self.object:inside( actor:position() ) then
            log( "info", "(%s):switch_state, enter", self.name )
            self:zone_enter()
            return
        end
    elseif not self.object:inside( actor:position() ) then
        log( "info", "(%s):switch_state, leave", self.name )
        self:zone_leave()
    end
end

function action_psy_antenna:update()
    if try_switch( self.object, self.st, actor ) then return end
    self:switch_state()
end

 

 

xr_logic.xr_logic.try_switch_to_another_section() здесь, как и везде, проверяет: не настало ли время переключиться на что-нибудь более другое, и если да, что что-либо делать здесь более не имеет смысла. switch_state спрашивает у рестриктора посредством self.object:inside( actor:position() ) - внутри ли актор, и в зависимости от результата посредством zone_enter() или zone_leave() во-первых, передает странному и загадочному class "PsyAntenna", который, ВНИМАНИЕ, создается только ОДИН раз и сохраняется в sr_psy_antenna.psy_antenna тоже только ОДИН раз. То есть, рестрикторов много, мест, где создаются схемы - много, и существовать они могут одновременно, а вот этот - ОДИН.

 

Из оставшихся тонких мест - манипуляции с постэффектами.

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

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

    local pname = st.postprocess
    local p = psy_antenna.postprocess[pname]
    if p then
        p.intensity_base = p.intensity_base + st.intensity
        return
    end

а вот если нет, тогда добавляем psy_antenna.postprocess[pname] = {табличка с его свойствами}, включаем сам эффект, и устанавливаем на некий минимум.

 

При выходе же возвращаем взад все наши "интенсивности", но не трогаем действующие постэффекты.

 

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

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

 

окончание следует.
 

Изменено 19 Января 2017 пользователем Dennis_Chikin

[Карлан 1 049]

Хотя у тех объектов, которые могут перeключаться on/offline, это скорее не работает, чем работает, остаются как раз актор, то, что у него в инвентаре, и - рестрикторы.

 

http://www.amk-team.ru/forum/topic/13387-prosectors-project/?p=1043209

 

 

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

 

Я предположу, что смысл здесь только в слове reset, то есть там и делается полный ресет схемы.

 

 

class "PsyAntenna", который, ВНИМАНИЕ, создается только ОДИН раз и сохраняется в sr_psy_antenna.psy_antenna тоже только ОДИН раз. То есть, рестрикторов много, мест, где создаются схемы - много, и существовать они могут одновременно, а вот этот - ОДИН.

 

Так и должно быть. Например, sr_aes_deadzone, из-за этого дедзону можно использовать только глобально, локально она заглючит, как только уйдет в оффлайн. Объясняю. Эффект у нас один, и управляет им один класс, который не должен быть связан с рестрикторами, отсюда следует, что все сделано совершенно верно, если мы заходим в зону, нас начинает долбить, выходим - постепенно(!) все пропадает. Заходим в две зоны сразу - долбят обе зоны сразу. Т.е. один эффект на все зоны, читай совокупный эффект. Тут же как с медикаментами, мне кажется странной будет ситуация, если дать человеку съесть разом блистер фенозипама, и ожидать эффекта лишь от одной таблетки.

 

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

[Dennis_Chikin 3 658]

Так, по антенну я что-то опять забыл (а что - у меня-то все работает, сэйвы не бьются, если, скажем, на янтаре н территории завода до получения шлема сохраниться/загрузиться, или на радаре непосредственно на антеннах, вечная желтизна при каждом s/l там же не настает...) Виноват, исправлюсь. А сейчас хочу поделиться более другим:

 

xr_combat_ignore, в некоторых модах, не будем показывать пальцем, выглядит как-то так:

function set_combat_ignore_checker( npc, ini, scheme, section )
	local st = xr_logic.assign_storage_and_bind( npc, ini, scheme, section )
	st.enabled = true
--	npc:set_enemy_callback( blowout_scheme.enemy_callback, nil )
	-- Подписываемся на hit callback-и:
	xr_logic.subscribe_action_for_events( npc, st, st.action )
end

А потом мы удивляемся, что оно не работает.

В то время как в оригинале имеет место быть совершенно логичный npc:set_enemy_callback( st.action.enemy_callback, st.action )

 

Гуманности ли ради ? ©

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

[Bak 753]

@Dennis_Chikin, В соли этот колбек устанавливается в blowout_scheme.script, там своя обертка над стандартной функцией. Что не так то?

[Dennis_Chikin 3 658]

То, что скорее не работает, чем работает.

[dsh 3 820]

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

[Dennis_Chikin 3 658]

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

[myjob_combat_ignore]

dist = 50

...

[mysect]

combat_ignore_cond = 100

 

Ну или {+то_что_есть_всегда} - без разницы.

[Dennis_Chikin 3 658]

Хочется ругаться матом...

 

В общем, оный blowout_scheme.script скорее работает, чем не работает, но, при этом, воистину, в слове из трех букв - 5 ошибок, а что остальные криворукие граждане вокруг навертели, на форуме про это пункт 2.0 правил рассказывает.

 

В общем, ни проверке условий вступления в бой, ни "обходу аномалий" там не место. Я, конечно, понимаю, что ООП и все такое, но результат: либо reset() либо прерывание execute() с возвратом на исходную позицию и попыткой повтора сначала практически во всем, что на это понавесили.

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

 

Теперь, что касается непосредственно "обхода аномалий":

метод с добавлением restrictions прекрасно работает, и реализуется точно так же, как и у монстров.

Неписи же, которые либо упорно лезут в аномалии, что ты с ними не делай (ну или при попытке сделать в итоге виснут) - все 146% являются задумкой авторов, и, у простого смертного, не владеющего исходниками олспавна, метод борьбы с этим, по сути, остается только один:

1. При НИ удалить таких неписей из игры вместе с логикой, прописанной _{{здесь было, как мне указали, нечто такое, завуалированное, так что пришлось выпилить. Честное слово, ни одна из известных математических констант не использовалась.}} автором.

2. Создать свой смарт (на самом деле скриптовое создание смартов - не так уж сложно) или использовать готовый,  посадить непися под него. Точки работ и расстояние "достижения работы" должно быть в зоне, полностью свободной от аномалий. Между этими свободными областями непись нормально передвигается под движком, с учетом прописанных restrictions.

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

[dsh 3 820]

 

 

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

 

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

[lsclon 527]

 

являются задумкой авторов

Прежде чем проклинать этих самых авторов, включая ПЫС, к коим они и относятся в единственном лице, нужно хотя бы немного понимать суть проблемы. А проблема в том, что  ПЫС ставили некоторым нпс, в том числе и Круглову, флаг - не видеть аномалии. И да, это флаг можно исправить только в аллспавне. А вторая причина, проявляется только у гулажных нпс, в работах которых прописаны запрещающие рестрикторы. Остальные нпс, прекрасно обходят аномалии.

Так что, авторы модов, здесь совсем ни при чём.

[Dennis_Chikin 3 658]

Не, с дерганием неписей все смешнее.

if self.prev_pos:distance_to(npc:position())>15 then
-- здесь был бред с высчитыванием какого-то "среднего вектора"
    self.prev_pos=npc:position()
    local list=amk_anoms.get_anomaly_list(npc,20)
    for i,o in ipairs(list) do
            amk_anoms.add_restriction(npc,o.id,o.name)
    end

Непись перечитывает аномалии, сдвинувшись на 15 метров. В принципе, все замечательно.

Поскольку влетают они в аномалии именно на длинных дистанциях (короткие неинтересны, поскольку просто область в исключения, и ага).

Но, 100500 скриптов, которые постоянно за него дергают, получают отлуп по УДАЛЕНИЮ аномалии из списка, делают себе резет, и гонят непися обратно на исходную точку, а потом оттуда же (поскольку аномалии "уже нет") опять пытаются повторить то, что было.

 

Ну, дальше там в action_anomaly:initialize() и action_anomaly:execute() - просто какой-то хронический антисемитизм, где непись переводится в состояние полной непонятки, куды бечь и зачем, но это уже в общем не важно.

 

А вот ПРУТ В АНОМАЛИИ неписи по тому, что их туда послали просто установив вертекс или позицию. Схемкой из логики. (Ну или еще каким лутосбором, которому на "исчезновение" аномалий из списка, естественно, наплевать).

 

Короче, просто СМЫСЛ всех совокупностей действа напрочь отсутсвует абсолютно во всех случаях. Код, который в результате кучи лютобешеных вычислений полностью обнуляет результаты таких же лютобешеных вычислений другого куска кода.

в том числе и Круглову, флаг - не видеть аномалии.

В том числе и это - ТОЖЕ.
См. п1 в исходном сообщении: удалить непися нафиг, и заспавнить на его место нормального.

---

И, да, в результате от того, что в скрипте сейчас, там можно оставить ровно тот же кусок, что и у монстров, и возвращать всегда false.
А в идеале - посносить все обращения к evaluator_outside:evaluate() отовсюду, а сам кусок перенести в мотиватор.

Ну, то есть, чтобы СОВСЕМ как у монстров.

Впрочем, это я просто повторяю-разжевываю то, что уже сказано.

[dsh 3 820]

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

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

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

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

[Dennis_Chikin 3 658]

Есть возможность редактировать олспавн - ставь ВСЕ как у обычного нормального непися.

Там ОСМЫСЛЕННЫХ - нет. Ну вот разве что нужно именно непися об аномалию убить, и то, проще, опять же, через npc:kill( anom ), подведя по-ближе.

 

P.S. А подробности по флагам - они только среди ИЗБРАННЫХ распространяются. Заведено еще со времен, когда вообще ни какого инструментария не было, но у Кого Надо - у тех все было.

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

[lsclon 527]

 

 

какой именно флаг за это отвечает?

Если у нпс в аллспавне стоит такой флаг

object_flags = 0xfffffff7

то аномалии он видеть не будет.

[dsh 3 820]

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

 

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

 

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

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

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

[Dennis_Chikin 3 658]

Начатое надо когда-нибудь уже закончить, так что - sr_psy_antenna !

Странная и загадочная часть, которая

class "PsyAntenna"

 

function PsyAntenna:__init() и т.д., которую надо зачем-то сохранять, загружать, и с которой вот так и чешеться сделать загрузку и сохранение в каждом апдейте каждого из 10000 рестрикторов на каждой локации, "чтобы разгрузить актора".

 

Суть научной необъясненности здесь состоит в том, что этот кусок отвечает за состояние актора. Точнее, за эффекты у него на экране и в колонках, ну и немножко оного игрока убивает иногда.

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

То есть, один актор, одна функция, несколько статических переменных.

 

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

Но все-же ?

 

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

Прежде все, зачем это надо вообще: а надо это для того, что у нас сделано ПЛАВНОЕ нарастание и снижение эффектов. Если бы не они, достаточно было бы просто добавить эффект, если актор в зоне, и убрать, если нет.

Но для плавности в этот наш странный объект каждой схемой ДОБАВЛЯЕТСЯ ЦЕЛЕВОЕ значение требуемого эффекта:

function action_psy_antenna:zone_enter()
...
	psy_antenna.sound_intensity_base = psy_antenna.sound_intensity_base + st.intensity
и т.д.
...
	local p = psy_antenna.postprocess[pname]
	if p then
		p.intensity_base = p.intensity_base + st.intensity
		return
	end

и так же убирается, а вот реальное значение вычисляется уже в апдейте АКТОРА:

	local dt = global_time_ms - self.last_upd
	self.last_upd = global_time_ms
	self.eff_time = self.eff_time + dt


	function update_intensity( intensity_base, intensity )
		local di = self.intensity_inertion * dt * 0.001
		local ii = intensity_base
		if math_abs( intensity_base - intensity ) >= di then
			if intensity_base < intensity then ii = intensity - di
			else ii = intensity + di
			end
		end

		if ii < 0 then return 0
		elseif ii >= 1 then return 1
		end
		return ii

	end
...
	local t, n = {}, 0
	for k, v in pairs( self.postprocess ) do
		v.intensity = update_intensity( v.intensity_base, v.intensity )
		if self:update_postprocess( v ) then
		else n = n + 1; t[n] = k
		end
	end

 

ну и тут же фантомы и хит, но это не интересно.

И только когда эффект ушел в 0 - он убирается из таблицы. А при входе в зону - добавляется из схемы зоны. Ну или при загрузке.

 

Собственно, ЭТО, и ТОЛЬКО это и нужно сохранять/загружать. Понятно, что к всем 10000 рестрикторам на локации процесс ни какого отношения не имеет ни на стадии загрузки, ни во время их апдейтов.

Все принадлежит актору, и только актору.

 

Что у нас остается интересного во внешних функциях load() и add_to_binder(), кроме того, что это обертки для абсолютно не нужного в рассматриваемом случае ООП ?

А ровно то, что это - обертки:

 

function load( p )
	if p:r_bool() then
		if psy_antenna then abort( "sr_psy_antenna.psy_antenna already exists" ) end
		loaded = true
		psy_antenna = PsyAntenna()
		psy_antenna:construct()
		psy_antenna:load( p )
		bind_stalker.task_add( "sr_psy_antenna.update", 200, update )
		log( "info", "load, ok" )
	end
end


function update()
	if psy_antenna then psy_antenna:update() end
end


function add_to_binder( sr, ini, scheme, sect, st )	-- вызывается через xr_logic.assign_storage...
	if not psy_antenna then
		psy_antenna = PsyAntenna()
		psy_antenna:construct()
		bind_stalker.task_add( "sr_psy_antenna.update", 200, update )
	end
	local a = action_psy_antenna( sr, st )
	subscribe_action( sr, st, a )

	log( "info", "add_to_binder, ok: %s, %s", sect, sr:name() )
end

 

 

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

1. Эффекты были активны, когда мы сохранялись. Следовательно, мы должны их иметь на экране до того, как схемой там чего-нибудь родится. Или не родится. Поэтому

function load( p )
	if p:r_bool() then
		if psy_antenna then abort( "sr_psy_antenna.psy_antenna already exists" ) end
		loaded = true
		psy_antenna = PsyAntenna()
		psy_antenna:construct()
		psy_antenna:load( p )
		bind_stalker.task_add( "sr_psy_antenna.update", 200, update )

При загрузке актора, если данные были - их надо загрузить, ну и эффекты включить.

Но вот если это УЖЕ сделано, или выглядит сделанным - что-то пошло не так, и далее все бессмысленно.

Последняя строка здесь, которой нет в оригинале - это я описывал в отдельной серии постов подключение тех апдейтов, которые ПОСТОЯННО - не нужны, и с "антеннами" у нас именно этот случай.

 

add_to_binder() - это включение эффектов и их апдейтов при активации схемы, отслеживающей нахождение актора внутри зоны, из рестриктора, если данные НЕ БЫЛИ загружены. Разумеется, если были - этого делать НЕ НАДО.

 

 

В общем и целом, мы имеем код, посвященный борьбе скубента с трудностями, которые ему создал препод при задании темы курсача, а также историю про то, как сообщество продолжало оную борьбу, бессмысленную и беспощадную, десятки лет после того, как скубент благополучно получил вожделенный диплом. По тому что Здесь Так Принято, и по тому что Древние Так Делали и мы тоже Обязаны.

 

Разумеется, возможно и творческое развитие в заданном направлении, да. Ибо мод, комфортно работающий на первопне - это не круто, так что даешь еще больше рестрикторов и еще больше апдейтов с еще более лютобешеными вычислениями внутри. ТакЪ ПобедимЪ !!!

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

[Карлан 1 049]

Продолжая тему загадок припяти. У меня у одного механизм включения/выключения ненужного pri_monolith_snipers_free мистически выглядит?