eu_tomat

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

А как они его умудрились выронить? Они его вместо гранаты что-ли метнули? Технические возможности реализации – вторичный вопрос относительно единодушного одобрения всех админов. Если бы нашлась возможность ограничить в улье использование разных перерабатывающих машин, как индустриальных, так и магических, то жадные до лагозаводов игроки вынуждены были бы строиться в мирах с незащищенными приватами. А при возможности отключить PVP это будет, считай, арена, которую ты так настойчиво просишь в темах об ивентах «Unreal Tournament: Resurrection». В целом это было неплохо. Единственное, тебе нельзя было давать доступ к SGSC – в качестве исключения и для сохранения баланса. И не потому, что к тебе здесь плохо относятся, а из жалости к другим игрокам. Больно уж ты злой был. Помнится, я тоже думал, «надо бы поиграть на сервере, но развиваться придётся с нуля, а там на сервере страшный @qwertyMAN носится, всех убивает, подожду-ка я вайпа, там хотя бы возможности равны будут». А потом @Alex заявил, что на следующем сервере комплектующие для компов будут на магическом алтаре создаваться. От этого я так расстроился и обозлился, что @qwertyMAN показался мне не самой страшной частью геймплея. Да, нубиков надо как-то защищать и везде, где возможно, предупреждать, что гриф на сервере разрешен, и что есть способы защиты. А когда нубик уже развился, разжирел и хочет стать еще жирнее – ему придется либо нагуливать жирок так же медленно, как и раньше, либо идти на риск.

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

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

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

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

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

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

Тогда продолжу. Продолжу даже не смотря на угасание интереса, т. к. благодаря примитивности задачи в ней на первое место выходят вопросы эргономики, а им на форуме уделяется мало внимания. Использование роботов помогает минимизировать механические, интеллектуальные действия игрока, его время. Исходя из этого и оценивается решение этой задачи. Регрессом я посчтитал новый способ взаимодействия системы с игроком в сравнении со старым. Скриншот, в котором нашлось место восьми сундукам, но не нашлось место монитору, воспринимается как рекомендуемая конфигурация для новой схемы. Возможно, это не так, но в чем тогда был смысл скриншота? Идея избавиться от внешнего сундука сама по себе прекрасна. Если всё сделать правильно, новая схема окажется удобнее старой. Но сильное неудобство возникает в случае, когда используется больше одного улучшения инвентаря, а монитор отсутствует. Причем, одного лишь монитора недостаточно, нужно еще и программу привести в соответствие с новой схемой. Теперь недостаточно выводить на экран лишь один компонент, на котором споткнулся робот; требуется выводить весь список. Это, кстати, было бы полезным и при работе через сундук, хотя и не таким важным. Чтобы не тратить кучу времени на многократное сканирование БД, его следует выполнить лишь один раз, перенеся все данные в таблицу. А содержимое таблицы проверяется быстро. Перекладывание предметов из слота в слот выполняется не очень быстро, но происходит это в то время, пока игрок бегает на склад за компонентами, и для игрока это всяко удобнее, чем ручная прокрутка инвентаря. Можно, конечно, обойтись и одним улучшением инвентаря, но, думаю, что с тремя улучшениями, монитором и соответствующей программой система станет удобнее и быстрее: внешний сундук становится совершенно ненужным, перемещать предметы из сундука не требуется, отслеживание изменений в инвентаре ускоряется за счет обработки сигналов. Почему с тремя улучшениями? Потому что инвентарь игрока имеет всего 36 слотов. И пока игрок ходит за следующей порцией компонентов, робот успеет раскидать уже имеющиеся по слотам реактора. Скорее всего, достаточно будет даже двух улучшений инвентаря, но с одним робот вряд ли будет успевать перемещать компоненты в реактор, пока игрок шифтом перемещает их в инвентарь робота. С одним улучшением инвентаря игроку придётся тратить время на ожидание, пока освободится инвентарь робота. Сколько я ни экспериментировал, порядок поступления сигналов никогда не нарушался. В течение 1-2 секунд у меня ни одно событие не было проигнорировано, а более экстремальных экспериментов я не ставил.

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

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

А что такое 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" не подразумевает "с минимальным индексом".

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

Вопросы: * Каков планируемый размер арены? * Будет ли арена иметь какие-либо препятствия для движения дронов? * Могут ли игроки во время соревнований мешать дронам, преграждая им путь? Предложения: Контрольные точки Роботы в качестве контрольных точек могут сами доползти до нужных позиций, а между раундами – сменить позиции. Мониторинг активности дронов Как уже говорилось, дроны естественным образом отслеживаются во время захвата контрольной точки. На остальные действия дроны постараются не терять много времени, поэтому провалы в их отслеживании будут не очень большими. На мониторе можно для каждого дрона выводить время, прошедшее с момента последней попытки захвата какой-то из точек и координаты этой точки. Прошивки дронов По-моему, прошивке достаточно скачать прогу игрока с сервера, а на случай ошибок циклически запускать ее в pcall. Прошивки всех дронов одинаковые, и задачей сервера будет выдать дрону его цвет и программу. Цвет команды передаётся в программу либо параметром функции, либо глобальной переменной. Аналогично передаётся список координат зарядников. Управление программам дронов можно будет передать одномоментно по сигналу сервера, исключив возможность фальстарта. Чтобы избежать порчи прошивок дронов программами предыдущих участников, при передаче дронов следующим командам следует заменять EEPROM на заведомо корректные. Комплектация дронов А много ли нашим дронам нужно? Обязательна только беспроводная карта. Желателен апгрейд навигации. Можно обойтись и без него, но боюсь, опять большинство дронов не сможет взлететь. Энергия дронов Тут надо исходить из размеров поля и частоты расположения зарядников. Пусть заряда хватает примерно на один облет периметра поля.

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

И чем GET-запрос от OpenComputers отличается от любого другого GET-запроса?

Все могут выполнить перебор сторон в цикле. Поэтому вопрос сужается: Как определить наличие сундука с определенной стороны адаптера?

А откуда сервер знает, кто посылает id? Запрос от OpenComputers не отличается от запроса, полученного от обычного компьютера.

Где записывается адрес компьютера OC? Кто не пускает?