AtomicScience

Вот именно - вы боитесь поднять голову выше банального пинг-понга пакетами между платками, а ваши низменные интересы ограничены фермами пшенца и картошечки на дронах и прочей ерунде уровня третьего класса церковно-приходской IT-школы. Когда на AtomicWars (дай бог ему здоровья и стабильной работы) вы задумаетесь над чем-то более глобальным, чем пароли на двери и бурение шахт друг-другу... на участках, вы так или иначе столкнетесь с необходимостью соединить ваши компьютеры, дронов и роботов в сеть. И именно тогда вы вспомните старину Атомика, который, словно Прометей, принес вам то, что изменит вашу жизнь навсегда. Запомните этот твит

Окей, а теперь прикрути к своему примеру рукопожатие и завершение сессии. Уверяю, получишь немногим менее обьемный код, чем мой Я тоже могу "просто" (и обрати внимание, что твое пример оперирует с пакетами, а мой - с сессией): local mnsp = require("OCNS").mNSP local listeningStream = mnsp.NetworkStream:newStream("l", nil, 0, 228) function onReceive(stream, address, remotePort, data) local respondStream = mNSP.NetworkStream:newStream("w", address, remotePort, 228) respondStream:print(data) respondStream:flush() respondStream:close() end listeningStream:attachListener(onReceive) Важно понимать, что echo демонстрирует не простоту стека, а возможность использования потоки по четко выделенному назначению. В моем примере есть поток для рукопожатий, отдельные потоки для клиентов с уникальными обработчиками - это все позволяет по-настоящему абстрагироваться от сети, вертя в руках лишь шайтан-поток, который словно по волшебству получает и отправляет данные - именно такой подход будет использоваться в серверах Прекрасной Сети Будущего. mNSP это всего лишь пример чудес, которые можно творить с помощью абстракции. Да, это не лучший вариант работы с сетью, но я взял именно его, потому что хотел универсальности Но ты прав, API потоков весьма и весьма грубо - мне стоило добавить функцию printf, которая бы автоматом писала бы в поток и отправляла его, автоматическое чтение из потока с слушателями и прочее. Альфа все-таки

Сейчас выполним

Полностью солидарен. Обещаю, что вторая версия протокола будет выложена с нормальным загрузчиком, а код будет доступен на GitHub вместе с вики, если повезет Стек как-раз таки и задумывался для маршрутизации в сложных сетях, эксплуатирующих различные среды передачи данных, но на данный момент он позволяет работать только в пределах одной Ethernet-сети, то есть в "пределах работы дефолтных сетевых карт" DHCP (mDHCP, если быть точнее) планируется, а на первое время я реализую что-то типа виндового Zeroconf, то бишь просто выделю небольшой диапазончик адресов и позволю машинам самим выбирать себе адрес при подключении к сети - в результате сеть будет настраиваться сама. Круто! Вот чего-чего, а вот профанства в английском от самого великого и легендарного Тоторки я никак не ожидал. Но на самом деле содержать две версии кода и документации очень неудобно, но понял я это только когда сам столкнулся с необходимостью МНОГО комментировать и документировать - теперь я даже понимаю ECS'а, который нахрен снес всю русскую документацию к MineOS и оставил только английскую. К тому же я ориентирую стек в большей степени на англоязычных юзеров и разработчиков, ибо наше комьюнити, без обид, ныне представляет из себя весьма жалкое зрелище, особенно на фоне потрясающих проектов прошлых лет, которые уже воспринимаются как наследие какой-то великой, но ныне павшей цивилизации.

Ответы на первые три вопроса содержатся в обновленной теме, а вот на вопрос "Как оно работает" ты ответишь себе сам, изучив мой по самые помидоры закомментированный код

Сразу проясню, что стек еще - это сразу разрешает очень много вопросов, например, "почему нет установщика?" - да просто потому, что постоянно мурыжить GitHub или, Боже упаси, Pastebin, просто не имеет смысла, поскольку альфа-версия по определению не предназначена для "боевого" использования, так что наш воображемый игрок на сервере просто не должен ее качать, а вот этот же игрок в креативе в своем мире на локалке - пожалуйста Но я согласен с тем, что установщик нужен. Не подскажешь самый удобный на твой взгляд? P.S. Обновил тему

