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

[Artos 99]

kamikazze,

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

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

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

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

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

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

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

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

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

 

 

[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

[Artos 99]

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

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

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

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

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

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

 

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

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

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

 

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

[Artos 99]

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

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

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

 

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

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

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

 

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

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

 

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

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

[Artos 99]

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

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

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

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

[Artos 99]

Viнt@rь,

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

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

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

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

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

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

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

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

и т.д.

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

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

 

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

[Artos 99]

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

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

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

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

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

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

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

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

Эх ...

 

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

[Artos 99]

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

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

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

 

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

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

"

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

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

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

 

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

[Artos 99]

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

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

 

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

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

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

[Artos 99]

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 99]

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

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

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

 

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

 

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

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

[Artos 99]

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

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

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

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

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

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

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

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

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

 

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

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

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

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

 

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

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

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

 

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

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

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

[Artos 99]

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

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

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

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

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

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

 

[Artos 99]

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 99]

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

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

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

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

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

 

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

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

[Artos 99]

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

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

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

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

[Artos 99]

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

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

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

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

[Artos 99]

Взглянул на скрипт 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 99]

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

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

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

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

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

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

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

 

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

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

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

[Artos 99]

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

 

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

 

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

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