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

[kamikazze 266]

Венгерская нотация? Нет уже, спасибо. Артос, тут ты не прав. Это вылазит в ужасный кошмар - код нечитаем, так как постоянная смена регистра вызывает "рваное" восприятие имен, и приходится напрягаться вчитываясь в текст, чтобы осознать название переменной. Соответственно исходник непригоден для скорочтения и на его разбор уходит раз в пять больше времени, это первое. Второе - использовать венгерскую нотацию в Lua - это вообще нонсенс, так как в среде игры нет типов данных, которые бы можно было друг с другом спутать при написании кода. Третье - такие переменные очень тяжело запоминаются что вызывает необходимость часто пролистывать код, что заставляет тратить много времени впустую. Лучше сразу назвать переменную по-человечески и всё, иначе через пару часов работы с таким кодом начинает раскалываться голова просто...

 

А вот привычное se_obj или soObj - сразу бы резануло глаза и подсказало бы гнилое место ...

 

А sobj и gameobj чем неочевидны?

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

[kamikazze 266]

Artos

 

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

 

В начале - это совсем другое дело. А вот в середине, после букв указания типа в нижнем регистре - это сбивает. Всё равно если бы я написал это предложение вот так:

 

вНачале - эт оСовсе мДруго еДело

 

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

 

 

[kamikazze 266]

Artos

 

Лады, завязали по синтаксису.

 

Хотя добавить тот же 'pcall' для funct(evt) в принципе не сложно.

 

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

[kamikazze 266]

Artos

 

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

 

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

 

[kamikazze 266]

Artos

 

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

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

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

 

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

[kamikazze 266]

Artos

 

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

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

 

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

 

P.S.

 

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

 

 

[kamikazze 266]

Artos

 

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

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

 

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

 

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

 

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

 

 

 

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

[kamikazze 266]

Artos

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

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

[kamikazze 266]

Artos

 

1. Упрощен/оптимизирован процесс записи/чтения нет-пакетов объектов хранения. Никаких лишних операций.

2. Операция по сериализации хранимых в хранилище таблиц оставлена только непосредственно при сохранении таблий в объекты хранения., что дало возможность оптимизировать оперции чтеия/записи в собственно хранилище.

 

Блин, а. Артос, не надо чинить то, что работает, пожалуйста. В твоё текущем варианте есть пара злобных привнесенных косяков:

 

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

 

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

[kamikazze 266]

Artos

 

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

 

 

 

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

А, да, и ещё - если "случайно" попадется таблица с метатаблицей, то сериализуется хрен знает что. Тоже учитывай.

Никто этого почему-то не учитывает (метатаблицы и рекурсию) как правило.

 

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

Хммм, и в компрессоре, где числовые ключи, предусмотрена ситуация, когда они идут не по порядку?

Ибо t[10] = nil, к примеру, не приведет к переиндексации и будет "дырка", если забить на это, то потом получим совсем другую таблицу

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