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

Artos · 28 Декабря 2011

kamikazze,

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

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

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

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

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

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

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

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

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

Artos · 29 Декабря 2011

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

Artos · 29 Декабря 2011

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Artos · 1 Января 2012

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

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

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

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

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

Но, все же, хотя раздел и носит название "Школа ...", но это не школа с учителями и учениками! ИМХО, тут мы все и учим и учимСЯ, т.е. даже обучая кого-то, делясь знаниями/навыками - подспудно оттачиваем и свои навыки/знания и ничего не мешает, получив порцию знаний, продолжить самостоятельно копать в этом направлении, набираясь уже не только базовых знаний.

Согласен, что все наши слова/ответы - это только наше видение/мнение. Но никто же и не заставляет насильно делиться знаниями и, начав о чем-то - в обязательном порядке продолжать. Вполне начать может кто-то и если ему надоело (разинтереснилось) - это может продолжить другой/другие. Если затронутая тема интересна НЕ одному/двум - то почему бы и ради "чистого исскуства" над ней не покумекать? :-)

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

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

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

Artos · 1 Января 2012

xStream, много буковок не только же для прочтения тобою понаписаны ... ;-)

(плз. не коверкать по-возможности мой ник)

P.S. и, конечно же, приятного аппетита за оливье и хорошего настроения на эти и последующие дни!

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

Artos · 1 Января 2012

Viнt@rь,

спаcибо за отзыв по моду. Ну и, в контексте топика, позволю себе дать небольшое пояснение:

1. "Солянка" - все же термин, который может выражать и суть (кратко: сборник из различных источников) и форму/качество (ругательно: мешанина из всякой всячины).

SIMBION был (времена ABC+AMR+SRP+...) в полном смысле первой "глобальной" солянкой (и по сути и по форме). После него пошли и иные моды-солянки, но ... (см. п.2).

2. Можно коды собрать в нечто единое (солянку) по разному:

а) Просто совместив коды, избежав синтаксических и логических ошибок;

б) Интегрировать коды, т.е. помимо просто совмещения, совмещаемые коды привести к некоей единой концепции/сюжету.

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

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

и т.д.

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

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

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

Artos · 2 Января 2012

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

xStream, ну ведь есть же пословица: "Не боги горшки обжигают.", зачем же так резко: "Не знаете ООП - не трогайте классы".

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

С твоим подходом - остается всем не профессионалам только конфиги ковырять да текстуры перекрашивать или садиться "за парту" и грызть теорию программирования. ;-(

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

xStream: Вон, хвалят АМК 2.0 за "приятность для глаз". А по сути хлам как был, так и остался ...

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

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

Эх ...

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

Artos · 2 Января 2012

Dennis_Chikin, наверное xStream более резко возразит или даст оценку потугам разработчиков игры, я же пока дам реплику:

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

"Полезность" - все же понятие относительное.

Ну а про код упомянутого тобою мода не поддержу тему

, для меня это из уже закрытой категории:

"

о покойниках или хорошо или ничего" - это о кодах/моде, а не о чем-то ином.

(сейчас мне кто-то врежет за такую, хотя и косвенную и личную, "оценку")

... хотя шанс разубедить у них все же есть.

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

Artos · 4 Января 2012

Хотелось бы прояснить вопрос по созданию дочерних классов/объектов.

Вопрос: Чем плохо создавать 'дочерний' класс/объект, даже может быть и не связанный с 'родительским' классом/объектами сутью или общностями применения/использования?

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

Если опустить различные "обще(не)принятости" и т.п. и субъективности - то собственно для ресурсов, производительности и т.п. чем "чистый" объект предпочтительнее "зависимого"?

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

Artos · 4 Января 2012

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

Не стал пока поднимать этот вопрос, т.к. связан или нет тоже может быть субъективным понятием ... ;-)

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

Ранее тут приводился пример с событиями (ивентами), т.е. создается класс "event".

class "event" --/ (by xStream @>-`-,--`,--)
function event:__init(name)
...
end

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

class "timer" (event) --/ дочерний класс
function timer_xs:__init() super("timer")
...
end

Учитывая что в самом классе таймеров в наличии обращение к классу "event":

event("timer"):register(...) иль event("timer"):unregister(...)

напрашиваеся сделать:

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

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

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

Artos · 4 Января 2012

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

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

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

Сорри, xStream, но я пока не вижу для себя убедительности в ответе. Мизерность выигрыша во времени создания и несколько байт в памяти, которые уничтожаются при исчезновении созданного объекта - неубедительны (особено на фоне кодов исходной игры, где "тонны" растранжириваются). "Лишние" символы/строки в кодах и времена их парсинга/выполнения - того же порядка ...

