xStream

Из шапки, дабы немного удовлетворить любопытство:

А понять, как пишется очень просто Загляни в xs_helpers, там расширения для table есть: serialize и unserialize Добавлено через 1 мин.: Andrey07071977, таймеры, которые тут выкладывались - фигня, по ним не надо фидбека

Блин, я так спать не уйду А это разве не оно? { name = 'ph_position', type = 'f32v3', default = vector():set(0,0,0) }, { name = 'ph_rotation', type = 'q8v', default = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}, len = 4*4 }, --quaterinon И if prop.name == "num_items" then updnum_items = ret["upd"..prop.name] if updnum_items==0 then return end info_mask = math.ceil(updnum_items/16) if not (bit_and(info_mask, 2)==0) then skip_props.ph_angular_vel = true end if not (bit_and(info_mask, 4)==0) then skip_props.ph_linear_vel = true end end Вот условное чтение, в зависимости от updnum_items

Для пользования ими есть специальные функции хелперы ОЧЕНЬ сильно упрощающие жизнь. Когда будет дошлифовано содержимое, то будет и мануал (а пока можно поглядеть readme.txt, там вполне реальные примеры приведены). Как минимум в одном моде уже используется (там люди знающие, поверь) и то радует - мои эксперименты не пропадут даром.

Йайа Вот за это и не люблю копипастить - легко что-то недосмотреть. Сенькаю, обновлено и залито. ЗЫ Хочется фидбека по использованию, если кто решит попользовать. И всем спокойной ночи, кто в московском поясе

У Artos'a они далеко неактуальные. А универсальный АСДС - слом мозга. Добавлено через 8 мин.: Со skeleton_flags не нашла ветвления в универсальном АСДС. Так что...

Дайте мне актуальную версию АСДС - будет А кто может сам исправить, спасибо скажу и исправления внесу. А что там разбирать? Тоже тип данных не верный? Вроде все корректно. А разбирать - ручками, вначале скрипта огромный ворох констант, bit_and в руки для определения того или иного свойства. ЗЫ Нету там таких констант, наврала. Опять же - все из АСДС, хехе. Добавлено через 12 мин.: Обновила архив, ссылка та же - http://dl.dropbox.com/u/46539648/xs_scripts.rar Спасибо KD87, внесла изменения в соответствии с его замечаниями.