Представляю вам плод своего долгого и упорного труда - стек протоколов для OpenComputers. Постарался создать аналог дискетки Network Stack, но это вылилось в полностью независимый стек - OpenComputers Network Stack или же OCNS Об OCNS в целом: OpenComputers Network Stack это TCP/IP-подобный стек протоколов, цель разработки которого - попытка стандартизировать сетевое взаимодействие компьютеров в OpenComputers. Первая версия стека, описание к которой вы сейчас читаете, является альфа-версией - много чего еще недоделано, часть протоколов напоминает грубые поделки, но я все же решился предоставить эту версию на суд общественности. Особенности стека: В архитектуру OCNS изначально закладывались следующие качества: Модульность Для легкой расширяемости и дополняемости протокол должен поддерживать возможность представления своих составляющих в виде отдельных элементов. Каждый протокол в стеке реализован в виде отдельного файла, соблюдающего определенное API для протоколов своего уровня, но для достижения идеальной модульности предстоит сделать еще многое - добавить автоматическую загрузку файлов без необходимости жестко прописывать оные в init.lua, написать адекватный менеджер конфигурации и т.д. Абстракция Для пользователя протоколов верхнего уровня не должно иметь никакого значения, как именно происходят маршрутизация, установление канала, сегментирование данных и прочее, и прочее. Четкое разделение протоколов на уровни и жесткое API позволяет пользователю просто использовать интерфейс протоколов высокого уровня, а разработчику протоколов - использовать лишь один протокол нижнего уровня, делегируя реализацию всех низлежащих деталей ему. Эффективность Вместо того, чтобы слепо подражать реальным протоколам, OCNS реализует свою, OpenComputers-ориентированную систему, и имеет автора, которому приходится высасывать преимущества своего стека из пальца, поскольку список из двух преимуществ выглядит не очень солидно Протоколы стека: OCNS предоставляет протоколы, распределенные по модели OSI следующим образом: Сеансовый: mNSP Транспортный: mUDP, pingStub Сетевой: mIP, mARP Канальный + Физический: Драйверы интерфейсов Начнем с самого низу: - Интерфейсы OpenComputers предоставляет множество сред передачи - туннельные карты, проводная сеть, беспроводная, и прочее. И чтобы унифицировать их интерфейсы, нам нужно создать одно API и объекты, которые будут соединять среды передачи с этим интерфейсом. Также ООП подход позволит создавать что-то совсем экзотическое, например, передачу пакетов через редстоун или дискеты, которые будут таскаться дронами. К версии 1 все протоколы жестко зависят от primary сетевой карты в системе, то есть все вышеописаное является лишь мечтой планами - mIP Протокол маршрутизации, очень и очень близкий к реальному IP. Использует крутые 3-октетные адреса (x.x.x). К версии 1 реализовано очень мало от запланированного - он позволяет просто передавать пакеты в одной локальной сети - mARP Протокол, который ищет некрутые физические адреса по крутым mIP адресам К версии 1 приведен в божеский вид и не планируется к изменениям - mUDP Протокол, позволяющий открывать mUDP-сокеты и работать с ними К версии 1 приведен в божеский вид и не планируется к изменениям - pingStub Старый протокол для отладки сетей, помечен к удалению, ибо теперь вместо него используется mUDP - mNSP Протокол, который позволяет общаться через mUDP сокеты с помощью очень удобных потоков. Ссылка на GitHub - https://github.com/AtomicScience/OCNS ------------------- В общем, представляю на ваш суд. Но учтите, что это очень и очень сырая альфа. Приемлю любые замечания и предложения.

А я забыл уже

В целом, улей это достаточно крутая идея. И у меня есть парочка идей по этому поводу. 1) В улье должна заправлять "матка" - специальный сервер, который будет подключаться через интернет-карту к реальному компьютеру, исполняющему, допустим, Python-программу (нейросеть на 4МБ ОЗУ - такое себе). Она анализирует (хотя это скорее ИИ, а не нейронка) задачу, которая ей дана - допустим, создание определенного количества роботов, разбивает ее на несколько мелких (создание робота = поиск ресурсов + крафт компонентов + крафт робота) и делегирует их роботам. Основная задача "матки" - недопущение собственной разрядки и разрядки роботов. 2) Роботы также должны иметь нейросеть или ИИ, но куда меньшие, предназначенные для решения "маточных" задач из разряда принеси-подай, добудь-поставь.

Думаю, это мод на шляпы

Карта невероятно простая, прошел за 10 минут P.S. А ведь получается, что у тебя образовалась целая серия карт, описывающих жизнь хакера - взлом интернета в 11 лет (просто), кража ответов ЕГЭ (средне) и взлом Сбербанка (сложно). Это получилось случайно?

Кстати, в принципе можно портировать игру TIS-100, у нее как раз "консольная" графика, так что проблем возникнуть не должно

