Лидеры

Всем привет, ранее, я разрабатывала SwiftOS, позже я приостановила данный проект, по некоторым причинам. Вновь, я возвращаюсь с новым проектом (операционной системой) Digital Stone. Вся необходимая информация, есть на сайте <Перейти> Digital Stone Операционная система, созданная на ранних знаниях, опыте полученном при разработке SwiftOS. Усовершенствованный код, новые возможности, идеи, и возможно смысл Изучая код со-программистов в этом сообществе, я узнала много нового, изучила документации, и решила начать снова Я ввела новый формат приложений, наделяя их конфигурациями, для упрощения работы с кодом, и обработкой данных, конфигурация приложения выглядит следующим образом: { main = { name = "Название программы", description = "Описание", author = "Автор", version = "Версия", kind = "Тип приложения, он может быть любым" }, safeness = { sign_key = "Ключ безопасности, который будет подтвержать подлинность приложения через сервер" }, compatibility = { type_program = "Тип приложения (пока что доступен только GUI)" }, BFI = { file = "Загрузочный файл", icon = "Иконка приложения" } } Функция подтверждения приложения через сервер временно отключена, но присутствует в коде Разработана новая система управления процессами графических приложений, каждый процесс сохраняется в памяти, и имеет свой id. Remote Component выбыл из разработки Разработана система уведомлений, группировка уведомлений, и их размещений Ввела сервисы Digital Stone id, авторизация ( и в целом система ) будет требовать постоянное подключение к интернету Команда для установки, требуется предустановка OpenOS, и интернет карта pastebin run Q5MNaUfS

cloudflared tunnel (нужен домен, 6-символьный домен из цифр вроде 000001 на TLD .XYZ стоит копейки), tailscale funnel из бесплатных решений. cloudflared в принципе пробивает любой CGNAT. Если говорить про хостинг TCP/UDP приложений — из бесплатных решений особо ничего нет, но можно попробовать использовать ipv6 брокера — tunnelbroker.net. Дают бесплатный ипв6 который, вроде как, должен пробивать CGNAT в том числе. Так же существует клиент https://playit.gg/, опенсорсный клиент, позволяет пробрасывать tcp/udp порты (4 штуки). дают и домен, и айпишник (не меняется). Бесплатно. Из платных решений можно взять впн и пробросить через него порт firstbyte.ru (не реклама) предлагает хостинг за 70 рублей.

Не нужна, это задел на дальнейшую разработку с анализом входящих сообщений. Бывают ситуации, когда робот застрял в приватной зоне или бедроке, когда села батарея или сломался инструмент - в этом случае имеет смысл отослать статусное сообщение с координатами робота относительно хоста, а затем отключить питание Вообще роботы с дронами, имхо, самая балдёжная часть мода. Тут и автоматизация рутины, и распределенное выполнение задач, и сетевой код, и инфо-безопасность. Когда кодил аналогичную систему контроля в сурве, то сформулировал для себя несколько рекомендейшнов: Метод modem.setWakeMessage() - имба. Когда робот выполнил все задачи, можно смело его выключать, оставляя где-то на глубине в границах привата. Когда необходимо продолжить работу, шлём сетевой пакет на включение - профит. И энергия сохранена, и нажимать кнопку Power не надо Широковещательные пакеты через modem.broadcast() опасны на публичных серверах, и в 100% случаев станут причиной угона робота. В идеале, когда все машинки скрафчены, необходимо внести адреса их модемов в конфиг на хосте, а впоследствии общаться приватными пакетами через modem.send(). Либо захардкодить в роботах адрес хоста и доверять лишь ему одному, как в примере выше Дополнительные батареи - мусор. Вместо них лучше установить апгрейд опыта, построить ферму кобблы и позволить роботу фармить экспу. Спустя 2-4 реальных часа у тебя раскачается "алмазный" робот с колоссальным буфером энергии Апгрейд навигации для вычисления позиции/поворота - мусор. Вместо него куда дешевле и интереснее накодить софтверную триангуляцию, основанную на перемещениях робота и расстоянии, которое "пролетел" сетевой пакет. А поворот можно определить с помощью геоанализатора, ломания/установки блоков и вращения робота Софтверное позиционирование - имба. Вычисляешь единожды координаты/поворот робота - и корректируешь их при вызове move/turn. Взамен появляется возможность автоматизировать перемещение в любую указанную точку. При отключении питания имеет смысл сохранять эти данные на диске, либо определять их автоматически при включении Геоанализатор - легальный чит. Однако использовать его в штатном режиме, сканируя вертикальными "столбцами" - выстрел в ногу, т.к. точность результатов на расстоянии в 10+ блоков будет отвратная. Вместо этого стоит заюзать опциональные аргументы scan(), анализируя небольшие горизонтальные плоскости 8х8 блоков вокруг робота, постепенно прокапывая вниз. Точность при этом станет как советском станке Экран/клавиатура/дисковод и полноценная ОС - штуки ситуативные, т.к. стоимость сборки улетает в космос, а выхлоп сомнительный. Мнение не навязываю, но я предпочитаю ставить больше апгрейдов инвентаря/крафтинг/редстоун-плату/etc., делая машинку универсальнее и контролируя её по сети Апгрейд крафтинга очень недооценён. Каким бы большим ни был инвентарь, он гарантированно заполнится всякими андезитами/мусоритами. Эту проблему в соло решает крафтинг, упаковывающий ресурсы в стаки, особенно на серверах с модами типа экстраутилит, позволяющими "сжимать" кобблу Жёсткий диск 1 тира - топ за свои деньги. Всегда приятно иметь возможность сохранять/загружать координаты робота или довольно объёмные "снимки" местности с геоанализатора

