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

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

Полтергейст, какова цель твоего довольно бессмысленного (ИМХО) поста?

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

Собственно и сам вопрос достаточно бестолков: "Как такое вообще может быть?", т.к. и идеальных безошибочных прогамм не бывает "вооЩе", и тем более сам "Сталкер" не блещет отсутствием самых разных багов ...

Вот если пояснишь в чем такая важность "наличия" данного бага и дашь соотв.пояснения по конкретике - тогда и потратить время можно на поиски причин и решений.

"Но иногда найдется вдруг чудак, этот чудак все сделает не так ..."© Машина времени

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

Проверку делал в функции update() биндера NPC.

В net_spawn присвоил

self.motivator = self.object:motivation_action_manager()

 

В update проверял вот этим кодом:

    local val = self.motivator.storage:property(stalker_ids.property_enemy)
    if val == true and not self.object:best_enemy() then
        error("property_enemy returns true when best_enemy() == nil!")
    end

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

FATAL ERROR

[error]Expression : fatal error

[error]Function : CScriptEngine::lua_error

[error]File : E:\stalker\sources\trunk\xr_3da\xrGame\script_engine.cpp

[error]Line : 73

[error]Description : <no expression>

[error]Arguments : LUA error: d:\games\soc\gamedata\scripts\xr_motivator.script:109: property_enemy returns true when best_enemy() == nil!

 

stack trace:

Scheduler tried to update object esc_lager2

 

Для stalker_ids.property_danger такая же ошибка. Возможно, эта функция вообще не работает так, как должна.

 

в чем такая важность "наличия" данного бага

Есть в некоторых скриптах такие проверки:

local mgr = npc:motivation_action_manager()
if mgr:evaluator(stalker_ids.property_*):evaluate() then
...
end

 

Вместо того, чтобы заново пересчитывать значение, быстрее и проще (особенно для скриптовых эвалуаторов, например property_danger) было бы воспользоваться уже готовым. В оригинальных скриптах эта функция не используется, поэтому баг никто не замечал. Скорее всего без ковыряния движка его не исправить.

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

Полтергейст, конечно попытки использовать низкоуровневые методы и функции похвальны ;-), но ...

1. Это все же уже скорее не скриптинг, а исследованиие начинки движка и эпистолярный жанр форумов врядли способствует таким "ковыряниям".

2. В подобных ковыряниях не следует заниматься навешиванием себе шор и тем более из'ясняться правильно и на общедоступном языке ...

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

3. Сравнивать/сопостовлять совершенно разные по сути элементы - бессмысленно в любом случае.

а) Что такое best_enemy()? Это метод, который возвращает об'ект врага для данного клиентского об'екта. В конкретный момент времени об'ект врага или есть или его нет.

б) Что такое (в контексте обсуждаемого) storage и конкретно storage:property(stalker_ids.property_enemy)?

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

Не следует путать (не)наличие подключенного эвалуатора с его состоянием (зафиксирован ли враг иль нет).

Ну а сравнивать состояние эвалуатора с конкретным наличием об'екта врага - это вообще абсурд! (см. п.4)

4. Факт наличия или отсутствия об'екта (врага) - однозначен в любой момент времени. Состояние же эвалуатора, который фиксирует событие наличия врага далеко не однозначно (точнее зависит не только от наличия врага в данный момент)! Нам вообще неизветен алгоритм проверки этого события внутри движка. Какова дискретность обсчета? Каков гистерезис или время "запоминания"? В игре вообще искусственно вводятся времена для "помнить" факт наличия врагов/раздражителей.

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

 

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

Изменено пользователем Artos

"Но иногда найдется вдруг чудак, этот чудак все сделает не так ..."© Машина времени

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

Что делает вызов amk_particle.amk_particle() ?

Скрипт, ну, предположим, стандартный от amk ?

 

Это amk_particle:__init(params) вызывается ? А что он возвращает ?

 

Artos, ага, спасибо. Парочку тривиальных вида nil:add( что попало ) уже вижу.

Ну и, как я понимаю, конструкция вида if p:is_finished() then p:update() применительно к этому "классу" - это, вроде, тоже не совсем здраво ?

 

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

