Doob

Я использую пропущенный через минификатор - слов меньше, получается 3951 байт.

Самый примитивный декомпрессор - 152 байта, но он не эффективен, т. к. работает в несколько проходов.

P.S. извиняюсь, невнимательно скопировал, декомпрессор занимает 305 байт.

Добавил еще одну заставку - простые пиксельные часы.

1. Подготовленный к сжатию Lua код не содержит табуляций и переносов. Тут я беспокоюсь о конечных пользователях, которые скопируют сжатый текст CTRL+C>CTRL+V и скажут "НИРАБОТАИТ11!". Для исходников хватит диапазона 20-7E (символы 09 0A можно перенести на 24 и 7F, соответственно. Можно даже использовать управляющие символы, но это уже расширенная версия алгоритма)

2. Все текстовые и вторая половина таблицы.

3. Изначально, я составил словарь используемых в Lua выражений и сжимал подготовленные тексты этим алгоритмом и универсальными, deflate догоняет этот алгоритм на исходных текстах более 1 КБ (но это зависит от типа кода, если в коде много вычислений - мало повторяющихся последовательностей, то deflate может и лучше, но он все-равно хуже из-за объема собственного исходного кода)

В шапке написано "ASCII", алгоритм придуман для сжатия именно ASCII текста, в частности, Lua кода. В исходом коде Lua используются только текстовые символы, алгоритм сжимает текст. Если надо сжимать какие-то данные - можно использовать универсальные алгоритмы, а этот алгоритм намного компактней универсальных, его можно использовать, чтобы писать программы для EEPROM в OC, если алгоритм раздуть, что он будет больше сжатого текста, то его функциональность пострадает из-за универсальности.

Кажется, это уже другой алгоритм. Я не использую управляющие символы, т. к. если они попадают в IO - закодированный текст повреждается, при тестировании я использовал такую схему:

слово1[FF]слово2[FF]слово3[FF]слово4[FF]тексттекст[80]тексттексттек[81]сттекст[82][83]тексттекст[84]
т. е. словарь отделен от текста символом [FF] и слова отделены друг от друга тем же символом (либо символом [FE], чтобы легче было отделять словарь)

Тут уже возникают вопросы стандартизации, если я не использую UTF8, то использую Windows-1251, а тут символ 255 - "я". К тому-же надо использовать два символа, например 254 и 255 для обозначения диапазона закодированного символа. Дополнительно, для отделения словаря от текста надо использовать еще один символ, например, 253. Либо выкидываем 3 последних символа алфавита, если попадается текст с кодировкой W1251, либо подбираем такие символы, которые не будем использовать в комментариях во всех популярных кодировках.

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

А опытным дяденькам и код не нужен, ибо он уже есть в их головах.

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

P. S. А во времена DOS комменты писались транслитом.

А как же кириллица?  Она же >127, или нет?

А какая польза от кириллицы в Lua? Как по мне, только вред - кодировка может слететь и файл будет забиваться мусором.

P. S. Если я правильно помню, Lua используются только 92 символа, а в таблице их 256.

P. P. S. Советую предварительно погуглить алгоритмы сжатия или парсинга.

Люди хoтят решать задачки? Чтo-ж, раз нечегo делать, тo лучше делать чтo-тo пoлезнoе. У меня есть прoстая задача, нo гoтoвых реализаций не встречал. Интереснo, какие есть спoсoбы решения, если приoритет алгoритма декoмпрессии - кoмпактнoсть, а кoмпрессии - скoрoсть (сo скoрoстью у меня прoблемы).

Алгoритм сжатия ASCII текста (oчень хoрoшo пoдхoдит для упакoвки Lua-кoда, степень сжатия как deflate, нo кoд намнoгo кoмпактней):

1. Сoздать пустoй слoварь
2. Найти в тексте пoвтoряющиеся слoва длинны L
    Если есть сoвпадения, тo:
        Если длинна слoваря <= 127:
            Внести слoвo в слoварь.
            Заменить в исхoднoм тексте слoва на симвoл с кoдoм [длинна_слoваря+128]
    Иначе:
        L--
        Если L == 2:
            Перехoд к шагу 3
        Иначе:
            Пoвтoрить шаг 2
3. Присoединить слoварь к тексту.
4. Вернуть текст.

Алгoритм декoмпрессии:

1. Отделить слoварь oт текста.
2. Взять oчереднoе слoвo из слoваря.
3. Найти в тексте ссылку на слoвo из слoваря (найти симвoл с кoдoм [индекс_текущегo_слoва+128]).
4. Заменить ссылку на слoвo.
5. Если еще не все ссылки заменены, тo:
    Перехoд к шагу 3
   Иначе, если индекс текущегo слoва != длинне слoваря:
    Перехoд к шагу 2
   Иначе:
    Вернуть текст.

Число 128 используется, потому-что коды текстовых символов в ASCII влезают в 7 бит, остальные символы можно использовать в качестве индексов словаря в сжатом тексте.

Псевдокод вроде-бы четкий, но и без подсказок.

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

Минификатором можно сжать код до 937 байт, вполне неплохо.

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

Вернул форматировантие, переназначил функции, полегчало?

Если отметить в треугольнике Паскаля четные числа, то будет видно, что исходная последовательность из единиц генерирует фрактал. Я подумал: "Хм! А что если исходная последовательность будет случайной?", но применив этот способ на разных последовательностях, не обнаружил ничего интересного.
Перевернул треугольники, чтобы они образовывали симметричный квадрат, сделал постоянное обновление - получил что-то типа скринсейвера (хотя оно сильно потребляет ресурсы процессора, зато красиво, впрочем, на любителя).
 
Мандалы
pastebin get 0nw5nSBJ ssv.lua

 
Часы
pastebin get wA3Nz2YC clock.lua

Вполне.

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

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

local component = require("component") -- загружаем компоненты
local robot = component.robot -- подключаем компонент робота
local i_c = component.inventory_controller -- подключаем компонент контроллера

local function finditem(side, name) -- функция поиска предмета в контейнере, первый параметр - сторона, второй - системное имя
  local inv, item = i_c.getInventorySize(side) -- узнаем количество слотов инвентаря
  if inv then -- если удалось узнать количество слотов
    for slot = 1, inv do -- в цикле проходим по всем слотам
      item = i_c.getStackInSlot(side, slot) -- получаем информацию о слоте
      if item and item.name == name then -- если имя предмета в слоте совпадает с нужным
        return slot -- возвращаем номер слота
      end
    end
  end
  return nil
end

local i = finditem(3, "minecraft:iron_pickaxe") -- ищем предмет в контейнере перед роботом
if i then -- если предмет найден
  robot.select(1) -- выбираем первый слот робота
  i_c.suckFromSlot(3, i) -- берем предмет
  i_c.equip() -- переносим в слот для инструмента
end

Справка по сторонам - 1 = сверху, 0 = снизу, 3 = спереди.

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

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

На карте 500x500 блоков еще можно было бы плакать, а так.. Не умеешь прятаться - не играй, в крайнем случае прячь все в эндерчест.

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

Мне нравится общая идея, кроме беспроводных карт на пол-сервера и апа роботов. Я играл на таком сервере и мне это очень понравилось.

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

Для экшон-шутеров OC не приспособлен, но какая-нибудь пиксельная казуальщина или продвинутые настолки работают прекрасно.

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

Предлагаю не добавлять в _G.effects пустые слоты "{}" и перед добавлением обрабатывать список эффектов в слоте через gmatch. Вывод будет красивый и удобный.

Я признаю только те законы, которые невозможно нарушить, а все остальное - всего-лишь пожелания. И программировать их будут игроки, поэтому если кто-то подключит к боту какого-нибудь IBM Watson и он начнет чудить, то я тут совершенно ни при чем.

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

Но функционал игрока - не единственное преимущество фейковых игроков, игру можно наполнить более живыми персонажами, нежели обычные жители, которые могут только хлопать дверьми и говорить "Хо!" каждые 10 секунд, кастомНеписи и рядом не стояли, т. к. ими невозможно управлять, только задавать какие-то невразумительные шаблоны, по которым они будут работать бесконечно. А андроиды позволят наполнить игру ролеплеем, приключениями, квестами, почти без участия игроков, т. к. сюжеты будет генерировать компьютер, который никогда не устает, в отличие от игроков, которые приходят и уходят.

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

И нечего кудахтать "Кт-кт-кт-кто это сделает?", как будет время - возьмусь и сделаю, добрые люди помогут советом.

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