В кои-то веки вспомнил про незакоммиченный (уж год как) мелкий багфикс, связанный со списком доп. компонентов для установки. Подправил и обновил. Лучше поздно, чем никогда.

Интересные изменения: Добавили поддержку Lua 5.4.4. Он не сильно отличается от Lua 5.3, но у него есть атрибуты локальных переменных (<const>, <close>). Последний выглядит очень полезным. Архитектура пока экспериментальна, нужно явно включать в конфиге мода. С остальными либами Lua тоже капитальная переделка. Наконец-то пофиксили инты в методах компонентов (если вам вызов когда-либо говорил invalid key to 'next', это оно). Сами либы обновили до последних версий (например, 5.3.6) и пересобрали с оптимизациями. В том числе под 64-битные армы (линукс, мак). Чтобы не путаться, на текстуре блока redstone i/o точками, как у игральной кости, показывается, какая это сторона: . Теперь рисуются юникод-символы выше U+FFFF. Там, например, всякие емоджи запиханы. Лишь бы в шрифте глифы под них имелись. Патчить шрифт можно ресурс-паками. Причём необязательно собирать глифы для всех символов: если в ресурс-паке глиф не указан, то он берётся из шрифта мода. Интернет-карту переписали на другую HTTP-библиотеку, чтобы она умела слать PATCH-запросы. Ссылка: 1.7.10 / 1.12.2.

OC тяжелее юзать иза ограничений в памяти и ограничений в действиях. Но это позволяет делать ефективные решения. Помню когда я свою БД писал на ОС. Мне пришлось создавать индексы как в реальной БД что б все ускорить. Помимо этого в ОС более функционален. Возьмем как пример робота из ОС - он может делать почти все что игрок и потому много кул програм было написанно: выведенние растений ИК с топ геном, пчеловод (выводит нужные мутации в форестри), шахтер с лазером из ИК, всякие шахтеры з норм инструментами (даж чареными) а не киркой что не ломается. В ОС даж есть специальный тип роботов (дрон). Он не считается блоком - он ентитя. Потому он позволяет тоже делать много интересных програм. И мне очень нравится что в ОС все идет на енергии а не как в СС (черепашки на угле. Притом тратят уголь ток что б двигатся. Остальные дейсвия бесплатные) Помимо этого в ОС даже есть интеграция с многими плагинами/модами. Например роботы не могут ломать чужые приваты (могут ломать ток приваты того кто его поставил). Потому я топлю за ОС. Правда очень большой минус это то что его забросили. Последняя версия для майна 1.12.2. Хотя там люди работают над портированием его на новые версии - даже ПР уже сделан. Но я б не ожидал что ктото его закончит

А знаешь, чего у него ещё нет? Нет аппаратных ограничений, что позволяет забить на оптимизацию софта, уничтожает челлендж, а новичков приучает бездумно писать плохой код. Ты думаешь, почему любой AAA-проект в 23 году имеет в минимальных требованиях RTX 2080? Всё потому что джуны учились кодить на CC! Нет сбалансированных рецептов крафтов, ПК в буквальном смысле создаётся из мусора. Это создаёт ложные представления о реальности, обучает требовать максимум, прикладывая минимум усилий. Сегодня ты кодишь на CC, завтра требуешь ЗП в 300к/наносек, а послезавтра спиваешься от разочарования! Нет возможности снести захардкоженную CraftOS и написать собственную взамен. Это пресекает на корню свободу творчества, уничтожает здоровую конкуренцию и приучает с ранних лет считаться с требованиями монополиста. Разве такого будущего мы желаем нашим детям? Нет тонны фич типа 3D-принтера, геосканера, голопроектора, карты данных, связанной карты, датчика движения, контроллера баков, транспозера, поводка, дронов. Человек не может развиваться, сознательно отказываясь от этих благ. Это путь к деградации и самобичеванию, к искусственным ограничениям и невежеству! Нет даже War Thunder! А знаешь, где есть War Thunder? В OC, вот пруф!

пст лжт н свлк

по быстрому накидал программу для доступа к OpenAi API, потом с помощью чатбокса добавил возможность игрокам говорить с ГПТ через чат/ Минимальные требования: Интернет карта. подключенный чатбокс ИЛИ обновления "чат" (computronics) Просто запустите программу и напишите в чат префикс "!гпт", "!gpt" и свой вопрос. Через пару секунд вы получите ответ. Программа имеет "память". но при этом не оптимизирует её использование. т.е. по достижению лимита токенов программа крашнется из-за ошибки на стороне OpenAI Репозиторий: https://github.com/Def-Try/MinecGPT/ Программа использует библиотеку json от sziberov Установка: wget https://raw.githubusercontent.com/Def-Try/MinecGPT/main/install.lua /tmp/cgpti.lua && /tmp/cgpti.lua

Было скучно — теперь опенось с апстрима, алсо портирован compress.lua на питончик для более "адекватного" пакования образа системы, если кому-то это вообще надо. Ну и патчики автоматические, да https://github.com/Chebuya/OpenOS-mineos

