Скриптование

Real Wolf · 17 Сентября 2011

Довольно часто при инициализации окна через класс CUIMessageBoxEx() вылетает без внятного лога.

Приведи примеры не "твоих" применений класса, приводящих хотя бы к редким к вылетам. --/ Artos

Кто-нибудь знает причину?

Предлагаешь погадать о природе твоих ошибок применения класса? --/ Artos

P.S. Как вариант я себе сделал скриптовой класс, очень похожий на CUIMessageBoxEx(). Если кому-то надо - в ЛС.

Изменено 17 Сентября 2011 пользователем Artos

PavelSnork · 17 Сентября 2011

Привет всем. Ребят, нужна ваша помощь. У меня в Сталкер ЗП, после добавления нескольких скриптов, не исчезают надписи "игра сохранена", "испольновано аптечка", и т.д..

function check_params()
  --/ health
  local iHealth = db.actor.health
  if iHealth > 0.04 then --/ здоровье не полное?
    local sHealth_Level = nil
    if iHealth < 0.08 then
      sHealth_Level = "health_level_1"
    elseif iHealth > 0.08 and iHealth < 0.12 then
      sHealth_Level = "health_level_2"
    elseif iHealth > 0.12 and iHealth < 0.16 then
      sHealth_Level = "health_level_3"
    elseif iHealth > 0.16 and iHealth < 0.2 then
      sHealth_Level = "health_level_4"
    elseif iHealth > 0.2 and iHealth < 0.24 then
      sHealth_Level = "health_level_5"
    elseif iHealth > 0.24 and iHealth < 0.28 then
      sHealth_Level = "health_level_6"
    elseif iHealth > 0.28 and iHealth < 0.32 then
      sHealth_Level = "health_level_7"
    elseif iHealth > 0.32 and iHealth < 0.36 then
      sHealth_Level = "health_level_8"
    elseif iHealth > 0.36 and iHealth < 0.41 then
      sHealth_Level = "health_level_9"
    elseif iHealth > 0.41 and iHealth < 0.45 then
      sHealth_Level = "health_level_10"
    elseif iHealth > 0.45 and iHealth < 0.49 then
      sHealth_Level = "health_level_11"
    elseif iHealth > 0.49 and iHealth < 0.53 then
      sHealth_Level = "health_level_12"
    elseif iHealth > 0.53 and iHealth < 0.57 then
      sHealth_Level = "health_level_13"
    elseif iHealth > 0.57 and iHealth < 0.61 then
      sHealth_Level = "health_level_14"
    elseif iHealth > 0.61 and iHealth < 0.65 then
      sHealth_Level = "health_level_15"
    elseif iHealth > 0.65 and iHealth < 0.69 then
      sHealth_Level = "health_level_16"
    elseif iHealth > 0.69 and iHealth < 0.73 then
      sHealth_Level = "health_level_17"
    elseif iHealth > 0.73 and iHealth < 0.77 then
      sHealth_Level = "health_level_18"
    elseif iHealth > 0.77 and iHealth < 0.82 then
      sHealth_Level = "health_level_19"
    elseif iHealth > 0.82 and iHealth < 0.86 then
      sHealth_Level = "health_level_20"
    elseif iHealth > 0.86 and iHealth < 0.9 then
      sHealth_Level = "health_level_21"
    elseif iHealth > 0.9 and iHealth < 0.94 then
      sHealth_Level = "health_level_22"
    elseif iHealth > 0.94 and iHealth < 0.97 then
      sHealth_Level = "health_level_23"
    else
      sHealth_Level = "health_level_24"
    end
    --/ убираем прежний кастомстатик
    hud_elements_remove.remove_elements_3()
    --/ показываем новый кастомстатик
    if sHealth_Level then
      local hud = get_hud()
      if not hud:GetCustomStatic(sHealth_Level) then
        hud:AddCustomStatic(sHealth_Level, true)
      end
    end
  end
  --/ power
  local iPower = db.actor.power
  if iPower > 0.04 then --/ сила не полная?
    local sPower_Level = nil
    if iPower < 0.08 then
      sPower_Level = "power_level_1"
    elseif iPower > 0.08 and iPower < 0.12 then
      sPower_Level = "power_level_2"
    elseif iPower > 0.12 and iPower < 0.16 then
      sPower_Level = "power_level_3"
    elseif iPower > 0.16 and iPower < 0.2 then
      sPower_Level = "power_level_4"
    elseif iPower > 0.2 and iPower < 0.24 then
      sPower_Level = "power_level_5"
    elseif iPower > 0.24 and iPower < 0.28 then
      sPower_Level = "power_level_6"
    elseif iPower > 0.28 and iPower < 0.32 then
      sPower_Level = "power_level_7"
    elseif iPower > 0.32 and iPower < 0.36 then
      sPower_Level = "power_level_8"
    elseif iPower > 0.36 and iPower < 0.41 then
      sPower_Level = "power_level_9"
    elseif iPower > 0.41 and iPower < 0.45 then
      sPower_Level = "power_level_10"
    elseif iPower > 0.45 and iPower < 0.49 then
      sPower_Level = "power_level_11"
    elseif iPower > 0.49 and iPower < 0.53 then
      sPower_Level = "power_level_12"
    elseif iPower > 0.53 and iPower < 0.57 then
      sPower_Level = "power_level_13"
    elseif iPower > 0.57 and iPower < 0.61 then
      sPower_Level = "power_level_14"
    elseif iPower > 0.61 and iPower < 0.65 then
      sPower_Level = "power_level_15"
    elseif iPower > 0.65 and iPower < 0.69 then
      sPower_Level = "power_level_16"
    elseif iPower > 0.69 and iPower < 0.73 then
      sPower_Level = "power_level_17"
    elseif iPower > 0.73 and iPower < 0.77 then
      sPower_Level = "power_level_18"
    elseif iPower > 0.77 and iPower < 0.82 then
      sPower_Level = "power_level_19"
    elseif iPower > 0.82 and iPower < 0.86 then
      sPower_Level = "power_level_20"
    elseif iPower > 0.86 and iPower < 0.9 then
      sPower_Level = "power_level_21"
    elseif iPower > 0.9 and iPower < 0.94 then
      sPower_Level = "power_level_22"
    elseif iPower > 0.94 and iPower < 0.97 then
      sPower_Level = "power_level_23"
    else
      sPower_Level = "power_level_24"
    end
    --/  убираем прежний кастомстатик
    hud_elements_remove.remove_elements_4()
    --/ показываем новый кастомстатик
    if sPower_Level then
      local hud = get_hud()
      if not hud:GetCustomStatic(sPower_Level) then
        hud:AddCustomStatic(sPower_Level, true)
      end
    end
  end
  if get_hud():GetCustomStatic("minimap_fake", true) then
    get_hud():RemoveCustomStatic("minimap_fake", true)
  end
  if not get_hud():GetCustomStatic("minimap_fake", true) then
    get_hud():AddCustomStatic("minimap_fake", true)
  end
  if get_hud():GetCustomStatic("bar_ammo", true) then
    get_hud():RemoveCustomStatic("bar_ammo", true)
  end
  if not get_hud():GetCustomStatic("bar_ammo", true) then
    get_hud():AddCustomStatic("bar_ammo", true)
  end
