ProgramCrafter

Что это ОЗА, или Огромный Запускатель Армагеддона - это хранилище, позволяющее достичь плотности до 2 квадриллионов предметов на кубический метр. Небольшая версия имеет меньшую плотность хранения (50 миллиардов предметов на блок), но помещается в 2x2 чанка - спокойно влезет в приват. Как это Хранилище состоит из шестнадцати блоков четырёх типов - α, β, γ и δ. αβγδ βγδγ γδγβ δγβα Каждый блок имеет такую архитектуру (С - сундук, Т - транспозер, К - контроллер): С С С СТСТСТС С С С СТСКСТС С С С СТСТСТС С С С Чем одни типы блоков отличаются от других: α - вещи просто лежат в алмазных сундуках. β - вещи складываются в МЭ ячейки хранения, те в сундуки. γ - блок хранилища вырезается пространственными пилонами AE2, полученная ячейка складывается в сундук. δ - пространственные ячейки складываются в бездонные сумки из Thaumcraft или что-то подобное. Сколько хранится предметов (Я не помню точно ёмкости сумки из таума и ячейки хранения AE2, но в любом случае порядок величин будет таким.) Маленькое хранилище: α - 80 слотов/м3 * 64 предмета/слот = 5 120 предм./м3 β - 5120 предм./м3 * 64 (слота в ячейке хранения AE2) = 327 680 предм./м3 γ - 327680 предм./м3 * 24 (сундука вырезается) * 80 (ячеек в новом сундуке) = 629 145 600 предм./м3 δ - 629 145 600 предм./м3 * 80 (ячеек в бездонной сумке) = 50 331 648 000 предм./м3 За счёт чего можно увеличить это хранилище? Можно увеличить количество сундуков в пространственной ячейке! Самая большая ячейка имеет размеры 128*128*128 блоков, половину из них можно занять сундуками (половина нужна на транспозеры). Тогда новая плотность хранения будет равна: α - 80 слотов/м3 * 64 предмета/слот = 5 120 предм./м3 β - 5120 предм./м3 * 64 (слота в ячейке хранения AE2) = 327 680 предм./м3 γ - 327680 предм./м3 * 1000000 (сундуков вырезается) * 80 (ячеек в новом сундуке) = 26 214 400 000 000 предм./м3 δ - 26 214 400 000 000 предм./м3 * 80 (ячеек в бездонной сумке) = 2 097 152 000 000 000 предм./м3 К чему это приведёт К ярости админов сервера, конечно. Если это построить и заполнить. Сервер может прекратить своё существование ещё до того, как кончится место в ОЗЕ. Если на один стак будет расходоваться 4 байта, то малое хранилище потратит четыре гигабайта памяти и места на диске. Кроме того, достаточно много данных будет отправляться клиентам - если поставить в это хранилище чанклоадер, можно достичь того, что никто не сможет войти на сервер. Если заполнить большое хранилище, то будет проблематичным даже чистить мир по чанкам - вероятнее всего, админу придётся удалять целый регион. Для чего использовать? Проще всего использовать это хранилище как свалку. В нём слишком много слотов, чтобы можно было что-либо найти. Однако можно использовать это и как хранилище иридия или жидкого опыта - главное, чтобы был механизм, производящий их в таком объёме.

Новый ход лагеря злоумышленников: Теперь у злоумышленников вместо робота стоит компьютер с интернет-картой, подключающийся к какому-нибудь эмулятору OC. После создания соединения он посылает запрос на авторизацию у сервера "хороших", все сетевые пакеты передаёт в эмулятор. Как контрить этот вариант? Задержка ответа будет весьма незначительной.

Теперь к сообщению для пробуждения можно добавить код исходного EEPROM и отрезать его при запросе. При этом робот лишается возможности загрузки по сети, но успешно представляется своим.

Интернет-карта не подойдёт взломщику: её можно пихать в каждого дрона/робота и создавать максимальное число соединений куда угодно. Например, взломщик может прокидывать запросы через свой компьютер, в обход дрона (правда, это будет вызывать дополнительную задержку). Однако, если сервер "хороших" будет учитывать задержку, он не сможет связаться с роботами в 400 блоках и дальше: слотов под связанные карты у компьютеров немного, а беспроводная карта перестанет доставать. Но, по-моему, есть ещё один фокус: данные можно хранить в сообщении для пробуждения у модема/связанной карты. Их тоже надо забивать псевдослучайными данными?

Немного не в теме: имеется в виду программная подмена компонента или вставка нового EEPROM? И кто должен убедиться в неизменности EEPROM: сам робот/дрон/кто-то там или компьютер, общающийся с ним по сети?

Планировал создать автономный рой дронов, но столкнулся с такими двумя проблемами: 1. Как дрон может добывать руду? (Подойдут почти любые методы, вроде динамитных шашек из IC2 или плоскости уничтожения из AE2. Важно, чтобы дрон оставался после этого целым.) 2. Может ли квадрокоптер активировать сборщик, чтобы создать нового дрона?

Наверное, вместо while true do нужно поставить while base[1].fuelConversion < 9800 do (Код читал по диагонали, реакторов из Draconic Evolution не видел, так что могу ошибаться.)

Главное, чтобы оператор АЭС не задумал посмотреть что-нибудь на рабочем компе. Иначе с реактором может случиться бо-ольшой бабах...

После долгого перерыва я наконец смог вернуться к своему моду OCTechnics! Решил сначала добавить в мод команду для проверки, всё ли работает правильно. В этот раз, чтобы узнать, как добавляются свои команды, полинтернета не хватило. Пришлось смотреть уже не гайды, а чистый код OpenComputers. Там нашёлся замечательный пример: .../common/command/SimpleCommand.scala. Сама реализация команды получила отдельный файл: org/octechnics/octechnics/OCTTestCommand.java: Чтобы команда /oct работала на сервере, нужно дописать ещё несколько строк кода в основной файл OCTechnics.java: Мод OCTechnics загружается и работает! В этом можно убедиться, вызвав команду /oct: мод ответит "OK, OCTechnics works." В следующей части уже будет добавление новых блоков, крафтов и блок-сущностей (на самом деле всё это готово, осталось только статью написать). Команда пригодится для отладки (я не планирую добавлять к своим блокам GUI, т.е. инвентарь без компьютера просмотреть будет невозможно!) Для тех, кому интересна разработка мода в реальном времени, рекомендую взглянуть сюда: https://github.com/ProgramCrafter/OCTechnics/.

Тогда можно использовать для соединения связанную или интернет карту (мост Stem - stem.fomalhaut.me). Главное, чтобы чанк с сервером был всегда загружен (например, чанклоадером). P.S. Где-то видел библиотеку под OpenOS для подключения сетевого диска, ссылку сейчас не вспомню.

Не совсем. Если в реакторе есть пластины обшивки, они увеличат максимальную теплоёмкость, и значения формул начнут расходиться.

Скорее всего, причина здесь проще: до библиотеки (может быть, не проверял) не доходит событие internet_ready. Проверял свой Thundernet и столкнулся с той же проблемой: программа не получает часть сообщений. Причём: 1) на ocelot.fomalhaut.me всё работает хорошо; 2) интернет во время теста работал нормально, без потерь пакетов вообще; 3) при посылке сообщения через веб-мордочку оно доходит примерно в трети случаев.

Вышла версия "0.0.1.5"! Из нового - добавлена поддержка Stem (т.е. теперь компьютеры могут подключаться через интернет). Для работы нужна библиотека stem, установленная в системе. P.S. Все ссылки остались прежними.

Судя по коду, переменные border1, ..., border4, bar и text_p глобальные. При первом вызове функции для первого прогрессбара компоненты создаются и записываются в глобальные переменные. При первом вызове для второго прогрессбара новые компоненты записываются поверх старых в те же переменные. После этого на каждом этапе обновляется только второй прогрессбар, первый остаётся на месте.

А какой код у функции progressbar? Возможно, она просто не очищает пустое место в прогрессбаре. Ещё подозрительно, что переменные p_energy и p_heat постоянно перезаписываются новыми значениями.

Если компьютер начал принимать входящие подключения (запустил run_server), но не подключился ни к какому другому узлу (не запускал connect/не нашёл того, к кому можно подключиться), то он автоматически становится корнем. Тот компьютер (корень), который вызвал метод connect, станет подчинённым. Корнем, соответственно, останется другой. Однако сейчас это не реализовано - сети не объединяются. Да, именно так. В моей библиотеке хранится только первый сегмент пути до абонента, дальше разбирается следующий компьютер в цепочке. Сеть разорвётся на несколько поддеревьев, внутри каждого из них доставка сообщений будет работать. Любым удобным образом: сетевая карта, Stem или вообще звёздные врата. Чтобы добавить свой интерфейс, надо отредактировать файл th_interfaces.lua: добавить туда компонент, как на строках 51-54. Придумывал я её, чтобы исключить коллизии для всех возможных вариантов. Да, можно сократить адреса, но не знаю, будет ли это иметь смысл. Можно завести какой-нибудь DNS-сервер, который будет переводить названия доменов в адреса компьютеров. Но я планирую сделать это вне рамок Thunderlib.