Суть вопроса, повторюсь, не в таймерах иль чем то конкретном, а именно в сравнении создания чистого или дочернего объекта. Это могут быть самые различные сущности, например те же actions, которые гоняются для монстров/машин через xr_logic, каждый раз перепроверясь на существование и т.п.

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

Artos · 4 Января 2012

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

Где то упоминалось про велосипед/гусеницы/стиралку? Почему такая тяга оппененту сразу навешивать ярлык изобретателя невразумительного велосипеда?

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

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

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

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

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

И невозможно учесть всевозможные зависимости и никто не отменял понятий универсальности и/или написания кода "на вырост".

Да и просто поисследовать как в игре поведет себя тот или иной вариант, чем полезен или вреден - тоже немаловажно.

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

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

Простейший пример: ставим таймер на выброс, по срабатыванию которого запускается собственно алгоритм выброса и куча иных алгоритмов! Разве это не событие? То, что оно синхронизировано с родительским апдейтом актора? Ну так тогда и это не событие, а рядовой таймер, только тикают его часики в недрах движка ...

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

Ну и т.д. и т.п. ИМХО, не следует свои шоры или наоборот ширту воззрений проецировать на нечто, что пока до конца то и не обусловлено и неограничено.

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

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

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

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

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

Artos · 5 Января 2012

