Народная 2010 разработка

[Kolmogor 5]

3 - вроде как какой-то экшен можно задать при попадании ГГ в него. С какой частотой запускается и как, например, её изменить - непонятно.

Рестрикторы с логикой обрабатываются в actor_binder:update

    -- обновление рестрикторов, которые под логикой, срабатывает через интервалы времени
    if self.next_restrictors_update_time < time then
        bind_restrictor.actor_update(delta)

        self.next_restrictors_update_time = time + 200 -- Частота 5 раз в секунду. Меняется здесь :)

        task_manager.actor_update()
    end

Изменено 28 Апреля 2010 пользователем Kolmogor

[Kolmogor 5]

Странно, что никто не вспомнил, что в АМК давным давно уже есть детектор зависания биндера актора

в начале actor_binder:update переменной amk.oau_watchdog выставляется значение 100, а потом в определенных местах уменьшается

Перед выходом из actor_binder:update amk.oau_watchdog присваивается 0

А в апдейте биндера НПЦ проверяется, что amk.oau_watchdog равно 0. Если не равно 0, то значит биндер ГГ завис и по значению можно понять в каком месте. Аналогичную штуку можно сделать и для биндеров НПЦ.

 

Этот механизм работает как часы, нет проблем ни с паузами, ни с загрузкой уровня и прочим

 

Подтверждаю - помогло мне при отладке усовершенствованной взрывчатки. Без этого маялся бы я с ней или вообще только баги исправил. sapsan

Изменено 3 Июня 2010 пользователем sapsan

[Kolmogor 5]

sapsan, если кратко, то IsMonster рабочая, а is_object_monster всегда будет возвращать false

 

А если длинно, надо проверить в конфигах монстров параметр class, найти его в class_registrator.script, посмотреть соответствующий ему script_clsid, и использовать в скриптах его

Например, для кабана в конфиге:

class = SM_BOARW ; AI class

в class_registrator.script строка:

cs_register (object_factory, "CAI_Boar", "se_monster.se_monster", "SM_BOARW", "boar_s")

значит в скрипте используется clsid.boar_s

[Kolmogor 5]

В скрипте se_respawn.script строку 351

table.insert(self.spawned_obj ,obj.id)

заменить на

