eu_tomat

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

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

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

Сидеть в бункере и рулить роботами – скучноватое занятие, как по мне. Управляя, наблюдать за армией роботов – совсем другое дело. Для зрелищности нужна свобода перемещений, но возможности игрока влиять на мир следует сильно ограничить.

 

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

 

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

 

Можно обойтись без эффекта скорости, заспавнив побольше свиней для развития авиации.

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

Кстати, о законе.

 

За гриферами (как и за вампирами) закрепился негативный смысл, и связано это с тем, что Майнкрафт является песочницей. Там игроки лепят куличики и строят домики. Понятно, что их печалит несанкционированная порча своих творений. Это, конечно, плохо.

 

Но на индустриальном сервере, где всю нудную работу могут выполнить роботы и другие механизмы, утрата становится менее существенной. А при наличии полностью защищенной базы, сохраняющей всё самое ценное, некоторый запас роботов, инструментов и небольшое производство, потеря завода перестаёт быть трагедией, особенно, если учесть, как быстро окупают себя заводы в Майнкрафте. Если на сервере любая постройка может быть собрана и разобрана роботом, ресурсы для построек тоже добыты роботом, то и постройки и ресурсы перестают иметь решающую ценность. И, как говорит @qwertyMAN, ресурсы для грифера тоже вторичны. Первичен же сам процесс. И если процесс завязан на использование роботов, то такой процесс на computercraft.ru должен быть не только не запрещенным, но и поощряемым.

 

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

Почему перед публикацией не проверяешь код на работоспособность?

В этом фрагменте и if потерялся, и в elsif ошибка, и в кодах zn разнобой.

  print ("Знак ❶[1],❷[2],➌[3],❻[6],➒[9],Нет знака[-]")
  zn = io.read()
  elsif zn == "-" then
   cb.setName(m.."§7§o]§r§8 [§"..pcol..pref.."§8")
  elseif zn == "1" then
   cb.setName(m.."§7§o]§r ❶ §8[§"..pcol..pref.."§8")
  elseif zn == "2" then
   cb.setName(m.."§7§o]§r ❷ §8[§"..pcol..pref.."§8")
  elseif zn == "➌" then
   cb.setName(m.."§7§o]§r ➌ §8[§"..pcol..pref.."§8")
  elseif zn == "❻" then
   cb.setName(m.."§7§o]§r ❻ §8[§"..pcol..pref.."§8")
  elseif zn == "➒" then
   cb.setName(m.."§7§o]§r ➒ §8[§"..pcol..pref.."§8")
  end 

И вообще, вместо длинной последовательности elseif удобнее использовать таблицу:

local sign={["1"]=" ❶ ", ["2"]=" ❷ ", ["3"]=" ➌ ", ["6"]=" ❻ ", ["9"]=" ➒ "}
cb.setName(m.."§7§o]§r" .. (sign[zn] or "") .. "§8[§"..pcol..pref.."§8")

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

...

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

...

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

Гриферы – они как вампиры. Один грифер покусал простого игрока, и тот тоже стал грифером. Некоторые имеют иммунитет. Другие пробуют себя в роли грифера. Третьи преодолевают тягу к обогащению и превращают своё занятие в искусство.

Ну они конечно запаниковали, выронили планшет (!)...

А как они его умудрились выронить? Они его вместо гранаты что-ли метнули?

 

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

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

 

Если бы нашлась возможность ограничить в улье использование разных перерабатывающих машин, как индустриальных, так и магических, то жадные до лагозаводов игроки вынуждены были бы строиться в мирах с незащищенными приватами. А при возможности отключить PVP это будет, считай, арена, которую ты так настойчиво просишь в темах об ивентах «Unreal Tournament: Resurrection».

 

А помнишь как Алекс меня назвал частью геймплея? Когда я всех сканил и убивал?

В целом это было неплохо. Единственное, тебе нельзя было давать доступ к SGSC – в качестве исключения и для сохранения баланса. И не потому, что к тебе здесь плохо относятся, а из жалости к другим игрокам. Больно уж ты злой был.

 

