Язык 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]

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

А пример я приводила как вариант замены твоим любимым 'uo' - вместо пачки переменных один объект-функтор. А) данные никак случайно не потеряешь, Б) защищены от изменения извне.

Для организации различных колбеков связка "безымянная функция + замыкание" вообще полезна очень. И не говори, что это теория. Это из практики. Все зависит от того, что ты хочешь реализовать.

А что касается "изюминки" - так в этом и есть суть топика: чем больше приемов знаешь, тем более эффективно можешь писать код. Пример один я привела.

 

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

dialog_functions.mega_dialog_1_rpg_precond = function () 
    ...
end

в файле dialog_functions функция mega_dialog_1_rpg_precond заменяется на другую.

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

 

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

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

[Artos 99]

xStream,

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

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

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

По "изюминкам":

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

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

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

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

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

 

По 'uo': любовь к этому варианту привили как раз АМК-коды ;-), но, по большому счету, вообще то не очень то мною любимы (именно в форме разно-колличественных кучек значений), т.к. по-возможности я их переделывал в таблицы с нужыми по-случаю параметрами. Так что, то, что ты сейчас называешь 'заменой пачки', собственно уже ранее в плоском коде было оформлено во многих вариантах как массив. сейчас мне очень просто было портировать все это под ООП.

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

 

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

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

 

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

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

[xStream 86]

Хочу только одно сказать: ты мне пытаешься приписать категоричность утверждений. Например про "защиту" переменных. Это неправда. Я просто перечисляю все вытекающие последствия при таком подходе. И пожалуйста, давай не будем вспоминать, что АМК (ввели эту хрень как раз мы с Ред75) используют юзер-обжекты. Ибо это было давно и мы ведь как раз говорим об уходе от старых решений, громоздких, как паровая машина на фоне ДВС или дизеля. При любом раскладе функторы компактнее, лаконичнее и удобнее, чем массивы и организация синхронизации этих самых юзер-обжектов.

 

Остальное не буду комментировать, ибо это возвращение к закрытой теме.

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

[Artos 99]

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

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

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

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

 

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

Хотел бы опять уточнить небольшой момент по применению выбранного варианта получения идентификаторов для реализации в таймерах:

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

Ведь этот вариант вполне пригоден:

timers_holder = {}

function check_timers(e)
  for _,tmr in pairs(timers_holder) do
    if t.trigger_time and t.trigger_time <= time_global() then
      event("timer_"..t.id):trigger()
    end
  end
end

--/ ---------------
class "timer"
--/ ---------------
function timer:__init()
  self.__once = true
  self.id = self:gen_id()
  timers_holder[self.id] = self
end

function timer:gen_id()
  local id = 1
  while timers_holder[id] ~= nil do
    id = id +1
  end
  return id --/> текущий индекс (для имени таймера)
end

...

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

Или я опять некий нюанс упускаю? (не считая небольшой потери производительности при выборе очередного идентификатора)

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

[kamikazze 266]

Artos

 

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

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

 

Во-первых, не в каждый вызов, а только в те что на апдейте - их на самом деле никогда не бывает особо много. Во-вторых, это у нас уже реализовано ещё с версии 0692 было без всяких евентов. А с евентами это реализуется просто до ужаса, Артос. Берется обработчик евента апдейта в скрипте, в самое его начало ставится увеличение счетчика на 1. А после него - деление величины счетчика на нужное число. Если делится без остатка - прогоняем, если нет - return. Настройка частоты прогона производится легко и непринуждённо сменой делителя, сам код - две строки. Можно этот малюсенький код в функцию выделить и проверять вернёт она true или false. И всё. Ничего не надо ни изобретать ни перестраивать. Какие события должны быть на каждом апдейте - там не ставим сей код. Где надо ставим и настраиваем делитель. И никаких заумных "распределений по времени" с помощью единого "счетчика-распределителя". Тебе же нужно будет ещё и неписям апдейт распределить и монстрам (это кстати гораздо сильнее разгрузит игру чем актор). И что, под каждый поток евентов ты собираешься мастырить отдельный диспетчер с рассчетом времени исполнения и динамической регистрацией/отрегистрацией? А не боишься что итоге этот твой диспетчер будет работать медленнее самих событий? И что в отладке утонуть будет просто можно.

 