@BenniShifer919 Проверил сейчас выделение памяти на cc-tweaked-1.12.2-1.89.2.jar. Проблема сохранилась со времён оригинального ComputerCraft. Эксперимент: Устанавливаем компьютер, запускаем интерпретатор Lua, запускаем скрипт s=string.rep("x",1024^3) print(#s) Повторяем на следующем компьютере и т.д. Результат: На первом компьютере строка имеет длину 1073741824. На последующих — только 6. Вывод: Мод непригоден для игры на публичных серверах. Любой игрок может выжрать всю память, ничего не оставив другим игрокам. Вот, собственно, и ответ, почему OpenComputers, а не ComputerCraft. Это как минимум.

Беспроводная карта может послать сообщение одновременно по проводному и беспроводному каналу, это нормально. Вторая карта (проводная) никаких сообщений не посылает, если её об этом не просят.

Минус CC и плюс OC. Низкое качество кода на OC нивелируется бюджетом вызовов и лимитом памяти. На CC таких ограничений нет, что позволяет убивать публичные сервера и перегружать чанки. Это более чем достаточный повод, чтобы выбросить CC на свалку истории Потому что это челлендж, а жизнь без челленджа скучна и пресна, как еда из столовки в сравнении с рестораном. Плохо, когда челленджа нет, как в CC. Плохо, когда он чрезмерен, как в GregTech. И хорошо, когда он сбалансирован - как в OC Затем, что наличие возможности, которая тебе не пригодится, всегда лучше её отсутствия, при котором она не пригодится никому. На форуме были также посты от авторов альтернативных ОСей, которые пишут их, несмотря на предостережения. Так к которому из авторов стоит прислушаться рабу системы? Я считаю, что одновременно ко всем, и ни к кому. Пост - это не более чем компиляция мыслей одного человека. Можно воспринимать их как рекомендацию, можно как личное кредо - но не как незыблемую догму для всего человечества. Один усатый художник тоже много чего писал)0 Ну, если сам BenniShifer919 не видел, то фичи действительно юзлесс, можно удалять из мода - сейчас кину PR авторам. А способность думать логически и пространственно зависит в том числе и от объема доступного инструментария. Чем он шире, чем гибче - тем лучше, т.к. перспективы и масштабы мышления расширяются. В случае с CC из-за облегчённого геймплея и недостатка фич они наоборот сужаются, а мыслительные процессы текут более вяло, позволяя ошибаться и писать плохой код чаще Потому что не играл на серверах, где рандомный гений крафтит стак компов из мусора, запускает while true и убивает хост за пару минут. OC искусственно ограничен для лучшей иммерсивности, и более-менее защищён от абьюзеров, он учит писать качественный код, не поедающий доступные ресурсы впустую, а CC - нет К примеру, несколько лет назад мне пришлось изрядно попотеть и изучить много нового, чтобы накодить на OC рейкастер с приемлемой производительностью, т.к. при бездумном кодинге движок выдавал лишь 1-2 FPS. Я очень радовался, что осилил, что сумел, что превозмог трудности. Это сродни получению достойной награды за действительно тяжелый труд. Как сказал бы Сэнку: "Это так волнительно!"

Зависит от кода программы. Если выбирать сетевую карту кодом modem = component.modem, то будет выбран именно главный компонент. И если им является проводная карта, то сообщение по беспроводному каналу не будет послано. Но если выбирать сетевую карту по её адресу, то главный компонент не будет играть какой-либо роли. При этом не имеет значения, как мы получим адрес компонента: введём ли его вручную или же определим перебором, проверяя нужное свойство сетевой платы. @WheatComp Кстати, я думаю, что в описанной задаче вообще не нужна проводная плата, т.к. и беспроводная точно также обеспечивает передачу по проводам. Если требуется заблокировать передачу по воздуху, можно уменьшить до минимума мощность передатчика кодом modem.setStrength(0). Или можно использовать разные номера портов для передачи по проводам и по воздуху.

computer.pullSignal ждёт первого сигнала определённое время. То, что ей передана пятёрка, означает, что ждать будет не дольше 5 секунд, но если какое-то событие придёт раньше (что здесь и происходит: возможно, подключение компонентов), то выйдет раньше. UPD. @ECS уже говорил про это в предыдущих сообщениях. Просьба внимательнее читать ответы. А os.sleep так не заработает: синтаксис function tbl.func() ... end создаёт новую функцию и кладёт её в поле "func" таблицы tbl. В данном случае функция кладётся в поле "sleep" таблицы os. Но такой таблицы в биосах нет. Либо нужно определить табличку эту: local os = {} function os.sleep(timeout) --[[ сюда код функции ]]-- end Либо вообще не пытаться класть функции в таблицы (что наиболее разумно): local function sleep(timeout) checkArg(1, timeout, "number", "nil") local deadline = computer.uptime() + (timeout or 0) repeat computer.pullSignal(deadline - computer.uptime()) until computer.uptime() >= deadline end Здесь ещё пропал event.pull, потому что event в биосах тоже отсутствует. (Да и в OpenOS event сначала нужно получить через require.) computer.pullSignal для наших целей достаточен.

@WheatComp Если по-читерски, то можно сдюпнуть жёсткий диск одного робота, вставить его в остальные и работать в одной общей папке Если по-честному, то имеет смысл дать возможность каждому роботу выполнять произвольный код, присылаемый компьютером-хостом по беспроводной сети. Это позволит избавиться от OpenOS, жёсткого диска и упростить сборку робота за счёт более дешёвых компонентов: 1) Крафтим 20 чистых EEPROM и беспроводных модемов 2) Прошиваем их скриптом-ресивером: 3) Вставляем прошитые EEPROM с модемами в роботов 4) Пишем управляющий скрипт для компьютера-хоста. Предполагаю, что на нём будет использоваться OpenOS: 5) Запускаем всех роботов и отсылаешь им любой файл с жёсткого диска на исполнение командой send robots/example.lua Единственный нюанс - работоспособность кода выше чекнуть не могу, т.к. майна под рукой нет, но общий концепт, думаю, понятен