Помнится, я тоже думал, «надо бы поиграть на сервере, но развиваться придётся с нуля, а там на сервере страшный @qwertyMAN носится, всех убивает, подожду-ка я вайпа, там хотя бы возможности равны будут». А потом @Alex заявил, что на следующем сервере комплектующие для компов будут на магическом алтаре создаваться. От этого я так расстроился и обозлился, что @qwertyMAN показался мне не самой страшной частью геймплея.

 

А с другой стороны новичкам, которые потно добывали рес, строили солярки, ветряки, сундуки под открытым небом размещали и прочее, было не так весело

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

Если верить Википедии, Энотни Левандовски, инженер беспилотных автомобилей Google и Uber, недавно создал религиозную организацию «Путь будущего», целью которой является развитие и продвижение реализации Божества на основе искусственного интеллекта.

https://en.wikipedia.org/wiki/Anthony_Levandowski

@@Alex, а может, нам создать раздел "Общение > Фольклор"? Пусть там народ травит байки. В мусорке лежат темы с фееричными названиями. Не заглядывал внутрь, может, и правда хлам, но каковы названия!

Школьник зверствует

Фермеры нарушители

Вскрытие папко-дома для чайников

Радиоактивный убийца

Кидалы сервера

Убийство на Черкизовском рынке!

Function zpOtz(name)

...

Вот что у меня выходит - https://imgur.com/a/OxN9y

Язык Lua чувствителен к регистру символов, ключевое слово functionпишется в нижнем регистре.

Возможности робогрифа, существовавшие во времена IT, я всегда считал частью геймплея. Это добавляло интереса к изучению роботов как для грифа, так и для защиты от него. Тогда, помнится, даже @Alex поддерживал идею робогрифа, но не все админы были с этим согласны. Некоторые из историй о том, кто, кого и как ограбил, мне было интересно читать. Да и сейчас я бы почитал с удовольствием. Вспоминается забавная история с @SDV, опубликовавшим свои похождения, когда гриф уже был запрещен.

 

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

@@qwertyMAN, Поведай нам наконец эту увлекательную историю о том, как ты угнал робота Кошака. А то нам придётся в любой теме про гриф и прочее веселье выслушивать эти намёки. Кошак забыл заприватить робота? Или ты с помощью SGSC отжал у него пульт? А может, он по неосторожности поставил твою софтинку с оставленным бэкдором? Или Кошак пользовался широковещательной передачей, а ты подслушал эфир, а потом скопировал команды?

А если я в определенный момент не успею проверить ивент и он проигнорится?

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

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

…

интерес угасает, из за не надобности этого робота

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

 

Регрессом я посчтитал новый способ взаимодействия системы с игроком в сравнении со старым.

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

 

Идея избавиться от внешнего сундука сама по себе прекрасна. Если всё сделать правильно, новая схема окажется удобнее старой. Но сильное неудобство возникает в случае, когда используется больше одного улучшения инвентаря, а монитор отсутствует. Причем, одного лишь монитора недостаточно, нужно еще и программу привести в соответствие с новой схемой. Теперь недостаточно выводить на экран лишь один компонент, на котором споткнулся робот; требуется выводить весь список. Это, кстати, было бы полезным и при работе через сундук, хотя и не таким важным.

 

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

Чтобы не тратить кучу времени на многократное сканирование БД, его следует выполнить лишь один раз, перенеся все данные в таблицу. А содержимое таблицы проверяется быстро. Перекладывание предметов из слота в слот выполняется не очень быстро, но происходит это в то время, пока игрок бегает на склад за компонентами, и для игрока это всяко удобнее, чем ручная прокрутка инвентаря.

 

