xStream

malandrinus, Глупости говоришь. Мне все равно, кто что будет делать, я свой сделала. Ты просто постоянно высказываешь мысли так, как будто это непреложная истина в конечной инстанции. Или как будто тебя лишают возможности использовать тот стиль программирования, к которому ты привык. Я не понимаю, как такое можно вообще в принципе сделать (запретить). Ты всегда можешь делать так, как хочешь, перед тем как использовать какой-то компонент: сделать 100 проверок и впихнуть 40 ассертов - дело то твое. Мягче надо быть, мягче.

Если делать в стейт части - валится стопудово.

Artos, мне просто написали, что это типа все в стейт части, так реализовала и, конечно же, оно все поломалось нахер. Возможно, ты прав. Попробую проверить.

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

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

Саша, пример РЕАЛЬНЫЙ и используется в РЕАЛЬНОМ коде. И оно работает. Там просто составлена табличка, для выставления здоровья. Либо монстрам, либо сталкерам. И так сделано специально! Можно пользоваться IsStalker и IsMonster() и стандартно ветвить ифами-елсами. НИКТО не запрещает использовать стандартные подходы. То, что ты назвал затычкой, таковой не является. Прошу смотреть amk_offline_alife.script. Не надо вне контекста оценивать такой пример, особенно, когда заявляют что оно таки работает. Сама функция isOk(), как ты верно заметил, ничего не контроллирует. Зато с ее помощью можно осуществить контроль над процессом. Хочешь тыкать ассерты - лепи. Никто не запретит. Я придерживаюсь иного подхода: многие ошибки можно в реалтайме перехватить и обработать и они далеко не всегда фатальны. Как в вышеприведенном примере, где месиво из разных объектов. Так что я не соглашусь про барьеры и так далее. Если хочешь контроля, контроллируй, что подаешь, ассерти и все такое прочее. Сам класс-обертка содержит такой функционал, который может поломаться только если до него кто-то что-то напортачил. Что касается исключений, то даже не спорю. Только такого мощного инструмента в ЛУА нет. И это явно не пойдет на пользу простому использованию (на что, в первую очередь и направлена библиотека) если такой механизм или подобный ему вводить. Если тебе необходим ЖЕСТОЧАЙШИЙ контроль, то, как я сказала - используй непосредственно класс 100% соответствующий объекту. Никаких дамми не будет, контролируешь все сам. А хелпер на то и хелпер. Как я акцентировала - разные уровни абстракций для разных задач. Причем - не мешающие друг другу совершенно.

Если нужен контроль, то есть метод isOk() у всех видов пакетов. Так вы получите результат проверки, которые вы и так и так делали бы. Либо вы забиваете, а в большинстве случаев это вполне вариант (вы только что создали объект и точно знаете, что это и что будет с ним дальше), либо получаете результат проверки (когда логика с ветвлением). При этом сработает это добро как в случае клиентский/серверный объект, так и если вообще что-то другое подсунули. Я лично предпочитаю этот метод использовать, он убирает недоразумения. При этом, несмотря на то, что "конвертирование" из клиентского в серверный предусмотрено (бывают ситуации, когда это проще), я лично сама предпочитаю передавать только серверные варианты. Что касается "пердали клиентский, а серверного нет", то как раз isOk() вернет false, а сам пакет будет net_dummy. Операции с ним бессмысленны, а isOk() у него всегда возвращает false. Я не описала этот метод (дада, мануал), но мне кажется, он решает все сомнения и вопросы, которые были выше указаны. Только что про это написала, а вот пример как раз про это в ридми (смысл в дамми появляется в ветвлениях!): local pk = xs_netpk.monster(obj) if not pk:isOk() then pk = xs_netpk.stalker(obj) end То есть такой подход позволяет сократить код для ветвлений. И проверяем и сразу создаем, если надо. Ну а для любителей строгого подхода есть всегда возможность создать конкретный класс, там разночтений быть не может. Скажем так: предусмотрены разные уровни абстракции для разных задач. ЗЫ или как вариант - сделать настройки, отключающие конвертирование и использование net_dummy, сделать это легко. И мне кажется, вполне имеет смысл. Добавлено через 43 мин.: Черт. Внимание! Есть подозрение, что работа со skeleton_flags, как тут объясняли и рекомендовали, приводит в битью пакетов и вылету. Надо найти { name = 'skeleton', type = 'skeleton' } и закомментировать эту строку. Но возможна, скорее всего, побочка - "растянутые рельсотрупы", как в пресловутом АМК. Возможно, я неправильно организовала разбор, надо будет проверить...

