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

eu_tomat

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

  • Публикации

    2 666

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

  • Посещение

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

    331

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

  2. Опубликовано: · Изменено пользователем eu_tomat

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

     

    При желании робота, не оснащённого контроллером инвентаря, можно снабжать кирками через воронку. Роботу нужно только пройти мимо неё правым боком.

     

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

     

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

     

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

    • Нравится 4

  3. Опубликовано: · Изменено пользователем eu_tomat

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

     

    Если речь идёт о лайфхаках, то вот ещё несколько:

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

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

    я удивился на цифре 1080. но все равно это какая-то дичь, тем более, что даже 21:9 поддерживается тремя с половиной играми.

    Дичь не дичь, а предложение на рынке имеется. На Яндекс-Маркете есть две модели.

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

    Прочел ваши посты и вообще ничего не понял. Надо либо все чистить, до основания, либо не чистить совсем. ;)

    Подчистил ещё раз. Главный смысл того оффтопа был в том, что моё раннее высказывание оказалось ложным

    Тут я соглашусь с Алексом. Дизайн меня не беспокоит.

    Просто я забыл, что ещё год назад добавил множество костылей в CSS-стили через расширение браузера. Костыли местами приводили к наезду одних элементов на другие, но основная цель - миниммзация скроллинга была достигнута. Сейчас я пытался минимизировать скролллинг ещё сильнее и тоже ценой наезда одних элементов на другие. Сам я справиться не смог, и @Alex помог мне выйти на удовлетворяющее меня решение. Разумеется, на сайте эти решения не применимы, и всё обсуждение было оффтопом в стиле: - это никому не нужно, - мне нужно, - это бред, - меня устраивает, - ну, бред же, - всё равно спасибо.

  8. Опубликовано: · Изменено пользователем eu_tomat

    Любое развитие в ширину, что в Factorio, что в Minecraft упирается в лимит вычислительных ресурсов сервера и компьютеров игроков. Поэтому, как мне кажется, более удачный вариант - это развитие качественное.

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

     

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

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

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

    Идея хорошая но скучно играть будет и игра закончится через часов 20, к тому времени у тебя будет куча рейсов и собственно все, в ваниле больше делать то нечего.

    Да. Наверное, поэтому большинство старожилов почти не играет. Интерес возникает только при обнаружении нового алгоритма, а удовлетворение возникает не от сундуков, забитых ресурсами, а от скорости, с которой они добываются. Причём, эта скорость достигнута не каким-нибудь разогнанным карьером из BC, а собственными мозгами.

     

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

     

    Честно сказать, я и сам пока не до конца сформулировал, чего я хочу от игры. И мне было бы интересно услышать какие-то идеи в этом направлении.

     

    Сформулированые тезисы:

    * компы и роботы должны быть доступны на ранних стадиях игры;

    * все механизмы из модов должны полностью управляться компами и обслуживаться роботами;

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

    • Нравится 1

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

    Радует, что разговоры о смене движка перетекли в обсуждение дизайна. Выскажу свои соображения.

     

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

     

    Награды не играют большой роли для старожилов, они и так знают достижения друг друга без дополнительных знаков. Зато награды могут мотивировать новичков к позитивной деятельности. Мотивация слабая, но и затраты на неё мизерные. Кроме того, награды помогают случайным посетителям хотя бы примерно оценить компетенцию авторов и, соответственно, достоверность информации. А это облегчает им вхождение в тему и способствует желанию участвовать в обсуждениях.

     

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

     

    Ну, и например, сама надпись "награды" только занимает место. И так понятно, что эти значки на экране являются наградами. А при наведении курсора мыши развеиваются последние сомнения.

     

    Значки принадлежности к группе мне тоже кажутся ненужными. Текстовая подпись более чем информативна.

  11. Опубликовано: · Изменено пользователем eu_tomat
    Дополняющий гайд от @ECS

    Для желающих понять, на какой магии работает эта библиотека, я написал гайд:

    http://computercraft.ru/topic/2413-gaid-kak-ubrat-chyornye-polosy-po-kraiam-ekrana-opencomputers/

     

    Дополняющий гайд от @ECS:

    https://computercraft.ru/topic/2501-kak-ubrat-chyornye-polosy-po-krayam-ekrana-v30/

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

    На днях в чате прозвучал вопрос, как убрать чёрные полосы по краям экрана. На форуме есть замечательная библиотека от @ECS, которая хорошо решает поставленную задачу: http://computercraft.ru/topic/1130-avtomaticheskii-mssahtab-monitora-izbavliaemsia/

    Но есть два нюанса:

    1) Код библиотеки явно избыточен.

    2) При чтении кода библиотеки создаётся впечатление, что она работает на неведомой магии тёмных сил, что демотивирует новичков, изучающих OpenComputers.

    Я намерен восполнить данный недостаток.

     

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

     

    Благодарю @Totoro за предоставленную информацию:

    1) Текстура блока имеет размер 16 px, а ширина рамки монитора – 2 px;

    2) Высота символа на экране в два раза больше его ширины.

    Данной информации достаточно для получения всех необходимых формул. Приступим:

     

    Первый шаг: получить соотношение сторон экрана, выраженное в символах

     

    В мире Майнкрафта текстура блока имеет размер в 16 пикселей. На рамку с каждой стороны тратится по 2 пикселя независимо от размера монитора.

    Pdqexqc.png

     

    Очевидно, что размер монитора в пикселях кратен 16 и пропорционален количеству использованных блоков, а размер полезной части экрана всегда меньше размера монитора на 4 пикселя как по вертикали, так и по горизонтали. Поэтому разрешение нескольких мониторов, выставленных в ряд, всегда составит 16*n-4 пикселей по соответствующей координатной оси.

     

    Это подтверждает и формула от @ECS, реализованная в функции calculateAspect(screens), но имеющая более сложный вид. Я предлагаю и вовсе отказаться от отдельной функции, т. к. в текущих условиях это будет напрасной тратой ресурсов.

     

    Немного поясняющего кода: 

    -- размер монитора в блоках