end

function remove_elements_3()
local hud = get_hud()

hud:RemoveCustomStatic("health_level_1")--, true)
hud:RemoveCustomStatic("health_level_2")--, true)
hud:RemoveCustomStatic("health_level_3")--, true)
hud:RemoveCustomStatic("health_level_4")--, true)
hud:RemoveCustomStatic("health_level_5")--, true)
hud:RemoveCustomStatic("health_level_6")--, true)
hud:RemoveCustomStatic("health_level_7")--, true)
hud:RemoveCustomStatic("health_level_8")--, true)
hud:RemoveCustomStatic("health_level_9")--, true)
hud:RemoveCustomStatic("health_level_10")--, true)
hud:RemoveCustomStatic("health_level_11")--, true)
hud:RemoveCustomStatic("health_level_12")--, true)
hud:RemoveCustomStatic("health_level_13")--, true)
hud:RemoveCustomStatic("health_level_14")--, true)
hud:RemoveCustomStatic("health_level_15")--, true)
hud:RemoveCustomStatic("health_level_16")--, true)
hud:RemoveCustomStatic("health_level_17")--, true)
hud:RemoveCustomStatic("health_level_18")--, true)
hud:RemoveCustomStatic("health_level_19")--, true)
hud:RemoveCustomStatic("health_level_20")--, true)
hud:RemoveCustomStatic("health_level_21")--, true)
hud:RemoveCustomStatic("health_level_22")--, true)
hud:RemoveCustomStatic("health_level_23")--, true)
hud:RemoveCustomStatic("health_level_24")--, true)    
end