Можно, конечно, обойтись и одним улучшением инвентаря, но, думаю, что с тремя улучшениями, монитором и соответствующей программой система станет удобнее и быстрее: внешний сундук становится совершенно ненужным, перемещать предметы из сундука не требуется, отслеживание изменений в инвентаре ускоряется за счет обработки сигналов. Почему с тремя улучшениями? Потому что инвентарь игрока имеет всего 36 слотов. И пока игрок ходит за следующей порцией компонентов, робот успеет раскидать уже имеющиеся по слотам реактора. Скорее всего, достаточно будет даже двух улучшений инвентаря, но с одним робот вряд ли будет успевать перемещать компоненты в реактор, пока игрок шифтом перемещает их в инвентарь робота. С одним улучшением инвентаря игроку придётся тратить время на ожидание, пока освободится инвентарь робота.

 

Как это реализовать? Разве ивенты не будут путатся в очереди? А если я в определенный момент не успею проверить ивент и он проигнорится?

Сколько я ни экспериментировал, порядок поступления сигналов никогда не нарушался. В течение 1-2 секунд у меня ни одно событие не было проигнорировано, а более экстремальных экспериментов я не ставил.

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

На данном этапе бесполезно обсуждать код, т. к. испортилась сама схема.

 

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

 

Это регресс. Не для того мы используем роботов, чтобы терпеть от них неудобства.

 

Ситуацию могли бы спасти три улучшения:

 

1) Отображение на мониторе списка недостающих компонентов поможет игроку быстро принять верное решение.

2) Перемещение в первые слоты инвентаря всего лишнего хлама, который игрок закинул в робота по ошибке, избавит его от необходимости пользоваться скроллингом.

3) Обработка события inventory_changed позволит оперативно отслеживать, что игрок положил, а что забрал из инвентаря робота, сделав ненужными повторные сканирования инвентаря.

А то и

local print = print or prn or function() end

 

А что такое prn?

или можно просто инвентарь робота юзать как буфер(или впихнуть буферный сундук)

тоесть робот сканирует сундук и берёт то, что нужно(выкладывает в буфер), и выкладывает так, как ему удобно, и уже с буфера сунет в реактор

Робот уже использует свой инвентарь как буфер с одним слотом. Задействовать все слоты робота можно. Это усложнит программу, но какие это даст преимущества?

В своём сообщении я заменил эту строку if not print then print=function()end end

на более компактную: print = print or function()end

Результат тот же, а выглядит проще.

 

Ещё обнаружил такую конструкцию:

function chekDatabase() for _ in component.list("database") do return false end return true end
while chekDatabase() do ... end

В ней я предлагаю избавиться от функции и от содержащегося в ней цикла:

while not component.list("database")() do ... end

От такой записи у меня рябит в глазах: items[slot.name][#items[slot.name]+1] = j

Визуально проще воспринимается: table.insert(items[slot.name], nil, j)

 

 

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

1) Проверять успешность попытки перемещения нужного предмета из сундука;

2) Минимизировать время между обнаружением предмета в сундуке и его перемещением. А из этого следует, что полное сканирование сундука и долгое хранение данных о его содержимом крайне нежелательно. Лучше запоминать содержимое базы данных, а обнаруженный в сундуке подходящий компонент – тут же перемещать, пока ситуация не успела измениться.

 

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

Отдебажил все, но тут ошибка

Если ошибка, значит ещё не всё отдебажил.

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

Гуглим перевод слова "unexpected", понимаем, что Lua не ожидает в этом месте встретить скобку.

Почему не ожидает? Видимо, сначала ожидает что-то иное. Вероятно, не закрыта какая-то другая скобка или конструкция.

Судя по коду, следует завершить функцию listener с помощью end.

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

 

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

 

Далее робот пред выкладкой каждой позиции заново перебирает все слоты сундука. Учитывая, что реактор может иметь 54 слота, а сундук – 108, то в худшем случае проверка содержимого слота сундука может быть вызвана 4401 раз. Однократно она выполняется 0.05 секунд, а в сумме – 220 секунд. Но можно однократно прочитать содержимое сундука, выполнив 108 итераций и затратив всего 6 секнуд. В случае нехватки каких-либо компонент и их докладывания игроком можно перепроверять содержимое сундука в следующей итерации. На случай, если в процессе выполнения программы игрок вынул какие-то компоненты из сундука, их тоже можно будет пометить как отсутствующие и повторить поиск в следующей итерации.

 

