Лидеры

Кажется, часть файлов (сама библиотека) нашлась: https://github.com/AtomicScience/OCNS Там нет программ вроде смены IP и прочего, т.е. команда change_mIP работать не будет. Но сама библиотека вроде цела. (уже фантазии) А может быть, идёт разработка новой версии стека, который займёт место старого? (Скорее всего, причина прозаичнее: автору могло понадобиться место на Яндекс.Диске.)

Да, я удалил архив, и маловероятно, что смогу найти его. Поэтому вот ссылка на GitHub - https://github.com/AtomicScience/OCNS Проект я забросил, и очень маловероятно, что когда-либо возобновлю работу над ним. Если кто-то хочет продолжить работу/сделать форк/etc., то не вижу в этом никаких проблем

Я думаю попросить название взять такое же (mIP, mTCP, mUDP?) и попробовать, но ничего не гарантирую. Планирую делать другой алгоритм поиска пути, поскольку никто не хочет заниматься ручной настройкой и разницы рангов как таковой нет, система провайдеров нам не подойдет (требует ручной настройки и централизации в виде провайдера), как и DHCP (требует настройки и централизации в виде роутера). Поскольку сеть будет скорее всего одноранговая, то ARP технически тоже не нужен, как и виртуальные адреса (обойдемся физическими). Думаю больше подойдет что-нибудь типо адресной книги (над форматом все еще думаю), либо как zn сеть... В список сомнительной надобности из-за использования физических адресов также уходит NSP (и DNS). Протокол DIX Ethernet условно входит в сам мод, кроме чек-суммы (а может и да, я хз как там мод работает внутри), но нам все равно как он работает, главное, что гарантирует доставку по физическому адресу. Для реализации остается mIP для роутинга, mTCP и mUDP для сессий и передачи любой информации любой длины. К сожалению, из-за децентрализованности сети не получится сделать что-то кроме P2P, но с другой стороны игроки и не готовы строить централизованную сеть, ей просто не суждено быть. А вот P2P итак постоянно используется игроками почти везде, остается только сделать доступным всех членов сети, ну и повысить абстрактность соединений (спрятав адресацию и тп), облегчив тем самым написание сетевых приложений. Могу быть сильно неправ, хотелось бы услышать мнение других. EDIT1: Только увидел про русскую документацию пост, хах. Я тоже не горю желанием писать 2 документации, но видимо придется)

Сервер STEM был обновлён до 0.2.4 и перезагружен. (Прошу прощения у всех у кого посыпались коннекты. ) Был исправлен баг, который не позволял посылать пакеты длиной более 1.5 килобайт. Теперь можно без проблем слать пакеты до 64 кб размером (это уже ограничение протокола STEM - если нужны пакеты жирнее, просто разбивайте данные на чанки). Кроме того, я чуть чуть обновил OC клиент stem.lua - теперь можно делать просто stem.connect() не указывая никакого адреса, и библиотека законнектит на stem.fomalhaut.me. Спасибо @BrightYC за то что как обычно пинал и требовал фиксов, спасибо @Fingercomp и @NEO за помощь в установлении причин, и конечно же спасибо @Totoro за то что баг обнаружил и исправил несмотря на жестокую лень.

Да, при штатной работе программы достаточно соотнести тики реактора с тиками, которые смог обработать компьютер. TPS как таковой вообще не обязательно знать. Но когда реактор остановлен, нужен инструмент косвенной оценки лагов сервера, без реактора. Чем меньше ресурсов потребляет комп, чем чаще он находится в простое, тем ниже вероятность, что он отключится по TLWY. Правда, на практике может оказаться, что наш код выполнил уступку времени на несколько тиков, передав управление методу компонента, и поэтому формально наш компьютер простаивает. При этом сам майн, обрабатывая вызванный кодом метод, может лагать. Это предстоит выяснить экспериментально. Но в целом это правило подтверждается: чем больше времени код тратит на вычисления и чем реже обращается к периферии, тем меньше его вклад в лаги, и тем меньше вероятность возникновения TLWY конкретно для этого компьютера. MineOS кроме прочих несёт ещё и эстетическую функцию в "мирное" время. И аварийное отключение компа с MineOS во время лагов меня не огорчит. Но лагомерки в наших watchdog'ах, должны погаснуть в последнюю очередь. Это не проблема, если отказаться от измерения именно TPS. Более того, как верно заметил @Doob, тикрейт может быть штатно изменён модами. Да, метод computer.uptime всегда показывает тики, хотя и представляет их в виде секунд. Фокус же в том, что выполнение одного и того же кода может занимать разное количество тиков в зависимости от лагов сервера. И для лагомерки я предлагаю эксплуатировать именно эту особенность.

Так я не буду писать, а вы.

Добрый день, любители редстоун схем! Сегодня, вашему вниманию представляется полноценный редстоун контроллер redcontrol (оригинальное название ) Но всё не так скучно как может показаться В программе есть: Возможность подавать обычный редстоун сигнал мощностью 15 Подавать цветной сигнал (16 цветов) мощностью 255 Принимать редстоун и цветной редстоун сигналы и видить их характеристики (цвет и значение) Управлять всеми шестью сторонами редстоун блоков (компов) Управлять всеми блоками редстоуна которые подключены в сеть В программе нет: Возможности задавать свою мощность генерации сигнала, кроме максимального (мне показалось это лишним) Управление: Красная кнопка справа сверху - выход Жёлтые указатели там же в углу - переход на между блоками Цветные кнопки - включение/отключение генерации выбранного сигнала Индикаторы: Буква G - генерация сигнала Цифры - мощность полученного сигнала Дробь в углу - текущий блок / число блоков в системе Скрины: Ссылка на код: http://pastebin.com/A8HHPHPB Рекомендации: Можете использовать как блоки, так и редстоун карты 2 ур. Но не в коем случае не ставьте карту 1 ур. Не ломайте редстоун блок на котором стоит прога - словите ошибку. Словили ошибку - лучше перезагрузите комп (для очистки event.listen) А с вами был qwertyMAN, удачной игры! Обновлено до v1.1 Добавлено: -Работа полностью на event (по идее теперь лагать не должно не у кого) -Исправлен вылет при отключении компонентов. Теперь можно со включенной прогой подключать/отключать компоненты

Эх, не дождались мы ТИТАНа...