P.S.

 

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

 

 

[xStream 86]

2Artos

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

Все

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

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

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

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

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

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

[Artos 99]

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

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

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

[xStream 86]

Строчные ключи для "страховки". Специфика работы ЛУА... (изначально я реализовывала на table.remove, а это приводит к перенумерации числовых индексов) Я перестраховалась в данном случае. Вот откуда строковые ключи.

Цели примера: таймеры как объекты (ну не нужны им методы ивентов, не соглашусь с тобой, хоть убей), вложенные события - одни "выстреливают" другие, безымянные функции и замыкания (в принципе функторы - см. переменную local proxy = self и колбек с использованием этой переменной).

 

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

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

[Artos 99]

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

Ну а по производительности - то как раз почему же примеров нет. ;-)

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

Взять тот же цикл для примера и представить что таймеров не один десяток/сотня:

function check_timers(e)
  for _,tmr in pairs(timers_holder) do
    if t.trigger_time and t.trigger_time <= time_global() then
      event("timer_"..t.id):trigger()
    end
  end
end

получаем, что все таймеры перепроверяются на достижение своего зачения.

На СП это уже обсуждалось и Gun12 тогда заметил (общий смысл): "А зачем каждый раз проверять все? Не достаточно ли вычислить ближайщее и ждать его? После чего определять следующее ближайшее и т.д.".

Этот вариант и реализован и вполне неплох. Так что экономить стОит и в таких мелочах (ИМХО).

Вот пример для указанного случая:

local nearest_time = nil

function check_timers(e)
  if nearest_time ~= nil then
    local current_time = time_global()
    if current_time <= nearest_time then
      nearest_time = nil
      for _,tmr in pairs(timers_holder) do
        if t.trigger_time then
          if t.trigger_time <= current_time then
            event("timer_"..t.id):trigger()
          elseif t.trigger_time < (nearest_time or 9^9) then
            nearest_time = t.trigger_time
          end
        end
      end
    end
  end
end

--/ ---------------
class "timer"
--/ ---------------
function timer:__init()
  self.__once = true
  self.id = self:gen_id()
  timers_holder[self.id] = self
end

function timer:gen_id()
  local id = 1
  while timers_holder[id] ~= nil do
    id = id +1
  end
  return id --/> текущий индекс (для имени таймера)
end

function timer:run(time_seconds)
  if self.trigger_time then
    return
  end
  nearest_time = 0 --/ reset!
  ...

 

Примечание: Тот же ранее приведенный пример с распределенным 1-о секундным апдейтом - из разряда аналогичных мелких оптимизаторов.

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

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

[xStream 86]

Не надо пример с таймерами брать как жизненный, плиз :-D На то и пример, написанный за 10 минут, доведенный до рабочего состояния более-менее и имеющий чисто академическое назначение.

А в остальном я согласна - бесполезно, хотя это и очень важный вопрос.

[Artos 99]

(обновил верхний пост, т.к. не успел до падения форума подправить)

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

 

Кстати, думаю, что такие примеры тоже служат помимо хорошего дела и ... в виде медвежьей услуги. Поясню: ведь немало тех, кто заглянув и мало что поняв, хватают вот такие упрощенные коды и начинают их вовсю использовать ... У них заимствуют другие и ... так и расползаются технологические примеры-времянки в моды. :-(

 

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

P.S. Что-то у нас достаточно беспредметный разговор пошел ... Вроде как о важном/нужном, но ... только об общем. :-(

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

Брать чьи-то давно вышедшие коды/моды - наверное достаточно буссмысленно. Ну так и давайте говоить о текущих!

Что мешает выкладывать на разбор полетов наработки? Мои текущие коды-наработки постоянно доступны и актуализируются не реже раза в месяц. Что мешает взять их в качестве примеров и врезать по полной программе за гриворукость иль за разгильдяйство? :-)

Что мешает выложить вам (вроде как и kamikazze сюда заглядывает и кидает реплики) выложить для обсуждения то, что отнисится к теме? Хотя бы ту же песочницу, чтобы не голословно утверждать иль намекать, а получить по полной программе за хороший иль корявый алгоритм? ;-) Вот и будет и тема и реальные примеры ...

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

