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

[Dennis_Chikin 3 658]

С чего начинать и где взять.

 

Установка Lua:
http://www.amk-team.ru/forum/index.php?showtopic=11584&p=629106

 

Руководство «Программирование на языке Lua», третье издание:
http://www.amk-team.ru/forum/index.php?showtopic=11584&p=905308

Изменено 2 Марта 2015 пользователем Kirgudu

[alpet 77]

Мелкое замечание по ODS. В тех модах где предполагается отключение luacap в релизной версии, напрямую вызывать экспортируемые функции не стоит. Лучше объявить в _g.script соответствующие глобальные обертки:

function logmsg(msg, flags)
if ODS ~= nil then
    ODS (msg, flags)
end
end

[Andrey07071977 18]

Функция exec принимает аргументом sName, по наличию которого вызывается функция assert, но в нее передается неопределенный аргумент sFilePath

 

Пардон, невнимательно повырезал функции Luacap - у меня sFilePath назначается в ExpandPath(sName), потом идет проверка на существование файла FileExists(sFilePath)

 

Андрей

[Artos 99]

xStream, kamikazze

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

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

Меня, например, бесят 'npc' иль 'obj' - что означает достаточно расплывчатое определение того, что же подразумевает автор кода ... но это именно уже привычное (но не приемлемое!).

Так что чем махать шашками, стОит вчитаться именно в семантику фразы и принять во внимание НЕ тождественность понятий: 'привычное' и 'предпочтительное'. ;-)

kamikazze: ... код нечитаем, так как постоянная смена регистра вызывает "рваное" восприятие имен

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

Если следовать логике - то уже привычное многим НЕ употребление заглавных букв в простых текстах, знаков препинания и т.п. - верх "понятного и читабельного" текста (и глаза не скачат и только буковки одного размера). И зачем модераторы/кураторы за грамотность радеют? ;-) (это я малость ерничаю).

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

Далее врядли стОит продолжать (<= O! как раз пример того, как выделить сменой регистра ударение в слове, не имея под рукою иного средства!) ... и хулить иль навязывать вкусы/предпочтения. Все же это не столь программирование, сколько форма воплощения алгоритма в читабельное воплощение.

 

P.S. Кстати, пришло на ум: А почему ник xStream выбран той, кому такое написание (аля-венгерка) глаза режет?

(это не поддевка, а только размышление на тему). @>-`-,--`,--

 

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

alpet, ну тогда при отключаемом Luacap функциональнее типа так:

logmsg = function() end --/ заглушка

if ODS then --/ при активном Luacap
  logmsg = ODS (msg, flags)
elseif log1 then --/ при наличии расширителя
  logmsg = log1(msg)
else --/ обычный вывод в лог
  logmsg = printf(msg)
end

- дабы в лог выводить при любом раскладе ...

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

[Andrey07071977 18]

xStream

И вообще, лучше б отписался по сендбоксу. У тебя критика конструктивная получается. :-P

Полностью с тобой согласен, бери пример

 

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

 

Artos

Насчет проблемы с оператором '...' - что-то непонятно..

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

[Artos 99]

Andrey07071977, вероятнее всего где-то описАлся. У меня в моде основной файл (по сути коммутатор между модулями) построен на половину именно применением оператора '...' , и практически все коллбэки и пр. с аргуменами идут во все модули именно через этот оператор.

--/------------------------------------------------------------------
--/ общий обработчик для коллбэков
local function do_callback(tCallback,...)
  for _,o in ipairs(tCallback) do
    o.func(o.uo,...)
  end
end
--/------------------------------------------------------------------
function on_new_game(...)
  do_callback(tCallbacks.new_game,...)
end
function on_pda_load(...)
  do_callback(tCallbacks.pda_load,...)
end
--/------------------------------------------------------------------
function on_fakebox(...)
  do_callback(tCallbacks.fakebox,...)
end
--/------------------------------------------------------------------
function on_npc_update(...)
  do_callback(tCallbacks.npc_update,...)
end
function on_mob_update(...)
  do_callback(tCallbacks.mob_update,...)
