Лидеры

Посмотрел я на тему "Возрождаем OpenNet (не опять, а снова)" и ради интереса решил накодить свою реализацию. Так вот. Представляю NetQuartz. Что эта ерундовина может: Многоуровневые IP адреса. Можно хоть 1.2, хоть 26.89.1.2, хоть 734.84.1.97.73.4, все зависит от вложенности роутеров. Встроенный DNS. Простенький веб-сервер и браузер с поддержкой цветов. Простая регистрация устройства в сети (хочешь подключиться - поставил ПО на клиента, написал одну команду - все готово!) Что она пока не может: Нема API. Нема всяких <hr> <a href> и прочей фигни. Ну и браузер бы полностью гуишным сделать. Тестил только на проводных подключениях! В теории конечно и вайфай должен работать, но в теории. Что она не может и добавлять не планирую: Шифровка трафика и прочая ерунда с безопасностью Терминология: роутер == маршрутизатор Корневой роутер (сервер), корень [сети] - основой компьютер, связывающий маршрутизаторы и клиентов, выполняющий функции DNS сервера и лежащий в иерархии сети выше всех. Всегда имеет IP 0.0. В одной сети может быть только 1. Маршрутизатор, роутер - компьютер, обеспечивающий перенаправление пакетов (маршрутизацию) от отправителя к получателю. Пакет (в контексте данного проекта) - 4 текстовых поля - Отправитель, Получатель, Тип, Данные Клиент - Любой компьютер / планшет / микроконтроллер / дрон / робот, подключенный к сети, являющийся конечным узлом. (То бишь, не имеющий дочерних узлов.) Узел - любое устройство в сети. Как это все работает: В контексте данного раздела "послать" == modem.send(). Все работает на 1110 порту. Если пакет типа DATA или DNSANSWER (в последнем случае 3-ий шаг выполнятся не будет, т.к. пакет уже послан с корня сети.): Клиент-отправитель посылает пакет на роутер, который его зарегистрировал в сети. Роутер получает пакет. Теперь есть несколько вариантов обработки: 1. Получатель находится в подсети роутера (включая вложенные подсети): роутер находит MAC узла, находящегося в адресе получатеся сразу после IP данного роутера и посылает на него пакет. Здесь неважно, является ли этот узел роутером или уже клиентом. Если получит роутер - пункт 2 повторится. 2. Получатель находится вне подсети роутера: Здесь еще проще - роутер просто посылает этот пакет родительскому узлу. Корневой сервер получает пакет. Данный шаг будет проделан, только если во время 2-ого шага роутеры добросали пакет вверх прямо до корня (например, в случае если отправитель 1.2, а получатель 2.3). Тут происходит все то же самое как и в 2.1. Клиент-получатель принимает пакет. На этом путь пакета завершен. Как он будет обработан - определяет ПО. Если пакет типа DNSREG или DNSLOOKUP: Клиент-отправитель посылает пакет на роутер, который его зарегистрировал в сети. Роутер получает пакет и перенаправляет его на родительский узел. Так повторяется, пока пакет не достигнет корня. Корень получает пакет, обрабатывет его и посылает ответ в виде DNSANSWER пакета. Если пакет типа FINDPARENT: (эти действия происходят при вып. кмд qclient find. При исп. другого ПО алгоритм обработки пакетов на стороне клиента может отличаться.) Клиент-отправитель посылает пакет методом broadcast. В поле данные указано "find". Любой роутер, получивший это отзывается сообщением (не пакетом) "FINDROUTER:ME". В т.ч. и корень. Клиент получает самый первый пакет и отсылает обратно уже методом send пакет FINDPARENT. В поле данные уже указан MAC роутера, на котором клиент желает зарегистрироваться. Собственно на этот же MAC и отсылается пакет. Роутер, получивший пакет, сравнивает свой MAC с указанным, и если они совпадают, то выдает клиенту IP и отсылает клиенту сообщение (не пакет) с его IP. Клиент сохраняет все в qclient.conf в формате MACродителя;свойIP. Железо и ось: Требования по железу: Обязательная сетевая карта. Минимум 25КБ свободного дискового пространства. Видеокарта 1+ ур. Рекоменд. дисплей. Процессор мин 1+, рекоменд 2+. ОЗУ не тестил. На тестовых компах стояло 2*2уровень На всех тестовых компах стояла ОпенОСЬ из коробки без модификаций. Как этим безобразием пользоваться: Создаем корневой сервер: Качаем на него root.lua и ttf.lua в папку /home/. Создаем папку /home/QuarksRouter/. Запускаем root.lua Создаем роутеры: Качаем unit.lua и ttf.lua в папку /home/. Создаем папку /home/QuarksRouter/. Подключаем и запускаем роутеры: Качаем qclient.lua в папку /home/. Пишем qclient find. После запускаем unit.lua Подключаем клиентов: Качаем qclient.lua в папку /home/. Пишем qclient find. Настраиваем веб-сервер: Качаем server.lua, желательно в папку /home/QServer/. Там же создаем папку /home/QServer/mctpdocs/, в нее будем пихать странички. ОБРАТИТЕ ВНИМАНИЕ! Страницы без расширений. Домашняя - index. Делаем странички: Пихаем файлы без расширений в папку /home/QServer/mctpdocs/. В них пишем любой текст. Поддерживается цветовое форматирование как в обычном майне, с помощью &. Также можно менять фон. Для этого пользуемся теми же колоркодами, только с префиксом не &, а ^. Запускаем сервер server.lua Ставим браузер на клиента: Качаем web.lua. Пишем web <url>/<page> (web test.low/test) для доступа. Регистрируем домен: На веб-сервере пишем qclient -p -l --r="0.0" --d="DNSREG;тутжелаемыйдомен". Собственно все. Гайд по qclient: -p - обязательно писать -l - слушать входящий пакет --r="ip.получателя" --d="типпакета;данные" Гайд по пакетам: Формат пакета: IPотправителя;IPполучателя;тип;данные Возможные типы: DNSREG - регистрация домена. В поле ДАННЫЕ пишем желаемый домен DNSLOOKUP - поиск ip по домену. В поле ДАННЫЕ пишем желаемый домен. DATA - пакет с данными. Типы, которые юзать нежелательно: DNSANSWER - ответ корневого сервера. В поле ДАННЫЕ указано QDNS:ответ. FINDPARENT - единственный broadcast-пакет. Регистрация в сети. Ссылки: root.lua https://pastebin.com/BDBsU4qm unit.lua https://pastebin.com/drZQ4MD0 qclient.lua https://pastebin.com/wMZqWwwL ttf.lua https://pastebin.com/rhbG8CW8 server.lua https://pastebin.com/mjzSm4Hi web.lua https://pastebin.com/xNYssMWc P.s. это мой первый проект на луа.

