Лидеры

PlayerMonitoring - программа мониторинга посещения игроками некой области. Это может быть ваша база или какое-то другое интересующее место. Позволяет сканировать область на наличие игроков раз в N секунд выводить список игроков на монитор выводить список игроков на гист уничтожает gist id и токен авторизации гитхаба при приближении опасных игроков ближе чем на 20 блоков - чтобы сохранить логи поддерживаются радар из Computronics и детектор сущностей из OpenSecurity Github: https://github.com/hohserg1/OpenComputersPrograms/tree/master/player-monitoring Видео-демонтрация Текстовая инструкция по установке 1. Это программа для HoverHelm, поэтому сначала нужно установить HoverHelm-сервер (pastebin run xh61Yx8a) 2. Далее установите сканирующее устройство(их можно сделать несколько) Его минимальная конфигурация(на основе сервера 1 тира): 3. Подготовьте для него eeprom (командой prepare_eeprom <device name> modem <port>) и убедитесь, что устройство коннектится к серверу 4. После скачайте radar.lua (wget https://raw.githubusercontent.com/hohserg1/OpenComputersPrograms/master/player-monitoring/radar.lua radar.lua) radar.lua должен лежать в папке programs конкретного устройства 5. В начале файла есть секция конфигурациии, настройте в ней gistId и githubToken, если хотите выгружать логи на гист. Подробнее про конфигурацию гиста: 6. Запустите программу из терминала HoverHelm командой your device name>radar Также можно настроить автозапуск. Для этого: 7. Скопируйте дефолтный конфиг из /home/hoverhelm/device_core/lib/config.lua в /home/hoverhelm/devices/<device name>/lib/config.lua 8. Установите опцию autorun в конфиге устройства на значение "radar"

Программа умеет управлять одним транспозером, для перемещения определенных предметов между инвентарями. Предметы можно перемещать/не перемещать проверяя их unlocalized name и meta. При запуске программы откроется графический интерфейс, в котором отобразится ID компонента транспозера, доступные инвентари, их названия, стороны, количество слотов ... Управление в программе: Для работы программы необходимо создать один или несколько правил (В программе они называются фильтрами. filters). Новые правила создаются нажатием клавиши INSERT на клавиатуре. При нажатии на эту клавишу вы попадете в меню настроек только-что созданного фильтра, в котором вы сможете настроить как именно, что и куда надо перемещать, используя данный фильтр. Виды полей и их описание: Алгоритм сортировки: Программа последовательно проходится по всем фильтрам в порядке их ID и пытается вытащить предмет из инвентаря источника (input side, input slot) и положить его в инвентарь приемник (output side, output slot), попутно проверяя совпадает-ли unlocalized name предмета с фильтром, meta с фильтром, если совпадает, то необходимое количество предмета перекладывается в инвентарь-приемник. Программа переходит к следующему фильтру. Ссылка на pastebin: https://pastebin.com/YQdYSa77 При корректном выходе из программы (С помощью BACKSPACE) программа сохранит конфигурацию в файл в корне файловой системы /filter.txt. Удаление этого файла сотрет конфигурацию. Буду благодарен за конструктивную критику по поводу качества кода. Скрины:

Теперь я предлагаю разобрать таблицу inventories и код, работающий с ней. Сейчас эта таблица строится при запуске программы таким образом: local function initInventories() for i = 0, 5, 1 do local name = transposer.getInventoryName(i) local size = transposer.getInventorySize(i) if name then table.insert(inventories, newInventory(i, name, size)) end end end Здесь я бы предпочёл избавился от вызова функции newInventory. Хотя быстродействие этого участка кода и не критично, но оно немного увеличится. А главное, упростится обслуживание кода спустя месяц-другой: не потребуется искать функцию newInventory, чтобы вспомнить детали её работы. Необходимые детали окажутся в месте непосредственного их использования: table.insert(inventories, { side = side, name = name, size = size, stacks = {} }) Есть и не столь очевидная оптимизация. Бегло изучив код, я предполагаю, что более эффективно себя покажет другой формат таблицы. И строить её следует так: local function initInventories() for side = 0, 5 do local name = transposer.getInventoryName(side) if name then inventories[side] = { name = name, size = transposer.getInventorySize(side), stacks = {} }) end end end Быстродействие этого участка кода увеличивается незначительно, но для сохранения работоспособности программы вслед за ним потребуется переписать и другие участки, новые варианты которых могут исполняться как более, так и менее эффективно. Для оценки общего изменения эффективности требуется более подробный анализ. В дальнейшем таблица inventories используется в следующих функциях: В функции drawInfo текущий код for i = 1, #inventories do local inventory = inventories[i] gpu.set(1, i + 9, inventory.side .. " : " .. inventory.size .. " : " .. inventory.name) end будет немного усложнён и замедлен: local i = 0 for side = 0, 5 do if inventories[side] then i = i+1 gpu.set(1, i + 9, side .. " : " .. inventories[side].size .. " : " .. inventories[side].name) end end Но содержащая его функция drawInfo вызывается один раз при запуске программы, а также используется в функции drawAdditional, которая вызывается лишь во время редактирования фильтров пользователем, что должно происходить редко. В функции getStacks текущий код for i = 1, #inventories do local inventory = inventories[i] inventory.stacks = transposer.getAllStacks(inventory.side) end также будет усложнён и замедлен: for side = 0, 5 do if inventories[side] then inventories[i].stacks = transposer.getAllStacks(inventory.side) end end Вызывается эта функция один раз при запуске программы, и далее каждый раз в главном цикле программы, то есть часто. Это уже неприятно и заставляет сомневаться в правильности смены формата таблицы inventories. В функции getInventoryBySide текущий код for i = 1, #inventories, 1 do local inventory = inventories[i] if inventory.side == side then return inventory end end будет сильно упрощён и ускорен: return inventory[side] Благодаря этому от вызова функции getInventoryBySide можно будет полностью отказаться. Количество вызовов функции getInventoryBySide в основном цикле равно удвоенному количеству фильтров. Даже если фильтр всего один, такая оптимизация уже позволит снизить общую нагрузку, создаваемую программой. По совокупному снижению нагрузки я считаю данную оптимизацию полезной. Также, если есть желание максимально повысить быстродействие программы, пожертвовав потреблением памяти, можно сформировать сразу две таблицы. Одну с номерами рабочих сторон транспозера для упрощения их перечисления, где это требуется, и вторую таблицу с ассоциативным доступом к нужной стороне транспозера без необходимости использовать перечисление.

Думаю будет полезно https://gitspartv.github.io/lua-patterns/

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