end
--/------------------------------------------------------------------
function on_npc_load(...)
  do_callback(tCallbacks.npc_load,...)
end
function on_mob_load(...)
  do_callback(tCallbacks.mob_load,...)
end
--/------------------------------------------------------------------
function on_npc_save(...)
  do_callback(tCallbacks.npc_save,...)
end
function on_mob_save(...)
  do_callback(tCallbacks.mob_save,...)
end
--/------------------------------------------------------------------
function on_net_spawn(...)
  do_callback(tCallbacks.net_spawn,...)
end
function on_mob_net_spawn(...)
  do_callback(tCallbacks.mob_net_spawn,...)
  on_net_spawn(...)
end
function on_npc_net_spawn(...)
  do_callback(tCallbacks.npc_net_spawn,...)
  on_net_spawn(...)
end
--/------------------------------------------------------------------
function on_respawn(...)
  do_callback(tCallbacks.respawn,...)
end
--/------------------------------------------------------------------
function on_net_destroy(...)
  do_callback(tCallbacks.net_destroy,...)
end
function on_npc_net_destroy(...)
  do_callback(tCallbacks.npc_net_destroy,...)
  on_net_destroy(...)
end
function on_mob_net_destroy(...)
  do_callback(tCallbacks.mob_net_destroy,...)
  on_net_destroy(...)
end
--/------------------------------------------------------------------
function on_death(...)
  do_callback(tCallbacks.death,...)
end
function on_npc_death(...)
  do_callback(tCallbacks.npc_death,...)
  on_death(...)
end
function on_mob_death(...)
  do_callback(tCallbacks.mob_death,...)
  on_death(...)
end
function on_actor_death(...)
  do_callback(tCallbacks.actor_death,...)
  tCallbacks.item_drop = {} --/#?# TODO: уточнить: а нужно ли все чистить?
end
--/------------------------------------------------------------------
function on_offline_death(...) --/#?# TODO: уточнить
  do_callback(tCallbacks.offline_death,...)
end
--/------------------------------------------------------------------
function on_hear(...)
  do_callback(tCallbacks.hear,...)
end
function on_npc_hear(...)
  do_callback(tCallbacks.npc_hear,...)
  on_hear(...)
end
function on_mob_hear(...) --/#?# reserve
  do_callback(tCallbacks.mob_hear,...)
  on_hear(...)
end
--/------------------------------------------------------------------
function on_actor_hit(...)
  do_callback(tCallbacks.actor_hit,...)
end
function on_hit(...)
  do_callback(tCallbacks.hit,...)
end
function on_npc_hit(...)
  do_callback(tCallbacks.npc_hit,...)
  on_hit(...)
end
function on_mob_hit(...)
  do_callback(tCallbacks.mob_hit,...)
  on_hit(...)
end
--/------------------------------------------------------------------
function on_enemy_see_actor(...)
  do_callback(tCallbacks.enemy_see_actor,...)
end
function on_actor_see_enemy(...)
  do_callback(tCallbacks.actor_see_enemy,...)
end
--/------------------------------------------------------------------
function on_npc_shot_actor(...)
  do_callback(tCallbacks.npc_shot_actor,...)
end
--/------------------------------------------------------------------
function on_info(...)
  do_callback(tCallbacks.info,...)
end
--/------------------------------------------------------------------
function on_change_hud(...)
  do_callback(tCallbacks.change_hud,...)
end
--/------------------------------------------------------------------
function on_task(...)
  do_callback(tCallbacks.task,...)
end
--/------------------------------------------------------------------
function on_trade(...)
  do_callback(tCallbacks.trade,...)
end
--/------------------------------------------------------------------
function on_use(...)
  do_callback(tCallbacks.use,...)
end
function on_use_npc(...)
  do_callback(tCallbacks.use_npc,...)
  on_use(...)
end
function on_use_mob(...)
  do_callback(tCallbacks.use_mob,...)
  on_use(...)
end
--/------------------------------------------------------------------
function on_item_use(...)
  do_callback(tCallbacks.item_use,...)
