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

[Dennis_Chikin 3 658]

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

 

Установка 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

Изменено 2 Марта 2015 пользователем Kirgudu

[xStream 86]

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

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

 

Еще раз - ООП вполне рулит. И не надо утверждать, что никак не уйти. Это ты так реализовал, но это далеко не истина и не оптимальное решение.

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

Переделать тот код, что я в качестве примера привела - очень просто. Надо только мыслить в соответствующем ключе.

 

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

 

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

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

[Artos 99]

Вопрос - зачем ты тогда вообще взял эту песочницу, если все равно приводишь ее к процедурному виду?

1. Уже писал, что давно намеревался то, что уже наработано было в моде перевести на класс ... т.е. сделать каркас мода на базе ООП.

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

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

 

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

 

И мен непонятно, о чем му уже ...? О моих неправильных и закостенелых кучерявостях или о том, что и как можно делать с кодами в Lua?

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

А уж у кого лучшЕе - это уже те, кто играет в игру/моды судят.

 

 

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

Под "чистой наукой" имел ввиду в данном случае твое навязывание испльзовать концепт песочницы в чистом виде и не более ...

Или же мне отказаться от ее использования раз так "изгаляюсь" над ней? (это вопрос и хотел бы получить ответ)

Изменено 27 Декабря 2011 пользователем Artos

[xStream 86]

Зачем тебе каркас на базе ООП, если ты ООП не используешь?

 

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

Да, я навязываю, потому что это моя идея, она самодостаточна. Ты уперся лбом и не хочешь принимать идею, что не надо разные сущности объединять в одну. Потому что в результате получается каша. И проще организовывать код от этого не становится. Возвращаемся к тому, что существует уже несколько лет в сталкере - хаос в коде, зависимости и полная каша.

 

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

[kamikazze 266]

Artos

 

Никогда не был сторонником "чистой науки" - первостепенное значение имеет практическое использование и конечный результат (ИМХО).

 

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

 

[xStream 86]

Мне все равно, кто будет использовать и как.

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

[Artos 99]

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

На сим закругляю это уже оффтопик ...

С наступающими!

:-)

 

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

P.S. kamikazze,

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

И, как уже ранее говорил, привык полагаться на свои выводы и предпочтения, а не довольствоваться тем что дадено, даже если это очень "хорошая весЧь". Если мне требуется досолить иль поперчит - то не вижу в этом ничего запретного иль зазорного и своих вкусов не навязываю (как и не хулю чужие).

 

Изменено 27 Декабря 2011 пользователем Artos

[xStream 86]

Ну почему же. Я сужу по тому, что ты пишешь и выкладываешь (код). Я вполне ясно представила, каким путем ты идешь.

И это все - отнюдь не холивор. Я предприняла две попытки, аргумента, подкрепленные конкретными вещами - это разве холивор?

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

 

ЗЫ И почему это "ныне" ты не хочешь со мной холиворить?

[Artos 99]

xStream,

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

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

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

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

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

 

Изменено 27 Декабря 2011 пользователем Artos

[xStream 86]

Еще раз: я не против. Я наоборот радуюсь, если то, что я делаю, приносит пользу.

И не искажай мои слова. Чистота кода вполне уживается с его практичностью.

[Artos 99]

Если кого заинтересует и в продолжение мысли "Чистота кода вполне уживается с его практичностью":