Код вообще заинтриговал. Зачем такие выкрутасы c pcall?

 

pcall(function() computer,component = require("computer"),require("component") end)

Делается это так:

computer = computer or require"computer"
component = component or require"component"

А этот фрагмент

function printT(a) pcall(function() print(a) end) end

Логичнее было бы написать так:

print = print or function()end

Такая конструкция позволит не вызывать каждый раз pcall и не менять везде в тексте программы print на printT

 

А этот код

for _, mod in component.list() do
  if mod ~= 'computer' then
    pcall(load(mod..' = component.proxy(component.list(\"'..mod..'\")())'))
  end
end

будет выполняться быстрее в таком виде:

for address, type in component.list() do
  if type ~= 'computer' and not _G[type] then
    _G[type] = component.proxy(address)
  end
end

А впрочем, зачем вообще потребовалось все компоненты копировать в глобальное окружение? Достаточно же взять лишь нужные. Тем более, нужным далее по коду даются новые имена.

 

В общем, pcall в этой программе – лишний костыль. Да и от сам робот-помощник неудобный получился.

[info]Оффтоп, перенесенный из обсуждения программы "Пакость" http://computercraft.ru/topic/2221-programma-pakost/[/info]

А в чём пакость-то?

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

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

 

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

Что за дьявольская магия? =)

Написано же - "любое значение nil по сути означает конец массива" но твой пример кода этому противоречит.

Меня тоже удивила такая логика. Но всё-таки формулировка "любое значение nil" не подразумевает "с минимальным индексом".

напечатать фразу "Hello World!" десять раз, при помощи Луа

Программисты такие программисты

...

Фомально условия ТЗ выполнены

И не говори. Программисты вечно всё усложняют.

Вопросы:

* Каков планируемый размер арены?

* Будет ли арена иметь какие-либо препятствия для движения дронов?

* Могут ли игроки во время соревнований мешать дронам, преграждая им путь?

 

Предложения:

 

Контрольные точки

 

Проблема будет тогда рандомно устанавливать эти µC.

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

 

Мониторинг активности дронов

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

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

 

Прошивки дронов

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

По-моему, прошивке достаточно скачать прогу игрока с сервера, а на случай ошибок циклически запускать ее в pcall. Прошивки всех дронов одинаковые, и задачей сервера будет выдать дрону его цвет и программу. Цвет команды передаётся в программу либо параметром функции, либо глобальной переменной. Аналогично передаётся список координат зарядников. Управление программам дронов можно будет передать одномоментно по сигналу сервера, исключив возможность фальстарта. Чтобы избежать порчи прошивок дронов программами предыдущих участников, при передаче дронов следующим командам следует заменять EEPROM на заведомо корректные.

 

Комплектация дронов

Какая комплектация у дронов? Нужно основательно продумать её, потому что дроны довольно лимитированы по компонентам.

А много ли нашим дронам нужно? Обязательна только беспроводная карта. Желателен апгрейд навигации. Можно обойтись и без него, но боюсь, опять большинство дронов не сможет взлететь.

 

Энергия дронов

Какие настройки энергии установить?

Тут надо исходить из размеров поля и частоты расположения зарядников. Пусть заряда хватает примерно на один облет периметра поля.

Laine_prikol > Как можно определить с какой стороны установлен сундук возле адаптера?

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

• Адаптер поможет узнать, что за периферия подключена, и сколько она имеет слотов инвентаря, но не может сказать, с какой стороны она подключена и к какому из адаптеров системы.
• Контроллер инвентаря в адаптере или транспозер могут сообщить количество слотов инвентаря с определенной стороны от них, но не скажут название инвентаря.
• Роботы в определенных условиях способны определить координаты, объем и название инвентаря, но роботы заметно усложняют рабочую систему.

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