eu_tomat

1) Где читать инфу о Lua именно для майна. 2) Есть ли раздел с такими гайдами или чем то похожим у вас на форуме (потому что я сам не нашел подобного). 3) Ну и пару слов мб с вашей истории было бы не плохо услышать (если не сложно) как вы учились писать проги на луа. Может книгу какую прочитали или есть канал на YouTube хороший?

1.

Нет абстрактного "Lua для майна", но есть поддержка Lua в моде ComputerCraft и в моде OpenComputers. Сильных отличий от стандартного Lua нет. Основная разница в API доступа к библиотекам и компонентам. Поэтому нужно знать обычный Lua и особенности модов.

2.

Раздел с гайдами имеется.

Также есть гайды по модам.

Там же лежит легендарная серия уроков от @1Ridav по Lua в ComputerCraft.

На главной странице есть "Полезные ссылки" с описаниями как языка Lua, так и модов ComputerCraft и OpenComputers.

3.

Я изучал Lua и мод ComputerCraft по тем самым урокам @1Ridav. Тем, кто уже имеет навык использования других языков программирования, эти уроки могут показаться нудными и затянутыми. Но таким людям и не нужны подобные уроки, а достаточно какой-нибудь статьи в духе "Lua за 60 минут", да справочника по API библиотек модов.

 

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

Я читал и API из OC и просто смотрел на примеры. Я кинул часть своего кода который не работает. И я не знаю почему. В интернете очень много инфы мне не нужной и очень тяжело ее фильтровать. Я подумал что тут мне смогут помочь.

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

 

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

В какой переменной сейчас учитывается время? Какое она имеет имя, и какой тип данных хранит?

Неужели так сложно сделать такой таймер? Киньте хоть ссылку где можно инфу по этой теме полезную почитать

Инфу конкретно по теме твоей программы вряд ли удастся найти.

Но если разделить задачу на части, то по каждой из них вся инфа найдётся в свободном доступе. В чём именно возникло затруднение?

Потому что это константы

Как в том анекдоте: либо штаны наденьте, либо крестик снимите.

 

Дело в том, что в Lua нет именованных констант. Но если значение переменной не меняется в течение срока её жизни, такую переменную условно можно назвать константой. Условно. Но так как обсуждаемые переменные не являются локальными, и срок их жизни может превышать время выполнения программы, и нет никаких гарантий, что их не изменит другая программа, то константами такие переменные не могут называться даже условно. В общем, выбирай: либо это совсем не константы, либо локальные переменные, которые можно условно назвать константами.

 

Остальные ошибки -  к @@Doob со своим IRC modem, я оттуда скопипастил всё

А это вообще шедевр. Особенно после предыдущего заявления:

Делать было нечего, накатал маленькую программу (74 строки) которая позволяет сделать мост между игровым и IRC чатом.

Так кто накатал программку: @Laine_prikol или @Doob? И если это вторичное творчество, то почему нет ссылки на оригинал, и описания отличий от него? И кто теперь будет сопровождать этот код? Пушкин? @Doob?

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

Точно. Обожаю рыть норы, чтобы в норах строить коробки. Зато рабочее пространство функционально, а порча территории минимальна.

 

Сейчас слетал от спавна на север до 2600. Ровно 5 домиков плюс 2 здоровых херни в виде коробки. Остальное околостандартный дом с растительностью снаружи.

Отлично! Можно сильно сэкономить на хранении общей карты, применив дельта-кодирование.

За стеной в 32+ блока. Даже за 6ю.

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

 

Зато оболочка в 32 блока принципиально непреодолима для геосканера. Печаль лишь в том, что от доступного привата в 500k блоков на EvilWorld при такой жирной скорлупе останется менее 4k блоков полезной ёкмости.

Киты работают, а хелп не хочет:

/help
У Вас нет прав для выполнения данной команды.

Тут принимаются идеи, баги, помощь.

Сканер вместо координат выводит шаблон форматирования:

Robot detected: x=%s y=%s z=%s

 

Радар на все запросы выдаёт пустую таблицу

=component.radar.getEntities(999)
{n=0}
=component.radar.getItems(999)
{n=0}
=component.radar.getMobs(999)
{n=0}
=component.radar.getPlayers(999)
{n=0}

Тестировалось в сингле на текущей сборке EvilWorld.

Самое время оживить тему, ведь текущие территории очень даже хорошо лягут в такую карту и хватит 20-30 проекторов чтобы покрыть все текущие домики.

Интересно, область какого размера ты планируешь покрыть 30 проекторами?

Спавн + 8 ближайших к нему приватов? Это точно не "все текущие домики".

Вставлю свои пять копеек, чтобы правильность была еще более правильной. Ох уж эта правильность... В общем, так как время, затрачиваемое на вызов функций в Lua значительно превышает время осуществления иных операций, следует использовать итеративный метод расчетов вместо рекурсивного. Кроме того, как вполне грамотно заметил товарищ с e-maxx.ru, для определения четности числа имеет смысл заменить "n % 2 == 0" на "n & 1 == 0". В итоге времечко сократится еще втрое. Собсна, пруф: https://ideone.com/t9Yv5F