function remove_elements_4()
local hud = get_hud()
    hud:RemoveCustomStatic("power_level_1")--, true)
    hud:RemoveCustomStatic("power_level_2")--, true)
    hud:RemoveCustomStatic("power_level_3")--, true)
    hud:RemoveCustomStatic("power_level_4")--, true)
    hud:RemoveCustomStatic("power_level_5")--, true)
    hud:RemoveCustomStatic("power_level_6")--, true)
    hud:RemoveCustomStatic("power_level_7")--, true)
    hud:RemoveCustomStatic("power_level_8")--, true)
    hud:RemoveCustomStatic("power_level_9")--, true)
    hud:RemoveCustomStatic("power_level_10")--, true)
    hud:RemoveCustomStatic("power_level_11")--, true)
    hud:RemoveCustomStatic("power_level_12")--, true)
    hud:RemoveCustomStatic("power_level_13")--, true)
    hud:RemoveCustomStatic("power_level_14")--, true)
    hud:RemoveCustomStatic("power_level_15")--, true)
    hud:RemoveCustomStatic("power_level_16")--, true)
    hud:RemoveCustomStatic("power_level_17")--, true)
    hud:RemoveCustomStatic("power_level_18")--, true)
    hud:RemoveCustomStatic("power_level_19")--, true)
    hud:RemoveCustomStatic("power_level_20")--, true)
    hud:RemoveCustomStatic("power_level_21")--, true)
    hud:RemoveCustomStatic("power_level_22")--, true)
    hud:RemoveCustomStatic("power_level_23")--, true)
    hud:RemoveCustomStatic("power_level_24")--, true)    
end

Скрипты рабочие. Помогите разобраться, где ошибка... Заранее спасибо.

Убедительная просьба ИСПОЛЬЗОВАТЬ тэги [cоde] для кодов. --/ Artos

Изменено 17 Сентября 2011 пользователем Artos

Artos · 17 Сентября 2011

PavelSnork

Несложно портянки организовать в циклы:

function remove_elements_3()
  local hud = get_hud()
  for i=1,24 do
    local sCustomStatic = "health_level_"..i --/ имя очередного
    if hud:GetCustomStatic(sCustomStatic) then --/ проверка наличия
      hud:RemoveCustomStatic(sCustomStatic) --/ удаление
    end
  end
end

function remove_elements_4()
  local hud = get_hud()
  for i=1,24 do
    local sCustomStatic = "power_level_"..i --/ имя очередного
    if hud:GetCustomStatic(sCustomStatic) then --/ проверка наличия
      hud:RemoveCustomStatic(sCustomStatic) --/ удаление
    end
  end
end

При удалении кастомстатика - делай проверки на его наличие!

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

Добавлено через 104 мин.:

P.S. Поправил ошибку в 4-ой строке: sName -> sCustomStatic (sorry)

Изменено 17 Сентября 2011 пользователем Artos

*Shoker* · 17 Сентября 2011

Gun12, Спасибо.

