Перейти к публикации
Форум - ComputerCraft
Appo

Установка схемы в реактор роботом

Рекомендованные сообщения

18915388.png

  • Робот выставляет в реактор записанную Вами схему из базы данных Grid_%D0%90%D0%BF%D0%B3%D1%80%D0%B5%D0%B используя компоненты из сундука над ним или из внутреннего инвентаря

Установка:
pastebin get NAuav7sx q

Минимальная конфигурация робота:

Версия с монитором (если Вы мажор)

18915385.png

  • Системный блок 2 ур.
  • Апгрейд "Контроллер инвентаря"
  • Апгрейд "Инвентарь"
  • Клавиатура
  • Монитор 1 ур.
  • Апгрейд "Контейнер" 3 ур.
  • Дисковод
  • Процессор с видеокартой 1 ур.
  • Память 1.5 ур.
  • Интернет карта
  • EEPROM (Lua BIOS)
  • Жёсткий диск 1 ур.

После создания робота делаем следующее:

  • Вставляем дискету OpenOS
  • Запускаем робота
  • Пишем install
  • Если будет выбор, то выбираем "OpenOS" и далее соглашаемся, вводя: "Y"
  • Перезагружаем робота
  • Скачиваем программу. Пишем pastebin get NAuav7sx q
  • Запускаем программу. Пишем: q

 


Версия через биос (без монитора)

18915387.png

  • Системный блок 2 ур.
  • Апгрейд "Контроллер инвентаря"
  • Апгрейд "Инвентарь"
  • Апгрейд "Контейнер" 3 ур.
  • Процессор 1 ур.
  • Память 1 ур.

После создания робота делаем следующее:

  • Открываем свой компьютер
  • При наличии интернет карты, пишем: pastebin get NAuav7sx q
  • Теперь перепрашиваем EEPROM (Желательно поставить пустой). Пишем flash -q q
  • Вытаскиваем только что записанный EEPROM из компьютера
  • Скрещиваем в окне крафта, робота и EEPROM

18915391.png

Так как у робота нету монитора, отсчёт об ошибках сделан на звуках.. Если он пищит, значит чего-то не хватает.


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


Процесс использования:

 

  • Либо ставим над роботом Grid_%D0%A0%D0%BE%D0%B1%D0%BE%D1%82_(Ope любой сундук 32px-Locked_Chest.png?version=24bba53667 с компонентами для схемы
    (Рекомендую сейф из Thermal Expansion, т.к. если его сломать, предметы в нём останутся)

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

    Версия с использованием EEPROM
    18944709.png


     

  • Крафтим базу данных 3 ур. Grid_%D0%90%D0%BF%D0%B3%D1%80%D0%B5%D0%B
  • Держа её в руке, нажмите ПКМ, что бы открыть её и нарисовать в ней схему предметами.

18915389.png

Начинать выставлять схему, следует с верхнего левого угла (Если у вас маленький реактор)

  • Затем вставить базу данных Grid_%D0%90%D0%BF%D0%B3%D1%80%D0%B5%D0%B в робота Grid_%D0%A0%D0%BE%D0%B1%D0%BE%D1%82_(Ope 
    ( Обязательно в слот улучшения, а не в лапки )

18915390.png

  • И запускаем :)

 

 

Изменено пользователем Appo
  • Like 6

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А зачем всё через pcall?

Эта прога универсальная. Как на биосе, так и на OpenOS работает

  • Like 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Маловато толку от такой программы. Обслуживает только один реактор и только на этапе начальной выкладки компонентов. Кроме того, после установки реактора приходится вручную, как минимум, установить робота, сундук и загрузить его компонентами, а как максимум, дождаться загрузки 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 в этой программе – лишний костыль. Да и от сам робот-помощник неудобный получился.

Изменено пользователем eu_tomat
  • Like 4

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Обслуживает только один реактор ....

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

 

По поводу замечаний и критики, огромное спасибо) Не знал как это по другому делается, делал как умел)

Обязательно всё учту и переделаю)

Изменено пользователем Appo

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Это проще транспозером делать. Попутно будет стержни менять.

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

  • Like 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Это проще транспозером делать. Попутно будет стержни менять.

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

микроконтроллером можно(подобную дичь уже писал)

Изменено пользователем ivan52945

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

function printT(a) pcall(function() print(a) end) end
Логичнее было бы написать так:

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

А то и 

local print = print or prn or function() end
Изменено пользователем evgkul

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ещё и адаптер прицепить, чтобы контролировать все функции.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В своём сообщении я заменил эту строку 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) Минимизировать время между обнаружением предмета в сундуке и его перемещением. А из этого следует, что полное сканирование сундука и долгое хранение данных о его содержимом крайне нежелательно. Лучше запоминать содержимое базы данных, а обнаруженный в сундуке подходящий компонент – тут же перемещать, пока ситуация не успела измениться.

 

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

  • Like 2

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

 

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

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

и да, в цикле на 6-й строке добавь, чтоб монитор чистило

Изменено пользователем ivan52945

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

а стоп, затупил

робот чисто расставляет схему, не следит(а думал, что следит за реактором будет)

 

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вновь обновил :) (ссылка в первом сообщении темы)

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

Вот такой комп можно собрать, используя EEPROM ( Без запуска OpenOS и без монитора )

18944709.png

Кому интересно как я изменял программу по мере критики, то вот старая версия, а вот еще старее старой

Изменено пользователем Appo

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

 

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

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

испортилась сама схема.

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

 

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

 

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

 

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

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

 

Если вы считаете что это действительно необходимо, пожалуйста упомните об этом еще раз.

 

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

 

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

 

 

При дополнении новыми возможностями не изменяя прежний принцип работы, типо это регресс? окда

 

 

 

И, да, ты же в курсе, что у робота максимум 64 слота инвентаря может быть (= 4 апгрейда)?

Спасибо) Не знал..

Изменено пользователем Appo

Поделиться сообщением


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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@@eu_tomat , думаю улучшить всё-таки можно, например ни кто не отменял апгрейд чата из conputronics :D

 

Претензий у меня нету, я лишь хотел по подробнее узнать о ваших предложениях и обсудить их :)

 

Вы и так много полезного сказали, я вам благодарен)

 

P.s.

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

Изменено пользователем Appo

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

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

 

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

 

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

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

 

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

 

Делается это так:computer = computer or require"computer"component = component or require"component"

Не совсем с тобой согласен (зачем так?!)

Да, все через pcall() делать совсем убого, но подключать библиотеки Я считаю ​нужно вот так:

local computer = require("computer")

Хоть программа может быть и в дроне, но local никогда не крашила проги :D

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я считаю ​нужно вот так:

local computer = require("computer")
Хоть программа может быть и в дроне, но local никогда не крашила проги :D

 

local, конечно же, не крашит. А вот, require не даст взлететь твоему дрону.
  • Like 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

local, конечно же, не крашит. А вот, require не даст взлететь твоему дрону.

Хотя это оригинальный способ пикнуть дроном.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Хотя это оригинальный способ пикнуть дроном.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Это проще транспозером делать. Попутно будет стержни менять.

Может, и не проще, но гораздо быстрее. При максимальной схеме реактора компоненты из сундука перемещаются роботом за 54 секунды, а транспозером – за 2.7 секунды. Разница огромная.
  • Like 2

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас

×