eu_tomat

Плохо понимаю вопрос. Как одно связано с другим? Если задача в том, чтобы выложить предмет из внутреннего инвентаря робота в определённый слот сундука, то можно использовать контроллер инвентаря: inventory_controller.dropIntoSlot(side:number, slot:number[, count:number]) А если задача состоит в том, чтобы никогда не использовать robot.select, то потребуется организовать процесс таким образом, чтобы нужный предмет всегда находился в первом слоте внутреннего инвентаря робота. Кстати, а какова причина отказа от robot.select? Существует какая-то практическая цель такого ограничения, или это чисто теоретический интерес?

Я сейчас почитал код и увидел там имя автора. Да, я знаю товарища aka_zaratustra, смотрел записи некоторых его стримов. Помню, что он играл на очень кастомизированной сборке. Моды в ней регулярно дописывались под его игровые нужды. Поэтому если есть желание играть так же, как и он, я предлагаю скачать его собственную сборку. Судя по уведомлениям в Дискорде, он и сейчас продолжает вести стримы. Подробнее сказать я не могу, т.к. недостаточно внимательно слежу за его творчеством. Ссылка на его сервер в Дискорде: aka_zaratustra. Где-то там можно найти сборку, на которой он играет. Заодно предлагаю подписаться и на наш сервер в Дискорде: ComputerCraft.RU, там тоже можно получить ответы на вопросы программированию.

Ролик посмотреть не сложно. Сложно помочь человеку, из которого приходится клещами вытаскивать информацию. Поэтому я предлагаю придерживаемся простых и понятных решений: Ищешь OS для ComputerCraft — используй CrfatOS. Ищешь OS из ролика @ECS, дождись ответа самого @ECS. Ищешь помощи в написании OS такой же как в ролике, сформулируй, в чём конкретно требуется помощь. Это, конечно, не гарантирует получения помощи, но при наличии специалистов по запрошенному вопросу, а также их заинтересованности получить помощь вполне реально.

@ECS, объясни, пожалуйста, что хочет этот товарищ?

А зачем устанавливать CrfatOS? Достаточно включить компьютер, и CraftOS запустится автоматически.

А CraftOS чем не устраивает?

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

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

А где упоминание о том, что этот код может работать для 1.7.10? Я не припоминаю сообщений об этой механике в официальных релизах. В неофициальных модификациях, конечно, возможно всякое. Актуальный официальный релиз для 1.7.10 можно скачать здесь: https://github.com/MightyPirates/OpenComputers/releases/tag/1.7.10-forge/1.7.7 Да, не может. Но это вообще не проблема. Не может робот, зато может компьютер. Это даже к лучшему, т.к. жёрдочки обновляются по их внутренним таймерам, а робот действует по динамически обновляемому расписанию. Поэтому компьютер может считывать обновлённые данные жёрдочек меньшим количеством операций.

А другие — это кто конкретно? Где можно посмотреть код их программ селекции, использующих геосканер? Для 1.7.10 с незапамятных времён существует аддон OpenPeripheral, позволяющий с помощью адаптера получить большой массив информации о растении на жёрдочках. Перевод описания API когда сделал @Xytabich. Конкретно про API жёрдочек можно почитать здесь: OpenPeripheral: Integration #5 IndustrialCraft 2

Хорошо. Вот тебе задание. Сделай реализацию ивента, которую можно было бы перенести на наш сервер.

Невыносимая лёгкость бытия? Я думаю, жанр песочницы не подходит игрокам, которые не могут самостоятельно придумать себе занятие в ней. Для таких игроков создаются специальные тематические сервера с тщательно перебалансированными рецептами. Возможно, когда-нибудь будет у нас и такой сервер, но на Школосервере у нас сохранится максимальная свобода и минимум принуждения. Программисты сами могут решить, что они хотят запрограммировать или протестировать в конкретный момент игры. Скажи, что тебе мешает самостоятельно придумать задание, выполнить его и предоставить отчёт, как это делает, например, товарищ @logic?

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

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

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

Тут я не понял. Нет, это не просто конфигурация, а способ программирования. И да, программа целиком загружается в оперативную память. Хорошо. А сколько символов могут сильно помочь? Каково минимальное значение? Самая дешёвая плата для робота — красная плата первого уровня позволит принимать чуть менее 80 байт в секунду.

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

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

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