self.spawned_obj[#self.spawned_obj+1] = obj.id

, то после тех же действий получаем мёртвый завис и такое в логе

Зацикливается походу на этом коде

388      -- экстренный спаун минимального количества объектов
389      if table.getn(self.spawned_obj) < self.min_count then 
390        while table.getn(self.spawned_obj) < self.min_count do
391          --sak.dbglog("RESPAWN: [%s] very small object", tostring(self:name()))
392          if self:create(100) == false then
393            return
394          end
395        end
396        return
397      end

Спасибо за подсказку. Я об этом догадывался. И думаю, что причина в нестыковке table.getn с новым способом вставки в таблицу. Сейчас заменю table.getn на # и проверю. Эта мысль пришла вот только что. sapsan

Изменено 7 Июля 2010 пользователем sapsan

[Kolmogor 5]

kamikazze,

Почему не меняется? Меняется - в таблицу добавляется элемент в функции se_respawn:create

По-моему нормальный цикл - собственно этот цикл еще с оригинальной ТЧ идет

Единственное изменение написано выше(заменен table.insert(t, el) на t[#t+1] = el)

 

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

 

Ну и кстати, я по-моему понял в сталкер старый луа, где getn сделан через внутреннюю переменную n у таблицы.

table.insert ее меняет, а t[#t+1] = el не меняет

 

sapsan, если интересно, добавь вывод в лог еще self.spawned_obj.n

и верни назад все table.insert

 

А если не вернуть, а заменить table.getn() на #. Этого будет не достаточно ? sapsan

По идее на table.remove еще можно нарваться - она по той же идее смотрит на переменную n и должна считать таблицу пустой

То есть table.remove(t, pos) надо заменять на t[pos] = nil

 

Мне просто кажется:

table.insert, table.remove, table.getn и таблицы-массивы отдельно(здесь именно такая)

и таблицы-словари с ключами отдельно

 

Хотя может и наоборот уйти ото всех функций table.*

Изменено 7 Июля 2010 пользователем Kolmogor

[Kolmogor 5]

Далее, присваивание нила элементу таблицы - фэйловая вещь, поскольку не высвобождается память, не уменьшается длина таблицы - а нам ведь надо побыстрее в цикле ее прокрутить потом.

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

Таблицы в луа - это не то же самое, что массивы в с++, это скорее как std::map в с++. Поэтому присваивание нила - освобождает память и уменьшает длину таблицы. Ведь если присвоить нил и перебрать всю таблицу, то нилового значения там не будет

 

2All

Вообще, по-моему, наблюдается слабое понимание таблиц и функций table.*

 

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

 

Оператор # возвращает не длину таблицы Он возвращает номер элемента после которого идет nil. То есть в частном случае когда в таблице нилов нет, вернется длина таблицы. В общем, как только начали баловаться присвоением нилов, вернет длину до первого нила. Это по документации было На практике по-другому

 

функции table.insert, table.getn, table.remove и прочие полагают, что таблица используется как массив, то есть ключом является целое число, в значениях ключа нет пропусков.

table.getn

Вот ее код на луа(взято с http://luagml.ucoz.ru/doc/lua/c5.html):

function getn (t)
  if type(t.n) == "number" then return t.n end
  local max = 0
  for i, _ in t do
    if type(i) == "number" and i>max then max=i end
  end
  return max
end

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

 

table.insert

Код:

function tinsert (t, ...)
  local pos, value
  local n = getn(t)
  if arg.n == 1 then pos, value = n+1, arg[1]
  else pos, value = arg[1], arg[2]
  end
  t.n = n+1;
  for i=n,pos,-1 do
    t[i+1] = t[i]
  end
  t[pos] = value
end

При вставке в середину сдвигает хвост и увеличивает внутреннюю длину таблицы n

 

table.remove

function tremove (t, pos)
  local n = getn(t)
  if n<=0 then
     return
  end
  pos = pos or n
  local value = t[pos]
  for i=pos,n-1 do
    t[i] = t[i+1]
  end
  t[n] = nil
  t.n = n-1
  return value
end

При удалении элемента, оставшиеся сдвигаются, чтобы не было пробелов. И уменьшает внутренню длину таблицы n

 

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

Изменено 12 Июля 2010 пользователем Kolmogor

[Kolmogor 5]

sapsan,

Странный лог Почему t, а не t1

! Cannot find saved game ~~~ testtables table.getn(t): 1

! Cannot find saved game ~~~ testtables #t: 2

! Cannot find saved game ~~~ testtables t.n: 1

Лог поправил. Там лишнее было. sapsan

 

устарелоСейчас сам поэкспериментировал: никакого внутреннего n нет по-видимому - table.getn всегда пробегается по таблице и возвращает наибольшее значение ключа(если занилить последний элемент, то вернет на единицу меньшее значение). #t у меня всегда равна table.getn(t) Если не используешь вставку t[#t+1] = 1 sapsan

 

Еще поэкспериментировал Последние данные такие:

- table.insert и table.remove заводят внутреннюю переменную, в которой хранят длину таблицы(ее имя то ли не n, то ли она не доступна из скрипта). table.getn, если эта переменная есть, выдает ее значение, если нет, перебирает таблицу и возращает максимальный ключ.

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

 

Утряски и не должно было быть. Утряска будет, если пользоваться table.remove

 

kamikazze,

проверил на ТЧ 4 и 6 патчи, ЗП ведет себя одинаково, как в этом посте выше написал

Изменено 12 Июля 2010 пользователем Kolmogor

[Kolmogor 5]

Shadowman,

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

Ну и кстати в подчищенном движке ЗП это сообщение убрали

* t-report - base: 1624, 771224 K

* t-report - lmap: 20, 20482 K

Сообщения нет.

Как соблюсти написано в: Reduce pixel density (worse) or use more vertex lighting (better). Компилировать карту с другими настройками. Но совершенно не нужно.

 

[Kolmogor 5]

Arhara,

начал сейчас новую игру в ТЧ на статике. Кордон. В логе:

* t-report - base: 866, 249933 K

* t-report - lmap: 10, 10241 K

***FATAL***: Too many lmap-textures (limit: 8 textures or 32M).

Reduce pixel density (worse) or use more vertex lighting (better).

Собственно столько в папке levels\l01_escape файлов lmap*.dds. Сходится как по количеству, так и по размеру

Изменено 18 Октября 2010 пользователем Kolmogor

[Kolmogor 5]

1. Все лайтмапы используются только на статике, на динамике используется гораздо меньше.

 

2. Никакими модами, ни каким подключением новых локаций количество используемых лайтмапов на старых локациях не изменить. Как кордон скомпилировали на 10 лайтмапов, так он и будет использовать 10. Можно открыть папку локации в levels и посмотреть сколько лайтмапов для каждого уровня. Именно столько и выведется в логе на статике

 

3. Никакой предельно-допустимой нагрузки для движка нет. Или, по крайней мере, она гораздо больше 8 текстур и 32Мб. Эта проверка осталась с двухтысячных годов, а сейчас производительность видеокарт выросла на порядки. В большинстве уровней ТЧ используется больше 8 лайтмапов, на станции 2 используется 18 лайтмапов.

 

[spoiler=Можно провести стресс-тест ]Есть скомпиленный ацтек под ТЧ: у него 222 лайтмапа на 222Мб !!! Обращаться к D1mon`у

 

 

Просьба: на офф. форуме и на геминаторе ссылки на правленные xrRender_R2.dll устарели - можно перезалить? Хочется пощупать плотность травы.

Лучше спроси на этих форумах - у меня нет этих дллек

[Kolmogor 5]

Я пытался в СДК в ogf модели непися убрать наличие бампов текстур, но сравнение файлов через тотал командер показало, что файлы идентичны, т.е. информации о бампах в модели ogf либо нет, либо я некорректно провел импорт-экспорт, либо "тонкая" настройка делается в 3D редакторе и утилитами Bardak не учитывается.

Бамп прописывается в thm или в textures.ltx