[Artos 99]

kamikazze,

Вот никак уже полдня не могу понять как относиться к твоим словам:

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

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

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

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

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

И при чем тут распределение апдейтов неписям? У тебя что на их апдейты и общие таймеры понавешаны и иные обще-игровые коллбэки?

Вот тут то как раз разумна аналогия с котлетами и мухами. Именно апдейт актора нуждается в максимальном внимании и максимальной разгрузке.

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

 

 

[kamikazze 266]

Artos

 

 

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

 

А у нас ещё и штатом тестеров проверяется, потому что не даёт самостоятельное тестирование адекватного результата, он не репрезентативен.

 

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

 

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

 

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

 

Никакого "устраивает" или не "устраивает", Артос. Мы не NLC делаем, которое не мод, а арт-объект, который нельзя трогать, в который ни в коем случае нельзя играть, потому что это искусство - им надо любоваться, восхищаясь замыслом и видением художников. Я просто очень прагматичен в коддинге. Дело не в тиражировании и не в личных предпочтениях. Если есть два пути - первый это небольшой копипаст, зато кода минимум, он быстр и прост настолько насколько это вообще возможно, и второй - это огромная обработка с регистрациями/отрегистрациями и тому подобным барахлом - я выберу первый вариант. Потому что скорость его работы будет в 100-200 раз быстрее чем второго, это раз и он избавит от излишка писанного кода, это два. Голый рационализм.

 

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

 

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

 

В качестве простого примера - помнишь тогда разошлись в подходах на менеджер вооружений, с потерей оружия. Ты тогда начал изобретать телепорты ящиков с оружием и т.п. Я это решение сразу отмел как нерациональное и чересчур громоздкое. Так вот, я таки переделал менеджер. Теперь он вообще не использует ящики, совсем. И в нём нет ни одного оператора трансфера вещей, а сам код похудел на 30%. Итого - пропали вылеты e_parent && e_entity, скорость работы менеджера выросла в разы, все косяки с пропажей оружия решились. Всё это с полным сохранением функционала, ничего не отрезалось, работает всё отлично.

 

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

 

Мне это вообще сейчас делать не нужно, у нас по факту вообще всё сейчас отлаживается автоматически.

 

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

 

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

 

И при чем тут распределение апдейтов неписям? У тебя что на их апдейты и общие таймеры понавешаны и иные обще-игровые коллбэки?

Вот тут то как раз разумна аналогия с котлетами и мухами. Именно апдейт актора нуждается в максимальном внимании и максимальной разгрузке.

 

Артос, биндер актора в игре ОДИН! А у неписей - у каждого по личной копии биндера. Личной, отдельной. Каждый апдейт запускающейся. Ты об этом не задумывался, не? Я когда ввёл распределение нагрузки для биндеров неписей, быстродействие игры выросло на 30%. Хотя там было всего 6 добавленных вызовов в этом биндере, не больше. На базе Свободы на АС, где до этой операции фпс на мощной машине держался в районе 25-27 кадров с секунду, резким скачком вырос до 35-37. Это всего лишь было сделано распределение нагрузки на биндер неписей. Аналогичное действие с биндером актора дало не более 10% прироста скорости. Хотя в нём намного больше вызовов. Вот и думай теперь. Ты за своим "максимальным вниманием" не видишь очевиднейших вещей.

 