Dennis_Chikin, вызов amk_particle.amk_particle() без параметров/аргументов приведет только к ошибке.

Собственно этот вызов запускает конструктор класса "amk_particle" и создается об'ект 'этого класса в зависимости от входных аргументов. Возвращает естественно созданный классом об'ект. Далее метод update этого класса вызывается из соотвествующего коллбэка 'update' сталкера (или и монстра в старой версии мода), что и приводит к изменениям ...

Примечание: Класс (в исполнении скрипта АМК) имеет скрытые потенциальные ошибки, что порою приводит в вылетам. Помнится, доработкой класса занимались и в OGSE и в SIMBION модах.

"Но иногда найдется вдруг чудак, этот чудак все сделает не так ..."© Машина времени

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

Подскажите что именно нужно сделать, чтоб этот скрипт работал на чистой игре?

local need_update = 0
local heart = nil
local id

function on_item_drop(item)
    if item:section() ~= "mega_heart" then
        return
    end
    --dbg.log("RES: on_item_drop item=%s", item:name())    
    heart = item
    need_update = 1
end

function update()
    if need_update == 0 then return end
    --dbg.log("RES: update stage=%s", need_update)
    if need_update == 1 then
        local obj = heart:parent()
        if obj == nil then
            --dbg.log("RES: only drop. return")    
            return
        end
        id = obj:id()
        
        local inv = level.main_input_receiver()
        if inv ~= nil then
            level.start_stop_menu(inv, false)
            --dbg.log("RES: close inv")
        end
        
        amk.convert_npc[id] = true
        local sim = alife ()
        sim:set_switch_online  (id, false)
        sim:set_switch_offline (id, true)
        --dbg.log("RES: [%s] move offline", obj:name())
        need_update = 2
    elseif need_update == 2 then
        --dbg.log("RES: update 2")
        local obj = level.object_by_id(id)
        if obj == nil then
            --dbg.log("RES: real move offline")
        else
            --dbg.log("RES: wait offline")
            return
        end
        --dbg.log("RES: update 3")
        local sobj = alife():object(id)
        --dbg.log("RES: update 4")
        t = amk.read_stalker_params(sobj)
        --dbg.log("RES: update 5")
        t.health=0.1
        t.killerid=65535
        for i=1,8 do t.game_death_time[i] = 0 end
        t.updhealth = 0.1
        t.skeleton_flags=0
        --dbg.log("RES: update 6")
        amk.write_stalker_params(t, sobj)
        --dbg.log("RES: repack packet")
        need_update = 0
    end
end

 

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

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

1. "Чистых" игр целых три (ТЧ/ЧН/ЗП), не считая патчей ...

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

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

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

 

Ну и вопрос к тебе: "А что тобою самим сделано, чтобы понять как заставить этот скрипт работать?" Или ты надеешься на халяву, т.е. чтобы тебе дали готовые коды и тебе оставалось бы только бездумно скопипастить?

 

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

P.S. Вот когда ты сможешь хотя бы так понимать скрипт:

local need_update = 0 --/ флаг режима оживления
local heart = nil --/ 'оживляющий' предмет
local idNPC --/ идентификатор оживляемого НПС

function on_item_drop(item) --/< вызов из коллбэка на потерю предмета актором
  --/ проверка: актором потерян 'оживляющий' предмет?
  if item:section() == "mega_heart" then
    heart = item --/ запоминаем 'оживляющий' предмет
    need_update = 1 --/ разрешаем 1-й этап оживления
  end
end