Вот ещё кто может подсказать, требуется скриптово присвоить НПС какой то диалог.

Тоесть у меня есть отдельный диалог, который я хочу дать механикам. Но мне не хочется делать это черезе character_desc_xxx.xml

Можно как то, обладая онлайн объектом персонажа, дописать ему ещё один <actor_dialog> в список фраз?

Нашёл только стартовый диалог.

Изменено 17 Сентября 2011 пользователем ColR_iT

Artos · 17 Сентября 2011

*Shoker*

"Скриптово присвоить НПС какой то диалог" - можно.

Скриптово "как-то ... дописать ему ещё один <actor_dialog>" - нет, и тем более не в "список фраз".

(каков вопрос - таков ответ)

Изменено 17 Сентября 2011 пользователем Artos

Nazgool · 17 Сентября 2011

PavelSnork

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

А вот про составление кода могу поболтать...

Твои проверки в функции

check_params() не очень оптимальны.

На скорую руку хотел посоветовать избавиться от лишних проверок, используя код типа :

function check_params()
  --/ health
    local iHealth = db.actor.health
    local sHealth_Level
    if iHealth > 0.97 then
        sHealth_Level = "health_level_24"
    elseif iHealth > 0.94 then
        sHealth_Level = "health_level_23"
    elseif iHealth > 0.9  then
        sHealth_Level = "health_level_22"
    elseif iHealth > 0.86 then
        sHealth_Level = "health_level_21"
    elseif iHealth > 0.82 then
        sHealth_Level = "health_level_20"
    elseif iHealth > 0.77 then
        sHealth_Level = "health_level_19"
    elseif iHealth > 0.73 then
        sHealth_Level = "health_level_18"
    elseif iHealth > 0.69 then
        sHealth_Level = "health_level_17"
    elseif iHealth > 0.65 then
        sHealth_Level = "health_level_16"
    elseif iHealth > 0.61 then
        sHealth_Level = "health_level_15"
    elseif iHealth > 0.57 then
        sHealth_Level = "health_level_14"
    elseif iHealth > 0.53 then
        sHealth_Level = "health_level_13"
    elseif iHealth > 0.49 then
        sHealth_Level = "health_level_12"
    elseif iHealth > 0.45 then
        sHealth_Level = "health_level_11"
    elseif iHealth > 0.41 then
        sHealth_Level = "health_level_10"
    elseif iHealth > 0.36 then
        sHealth_Level = "health_level_9"
    elseif iHealth > 0.32 then
        sHealth_Level = "health_level_8"
    elseif iHealth > 0.28 then
        sHealth_Level = "health_level_7"
    elseif iHealth > 0.24 then
        sHealth_Level = "health_level_6"
    elseif iHealth > 0.2  then
        sHealth_Level = "health_level_5"
    elseif iHealth > 0.16 then
        sHealth_Level = "health_level_4"
    elseif iHealth > 0.12 then
        sHealth_Level = "health_level_3"
    elseif iHealth > 0.08 then
        sHealth_Level = "health_level_2"
    elseif iHealth > 0.04 then
        sHealth_Level = "health_level_1"
    end
.... и т.д.

Но и этот вариант хоть по скорости и "реальному состоянию ГГ" лучше твоего, но неравномерность нагрузки мне не нравиться.

Поясню.

Скорость выигрывается только за счет удаления лишних проверок.

Теперь о "реальном состоянии ГГ".

В твоём коде самые быстрые проверки (первые 3-5) приходятся на то, когда у ГГ здоровье ниже четверти.

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

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

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

И не известно к чему такие пики могут привести.

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

Разница в количестве операций очевидна.

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

Например по принципу "Поиск льва в Африке" (делим Африку пополам,...,потом оставшуюся часть ещё пополам. И в конце концов найдём) :