Очередное "Лучше поздно, чем никогда". У игры еще месяцев 8 назад появился редактор задач - VVPTask. В этом редакторе можно создавать свои собственные "таски" для игры. Задачи хранятся по пути Tasks/task*.vtf, где * — номер задачи. Заменяя или добавляя задания, вы можете изменять игру, упрощая или усложняя ее.

хочу еще добавить, что http://eu.org дает домены бесплатно по запросу вида domain.eu.org или example.domain.eu.org

Решение: удалить папку network, потому что в изначальной установке OpenOS её нет, и также проверить папку boot на соответствие чистой (https://github.com/MightyPirates/OpenComputers/tree/master-MC1.7.10/src/main/resources/assets/opencomputers/loot/openos/boot), перезагрузить компьютер.

Судя по ошибке, в дисководе до сих пор установлена дискета Network, которая проворачивает в фоне какую-то чёрную магию, регистрируя глобальные обработчики событий. Решение: вынуть дискету и ребутнуть ПК

У него больше возможностей, мои причины почему я на OC: Модульность. Да, он сложнее в сборке, но ты можешь собрать тот компьютер который подходит тебе под определённую задачу. Обилие предметов. Когда в СС только компьютер и черепаха (по памяти), в ОС дроны, микроконтроллеры, гео анализатор, карта красного камня, адаптер (Взаимодействие с другими модами), и т.п. У него нету сильных недостатков перед СС, наоборот он более продвинутый, имхо. Оба мода в разработке. Аргумент то прав но обновляться оба мода. Мы пытаемся быть интеллигентным сообществом, поэтому лучше было-бы написать помидорами. Оба моды сильны в определённых аспектах, и не вижу причины опускать или завышать кого-либо. Один работает 1.12.2, другой на 1.19.*. Они взаимозаменяемы, просто кто-то начал с одного мода , а переходить на другой желания нету. Я не вижу вязкой причины переходить на СС, имхо ОС лучше. Каждый решает сам что ему использовать. Думаю что победит дружба, так-как выяснять разницу почему один мод лучше другого это как спросить: что лучше интел или амуде?

Пинговать людей, когда их прямо ничего не касается, есть очень дурной тон. Прошу так больше никогда не делать. В качестве исключения отвечу так: дискета бесполезна, давно устарела, еле работает, не имеет документации, и кто-то из разрабов мода вообще собирался всех их выкинуть за ненадобностью. Если это не останавливает, разбираться прошу самостоятельно.

Символ "s" поставил лишний, сорян. Я тебе сам принцип хотел показать, что нужно сначала пройтись по всем имеющимся танкам, а затем уже обращаться к их полям. Если нужен самодельный сериализатор для любого типа таблиц, то можно написать что-то вроде tank1 = {amount = 222, capacity = 333, nestedTable = {1, 2, 3}} tank2 = {amount = 452, capacity = 349, nestedTable = {4, 5, 6}} tankTable = {tank1, tank2} local function printTableContents(source, name, indentator) indentator = indentator or "" name = name or "" print(indentator .. name .. "{") for key, value in pairs(source) do if type(value) == "table" then printTableContents(value, tostring(key) .. " = ", (indentator or "") .. " ") else print(indentator .. " " .. tostring(key) .. " = " .. tostring(value)) end end print(indentator .. "}") end printTableContents(tankTable) В результате выведется

Там написано, что при нажатии генерируется событие. Соответственно, чтобы получить информацию, надо это событие обработать. Например, запустив в интерпретаторе Lua такой код: while true do print(serialization.serialize({event.pull()}))end

Широковещательное сообщение может быть принято любой сетевой платой с открытым портом-адресатом при наличии среды передачи (либо при подключении кабелем, либо нахождении в зоне действия беспроводного сигнала). Беспроводную сетевую плату можно рассматривать как улучшенный вариант обычной проводной платы, т.к. она сохраняет возможность проводной связи. Главный компонент нужен лишь для упрощения подключения компонента. Если главный компонент назначен, то для его подключения достаточно лишь выполнить что-то вроде modem = component.modem. В противном случае приходится использовать более длинный вариант кода с component.list("modem"). Нет принципиальной разницы в работе с компонентами через component.invoke или component.proxy. component.proxy удобнее для программиста, и является высокоуровневым API для component.invoke. component.invokeчуть меньше нагружает компьютер, а также доступен из EEPROM, т.к. является низкоуровневым интерфейсом.

Оказалось, мой косяк: local robot = component.proxy(component.list("robot")()) local computer = component.proxy(component.list("computer")()) computer.pullSignal(3) for i = 1, 4 do robot.turn(true) end определил computer, хотя он и так есть, как Вы и объяснили. Без этой строчки pullSignal работает как и должен работать. Наверное, им и буду пользоваться. Спасибо, работает, в том числе и модули можно использовать.

Очень интересная идея. Да, из опенкомпов можно использовать симлинки, но простого ярлыка будет недостаточно - в игре он окажется обычным файлом с расширением .lnk. Чтобы (на windows) засунуть в игровой хдд симлинк директории, нужно в cmd.exe (именно в cmd.exe, PowerShell, почему-то, такой команды не знает) прописать: mklink /D <название ссылки> <путь к целевой директории> Например, засунем в папки /home двух компов ссылку на директорию "C:\Test". Вуяля:

Проверяй наличие файлов и корректность вводимых путей. Интереса ради загрузил майн, проверил - всё сработало, как и задумано: Управляющий скрипт /home/send.lua: Микропрограмма-ресивер для робота /home/eeprom.lua: Исполняемый код, отсылаемый роботам по сети /home/robot.lua: Команда для отсылки: send robot.lua Результат: Движение робота реализуется самим роботом, а не OpenOS. Как правило, любая ОС в OpenComputers - это софтверная оболочка, функционирующая поверх аппаратной части, и предоставляющая набор библиотек, упрощающих разработку софта. Например, в случае с роботами OpenOS оборачивает компонент robot в библиотеку robot, предоставляющую набор шорткатов. То же самое и с глобальной функцией require - её попросту нет в "голых" роботах, управляемых из-под EEPROM Использовать ОС крайне удобно, когда речь идет об одном роботе, хранящем пользовательские скрипты и управляемом напрямую через экран/клавиатуру. Однако в случае с роем такое решение контр-продуктивно, т. к. любая ОС потребляет ресурсы и требует крафта более дорогостоящих компонентов - в частности, планок памяти и жёстких дисков. Это всё равно что ставить Debian на сеть устройств для капельного полива домашних растений - ну то есть да, это возможно, а зачем? Разумнее прибегнуть к концепции микропрограмм на EEPROM, которые относительно дёшевы в плане крафта, а профит в виде освободившихся слотов под компоненты существенный. Заодно можно получить интересный опыт по "низкоуровневой" разработке под опенкомпы: -- Робот с OpenOS local robot = require("robot") robot.moveUp() robot.turnRight() robot.swing() -- Робот с EEPROM local robot = component.proxy(component.list("robot")()) robot.move(1) robot.turn(true) robot.swing(3) Таблицы component/computer/robot/unicode/bit32 являются суперглобальными и доступны сразу при запуске микропрограммы EEPROM, однако во время инициализации OpenOS они маскируются из соображений консистентности кода. Поэтому при работе из-под EEPROM вызов require не требуется, а из-под OpenOS уже требуется Верстаки, контроллеры инвентаря и ёмкости - это аппаратные компоненты, функционирующие самостоятельно и не требующие OpenOS. Любая ОС - это просто средство доступа к компонентам, причём одно из многих: -- Робот с OpenOS local component = require("component") local sides = require("sides") local crafting = component.crafting local inventoryController = component.inventory_controller local tankController = component.tank_controller crafting.craft(10) inventoryController.dropIntoSlot(sides.front, 10) tankController.drain() -- Робот с EEPROM local crafting = component.proxy(component.list("crafting")()) local inventoryController = component.proxy(component.list("inventory_controller")()) local tankController = component.proxy(component.list("tank_controller")()) crafting.craft(10) inventoryController.dropIntoSlot(3, 10) tankController.drain() Как видно, разница в коде несущественна, отличие лишь в способе получения доступа к ним и в наличии упрощающих библиотек типа sides Чтобы прояснить ситуацию: никто не призывает тебя использовать голый EEPROM вместо классического подхода с HDD/OpenOS. Разрабатывай так, как считаешь комфортным и оптимальным для себя - я лишь указал один из способов решения поставленной задачи, который использовал при выживании, и который сам считаю оптимальным Если тебе требуется весь богатый функционал, поставляемый OpenOS для роботов, ничто не мешает модифицировать скрипт-ресивер таким образом, чтобы он работал из-под OpenOS:

Это не возымеет эффекта, т.к. библиотека package реализована средствами OpenOS, а не мода. То есть ей доступны те же данные, что и игровому жёсткому диску. А ему в свою очередь доступны только данные в рамках директории игрового сейва - это захардкожено из соображений серверной безопасности, и обойти не получится Вероятно, package задумывалась как полный аналог одноименной библиотеки в "реальной" версии Lua - отсюда и путаница

И ещё идея - делать всё через виртуальных игроков. 1. Подключаем майнкрафт к серверу через Wireshark/ещё что-то, что захватит трафик (с offlineMode=true шифрования нет). 2. Кликаем по токарному станку как надо. 3. Отключаемся, находим нужные пакеты. 4. Подключаемся (хоть скриптом на локальном компьютере, хоть с самого сервера из OC) к серверу майна и управляем токарным станком.

Не надо недоговаривать. У тебя сломанная windows 10 pro 2019, из которой, насколько я знаю, удалены некоторые системные компоненты. Учитывая эти обстоятельства, разбираться в проблеме практически становится бесполезно. Переустанавливай винду или неси в сервис.

liteOS это одна из самых легких ОС с GUI в данный момент находится в активной разработке оська находить в очень раннем доступе, и большая часть из описанного здесь нереализованное/неопубликованное магазин на данный момент является заглушкой, которая скачивает 3 доступных пакета, для того чтобы они появились в недоделанном меню нужно перезагрузить устройство github: https://github.com/igorkll/liteOS native-installer: https://raw.githubusercontent.com/igorkll/liteOS/main/native_installer_compress.lua native-installer: нативный установщик liteOS под API opencomputers, может быть запущен с использованием технологии urlboot из под большинства "современных" биусов имеет возможность запуска операционных систем, чтобы вы могли использовать его как обычный bios может быть прошит в eeprom может быть запушен из под ОС не изменяющий API opencomputers(например: MineOS, likeOS, liteOS, inerpat) из фишек: Оконная система Поддержка аппаратных и программных буферов Поддержка динамического разрешения и палитры, на разных сценах gui может иметь разное разрешения и палитру Полная совместимость со всеми программами для openOS (пока что не реализовано) минимальные системные требования: жесткий диск: 512кб озу: 1 x 1.5 tier видеокарта: 2 tier монитор: 2 tier процессор: 1 tier рекомендуемые системные требования: жесткий диск: 1мб озу: 1 x 2.5 tier видеокарта: 2 tier монитор: 2 tier процессор: 2 tier особенности: система может решить использовать аппаратный буфер при недостаточном объёме ОЗУ система поддерживает дизиринг, что дает весьма сносную картинку на мониторах первого тира спецификация: на данный момент спецификация ос является от части закрытой, из за проходящей активной разработки, она постоянно меняется варианты установки: установить liteOS используя диск/дискету с liteOS, а конкретнее встроенную утилиту "disks" (пока что не реализовано) использовать нативный установщик, вставив ссылку на него в url-boot использовать нативный установщик, прошив его в eeprom установка софта: в liteOS присутствует магазин приложений, в котором будет довольно много софта, (пока что не реализовано) а так же что самое главное пользователе смогут выкладывать туда свой софт (пока что не реализовано) скриншоты: прошу не подвергать оську критики только из за того что она была выпущена "самым отсталым среди отсталых, самым никчёмным среди таковых logic`ом" я изменился правда против здравых замечаний не имею нечего против, но я не люблю плохое отношения к моим продуктам только потому что я решил выложить их от своего имени пожалуйста прошу простить за мое не слишком удачное появления на этом форуме, так как это был мой первый форум где я основательно засел, и я не совсем понимал как работают форумы, вернее совсем не понимал этого выложить ос на этапе тестирования gui`шки решил по причини страха что меня опять опустят на дно потому что "rootmaster не может сделать нечего хорошего" и я уже настроился на такой исход по этому решил принять на себя весь этот хейт заранее

На досуге приперло мне написать игрульку. Простенькую, но интересную. Генератор идей у меня фиговый, потому решил подыскать уже существующую несложную игрушку (опенсорсную), да перенести ее на OC. Мне подвернулась игра ВычВыжПром, написанная на Java одной группой. За неделю я практически полностью перенес ее на Lua (пару моментов пришлось упростить ввиду хилой мощности компов). Цель данной игры проста: у нас есть выжигатель, контроллер и некоторое количество заданий. Нужно программировать контроллер для выжигания узора, показанного в задании, располагая небольшим набором команд Assembler-а. Минимальные системные требования: Видеокарта и Монитор - Уровень 3 (160x50 символов, 256 цветов) Процессор - Уровень 1 ОЗУ Память - Не менее 1.5 Mb (Уровень 3 x2) Жесткий диск - Не менее 95 Kb свободного места Установка: pastebin run nw0FNGjr Игра также доступна в MineOS App Market Репозиторий на GitHub

помню у меня было такое.. я вроде бы спрашивал как измерить длинну текста. лучшее решение что бы не задавать таких тупых вопросов это гуглить вот простейший пример: или так же оооочень помогает Chat GPT он уж точно не будет говорить что то плохое сложное чёт не напишет но может пояснить что либо пример: кстати с OC он тоже умеет работать, пишет не идеально но пойдёт что бы понять как оно работает. пример: 3 скрина не будет места не хватает) вот так бац бац и документация уже не плохая

