man_cubus

Неожиданно Это небось всякие оптимизации под SSE влияют

Отличная идея, годится

Что нужно: промаркировать каким-то образом несколько голографических излучателей чтобы операционка их распознавала не только по uuid для чего нужно: выстроить несколько голографических излучателей в структуру чтобы ими можно было пользоваться как единой матрицей голографических излучателей Вопрос: как пометить компоненты чтобы распознавать их место в матрице автоматически при подключении? Еще до того как операционка впервые увидит uuid компонента

Я не нашел, но могу набросать приблизительный план: вот тут есть пример регистрации события установки блока в мир и формирования списка блоков, которые его не триггерят. вот тут похоже, но с использованием forge Дальше по этому вот гайду сохраняем игрока и поставленный блок (если блок прошел по условиям как механизм) в глобальное хранилище По таймеру на сервере проверяем очередного игрока: не накоплена ли "критическая масса блоков" А дальше если таки накоплена, даём волю своей извращённой фантазии Хошь спамь игроку в гуи "заплати копеечку на сервер и ставь себе больше механизмов", хошь регистрируй ему запрет эти механизмы ставить чтобы новые механизмы выпадали под ноги вместо установки в мир, хошь взрывай с рандомным шансом один из уже установленных блоков

Есть разница. Ты, как я погляжу, за уравниловку. В духе "все одинаково хотят играть" и эта предпосылка - некорректная. Есть те, кто сидит на сервере сутками, а есть южуал кэжуал фар фром хардкоре. Мне видится не совсем справедливым оценивать их желание играть на сервере одинаково. И считать что у каждого из них равные права на процессорное время сервера Маньяки - это по-моему хорошо.

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

С вашего позволения встряну: Насчет бага с материальной пушкой скорее согласен с Алексом: баги надо чинить. Насчет усложнения рецептов в духе "как бы лагов не вышло" согласен с Томатом, потому что это дорога вникуда, вернее в ванильку, в которой программирование возможно максимум на редстоуно-ассемблере после крафта безумно гигантского вычислителя на ванильных механиках. Ограничение на число машин по игроку и чанку - неприятная мера, но необходимая на густонаселенных серверах. Атомик вряд ли можно к таким отнести. Так что я не против лагов от одного-двух маньяков, одержимых установкой десятка реакторов на базе. Но считаю справедливым чтобы при взрыве реактора такие маньяки огребли бы сильнее не-маньяков. К примеру если в чанке два реактора, то разрушения от взрыва будут в квадрате, если три - в кубе. Или какой-то другой вариант экспоненты. И радиационное заражение на n*2 дней реального времени, где n - число реакторов, такое, чтоб и хазмат не спасал То же самое можно организовать со взрывом механизмов от неправильного вольтажа: чем больше механизмов на одном проводе тем сильнее рванёт. Таким образом те кто больше всего лагов вызовет сильнее рискует.

Я ж написал что это предположение, гипотеза. Написал как её проверить. Причём тут номер версии чего бы то ни было? Например вот тут есть неявное предположение о том, что в секунде 20 игровых тиков. Для нагруженного сервера это не совсем верно и при старте может вызвать как минимум отставание аптайма. А если еще и entityPlayer.getEntityWorld.getTotalWorldTime обнуляется для сервера целиком, то аптайм уйдёт далеко назад от последнего таймстампа. Еще раз: я этого не знаю, это только предположение которое можно проверить.

Предположение: При перезапуске сервера аптайм компьютера обнуляется, а переменная timestamp остается неизменной. Таким образом после перезапуска (computer.uptime() - timestamp > TimeOut) and (TimeOut > 0) всегда будет ложным и ShowMenu() на с167 строке не выполнится. Проверка: нужно проверять не ушло ли значение uptime назад.

Есть такая замечательная утилита: luacheck Я сам невнимательный в таких вот мелочах и она меня прям очень выручает. Рекомендую.

Да, но для однопоточной ОС без параллелизма может прокатить.

На самом деле кроме метатаблиц я хотел показать, что можно возвращать не выходные данные в ответ на входные, а функцию-обработчик. В итоге мы для каждого элемента сети тупо делаем knowns[item_stack.name]() и для тех предметов, которые мы определили, мы можем обрабатывать их или единообразно, выводя про них комментарий или неоднородно, в зависимости от типа. В итоге вместо 10 elseif будет 2-3 функции-обработчика, организованных в одну таблицу.

Действительно, тут нужна прокси таблица. Вот исправленная версия local prefix = "Я знаю, это " local function unknown() print("Об этом я не ничего знаю") end local descriptions = { ["minecraft:cobblestone"] = "опять чертова кобла", ["minecraft:planks"] = "доски", ["minecraft:tnt"] = "кубик веселья", ["minecraft:log"] = "бревно, как моя бывшая" } local indexer = { __index = function(self, key) local value = descriptions[key] if value then return function() print(prefix .. value) end else return unknown end end } local knowns = {} setmetatable(knowns, indexer) local me_controller = require("component").me_controller for _, item_stack in pairs( me_controller.getItemsInNetwork() ) do print(item_stack.label, " = ", item_stack.size) knowns[item_stack.name]() end

