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

Язык Lua. Общие вопросы программирования


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

С чего начинать и где взять.

 

Установка Lua:
http://www.amk-team.ru/forum/index.php?showtopic=11584&p=629106

 

Руководство «Программирование на языке Lua», третье издание:
http://www.amk-team.ru/forum/index.php?showtopic=11584&p=905308

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

(по следам ранее опудликованного)

"Упаковка таблицы в строку (стринг) и обратная распаковка"

 

Доработанный вариант с возможностью проверки в SciTE:

  комплект функций и краткое описание: (Показать)
Изменено пользователем Artos

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

Ссылка на комментарий
  malandrinus писал(а):
...т.е. для запуска надо нажать F5 или такую зелёную кнопочку со стрелочкой вправо на тулбаре, или из меню "Tools" выполнить команду "Go". Я правильно понял? =)

Из меня писатель не лучший чем, скажем, программист. :-(

Когда начинал описание, думал упомянуть и туллбар. Пока дошёл - забыл.

Все описания, что я пишу и хочу написать, основаны на собранных по крохам информации из НЕТ-а и собственных исследованиях.

Поэтому никакой гарантии в плане абсолютной достоверности и правильности "подачи" не даю. Это все-лишь моё понимание.

Я выкладываю эту информацию как макет, в надежде на участие сообщества в приведении её к более полному, достоверному и "читабельному" виду, такому, чтобы наконец собрать всё до кучи и поместить в шапку темы (зачистив при этом посты с процессом поиска и исследования).

Так что не стесняемся высказывать своё мнение, знания и (malandrinus-у) редактировать неверные позиции.:-)

 

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

Хочу залезть глубоко в недра своего виртуального справочника, и показать как хотелось бы сделать описания. К примеру возьму функцию pairs, тем более что уже возникали вопросы по её использованию.

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

  pairs (Показать)
Изменено пользователем Gun12
Ссылка на комментарий

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

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

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

Я поступил следующим образом:

в bind_stalker-e в функции actor_binder:update(delta) вызываю свой апдейтер

twoteam.actor_update(self, delta)

А сам апдейтер организую таким образом

local time_100 = 0
local time_300 = 0
local time_1200 = 0
local time_5000 = 0

function actor_update(actor, delta)
--- Действия, которые надо производить с частотой fps

    time_100 = time_100 + delta
    if time_100 > 100 then
    --- Действия, которые надо производить с частотой раз в 100мс

    time_100 = 0
    end
    time_300 = time_300 + delta
    if time_300 > 300 then
    --- Действия, которые надо производить с частотой раз в 300мс

    time_180 = 0
    end
    time_1200 = time_1200 + delta
    if time_1200 > 1200 then
    --- Действия, которые надо производить с частотой раз в 1200мс

    time_1200 = 0
    end
    time_5000 = time_5000 + delta
    if time_5000 > 5000 then
    --- Действия, которые надо производить с частотой раз в 5 секунд

    time_5000 = 0
    end
end

Какие периоды срабатывания ставить, и сколько делать таких под-апдейтеров, каждый сам для себя решит исходя из практических целей. Плюс в том, что какое-то ресурсоемкое действие можно поставить, скажем, в обработку раз в 1200 мс. Допустим оно занимает 100 мс. Оно будет выполнено, несущественно повлияв на производительность (снижение среднего fps менее 10%). А если бы мы поставили это действие прямо в "родной" апдейт, получили бы fps = 10 или менее. А это уже на грани неиграбельности, согласитесь :)

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

  p.s. по поводу первых полутора-двух страниц (Показать)
  • Нравится 1

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

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

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

Ссылка на комментарий
  Zander_driver писал(а):
...пока большая часть темы представляет практический интерес не для всех, кто считает себя скриптерами...

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

Например мне в ЛС задают вопросы, и я прошу задавать их в этом топике. Но то ли стесняются, то ли ...? Не знаю. Если бы была способность предугадывать желания, то я сменил бы профессию :-)

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

Zander_driver

1. Плз, длинные портянки кодов стОит прятать под спойлеры (ИМХО).

2.

  Цитата
Zander_driver: Может быть, это будет из разряда "Капитан очевидность рекомендует", но я своих методов в других модах пока не встретил, так что думаю начинающим скриптерам будет полезно.

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

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

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

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

  вариант 'елочка (Показать)
Изменено пользователем Artos

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

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

Artos

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

А за поправки и уточнения спасибо :)

Вариант "елочка" довольно интересен, но, с другой стороны, когда допустим будут выполнены действия 1200 мс, то и 300мс, и 100мс будут выполнены в тот же такт. А это уже может привести к изрядному подвисанию, если там что-то тяжелое. Несколько независимых таймеров можно подстроить так, что их частоты не будут кратны друг другу. Например, 100мс, 260, 1170, и т.д.. нагрузка на цп будет распределяться равномернее. А в варианте "елочка" пики нагрузки неизбежны.

 

  Ремарки (Показать)
Изменено пользователем Zander_driver

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

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

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

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

Zander_driver: Ну насчет того, что мой пост был бы уместнее "Скриптовании", поспорю

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