function update() --/< вызов (например) из коллбэка апдейта актора
  if need_update == 0 then
    return --/> режим оживления отключен
  end
  --/(1) Этап проверки 'попадания' предмета в труп НПС
  if need_update == 1 then
    local oNPC = heart:parent() --/ новый 'владелец' предмета
    if not oNPC then
      return --/> труп еще не стал владельцем
    end
    idNPC = oNPC:id() --/ запоминаем ID оживляемого НПС
    --/ нужно закрыть окно инвентаря:
    if level.main_input_receiver() ~= nil then --/ если открыто
      level.start_stop_menu(inv, false) --/ закрываем окно
    end
    --/ заносим ID оживляемого в таблицу переключения в онлайн (внешний amk.script)
    amk.convert_npc[idNPC] = true
    --/ переводим НПС в оффлайн
    alife():set_switch_online(idNPC, false)
    alife():set_switch_offline(idNPC, true)
    --/ разрешаем следующий этап-2
    need_update = 2
  --/(2) Этап подготовки к оживлению трупа
  elseif need_update == 2 then
    --/ проверяем состояние трупа:
    if level.object_by_id(idNPC) then
      return --/> еще рано, труп в онлайне
    end
    --/ получаем серверный об'ект трупа НПС
    local soNPC = alife():object(idNPC)
    if soNPC then --/ об'ект в игре?
      --/ читаем внешним amk-скриптом нет-пакет сталкера
      t = amk.read_stalker_params(soNPC)
      --/ меняем параметры для оживления трупа
      t.health    = 0.1
      t.updhealth = 0.1
      t.killerid  = 65535
      for i=1,8 do t.game_death_time[i] = 0 end
      t.skeleton_flags = 0
      --/ записываем внешним amk-скриптом измененный нет-пакет сталкера
      amk.write_stalker_params(t, soNPC)
      --/ выключаем режим оживления
    end
    need_update = 0
  end
end

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

Изменено пользователем Artos

"Но иногда найдется вдруг чудак, этот чудак все сделает не так ..."© Машина времени

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

Artos

Лично я ничего своего ещё не сделал, в скриптах я полный ноль.

И неужели все кто использует что-то, что не сделал сам, это халявщики.

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

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

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

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

 

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

alex5773, не нужно всех валить в одну кучу! У тебя несколько извращенное понятие о "помощи".

Халявщик - это далеко не тот, кто пользуется трудом других, а тот, кто НИЧЕГО сам при этом не делает, а только пользуется.

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

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

alex5773, Лично я всегда помогаю, кто у меня просит помочь ему что-либо сделать, что смогу всегда сделаю
Разница между помочь сделать и сделаю за кого-то очень велика, как и сам результат.

Раздел носит название "Школа моддинга", где помогают САМИМ что-то узнать/понять/сделать, а не "Мастерская по заказам" ...

Не умеешь и не хочешь научиться - подищи себе иное место для поиска "помогальщиков", ну а если иначе - то начинай читать-читать-читать и учитьСЯ самому делать, а не уповать на "помощь" других (ты вроде как не ребенок и не немощный старец).

 

Оффтопик прекращаем! Прочти шапку - о том какие и как вопросы задаются в этом топике.

Изменено пользователем Artos

"Но иногда найдется вдруг чудак, этот чудак все сделает не так ..."© Машина времени

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

Всем привет.

Возникла нужда по сокращению кол-ва if-ов в функции. А именно:

Спавню телепорты, пример ф-ии:

function spawn_nano_tel_lim_24()
    local se_obj = alife():create("nano_tel_119",vector():set(-23.000,20.283,-121.000),13608,2996)
      xr_logic.pstor_store(db.actor, "nano_tel_119", se_obj.id)    
end

 

И спавнов происходит иногда до 2-3 х десятков. Удаляю все созданные телепорты в конце, пример ф-ии:

function del_nano_tel_lim(story_id)
local aa = alife()
local bb = xr_logic.pstor_retrieve
local gg = db.actor
    local obj_1 = bb(gg, "nano_tel_84", -1) -- тут куча переменных для каждого ТП
    local tel_1 = aa : object(obj_1)

    if tel_1 then -- а тут иногда огромные лесенки из if-ов
      aa:release(tel_1, true)
    end 
end

 

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

local tbl_nano_tel = { -- Пишем глобальную табличку телепортов

["nano_tel_war"] = { -- подтабличка для 1 локации
"nano_tel_1", 
"nano_tel_2",
........,
........
},
["nano_tel_x16"] = { -- подтабличка для 2 локации
"nano_tel_1", 
"nano_tel_2",
........,
........
},
..........
}

 

Однако встала проблема, теперь телепорты не удаляются.

Раньше я писал секцию телепорта, сейчас делаю так:

function del_nano_tel_war(story_id) -- удаляем ТП с Варлаба
local war = tbl_nano_tel["nano_tel_war"] -- объявим подтаблицу с нужными ТП
local obj = xr_logic.pstor_retrieve(db.actor, war, -1)
local tel = alife():object(obj)
    if tel then
          alife():release(tel, true)
        end