Неправда t = {1,2,3,4} mt = {__index=function(self, key) v=rawget(self,key) if v then return v else return "shit!" end end } setmetatable(t,mt) for i=1,6 do print(t[i]) end

Я не тестировал. Каковы сомнения?

Вот тебе еще один способ сравнения: local prefix = "Я знаю, это " local function unknown() print("Об этом я не ничего знаю") end local indexer = { __index = function(self, key) local value = rawget(self, key) if value then return function() print(prefix .. value) end else return unknown end end } local knowns = { ["minecraft:cobblestone"] = "опять чертова кобла", ["minecraft:planks"] = "доски", ["minecraft:tnt"] = "кубик веселья", ["minecraft:log"] = "бревно, как моя бывшая" } setmetatable(knowns, indexer) local me_controller = require("component").me_controller for _, item_stack in pairs( me_controller.getItemsInNetwork() ) do print(item_stack.label, " = ", item_stack.size) knowns[item_stack.name]() end Для того чтоб посмотреть как оно работает, надо подключиться к контроллеру МЭ-сети адаптером.

Это прекрасно! Пожалуйста добавьте репку в hpm

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

Ну то есть не получится. Потому что в совокупности эти твои модули - это и есть твоя графическая оболочка. А вкупе с прикладным софтом и есть МайнОС. И если, предположим, меня не устраивает предпосылка о необходимости в богатой графике и её следствие - требовательность к ресурсам, то объектный интерфейс отдельно, без графики, мне не получить. И действительно, ну надо же. И по моему примитивному критерию тоже можно. И я это сделал. О как, "вас заметили" О том называть ли технически не-ось осью, разве нет? Предпосылка тем и отличается от прямого утверждения что она явно не выказывается, но предполагается. Как предполагается графический десктоп с тремя риложениями и нужность именно такого варианта. А двойная буферизация и размеры кодовой базы - следствие предпосылке об именно таком подходе к интерфейсу. Да, но тут не атмега. Тут одна и та же аппаратная часть. И есть случаи когда для одной и той же ситуации невозможно применить именно твоё решение. Для таких ситуаций оно непригодно. И не потому что оно имеет особые требования а потому что оно не настолько универсально. Нет чего-то вроде minimal setup. И изначальной предпосылкой такой вариант вообще не предусмотрен. То, что ты её, преальфу, неопубликованную, всерьёз сравниваешь пусть и с элементарной, но надёжной и работающей на всём оборудовании системой. Для того чтобы даже по такому переоцененному (но всё ещё валидному) критерию иметь полноценную ОС. Например. Но, вероятно, перелопатить тонну кода для удовоетворения этому критерию сложнее чем сказать "зелен виноград". То же насчет минимальной установки без графических изысков. Пример прочёл. Да, такой способ лучше. Если использование объектного UI предполагает еще и графические либы и вот такие требования к памяти то не всегда это дело субъективное. Я сказал "почти стандартная". Не уловил, да?

Технически правильно всё же не не называть MineOS полноценной ОС. Что на мой взгляд неправильно, так это не объявлять свои личные нервы чем-то представляющим безусловную ценность и принимать критику чуть спокойнее. Кроме того разумеется фраза не является переходом на личности, но токсичной - да, является. И мои фразы тоже примерно такие же. Где например прямой переход на личности у меня? Вряд ли ты его найдёшь. Но я веду себя недружелюбно - факт. При том что он -матёрый человечище и написал отличную графическую подсистему. Да, вот такой вот я. Ты удивлён?

Тем не менее твоя ОС с её более лучшими модулями на минимальной конфе не запустится. Потому и сравниваю. Я ведь не смогу запустить более лучшие модули отдельно, правда? Самоцитата: [сравнивать] точно нельзя. Потому что они ориентируются на разные вещи и исповедуют разные подходы Ну ты же откуда-то взял что ОС - это непременно богатая графика, верно? воды нет. Населена роботами. Вот и я не удивляюсь. Это если мне непременно нужен оконный десктоп с параллельно выполняющимися тремя приложениями. В однопоточной системе. Как и ты. Но свой критерий сравнения я уже приводил. Удобную для кого? Я ж не исхожу из предпосылки, что могучая графика непременно нужна в однопоточной ОС. Для простейшего фонового сервиса не нужен гуй. И их у меня довольно много в репе. И все под rc. Что например в МайнОС есть вместо rc? А меня ломает пилить ненужный мне гуй. Всё понятно. Но тогда как же ты тогда сам сравниваешь готовый продукт под названием OpenOS и твой законсервированный до лучших дней набросок, говоря, что на этот набросок тебе понадобилось намного меньше времени? Ты не видишь тут небольшое противоречие? Чудесно. Если б еще графическая часть не была непременно обязательно запускаемой - было бы идеально. Майкрософт со своим Windows Server 2018 Core тоже к этому пришла. На пару десятков лет позже юниксоподобных ОС. Эти ограничения и называются "вежливость" Если повезет Да, всё верно, ведь ты никогда не ошибаешься. Да, потому что если ты его не публикуешь и не афишируешь, то при сравнении с чем-то готовым получишь ожидаемую реакцию в этом вот ключе. Потому что а давай пофантазируем чего бы достигла, скажем, BeOS, если бы... да что угодно. Ведь её сравнивать с тогдашней виндой и линуксом вполне можно как готовые продукты. В отличии от MineOS standalone, которая даже готовой не является, давай? Ощущаешь где именно всё идёт не по плану? Как я сделаю копипаст внутри своего приложения? Кусок кода для консольного исполнения я для OpenOS привёл. Может приведешь как то же самое делается через особенный, более совершенный механизм в MineOS standalone? Так же? Или как в каком-нибудь win32 API с обязательным указанием хендла на окно приложения? Не вкусовщина на самом деле. Ах да, я забыл что оно "сокрытый от человечества набросок" и сравнивать низзя. Но тебе ведь это не помешало его приплести, верно? Вообще, системное программирование, а речь именно о нём если ты сейчас не понял, на винде до выхода такой вещи как PowerShell был тем еще геморроем. И Майки выпустили достаточно приличный консольный инструмент. Которому всё же не хватает простоты того же bash. Аналогия понятна? Не совсем. Я могу и практически стандартную io задействовать. Но зачем?