Жаль, что диалоги постоянно скатываются с сути вопроса/темы на субъективности личностного характера. ;-(

Отбросив шелуху в ответной реплике, все же по сути выскажу:

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

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

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

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

Artos · 7 Января 2012

xStream: У Artos'a они далеко неактуальные.

Можно попросить привести аргументы/примеры неактуальности модуля нет-пакетов (m_net_utils.script).

Для справки:

1. Последняя доступная версия модуля нет-пакетов (m_net_utils.script) датирована 17.12.2011.

2. Последняя (актуальная) версия модуля всегда доступна в текущей на 'сегодня' версии SIMBION:SHOC, которую можно взять на сайте мода.

3. На этом форуме был выложен линк на версию от 27.10.20011 (см. #3067), которая и не сильно "устарела" и до сих пор доступна.

4. Модуль нет пакетов (m_net_utils.script) совместим со всеми версиями игры/патчей (ТЧ/ЧН/ЗП), начиная с 1.0006 и далее.

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

Artos · 7 Января 2012

xStream, можно попросить все же быть более уважительной к оппонентам/собеседникам?

Если тебе лень вообще что-то знать о модуле/моде, то не стОит высказывать ложных тезисов.

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

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

Дискуссии пока и не будет, твой вариант еще даже не посмотрел.

P.S. Версия от 17.12.2011 ссылка на народ.ру (~15.9 кБ)

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

Artos · 7 Января 2012

Viнt@rь, в даннм случае, модуль нет-пакетов мною пишется в основном для 'использования', а не его просмотра/ковыряния.

Именно поэтому почти и не требуется ни мануала ни описания его начинки. Достаточно правильно скопировать сам скрипт и его конфиг и использовать, вызывая с любым серверным объектом и получая/отдавая табличку данных формата ACDC (только отдельные рудименты еще несинхронизированы).

код симбиона охрененно трудно сопроводжаемый не автором

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

Artos · 7 Января 2012

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

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

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

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

Artos · 8 Января 2012

Взглянул на скрипт xs_netpk.script (пока беглым взглядом).

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

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

Пока мое резюме: Перепев на новый лад с дополнениями прежнего amk.script/xrs_utils.script.

Если нужна (а вдруг ...) конструктивная критика/замечания, то готов и ее дать, хотя ... врядли это востребовано, т.к. задевает ЧВС.

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

(ИМХО)

KD87, по skeleton_flags ты имеешь ввиду что-то типа этого(?):

  tP.skeleton_flags = oPs:r_u8()
  --[[ --/#?#
  if oPu and tP.upd and bit_and(tP.skeleton_flags,4) == 4 then --/ 3-ий бит
    tP.upd.bones_mask = oPu:r_u64()
    tP.upd.root_bone  = oPu:r_u16()
    tP.upd.ph_angular_velosity = Get_Chunk({},oPu,3,'r_s32') --/#?# vector
    tP.upd.ph_linear_velosity  = Get_Chunk({},oPu,3,'r_s32') --/#?# vector
    tP.upd.bone_count = oPu:r_u16()
    for i=1,tP.upd.bone_count do
      local t = {}
      t.ph_position = Get_Chunk({},oPu,3,'r_u8') --/#?# q8v3
      t.ph_rotation = Get_Chunk({},oPu,4,'r_u8') --/#?# q8v4
      t.enabled = oPu:r_u8()
      tP.upd["bone_"..i] = t
    end
  end
  --]]
  tP.source_id      = oPs:r_u16()

и для каких классов объектов? Для cse_alife_object_physic или же и для всех/других?

Или все же что-то с num_items для cse_alife_object_physic перемешалось?

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

Artos · 8 Января 2012

Viнt@rь, а вот в этом поддержу выбранную позицию xStream.

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

Хранилище о котором говорит xStream - расширитель именно pstor'a актора, снимающий ограничение на размер (~8 кБ для SHOC). Вполне можно хотеть запихнуть в него и все остальное, но ... зачем пытаться в одну корзину класть все яица?

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

Хранить огромные списки/тексты, типа "записки сталкера", в которые игрок может понапихать все чего захочет (если не ограничить ему объем) - вполне можно потрудиться и расширить функционал внешними расширителями до записи в 'пользовательские' файлы (*ltx и иже).

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

Хотя ... сам никак не подберу варианта для достаточно простого хранения именно начальных/стартовых настроек (типа доп. опционала), когда возникает необходимотсь до начала игры (соответственно до спавна в нее актора) добавить/изменить именно внутри-игровые настройки/параметры. И хотелось бы это делать не сторонними расширителями, а на ресурсах движка/игры и не засоряя 'user.lx'.

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

xStream, можно попросить привести тут наметки конфига для объекта с произвольным объемом нет-пакетов (до готовности всего модуля по расширенному pstor'у)?

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

Artos · 8 Января 2012

Viнt@rь, сорри, но я из контекста по расширенному хранилищу высказанному тут, воспринимаю его как в-первую очередь расширитель именно акторского pstor'а, а это как раз и обуславливает наличие актора в игре/онлайне. Ведь pstor для любого игрового объекта - одна из субтаблиц, которые создаются для объектов в db.storage и, если их даже создать ранее - придется перелопатить коды, дабы не затирались преждевременно созданные 'штатными' скриптами оригинальной игры.

P.S. (ох что-то лагает сервер форума) Pstor'ы всех забинденых объектов конечно же сохраняются в сэйвы (см. в xr_logic.script) и размер всего суммарного нет-пакета для объектов как раз и имеет ограничение в 8 кБ (SHOC). Хотя ... вероятно все же есть вариант для расширения этого лимита (жду ответа от xStream). Возможно какие-то технические классы имеют бОльший диапазон ...

P.P.S. И я так понимаю, что речь НЕ идет о замене акторского (ПЫС'овского) pstor'а, а именно о его расширении. Т.е. 'штатные' коды/движек/... могут продолжать писать в прежний, а 'модовские' данные можно перенаправлять в удобный - штатный или расширенный.

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

Войти

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

Рекомендуемые сообщения

Artos 99

Поделиться этим сообщением

Ссылка на сообщение

Artos 99

Поделиться этим сообщением

Ссылка на сообщение

Artos 99

Поделиться этим сообщением

Ссылка на сообщение

Artos 99

Поделиться этим сообщением

Ссылка на сообщение

Artos 99

Поделиться этим сообщением

Ссылка на сообщение

Artos 99

Поделиться этим сообщением

Ссылка на сообщение

Artos 99

Поделиться этим сообщением

Ссылка на сообщение

Artos 99

Поделиться этим сообщением

Ссылка на сообщение

Artos 99

Поделиться этим сообщением

Ссылка на сообщение

Artos 99

Поделиться этим сообщением

Ссылка на сообщение

Artos 99

Поделиться этим сообщением

Ссылка на сообщение

Artos 99

Поделиться этим сообщением

Ссылка на сообщение

Artos 99

Поделиться этим сообщением

Ссылка на сообщение

Artos 99

Поделиться этим сообщением

Ссылка на сообщение

Artos 99

Поделиться этим сообщением

Ссылка на сообщение

Artos 99

Поделиться этим сообщением

Ссылка на сообщение

Artos 99

Поделиться этим сообщением

Ссылка на сообщение

Artos 99

Поделиться этим сообщением

Ссылка на сообщение

Artos 99

Поделиться этим сообщением

Ссылка на сообщение

Artos 99

Поделиться этим сообщением

Ссылка на сообщение

Недавно просматривали 0 пользователей

AMK Склад