На доки наговаривать не надо, документация весьма хороша. Да, в документации некоторые нюансы отсутствуют. Так оно так и в реальной жизни зачастую бывает. Можешь считать игру с OC симулятором разработчика ПО. Если хочешь хороших гайдов, то возьми, да и напиши или сними свои гайды. Проблема гайдов в том, что их зачастую снимают люди, которые либо сами плохо разбираются в предмете, и потому гайд получается путаным, либо наоборот, люди разбираются в предмете слишком хорошо, и многие вещи они не поясняют, считая их очевидными. Самые лучшие гайды получаются у вчерашних студентов, которые уже знают предмет, но ещё помнят, через какие трудности им пришлось пройти, но даже в этом случае их гайды субъективны. С этим ничего не поделать. Рецепт хорошего учебника всегда один: читать другие учебники и, учитывая допущенные в них ошибки, писать свои учебники лучше прежних. Возможно, автором лучшего гайда по OpenComputers станешь именно ты. Собственно, для этого и существует форум. Кто-то спрашивает, кто-то отвечает, кто-то корректирует. По возможности, конечно. Не всегда и не у всех есть время ответить, не всегда собеседник кажется приятным человеком, не всегда есть нужное настроение, не всегда интересен вопрос. Всякое бывает. Но на корректно заданные вопросы на этом форуме ответы поступают почти всегда.

