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

[Appo 86]

• Робот выставляет в реактор записанную Вами схему из базы данных  используя компоненты из сундука над ним или из внутреннего инвентаря

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

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

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

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

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

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

 

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

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

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

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

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

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

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

 

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

  
   

• Крафтим базу данных 3 ур. 
• Держа её в руке, нажмите ПКМ, что бы открыть её и нарисовать в ней схему предметами.

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

• Затем вставить базу данных  в робота  
  ( Обязательно в слот улучшения, а не в лапки )

• И запускаем

 

 

Изменено 10 октября, 2017 пользователем Appo

[Totoro 3 563]

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

[Appo Автор темы 86]

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

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

[Totoro 3 563]

Ты кстати понтовый ID для топика отхватил =) 2222.

[eu_tomat 2 155]

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

Изменено 8 октября, 2017 пользователем eu_tomat

[Appo Автор темы 86]

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

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

 

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

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

Изменено 8 октября, 2017 пользователем Appo

[BarBoss 89]

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

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

[ivan52945 75]

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

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

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

Изменено 8 октября, 2017 пользователем ivan52945

[evgkul 571]

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

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

Изменено 9 октября, 2017 пользователем evgkul

[Doob 2 749]

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

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

[Appo Автор темы 86]

Обновил программу, с учётом всей критики ( жду новую )
Старая версия

[eu_tomat 2 155]

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

 

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

[ivan52945 75]

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

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

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

 

 

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

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

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

Изменено 9 октября, 2017 пользователем ivan52945

[eu_tomat 2 155]

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

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

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

[ivan52945 75]

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

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

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

 

 

 

 

[eu_tomat 2 155]

А то и

local print = print or prn or function() end

 

А что такое prn?

[Appo Автор темы 86]

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

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

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



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

Изменено 10 октября, 2017 пользователем Appo

[eu_tomat 2 155]

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

 

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

 

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

 

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

 

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

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

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

[Fingercomp 4 409]

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

[Appo Автор темы 86]

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

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

 

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

 

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

 

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

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

 

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

 

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

 

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

 

 

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

 

 

 

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

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

Изменено 11 октября, 2017 пользователем Appo