eu_tomat

Каков текущий список задач? А если я переделаю какой-нибудь GUI на кнопочки в виде слоников, такое изменение будет принято?

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

Сколько бы вас там ни было, нет смысла создавать тему в разделе "Программы" без самих программ. Переношу тему в Беседку. В чём именно поучаствовать? В чём суть этой системы? Чем она будет отличаться от других?

А сколько обычно приходится ждать в таких случаях? И часто ли юнити отказывается работать? И нельзя ли обойтись вообще без юнити, если оно такое кривое?

Да чего уж там. Семь лет ждали эту программу, и ещё подождём. Недолго же осталось? Вот только зачем этот текст нужен в разделе "Программы" без самой программы? Для рассказов о далеко идущих планах у нас имеется, например, "Беседка" или даже блоги. Я думаю, читатели этой темы будут бомбить от того, что им не дали саму программу. Поэтому перенесу пока тему до лучших времён в "Беседку".

Это ещё что. Я на прошлой неделе пытался эту страницу в браузере открыть. Браузер, конечно, старый, и давно уже не обновляется для Windows XP, но он вполне обычный легальный браузер. Я раз 10 пытался доказать, что я не робот, помечая фотографии то светофоров, то грузовиков. В итоге страницу я так и не посмотрел. Окей, Гугол, я робот.

Ого! А в эмуляторе без ожидания что-ли работало? В Майнкрафте-то всегда ждать приходилось.

А что именно не работает? Как проявляется ошибка? И хорошо бы приложить ответную часть нерабочего кода. Иначе о причинах можно будет лишь гадать.

Я бы сказал иначе: не очень стабильно. Огромная разница. По факту сделать можно. Я даже предложил простой вариант более-менее стабильного алгоритма в этом посте: Также возможно более-менее стабильное обслуживание реактора без его останова даже на перегруженном сервере и даже на OpenComputers версии 1.6.3. Но стабильность этого решения сильно зависит от предсказуемости сервера. Всегда существует лаг такого размера, который окажется фатальным для того или иного алгоритма. Но с какой вероятностью такой лаг возникнет на сервере, это тоже важный вопрос. Может быть, такое случается один раз в полгода. Тогда риск может быть оправдан. А для тех, кто не желает рисковать, есть менее производительные схемы. Например, чередование в шахматном порядке топливных ячеек и конденсаторов позволяет охлаждать любой ТВЭЛ как минимум двумя конденсаторами. Тогда во время замены любого конденсатора смежные с ним ТВЭЛы будут подстрахованы другими конденсаторами. Только надо позаботиться о том, чтобы конденсаторы не изнашивались одновременно, чтобы во время замены всегда были конденсаторы с достаточным запасом поглощения тепла.

Я не уловил взаимосвязи. Эти наработки помогают обойти ошибку 403?

@_bongo_ достаточно отредактировать этот блок: local users = { {"Creeper","Owner"}, {"Zombi","Member"}, {"Skeleton","Member"}, {"Ghast","Member"}, {"Blaze","Member"}, {"Witch","Member"} } Просто заменяем текущие имена на требуемые. Также можно изменить группу, к которой принадлежит игрок. Также можно удалить лишние записи или добавить недостающие.

О каком из вариантов программы идёт речь?

Без навыка можно создать лишь то, на что создатель запрограммирован генетически. В иных же случаях требуется либо наработка требуемого навыка, либо перенос уже имеющегося навыка в новую область. Также можно не создавать, а купить продукт у того, кто имеет навык его создания. Любая библиотека или программа для работы с ней требует какого-то знания. Поэтому такая постановка вопроса некорректна. Предлагаю ослабить условие и конкретизировать его. Например: Нужна библиотека для создания GUI с кнопками с записью кода не более 50 символов на кнопку. или: Нужна программа для визуального программирования GUI. Но читать документацию или смотреть видеогайды, если они есть, всё равно потребуется. Без знаний не получится создать ничего.

Так при указании корневой директории в качестве стартового пути вся смонтированная файловая система и обходится. В моём примере так и задано.

За изобретение велосипеда лайк. А нужный функционал уже реализован утилитой find.lua в OpenOS: find / --name=*find*

Также я выяснил, что максимальный размер считываемого блока для компонента filesystem составляет 2048 байт против 512 для компонента drive. И при использовании максимальных размеров блока скорости чтения filesystem и drive уравниваются. Учитывая это знание, я бы выбирал между filesystem и drive, исходя из оптимального размера блока. Но это справедливо для постоянно открытых файлов. В ином случае к затратам на чтение требуется добавить затраты на открытие и закрытие.

Оставлю здесь результат обсуждения в чате по этим двум постам: Я не учёл того, что размер данных, считываемых с кассеты, ограничен лишь размером доступной оперативной памяти, на что мне указал в чате@ProgramCrafter. Поэтому не смотря на то, что для чтения с кассеты требуется потратить один тик на позиционирование плюс один тик на чтение, итоговая скорость чтения с кассеты может оказаться в десятки раз выше скорости чтения жёсткого диска. Но возможность использовать преимущество чтения огромного блока в конченом счёте будет определяться конкретными условиями. Недостаточный запас свободной оперативной памяти даже если и позволит считать блок данных, не обязательно позволит его использовать, это сильно зависит от используемого алгоритма. Также чтение большого блока данных может оказаться попросту ненужным, так как тот же алгоритм B-tree позволяет обойтись меньшим количеством данных, но находящихся в независимых друг от друга блоках. И про затраты в два тика времени также не стоит забывать. Но я не исключаю, что в каких-то применениях лучшую скорость покажет именно работа с кассетами. Например, Lua позволяет быстро находить фрагменты хешей внутри даже больших строк, что позволит не тратить время и оперативную память на полную расшифровку считанного блока данных.

Это рассуждение применимо только по отношению к дрейфу тиков Майнкрафта относительно времени сервера. Такты же времени OpenComputers относительно тактов реактора не дрейфуют. По крайней мере, я такого поведения никогда не наблюдал, и предпосылок для него не вижу. Зато регулярно можно наблюдать внезапные задержки отдельных операций, не требующих дополнительной синхронизации. И значительно реже требуется вычисление новой задержки, которая будет актуальна до следующего сбоя синхронизации. Что такое рассинхрон? Это непредсказуемое изменение величины лага. Потому что если лаг постоянный, его можно учесть в управлении реактором. По сути именно учёт лага в планировании действий и позволяет сделать управление синхронным. А неучтённое изменение лага ведёт к сбою синхронизации. Что значит "зависают"? Реактор становится невосприимчивым к отключению сигнала редстоуна? Как долго сохраняется зависание? В какой схеме? Что является источником сигнала?

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

OpenComputers никак не препятствует созданию файлов размером с целый диск или даже RAID-массив.

Кассеты работают в сотни раз медленнее дисков. Поэтому RAID вне конкуренции. А кому и этого мало, то на сервер можно повесить несколько десятков дисковых массивов без особой потери производительности.

Вряд ли что-то сохранилось. Я никогда не проявлял особого интереса к программированию очков. Изучил механику, не более. Программы для очков обычно примитивны и доступны для написания даже новичку. Спроси у поисковика по фразе openperipheral_bridge, наверняка он подскажет примеры.

Для этого нужны очки из мода OpenGlasses.

Какие именно команды не работают?

@kosta1809 Похоже, не подключился мост. Иначе компонент отобразился бы.