ZO125
Пользователи-
Публикации
14 -
Зарегистрирован
-
Посещение
-
Победитель дней
2
Тип публикации
Блоги
Профили
Форум
Багтрекер
Магазин
Все публикации пользователя ZO125
-
Либо я не понял идею, либо она мне кажется странной. Я так понимаю автор решил создать несколько регистров "предварительно" содержащих результат любой возможной операции? А их содержимое просто копировать? Такой подход мне кажется как минимум неэффективным. Придется дожидаться установки последнего из возможных регистров перед выполнением следующей инструкции, что значительно уменьшит скорость операции mov, и как следствие вообще любого алгоритма исполняемого на такой архитектуре, иначе есть риск скопировать ммм... Помехи...
-
Боюсь оба варианта неправильные. Если вам надо прочитать всего один байт то в аргумент file:read(<сюда>) ставьте число 1. В в том положительное число или отрицательное вам нужно-я бы поэксперементировал, но думаю отрицательное. Предлагаю прочитать про функцию file:read из стандартной библиотеки lua io (в рукововодстве file:seek и file:read): http://lua.org.ru/contents_ru.html
-
Если мне не изменяет память whence это строка, которая может содержать: "set" установить позицию чтения относительно начала файла, "cur" относительно позиции, на которой она уже стоит, "end" относительно конца файла. Например этот код прочитает из файла 4 байта начиная с 10го: file:seek("set", 10) print(file:read(4))
-
Как ни странно первое желание я узнал про функционал сетевых карт было написать что-то вроде похожего чатика... Вообще если исключить факт существования внешних средств коммуникации между игроками (Скайп, дискорд и прочие) то это даже могло-бы послужить хорошим дополнением к игре. Например на сервере существует сеть по которой игроки могут общаться, а радиус чата в.т.ч. личного ограничен скажем 64мя блоками. Глобальный чат отсутствует. Можно даже прилепить к подобным прогам чатбокс для трансляции сообщений из чата-в чат на расстоянии, а с помощью мостов и хорошей сети передавать сообщения в.т.ч и между серверами...
-
Из статьи мне непонятно: компоненты периодически отваливаются самопроизвольно (Почему? Они сами отваливаются или их кто-то может сломать?) во время работы программы, или автор хочет проверить то, подключен ли конкретный компонент к системе и можно-ли с ним нормально взаимодействовать. Полагаю в случае, когда компонент отваливается из-за ошибок игры, данное решение грубое, или даже не годится, но во втором почему-бы просто не ловить ошибки вызовов компонентов с помощью оборачивания их pcall()? Да компонент может отвалиться по любой причине прямо во время работы программы, но тогда программа все равно не ляжет, а ты сможешь не знаю... Вывести на экран сообщение что компонент отвалился. function draw() local gpu = component.gpu gpu.set(1, "Hello World!!") end local ok, err = pcall(draw) -- Так в случае любых ошибок в ok попадет false, а в err название ошибки.
-
Ваши программы и вложенные в них сопрограммы должны соблюдать простое правило: не обрабатывать ничего дольше чем промежуток времени до следующего computer.pullSignal(), если-же вам необходимо сделать что-то что занимает времени больше вы просто делаете этот pullSignal() и считаете дальше. Чем чаще вы ставите yield-ы тем дольше (реального времени) вы считаете, но тем меньше шанс словить TLWY. Просто найдите компромисс между скоростью вычислений и опасностью словить TLWY в конкретной части кода. А еше лагающий сервер это плохо. Не стоит возвращать каким-либо образом управление компьютеру отключившемуся от TLWY. В любом случае ваш сервер не должен лагать, или какой смысл вообще играть на таком сервере?
-
local function sleep() return coroutine.yield() end local function longCodePiece() --Тонна кода тут sleep() --Еше тонна тут end local thread = coroutine.wrap(longCodePiece) while true do local event = {computer.pullSignal(0.05)} -- Обрабатывем сигнал тут coroutine.resume(thread, event) end А такое чудо от потери событий не спасет? Вообще если ваша задача слишком жирна для одного тика почему-бы ее не выделить в отдельную сопрограмму?
-
Я погонял прогу... Ну можешь написать костыль, который переведет это чудо в lua-number, а потом ручками в UTF 8. В любом случае код, который выплевывает твоя прога похож на русские буквы в юникоде с небольшими исключениями. Если мне не изменяет память чтобы перевести число после U в UTF 8 надо: 1) Перевести его в двоичный вид 2) Посчитать сколько байт тебе понадобится 3) Занести его туда по следующим правилам: 3.1) В первом байте начиная со старшего бита ввести столько единиц, сколько понадобится байт, завершив нулем, т.е 110 значит что символ двухбайтовый, а 11110 - четырехбайтовый. 3.2) Любой следующий байт начинается (1-старший бит) с 10 Просто вбить двоичный код полученный из числа в оставшиеся биты по порядку. Программа красиво выплевывает ошибку HTTP:400 при неправильных учетных данных )
-
Изменил формат таблицы и места взаимодействия программы с ней. Обновил код на pastebin. [21.11.20]: Добавлена простейшая поддержка Unicode, интерфейс переведен на Русский язык. В меню в качестве границ используются символы Unicode. Улучшен механизм ввода текста. Строка теперь выделяется нормально, каретку можно перемещать, добавлен мигающий курсор и строка теперь принимает Unicode-символы (Хотя зачем это нужно в англоязычном unlocalized-name непонятно...) [05.12.20]: Добавлена возможность выбора диапазона слотов. Исправлены некоторые (А их еше и осталось много) ошибки.
-
@eu_tomat С отзывом ознакомлен. Отредактировал код функций loadProperities и saveProperities. Заменил ссылку на pastebin. Исправил все, кроме Тут я все-таки настою чтобы остался именно такой формат цикла. Мне не очень нравится как в lua реализованы циклы с итератором... Также я считаю быстродействие кода несколько важнее красоты... Кстати вот тут наверное следует задать следующий вопрос: Хорошо-ли инициализировать новую функцию внутри старой, которая может вызываться несколько раз, например (код): function generator(text) return function() print(text) end end local f1 = generator("Some text 1...") local f2 = generator("Some text 2...") f1() f2() Не загадит-ли вложенная функция кучу ОЗУ, если я создам их несколько? Не лучше-ли создать "обьект" с полем text и один метод, вызывая его через ":"? Долго-ли занимает процесс инициализации функции, т.е имеет-ли вообще смысл где-то инициализировать одну функцию внутри другой, или лучше сразу инициализировать все что надо, передавая данные через аргументы или "обьектом"?
-
@eu_tomat Ознакомился с вашим сообщением, отредактировал тему. Вот пример практического применения подобной программы: Столик крафта из Tinkers Construct умеет взаимодействовать с ванильным сундуком. Почему-бы не реализовать механизм, который будет подавать частоиспользуемые ресурсы прямо в сундук? Это может упростить процесс крафта. Вообщем идея и схема для примера, но вот. Скрины: В компьютере прописано какой ресурс из какого сундука брать и сколько его поддерживать в целевом сундуке. Собственно файл фильтра: filter.txt Именно второй вариант. Мы выбираем инвентарь и предметы которые мы хотим в него положить / из него извлечь посредством ввода стороны света и слота, а также unlocalized name самого предмета. Я также должен сказать что не первый год пишу на lua в майне, но это моя первая "Публичная" программа. Я просто понял что мое умение писать код не будет развиваться, если я его(код) не опубликую.
-
А если попробовать так? text_buffer = unicode.sub(text_buffer, 0, unicode.len(text_buffer) - 1) Код не проверял. Набросал наскоро.
-
Программа умеет управлять одним транспозером, для перемещения определенных предметов между инвентарями. Предметы можно перемещать/не перемещать проверяя их unlocalized name и meta. При запуске программы откроется графический интерфейс, в котором отобразится ID компонента транспозера, доступные инвентари, их названия, стороны, количество слотов ... Управление в программе: Для работы программы необходимо создать один или несколько правил (В программе они называются фильтрами. filters). Новые правила создаются нажатием клавиши INSERT на клавиатуре. При нажатии на эту клавишу вы попадете в меню настроек только-что созданного фильтра, в котором вы сможете настроить как именно, что и куда надо перемещать, используя данный фильтр. Виды полей и их описание: Алгоритм сортировки: Программа последовательно проходится по всем фильтрам в порядке их ID и пытается вытащить предмет из инвентаря источника (input side, input slot) и положить его в инвентарь приемник (output side, output slot), попутно проверяя совпадает-ли unlocalized name предмета с фильтром, meta с фильтром, если совпадает, то необходимое количество предмета перекладывается в инвентарь-приемник. Программа переходит к следующему фильтру. Ссылка на pastebin: https://pastebin.com/YQdYSa77 При корректном выходе из программы (С помощью BACKSPACE) программа сохранит конфигурацию в файл в корне файловой системы /filter.txt. Удаление этого файла сотрет конфигурацию. Буду благодарен за конструктивную критику по поводу качества кода. Скрины:
