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

jammer312

Пользователи
  • Публикации

    48
  • Зарегистрирован

  • Посещение

  • Дней в лидерах

    3

Последний раз jammer312 выиграл 21 января

Публикации jammer312 были самыми популярными!

Репутация

36 Обычный

2 подписчика

  1. Не уверен, насколько эффективно и верно предлагаемое, но оно весьма просто. Ну и я на практике не проверял, это просто на ходу придуманный вариант. Сначала надо выяснить, какое максимальное целое число можно хранить в переменной в луа без потери точности, пусть это будет N, тогда n=sqrt(N) (округленное вниз). Длинное число реализуем как индексированную таблицу произвольной длины, в которой в каждой ячейке хранится число от 0 до n, сие есть запись числа в позиционной системе счисления по основанию n+1. Тогда операции можно реализовать по аналогии с сложением/вычитанием/делением/умножением столбиком (с учетом того, что система счисления уже не десятичная, конечно же), при этом операции над разрядами - просто арифметические операторы луа. Выбор основания гарантирует, что при сложении, вычитании и умножении разрядов переполнения или потери точности не будет. Взятие остатка от деления можно реализовать через деление, умножение и вычитание (ессно целочисленное) (a%b = a-(a/b)*b). P.S. Основание у системы счисления выбрано согласно двум соображениям: 1. оно должно быть как можно больше, чтобы кол-во разрядов, а следовательно - кол-во операций при умножении и делении, было как можно меньше; 2. оно должно быть таким, чтобы при самой "опасной" операции - умножении - не происходило потери точности (ну или переполнения, будь в луа целочисленная арифметика). Ну и "какое максимальное целое число можно хранить в переменной в луа без потери точности" сформулировано немного некорректно, я имел ввиду такое число N, что все числа от 0 до N представимы в переменной. Скорее всего с этой оценкой я переосторожничал, но лучше недооценить, чем переоценить.
  2. Ввиду отсутствия адекватных хранилищ для жидкости на сборке эвила, чей-то вопрос о способах хранения больших объемов жидкости привел к такой весьма странной идее. Предлагаемое - цистерна емкостью до 65536 ведер жидкости, что достигается связкой цистерны из мода EnderStorage с компом. Но у оной связки есть одна существенная проблема, о которой напишу в конце поста. Концепт - цистерна настроена на некий цвет, хранит некую жидкость; если в цистерне кончается жидкость, она переключается на другой цвет, в цистерне с которым жидкость есть; если же цистерна заполняется - переключается на "пустой" цвет. Вот простая реализация, которая работает (не проверял, но должна) как на ОпенОС, так и на чистой прошивке: https://pastebin.com/2V1qY4LH В начале проги три параметра, первые два задают области частот (на каких цветах цистерна может хранить жидкость), третий - задержку меж обновлениями цистерны (проверкой и переключением на цвета). Для работы нужен комп с подключенным к нему адаптером, стоящим вплотную к цистерне. Работает согласно описаному концепту. Защиты от дурака особо не содержит, разве что ограничение диапазона частот (нижняя граница взята "с потолка", но наверняка верная, верхнюю искал бинпоиском (последняя не рантаймящая)(да, мне лень было считать кол-во цветов и возводить в куб)) Преимущества: 1. Весьма дешевая 4-блоковая цистерна емкостью в 65536 ведра (можно меньше). 2. Неужто вам первого пункта не хватило? Оная цистерна может находиться в нескольких местах сразу, а также легко перемещаема, что существенно, например, при осушении незера. Недостатки: 1. Задержка меж обновлениями. Если у вас нечто, что люто быстро забирает или заливает жидкость, скорость оного будет ограничена скоростью компа. 2. "Дребезжание" на границах. Если цистерна заполнена, она будет переключаться меж эти "заполненным" цветом и следующим "пустым", что может немного задержать доступ к жидкости (когда надо выкачать, а оно "прыгнуло" в "пустой" цвет, например). Я не придумал умного способа это отлавливать, но можно придумать внешнее средство контроля (которое в этом неопределенном случае определяет состояние), или захардкодить определенный выбор. Но текущий вариант позволяет без вспомогательных конструкций и забирать, и доливать жидкость, пусть и с небольшой задержкой. 3. Возможные приколы при использовании нескольких таких канистр на пересекающихся диапазонах (например, когда из состояния неопределенности из-за небольшого рассинхрона одна канистра ушла на следующий цвет и в нее долили, а из другой в то же время забрали, и они рассинхронизировались меж собой). Проблема: Комп не может менять частоту цистерны с алмазным замком, что делает идею неприменимой на сервере (ибо с замком оно не работает, а без замка использование приравнивается к раздаче, и вас скорее всего переедет фемидой). Однако, если вдруг подобное ограничение уберут, система наверняка будет востребованной. К синглу эта проблема по очевидным причинам не относится.
  3. io,component=require"io",require"component" -- Подключаем библиотеки io и component для взаимодействия соответственно с пользователем и с компонентами redstone=component.redstone -- Получаем прокси компонента редстоуна, будь то карта или блок SIDE=2 -- Задаем сторону, в которую будет выдаваться сигнал function lock() print"Enter password" t=io.read() if t=="123" then print"Correct!" redstone.setOutput(SIDE,15) os.sleep(7) redstone.setOutput(SIDE,0) else print"Incorrect!" end end -- Начало самой программы while true do --Всегда повторяем кусок ниже lock() --Вызываем функцию замка os.sleep(0) --Даем событиям шанс на обработку. Здесь не играет особой роли, но обычно полезно end
  4. 1. Объявляешь функцию lock, вызываешь функцию pass. Pass не определена, о чем он тебе и говорит. 2. Если не ошибаюсь, у тебя не заработает еще по одной причине, а именно redstone не определен. Попробуй впихнуть в самое начало 'redstone=require"redstone"' или 'redstone=component.redstone'. 3. Делать это через рекурсию - упорото и небезопасно, переделай под цикл. P.S. 4. 'sleep' замени на 'os.sleep' 5. В начало проги 'io=require"io"', 'read' замени на 'io.read'
  5. Вот одно из предложений: http://computercraft.ru/topic/1977-rekvest-apgreida-kompas-dlia-os/ Для поддержания чистоты темы предлагаю все обсуждение этого предложения вести в его теме. Вкратце суть: предлагается введение апгрейда для планшета, который позволяет получать направление, в котором смотрит игрок.
  6. Апгрейд для планшета; возможно, найдется применение и в роботах/дронах, но я пока не придумал. Суть апгрейда - позволяет получать направление, в котором смотрит игрок, который держит планшет (два угла, по горизонтали и по вертикали), помимо этого сообщает оное вместе с событием "tablet_use". Область применения - задачи, в которых требуется более точное позиционирование в пространстве, вот несколько идей в качестве примеров: банальное ручное наведение турелей гораздо более удобное и точное дистанционное управление дроном редактирование голограмм на самих голограммах (например, с постройкой голограммы в воздухе подобно постройке структур в майнкрафте, т.е. присоединением блоков к уже имеющемуся куску) голографический интерфейс в 3д со всякими голографическими же кнопками, текстовыми полями и подобным Очевидно, применение апгрейда этими примерами не ограничивается. Надеюсь, многие найдут предложенное полезным, просьба оставлять конструктивную критику/предложения по улучшению идеи апгрейда в комментариях, если таковая (-ые) будет.
  7. У меня не получилось установить оное ингейм, валится на подгрузке иконки. Пока в код не лез, но вот скрин проблемы: P.s. До меня внезапно дошло, что может не хватать места. Ща вставлю второй хард и попробую снова. [uPD] Да, именно так, теперь вроде нормально поставилось.
  8. Сие ( http://pastebin.com/C0S2m3d8 ) является реализацией программной навигации для робота под eeprom. Здесь уже мелькали реализации подобного, но их все отличает от предложенной большой размер и наличие малоиспользуемых функций. Собственно эта реализация влезает в 780 байт с учетом двух переводов строки после себя (ну мало ли). Имена переменных и функций сокращены настолько, чтобы занимать как можно меньше места, но при этом оставаться осмысленными. Отступы убраны для уменьшения размера. Некоторых проверок "на дурака" нет из тех же соображений. Значимые переменные: ns,nx,ny,nz - направление и три координаты, где x и y образуют горизонтальную плоскость. Изначально робот смотрит в сторону оси x, ось y направлена направо, ось z - вверх. Значимые функции: n_u, n_d - navigation_up/down, движение вверх/вниз; n_f - navigation_forward, движение вперед; n_l, n_r - navigation_left/right - поворот налево/направо; t_t - turn_to, повернуть к, принимает в качестве аргумента число от 0 до 3, задающее новое направление. 0 - направление оси x, далее по порядку по часовой стрелке; n_t - navigate_to, движение к заданой точке, принимает в качестве аргумента координаты точки, в которую требуется проследовать. Сначала передвигается по оси z, затем x и y. Для использования достаточно скопировать код в вашу программу, далее все описанное будет доступно. Если место позволяет, для удобства можно переназвать планируемые к использованию функции (аля "local turn_left=n_l"). Далее у вас будет более 3Кб под остальную часть программы. Надеюсь, кому-нибудь будет полезно.
  9. jammer312

    Ферма для вяления еды

    Не хочу никому навязывать мое увлечение дронами, но не кажется ли Вам, что это - одна из тех задач, в которых они будут справляться намного лучше? Вместо дорогой и местозатратной конструкции из транспозеров и сундука делаем плотное (по вялилке на блок) поле вялилок в виде параллелепипеда, рядом ставим сундук, который каким-либо образом пополняется, а лучше сразу два (входной и выходной). И запускаем дрона под управлением компьютера, который растаскивает ресурсы из сундука по вялилкам, а потом собирает готовое с вялилок в второй сундук. С контроллером инвентаря можн даже вялить разные ресурсы. Комп знает расположение вялилок и помнит, что на них висит, дрону только говорит "неси туда/оттуда". При вялении разных ресурсов дрон еще сообщает компу тип ресурса, чтобы комп учитывал это при выдаче заданий. Учитывая скорость и проходимость дрона, это сильно лучше, чем транспозеры или роботы. Лучше по: цене (очевидно), плотности (можно упихать гораздо больше вялилок в единицу объема), наверное, лагодромности, ибо 1 дрон + 1 комп наверняка грузят сервер меньше, чем сервер + тонны транспозеров. P.s. Специально потратил некоторое время на проверку возможности взаимодействия дронов с вялилками, чтобы удостовериться в том, что автор не выбрал дронов не потому, что они не могут решать эту задачу. Они могут.
  10. jammer312

    GPS

    Если я не ошибаюсь, если мы жертвуем одним реле (оставляя только три), мы получаем при первом и втором замере по две возможных точки, т.е. два возможных вектора перемещения. Можно сказать, что то, что дает перемещение вдоль одной из осей координат - наш искомый вектор, но я не уверен, всегда ли можно будет однозначно его определить. Ну и делал я систему скорее под дронов, которых собираюсь массово использовать для логистики, а они и так знают направления. С массовой добычей роботов и использованием роботов в качестве реле - может быть, но затраты на их общение будут повыше, чем у проводной сети, к тому же робот то подороже микроконтроллера будет. Возможно, постройка такой полевой структуры будет заметно выгоднее.
  11. jammer312

    GPS

    Во-первых, помимо роботов есть дроны, которые не изобилуют количеством слотов, во-вторых, не всегда "робот" означает копатель, не всегда место работы означает дикую глушь вдали от населенных пунктов. В-третьих, радиус действия достаточно хорош, 400 блоков в любую сторону, если не ошибаюсь(точнее, чуть меньше, и зависит от конструкции). И конструкция одна на много клиентов. Да и построить эту конструкцию можно шустро, особенно если применить того же робота, если тебя таки интересует необитаемая глушь. Ну не знаю, я только что проверил посыл сообщения на максимальную(400, вроде максимальная) дальность броадкастом с замером энергии до и после, разница - 20 единиц энергии. А потом сделал то же самое, но вместо посыла сигнала - os.sleep(1). Второе выжрало 10 единиц энергии. Неужто такой большой расход энергии на посыл одного единственного сигнала? P.S. Вспомнил, что у меня соляра в планшете, которым я это тестировал. Но по сути (если я не великий бог рандома) оно должно уменьшить только расход при сне, а не при посыле сигнала, так что особой роли не играет. Да, можно сделать програмную навигацию относительно точки установки, можно даже вручную прописывать абсолютные координаты для нее. Да, это просто и не требует каких-либо затрат. Но иногда случаются ошибки в навигации, и в некоторых случаях требуется синхронизация с чем-то. Более того, иногда требуется синхронизировать несколько устройств, а потом еще в процессе работы при всяких форсмажорах заменять некоторые из них. Иными словами: иногда программной относительной навигации недостаточно, иногда требуется абсолютная или хотя бы просто единая на несколько устройств навигация. Суть в том, что это почти что та же навигация(если ее не тыкать и не кормить новыми картами), только без особых дополнительных затрат на каждое новое устройство. Про транспортабельность - тот же дрон и робот могут шустро построить, робот - демонтировать, но не вижу в этом особого смысла, т.к. данная система предполагалась для использования в местах обитания человека либо для большого числа устройств.
  12. jammer312

    GPS

    Недавно столкнулся с тем, что апгрейд навигации, предоставляемый модом, достаточно убог, при этом он занимает компонент-слот и относительно затратен для крафта. Был удивлен тем, что еще никто не запилил систему геопозиционирования (gps), собственно, написал ее сам. Заранее скажу, что, очевидно, ее можно улучшить, в том числе перенести работу контроллера на один из реле, но первая попытка по написанию системы, состоящей лишь из микроконтроллеров, была неудачной, возможно, из-за малого уровня компонентов, которые вмещают микроконтроллеры, но скорее всего из-за того, что я криво что-то написал (вполне вероятно, если учесть отсутствие вывода ошибок и нормального дебага). Вполне вероятно, что текущую версию можно перенести на контроллер (с минимальными модификациями для избавления от необходимости в операционной системе), и все заработает, но мне это не нужно и лень. Использование клиентом: Требуется беспроводная плата. Клиент(то, что хочет получить свои координаты через gps) броадкастит одно сообщение с содержанием "gps_request" на порт 312 (можно поменять, менять надо в коде реле), через некоторое время, если сообщение достигло всех 4 реле, он получает в ответ сообщение на порт 312 (опять же, можно поменять, на этот раз в коде контроллера), содержание сообщения: строка "gps_response", число x, число y, число z; где x,y,z - координаты клиента, x и y по горизонтали, z - высота. Использование сервером: Сервер состоит из компьютера-контроллера с установленной OpenOS и четырех микроконтроллеров, которые я буду называть (и уже называл) "реле". Реле должны иметь беспроводную и сетевую платы, а также процессор и память (я грузил 2 планки 1 уровня, но даже одной должно хватить). Помимо этого в них должен быть биос с программой(2 ссылка), соответствующей определенному реле. Программа должна быть отредактирована под соответствующее реле (4 переменных в начале, координаты, где (по крайней мере в моей системе) y полагается горизонтальной осью, и идентификационная строка реле, которая должна быть уникальна для конкретной системы (иначе не будет работать)). Предпочтительно на каждом реле по разу запустить wakesetter (программа, третья ссылка). Каждый реле должен быть подсоединен к компьютеру-контроллеру кабелем, помимо этого все 4 реле должны быть некомпланарны (расположены так, чтобы нельзя было провести одну плоскость через все 4 реле) . Компьютер-контроллер должен иметь помимо базовых составляющих, необходимых для работы, беспроводную и сетевую платы. Для запуска системы нужно лишь запустить программу gps_controller (1 ссылка), которая разбудит реле в сети с ней и начнет выполнять свою функцию. Программа является блокирующей, т.е. не позволяет пользоваться компьютером, на котором установлена, пока сама работает. Программа будет выводить print'ом пойманные сигналы от реле, выводить им же координаты, когда сигналов достаточно (когда все 4 реле поймали запрос); уведомлять о таймауте зафейлившихся запросов (когда запрос достиг не всех реле, программа выжидает 2 секунды, чтобы удостовериться в том, что сигналов от остальных реле на его счет она не получит, и удаляет его из таблицы обработки). Ну и, естественно, отвечать на запросы координат. Принцип работы: Когда реле получает запрос от клиента, оно передает свои координаты, идентификатор и расстояние до клиента контроллеру. Контроллер, набрав 4 таких различных (от реле с разными идентификаторами) запроса, вычисляет координаты клиента и отсылает их ему. Подробнее о вычислении: известны 4 точки и расстояние от пятой точки до каждой из них. Тогда мы можем построить по сфере на каждой точке с радиусом, соответствующим расстоянию до пятой, причем эти 4 сферы пересекутся, и пересекутся только в этой точке. Пересечение очевидно, ибо все они проходят через эту точку. Единственность пересечения гарантируется некомпланарностью центров(в трехмерном пространстве), доказывать ее мне лень, примите как факт. Запишем гмт пересечения сфер системой уравнений (каждое вида (X-xi)^2+(Y-yi)^2+(Z-zi)^2 = Ri^2, где Ri - i-тое расстояние, xi,yi,zi - координаты i-той точки, X,Y, Z - координаты искомой(-ых) точки(-ек)), получим 4 уравнения в системе, вычтем из первого, из второго третье, из третьего четвертое, получим систему линейных уравнений на 3 уравнения, при условии некомпланарности точек и верных входных данных она совместна и имеет единственное решение, находим его через метод Крамера. Задача решена. Код: контроллер: http://pastebin.com/QD44ZWBv реле: http://pastebin.com/eAzPst2s прога, которую желательно по разу запустить (записать на биос чип, вставить в микроконтроллер и включить его) на каждом из реле, она позволяет контроллеру их включать через сообщение на модем ("gps awake"): http://pastebin.com/XijvUbB9 Скрины: Как может выглядеть сервер: Скрин того, что он выводит во время работы: Скрин клиента (планшет) с простым кодом для проверки: Следует заметить, что планшет на самом деле на блок выше, чем координата игрока, также следует еще раз для себя заметить, что координаты идут в порядке плоскость-высота, а не как в майне. Сверху код проверщика, чуть ниже зафейленная попытка, ибо сервер gps был вырублен, чуть ниже успешная попытка уже при включенном серве.
  13. Был, когда я последний раз был на сервере. Но либо он не работает, либо у меня руки кривые P.S не работает всмысле многие функции(конкретно перекидка вещей между сундуками) не работают
  14. Учусь в СУНЦ МГУ, на форум гляжу редко, дом разгрифили нелюди поганые.

  15. Так как большинство начинающих в сфере ОС игроков не знакомы с оными, опишу самые важные из них. cat [file] - выводит содержимое файла в стандартный поток вывода(иными словами на экран) echo - выводит все следующее за ним в стандартный поток вывода edit [file] - запускает встроенный редактор файлов rm [file] - удаляет файл cp [file] [destination] - копирует файл в заданное место mv [file] [destination] - перемещает(то есть копирует файл из места 1 в место 2 и удаляет файл в месте 1) cd [path] - переходит в другой каталог ls - показывает содержимое текущего каталога -- насчет следующих не уверен, но должны работать mkdir [dir] - создает каталог rmdir [dir] - удаляет каталог touch [file] - обновляет файл, создает его, если его не существует -- в квадратных скобках показаны аргументы, обозначающие путь к файлам или каталогам --кратко о путях: пути бывают двух типов - абсолютные и относительные. относительные могут начинаться либо с точки и слеша(./), либо просто с имени файла и каталога. Если в текущем каталоге есть каталог dir, то можно в него перейти по разному: cd /[путь до нашего каталога]/dir cd ./dir cd dir Все имена в пути разделяются слешем(/)(cd /dir1/dir2/file) В пути точка обозначает текущий каталог, 2 точки(..) - родительский каталог(такой каталог, в котором находитя текущий каталог) Каноническая запись пути - запись пути, в которой нету никаких факапов ( cd dir - каноническая, cd dir2/../dir3/.././dir - нет)
×