end
--/------------------------------------------------------------------
function on_item_take(...)
  do_callback(tCallbacks.item_take,...)
end
--/------------------------------------------------------------------
function on_item_take_from_box(...)
  do_callback(tCallbacks.item_take_from_box,...)
end
--/------------------------------------------------------------------
function on_item_drop(...)
  do_callback(tCallbacks.item_drop,...)
end
--/------------------------------------------------------------------

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

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

А вот с unpack в свое время так и не нашел ответа, столкнувшись в игре с ограничением буфера/таблицы в ~2048 байт (точно не помню). Для передачи аргументов это конечно не критично (за глаза хватит), но использовать уже стараюсь с опаскою ...

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

[xStream 86]

Так что чем махать шашками, стОит вчитаться именно в семантику фразы и принять во внимание НЕ тождественность понятий: 'привычное' и 'предпочтительное'. ;-)

Уважаемый, вот про шашки возвращаю фразу тебе. Это ты тут ими начал махать. Я преднамеренно обрамила свое высказывание в оффтоп, так что...

Как итог - я, камикадзе, мы твой код перевариваем с трудом. Тчк. Венгерка негласно принята устаревшей в том же Google Code Guideline. Пользуйтесь на здоровье, но помните - аргументировать пользу бесполезно. И холивор устраивать - тоже.

 

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

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

 

P.S. Кстати, пришло на ум: А почему ник xStream выбран той, кому такое написание (аля-венгерка) глаза режет? tongue.gif

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

Далее - само такое написание (camelCase) мне глаза не режет, когда применяется к методам или именам классов (В ЛУА классов нет, поэтому "классы" я нотирую С-стайл). Ибо здесь оно несет другую смысловую нагрузку: а) само такое написание указывает, что имеем дело с методом объекта ( e:setFingerprint ), б) опять же - уже дело привычки насчет привычек я и не спорю. Но подавляющее большинство кода ( не моего, но который приходилось ревизировать) именно такой нотации и выдержаны. Венгерку я видела только в старых проектах. Что характерно - на префиксы там делается упор, а имена переменных сплошь и рядом несемантичны.

 

@>-`-,--`,--

Спасибо

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

[Malandrinus 615]

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

 

В настоящее время во многих языках эта нотация бесполезна, поскольку не соответствует современным реалиям. К примеру, она ничего не даёт в случае массированного использования ООП, поскольку в этом случае основной упор делается на использование разных классов, а на каждый класс префиксов не напасёшься. Также, одним из самых полезных элементов венгерской нотации является различение переменных и указателей, но во многих языках (и в частности Lua) указателей нет, а почти всё представлено единообразно ссылками.

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

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

 

Именно поэтому в стандартной библиотеке С++, а также в boost принят подход записи всего только нижним регистром, а макросов - только верхним. Лично я нахожу такой подход достаточно комфортным и в других языках и практикую его в том числе в Lua. Моё субъективное мнение, что сам идентификатор вполне способен обеспечить понимание сути того, что за ним стоит, если конечно дать ему внятное имя.

 

ЗЫ:

Препод ругает студента: "Что у вас тут, A,B,C... Надо делать длинные мнемоничные идентификаторы.". В общем, проел всю плешь. На следующий раз студент приносит программу, а там переменные названы: длинный_мнемоничный_идентификатор_номер_один, длинный_мнемоничный_идентификатор_номер_два, ...

 

[Artos 99]

xStream, посмотрел коды сендбокса ... приятно удивлен. :-)

Как уже упомянул, показалось знакомым и ... даже не на 50% а на почти 100%.

Ведь это же продолжение развития того, что было заложено в АМК-моде, кастрировано в ЧН (xr_s.script) и чем собственно сам занимаюсь эти годы моддинга Сталкера. Т.е. это интегратор (каркас конструктора) на котором можно строить любой по функциональности мод. Только еще бы добавить функционала аля- подзабытый 'xrs_ai.script'.