Фидбек - это здорово. Все типы данных брались из ACDC, возможно, мне попалась устаревшая версия, или версия с неточностями. Как написано в шапке - это своеобразный интерфейс (постаралась сделать простым для расширения) для "портирования" из АСДС. Так что если косяки, то все оттуда. Я, конечно, еще проверю. Но что для ТЧ с версии 1.0004 и выше - точно. Еще бы фидбек по использованию, но там, надеюсь, проблем не возникнет Добавлено через 1 мин.: Угу, что-то неактуальное, наверное, тот самый шотган: use constant upd_properties_info => ( { name => 'upd:ammo_ids', type => 'u8' }, # 0x1c0 (0x1e0) ); Хорошо, что предусмотрен tail, по крайней мере данные не потеряются Подкиньте ссылку на актуальную версию для ТЧ, 6-й патч. Универсальный не предлагать - я себе мозги сломаю заниматься переносом оттуда

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

http://dl.dropbox.com/u/46539648/xs_scripts.rar - библиотека для работы с нетпакетами. Зеркальное отображение АСДС, только в скриптах и ООП. Прошу любить и жаловать: еща парочка, надеюсь полезных, скриптов. Дада, опять же в концепции ООП. Но это не главное. Главное - задачи, которые они выполняют. Так же на подходе универсальное хранилище данных (а-ля доисторический pstor) и (ахахахаха, барабанная дробь)... - моя реализация сохраняемых таймеров с использованием этого самого хранилища. ЗЫ Если это можно в какую-то другую тему запихать, то пожалуйста. Я не нашла ничего семантически подходящего, а в связи с отсутствием подробного мануала, новичкам сразу выдавать это не стоит В то же время, там внутри несколько приемов используются, как сакраментальное наследование и прочие интересности.

Как же ты любишь унасекомить собеседника, ув. Artos... Пример не абсурден, а полностью аналогичен твоим действиям, только переведено все в категории обычной жизни. А еще мне надоели твои простыни, требуешь по существу, а сам растекаешься мыслью по дереву. И очень, очень зашкаливает градус резкости высказываний. Ты еще хочешь чтобы тебе "доказали" что-то? Да тут не доказывать кому-то надо, а мыслить другими категориями. В этом случае новичкам даже легче - у них нет груза навыков, опыта и привычек за спиной. Я раскланиваюсь и покидаю тему, где единственный активный участник не пытается понять, а всегда ставит в пику, какой он опытный и как классно он пишет код, а все остальные этакие редиски. ЗЫ Всех с наступившим!

1) Не передергивай, пожалуйста. Ответ был общий по общему вопросу, ты просил причины, я их привела. Не важно, уговорили они тебя или нет. Просто как констатация факта, для понимания механизма работы. Никакого другого смысла не вкладывалось. 2), 3) туда же... - описание механизма. Я не претендую на то, что это важные факторы и сама закрою на них глаза при гораздо более важных плюсах. Я просто поддержала тему. Парадигма - не абстрактна, она описывает иерархию. Пример из реальной жизни: есть у тебя велосипед, двухколесный, красивый, 18 скоростей, тут ты прикручиваешь на руль стиральную машину, которая должна подключаться к электросети. Аналогия понятна? Учитывая, что множественного наследования в ЛУА нет, то рано или поздно, как минимум уткнешься в вопрос - а что и от кого и зачем наследовать. Если делать "на всякий случай", то я не понимаю в этом ни логики, ни смысла. Подозреваю, что ты тоже не понимаешь, а именно "на всякий случай" случай делаешь. На всяких случай не делают. Добавляют не хватающее по мере необходимости, но никак не наоборот - не пихают все в кучу. Опять же, тебе нужны факты, аргументы. Есть аксиомы, заложенные таким подходом программирования. Не с того конца подходишь. Как сказал выше malandrinus, "уменьшить время разработки и/или уменьшить объём кода за счёт повторного использования готового кода." Могу только добавить "повторного использования там, где он нужен". Про таймеры заговорила, потому что были в твоем посте, не надо валить со своей головы на мою. Не зачем на меня тут наезжать, сам же поднял этот пример. Добавлено через 5 мин.: Во! Сообразила, как, наверное, правильно написать. Дело не в использовании на всякий случай (self:unregister(...) и self:unregister(...) - что доступно для дочернего класса и не заморачиваться и в др. ситуациях, если вдруг понадобились родительские методы, а просто их использовать.), а в такой вещи, как проектирование и архитектура кода. Код сначала проектируется, учитываются все возможные зависимости, область применения и так далее. После этого составляется иерархия, по которой становится ясно, что от чего наследуется и зачем. Если в таймерах предусматривается какой-то регистрирование-отрегистрирование (не понимаю, правда, зачем от объекта отрегистрировать его же собственный единственный колбек, ну да лано. Таймеры злополучные взяты как пример), наследуемся, если они никогда в жизни этого не будут использовать (как уже сказала - зависит от решения, архитектуры), то и наследовать то смысла нет. Пожалуй, аргумент носит имя "рациональность", но поскольку каждый понимает его как хочет, то он не объективен. Увы. ЗЫ Еще раз акцентирую, дабы избежать очередной агрессии: это моя позиция, никому давно не навязываю даже.

Нуну Так давайте же начнем смешивать различные сущности, так, просто на всякий случай. Объекты луабинда создаются копированием таблиц с метатаблицами, таким образом, все объекты имеют свой инстанс методов и хранилищ. Соответственно, тупо не наследуя то, что не нужно, уже получаем выигрыш в памяти на хранение объекта и времени на его создание. Как минимум такая причина, думаю, убедительна, если оторваться от парадигмы. .... Таймеры мне скоро плешь проедят Все зависит от принципа реализации. Делая один ивент "timer" (тут вообще напрашивается тогда вопрос - а нахрена тогда несколько объектов?), а внутри устраивая разбор полетов, - это одно, а использование объектов, не работающих вообще в принципе с ивентами - это другое. Правильнее всего, имхо, - создать систему объектов, которые просто проверяются на апдейт (вот тут то и нужна песочница и event-driven модуль), а к каждому присобачен колбек. Плюс таймер несет произвольные данные для срабатывания. Это позволит легко сохранять/восстанавливать, а срабатывать и вызывать напрямую. Тут вообще не особо нужна event-driven модель.

1) Не было, за исключением биндеров и всяких ГУИ - там наследование и там оправданное использование. Никто в модах ООП не пользовал в том понимании, какое заложено парадигмой. 2) А что мешает писать аккуратный код и без этого, скажите мне? Каждый файл в сталкере - отдельный модуль, вот вам и неймспейс, там же локальные переменные. По сути, когда обворачивают в класс, получается аж две обертки для процедурного кода. Зачем? Красивый и читабельный код можно писать и без классов. Тем более, что в данном конкретном случае это использование не по назначению.

