eu_tomat

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

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

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

Хорошая идея, newbie. Предлагаю дать игроку робота с самого начала игры, чтобы автоматизировать можно было бы всё от начала и до конца. Или выдать компоненты, как предлагает Quant. Увеличение задержек для роботов защитит от лагов лишь в начале развития, т.к. увеличенные в 10 раз задержки легко компенсируются 10-кратным увеличением числа роботов. Насколько я понимаю, Ex Nihilo может обеспечить экспоненциальное развитие, и сдержать его можно либо уменьшением доступного игроку пространства, либо отключением крафта, например, процессоров, и их выдачей за выполнение квестов. Идеально было бы придумать квесты с большим количеством повторяющихся, но разнообразных действий, чтобы игра не превращалась в кликер, а игрок чувствовал облегчение от использования роботов. AFK за счет роботов – наше всё.

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

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

А куда пропала тема Рубикон 1.0 (Операция "Торнадо")? В ней Alex популярно объяснил необходимость в усложнении крафта компьютеров и роботов, а также разъяснял, как это нововведение соотносится с названием проекта. Надо бы восстановить ту тему, чтобы отсылать к ней всех вопрошающих. Тем более, крафт роботов через кастомные руды – куда меньшее зло, чем крафт через магическую инфузилку.

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

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

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

Система координат является условностью, а переход из одной прямоугольной системы в другую легко преодолевается перестановкой и инвертированием аргументов: azimuth=math.deg(math.atan2(x,-z))%360 Спор же о правильных координатах не имеет большого смысла, т.к. в реальности всё относительно. Есть традиции, помогающие сделать более понятными учебники. На практике же приходится приспосабливаться к другим координатным системам, как, например, в Майнкрафте.

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

Зачем нужен чатбокс, когда есть замечательные очки, через которые мало того, что можно посылать команды, так еще и прямо в них отображать всю схему расположения турелей и секторов обстрела? Так сообщение в чат и сейчас можно послать. Но предупредительный выстрел в голову донесет мысль о надвигающейся опасности куда лучше чата. Сбалансировано или не сбалансировано – это всего лишь вопрос количества. Квантовик один, а на один сервер OpenComputers можно повесить полсотни турелей. Про быстродействие такой системы не скажу, это будет зависеть от физического сервера и его настроек, надо проверять в каждом конкретном случае. Буду предполагать, что скорость цели ты вычислил, и даже смог определить скорость пули. Есть два варианта: либо турели стреляют залпом, либо время выстрела каждой из них переменно. У каждого способа свои особенности. Не буду в них вдаваться, сосредоточусь на вычислениях. Если турели могут стрелять асинхронно, достаточно произвести выстрел чуть раньше. Время можно получить исходя из скорости пули и расстояния до точки поражения цели. Вычисления элементарны. При залповой стрельбе требуется корректировать точку наведения. Узнать ее координаты можно, например, так: Есть неизвестное время с момента выстрела до попадания в цель. Через него, а также через координаты цели в момент выстрела и ее скорость можно определить координаты в точке поражения цели. Через координаты можно выразить расстояние до этой точки, которое также можно выразить через время и скорость пули. Получится квадратное уравнение, решением которого будет время между выстрелом и поражением цели. Из времени вычисляются координаты, а из них углы и время поворота турели, оценка которого позволит наводить на цель лишь те турели, которые успевают за ее движением. Во избежание ситуации, когда ни одна из турелей системы не успевает за целью, следует аккуратно задать сектора обстрела каждой турели и запретить выход турелей за их пределы. Не вижу заметных преимеществ. К тому же задача решается имеющимися средствами. Абсолютные координаты легко вычисляются из относительных, а в системе турелей они вообще не нужны. Ошибка сенсора из OpenPeripheral легко скрывается с помощью pcall. Один адаптер на один сенсор – некритичное усложнение системы. Upd: Все-таки расскажу о тонкостях ведения огня. Залповый огонь реализуется проще. Достаточно выбрать время цикла с запасом, чтобы успели выполниться необходимые вычисления. Синхронизация цикла не представляет сложностей. Беглый огонь эффективнее залпового. Во-первых, он позволит каждому из орудий стрелять сразу, как оно будет готово, не дожидаясь момента залпа. Во-вторых, можно будет прогнозировать время выстрела турели задолго до входа бегущей цели в сектор данной турели. В-третьих, отсутствие общего ритма стрельбы не позволит игроку подстраиваться под него. С другой стороны, главный цикл при беглой стрельбе имеет непостоянное время выполнения, прогнозируемое лишь в некоторых пределах, что усложняет алгоритм, приоритетной задачей которого будет совершение выстрела в удобное для каждой из турелей время, а вычисления придется распределять между выстрелами. Задача в общем решаема, но с алгоритма залпового огня проще начать.