Собственно на эту тему могу говорить очень много, т.к. суть этого сэндбокса и SIMBION'ов - едины, и критиковать/хвалить то, чем занимаешься сложновато. ;-)

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

 

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

Собственно почти(!) все в сэндбоксе так или иначе реализовано у меня в моде, но более кучеряво (в моем варианте). Это и плохо и хорошо. 'Плохо' - - это значит вариант этого сэндвокса более оптимизирован, а 'хорощо' - он менее функционален. По порядку:

 

1. О функции вывода в лог (vis_log) лучше промолчу ... еще во времена АМК-мода (1.3) это было первое, что я начал править и ... выкинул.

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

 

2. О регистрации модулей:

Я все же сторонник выносить из скриптов то, что может потребовать правке игроком или другим модмейкером в конфиг-файл. Неаккуратная запись/правка в скрипте - блокирует весь конфиг-скрипт (xs_sandbox_binds.script), а вот прочитать конфиг-файл (*.ltx) можно и безопасно и пропустить некорректности.

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

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

 

3. О регистрации коллбэков (событий):

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

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

 

4. О работе сэндбокса (trigger):

Очень удачно введена проверка на зависание модулей! Подспорье моддейкеру может дать немалое при отладке кодов.

С Вашего позволения добавлю в свой вариант аналогичный функционал.

Удачно реализована и остановка цепочки обработки одного события (у меня слишком кучеряво сделано).

 

5. Ну и о том, что бы я подправил:

5.1. В 'event:trigger' чуть хромает логика условий. Ну зачем при 'data_table == nil' пропускать до цикла и даже в него подставлять пустую таблицу, по которой все одно не будет перебора полей? Отсечь все это в самом начале:

--/ triggers event
function event:trigger(data_table)
  if type(data_table) == 'table' then
    for k,v in pairs(tData) do
      self[k] = v
    end
  elseif data_table ~= nil then
    vis_log("sandbox error: event's data should be a table or nil. " .. type(data_table) .. " is passed")
  end
  trigger(self)
end

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

 

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

 

Пока закругляюсь, хотя на эту тему могу порассуждать очень много ... :-)

 

xStream, осмелюсь все же спросить, а какова причина появления этого кода (сэндбокса)? Это из старых загашников или Вы вновь чуток пробуете кодить для Сталка? Готов в этом случае (для сэнд бокса) быть типа спаринг партнером (критиком) или просто партнером, дабы этот конструктор все же увидел свет (был реализован) в других модах ...

 

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

malandrinus, если это все для тех, кто начинает программировать - полностью соглашусь, но если это все же критика того, что, например, мною используется устаревшая рудиментарность - начну оббороняться ... ;-).

Мне, например, наплевать, что модно стало пить обезжиренное молоко, есть бутербродное "масло", пить тоники, поменьше соли/сахара и т.п. ... Ел жирное, пил крепкое, солил по вкусу - и буду так делать далее несмотря на "немодность и устарелость".

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

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

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

[xStream 86]

xStream, осмелюсь все же спросить, а какова причина появления этого кода (сэндбокса)? Это из старых загашников или Вы вновь чуток пробуете кодить для Сталка? Готов в этом случае (для сэнд бокса) быть типа спаринг партнером (критиком) или просто партнером, дабы этот конструктор все же увидел свет (был реализован) в других модах ...

Ни то ни другое, в принципе Это было больше для того сделано, чтобы освоить в луа то, что я использую в других языках, заодно показать силу ООП (настоящего, а не псевдо) на реальных примерах и в реальных жизненных условиях. Ибо то, что громоздят сейчас - либо биндеры и этим все сказано, либо для ИИ схем, там тоже все ясно. Но я бы переписала все свои схемы, если было бы не лень xD. А вот реального понимания и использования ООП - нет. Спасибо луабинду за подобный функционал (типа "классы") и реализацию наследования. А главное - инкапсуляция.

В принципе - это практически самоцель. Я написала под действием ностальгии, рада, если кому-то пригодится.