Я не буду ни возражать, ни давать оценку. На вкус и цвет фломастеры разные. Скажу только одно. Про скорость и "а по тому, что все так делают". Всякие "оптимизации на скорость" и "неторопливые вызовы" это смех. Ребята, не занимайтесь фигней. Оптимизировать надо тогда, когда появляются боттлнеки, а абстрактно рассуждать о скорости - глупо. Что касается второго, то вот все и делают на функциях все свои потроха для модов, убер быстро, ага. Не надо присваивать свое видение другим. Итог: ООП - это удобная иерархическая архитектура. Позволяет инкапсулировать данные, заниматься рефлексией и наследованием. Не надо говорить, что это уберкруто или уберплохо. Надо знать, когда использовать и что использовать, выбирать инструмент исходя из задачи, а не в теоретическом ключе, сравнивая такты процессора, затраченные на то или иное. Если вы не можете оперировать разными категориями инструментов - это ваши проблемы. Я могу и оперирую, и классами и функциями, и разными методиками хранения данных. Но я могу выбирать, а вы, судя по всему - нет. (последнее высказывание в первую очередь адресовано Dennis_Chikin) Добавлено через 1 мин.: Засим я отказываюсь продолжать холиворного оттенка беседу, буду высказываться только по конкретным методикам и решениям. ЗЫ Ув. Artos, как бы то ни было, я имею полное право давать категоричную оценку тому, что было написано мной, не так ли? А код АМК и его последователя (и других модов, использующих куски АМК) в конкретном случае на очень неслабую часть - мой, спорить, надеюсь, не будем (моежете мне приписать огромное ЧСВ, если хотите)? Методики, использованые там, заложены Red75, sokol_jack и мной. Причем, скорее, в разных сферах и направленностях. Поэтому, я вполне в состоянии критически оценить и эффективность самих методик и их реализаций. Методики, подчеркиваю, и код для их реализации, остался по сути неизменным с тех времен по большей части. Хоть как перекомпонуйте, оберните в псевдо-классы, переназовите переменные и т.п. - суть остается той же.

Я ругаю? Где? O_o Я его наоборот использую вовсю и всем остальным советую (кто знает как использовать). Ты, видимо, что-то не так понял. Я ругаю то, как это используют. Вон, хвалят АМК 2.0 за "приятность для глаз". А по сути хлам как был, так и остался. Просто оно все аккуратнее смотрится из-за организации в виде классов. Но по сути это все то же процедурное программирование. Скажем так - забивание микроскопом гвоздей, использование не по назначению. Просто подобный подход я видела не в одном языке и руки бы поотрывала а такое. Не знаете ООП - не трогайте классы.

Совершенно верно. И мне непонятно, почему придирание к опечатке пошло и речь о контексте...

Хорошо, исправлюсь. А много буковок тут и читать-то особо некому Тем более, что их ты написал в ответ на мой пост. Не прокатила отмазка. ЗЫ спасибо. Тебе желаю того же.

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

Челоаек просто опечатался, написав плюс вместо подчеркивания - посмотри на свою клавиатуру и поймешь. Обе записи имеют вполне внятный смысл. Только вторая опасна, если _G[module] == nil

Ув. Artos, я не передергиваю. Все к тому и пришло: "есть два мнения, мое и неправильное". Не хочу дальше эту тему развивать. А все остальное - слова, много слов. Не осилила прочитать, не обессудь ЗЫ Пойду лучше оливье доедать.

Искусство ради искусства? Я ничего против не имею. Только с этим вопросом (имитациия классов через метатаблицы) точно не ко мне. Я не настолько "продвинута" в этом вопросе. Да и сочинять велосипед не очень хочется Будем считать, что это был мой ответ на твой вопрос. Только мой. Программисты знают в первую очередь то, что используют. Я, например, про замыкания знаю и вовсю их использую, потому что в работе нужны. Метатаблицы ЛУА я знаю, и даже не в теории. Но повторять то, что сделано просто классно и офигительно - никогда не было желания. Ибо, скорее всего, я сделаю хуже и менее производительно. Так а разве нет? Нового ты не прочитал / не обнаружил на последних страницах? Этот топик читает очень мало людей, еще меньше что-то пишет. И уровень, в основном, так сказать, повышенной сложности. А если еще вспомнить предыдущие прения (где я настаивала на нововведениях, а Артос тут же пресекал тем, что это "чисто академические" вещи и использовать их нет смысла), то как-то грустно становится. Ты говоришь, что кому нужно, тот спросит? А где этот кто-то? Вот я что-то не наблюдаю. Может ты что-то спросишь? Поучавствуй в обсуждении. Посижу в сторонке? Займусь велосипедами?

ООП не относится к ЛУА. Это общая парадигма. Ее не расскажешь в двух словах и не научишь за 10 минут. Максимум, чему можно научить в пределах топика - базовым принципам использования готового кода с использованием готовых классов, кем-то написанных. А смысл извращаться? В ЛУА нет классов как таковых. Все имитируется с помощью метатаблиц. Луабинд это делает автоматически и предоставляет соответствующий функционал, благодаря чему праздник в дом приходит в ЛУА появляется удобный инструмент для использования ООП - классы и объекты этих классов. Описывать, как реализовать подобное вручную метатаблицами - нет ни желания, ни необходимых знаний.

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

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