Artos, Есть, сделана была по причине, что там, где используется (ОГСЕ и мои скрипты) кастомдата и так и так распарсивалась в таблицу. Заменить тип данных обратно на строку очень легко: заменяем { name = 'custom_data', type = 'cd', default = xs_helpers.custom_data() }, на { name = 'custom_data', type = 'sz', default = '' }, Тогда для кастом даты будет обычная строка. Пока только ТЧ выяснялось и билд 3120. В принципе, собираюсь протестировать и на ЧН с ЗП, если и когда их установлю себе Мои подобные эксперименты с пакетами в ЗП никаких особых трудностей не вызывали. (Да, я слышала про трудности эти, но сама не сталкивалась) Не совсем корректно. Это для "специфических" объектов. Для самых распространенных (правда, пока не всех) есть короткоименные функции-хелперы (они вынесены ближе к началу скрипта. По хорошему надо вынести в шапку, где идет описание про эти хелперы): сталкеры - xs_netpk.stalker(obj) монстры - xs_netpk.monster(obj) (что характерно - работает со всеми монстрами, даже с разными пакетами, просто возвращает нужный, так что запариваться не надо.) оружие - xs_netpk.weapon(obj) (сама определяет тип оружия и возвращает подходящий пакет) рестриктор - xs_netpk.space_restrictor(obj) левел_ченджер - xs_netpk.level_changer(obj) аномалии - xs_netpk.anomaly(obj) (аномалии как с визуалом типа хваталки, так и обычные) Все эти функции, если им подсунуть что-то "левое", вернут так называемый net_dummy. Пакет, который не делает ничего. Это сделано для избавления от разных проверок на то, правильный ли объект передали или нет. Так же все функции принимают как серверный, так и клиентский объект. Опять же, крохотное упрощение интерфейса. Список хелперов думаю расширить. Принимаю заявки ЗЫ Так же подумываю о специальном методе, котрый бы дампил в строку содержимое пакета, чтоб можно было узнать, какие у него свойства.

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

bind - "привязать". Речь идет о связях скриптовых классов с серверными. При наследовании такая связь теряется, если методы переопределять и используются конструкции типа cse_alife_item_custom_outfit.STATE_Write (self, packet) Мы таким образом все равно вызываем "оригинальный класс" Однако суть все же не в этом. Семантически все, что мы заэкспортили из двига в ЛУА является "биндингом" - связью ЛУА-инстанса с С-инстансом. То есть вообще все является биндингом. Биндером является то, что делает такую связь принудительно. В общем, если очень действительно хочется некую терминологию ввести и придерживаться ее, то получается так. Но это все глупо и бессмысленно Все равно все по примеру понимают, что надо делать. ЗЫ Например, для таймеров, потом меня осенило, и семантичнее и короче было бы использовать bind и unbind. Но, поскольку уже есть код, завязанный на этом, то оставила register и unregister.

Еще раз - советую вспомнить/посмотреть перевод слова bind. Хорошенько вникнуть. Для аналогии и стимуляции мышления могу подкинуть слово 'luabind'.

abramcumner, что такое bind в переводе с английского? Что касается поворота - мб. Там всего лишь написано, что мне подсказали.

Так, доработка по библиотеке пакетов. Мануала все ще нет, но как допроверю, что все ок, будет. http://dl.dropbox.com/u/46539648/xs_netpk.script 1) Да, оно завязано на мою песочницу, так что надо прописать, если используется эта песочница. 2) Кто любит все переделывать, типа Artosa, могут так же переделать и это, суть понятна, мне кажется. Собственно, какие изменения: Попробовала учесть все замечания по неправильному содержимому пакетов, опечатки и прочее. Добавлен класс для работы с абстрактной частью пакетов - описание в шапке файла. ЗЫ Да, лакончино, скомкано и т.п. Все будет развернуто, когда доберусь до мануала. А пока тот, кто понимает, прошу вас это посмотреть, потестить. Нужен фидбек по ошибкам. Заранее спасибо.