Предисловие Здравствуйте, друзья! Основная активность сообщества переместилась в чатики дискорда. Именно в них предпочитают задавать свои вопросы начинающие программисты. Кроме этого чаты удобны и для мозгового штурма задач с неочевидным на первый взгляд решением. Такой режим обсуждения позволяет не только быстро наполнить котёл сырых идей, но и так же быстро сварить их, отсеяв явно неработоспособные и выбрав более-менее применимые. Но финальная доводка сложных идей в общих чатах кажется мне нецелесообразной, т. к. традиционно общение в чате не предполагает вдумчивости и аккуратности формулировок. В итоге обсуждение начинает двигаться по замкнутым петлям. Поэтому я предлагаю переносить на форум хотя бы часть обсуждения. Для фиксации более-менее оформленных идей форум подходит идеально. Обсуждать явно сырые идеи можно всё так же в чате. Сразу оговорюсь, что в этой теме я буду излагать свою субъективную точку зрения. С самого начала обсуждения у меня имелось представление о допустимости тех или иных решений, и оно по большому счёту не изменилось. Изменения коснулись лишь аргументации. Но некоторые из идей показались мне любопытными и достойными упоминания в этой теме. Задача В этой теме я предлагаю обсудить оптимальную архитектуру банковской сети игрового сервера. Банк принадлежит администратору, он же управляет сетью, но сеть имеет публичный API с доступом в неё других игроков для проведения банковских операций. Во время мозгового штурма в дискорде были рассмотрены все варианты обмена данными клиентов с банковской системой: проводные сетевые платы, беспроводные, связанные, интернет-платы. Также были рассмотрены некоторые их сочетания. Кроме того прозвучали предложения дописать моды, аддоны и серверные плагины. Для начала я перечислю забракованные варианты с причиной отказа от них. Возможно, я забыл какие-то из них, но перечитывать несколько тысяч строк обсуждения в чате я не буду. Если чья-то идея оказалась незаслуженно забытой, я прошу других участников описать её отдельным постом. Интернет-платы были отброшены разработчиком банка ради сохранения игровой атмосферы. Коммуникация компьютеров игроков с банком должна осуществляться исключительно с помощью игровых механик без использования сервисов за пределами игры. Беспроводные сетевые платы являются ненадёжным звеном системы. Ограниченная глубина очереди событий в OpenComputers, а так же низкая скорость их извлечения приводят к тому, что несколько компьютеров, генерирующих спам на открытый порт, могут спровоцировать потерю пакетов сервером. В качестве решения предлагалось использовать промежуточные фаерволлы, но они подвержены спаму точно так же, как и основной сервер. На мой взгляд, не имеет особого значения, будет ли пакет потерян на фаерволле или же на самом сервере. Устойчивость работы беспроводных сетей игроков основана прежде всего на секретности номера порта и возможности сменить его на другой. Но так как обсуждаемая здесь банковская сеть должна предоставить публичный доступ к ней, то речи о секретности номера порта идти не может. Эта проблема, возможно, и не сыграла бы особой роли при наличии возможности быстро вычислить злоумышленника. В частных случаях это возможно. Но для общего случая такой возможности обнаружено не было. Проводные сетевые платы совершенно неприменимы для публичной сети. Такие сети потребуется защищать приватом, растянувшимся по всему серверу. В противном случае их можно легко разрушить, или подключить любого нелегального абонента. А найти его будет не проще чем в беспроводных сетях. Связанные платы я считаю наилучшим вариантом. В основе схемы лежит архитектура сети OpenNet, но без последнего слоя, реализованного на беспроводных платах. Выше я объяснил, почему считаю беспроводные платы неприменимыми для банковской сети. Изначальный вариант для меня выглядел так: В админпривате находится банковский сервер, общающийся с сетью мостов-фаерволлов с помощью обычной проводной сети. Каждый такой мост общается с единственным клиентом через пару связанных плат. Одна плата работает на стороне моста. Вторая выдаётся клиенту банка. Можно сказать, это его пропуск в систему и удостоверение личности. Если эта плата попадёт в чужие руки, игрок всё равно будет нести ответственность как за финансовые потери, так и за возможный спам с этой платы. Правда, этот спам не повредит банку, т. к. он приведёт лишь к пропуску пакетов, идущих от самого спамера, но не от добросовестных игроков. Но разработчику банка в такой архитектуре сети не понравилась её громоздкость. Так появилась идея админсредствами сделать пачку связанных плат с одинаковым адресом, получив соединение всех узлов со всеми. Но тогда возник вопрос, в каком устройстве будут размещаться эти платы. Просто выдать эти платы пользователям системы нельзя, т. к. все они имеют одинаковый адрес, и в случае спама вычислить его авторство будет почти невозможно. Можно было бы разместить их в админприватах, но тогда снова встаёт вопрос об организации последней мили. Да и проблема громоздскости не решается. Просто часть устройств переносятся из основного банка в его филиалы. Для решения этой проблемы появилась идея размещать устройства непосредственно в приватах пользвователей, но с ограничением их доступа к содержимому самих устройств. Компьютеры на эту роль не подходят, т. к. позволяют извлечь из них любой из компонентов и полностью пересобрать компьютер. Робот, да ещё и установленный от имени администратора, может принести столько разрушений, что этот вариант следует рассмотреть, когда не удалось применить более простые. Остаётся микроконтроллер. Но возникают две проблемы. Во-первых, микроконтроллер тоже потребуется защитить от разборки игроком. А во-вторых, что более важно, система остаётся такой же громоздкой, просто её части переносятся в приваты клиентов, что затрудняет её контроль. То есть, это решение не позволяет исправить заявленную проблему, но систему усложняет. Тем не менее, такая идея мне кажется любопытной, и я решил сохранить её для истории. Возможно, она натолкнёт читателей этого поста но более интересные решения. Были и другие идеи, но я не помню какая из них была бы достойна упоминания. Написание модов, аддонов и плагинов было некоторым выходом за рамки заявленной темы. Практически все предложенные идеи предлагали так или иначе изменить привычные игровые механики. @Fingercomp предложил наиболее перспективную, на мой взгляд, идею: добавить в игру блок маршрутизатора-фаерволла, который на уровне мода отсекал бы пакеты спамеров. Развивая эту мысль, я предложил использовать модифицированные сетевые платы, которые бы помещали в очередь событий лишь пакеты, принятые с адресов из белого списка. Единственное, что меня в этом случае беспокоит, это возможное злоупотребление игроками, создающими длинные бессмысленные списки, приводящие к неконтролируемому росту файлов сохранений игры. Но с этой проблемой можно было бы бороться. Во-первых, можно было бы добавить разновидности плат, доступные как игровыми способами, так и исключительно в творческом режиме. Для плат игроков можно выставить серьёзные ограничения, которые при необходимости можно было бы изменить в файле настроек мода. Во-вторых, имеет смысл подумать об общих списках для множества однотипных базовых станций, обслуживающих большую сеть мобильных абонентов. Это позволило бы не только уменьшить объём хранимых данных, но и ускорить развёртывание таких сетей. Но о том, как это всё может быть воплощено в коде, я имею весьма смутное представление. Я лишь фиксирую эту идею на форуме, чтобы она не затерялась среди других сообщений чата. Послесловие Ещё раз напомню, что я выразил лишь свою субъективную точку зрения. Извините, если я забыл упомянуть какую-то значимую идею, исказил её или же не упомянул её автора. Сообщество хорошо справилось с набросом идей. Я же был сосредоточен на критике этих идей и фильтрации защищающих их аргументов. Иначе бы у меня просто лопнул мозг. Если кто-то хочет высказать взвешенную и хорошо аргументированную позицию по заявленной теме, прошу высказываться здесь на форуме. Наброс же новых идей или уточняющих вопросов можно продолжить всё так же в дискорде.