Несколько ранее тут приводились примеры реализации распределенных обработчиков (см. #52 и ранее).

Вот практическая реализация на обсуждаемом в текущее время сэндбоксе:

1. Регистррации всех коллбэков, которые вызываются 1 раз в секуду реализуются в массив:

callbacks_recipients.update_1s = {}

2. В каждый цикл апдейта актора вызывается зарегистрированная на это событие функция OnActor_Update, которая и выполняет выбор времени срабатывания и саму функцию их массива подписанных односекундных апдейтов. Каждая из них вызывается по 1 разу в секунду и их вызов "размазан" (распределен по времени) на всю эту секунду.

--/------------------------------------------------------------------
local count_1s,index_1s = 0,0 --/ кол-во функций коллбэков и текущий индекс обрабатываемого коллбэка
local time_1s,period_1s = 0,0 --/ таймер-счетчик и период его обновления
--/ коллбэк на апдейт ГГ
function OnActor_Update(e) --/< e.time == time_global()
  --/ распределенный обработчик события 'update': вызов каждой подписанной функции 1 раз в сек
  if e.time > time_1s then --/ сверка с текущим временем
    if index_1s >= count_1s then --/ закончен цикл: переустановка
      period_1s = 1000 --/ общий период цикла таймера (1 сек)
      index_1s,count_1s = 1,#callbacks_recipients.update_1s --/ начальный индекс и кол-во вызываемых функций
      if count_1s > 1 then
        period_1s = period_1s/count_1s --/ 'распределенный' период вызова функций
      end
    else --/ продолжение цикла:
      index_1s = index_1s +1 --/ обновляем текущий индекс вызываемой функции
    end
    local tCb = callbacks_recipients.update_1s[index_1s]
    if tCb then
      table.insert(callbacks_recipients.update,{funct=OnUpdate_1s,idx=index_1s}) --/ добавляем 'прокси' обработчик события
    end
    time_1s = time_global() + period_1s --/ 'тикает' таймер
  end
end
function OnUpdate_1s(e)
  local tCb = callbacks_recipients.update_1s[e.idx]
  if tCb then
    tCb.funct(e) --/> вызов 'зарегистрированной' функции обработки события
    if e.__removeThisCallback then
      table.remove(callbacks_recipients.update_1s, e.idx) --/ remove collected callbacks from stack
      index_1s,count_1s = index_1s-1,#callbacks_recipients.update_1s --/ корректируем начальный индекс и кол-во вызываемых функций
    end
  end
  e.__removeThisCallback = true
end
--/------------------------------------------------------------------

 

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

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

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

Изменено 27 Декабря 2011 пользователем Artos

[xStream 86]

Не поняла пассажа про "в продолжение мысли "Чистота кода вполне уживается с его практичностью":"...

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

[Artos 99]

xStream,

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

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

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

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

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

Мне совершенно не хочется обсуждать чьи то вкусы или предпочтения более (не)правильные, типа кому хочется кататься на велосипедах иль заморачиваться с грейдером ... Тема форума совершенно не об этом. Есть интересная ИНФОРМАЦИЯ по кодингу для других - мне это интересно, есть вопросы - можно пообсуждать/порешать/поспорить ... а то, чем сейчас перебрасываемся - ничего не принесет, кроме потери времени и настроения и выслушивания очередных "истин".

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

 

Все, мне малость поднадоело, удаляюсь, а то ... начну парировать.

 

Изменено 27 Декабря 2011 пользователем Artos

[xStream 86]

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

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

------------------

А теперь вернемся к теме топика. В ходе ковыряния песочницы, выяснилось, что в ЛУА таки есть замыкания (closures). Это такая ситуация, что переменные, которые были "видны" при объявлении функции, могут быть в ней использованы. Кроме того - эти переменные существуют, пока на них ссылается эта функция. Очень, очень удобно.

Извини, Артос, но на примере 'uo' рассмотрю Когда надо в функции чтоб было видно переменную, объявляем ее, потом функцию и вуаля - дополнительные параметры можно в функцию не передавать. Мда... наверное, плохо объяснила.

Но вот ссылка http://www.lua.org/pil/6.1.html/ тут очень наглядно показано применение и что это вообще такое.

 

ЗЫ Мне вспомнить холивор о "вкусах", касающийся венгерской нотации? Делая замечания окружающим, в упор не видишь бревна у себя в глазу...

Изменено 27 Декабря 2011 пользователем xStream

[kamikazze 266]

Artos

 

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

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

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

 

Артос, ты чего, не в курсе чтоль? o_O Движок сталкера синхронный однопоточный. Одновременный запуск нескольких событий не может произойти физически. Никак. Никогда. Новое событие, любое, не важно чьё - непися, монстра или ГГ, стартует только после завершения предыдущего, в общей очереди. Никакого "единомоментного", и уж тем более "по паре или более" срабатывания не может быть физически. Это нонсенс. Этим своим добром ты только нагрузишь лишний раз процессор. Если хочешь сделать ниже нагрузку, просто выдели среди модулей те, которые не обязательно запускать на каждом апдейте (таких как правило очень много) и просто встрой в них счетчик пропусков. Т.е. запускать только каждый второй/третий/четвертый/энный вызов.

[Artos 99]

{последняя попытка вести конструктивное обсуждение по поднятой теме}

Но все же пару слов:

Приписывать голословно

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

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

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

Видеть в данном решении, как выразился kamikazze, велосипед - не собираюсь. Я вижу в нем очень даже грузоподъемный грузовик, который способен на перевозку достаточно объемных и многочисленных грузов. Добавить ему проходимости и адаптировать под "местные погодные условия" (да хоть на лыжи поставить) - не вижу пока никаких ограничений.

И всегда считал универсальность достоинством, а не недостатком, когда это не в ущерб функционалу и целевой задаче.

 

И я не защищаю попранную справедливость (не нужно опять высокой демагогии!), но действительно уже раздражает неуемность ваших попыток навязать свое (на веру) и охаить даже еще не видимое и не до конца высказанное.

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

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

 

 

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

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

 

 

kamikazze,

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

Под единомоментным в данном контексте подразумевается 'единой последовательной цепочкой вызовов в одном и том же цикле апдейта актора'.

Неужели совсем разучился читать код (даже не на венгерке написанный)?

Данное решение как раз и создает единый счетчик-распределитель, который ты предлагаешь встроить в каждый вызов. Мда ... уж.

Ну похвастай как это у вас на евентах реализовано, утри нос неумехе! ;-)

[x]

Изменено 27 Декабря 2011 пользователем Artos

[Valerius 31]

Сообщение от модератора Valerius

Artos, xStream, kamikazze, давайте чуть спокойней, без переходов на личности, хорошо?

[xStream 86]

Артос, припрячь ЧСВ, пожалуйста. Теме уже свернули шею.

Давай лучше вернемся к топику. Вот ты, например, пользуешься безымянными функциями? Теми же замыканиями? Кастомными классамии ООП?

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

[Artos 99]

Отвечу только в котексте того, что применимо к игре/моддингу, а не вообще ...

- безымянными пользуюсь, хотя не часто;

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

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

Слово "потребуется" наверное все же не совсем тут уместно.

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

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

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

 

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

Изменено 27 Декабря 2011 пользователем Artos

[xStream 86]

"Потребуется" было в плане обсуждения таких фич. Насколько интересные вещи можно реализовывать и т.п. Описание можно просто выложить в виде ссылок.

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

 

ЗЫ Кастомные ООП классы - я так обозначила новые классы, которые были описаны и использованы в игре НЕ АВТОРАМИ игры И которые действительно представляют собой реализацию парадигмы, а не псевдо-ООП (структурный подход), когда создается класс, а в него тупо фигачатся функции, которые в принципе можно сддеать и свободными (при таком подходе получается просто группировка функций, не более. Объекты таких классов малофункциональны сами по себе и обозначают скорее некий неймспейс)

[Artos 99]

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

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

 

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

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

Изменено 27 Декабря 2011 пользователем Artos