Об этом выше уже упомянул @serafim : Но с этим вроде как разобрались: На практике проверял я. Момент узнать можно. Ты в своей программе уже выполняешь проверку tr.getStackInSlot(sides.up,23).damage > 1000. И если будешь сравнивать значение прочности с полученным на предыдущем шаге, ты поймаешь тот майнкрафтовский тик, в который был выполнен реакторный тик конкретно этого реактора. Следующий реакторый тик повторится ровно через 19 майнкрафтовских тиков. И так далее с интервалом 20 тиков, пока чанк не перезагрузится. После перезагрузки чанка потребуется синхонизироваться заново. За 19 тиков теоретически можно выполнить 9 обменов конденсаторов. Или даже 10 обменов, если отказаться от постоянного чтения запроса прочности конденсатора. Но всё это актуально, если нет лагов. Даже на ненагруженном сервере иногда случаются микролаги, и в запасе оказывается не 19 тиков, а всего 18. Да и транспозер также может отработать не за положенный тик, а за два. А на лагающем сервере вообще может потребоваться несколько тиков. К сказанному добавлю, что короткое отключение реактора в правильно выбранный момент и вовсе не приводит к снижению выработки энергии. Главное, держать реактор включенным в момент реакторного тика. А в течение остальных 19 тиков реактор можно держать выключенным, без конденсаторов и топлива. Такова механика. Если интерес чисто теоретический, то конденсаторы можно менять без останова реактора. На лагающих же серверах реактор лучше останавливать, правильно выбрав момент. При наличии лагов отключение подстрахует от взрыва. А при отсутствии лагов реактор даже и не заметит отключения. Но нужно помнить, что все эти лишние включения-выключения создают нагрузку на сервер. Как, собственно, и непрерывная проверка износа конденсатора также нагружает сервер. Следующая идея, которая поможет успешно решить задачу: слона надо есть по частям. То есть, не надо пытаться между реакторными тиками поменять сразу все конденсаторы. Схема с тремя столбиками конденсаторов выдаёт 9856 hu/s. Ёмкость же лазуритового конденсатора составляет 100k hu. Это значит, что замена конденсатора требуется в среднем один раз в 100000/9856 = 10.146 секунд. За это время пройдёт 10 реакторных тиков. В идеале реактор будет требовать внимания один раз в 10 секунд. Но такое планирование требует серьёзно расшевелить мозги, да и алгоритм может оказаться тяжеловатым для сервера. Но можно решить задачку попроще: спланировать график ближайших замен всех компонентов таким образом, чтобы за один реакторный тик требовалось не более одной замены. А если ещё и отказаться от непрерывной проверки износа конденсатора, то получим рекордные две операции на один реакторный тик. Это будет лучшей защитой как управления реактора от лагов сервера, так и самого сервера от некачественного управления реактором.