Часть замечаний справедлива, и в то же время - не очень. Дело в том, что это - концентратор. Тут все в одном месте и отслеживать это все можно легко и просто. Для отрегистрации модуля его достаточно тупо удалить (или переименовать, сменить расширение), и ничего не поломается. А что касается лога - даже спорить не буду. Мне нужно было отлаживать, я не хотела использовать никаких примочек никаких модов. Взяла то, что реализуется просто и не тянет зависимостей. Можете его убить у себя, если будете использовать. Что касается pcall, то я преднамеренно не стала оборачивать в него. Я считаю, что все-таки эта штука не для совсем новичков, хотя и может быть ими использована.

 

Только еще бы добавить функционала аля- подзабытый 'xrs_ai.script'.

А зачем? Это реализуется в виде модулей, которые либо есть, либо нет. Генерировать же можно абсолютно произвольные события типа "scheme_addCommonPrecondition" или "game_blowout". Кроме того, и это очень важный момент, у нас работа идет с объектом, который можно передавать по ссылке, а это значит, что если использовать альтернативное "выстреливание", то можно из события в месте, где выстрелили, получить, например, измененные данные. Ничто не мешает внутри обработчиков к ивенту присобачивать произвольные данные (или менять существующие - они, измененные, попадут в следующий обработчик). Я считаю, это неявной, но ОЧЕНЬ полезной штукой.

 

Ну зачем при 'data_table == nil'

Садись, два! © Ну да. Верно. ПО сути там есть несколько подобных штук некритического характера. По хорошему - из песочницы надо убрать все логи вообще. И натыкать проверок. Ибо в таком случае песочница станет багонепробиваемая Ведь она, по сути, должна просто транслировать события. При этом никак не должна реагировать или добавлять баги. Это мое мнение.

 

мною используется устаревшая рудиментарность - начну оббороняться

Да Боже упаси Никто не трогает венгерку.

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

[kamikazze 266]

Artos

 

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

 

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

 

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

 

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

 

 

[Artos 99]

kamikazze, давай перестанем холиварить и обсуждать/навязывать вкусы других!

(алаверды) Также не нужно аргументировать неудобство венгерки с читабельность кодов как чтение обычных текстов ...

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

(брек, иначе начну нападать ... )

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

[xStream 86]

С учетом вышеоговоренного, и плюс кое-какие свои соображения привели к правкам - http://dl.dropbox.com/u/46539648/xs_sandbox.script

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

[Artos 99]

xStream: Я написала под действием ностальгии, рада, если кому-то пригодится.

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

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

 

А двойку - это зря-я-я ... ИМХО, если присутствует подобная примочка, то должна а) минимизировать свое присутствие тратой ресурсов/тактов б) быть функциональной. Для готового продукта, конечноже подобное лучше выкинуть и концентратор сделать 'непробиваемам', но пока код в отладке - концентратор как раз очень удобен для отлова 'всего в купе'.

 

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

[kamikazze 266]

Artos

 

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

 

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

 

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

[xStream 86]

А двойку - это зря-я-я

Это мне двойка Не тебе. Я учла и исправила

[Artos 99]

xStream: Включение/выключение модулей производится тупо удалением файлов или их переименованием

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

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

[xStream 86]

Это неправильно. Зависимостей должно быть минимум. И ничто не мешает использовать data-only скрипты. И использовать как в модуле, так и в других скриптах.

[Artos 99]

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

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

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

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

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

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

 

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

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

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

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

[xStream 86]

Кто сказал, что модуль должен состоять только из одного файла? Так, мысль на подумать.

Вторая мысль на подумать - разве речь шла о том, чтоб ВСЕ скрипты делать модулями?

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

[Artos 99]

xStream, но я все же имею ввиду конечно не скрипт-файл в качестве модуля, а некий законченный фрагмент алгоритма для мода.

Конечно же можно писать и в несколько файлов, но тогда начинают расти 'транспортные' расходы передачи информации между файлами оодного модуля ...

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

 

Хотел бы по багоустойчивости сэндбокса высказать мысль:

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

 

И по функциональности:

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

(Подобное реализовано у меня и попробую перенести в данное исполнение)