Допустим. Точно нельзя. Потому что они ориентируются на разные вещи и исповедуют разные подходы. А сведения и вправду из-за одинаковости названий, тут я действительно ошибаюсь и возвожу тут напраслину. Тем не менее, модули из опенос работают на компе первого тира с единственной минимальной планкой памяти и графической карточкой первого тира. Можно ли это сказать о майноси? Очень сомневаюсь. Ну, тут сложно сказать. Утилита cp - это прикладное ПО? Да. Можно ли без неё и остального элементарного ПО нормально работать с ОпеноОС? Нет. Так что грань несколько размыта. Вон, недавно видел реализацию архитектуры с микропитоном всместо Луа, и что? Мне очень нравится идея использования питона, но она ж бесполезна без скелета из прикладного ПО с единственным интерпретатором, который запускается после загрузки. Окей. Но я сравниваю ОпенОС с МайнОС в том числе и по наличию таких скриптов. Хотя основной критерий лично для меня вообще примитивен донельзя: насколько легко написать под %ОСнейм% программу для %действиенейм% осложнённую %наборфакторовнейм%? В случае с ОпенОС ответ - "довольно просто". В случае с МайнОС в в non-standalone виде бует "точно сложнее". Просто потому что МайнОС сама съедает немало системных ресурсов и на робота первого уровня её не поставить, к примеру. А в standalone режиме - вообще непонятно куда копать и как оценить сложность, ибо пререлиз и альфа. Зато кнопочки и обои. Но каждому своё как я уже говорил. Шикарно. И документацию тоже ко всему этому? Потому что вон Фингер тоже свой wonderful написал, а как им пользоваться простому говнокодеру вроде меня непонятно. Хотя в отличии от твоего творения у него доки почитать таки завезли. Опыт личной переписки в вк. Ты действительно хочешь чтобы я принёс это сюда? Или слова "ИМХО" для тебя недостаточно и ты решил что раз ты такой замечательный, то всем без разбора нравишься? У меня для тебя плохие новости в этом плане. Для меня лично заявление о трудозатратах - подтасовка фактов. Потому что помимо реализации низкоуровнего апи для работы с объектами ОС есть еще то самое базовое прикладное ПО, написание документации для всего этого. И этого ты не делал для МайнОС-standalone И таки базовое ПО по моему мнению является составной частью ОС просто потому что мне куда проще сделать os.execute(string.format("cp %s %s"), src_file, dst_file)) чем городить огород с самостоятельным вводом-выводом и буферизацией всей это фигни.

Здесь мерилом работы считают усталость. © Но даже если так, то первый релиз опенкомпов был согласно гитхабу 26-02-2015. И что, вот прям с первого же релиза вы с группой товарищей начали пилить вашу МайнОС? Или даже раньше первого релиза, телепатически предугадав выход опенкомпов? Сомнительно. Также сомнительно что можно поставить знак равенства между трудозатратами преобразованиея MineOS в MineOS standalone (с готовыми модулями из опеноси) и написанием OpenOS с нуля. А с нервами у тебя вообще не всё хорошо. Имхо. Я ничуть не пытаюсь обесценить твою замечательную систему. Графическая составляющая, документация, возможности - всё куда лучше чем у любых мыслимых конкурентов (которых что-то вот вообще даже припомнить сходу не выходит). Но не надо передергивать факты, а тем более драматизировать и давить на жалость. Опенось и опенкомпы целиком - сложнее и универсальнее чем майнось, хотя по удобству использования оставляют желать много лучшего. С другой стороны удобство использования и любой вау-эффект никогда не были целью автора опенкомпов. Каждому - своё. И лично мне Майнось пока не пригодилась.

Добавлю мою любимую схему начального реактора без камер на 9 стержней с эффективностью 3,33 и выходом в 100 Еу/тик

Фидбек