function check_params()
  --/ health
    local iHealth = db.actor.health
    local sHealth_Level
    if iHealth > 0.53 then
        if iHealth > 0.77 then
            if iHealth > 0.9  then
                if iHealth > 0.94 then
                    if iHealth > 0.97 then
                        sHealth_Level = "health_level_24"
                    else
                        sHealth_Level = "health_level_23"
                    end
                else
                    sHealth_Level = "health_level_22"
                end
            elseif iHealth > 0.82 then
                if iHealth > 0.86 then
                    sHealth_Level = "health_level_21"
                else
                    sHealth_Level = "health_level_20"
                end
            else
                sHealth_Level = "health_level_19"
            end
        elseif iHealth > 0.65 then
            if iHealth > 0.69 then
                if iHealth > 0.73 then
                    sHealth_Level = "health_level_18"
                else
                    sHealth_Level = "health_level_17"
                end
            else
                sHealth_Level = "health_level_16"
            end
        elseif iHealth > 0.57 then
            if iHealth > 0.61 then
                sHealth_Level = "health_level_15"
            else
                sHealth_Level = "health_level_14"
            end
        else
            sHealth_Level = "health_level_13"
        end
    elseif iHealth > 0.28 then
        if iHealth > 0.41 then
            if iHealth > 0.45 then
                if iHealth > 0.49 then
                    sHealth_Level = "health_level_12"
                else
                    sHealth_Level = "health_level_11"
                end
            else
                sHealth_Level = "health_level_10"
            end
        elseif iHealth > 0.32 then
            if iHealth > 0.36 then
                sHealth_Level = "health_level_9"
            else
                sHealth_Level = "health_level_8"
            end
        else
            sHealth_Level = "health_level_7"
        end
    elseif iHealth > 0.16 then
        if iHealth > 0.20 then
            if iHealth > 0.24 then
                sHealth_Level = "health_level_6"
            else
                sHealth_Level = "health_level_5"
            end
        else
            sHealth_Level = "health_level_4"
        end
    elseif iHealth > 0.12 then
        sHealth_Level = "health_level_3"
    elseif iHealth > 0.08 then
        sHealth_Level = "health_level_2"
    elseif iHealth > 0.04 then
        sHealth_Level = "health_level_1"
    end

В этом случае нагрузка становиться практически одинаковой при любом показателе, т.к. для поиска совпадения для любого состояния здоровья производиться примерно 5 шагов.

(на последней проверке 6, но это из-за лени :-))

Изменено 17 Сентября 2011 пользователем Gun12

Artos · 18 Сентября 2011

Gun12, PavelSnork

А почему совсем не снять шоры (зацикленность именно на стандартном подходе в таких ситуациях) и ...

Имеем здоровье актора: iHealth = db.actor.health , которое может лежать в диапазоне 0 ... 1

Имеем набор кастомстатиков строго в диапазоне 1 ... 24

Зависимость, судя по проверкам линейна!

Т.е. на каждые 0.04 - один элемент из списков статиков.

В итоге имеем:

  local iHealth = db.actor.health
  if iHealth < 0.94 and iHealth > 0.04 then
    local sHealth_Level = "health_level_"..(math.ceil(iHealth * 25)-1)
    local hud = get_hud()
    if not hud:GetCustomStatic(sHealth_Level) then
      hud:AddCustomStatic(sHealth_Level, true)
    end
  end

и никаких переборов кучи условий, а только не более двух + простенькое вычисление и выбор нужного. :-)

При совсем здоровом ГГ - только проверка "не приболел ли малость?"

Добавлено через 22 мин.:

P.S. Остается немного и ... переходим в следующий класс, если как полагаю, этот кастомстатик - некая шкала с переменной длиною.

Оставляем один кастомстатик дабы не плодить строк в конфиге иль даже текстур и ... меняем скриптом его длину. ;-)

Но .. не будем отвлекаться, вопрос пока в ошибке, которая как полагает PavelSnork именно в этих функциях.

Добавлено через 247 мин.:

P.P.S. Чуть поразмышлял (отвлекаясь от других дел ...):

PavelSnork, уточни, плз, диапазоны здоровья и силы актора 0...0.04 тебя совсем не волнуют?