теоритически можно менять конденсаторы без нагрева реактора в определённый момент времени но есть маленькая проблема - низкий TPS на сервере + лаги в итоге получаем включенный реактор без теплопоглатителя с вероятностью взрыва выключение реактора и замена конденсатора много времени не занимает, да энергии чуть меньше расчётной, но зато это безопасно

Осталось найти ещё 36 ошибок.

Мы ж программисты. Давай рассуждать логически. Да, додумал. Благо, вариантов не так много. Например, ты согласен с источником, и в случае его ошибочности заблуждаешься вместе с ним. Либо, отдавая себе отчёт в некорректности утверждения, намеренно вводишь читателей в заблуждение. Я предпочёл первый вариант. Додумал. Какие ещё существуют причины для вброса ложного утверждения? Смотрим выше и видим конкретные места в исходниках (с кусками ассемблерного кода и описанием причин): Выше есть и результаты замера пар int/float и int/int: В сухом остатке в твоём посте новой информацией оказались лишь результаты замера для пары float/float. Да и то, для операции обычного деления, а не целочисленного. А это разные операции: в случае обычного деления не требуется округление результата. Начинался же пост претенциозной фразой: Мораль: обесценивая сообщения предыдущих участников и претендуя на новизну, будь готов к тому, что любой высказанный тобой тезис также будет подвергнут оценке и, возможно обесценен. Полагаю, вопрос ценности и новизны исчерпан. Возвращаемся к исходному вопросу. Что именно ты предлагаешь? Как эту тему назвать? О чём она? Об оптимальном способе округления? Об оптимизации кода? О целочисленном делении? Какие посты предлагаешь перенести из этой темы в новую? Или ничего переносить не надо, а просто процитировать в новой теме? И о объединении каких материалов идёт речь? Что, с чем и как предлагаешь объединять? И как предлагаешь систематизировать наработанный материал, учитывая, что на результат измерений влияет не только оборудование, но и другое ПО, разделяющие общие с Lua ресурсы? Была когда-то тема с похожей идеей. Но там тоже всё сложно.

Экспериментальное обновление Ocelot. Я синхронизировал Ocelot Brain с последними изменениями в оригинальном моде. (Релиза у них ещё не было, но вроде фишки интересные, имеет смысл подтянуть их в эмулятор). Основное изменение это буферы видеопамяти (vram), можно делать графику быстрее и круче (в теории). Кто-нибудь уже игрался с этим? Протестируйте пожалуйста, потому что пока всё сделано на черновую. Ocelot Desktop VRAM Edition - Скачать бесплатно без СМС