Перейти к содержимому

eu_tomat

Модераторы
 Профиль  Активность

  • Публикации

    2 666

  • Зарегистрирован

  • Посещение

  • Победитель дней

    331

Сообщения, опубликованные пользователем eu_tomat

  1. Опубликовано:

    9 минут назад, Wolframoviy сказал:

    ладно, всё равно походу ещё долго ждать пока юнити заработает

    А сколько обычно приходится ждать в таких случаях?

    И часто ли юнити отказывается работать?

    И нельзя ли обойтись вообще без юнити, если оно такое кривое?

    • Спасибо 1

  2. Опубликовано:

    20 часов назад, Wolframoviy сказал:

    Пока что приложение не до конца разработано, есть только сервер и скрипт для робота. Так что - ждите, мои дорогие форумчане.

    Да чего уж там. Семь лет ждали эту программу, и ещё подождём. Недолго же осталось?

     

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

     

    20 часов назад, Wolframoviy сказал:

    Это мой первый проект, так что не бомбите от багов и проблем.

    Я думаю, читатели этой темы будут бомбить от того, что им не дали саму программу.

    Поэтому перенесу пока тему до лучших времён в "Беседку".

    • Спасибо 1

  3. Опубликовано:

    57 минут назад, serafim сказал:

    вроде помогло, ну и морока

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

    • Нравится 1
    • Спасибо 1
    • Грусть 1

  5. Опубликовано:

    2 часа назад, DivByZero сказал:

    я немного подредачил скрипт на свой лад но теперь он не работает

    Из за чего он может не работать?

    А что именно не работает? Как проявляется ошибка?

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

  6. Опубликовано:

    17 часов назад, Sasiso4kaS сказал:

    Эх послушав ваши рассуждения. Я понял, что сделать по факту можно, но работать будет очень нестабильно.

    Я бы сказал иначе: не очень стабильно. Огромная разница.

     

    По факту сделать можно. Я даже предложил простой вариант более-менее стабильного алгоритма в этом посте:

    В 18.08.2021 в 23:14, eu_tomat сказал:

    Аккуратная работа:

    • Загрузили реактор топливом и конденсаторами
    • Вычислили время ближайшей замены конденсаторов, уменьшив его на половину реакторного тика.
    • Подали сигнал красной платой, находящейся в управляющем компьютере.
    • Выждали нужное количество реакторных тиков в os.sleep и убрали красный сигнал.
    • Заменили уже непригодные конденсаторы. Их даже проверять не надо, они вычислены ещё до пуска реактора.
    • Вычислили время ближайшей замены следующей партии конденсаторов и т.д. по кругу.

     

    Также возможно более-менее стабильное обслуживание реактора без его останова даже на перегруженном сервере и даже на OpenComputers версии 1.6.3. Но стабильность этого решения сильно зависит от предсказуемости сервера. Всегда существует лаг такого размера, который окажется фатальным для того или иного алгоритма.

     

    Но с какой вероятностью такой лаг возникнет на сервере, это тоже важный вопрос. Может быть, такое случается один раз в полгода. Тогда риск может быть оправдан.

     

    А для тех, кто не желает рисковать, есть менее производительные схемы. Например, чередование в шахматном порядке топливных ячеек и конденсаторов позволяет охлаждать любой ТВЭЛ как минимум двумя конденсаторами. Тогда во время замены любого конденсатора смежные  с ним ТВЭЛы будут подстрахованы другими конденсаторами. Только надо позаботиться о том, чтобы конденсаторы не изнашивались одновременно, чтобы во время замены всегда были конденсаторы с достаточным запасом поглощения тепла.

     

     

  7. Опубликовано:

    19 часов назад, serafim сказал:

    Поскольку сайт под ддос защитой и возвращает только ошибку 403

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

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

    • Спасибо 1

  8. Опубликовано:

    @_bongo_ достаточно отредактировать этот блок: 

    local users = {
  {"Creeper","Owner"},
  {"Zombi","Member"},
  {"Skeleton","Member"},
  {"Ghast","Member"},
  {"Blaze","Member"},
  {"Witch","Member"}
}

    Просто заменяем текущие имена на требуемые. Также можно изменить группу, к которой принадлежит игрок. Также можно удалить лишние записи или добавить недостающие.

    • Нравится 3
    • Спасибо 1

  10. Опубликовано:

    7 минут назад, PayDayer сказал:

    Есть-ли какой-либо путь создать интерфейс приложения без навыков создания GUI?

    Без навыка можно создать лишь то, на что создатель запрограммирован генетически. В иных же случаях требуется либо наработка требуемого навыка, либо перенос уже имеющегося навыка в новую область. Также можно не создавать, а купить продукт у того, кто имеет навык его создания.

     

    9 минут назад, PayDayer сказал:

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

    Любая библиотека или программа для работы с ней требует какого-то знания. Поэтому такая постановка вопроса некорректна. Предлагаю ослабить условие и конкретизировать его. Например:

    • Нужна библиотека для создания GUI с кнопками с записью кода не более 50 символов на кнопку.

    или:

    • Нужна программа для визуального программирования GUI.

     

    Но читать документацию или смотреть видеогайды, если они есть, всё равно потребуется. Без знаний не получится создать ничего.

    • Спасибо 1

  11. Опубликовано:

    3 минуты назад, miner7 сказал:

    А им можно весь диск обойти?

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

    • Спасибо 1

  13. Опубликовано:

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

     

    Но это справедливо для постоянно открытых файлов. В ином случае к затратам на чтение требуется добавить затраты на открытие и закрытие.

    • Нравится 1
    • Спасибо 2

  14. Опубликовано:

    Оставлю здесь результат обсуждения в чате по этим двум постам:

    В 20.08.2021 в 10:16, ProgramCrafter сказал:

    Надо бы ещё проверить, как ведут себя кассеты из аддонов, особенно самая большая.

    В 20.08.2021 в 11:03, eu_tomat сказал:

    Кассеты работают в сотни раз медленнее дисков.

    Я не учёл того, что размер данных, считываемых с кассеты, ограничен лишь размером доступной оперативной памяти, на что мне указал в чате@ProgramCrafter.

     

    Поэтому не смотря на то, что для чтения с кассеты требуется потратить один тик на позиционирование плюс один тик на чтение, итоговая скорость чтения с кассеты может оказаться в десятки раз выше скорости чтения жёсткого диска. Но возможность использовать преимущество чтения огромного блока в конченом счёте будет определяться конкретными условиями.

     

    Недостаточный запас свободной оперативной памяти даже если и позволит считать блок данных, не обязательно позволит его использовать, это сильно зависит от используемого алгоритма. Также чтение большого блока данных может оказаться попросту ненужным, так как тот же алгоритм B-tree позволяет обойтись меньшим количеством данных, но находящихся в независимых друг от друга блоках. И про затраты в два тика времени также не стоит забывать.

     

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

    • Спасибо 2

  15. Опубликовано:

    19 минут назад, Disc2 сказал:

    Я говорил про накопление результатов рассинхрона - как если есть два часовых механизма,но один спешит на 0.00001сек\час.

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

     

    Что такое рассинхрон? Это непредсказуемое изменение величины лага. Потому что если лаг постоянный, его можно учесть в управлении реактором. По сути именно учёт лага в планировании действий и позволяет сделать управление синхронным. А неучтённое изменение лага ведёт к сбою синхронизации.

     

    50 минут назад, Disc2 сказал:

    бывают баги когда сигналы редстоуна на реакторе зависают

    Что значит "зависают"? Реактор становится невосприимчивым к отключению сигнала редстоуна? Как долго сохраняется зависание? В какой схеме? Что является источником сигнала?

    • Спасибо 1

  16. Опубликовано:

    1 час назад, Disc2 сказал:

    Да поставить чтобы один пропихивал кондеры перманентно.:smile14: 

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

    1 час назад, Disc2 сказал:

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

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

     

    1 час назад, Disc2 сказал:

    даже если будет небольшой рассинхрон между компом и реактором - он будет сбрасываться с каждой заменой кондеров,и не будет аккумулироваться.

    Основная проблема заключается не в накоплении лага, а в непредсказуемости момента и величины его изменения. Да и в большинстве случаев лаг не аккумулируется. Это похоже на одиночные волны, которые, накатываясь, всегда откатываются назад.

    • Спасибо 1

  18. Опубликовано:

    41 минуту назад, ProgramCrafter сказал:

    Надо бы ещё проверить, как ведут себя кассеты из аддонов, особенно самая большая.

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

    • Спасибо 1

  19. Опубликовано:

    3 минуты назад, kosta1809 сказал:

    А у тебя есть какие то полезные программки для очков? Отображение чего то и т.д. Ну например отображение температуры реактора из IC2

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

    • Спасибо 1
×
×
  • Создать...