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

[RayTwitty 492]

У себя уже давно использую оригинальный пысовский метод level.add_call() - как раз для таких "быстрых" таймеров. Каждый новый вызов этого метода, по сути и является созданием экземпляра класса и всё действо помещается в одну строку луашного кода. Но при такой компактности, конечно, и наворотов меньше чем у malandrinus'a - например из входных параметров только: имя таймера, время (таймаут), функция, которая будет вызвана по окончанию таймера и аргументы, переданные в эту функцию. То есть это именно таймер, с одним лишь условием - временем. Сохранение между сейвами так же не предусмотрено, но лично для моих нужд, пока этого хватает.

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

[RayTwitty 492]

 

 

Это не ООП, а типичный процедурный подход, поскольку отсутствует инкапсуляция кода и данных.

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

 

 

 

Ответь на простой вопрос, как ты при этом будешь хранить данные, которые надо "донести" от места/момента запуска до места/момента срабатывания?

Передаю внутрь функции, которая будет вызвана после отработки первой функции.

[RayTwitty 492]

 

 

я так понял, что ты сделал некую обёртку для level.add_call(), позволяющую хранить данные до вызова функции?

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

 

 

 

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

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

[RayTwitty 492]

@Карлан, лучше в справочник по функциям и классам запостить, имхо. Хотя, тут не особо много постов, найти при надобности тоже просто. Изменено 31 Июля 2015 пользователем Shadows

[RayTwitty 492]

Возможно я чего-то не понимаю...

 

task_manager.script

function CRandomTask:save(p)
    ...
    p:w_u32(v.selected_target or -1)

беззнаковое целое не может быть -1, поэтому сохраняется 4294967295 (что логично)

 

загрузка:

function CRandomTask:load(p)
    ...
    local selected_target = p:r_u32()
    if selected_target ~= -1 then
        self.task_info[id].selected_target = selected_target

какое нахрен -1???

Причем ниже, они из этого числа хотят получить игровой объект.

if self.task_info[id].type == "defend_lager" then
    local defend_object = alife():object(self.task_info[id].selected_target)

А теперь вопрос - как оно вообще работает? o_O

 

Добавляю вывод в консоль:

if self.task_info[id].type == "defend_lager" then                                                           
    local defend_object = alife():object(self.task_info[id].selected_target)                                  
    local sm_ini = defend_object:spawn_ini()  
 
    log1("defend_object selected_target = "..self.task_info[id].selected_target.." name = "..defend_object:name())
 
    self.task_info[id].defend_target = utils.cfg_get_number(sm_ini, "random_task", "defend_target", nil, true)
end

результат:

defend_object selected_target = 4294967296 name = single_player

И так для каждого задания "defend_lager". WTF. Изменено 2 Августа 2015 пользователем Shadows

[RayTwitty 492]

1) условие if selected_target ~= -1 then не имеет смысла, так как u32 никогда не может быть -1, следовательно self.task_info[id].selected_target всегда равно значению p:r_u32()
2) после чего они пытаются из этого числа получить объект и даже не проверяют есть ли он вообще (!)
3) зачем вообще сохранять для заданий это значение, если оно всегда равно -1 (на save), а следовательно всегда (на load) получается (подразумевается) актор
 

вроде с кодом все нормально.

Там ничего нормального нет - весь код сплошной ахтунг.
 

Если посмотришь на код внимательней, то по -1 объект не получают.

Причем ниже, они из этого числа хотят получить игровой объект.

Я имел ввиду число selected_target, а не -1.

Изменено 2 Августа 2015 пользователем Shadows

[RayTwitty 492]

Как ты понял, что всегда равно -1?

В ходе практических тестов и вывода сохраняемых значений в лог на оригинальной игре.

 

Если null, то вместо null, пишем -1.

А то что -1 пишем в u32 не смущает?

Изменено 2 Августа 2015 пользователем Shadows

[RayTwitty 492]

В с++ -1 прекрасно пишется в u32 и читается обратно.

 

 

Пруф?

Изменено 2 Августа 2015 пользователем Shadows

[RayTwitty 492]

инвентарь Судьбы Зоны

Почти 40 тыс. строк, охренеть

 

У меня весь апгрейд оружия и брони аля ЗП, вроде не больше 500.