eu_tomat

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

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

Радует, что разговоры о смене движка перетекли в обсуждение дизайна. Выскажу свои соображения. Дискуссия о медальках поднимается не первый раз. Главная претензия к ним в том, что они занимают много места. Звучали идеи убрать медали совсем, а также использовать орденские планки. Награды не играют большой роли для старожилов, они и так знают достижения друг друга без дополнительных знаков. Зато награды могут мотивировать новичков к позитивной деятельности. Мотивация слабая, но и затраты на неё мизерные. Кроме того, награды помогают случайным посетителям хотя бы примерно оценить компетенцию авторов и, соответственно, достоверность информации. А это облегчает им вхождение в тему и способствует желанию участвовать в обсуждениях. То есть, награды в целом полезны. В идеале хорошо было бы разработать дизайн медальных лент и размещать их все на одной узкой планке, а значки самих медалей демонстрировать либо во всплывающем окне, либо в div'е, по умолчанию скрытом, и отображающемся при наведении указателя мыши. Ну, и например, сама надпись "награды" только занимает место. И так понятно, что эти значки на экране являются наградами. А при наведении курсора мыши развеиваются последние сомнения. Значки принадлежности к группе мне тоже кажутся ненужными. Текстовая подпись более чем информативна.

Для желающих понять, на какой магии работает эта библиотека, я написал гайд: 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/

На днях в чате прозвучал вопрос, как убрать чёрные полосы по краям экрана. На форуме есть замечательная библиотека от @ECS, которая хорошо решает поставленную задачу: http://computercraft.ru/topic/1130-avtomaticheskii-mssahtab-monitora-izbavliaemsia/ Но есть два нюанса: 1) Код библиотеки явно избыточен. 2) При чтении кода библиотеки создаётся впечатление, что она работает на неведомой магии тёмных сил, что демотивирует новичков, изучающих OpenComputers. Я намерен восполнить данный недостаток. Прочтение этого гайда поможет любому желающему написать кусочек кода под нужды конкретной программы, не подтягивая библиотечный код. Благодарю @Totoro за предоставленную информацию: 1) Текстура блока имеет размер 16 px, а ширина рамки монитора – 2 px; 2) Высота символа на экране в два раза больше его ширины. Данной информации достаточно для получения всех необходимых формул. Приступим: Первый шаг: получить соотношение сторон экрана, выраженное в символах В мире Майнкрафта текстура блока имеет размер в 16 пикселей. На рамку с каждой стороны тратится по 2 пикселя независимо от размера монитора. Очевидно, что размер монитора в пикселях кратен 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/

Только не пойму: это развитие или регресс?

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

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

Прекрасно работает. 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})

Мой вариант не работал, потому что я ошибся. Надо было так q = tonumber(io.read()) Без скобок в tonumber передавался адрес функции io.read, а не результат её работы. А твой вариант не работал, потому что io.read() возвращает строку, а не число. Зато tonumber выполняет преобразование строки в число.

Должно помочь q = tonumber(io.read)

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

read("*a") является допустимым сокращением от read("*all") и значит "прочитать весь файл целиком". Подробности: http://www.lua.org/pil/21.1.html

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

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

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

К терминалу? Может, что-то изменилось, но раньше доступ можно было получить через МЭ-интерфейс component.me_interface. Пример кода есть по указанной выше ссылке на блог @Fingercomp. Нужные строки легко находятся в программе. Объяснение можно увидеть, например, здесь http://computercraft.ru/topic/1319-pomosch-po-komponentu-me-upgrade-me-upgrade-iz-moda-extracells2/?p=19086

Таблицы на маленьком экране робота я чаще всего отображаю кусками 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/ Да, это нормально. Есть таблица, но она пустая.

Круто то, что подобное вообще кому-то пришло в голову. Но с точки зрения геймплея крутости пока нет. У индустриальщиков есть джетпаки, у магов тоже какая-то летающая броня, дающая гораздо больше возможностей для манёвра, чем корабли. Сильные противники этот корабль разгриферят, а слабые спасутся под землёй. Если под крутостью подразумевать просто интересную механику, то интереса хватит максимум на пару вечеров. Да, в будущем компы могут сделать эти кораблики очень интересными, алгоритмически повышая манёвренность или устойчивость кораблей за счёт быстрой реакции при управлении каждым двигателем или группами двигателей. Но это в перспективе. Кроме того, не до конца понятно взаимодействие с миром. Во времена RedPower2 с кораблей можно было выпускать черепашек на добычу ресурсов и перерабатывать ресурсы прямо на борту. Потом был неплохой мод Redstone in Motion, сделавший кораблестроение даже более удобным. Сейчас вроде бы есть Remain in Motion, но я его не тестировал. Да, все эти моды позволяют строить только корабли, перемещающиеся исключительно вдоль кубической сетки. Физика скучная, но зато роботы без проблем загружаются на борт корабля и выгружаются. Valkyrien Warfare имеет физику на порядок более интересную, но без компов этот интерес не раскрыть. Иногда вспоминать про этот мод будет полезным. Так что, пусть пока полежит в копилочке.