Да, это надо сделать в первую очередь. У меня установщик network добавил следующие файлы: ./boot/95_hostname.lua ./boot/80_network.lua./bin/route.lua ./bin/arp.lua ./bin/ping.lua ./bin/ifconfig.lua ./lib/network/tunnel.lua ./lib/network/modem.lua ./lib/network/loopback.lua ./lib/network.lua ./usr/bin/nc.lua ./usr/man/ping ./usr/man/network ./usr/man/ifconfig @WheatComp А вообще, самым простым решением является форматирование диска.

Там банальная опечатка внутри ipairs: вместо tanksTable должен быть tankTable.

робота можно прокачивать зачереным лутом (книги, предметы), макс 30 уровней https://pastebin.com/ZKFw0Lst

В этом месте: https://github.com/MightyPirates/OpenComputers/blob/af2db43c53b9690fceabfb813987572bf2258db5/src/main/resources/assets/opencomputers/loot/openos/boot/04_component.lua#L104-L108 function component.setPrimary(componentType, address) ... timer=event.timer(0.1, function() adding[componentType] = nil primaries[componentType] = primary computer.pushSignal("component_available", componentType) end) Предлагаю рассмотреть другой вариант решения задачи. Так как сетевых плат всего две, а их типы различны, то можно отказаться не только от манипуляций с главным компонентом, но и от запоминания адресов. Например, так: local component = require"component" local wireless_modem_required = true local modem for addr in component.list"modem" do if component.invoke(addr,"isWireless") == wireless_modem_required then modem = component.proxy( addr ) break end end if modem then print( modem.address ) modem.broadcast( 1, "success" ) end Значение переменной wireless_modem_requiredв этом коде задаёт тип сетевой платы: проводной или беспроводной.