И если для тебя, вероятно, решение с ивентами стало откровением и ты до сих пор в восторге от него, то я уже несколько лет использую, если и не ООП исполнение этого алгоритма, но на 90% схожее с ним и наработал опыт и по производительности и по отладке.

 

Какое там откровение, подобная реализация в очень примитивном виде ещё в АМК была. Я её не использовал потому, что не-ООПшная её версия меня как-то ну вообще не радует и ни малейшего энтузиазма не вызывает. Ибо рогло унылое.

 

 

 

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

[xStream 86]

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

Ладно, скатываюсь в оффтоп. Пойду к НГ готовиться, чего и вам желаю.

[Artos 99]

kamikazze, жаль, что все еще продолжаем достаточно беспредметный разговор на отвлеченные темы ... :-(

1. Что мешает тебе выложить свой вариант решения (если нашел изюминку) для других и сравнить/указать на недостатки иных?

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

Вот то, чем пользуюсь касательно IsStalker и пр.:

  tStalkerClasses = {
    [clsid.stalker]              = true,
    [clsid.script_stalker]       = true,
    [clsid.actor]                = true
    --[clsid.script_actor]         = true --/ STCS|SCoP
  }
  tMonsterClasses = {
    [clsid.bloodsucker_s]        = true,
    [clsid.boar_s]               = true,
    [clsid.burer_s]              = true,
    [clsid.cat_s]                = true,
    [clsid.chimera_s]            = true,
    [clsid.controller_s]         = true,
    --[clsid.crow_]                = true, --/#?#
    [clsid.dog_s]                = true,
    [clsid.flesh_s]              = true,
    [clsid.fracture_s]           = true,
    [clsid.gigant_s]             = true,
    [clsid.poltergeist_s]        = true,
    --[clsid.pseudo_gigant]        = true, --/#?#
    [clsid.pseudodog_s]          = true,
    --[clsid.psy_dog_phantom_s]    = true, --/#?#
    [clsid.psy_dog_s]            = true,
    [clsid.rat]                  = true, --/#+# SM_RAT
    [clsid.psy_dog_s]            = true,
    [clsid.snork_s]              = true,
    [clsid.tushkano_s]           = true,
    [clsid.zombie_s]             = true
  }

function get_clsid(obj)
  return obj and obj.clsid and obj:clsid() --/> iClassId
end

function IsStalker(object, iClassId)
  return tStalkerClasses[iClassId or get_clsid(object) or -1] == true
end
function IsMonster(object, iClassId)
  return tMonsterClasses[iClassId or get_clsid(object) or -1] == true
end

просвяти нас по "фишке", плз.

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

 

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

О какой непрезентабельности тестирования не "штатными тестерами" ты гутаришь?

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

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

У меня и не было ранее ошибок в менеджере оружия по парентам. И "ящик" у меня используется не столь для оружейного менеджера, сколь для иных алгоритмов и именно это так же снижает и затраты на коды/ресурсы и позволяет использовать отлаженные наработанные моменты не только в одном месте.

 

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

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

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

Обсуждать то, чего не знаю или осуждать/критиковать то, чего не видел - пустословие и критиканство ...

 

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

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

[kamikazze 266]

Artos

 

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

 

Вот то, чем пользуюсь касательно IsStalker и пр.

 

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

 

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

 

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

 

О какой непрезентабельности тестирования не "штатными тестерами" ты гутаришь?

 

Да банально... Артос, тестер это тоже профессия на которую нужен талант и навыки. У нас нехилый отбор в тестерскую команду, и ребята реально полезны. Плюс я точно уверен что у них всё в порядке с железом, машины не населены зверьём и результат не зависит от посторонних факторов. Простые юзеры тебе не дадут вменяемых результатов. В лучшем случае от них можно дождаться отчета в стиле "как-то медленно" или "стало лучше". Штатному тестеру не надо расставлять счетчики - я ему сам выдаю отладочный пакет с заданием на тестирование, он тестирует и скидывает мне аккуратные результаты.

 

У меня и не было ранее ошибок в менеджере оружия по парентам.

 

Они там by design эти вылеты. Их можно победить опять же как двумя путями - нагородить кучу кода, либо использовать иной алгоритм, о котором Бак был не в курсе когда менеджер писал. Во втором случае всё очень сильно упрощается и сильно растёт производительность. Если ты использовал это добро с ящиками в другом месте с допиленной скриптовой обвязкой - ну что делать, пусть остаётся. Но я попозже зарелижу переделанный менеджер вооружений - оно того стоит, народу пригодится.

 

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

 

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

 

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

 

Артос, если бы меня душила жаба за сырцы, то OGSE и компаньоны были бы вообще в компилированном байткоде Lua Я просто никогда не раскрываю разрабатываемый код - с проблемами в нём я могу в 99% случаев разобраться самостоятельно, а подкидывать лишние грабли народу ни к чему. Мне пока вообще не до песочниц... я сейчас вообще другим занят - создал на основе старого скрипта очень удобный инструмент - практически полный визуальный отладчик неписей - и отладил полностью стейтменеджер, а так же схему реакции на опасности. Итого победились (тьфу-тьфу) все родные проблемы игры с затупливанием неписей в одну точку после боя, с шухером по непонятным причинам, зависаниям схем поведения и тому подобной хренью. Впечатление теперь такое будто играешь в совершенно новую игру, настолько непривычно.

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

[Artos 99]

kamikazze, посмотри на название/шапку темы!

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

Никому (кроме нас с тобою) не интересны неинформативные реплики "правильно иль неправильно", интересен сам код + комменты что и где правильно или что плохо и как это исправить!

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

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

Давай давать комментарии по сути кодов, а не реплики "хорошо/плохо" ...

 

Ну и вот опять пошла демагогия:

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

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

 

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

 

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

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

Что мешает приводить не целые модули, а только выжимки из них?

Ну а без этого - весь разговор напоминает или похвалбушками или критиканство.

... работает над тем чтобы совместить плюсы первой и второй и сделать единую. Пока оно не будет готово ещё нет смысла спорить особо.

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

Если цель застолбить за собою и зазвездиться - то опять зачем тут эти разговоры?

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

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

kamikazze: то OGSE и компаньоны были бы вообще в компилированном байткоде Lua

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

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

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

 

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

[Nazgool 250]

Поздравляю всех с Новым Годом.

2Artos

По поводу упомянутых тобою таймеров - есть дополнения и улучшения.

На днях выложу (когда приду в сознание).

[Viнt@rь 50]

Возможно не в тему пишу(не в тему обсуждения), но все же хотел узнать, xStream, согласен с тобой, возможно АМК 2.0, как ты выразилась, "говно", но все же скрипты там довольно интересные, вот собственно по этому и спрашиваю, если писать скрипты-схемы организовывая их классами(на подобии АМК 2.0) это влияет на производительность и тп, если влияет, то чем, и как именно? Заранее спасибо...

Изменено 1 Января 2012 пользователем Viнt@rь

[xStream 86]

К АМК 2.0 я не имею никакого отношения. Однако скрипты в нем, "переписанные с нуля", чуть более чем полностью такие же по сути, как в 1.4. Однако за 2.0 я ответственности не несу

 

На производительность, не важно в каком моде, при ОО подходе затраты идут на создание объектов. Но, зачастую, эти накладные расходы ничто по сравнению с временем выполнения рабочего кода. Главное не делать цикл на 100к итерций и не создавать там объектов Это раз.

 

В АМК 2.0 то, что я раньше по топику называла псевдо-ооп. Это когда набор функций объединяют внутри класса. По сути толку от этого ноль целых ноль десятых. Так как эти псевдо-объекты не используются в сочетании с другими, как аргументы методов других классов, хотя бы. Это все тот же старый добрый процедурный подход. Это два.

 

Вывод - как в АМК 2.0 делать не надо. Надо знать ООП, а это уже явно выходит не только за пределы топика, но и форума

Изменено 1 Января 2012 пользователем xStream