Т.е. не важно что (есть/нет) кажут кастомстатики?

Вот полный вариант, совмещающий все твои функции, в котором при полных (почти) здоровье и силе актора выводятся твои 24-ые кастомстатики и при падении параметров - номера уменьшаются. При <=0.04 - удаляются.

local sHealth_Save = nil
local sPower_Save  = nil

function check_params()
  local hud = get_hud()
  --/ clear
  function Clear(sName)
    for i=1,24 do
      if hud:GetCustomStatic(sName..i) then --/ проверка наличия
        hud:RemoveCustomStatic(sName..i) --/ удаление
      end
    end
  end
  --/ health
  local iHealth = db.actor.health --/ здоровье актора
  if iHealth > 0.04 then --/ если есть здоровье
    --/ вычисляем нужный индикатов
    sHealth_Level = "health_level_"..(math.ceil(iHealth * 25)-1)
    if sHealth_Level ~= (sHealth_Save or "") then --/ индикатор уровня не прежний?
      if sHealth_Save then
        Clear("health_level_") --/ чистим
      end
      hud:AddCustomStatic(sHealth_Level, true) --/ выводим нужный
      sHealth_Save = sHealth_Level --/ запоминаем
    end
  elseif sHealth_Save then --/ нет здоровья и при наличии индикатора
    Clear("health_level_") --/ чистим
    sHealth_Save = nil --/ обнуляем, дабы не чистить постоянно
  end
  --/ power
  local iPower = db.actor.health --/ сила актора
  if iPower > 0.04 then --/ если есть сила
    --/ вычисляем нужный индикатов
    sPower_Level = "power_level_"..(math.ceil(iHealth * 25)-1)
    if sPower_Level ~= (sPower_Save or "") then --/ индикатор уровня не прежний?
      if sPower_Save then
        Clear("power_level_") --/ чистим
      end
      hud:AddCustomStatic(sPower_Level, true) --/ выводим нужный
      sPower_Save = sPower_Level --/ запоминаем
    end
  elseif sHealth_Save then --/ нет силы и при наличии индикатора
    Clear("power_level_") --/ чистим
    sPower_Save = nil --/ обнуляем, дабы не чистить постоянно
  end
end

Изменено 18 Сентября 2011 пользователем Artos

Real Wolf · 18 Сентября 2011

Код в скрипте:

    local oMessage = CUIMessageBoxEx()
    oMessage:Init("message_bad_cond")
    level.start_stop_menu(oMessage, true)

Несколько раз вызвав окно таким образом, я получил вылет:

stack trace: 
[error][       8]    : Недостаточно памяти для обработки команды.

*Shoker*,

Без дополнительного UI окна. Причем вылет происходит не сразу.

Изменено 18 Сентября 2011 пользователем Real Wolf

PavelSnork · 18 Сентября 2011

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

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

P.S. Остается немного и ... переходим в следующий класс, если как полагаю, этот кастомстатик - некая шкала с переменной длиною.
Оставляем один кастомстатик дабы не плодить строк в конфиге иль даже текстур и ... меняем скриптом его длину. ;-)

Было бы неплохо... Но думаю, это невозможно, т.к. индикаторы идут по кругу. Так что лучше я буду плодить текстуры. ;-)

Изменено 18 Сентября 2011 пользователем PavelSnork

*Shoker* · 18 Сентября 2011

Real Wolf

Ты вызываешь MB посреди другого UI или прямо во время игры?

Тоесть твой код находится в скрипте другого UI или весь твой UI ограничен тока этими 3-я строками?

Если второе, то наверно так нельзя, хотя не уверен. По крайнем мере в ЧН я сперва инициализирую обычный скриптовый UI (CUIScriptWnd) а уже в нём инициализирую MB. По другогому не пробовал и не знаю, сработает ли, но мой вариант работает без проблем, а там только вызов MB-а.

_________

Вот ещё хотел уточнить, в функциях открытия UI-окон (level.start_stop_menu() а также self:GetHolder():start_stop_menu(self.ui_dlg, true))

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