Ты ставишь компонент модема перед тем как проверить есть ли он. А почему ты используешь примари? component.invoke(addrs, functionName, ...) <-- обращается именно к компоненту addrs, имя функций пишешь в строковом варианте, например: local address = '0ab' local cmp = require('component') local address = cmp.get(address) --Получаем полный адрес из скороченого, обезательно local sides = require('sides') cmp.invoke(address,'setOutput',sides.up,5) print(cmp.invoke(address,'getOutput',sides.north)) cmp.invoke(address,'setOutput',sides.down,12)

Что именно требовалось, мне до сих пор не особо понятно. Для примера опишу свой подход. Я использую символические ссылки для тестовых целей в творческом режиме. Мои файлы с программами и конфигами обычно находятся в удобном для разработки месте, вне игрового каталога. Типичный игровой эксперимент я заканчиваю удалением сохранения. При этом программы, находившиеся на компьютерах и роботах, не теряются, т. к. моё сохранение игры обычно содержит не сами программы, а лишь ссылки на них. При последующих экспериментах я создаю ссылки на нужные мне файлы и каталоги, используя комбинацию клавиш C-x s в Midnight Commander. Иногда я подменяю ссылками каталоги самих дисков OC. Получаются как бы клонированные диски. С точки зрения игры эти диски не являются клонами, но по факту они ссылаются на общее хранилище. Если требуется провести масштабный эксперимент с десятками роботов, то я беру их из креатива. В момент установки роботов в мир появляются каталоги, соответствующие их дискам. Для массовой подмены каталогов я использую скрипт, подменяющий только пустые каталоги с подходящими именами: #!/bin/bash # Подмена каталогов жёстких дисков OpenComputers ссылками на каталог-источник # Параметры запуска: каталог-источник, каталог OpenComputers сохранения игры dirSource=$1 dirTarget=$2 for dir in $dirTarget/*; do # обрабатывать только каталоги if [ ! -d "$dir" ] then continue; fi # обрабатывать только каталоги с подходящими именами if ! (basename "$dir" | egrep -q \ '^[0-9,a-f]{8}-[0-9,a-f]{4}-[0-9,a-f]{4}-[0-9,a-f]{4}-[0-9,a-f]{12}$') \ then continue; fi # обрабатывать только пустые каталоги if [ -n "$(ls -A ""$dir"")" ] then continue; fi # подмена каталога ссылкой на источник rm -r "$dir" ln -s "$dirSource" "$dir" done

Решил значит я сделать мод для OpenOS, да не обычный, а такой что бы пользователь мог его сам собрать. Что то вроде Arch Linux: можешь поставить только базу командой pacstrap -K /mnt base linux linux-firmware А можешь сразу и DE накатить да и пару приколов заодно: pacstrap -K /mnt base linux linux-firmware neofetch nano gcc make xfce4 ... Итак, к чему я. Какие пункты OpenOS вы бы хотели модифицировать? И каким образом? Текущий список идей: Замена цветовой темы (openos-mod colorscheme [FG] [BG]) [ГОТОВО] Свой менеджер пакетов поддерживающий oppm и hpm (pacman) Замена загрузчика /init.lua (Полный вывод действий, вывод только стадий, анимация загрузки, ... - openos-mod bootloader [путь/к/пакету/загрузчика.bld]) Ссылка на репозиторий: https://github.com/Def-Try/OpenArch/tree/main Буду очень рад вашему вкладу в проект

Библиотека filesystem абстрагируется от действий текущего юзера и рабочей директории, предоставляя более "сырой" доступ к файловой системе без высокоуровневых проверок. Для поддержки поиска по раб. директории следует обратиться к методу shell.resolve(path), который используется большинством штатных скриптов в /bin/. Посмотри на отправляющий код с пред. сообщения - там я как раз добавил эту фичу для удобства Всё верно. В десктопном Lua ты получил бы что-то наподобие: А в OpenComputers уже нет, т.к. глобальной переменной arg вовсе не существует: Все входные аргументы мы получаем вручную через args = {...}, создавая при этом самую обычную переменную. Она не какая-то магическая, не системная. Её и назвать можно как угодно, хоть someWeirdDots = {...}, тут уж воля фантазии Согласен, хотя это скорее дело привычки. Всегда можно скопировать таблицу направлений из исходников Sides API, и воспользоваться ей для движения робота в нужную сторону, если вводить непонятные цифры а-ля robot.move(1/2/3/4) дискомфортно Как раз по этой ссылке и перечислены все остальные "низкоуровневые" команды, других попросту не существует в компоненте robot. Пикча для наглядности: Например, back/up/down реализуются софтверно средствами OpenOS. При этом robot.back() из OpenOS эквивалентен компонентному вызову robot.move(2). Вообще крайне рекомендую чекнуть исходники по пред. ссылке - там много всего интересного, и на деле окажется, что работа с "чистым" роботом ничуть не сложнее, чем с библиотекой из OpenOS. Непривычно и неочевидно - да, есть такое

Сделал сам, но без пима, а чисто на сундуках, норм работает.

Один из игроков в мой модпак сделал видео по тому как сделать убивающего робота.