Наверное может пригодится. Но в случае компов я совсем не уверен в этом. Для запуска первого компа всегда крафтится как дисковод, так и дискета с OpenOS. Потом обычно это добро лежит в сундуке на случай установки OpenOS на новые диски. Имея такой набор, не сложно и подлечить систему со случайно удалённым файликом. Случаи с планшетами и роботами более реалистичны. Но тут возникает другая сложность. Если игрок опытен, то он не удаляет с диска системные файлы. А если неопытен, и воспользуется твоим решением, то он не может быть уверен в том, что ты не подсунешь трояна в его систему. Такому игроку проще будет разобрать свой планшет, и собрать его с правильным диском. Тем более, интернет-плата в планшете может отсутствовать. А она, как правило, отсутствует. Как такое возможно? Игроку не хватило ресурсов на диск, который крафтится из камней, палок и повсеместно встречающегося железа, но у него нашёлся жемчуг края? Такое, конечно, теоретически возможно, но случается крайне редко. К моменту выбивания жемчуга из эндерменов у игрока достаточно железа для крафта дисков, не говоря уже о камнях и палках. А ещё возникает вопрос. Если у игрока нет дисков, то зачем ему OpenOS? Максимум, что мне требовалось в таких случаях -- запустить интерпретатор команд Lua. Но использование OpenOS для этой цели выглядит явно избыточным. Тем более, если планшет изначально спроектирован бездисковым, то его EEPROM уже содержит весь необходимый для работы функционал. При случайном повреждении EEPROM удобнее просто заменить его новым, без использования любых дополнительных EEPROM. Не знаю, какой популярности ты ожидаешь. Хорошо, если твоё решение пригодится хотя бы одному игроку. Но, надеюсь, оно заинтересует других программистов, они применят твою идею и напишут что-то более востребованное. Это тоже хорошее достижение, кстати говоря.

Почитай личные сообщения. Я предлагаю не захламлять эту тему коротким сообщениями в стиле SMS, а перейти в дискорд или IRC.

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

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