На форуме в последнее время начали появляться темы с сетевыми библиотеками и браузерами. Продолжу это движение (да, скоро и мой браузер будет). Итак, представляю вам ThunderNet! Кстати, анонс уже был: вот это сообщение как раз рассказывало про пришествие ThunderNet. ThunderNet - это сеть, позволяющая объединить множество компьютеров OC, даже на разных серверах. По топологии это (почти) дерево, при этом корнем может быть любой компьютер. Уровней может быть любое количество. Компьютеры взаимодействуют по некоторому каналу: сетевая/соединённая карта/красный камень/Stem/звёздные врата и т.д. Идентификация происходит при помощи MUID (Minecraft-Unique IDentifiers): кодов, уникальных для каждого запуска на каждом компьютере OC. Спецификация протокола: 1. Подключение к сети: — WTC <uid> (Want-To-Connect) Ближайшие компьютеры запоминают этого соседа и отвечают (или не отвечают) — CAC <uid> <level> (Can-Accept-Connection) (level - глубина дерева от корня до отвечающего компьютера); Подключаемый компьютер подтверждает соединение: — AC <uid> (Accept-Connection) Отвечающий компьютер ("родитель") отправляет сообщение до корня: — UCA <uid> (Underlying-Connection-Accepted) Все компьютеры от корня до отвечающего запоминают, в каком направлении посылать сообщение новому. 2. Пересылка сообщений: — RM <message> <target-uid> (Retranslate-Message) Компьютер, получивший такое сообщение, должен: 1) Если он знает путь до <target-uid>, переслать этот пакет по пути. 2) Если он не знает путь и не является корнем, отправить этот пакет родителю. 3) Если он не знает путь и является корнем, забыть это сообщение (потому что куда его отправить? некуда.) При получении сообщения с target-uid, равным uid текущего компьютера, библиотека вызывает событие: thunderlib_incoming <message> 3. Отключение от сети: — DC <disconnected-uid> Компьютеры выше по дереву забывают путь до указанного компьютера и его потомков. Моя реализация этого протокола: Библиотека сейчас состоит из трёх файлов: th_inform.lua, thlib.lua и th_interfaces.lua. Для работы их надо сложить в ту папку, откуда будет запускаться программа. Важное замечание: все методы Thunderlib являются синхронными, т.е. блокируют вызывающий поток! В некоторых функциях есть параметр is_timeout, который завершает выполнение, когда функция возвращает true. Документация по методам: thunderlib.connect([is_timeout]) - подключение к ThunderNet thunderlib.disconnect() - отключение Отключение после использования крайне рекомендовано! В противном случае у компьютеров выше в иерархии может кончиться память. thunderlib.send(<address>,<data>) - посылка сообщения заданному компьютеру по его MUID thunderlib.run_server([is_timeout[, allow_connections]]) - запуск сервера ThunderNet Сервер нужен для приёма входящих подключений и обнаружения соседних компьютеров. thunderlib.uid() - возвращает MUID текущего компьютера thunderlib.parent_node() - возвращает MUID родительского компьютера

Какие-то странные проблемы. Это точно не сеть, не VPN и сомнительно, что брандмауэр: - Ocelot Desktop (Lua 5.2) работает замечательно; - OCEmu (Lua 5.2) не принимает входящие сообщения, но может отправлять; - Minecraft 1.7.10 (Lua 5.3) работает замечательно. P.S. Я проверял всё с локального компьютера.

Я пришёл ровно к тому же, но у меня получился другой формат страниц, более похожий на Python. Интересно, будет ли потом битва браузеров. Представляю себе: половина страниц в одном формате, половина в другом. page: addr: "browser:about" desc: "О TigerFox" styles: style: properties: "@ 5 nil * 0x0 0xFFFF00" id: "styles_test" script: command: "client.test_style = searchID[[styles_test]]" rect: properties: "@ 0 0 | 60 20 * 0x333333 0xAAAAAA" text: properties: "@ 1 1" txt: "TigerFox - удобный браузер для OpenComputers."

Если нужен именно красный цвет, можно использовать вывод через io.stderr. io.stderr:write('Hello World\n') Ещё можно использовать такой трюк (он встречается в библиотеке io), там цвета можно менять: print('\27[31mHello World\27[37m')

Нашлась пара багов. Не знаю, как один из них стабильно воспроизводить, но назову. 1. Менее страшный: ошибка или зависание во время выхода из эмулятора. 2. Более страшный: некоторые сейвы отказываются грузиться. В сейве два включенных компьютера, на каждом OpenOS установлена на диск. Логи stderr (открыт сейв "NostdWorkspace", открываю "StdWorkspace"): Stdout при закрытии с ошибкой: При зависании лог такой же, но заканчивается перед надписью "Cleaning up". Версия Java:

Видимо, центральный блок, по которому он ударяет - это камень, и в 3x3 разрушаются только камни.

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

Я думаю, можно ещё пошаманить с функцией magic и не рассчитывать максимальную и минимальную плотность камня. Если это выражение - это RANDOM_BYTE, то его можно перед взятием дробной части проверить и на попадание в диапазон [-128; 127].

Спасёт, но с двумя оговорками: 1. События должны быть нужны только одной программе. Если доставлять события всем программам, то yield надо делать на каждую программу и на каждое событие (вдруг каждая программа обрабатывает нажатие клавиши по секунде?) Тогда и начнётся пропуск части событий. 2. Вредоносные программы по-прежнему будут нагружать сервер и получать TLWY, а при этом могут крашиться любые компы.