Твои же слова из того же поста: "Да, к Lua это отношения не имеет никакого. Я применял точно такой же прием, когда писал код в Delphi." - сводят на нет твои же "аргументы" и только подтверждают вышесказанное.

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

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

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

 

По сути твоих рассуждений по таймерам:

Не хочу обидеть, конечно, но ... давая советы 'начинающим скриптерам', ты сам недалеко от них отошел и набрав немного навыков/опыта, так и не снял шоры на многое.

  Цитата
Zander_driver: Вариант "елочка" довольно интересен, но, с другой стороны, когда допустим будут выполнены действия 1200 мс, то и 300мс, и 100мс будут выполнены в тот же такт. А это уже может привести к изрядному подвисанию, если там что-то тяжелое. Несколько независимых таймеров можно подстроить так, что их частоты не будут кратны друг другу. Например, 100мс, 260, 1170, и т.д.. нагрузка на цп будет распределяться равномернее.
Хорошо, что все же заметил этот недостаток, хотя при более внимательном чтении о нем же уже было сказано:
  Цитата
Artos: А один из основных недостатков и твой и 1-й вариант не решают. Все одно все 'тяжелые' скрипты/алгоритмы будут выполняться единомоментно - а значит будут лаги.

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

Жаль не заметил слов 'и твой', читать нужно внимательнее.

Все твои таймеры имеют одну и ту же стартовую установку (0) Это означает, что ВСЕ они работают СИНХРОННО, и когда сработает таймер 1200, в это же время сработает и таймер 300 и таймер 100.

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

Заинтересовавший тебя вариант "елочка" НИЧЕМ не отличается от твоего же, только оптимизирован с целью исключения лишник операция по сложению и сравнению. Твой вариант точно также будет запускать все вызовы так же как и "елочка", т.е. единовременно.

Итого, если хочешь получить независимые (ассинхронные) таймеры следует сделать что-то типа:

  ассинхронные таймеры (Показать)
Изменено пользователем Artos

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

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

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

  Полезный утиль (Показать)
Ссылка на комментарий

Все дейстия можно разделить на группы:

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

б) - постоянно требующие проверок условий/вызовов на протяжении игры, но на конкретной локации (группе локаций);

в) - требующие непрерывных проверок условий/вызовов до или после некоего события (например инфопоршня);

г) - требующие разовой проверки условий/вызовов после некоего события и до другого события;

...

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

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

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

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

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

Известно, что разработчики по сути кастрировали вывод информационных сообщений из скриптов. Разработка, отладка, поиск ошибок без подобной информации затруднителен. Начинающие модмейкеры порой и не догадываются о полезности вывода в лог удобных сообщений при модификациях кодов.

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

 

Итак критерии: 1. - надежность (безопасность) кода, 2. - информативность и 3. - производительность.

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

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

3. Вывод в лог и получение его в лог-файле должен по-возможности не приводить к значительным лагам в игре.

 

Предлагаю рабочий вариант комплекта функций для вывода в лог (лог-файл):

  комплект функций: (Показать)
Изменено пользователем Artos

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

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

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

 

Artos.

  Ошибочку у вас нашел (Показать)

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

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

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

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

Zander_driver

Начну с конца, хоть это не совсем оффтопик, т.к. касается любой темы:

  Раскрывающийся текст (Показать)
Изменено пользователем kokkai

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

Ссылка на комментарий
  malandrinus писал(а):
Теоретически, поскольку Lua в составе сталкера сделан в виде динамической библиотеки, то можно пересобрать эту библиотеку из исходников и добавить туда то, чего не хватает.

 

Пытался, не прокатило, но только потому, что я не включил в него luabind.

В принципе, есть вероятность что разработчики движка дописать какое-то API сами, но если нет, то в результате, после подключения luabind, должно работать.

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

Один хороший товарищ уже всё подключил к ТЧ. Luа в полном составе и работает. Сейчас тестируем.

Только вот не стоит забывать, что функции dеbug,* изначально работают значительно медленнее стандартных. Даже JIТ особо не поможет.

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

Gun12,

  Цитата
Один хороший товарищ уже всё подключил к ТЧ. Luа в полном составе и работает.

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

  Полезный утиль (Показать)
Ссылка на комментарий

Не я автор.

Поделиться не позволяют морально-этические.

Как только "хозяин" решит, то сам и выложит. Сорри.

 

Ну так а какой глубокий смысл тогда был об этом сообщать?

 

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

Какой смысл?

Были сомнения по поводу нужности этой работы.

Видим что нужно.

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

а читать сообщение до конца никто не пробовал?:)

  Цитата
Сейчас тестируем

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

Vita sine libertate, nihil

Vita sine litteris - mors est

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

RvP, а не проще тестировать не в 'две руки'? Как грится ... одна голова хорошо, две - лучше, но и другие не помешают. ;-)

Ведь это же не мод, в котором поигральщики от глюков сопли распускают, а инструментарий для ...

(сорри за оффтопик)

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

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

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

RvP, а ты не заметил что 'две руки' - в кавычках, да еще и прописью? Все же это не информация и не констатация некоего факта, а образное выражение. Как, в прочем, и про головы ...

 

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

Ну да ... ежели нет желания/потребности, то и не настаиваем и не навязываем(ся). :-)

[x]

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

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

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

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

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

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

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

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

Войти

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

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

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