Doob

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

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

Я использую пропущенный через минификатор - слов меньше, получается 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 комменты писались транслитом.

А какая польза от кириллицы в 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 и он начнет чудить, то я тут совершенно ни при чем.