Хех, я бы не сказала, что интерфейс простой (по мне так он сильно перегружен параметрами, пусть даже в виде таблицы), но да ладно. А что касается таймеров. Лично я придерживаюсь все же подхода - все из коробки, как готовый продукт. Есть класс и используй для чего хочешь и как хочешь. У тебя надо что-то создавать. По-моему переусложнение для конечного пользователя. В С++ это еще б имело смысл, но не в луа. Так же как и передача селф+метод вместо простой функции - чисто Сишная примочка, я знаю. И так же создание описаиния слота. Когда вместо этого можно работать все с теми же замыканиями и безымянными функциями. И интерфейс проще и внутренний код системы. Но это просто имхо, чтоб ты знал его А что касается приоритетов, это вообще отдельный разговор. Я всегда очень отрицательно отношусь к таким вещам, где может производиться при определенных условиях переполнение очереди. Я, конечно, гляну сигналы, но что-то мне подсказывает...

Объект и биндер - Саша делал. В коде указано же было. Добавлено через 25 мин.: Только вот прописывать их в АСДС смысла нет. Они спавнятся только скриптами. В редакторе не имеют вообще никакого визуала и не несут никакой нагрузки. То есть в спавне им делать в принципе нечего.

Саш, peace Просто ты привел такие примеры. Ну а насчет интерфейсов я все равно настаиваю, что они должны быть как можно проще и как можно меньше вариаций иметь

Andrey07071977, прикол в том, что боттлнека, кстати, не будет при таком подходе: при set производится одна сериализация, при сохранении в "оптимизированном" варианте - при сохранении сериализуется все. В первом подходе нагрузка распределена по времени. И влияние на производительность оказывает небольшое. Зато мы сразу предупреждаем программиста - у тебя тут гавно, срочно принимай меры.

Саш, дополнительные параметры в инетрфейсе, использование метатаблиц - это не сложности? По сравнению с одним единственным замыканием - еще какие.

Andrey07071977, А смысл мне от этой проверки? Это проверяется при сохранении и получаем ошибку. Функция set была изначально организована так, что возвращала булевое значение - успешность помещения переменной в хранилище. Тогда, программист, получив false, мог бы принять меры - уменьшить как-то размер таблицы. (Черт! Надо еще длину у строки проверять!) А так. Он запихнул, а потом огреб ошибку, и как ее обрабатывать?

Andrey07071977, http://www.amk-team.ru/forum/index.php?s=&...st&p=661284 Там более развернуто, с созданием переменных, но это не обязательно. Пример выше - гораздо компактнее. Но делает то же самое. Добавлено через 5 мин.: Да, правильно. Можно, правда, еще короче: function object_execute(obj) return function (...) return obj:execute(...) end end function object_execute_1(obj) return function (...) return obj:execute_1(...) end end

Andrey07071977, Использовать замыкания. Я раньше писала, как это делать. Я не знаю, зачем такие сложности Саша придумал Вот вариант: function bind_method_x(obj) return function (...) return obj:method_x(...) end end local funct = bind_method_x(megaobject) --в переменной funct окажется функция, которую можно передать куда угодно.

Gun12, да никакого высшего пилотажа там нет Только синтаксис ЛУА. Класс - таблица-прототип, хранящая логику. Объект класса - тоже таблица, но хранящая данные. По метаметоду __index ссылается на таблицу-прототип. Наследование реализуется тоже с помощью __index - таблица-прототип ссылается на другу (другой класс) получая оттуда другую логику. Элементарно.

Gun12 Что-то как-то громоздко. И я не понимаю интерфейса (имхо, тоже перегружен - мне кажется, геттеры и сеттеры в чистом виде не нужны. В "методы" обернуть бы более комплексную логику). Зачем ограничение, что таймер нельзя сохранять в переменной? Это не удобно, всегда присваивать имя. Это аналогично безымянным функциям - они есть, работают, можно передавать, но имени нет. ИМХО.

Gun12, Viнt@rь, вот для общего развития. Реализация "классов", подобная реализации луабинд. Можно "наследовать" классы, форма записи - такая же (определение классов). Как видно из кода - реализация примитивнейшая средствами ЛУА, но результат...

KD87, я думаю, проблема не в том, чтоб его прочитать или записать, а в том, что он должен попасть в реестр стори_идов. А это, насколько мне известно (в том числе и по опытам, аналогичным опытам *Shoker*), происходит в момент старта игровой сессии. (черт, похоже не в тему ответила. Я имею ввиду такие ситуации, как споты в ПДА на определенные объекты. Там задействован реестр)