@@Appo, я не уверен, что мой подход удобен для всех, но попробую описать его. Начну с того, что уже давно у меня появилась привычка не пользоваться встроенными редакторами сообщений. Это такой способ борьбы с глюками интернет-соединения, доступности сайтов и стабильности движков форума. Много раз случалось так, что длинный текст, набранный в форме сайта попросту пропадал, и его приходилось составлять заново. Встроенные в сайты редакторы я обычно использую для коротких сообщений в два десятка слов. Если мысль мне кажется сложной, всегда начинаю набор в обычном текстовом редакторе. Форматирую там же, теги расставляю руками. Благо, много их не требуется. Если форматирование сложное, использую LibreOffice Writer и форматирую текст в нём для оценки внешнего вида. А потом к выделенному каким-то стилем тексту вручную добавляю нужные теги и переношу в форму сайта как простой текст. Затем в форме редактирования или создания поста выбираю предпросмотр и перечитываю пост, оцениваю вид. Если обнаруживаются ошибки, исправляю в том же текстовом редакторе, снова вставляю текст в форму и выбираю предпросмотр. И так до полного удовлетворения статьёй. Соответственно, встроенный в форум редактор интересовал меня разве что с точки зрения демонстрации доступных в нём возможностей форматирования, не более того. Как по мне, картинки в этой теме не несут никакой информации. У нас же тема о кодинге? А картинки особенности кодинга в той или иной игре никак не проясняют. Поэтому место им под спойлером. Про минимизацию картинок масштабирвоание при наведении курсора или клике мне самому интересно узнать. Если картинки и создают какое-то первое впечатление, то на меня негативное из-за скроллинга. Не исключаю, что кому-то нравится. Не хочу об этом спорить. Тема для форума нетипичная, и каких-то типовых требований к таким статьям нет. Если говорить в общем, то большое разнообразие шрифтов, их стилей, размеров скорее порит внешний вид статьи, нежели улучшает его. Редактировать основное оформление я не буду. Я вообще не знаю, будет ли эта тема популярной и читаемой. Мне она кажется полезной, @@Fingercomp особого смыла не видит, а другие пока молчат. Пусть пока тема остаётся в текущем виде. Исправлю только самое начало, удалив нестандартные шрифты. Оно, конечно, будет диссонировать с дальнейшим текстом, но и не все захотят читать тему дальше.

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

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

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

Интуиция мне говорит, что площадь осевого сечения конуса можно использовать для оценки его объема. Но для подтвеждения этого надо всё-таки вывести формулу, желательно для случая проивзольного профиля осевого сечения. Для конуса формула выводится по тому же алгоритму, что и для цилиндра, но я пока не занимался этим вопросом. Меня сейчас больше занимает поиск решения для произвольного профиля. Если тебе интересен случай конуса, то посчитай сам, не ленись. Да, многие допускают эту ошибку. И чтобы расставить точки над Ё, приведу аналогию, понятную майнкрафтерам. Вот, есть у нас кубик. Он имеет объём одного куба и площадь в шесть квадратов. Возьмём ещё один кубик. Суммарно их объём составлит два куба, а площадь 12 квадратов. И если мы поставим эти кубики один на другой, то суммарный объём не изменится, зато площадь уменьшится на два квадрата. В принципе, эти два кубика можно было бы соединитдь любыми сторонами, площадь всегда уменьшится на два квадрата. Но пока оставим фигуру из двух поставленных друг на друга кубов. Возьмём ещё одну точно такую же фигуру из вертикально расположенных двух кубиков. Если мы поставим её на предыдущую так же вертикально, то снова их суммартный объем сохранится, а суммарная площадь уменьшится на два квадрата. Видно, что соотношение объема к поверхности улучшится. Но если эти две фигуры соединить не вертикально, как в прошлый раз, а присоединить по горизонтали, то суммарная площадь сможет уменьшиться не на два, а на четыре блока, что даст гораздо лучшее соотношение. В следующей итерации объединения фигур можно будет уменьшить суммарную площадь поверхности на 4 или на 8 блоков. Эффективность фируры при росте её объема возрастёт в любом случае, но максимума она достигнет только при соотношении сторон, приближающем форму готовой фигуры к кубической. Понятно, что мы не можем просто так склеить два цилиндра боковыми поверхностями, но аналогия сохраняется при выборе увеличить ли высоту цилиндра или его радиус. Как уже говорилось выше, оптимальное соотношение радиуса и высоты даёт квадрат в осевом сечении цилиндра.

В вопросах по Lua так и есть. Там могут быть конкретные вопросы и конкретные ответы. А здесь беседка, где важен не только ответ, но и сам процесс общения. И да и нет. Смотря как сечь фигуру. К примеру, в сечении цилиндра можно увидеть круг, который никак не покажет нам результаты оптимизации. Опытные математики знают правильное сечение, что упрощает им жизнь. Зато площадь поверхности фигуры является более универсальным мерилом, формулы усложняются, но возможность ошибки при аккуратном преобразовании формул исключена. Я до конца не уверен в том, что во всех случаях достаточно оперировать площадью фигуры. Но то, что площадь эквивалентна объёму при бесконечно малой его толщине, не должно вызывать сомнений. Наш пример: Находим полезный объём цилиндра, объём с добавлением толстых стенок, и объём самой стенки. Затем получаем площадь делением объёма стенки на её толщину и находим её предел при стремлении толщины к нулю. Как можно видеть, формула площади, полученная через предел от объёма стенки, полностью совпала с привычной формулой площади цилиндра.