Лидеры

Некоторое время назад возникла необходимость иметь доступ к файлам с разных компьютеров. Для такого уже есть программка от @Zer0Galaxy, но ей невозможно пользоваться, поскольку сервер падает при открытии файла (ибо модем заставляют переслать таблицу с функциями файла, а он в такое не умеет). В октябре я засел писать свою версию (еще не зная о программе "FTP"), писал с большими перерывами, а потому первая более-менее рабочая версия у меня получилась только сейчас. Данная система работает несколько иначе, она выделяет под сервер не определенную папку, а диск целиком, являясь, фактически, прокси-прослойкой между диском сервера и ОС клиента, также на стороне сервера есть два уровня логирования запросов (в текстовый файл). "Лэйбл" передается напрямую с реального удаленного диска, адрес тоже соответствует реальному, но без всех тире и с приставкой "-rfs". Посмотреть весь код можно на ГитХабе Как развернуть сеть: Про режимы работы и уровни логирования: Примите во внимание, что обмен сетевыми пакетами требует некоторого времени, поэтому чтение/запись данных (особенно малыми блоками) может занять продолжительное время. Возможно, в будущем, попробую снизить задержки. Еще, если кто-то нашел в программах баг или недоработку (а таких может быть много), просьба сразу сообщить об этом. А если вы еще и скажете, как решить эту проблему, то цены вам не будет))).

Ладно, позже попробую реализовать. Если получится, добавлю в качестве третьего режима (первые два режима все же более надежны и стабильны, поэтому пускай будут)

Начнём пожалуй с самого начала, для оптимизации программы разберём предложенный код поэтапно 1 local sides = require "sides" библиотека sides на 1й строке - этот интерфейс предоставляет таблицу названий, для работы со сторонами блоков в формате: Низ (bottom): 0 , Верх (top): 1 , Тыл (back): 2 , Перед (front): 3 , Право (right): 4 , Лево (left): 5 пример для работы с контроллером красного камня: 1 local component = require("component") 2 local sides = require("sides") 3 local rs = component.redstone 4 rs.setOutput(sides.left,15) здесь использован rs.setOutput(sides.left,15) на 4й строке (включить сигнал с лева, с силой сигнала 15), без библиотеки sides пришлось бы указать сторону в формате rs.setOutput(5,15) Вот только в коде эта библиотека не используется, вызывать её не требуется 3 local component = require "component" библиотека component на 3й строке - этот интерфейс используется для доступа и взаимодействия компьютера с компонентами тот же пример для работы с контроллером красного камня: 1 local component = require("component") 2 local rs = component.redstone для того чтоб взаимодействовать с контроллером красного камня необходимо его назначить компонентом 2 local rs = component.redstone Вот только ни какие взаимодействия с компонентами в коде не происходят, вызывать её не требуется 5 size=robot.inventorySize() глобальная переменная size на 5й строке вызывается один раз при запуске программы и принимает значение последнего слота в инвентаре робота, который при одном улучшении инвентаря равен 16 ячейкам желательно назначать переменные локально 5 local size = robot.inventorySize() чтобы она не вносила изменения в другие программы за пределами данного кода 6 local function Text() 7 os.execute("cls") 8 print("РОБОТ РАБОТАЕТ!! Создатель - GooodGame") 9 print("Доработал-atomzerg") 10 end 12 Text() функция Text() вызывается только один раз на строке 12, её можно упростить 7 os.execute("cls") 8 print("РОБОТ РАБОТАЕТ!! Создатель - GooodGame") 9 print("Доработал-atomzerg") также вопрос а требуется ли она вообще, достаточно указать что за программа сейчас работает print("работает установщик блоков") теперь касательно основного тела программы: 16 robot.select(active_slot) 17 if robot.count(active_slot) == 0 then 18 active_slot = active_slot + 1 end 19 if robot.select(active_slot) ==size then 20 active_slot = 1 end 21 if robot.place() == false then active_slot = active_slot + 1 end 22 if active_slot == size then active_slot = 1 end 23 robot.place() текущий алгоритм работы: строка 16 выбирается активный слот инвентаря робота из переменной active_slot , при первом запуске она равна 1 строка 17 проверяется значение слота (в данном случае 1) и если он пустой то строка 18 к глобальной переменной active_slot плюсуется 1 строка 19 если выбран последний слот инвентаря робота то строка 20 переменная active_slot меняет значение на 1 строка 21 если робот не смог поставить блок то к активному слоту плюсуется 1 строка 22 если переменная active_slot равна последнему слоту робота то переменная active_slot меняет значение на 1 строка 23 робот ставит блок без проверок успешно или нет Вывод: в текущем алгоритме творится каша использован не оптимальный метод выбора заполненного слота назначая переменную active_slot если робот не может поставить блок то назначается следующий слот инвентаря независимо от того если там руда или нет, причиной не возможности поставить блок может быть из за того что блок ещё не сломали, или другой робот установщик поставил его раньше, в итоге будет постоянно перебирается инвентарь тратя время в пустую отдельно хотелось бы обратить внимание на форматирование кода, читать его затруднительно общепринято использовать для lua два пробела, да это не обязательно но сильно улучшает восприятия написанного кода второе - это как написаны логические элементы, тут не выделены начало и конец а также выполняемые условия каждое условие проверяется отдельно, хотя логичное было бы остановится на том которое соответствует требованию вот так должен был выглядеть код при соблюдении общепринятых норм while true do robot.select(active_slot) if robot.count(active_slot) == 0 then active_slot = active_slot + 1 elseif robot.select(active_slot) == size then active_slot = 1 elseif robot.place() == false then active_slot = active_slot + 1 elseif active_slot == size then active_slot = 1 end robot.place() end Использовать кучу условий и метод счётчика для выбора заполненного слота в инвентаре робота не эффективно правильнее применить цикл перебора инвентаря пропуская пустые слоты и при нахождении полного слота выбрать его, остановив дальнейший перебор for slot = 1, inv do if r.count(slot) > 0 then r.select(slot) break end end вместо кучи условий с переменной active_slot можно использовать только одно условие, (если выбранный слот пуст) if r.count() == 0 then также если инвентарь робота пустой, то не логично перебирать его до посинения, правильнее остановить поиск, пока в инвентаре не появится новые блоки, и при добавлении новых блоков, сразу его выбрать if slot == inv then local e, slot = event.pull("inventory_changed") r.select(slot) end проверять поставил ли робот блок нет необходимости if robot.place() == false then особенно если использованы несколько установщиков блоков, программа будет простаивать r.place() Собственно готовый код занимает всего 21 строку, осталось его только собрать до кучи Но я этого делать не буду, и вот почему: Эта программа при лагающем сервере вызывает рассинхрон при быстрой смене блока, устанавливая и разрушая его сервер выдаёт финты типа моментального разрушения или дюпа Подобные действия не способствуют популезации мода OpenComputers Рекомендую проголосовать за удалении этой темы как потенциально нежелательной

А почему бы не сделать в этом случае виртуальные файлы с очередью записи на диск? Типо, если юзер открывает файл для чтения, то он читается полностью и помещается в таблицу, а файл закрывается. Если юзер открывает файл для записи, то запись идет в таблицу, а при закрытии добавляется в очередь записи на диск. Плюс еще какие-то условия для соблюдения прозрачности.