Записал небольшой гайд о простом функционале

С/Assembly все кто с Windows играют знают, без этого не как

Проблема: мы с друзьями живём в различных измерениях или на огромном расстоянии друг от друга, из-за чего беспроводные модемы использовать невозможно. При этом нам нужна система, позволяющая отправлять приватные сообщения конкретному человеку, зная адрес получателя. Очевидным решением будет использование связанных плат, но что если нужно работать более чем с 1 получателем? Связанные платы, увы, лимитированы. Что если мы играем с GalactiCraft, имеем базу на Земле, и кровь из носу хочется контролировать добычу камня на Луне, реакторы на Марсе и ферму урана на Венере с одного компьютера? Решение: объединить множество связанных плат в кластер! Принцип работы системы проще пареной репы: каждый новый клиент, подключаемый к сети, должен предоставить 1 из 2 скрафченных связанных плат. Первую мы вставляем в кластер, а вторую - в компьютер клиента. Чтобы отослать сообщение другому клиенту кластера, нужно знать имя канала его связанной платы. Далее - дело техники: если сервер получает сообщение от связанной платы, то осуществляется поиск платы-получателя в нём же. Если плата-получатель не найдена, то сообщение перенаправляется через широковещательный пакет проводного модема всем серверам кластера, чтобы те в свою очередь попытались найти получателя. Если получатель найден - ему отсылается имя канала отправителя и само сообщение. Теперь подумаем, как лучше объединить связанные платы. Каждая плата может быть вставлена только в Tier 3 слот компьютера или сервера. Оптимальным решением для экономии пространства будет использование серверных стоек, т.к. каждый Tier 3 сервер имеет целых 2 Tier 3 слота. Поэтому каждый сервер сможет обслуживать максимум 2 клиента сети. В итоге схема расположения стоек и конфигурация серверов должна быть примерно такой: Процессор не важен, память не важна, и требования если не нулевые, то минимальные. Разумеется, каждый сервер будет работать на микропрограмме EEPROM, ибо крафтить для этого жёсткие диски было бы нецелесообразно. Берем код и прошиваем столько EEPPROM'ов, сколько требуется: https://gist.github.com/IgorTimofeev/15b75915caa93a344c2be25dac308138 После включения сервер будет доступен для взаимодействия. Как же отправить сообщение получателю? Используем функцию tunnel.send(), и первым аргументом указываем имя канала получателя. Его можно получить через tunnel.getChannel(): local tunnel = require("component").tunnel local receiver = "867a85de-ae4c-4359-b06f-0d30c5dad6f1" tunnel.send(receiver, "Привет") Это всё замечательно - но где же практический пример? Давайте запустим чат! Да простят меня боги, старые и новые, но я буду использовать MineOS, т.к. общаться через GUI мне банально удобнее. Во всех компьютерах сети создаем новое приложение, открываем файл Main.lua для редактирования: Берём исходник чата: https://gist.github.com/IgorTimofeev/724992e8641245a51cef57ac883f541f Вставляем его содержимое вместо имеющегося в Main.lua и запускаем приложение. Для отсылки сообщения необходимо ввести канал связанной платы получателя, а также отправляемый текст. Вот пример интеллектуальной беседы двух величайших умов современности: Кроме того, каждый сервер кластера поддерживает протокол для обновления прошивки по сети, а также удаленного отключения и запуска всех серверов. Для этого вам потребуется отдельный компьютер, находящийся в локальной сети с кластером. Для удобства я также накатал мини-приложение: https://gist.github.com/IgorTimofeev/0fe93bd4549aa32161b9dbbba59425e8 Подытоживая, хотелось бы отметить, что этот софт находится в разделе "программы новичков", он не преследует никаких глобальных целей и не реализует "киллер-фич", ориентируясь больше на прикладное использование. Разумеется, серверную часть можно улучшить по своему вкусу, добавив поддержку широковещательных пакетов, PING-систему и системные события по типу дисконнекта/доступности серверов, а для клинетского чата можно реализовать систему контактов и отсылку медиа-файлов. Было бы время и желание... Однако в своё время даже такой функционал неплохо сохранил нам нервы во время войн с серверной цензурой, а также экономил время, которое потребовалось для длительных полётов на разбросанные по уголкам вселенной базы. Надеюсь, для кого-нибудь эта схема будет так же полезна, как и для нас c:

Ни для кого не секрет, что существует множество занятных софтин для работы с геосканером и вывода результата на голопроектор, очки из OpenGlasses или просто в виде сечения на экран. Мне захотелось пополнить их коллекцию программой для просмотра результата сканирования от первого лица в трехмерном пространстве. Работает детище по принципу рейкастинга и на данный момент имеет следующие фичи: Сканирование местности по указанному радиусу (до 32 блоков), сохранение и загрузка результата Примитивная мини-карта для упрощения ориентации в пространстве Кастомизация дистанции прорисовки, полей зрения игрока и уровня детализации Выбор палитры (оттенки серого или спектральная) Изменение размеров окна курсором Разумеется, оперативку оно жрет быстрее, чем репликаторы поглощали флот Гоа'Улдов, а также требует топовый ПК для работы, т.к. хранит безумное количество данных о результатах сканирования. Изначально я хотел замутить софтину для управления дроном-грифером, делающего снимки местности для упрощения воровства картошки с полей, однако по факту получилась просто занятная игрушка без какого-либо практически полезного с точки зрения выживания функционала. Поэтому хотелось бы услышать предложения по использованию подобных технологий именно в сурве. Команда для установки, чтобы пощупать ручками: pastebin run Gm8t26kd