Ну, для местных нужд хватит и собственного формата. Вот у меня, например, есть наработки браузера и собственного формата веб-страниц, основанного на фреймворке GUI от @@ECS Кстати, кто-то изучил более-менее досконально Minitel? Просто интересно, может это и есть "сеть будущего"?

Браузер делали-делали, да не доделали, к сожалению. Да и, думаю, это малореализуемо - обработка и отображение HTML-страниц на мониторе разрешением 160x100

А, собственно, чем оно тебе не угодило?

Также есть еще один способ: Поскольку сочетание клавиш Ctrl+Alt+C кидает ошибку "interrupted", мы можем ее отловить с помощью pcall(), например, при вводе пользователем строки. Ниже - кусочек кода из одной программы с Minecraft Wiki: io.write("Enter password: ") err, try = pcall(io.read) -- если игрок попытался прервать программу if not err then print("No, no, no!") end

Ну тогда зачем нам вообще валюта? Зачем напрягаться, ставить какие-то моды, утяжелять сборку? Просто добавить крафт алмазов в обломки и назад, и все - торгуйся своими алмазами, покупай нужные ресы, продавай лишние

А вот зачем нам обеспечивать валюту каким-либо ресурсом? Учитывая то, что в руках у администрации есть огромное количество рычагов для управления экономикой, подкреплять деньги, как я считаю, не нужно. Лучший способ это, имхо, все-таки выдача валюты в стартовом наборе: поможет обустроить улей на начальных этапах и наглядно объяснит игрокам все прелести цивилизованной торговли перед бартером или самостоятельной добычи всех без исключения ресурсов. Количество валюты будет прямо пропорционально количеству игроков, следовательно даже не придется водиться с эмиссией

В этом случае количество игровой валюты в игре будет изменяться не прямо пропорционально онлайну, следовательно будет иметь место инфляция, и владельцам магазинов придется постоянно актуализировать цены, что не есть гуд

Оптимальный вариант, как мне кажется, поскольку количество валюты напрямую зависит от количества игроков. Соответственно, если игроки будут активно участвовать в торговле, а вмешательство сервера в систему будет минимально, то как-раз таки реализуется концепция рыночных "плавающих" цен и можно будет не волноваться насчет стоимости валюты.

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

Ну, значит я реально сделал все не так Попозже попробую сделать нормально, а там поглядим на производительность

Я решил провести несколько замеров, чтобы убедиться в правильности следующего утверждения товарища Totoro: Итак, я набросал следующий код: local component = require("component") local gpus = {} for address in component.list("gpu") do table.insert(gpus, component.proxy(address)) end for i = 1, #gpus do gpus[i].bind(component.screen.address) end ---------------- local op = { function(i) gpus[i].fill(30, 30, 1, 1, tostring(i)) end, function(i) gpus[i].set(30, 30, tostring(i)) end, function(i) gpus[i].setForeground(i * 600000) end, function(i) gpus[i].setBackground(i * 100000) end, function(i) gpus[i].copy(30, 30, 1, 1, 30, 30) end } local op_num = 1 local gpu_num = 1 local start_time = require("computer").uptime() for i = 1, 10000 do op[op_num](gpu_num) op_num = op_num + 1 gpu_num = gpu_num + 1 if gpu_num > #gpus then gpu_num = 1 end if op_num > #op then op_num = 1 end end component.gpu.setForeground(0xFFFFFF) component.gpu.setBackground(0) print("Результат для " .. #gpus .. " видеоядер : " .. (require("computer").uptime() - start_time) .. " секунд") Он выполняет все 5 типов операций на каждой из доступных ему видеокарт, всего 10000 операций. Запускаем несколько раз с разным количеством видеокарт, наслаждаемся несколько секунд мелькающими цифорками и получаем результат: 1 видеоядро: 3.15 2 видеоядра: 3.15 3 видеоядра: 3.14 4 видеоядра: 3.15 5 видеоядер: 3.14 Вывод делайте сами Возможно, я что-то сделал не так, но все же

Помню @@FluttyProger хотел реализовать отрисовку то ли GIF-анимации, то ли полноценного видео, с помощью нескольких ПК, у него даже альфа-наброски были, то есть возможно на один монитор выводить изображение с разных компьютеров. Также можно разделить один экран пополам и выделить каждой видеокарте свою половинку монитора - по идее сработать должно, а-ля VSync А две видеокарты к одному монитору подключить НЕВОЗМОЖНО, это даже в документации написано: http://ocdoc.cil.li/component:gpu (метод bind) По логике, если один монитор подключен к двум ПК, то при запуске системы на каждом компьютере она автоматически забиндит видеокарту на этот монитор (если он один)

Урон от падение, спавн монстров и PVP. Еще: Добавить игрокам перм на /sethome