Если делать device():pause() то UI тоже блокируется.

Изменено 18 Сентября 2011 пользователем *Shoker*

RayTwitty · 18 Сентября 2011

*Shoker*,

start_stop_menu(self.ui_dlg, true)

Последний аргумент отвечает за скрытие элементов худа при включенном меню.

Изменено 18 Сентября 2011 пользователем Shadows

Artos · 18 Сентября 2011

Real Wolf

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

Для объектов класса 'CUIMessageBoxEx' не предусмотрен метод 'Init(string)', но зато есть 'InitMessageBox(string)' (ЧН!).

(беря коды из ТЧ - следует проверять - а не изменилось ли чего в ЧН/ЗП?)

Добавлено через 7 мин.:

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

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

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

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

Изменено 18 Сентября 2011 пользователем Artos

Real Wolf · 18 Сентября 2011

Код применяется в ТЧ. В любом случае, я проблему решил с помощью скриптового класса.

panzyuza · 18 Сентября 2011

А как правильно, используя похожую функцию #2790 выполнить проверку на то, что в данный момент собака атакует игрока? И указать вероятность 50% на выпадение оружия у ГГ.

Изменено 18 Сентября 2011 пользователем Artos

Artos · 18 Сентября 2011

Real Wolf

Ну что- же если решил, так это хорошо ...

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

ИМХО, если это в ТЧ, то твоя проблема в том, что вместо однократного создания объекта, что обычно делают при инициализации схемы/скрипта, ты плодишь объекты окон с каждым вызовом, а не "Несколько раз вызвав окно". Вот и ... -> нехватка памяти.

Создав некий 'свой' класс - предполагаю, что именно в нем ты, единожды создав, уже и работаешь с этим окном.

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

Добавлено через 4 мин.:

panzyuza

Заменить класс бюрера на собачий (собачьИ) ...

Изменено 18 Сентября 2011 пользователем Artos

*Shoker* · 18 Сентября 2011

Да, кстати, по поводу "Несколько раз вызвав окно"

Использую в скриптах у себя такую конструкцию.

    self.helper_dlg         = m_helper.helper(true)
    self.helper_dlg.owner    = self
    self:GetHolder():start_stop_menu(self.helper_dlg, true)

Тоесть при каждом её вызове переменной self.helper_dlg присваивается (или ещё что то) мой UI.

У GSC есть похожая конструкция, но там они делают проверку, что переменной self.helper_dlg уже хотя бы раз был присвоен UI.

    if self.helper_dlg == nil then
     self.helper_dlg         = m_helper.helper(true)
    end

    self.helper_dlg.owner    = self
    self:GetHolder():start_stop_menu(self.helper_dlg, true)

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

Так вот, не остаётся ли мой старый UI в памяти, если я инициализирую новый (такой же) на ту же переменную, что и старый?

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

Изменено 18 Сентября 2011 пользователем *Shoker*

Artos · 18 Сентября 2011

*Shoker*

Если старый объект (UI в частности) имеет локальный характер - его (если уже не востребован) с некоторой периодичностью уничтожает 'сборщик мусора' LUA.

Отступление: Если хочется побыстрее избавиться от мусора - смотрим как это делают SGC:

collectgarbage('collect') --/ performs a full garbage-collection cycle

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

Примечание(важно!): GUI объекты сохраняются даже при перезагрузке игры (т.е. без выхода в ОС), что может сослужить плохую службу и приводить к вылетам. Такие объекты, которые должны в игре, запущеной заново, создаваться 'c ноля' - следует удалять (нанилять их переменные) в обязательном порядке.

(сорри за пространное пояснение, но оно бельше 'для всех', а не как ответ на конкретный вопрос)

Изменено 18 Сентября 2011 пользователем Artos

*Shoker* · 18 Сентября 2011

Хм, тоесть если я допустим сделаю инициализацию UI вот так и так:

local ui = m_helper.helper(true) --\\ локальная переменная