А я вставлю ещё копейку. Не знаю, как в текущей версии OpenComputers, но около года назад я проводил замеры, и не обнаружил разницы во времени исполнения разной арифметики типа + - * / % & | >> <<

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

 

@@HeroBrine1st а зачем тебе статичная таблица простых чисел, если можно легко написать генератор этих чисел? И будет у тебя сколько хочешь таких чисел. Генерация не займёт много времени.

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

 

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

 

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

 

я нашел странную вещь - при больших числах выходное значение дешифрования отлично от входного значения шифрования.

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

Гифка впечатляет. Теперь скрытые под толщей обсидиана лабиринты доступны для осмотра любым желающим. Где теперь прятаться?

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

 

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

 

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

Попробовал от 990000 до 1000000 использовать простые числа. Шифровка - нормально, дешифровка - too long without yielding.

Что и неудивительно с такой реализацией:

 

local function modulePow(n1,n2,m) --возведение в степень по модулю
    local c = 1
    for i = 1, n2 do
        c = (c*n1)%m
    end
    return c
end

 

На помощь придут Алгоритмы быстрого возведения в степень

А вот если взять робота из OpenComputers, то можно и для других нужд лаву начёрпывать. =)

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

А как выкачивать лаву из черепашки?

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

В openOS не хватает какой-нибудь оболочки, типа midnight commander

Возможно, как-то поможет эта оболочка:

Файловый менеджер Midday Commander

Это решается кодированием Хаффмана. Можно реализовать, если это востребовано

Ничего в Майнкрафте не востребовано. Всё ради фана. Многие вообще без роботов обходятся.

Вопрос же был об экстремальных задачах для OpenComputers, но чтобы без самой игры.

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

Так играть то не интересно. Я вообще сам майнкрафт как игру не люблю, как бы странно это не звучало. Мне очень нравится хардкорное программирование. Тут есть кривой язык (Lua, конечно, крутой скриптовый язык сценариев для игр, но полноценный софт на нем писать не надо), ограничения по памяти, дравколлам, процессору. И сообществу по факту предлагается написать свою инфраструктуру, свой софт, который является пародией на реальные аналоги. Это интересно как отдых, развлечение, не больше. Никакой практической ценности, чистый фан. И мне автоматизировать робота скучно. Это ближе к игре, чем к чистому программированию. А вот решать сложные задачи в таких спартанских условиях действительно весело.

Одно время я увлёкся темой компрессора Lua-кода, но написал только SFX-модуль, да поиск сжимаемых участков, благодаря чему смог оценить степень сжатия, и на этом успокоился. Вполне экстремальная задача, когда весь код должен помещаться в 4096 байт и более-менее быстро распаковываться.

 

Если интересно, Задачка (алгоритм: ASCII-компрессор)

Интересно, конечно, софт из реальной жизни переносить в мод, но по большей части это невозможно, к сожалению.

@@Jakowlew Большинство из тех, кто пишет, не мучают себя поисками задачи. Играют, пишут какую-то автоматизацию для удобства. Если получается чем-то лучше, чем у других, выкладывают. А если не получается, так хотя бы в игре развлекаются.

Да что такое :с

Все уже написано. Даже для мода на майнкрафт. Я разочаровался :с

И что, нет никаких нереализованных проблем? Серьезно?

Во-первых, оно так и не было написано. И возможно, речь здесь идёт как раз о нём:

Браузер делали-делали, да не доделали, к сожалению.

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

З.Ы. Браузер тоже сделали?

@Krutoy, помнится, "Арбузер" писал.

Для MC 1.7.10 в версии OC 1.7.2 контроллер инвентаря и транспозер наконец-то научились получать название инвентаря. Положение сундука теперь определяется однозначно.

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

Второй вопрос звучал иначе, а это ответ на какой-то другой вопрос. Если я верно понял, формулировки останутся.

 

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

Тема будет редактироваться!

...

Писалось это все на коленке, могут быть опечатки =)

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

 

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

 

Что в данном случае означает фраза «тема будет редактироваться»? Считать ли такую тему черновиком и подождать, когда автор доведёт её до ума и оповестит об этом дополнительным сообщением в теме? Или сам автор уже сделал, что мог, а тема будет редактироваться в соответствии с вопросами и уточнениями читателей?

 

И еще один вопрос. Планируется ли впоследствии удалить формулировки про редактирование, про опечатки и коленки, и при каких условиях?

Ой! А зачем же так код упакован? И Lua beautifier не хочет приводить его в порядок.

В общем, код я посмотреть пока не смог, а запускать не буду.

 

В связи с этим возникает вопрос: не приводит ли интенсивное использование этой библиотеки к обратному эффекту, о котором рассказывал @ECS, когда сборщик мусора не успевает чистить интенсивно создаваемые и уничтожаемые объекты, от чего фактическое потребление памяти начинает расти?