Первым делом следует определиться с задачей, которую будет выполнять система турелей. * Будут ли целью турелей случайно заспавнишиеся или укрывающиеся от солнца мобы, либо игроки, одетые в квант? * Как быстро квантовик должен убиваться, оставаясь в охраняемой зоне?. * Какой объект охраняется: площадь с равномерно расставленными на ней турелями, или замкнутая комната или коридор с турелями по периметру? Вторая задача решается существенно легче, а в первой сложнее найти оптимальный алгоритм распределения секторов обстрела для имеющихся турелей. Об «интересных» кусках кода: * Запрещать выстрел турели, если на пути стоит мирный моб или игрок из белого списка, можно, но тут имеются другие сложности. Между выстрелом турели и попаданием в цель проходит время, за которое успевает сместиться и цель и защищаемый игрок. Защищаемый всегда рискует попасть под огонь если не одной, так другой турели. Поэтому лучшим решением для защищаемого будет как можно скорее убраться с защищаемой территории. * Если всё же использовать фильтр, защищающих «своих» от обстрела, то он должен идти первым, чтобы турель смогла переориентироваться на другую ближайшую к текущему прицелу цель. Можно, конечно, продолжать удерживать прицел на изначальной цели, и ждать, пока мирный игрок покинет линию огня, но будет проще отдать недоступную в данный момент цель другим турелям, а эта тем временем может стрелять в других мобов, находящихся в ее секторе. * Можно было бы определять характер движений защищаемого игрока. Пока он стоит в AFK – исключать из обстрела линии, проходящие через его координаты, а как только он начнет движение – стрелять без разбора в надежде, что защищаемый бежит в укрытие. Вепрочем, для AFK'шника лучшим решением будет провалиться в подземный бункер – сохраннее будет. Что-то из моих давних соображений: * Для эффективного уничтожения целей следует стрелять на упреждение, учитывая как скорость цели, так и скорость «пули». Также не следует забывать об ограниченной скорости поворота турели и о кулдауне. То есть, турель должна заранее повернуться на нужные координаты и в нужный момент произвести выстрел. * Зная об упреждающем алгоритме, квантовик будет вынужден двигаться неравномерно, зигзагами, замедляясь и ускоряясь. В таком случае эффективной окажется стрельба наугад, но так, чтобы простреливалось всё пространство вокруг цели, не давая врагу возможности стоять на месте. Тут потребуется алгоритм, который производит обстрел, равномерный как по времени, так и по защищаемому объему, но при этом максимально сосредоточенный вокруг цели. * Можно комбинировать оба алгоритма, когда часть турелей деморализует квантовика случайным огнем, а другая – выцеливает его, если тот случайно сумел найти безопасный островок. * По возможности турели должны вести согласованный огонь, и целиться не в просто ближайшего в своем секторе моба, а в первую очередь добивать наиболее слабых, пока те не успели восстановить свое здоровье. Практическое применение турелей и вправду не впечатляет, на задачки получаются интересные, и разнообразных уровней сложности. Я бы начал с коридора, в котором игрок убегает от моба. А когда турели научаться эффективно выцеливать бегущего моба, при этом не раня игрока, можно попробовать научить их истреблять сразу нескольких мобов в комнате, опять же, щадя игрока. И только тогда уже можно будет подумать об унижении квантовиков.

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

Это не ко мне вопрос. У меня в майне никогда ничего не горело за пределами обогатителя урана. Тут вопрос был, как не тушить поставленный игроком верстак. Поэтому вышел из комнаты – тушат роботы, а как вошел – сам туши. Тушка тушит – вообще хорошо. Правда, придется научить робота обходить препятствия и выбираться из тупиков – то, что надо для освоения алгоритмов.

Здравый смысл говорит, что сначала нужно сделать так, чтобы помещение не горело. То есть, следует строить огнеопасное помещение из негорючих материалов. А если негорючие материалы по каким-то причинам неуместны, то можно сделать дом из отсеков, разделенных водой. Если же очень хочется использовать OC, то для этого всё имеется: геосканер или сенсор из OpenPeripheral отслеживает объем комнаты, а в случае изменений при отсутствии хозяина будит висящего под потолком робота, передает ему координаты, тот перемещается в нужную позицию и поливает опасное место из ведра.

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

Заинтересовал скриншот с именующими прессами в продаже. Они уже продаются поименованными, или можно как-то позже задать нужное имя?

А зачем нужна отдельная функция для получения строки конфига? При этом еще и конфиг зачем-то три раза перечитывается. Есть же более простое решение, записываемое короче и работающее быстрее: ls = io.lines(fpath) username, workspace, path = ls(),ls(),ls()

Во всём устаревшие словари виноваты. Это они путают людей. Нужен новый словарь, без этих дурацких приставок.

По правилам русского языка цветовое оформление не оказывает влияния на смысл слов. Парадокса нет, и ответ очевиден. Приведенное в пример высказывание вообще записано с нарушением правил русского языка. Нарушая же правила, можно легко доказать, что 2x2=5. А если быть точным, то не доказать, а немного удивить неграмотных.

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

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

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