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

man_cubus

Пользователи
  • Публикации

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

  • Посещение

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

    4

man_cubus стал победителем дня 27 марта 2019

man_cubus имел наиболее популярный контент!

Репутация

28 Обычный

1 подписчик

man_cubus

  • Звание
    Участник

Информация

  • Пол
    Мужчина
  • Город
    Kiev

Посетители профиля

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

    Оффтоп

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

    Оффтоп

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

    Оффтоп

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

    Оффтоп

    С вашего позволения встряну: Насчет бага с материальной пушкой скорее согласен с Алексом: баги надо чинить. Насчет усложнения рецептов в духе "как бы лагов не вышло" согласен с Томатом, потому что это дорога вникуда, вернее в ванильку, в которой программирование возможно максимум на редстоуно-ассемблере после крафта безумно гигантского вычислителя на ванильных механиках. Ограничение на число машин по игроку и чанку - неприятная мера, но необходимая на густонаселенных серверах. Атомик вряд ли можно к таким отнести. Так что я не против лагов от одного-двух маньяков, одержимых установкой десятка реакторов на базе. Но считаю справедливым чтобы при взрыве реактора такие маньяки огребли бы сильнее не-маньяков. К примеру если в чанке два реактора, то разрушения от взрыва будут в квадрате, если три - в кубе. Или какой-то другой вариант экспоненты. И радиационное заражение на n*2 дней реального времени, где n - число реакторов, такое, чтоб и хазмат не спасал То же самое можно организовать со взрывом механизмов от неправильного вольтажа: чем больше механизмов на одном проводе тем сильнее рванёт. Таким образом те кто больше всего лагов вызовет сильнее рискует.
  7. Я ж написал что это предположение, гипотеза. Написал как её проверить. Причём тут номер версии чего бы то ни было? Например вот тут есть неявное предположение о том, что в секунде 20 игровых тиков. Для нагруженного сервера это не совсем верно и при старте может вызвать как минимум отставание аптайма. А если еще и entityPlayer.getEntityWorld.getTotalWorldTime обнуляется для сервера целиком, то аптайм уйдёт далеко назад от последнего таймстампа. Еще раз: я этого не знаю, это только предположение которое можно проверить.
  8. Предположение: При перезапуске сервера аптайм компьютера обнуляется, а переменная timestamp остается неизменной. Таким образом после перезапуска (computer.uptime() - timestamp > TimeOut) and (TimeOut > 0) всегда будет ложным и ShowMenu() на с167 строке не выполнится. Проверка: нужно проверять не ушло ли значение uptime назад.
  9. Есть такая замечательная утилита: luacheck Я сам невнимательный в таких вот мелочах и она меня прям очень выручает. Рекомендую.
  10. Да, но для однопоточной ОС без параллелизма может прокатить.
  11. На самом деле кроме метатаблиц я хотел показать, что можно возвращать не выходные данные в ответ на входные, а функцию-обработчик. В итоге мы для каждого элемента сети тупо делаем knowns[item_stack.name]() и для тех предметов, которые мы определили, мы можем обрабатывать их или единообразно, выводя про них комментарий или неоднородно, в зависимости от типа. В итоге вместо 10 elseif будет 2-3 функции-обработчика, организованных в одну таблицу.
  12. Действительно, тут нужна прокси таблица. Вот исправленная версия 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
  13. Неправда 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
  14. Я не тестировал. Каковы сомнения?
×
×
  • Создать...