sw,sh = component.screen.getAspectRatio()
-- размер экрана монитора с учётом затрат на рамку:
sw_ = sw*16-4
sh_ = sh*16-4
-- соотношение сторон экрана, выраженное в пикселях текстуры блока
sa = sw_/sh_
-- соотношение сторон экрана, выраженное в символах
sa = 2*sw_/sh_
-- оно же без промежуточных присваиваний:
sa = 2*(sw*16-4)/(sh*16-4)
-- оно же после упрощения формулы и сокращения количества операций
sa = (sw*2-0.5)/(sh-0.25)

    Второй шаг: скорректировать разрешение графической карты под соотношение сторон экрана

     

    Теперь требуется получить максимально доступное разрешение GPU и соответствующее ему соотношение сторон: 

    -- максимально возможное разрешение графической карты в символах
gw, gh = gpu.maxResolution()
-- соотношение сторон при максимальном разрешении в символах
ga = gw/gh
-- формулы, полученные из предыдущей, и которые пригодятся чуть позже
gw = gh*ga
gh = gw/ga

    Для определения дальнейших действий следует вспомнить о физическом смысле соотношения сторон. Исходя из приведённых выше формул, sa и ga можно назвать коэффициентами горизонтальности. Сравнивая их, можно определить, что по горизонтали более вытянуто разрешение либо видеокарты, либо монитора. Понятно, что если монитор имеет больший коэффициент горизонтальности, то для приведения к нему коэффициента горизонтальности видеокарты следует уменьшить её разрешение по вертикали. В ином случае следует уменьшать разрешение GPU по горизонтали: 

    -- код в понятной форме, использованы формулы из предыдущего фрагмента
if sa>ga then -- недостаточная горизонтальность GPU
  ga=sa -- привести горизонтальность в соответствии с экраном
  gh = gw/ga -- за счёт уменьшения высоты
else -- избыточная горизонтальность GPU
  ga=sa -- привести горизонтальность в соответствии с экраном
  gw = gh*ga -- за счёт уменьшения ширины
end
-- код после сокращения лишних операций
if sa > gw/gh then
  gh = gw/sa
else
  gw = gh*sa
end

    Третий шаг: скорректировать разрешение графической карты под нужны программы

     

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

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