global_ui = m_helper.helper(true) --\\ глобальная переменная

То первая удалится при загрузке, а вторая так и останется в памяти?

Странно конечно, но так ли это критично? Ну останется, так останется, или он как то может повредится при save\load?

Просто не понятно от чего такие глюки вызывает это.

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

Кстати кто проверял всё это? ^^^

Изменено 18 Сентября 2011 пользователем *Shoker*

Artos · 18 Сентября 2011

*Shoker*

Без довольно глубоких опусканий к основам - такое объяснить и понять сложновато ...

Чуть подробнее и не на абстракии , а на практическом примере:

В Simbion'e есть модуль, который выводит окна доп.слотов (нож,бинокль, ...)

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

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

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

Принудительное деаттачивание и удаление созданных объектов в методе '__finalize()' при выходе из игры - сняло все проблемы.

Т.о. имеет важность именно объект, а не переменная, о чем выше не совсем внятно написал.

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

Изменено 18 Сентября 2011 пользователем Artos

=VENOM= · 19 Сентября 2011

abramcumner, цитирую:

=VENOM=,
если хочешь, чтобы респавнеры работали в соответствии со своими названиями, то прописывай им respawn_radius. Но не уверен что это хорошая идея - может получаться как на свалке у ангара - непрерывный поток НПЦ. Сейчас от момента спавна до прибытия на точку проходит достаточно много времени именно из-за того, что НПЦ далеко идти от респавнера. А если бы все было как говорит Artos, то не успел бы обшмонать бандитов на АТП, как туда уже новые входят

Я, если честно, знаю об этом, и у меня в all.spawn уже давным-давно вообще нет тех респонеров, которые были в оригинальной игре (цель постановки вопроса была совсем в другом - и, в общем, достигнута ). Однако, с моей точки зрения, гораздо лучше оставить всё, как есть (т.е. оффлайновый респон всех NPC - и сталкеров, и... мутантов), иначе неудачно расположенные респонеры, подходящие по параметрам для смартов на текущей локации (достаточно далеко от "зачищаемого" смарта по respawn_radius) в некоторой степени лишат игру "симуляционной миграции" NPC между локациями. Что будет выглядеть не очень хорошо - как будто локации изолированы друг от друга. А насчёт "вербовщиков" - это, конечно, разработчику решать. Моё мнение - совсем уж сопливых новичков никто не ждёт в группировках - себе дороже обойдутся. Более логичным выглядело бы вербовать более опытных сталкеров, скажем, в Баре (тут, правда, есть проблема - в оригинальной игре Бар контролируют "долгари", как быть со "Свободой"?). Ну, а создать респонеры, срабатывающие по условию, проще простого. К примеру, у себя я сделал отслеживание продвижения игрока по локациям, и, по ходу игры - в соответствии с этими условиями - начинают включаться респонеры (чтобы они раньше положенного срока не плодили тех NPC, которые на ранних этапах не требуются). Ну, а некоторые, наоборот, отключаются. В значительной степни пришлось сделать это из-за АМК "оффлайн-алайфа", отключать который мне не хочется. Впрочем, можно чуточку "поколдовать", и сделать так, чтобы в зависимости от условий (функция, инфопоршн) один и тот же респонер будет порождать NPC селективно, а не по приоритетному выбору из нескольких секций, как сейчас.

Войти

Скриптование

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

Real Wolf 34

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

PavelSnork 3

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

Artos 99

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

*Shoker* 322

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

Artos 99

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

Nazgool 250

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

Artos 99

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

Real Wolf 34

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

PavelSnork 3

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

*Shoker* 322

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

RayTwitty 509

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

Artos 99

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

Real Wolf 34

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

panzyuza 43

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

Artos 99

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

*Shoker* 322

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

Artos 99

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

*Shoker* 322

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

Artos 99

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

=VENOM= 50

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

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

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

Войти

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

AMK Склад

Shoker 322

Shoker 322

Shoker 322

Shoker 322