end

 

Что я сделал не так? Заранее спасибо.

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

volazar у тебя в переделанной функции удаления, ключом для чтения из пстора является таблица телепортов локации. а функцию спавна ты переделал? она же у тебя записывает по строковому ключу, а не по таблице.

 

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

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

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

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

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

Zander_driver, Да я уже разобрался, Charsi подсказал. Только вот пост уже не смог отредактировать(

Все оказалось просто, надо было добавить строку:

for _, teleport_name in pairs (war) do

Где war это объявленная ранее нужная подтаблица.

И добавить end в конце. Проверил - все отлично удаляется.

function del_nano_tel_war(story_id) 
local war = tbl_nano_tel["tel_war"]()
for _, teleport_name in pairs (war) do
   local obj = xr_logic.pstor_retrieve(db.actor, teleport_name , -1)
   local tel = alife():object(obj)
    if tel then
      alife():release(tel, true)
    end
end
end

 

ЗЫ: Я тут немного переделал (local war = tbl_nano_tel["tel_war"]()) - таблица хранится в отдельном файле, а не вместе с ф-ями удаления.

А ф-ию спавна мне и надо по строковому. Так как телепорты спавнятся не все сразу, а друг за другом и из логики рестриктора.

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

В общем всем спасибо. Пост на усмотрение модератора.

Собственно вопрос не имеет никакой информативной ценности, т.к. допущена банальная ошибка/путаница с аргументом для вызываемой функции.

Однако есть другой нюанс, о котором см. ниже. --/Artos

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

volazar, хотел бы обратить внимание на:

1. Тобою используется для запоминания заспавненных телепортов таблица pstor актора. Эта таблица полностью запоминается в сэйвы.

Размер каждого пакета для об'ектов в сэйвах НЕ может превышать 8 kБ для ТЧ (или 16кБ для ЧН/ЗП).

Теперь считай: каждая твоя переменная имеет имя ~12 байт и значение 4 байта, т.о. тратится в сумме 16 байт на каждую(!) переменную.

Если, как ты пишешь: "спавнов происходит иногда до 2-3 х десятков" и вероятно не раз в процессе игры - напрашивается простое желание подсчитать: "А сколько же будут с'едать эти запомненные телепорты байтов в сэйвах?".

Довольно просто подсчитать, что при сотне - будет потрачено более 1.5 кБ !

2. При удалениях телепортов тобою НЕ чистятся в pstor актора соответствующие переменные, т.е. занимаемый ими об'ем остается(!) даже после сэйвов!

 

Итого: Подобный вариант хранения и удаления чреват переполнением нет-пакета актора и соответственно фатальными ошибками и/или битыми сэйвами.

 

"Но иногда найдется вдруг чудак, этот чудак все сделает не так ..."© Машина времени

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

volazar, ну это же можно посмотреть в кодах игры.

pstor - такая же (суб)таблица как и другие в игре и, присваивая соответствующему полю 'nil' - тем самым удаляешь (чистишь) его.

т.е. типа:

xr_logic.pstor_store(db.actor, teleport_name, nil) --/ очистка поля переменной

в циклах порою удобнее:

  local pstor = db.storage( db.actor:id() ).pstor --/ прямой линк на пстор-актора
  ...
    pstor[teleport_name] = nil --/ очистка соотв.переменной
  ...

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

 

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

P.S. Поправка: Совсем забыл, что в чистой игре функция xr_logic.pstor_store принимает только строки/числа/булевы значения и 'nil' в числе незарегистрированных значений. В модах использующих правки из AMK-мода это ограничение решено.

На чистой же игре следует чистить pstor напрямую, т.е.:

db.storage( db.actor:id() ).pstor[teleport_name] = nil

Изменено пользователем Artos

"Но иногда найдется вдруг чудак, этот чудак все сделает не так ..."© Машина времени

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

Странный такой вопрос возник:

local packet = net_packet() 
sobj:STATE_Write(packet)

- в packet ведь полностью наша копия того, что было в момент получения ? Что хотим, то и делаем ?

 

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

Dennis_Chikin, действительно странный вопрос ...

local packet = net_packet()

- получение об'екта класса нет-пакета, т.е. ПУСТОГО (хотя внутри может быть "мусор"), только что созданного!

sobj:STATE_Write(packet)

- запись в нет-пакет (в пустой) параметров об'екта 'sobj', причем только state-части (без update).

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

Изменено пользователем Artos

"Но иногда найдется вдруг чудак, этот чудак все сделает не так ..."© Машина времени

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

Artos, какой код - такие и вопросы.

Я, как обычно, пытаюсь понять сакральный смысл перечитывать именно это 100500 раз подряд, и полностью разбирать содержимое ради одного значения (18-я запись из 100500 возможных).

 

upd: Ну, как-бы, есть разница немалая - до нужного, или весь. пара-тройка десятков мс, или аж полсекунды тормозов, и так - 20 раз подряд.

 

Если мы не собираемся его перезаписывать - достаточно один раз прочитать, и один раз разобрать ровно до куда надо. Вроде бы. А вот по тем перекрестным ссылкам из пяти простыней, которые вопрос и вызвали, можно было предположить сколь угодно странное. Типа наличия какого-нибудь внутреннего счетчика, который нужен еще чему-нибудь, и если разобрали не за один раз, и не до конца, то случится страшное. ;)

 