local component = require"component"
local gpu, screen = component.gpu, component.screen

function set_proportional_resolution( scale )
  -- коррекция допустимых пределов масштаба
  if not scale or scale > 1 then
    scale = 1
  elseif scale < 0.1 then
    scale = 0.1
  end
  -- соотношение сторон монитора в символах:
  local sw,sh = screen.getAspectRatio()
  local sa = (sw*2-0.5)/(sh-0.25)
  -- запрос и коррекция максимального разрешения GPU
  local gw, gh = gpu.maxResolution()
  if sa > gw/gh then
    gh = gw/sa
  else
    gw = gh*sa
  end
  -- установка нового разрешения GPU с учётом заданного масштаба
  gpu.setResolution( math.floor(gw*scale), math.floor(gh*scale) )
end

-- тест работоспособности на нескольких вариантах масштаба
-- в процессе можно видеть, что на некоторых масштабах чёрные полосы имеют больший размер, чем на других
local w,h
local unicode = require"unicode"

for i=0.1, 1, 0.1 do
  set_proportional_resolution(i)
  w,h = gpu.getResolution()
  gpu.fill(1,1,w,h, unicode.char(0x2592))
  os.sleep(2)
end

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

     

    Полное исключение чёрных полос

     

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

     

    Пример №1:

    Монитор максимального допустимого размера 8x6; GPU Tier3 обеспечивает максимальное разрешение 160x50.

    Условное разрешение монитора в целых символах:

    sw = 8*8-2 = 62

    sh = 6*4-1 = 23

    Допустимые разрешения GPU, которые обеспечат отсутствие полос: 62x23 и 124x46.

     

    Пример №2:

    Монитор 6x5; GPU Tier1 обеспечивает максимальное разрешение 50x16.

    Условное разрешение монитора в целых символах:

    sw = 6*8-2 = 46

    sh = 5*4-1 = 19

    Нет разрешений GPU, обеспечивающих полное отсутствие полос.

     

    Пример №3:

    Монитор 5x5; GPU Tier1 обеспечивает максимальное разрешение 50x16.

    Условное разрешение монитора в целых символах:

    sw = 5*8-2 = 38

    sh = 5*4-1 = 19

    Разрешения GPU 50x16 недостаточно для размещения поля символов 38x19. Но если присмотреться внимательно, и вспомнить, что нам важно соотношение, то поле символов можно сократить до 2x1, избавившись от общего делителя 19. В этом случае допустимых разрешений GPU предостаточно, начиная от 2x1 и заканчивая 32x16. Во всех этих случаях пустых чёрных полос на мониторе не будет.

     

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

     

     

    Вот, и вся магия. То, что выглядит сложным, не всегда является таковым на самом деле.

     

    Upd: Дополняющий гайд от @ECS:

    https://computercraft.ru/topic/2501-kak-ubrat-chyornye-polosy-po-krayam-ekrana-v30/

    • Нравится 8

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

    а вот это вообще просто выше небес. шыдевр. места больше, чем в моем городе чистого воздуха.

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

  16. Опубликовано: · Изменено пользователем eu_tomat

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

     

    Пруф: http://www.lua.org/manual/5.2/manual.html#3.4.9

     

    Записи вида f'string', f"string" и f[[string]] эквивалентны f('string').

    Аналогично и для конструкторов таблиц: f{fields} эквивалентно f({fields})

    • Нравится 3

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

    Мой вариант не работал, потому что я ошибся. Надо было так q = tonumber(io.read())

    Без скобок в tonumber передавался адрес функции io.read, а не результат её работы.

     

    А твой вариант не работал, потому что io.read() возвращает строку, а не число. Зато tonumber выполняет преобразование строки в число.

    • Нравится 3

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

    Переходить на другой форум нет смысла, ибо гемора много, выхлопа мало.. Проще обновить текущий и допилить под себя (как было с этим). Начинать на новом форуме тоже не вариант т.к. нас читают, но не регаются, да и опять, это все таки многолетний труд всех тут и просто по сути его просто выкинуть... не знаю как вы, а я так не могу

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

     

    Предпочту обновление движка, а не перенос выбранных тем на новый. Если беспокоит обилие малосодержательных тем, то отдельные (редкие) темы можно и удалить, какие-то основательно почистить, а на самые полезные сделать ссылки из тем-каталогов. Это позволит и ребёнка вместе с грязной водой не выплеснуть и доступность наиболее полезной информации повысить.

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

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

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

     

    А как смотрите на вариант (по сути вернуться как раньше было) что-то вроде сайт + форум? На сайте всякие новости, обзоры программ и прочее, а на форуме уже саппорт и прочее.

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

     

    Возможно, имеет смысл вернутсья к своей вики. Я в сомнениях.

     

    А ещё помните, у нас бы раздел "статьи", который ушёл в "гайды" форума? В чём преимущество обратного разворота?

    • Нравится 1

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

    Ты просто очень серьезно  подошел к этому моду, и пытаешься его оценить с научной точки зрения)))

    Каждый на этом форуме серьёзен по-своему: кто-то не может играть без магии, кому-то нравятся электрические машины, кому-то рельсы и паравозы, кто-то хочет "ещё один" новый мод в сборку, кто-то под лупой рассматривает новые механики, а кто-то во главу угла ставит стабильность сборки. И, как общий знаменатель, всем нам в той или иной степени нравится Майнкрафт и компы. Разве это не прекрасно?

     

    Я смотрю на любые моды сквозь призму компьютеризации. Кому-то компы интересны и сами по себе, но без игровых механик на этих компах останется только мини-игры писать, да информационные панели. Игровые механики, сопряжённые с компами – это топливо нашего форума.

     

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

     

    В чем крутость этого мода, ума не приложу.

    Собрать в Майнкрафте летающую табуретку на реактивной тяге и компьюетром стабилизировть её полёт будет весьма увлекательной задачей, как по мне. Конечно же, если к моменту безглючной работы этого модика со мной не приключится та же история:

    с ужасом начинаю понимать, что уже давно перевалил за границу возраста в 5-13 лет и уже совершенно не важно, есть ли там компы или нет, для "раскрытия" интереса к валькирии варфайр

    • Нравится 1

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

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

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

    i,i1,i2=0,номер_начальной_строки,номер_конечной_строки for k,v in pairs(таблица)do i=i+1 if i>=i1 and i<=i2 then print(k,v)end end

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

    Я имел ввиду обычный сундук, а адаптер я ставил к мэ терминалу.

    =component.aemultipart.getAvailableItems()

    К терминалу? Может, что-то изменилось, но раньше доступ можно было получить через МЭ-интерфейс component.me_interface.

     

    И еще, я там внизу темы попросил привести пару примеров кода с парой слов объяснений, как юзать API в самой проге, а не интерпретаторе. Или может где то тема об этом есть более менее понятная? Потому что, как в интерпретаторе вывести на экран что-то, мне парень рассказал, а вот уже как использовать это в программе, я не могу понять как.

    Пример кода есть по указанной выше ссылке на блог @Fingercomp. Нужные строки легко находятся в программе.

    Объяснение можно увидеть, например, здесь http://computercraft.ru/topic/1319-pomosch-po-komponentu-me-upgrade-me-upgrade-iz-moda-extracells2/?p=19086

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

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

    Таблицы на маленьком экране робота я чаще всего отображаю кусками

    i,i1,i2=0,5,10 for k,v in pairs(t)do i=i+1 if i>=i1 and i<=i2 then print(k,v)end end
    Иногда целиком вывожу в файл. Бывает, добавляю ожидание нажатия клавиши между выводом строк таблицы. Тут каждый делает, как привычно, или как удобнее по ситуации.

     

    Как посмотреть все вещи которые есть в мэ? С сундуком работает

    С сундуком и не будет работать. В сундуке может лежать только ячейка памяти. А читать содержимое сети нужно ченрез МЭ-интерфейс, @Fingercomp рассказывал про это:

    http://computercraft.ru/blog/3/entry-412-avtokraft-opencomputers/

     

    Если попробовать сунуть это в переменную и распечатать ее, то вижу это

    Да, это нормально. Есть таблица, но она пустая.
×
×
  • Создать...