Upd2: да не над чем там смеяться. Все занудно. В первом вопросе информации вполне достаточно, в ответе - тоже. По результатам снесу сотню-другую килобайт. А вот что до времени - с чтением с диска и последующим разбором - не сравнить, но тоже не мало. Специально мерил. Именно что до полусекунды получается иногда. В первый раз когда увидел - офигел.

 

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

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

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

 

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

P.S. Я тебе про одно, ты все о том же ... Ну как можно lfm ответ на абсолютно оторванный кусок кода и критиковать иль защищать?

Ты бы хоть привел пару конкретных примеров напрасного перечтения 100500 раз нет-пакетов, может вместе посмеялись бы? ;-) И не понял о каких ты "пяти простынях" говоришь ...

Ну на тебе пример ненапрасностей из моей практики:

Как определить, сколько патронов осталось в стволе у ГГ (иль у какого-то непися)? А какие патроны в стволе? А не из подствольника ли будет стрельба иль подствольник пуст??? и т.п.

 

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

Изменено пользователем Artos

"Но иногда найдется вдруг чудак, этот чудак все сделает не так ..."© Машина времени

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

Мне нужен алгоритм...я кликаю на "list_item" и мне выпадает рандомный текст(это я сделал), как запомнить какой текст выпал и больше его не выдавать(тексты выдаются из таблицы, так что я предполагаю использовать table.remove), но текстов ограниченное количество, а кликов неограниченное количество, и еще нужно сделать запоминание одного текста для кажлого лист итема...

 

Т.е. нажимаю на "1" грубо говоря, и у меня выпадает "Текст3" к примеру(рандомно разумеется), и он всегда должен выпадать когда я нажимаю на "1"(т.о. table.remove уже и не очень то подходит), а не единожды(как было бы при использовании table.remove).

function ui_c1:OnDelClicked() 
  local list = self:GetListWnd("list_spawn") 
  local index = list:GetSelectedItem()
  if index == -1 then return end 
  local item  = list:GetItem(index)  
  if item == nil then return end
  if index >= 0 then 
    local rndtext = texts[math.random(table.getn(texts))]
    local xml = CScriptXmlInit()
    xml:ParseFile("ui_c1.xml")
    local inf = xml:InitFrame("info_list", self) 
    self.a = xml:InitStatic("info_list:closjpg", inf) 
    self.b = xml:InitStatic("info_list:infotexts", inf) 
    self.b:SetText(rndtext) 
  end
end

 

Пока работает у меня так:

Кликаю на один "list_item", и появляется каждый раз рандомно выбранный текст(первичный выданный не запоминается)...в остальном в принципе как мне и надо.

texts выглядит просто...{"text1","text2","text3"...}

 

Для технических текстов используем тэги спойлера и не "убиваем" форматирование/отступы. --/Artos

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

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

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

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

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

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

Войти

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

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

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

AMK-Team.ru

×
×
  • Создать...