Лидеры

Недавнo завезли нескoлькo нoвых функций. canSeeSky():boolean - вoзвращает true, если виднo небo. Прoзрачные блoки, стекла, крoвати не мешают, а ступеньки и пoлублoки считаются непрoзрачными. detect(стoрoна:number):boolean, string - кoпия функции component.robot, прoверяет наличие блoка с указаннoй стoрoны. Вoзмoжные варианты выдачи: (false, 'air') - пустo, блoк вoздуха. (false, 'replaceable') - есть блoк, кoтoрый мoжнo сдвинуть этo цветы, трава, лианы (пoка неизвестнo, как будет пoсле апдейта MC1.14). В приватах мoжнo считать за true, т. к. рoбoтoм лoмаются тoлькo кактусы. (false, 'liquid') - блoк жидкoсти, текущая жидкoсть (true, 'solid') - есть твердый блoк. (true, 'entity') - какая-тo сущнoсть. (true, 'passable') - блoк, через кoтoрый мoжет хoдить сущнoсть - флаг, кувшинка, паутина, пoртал и т. п. Некoтoрые блoки имеют нескoлькo сoстoяний, например, дверь и люк в oбoих solid, а вoрoта тoлькo закрытые. store(стoрoна:number, адрес_БД:string, слoт_БД:number):boolean - сoхранить блoк с указаннoй стoрoны в базу данных. isSunVisible():boolean - вoзвращает true, если пoгoда ясная, вo время дoждя или грoзы - false

Чтобы программа могла контролировать движения робота, добавим систему координат и функционал связанный с ней. Так как робот будет шахтером, то все движения должны сопровождаться разрушением блоков, он будет ползать сквозь породу, попутно захватывая руду. Описание основной двигательной деятельности занимает всего четыре функции (можно и три, но в прошлой версии, в процессе борьбы за место, пришлось одну разделить) Приведу базовый код, затем опишу, что он делает. local component = require('component') -- подгрузить обертку из OpenOS local X, Y, Z, D = 0, 0, 0, 0 local WORLD = {x = {}, y = {}, z = {}} local function add_component(name) -- получение прокси компонента name = component.list(name)() -- получить адрес по имени if name then -- если есть адрес return component.proxy(name) -- вернуть прокси end end local robot = add_component('robot') -- загрузка компонента local function step(side) -- функция движения на 1 блок local state, type = robot.swing(side) -- тестовый свинг if not state and type == 'block' then -- если блок нельзя разрушить print('bedrock') os.exit() -- временная заглушка else while robot.swing(side) do end -- копать пока возможно end if robot.move(side) then -- если робот сдвинулся, обновить координаты if side == 0 then Y = Y-1 elseif side == 1 then Y = Y+1 elseif side == 3 then if D == 0 then Z = Z+1 elseif D == 1 then X = X-1 elseif D == 2 then Z = Z-1 else X = X+1 end end end if #WORLD.x ~= 0 then -- если таблица меток не пуста for i = 1, #WORLD.x do -- пройти по всем позициям if X == WORLD.x[i] and (Y-1 <= WORLD.y[i] and Y+1 >= WORLD.y[i]) and Z == WORLD.z[i] then if WORLD.y[i] == Y+1 then -- добыть блок сверху, если есть robot.swing(1) elseif WORLD.y[i] == Y-1 then -- добыть блок снизу robot.swing(0) end table.remove(WORLD.x, i) -- удалить метку из таблицы table.remove(WORLD.y, i) table.remove(WORLD.z, i) end end end end local function turn(side) -- поворот в сторону side = side or false if robot.turn(side) then -- если робот повернулся, обновить переменную направления if side then D = (D+1)%4 else D = (D-1)%4 end end end local function smart_turn(side) -- поворот в определенную сторону света while D ~= side do turn((side-D)%4==1) end end local function go(x, y, z) -- переход по указанным координатам while Y ~= y do if Y < y then step(1) elseif Y > y then step(0) end end if X < x then smart_turn(3) elseif X > x then smart_turn(1) end while X ~= x do step(3) end if Z < z then smart_turn(0) elseif Z > z then smart_turn(2) end while Z ~= z do step(3) end end Сначала создаются переменные для локальных координат робота. X, Y, Z - собственно, позиция робота, относительно стартовой точки. D - направление, куда смотрит мордочка робота. при старте программы она относительная. Поэтому, чтобы привязать ее к сторонам света, надо будет произвести некоторое шаманство при помощи геосканера. Таблица WORLD - это метки, которые будут устанавливаться в процессе сканирования. Таблица разделена на три, это смежные хранилища переменных для каждой координаты, например, сканер обнаружил блок с подходящей плотностью по координатам x15, y-10, z3, в таблицу они будут добавлены по одному индексу. Допустим, таблица была пустая, после добавления будет иметь вид WORLD.x[1] = 15, WORLD.y[1] = -10, WORLD.z[1] = 3 или WORLD = {x = {15}, y = {-10}, z = {3}} Далее следует функция, упрощающая добавление компонентов. На вход получает имя нужного компонента и, если он есть, выдает прокси к нему. Функция step() - основное движение робота. Учитывая, что программа используется исключительно для копания, копание будет в каждом шаге. Робот не тыкается носом в породу и не спрашивает какой блок перед ним. Махнул инструментом и смотрит результат. Если есть блок, но добыть его не получилось - следовательно, дальше делать нечего, там бедрок или еще чего похуже, потом добавим правильную обработку и эвакуацию по хлебным крошкам, а пока пусть будет заглушка. Если махнул удачно - пробуем еще раз и еще, до посинения. Это своеобразная защита от лагающего гравия/песка и назойливых сущностей (в виде гномиков). Далее, если функция движения была совершена удачно, то обновляем локальные координаты, учитывая направление движения. Ну и в конце функции сканируем таблицу меток, ищем метки с текущей позицией и удаляем, т. к. по нашим данным робот находится в блоке руды, следовательно, он его добыл. Еще есть дополнительная проверка по вертикали - если есть руда сверху или снизу, то захватываем, это позволит сократить общую сумму переходов между метками и ускорить добычу. Функция turn() - основной поворотник (аналог robot.turn(), но с обновлением переменной направления) Робот поворачивается, записывая результат в переменную, добавляя/отнимая единицу по модулю 4 при каждом повороте. Функция smart_turn() - поворот на желаемую сторону света, с минимумом действий. Вычисляет разницу между текущим и целевым направлением, запуская результат по модулю 4 через turn() Функции поворота можно будет объединить, но пока оставлю так. Функция go() - великий ход конем до нужных координат. Принимает координаты целевого блока, двигается по вертикали, поворачивает на цель X, двигается до цели, поворачивает на цель Z, двигается до цели. Для поворота использует smart_turn(), т. к. оси x и z глобальные, это стороны света.

И так, наконец-то возвращаюсь к роботу-копателю. Да будут новые баги и новые фичи! Краткий план внедряемых фич: Улучшенное сканирование руд. Робот сканирует под собой квадрат 16x16 блоков, опускаясь блок за блоком. При обнаружении бедрока запускается функция добычи. При добыче робот поднимается и в цикле ищет ближайшие по горизонтали блоки руды, захватывая три слоя - Y+1, Y, Y-1 Определение энергопотребления сборки при запуске. На старте, робот запоминает количество потребленной энергии на один шаг + прочность инструмента. Это будет служить константой при проверке статуса, чтобы была возможность гарантированно вернуться на точку старта. Умная упаковка добычи. Перед обработкой рассыпухи, теперь будет точнее анализироваться свободное место, упаковка не будет происходить механическим перебором, из-за которого бывали внезапные сбои. При наличии генератора, робот всегда будет с собой таскать уголь, при разгрузке на точке старта будет забирать стак угля или угольных блоков. Текущие константа энергопотребления и координаты будут записываться в EEPROM. Следовательно, при наличии сетевой/связанной карты, робота можно будет будить и не бояться выгрузки чанков, лагов, космических лучей. Скорее всего, добавлю функцию аварийного крафта кирок из булыги, в случае работы с ванильными инструментами. Планируется утилита, собирающая программу по параметрам, заданным пользователем. ...Или не планируется, скорее всего все возможности копалки не получится впихнуть на EEPROM, поэтому на EEPROM будет загрузчик с main функцией, а дополнительные модули придется записывать на жесткий диск. Планируется поддержка модов, например, возможность возить с собой и разворачивать заправочную станцию в виде генератора и зарядника. Или скидывать предметы в межпространственные сундуки. Тут надо будет смотреть, как будут развиваться моды. В блоге буду описывать каждую функцию, чтобы отследить создание программы шаг за шагом, надеюсь, кому-то это поможет.

Каждый, кто занимался разработкой человеко-машинного интерфейса под OpenOS, наверное знает какое это муторное занятие. Даже если Вы используете библиотеку GUI. То и дело приходится выходить из редактора кода, запускать свою программу, смотреть на результат своих стараний и снова заходить в редактор, чтобы исправить всего одну цифру. Предлагаемая система позволяет создавать интерфейсы программ не в текстовом редакторе, а в графическом при помощи мыши, но самое главное - результат своей работы Вы можете видеть сразу, не выходя из редактора. Построена система на основе уже известной Вам gui-библиотеки forms. При входе в FormsMaker мы видим пустую форму Щелкните правой кнопкой мыши в любом месте формы после чего откроется окно управления компонентом Выбрав пункт "Свойства Form1" можно (будет) редактировать свойства формы, такие как цвет рамка и т.д. Пункты "Add ..." добавляют на форму соответствующий компонент. Пункт "Проект" позволит управлять проектом: сохранять, компилировать и т.д. Для возврата к редактируемой форме выберите "Отмена" К примеру мы выбрали пункт "Add frame". Это добавит на нашу форму рамку. Таким же образом на рамку можно добавить кнопку. Щелкаем ПКМ на рамку и выбираем "Add button" Изменить размер рамки можно при помощи ЛКМ, потянув за правый-нижний ее угол А перемещать рамку по форме можно перетаскивая за любое свободное её место pastebin get wA5KMKav fmaker.lua Приму с благодарностью любую посильную помощь в развитии проекта, как в программировании, тестировании так и просто советом.

Никак, стандартный уровень шума не изменился. Первая версия сканировала 8x8 блоков, я жестко задал плотности, которые получил при сканировании дальних блоков (самая мягкая руда и бедрок) В этой версии изменять ничего не придется, т. к. так же сканируются 4 квадрата x8, только теперь робот не будет смещаться по горизонтали, пока не дойдет до бедрока. С таким подходом уровень шумов по краям будет постоянным, ускорится добыча руды и общий профит.

текст

Насколько я помню, в меню по ПКМ она где-то. Надо прокрутить ещё будет, вроде.

Вроде, поправил. Обновите либу forms.

После обновы OC 1.6 расширился функционал геосканера. Теперь, помимо обычного сканирования вертикальных столбов появилась возможность сканировать произвольный кубоид, содержащий не более 64х блоков (т. к. функция в любом случае возвращает таблицу из 64х элементов) scan(x, z[, y, w, d, h][, игнорировать_замещаемые]) Если задать только x, z, то геосканер будет работать в обычном режиме. А при добавлении y, необходимо указать ширину, длину и высоту кубоида, соответственно: w, d, h. Т. е. первые три значения это стартовые координаты, откуда начинать сканирование, а дальше его размеры. Четвертое значение это указатель, приравнивать ли замещаемые блоки (трава, саженцы и т. д.) к воздуху. Возвращаемые значения приходят в не очень удобном формате. Чтобы отобразить отсканированный объем в одномерной таблице, сканирование происходит в виде трех циклов, один в другом: for x(for z(for y())) Т. е. сначала идет заполнение по x, потом по z, потом по y. (Запад->Восток, Север->Юг, Низ->Верх) К примеру, надо просканировать куб x2, где какой блок будет отображен в таблице? Зададим область сканирования: scan(0, 0, 0, 2, 2, 2) - точкой старта будет блок геосканера, точка финиша в относительных координатах 1, 1, 1 Сначала у нас идет x, следовательно, первый элемент таблицы - плотность самого геосканера (0, 0, 0), второй элемент - блок на восток от сканера (1, 0, 0). Далее у нас идет второй блок по z, следовательно это южный блок (0, 1, 0), затем - юго-восток (1, 1, 0). Второй блок по оси y - (0, 0, 1) и т. д. Следовательно, таблица у нас будет выглядеть так: [1] = 0, 0, 0 [2] = 1, 0, 0 [3] = 0, 1, 0 [4] = 1, 1, 0 [5] = 0, 0, 1 [6] = 1, 0, 1 [7] = 0, 1, 1 [8] = 1, 1, 1 Остальные элементы можно отбросить, т. к. это шум. В голове это держать может быть неудобно. Поэтому, напишем функцию, через которую можно будет задать кубоид и координаты блока, а она выдаст позицию в таблице, где указана плотность этого блока. local function tblpos(x, z, y, w, d, h, tx, tz, ty) -- первые 6 значений это то, что мы задаем геосканеру, tx, ty, tz = координаты искомго блока local p = 1 -- создаем счетчик local xmax, zmax, ymax = x + w - 1, z + d - 1, y + h - 1 -- преобразуем размеры кубоида в финишные координаты for y1 = y, ymax do for z1 = z, zmax do for x1 = x, xmax do if x1 == tx and z1 == tz and y1 == ty then -- если счетчик допрыгал до искомых координат return p -- возвращаем позицию end p = p + 1 end end end end Например, зададим тот же кубоид и узнаем позицию блока, с координатами 1, 1, 1 pos = tblpos(0, 0, 0, 2, 2, 2, 1, 1, 1) pos станет равно 8 Чтобы проверить плотность этого блока, обратимся к таблице print(geolyzer.scan(0, 0, 0, 2, 2, 2)[pos]) Либо, более наглядно - print(geolyzer.scan(0, 0, 0, 2, 2, 2)[tblpos(0, 0, 0, 2, 2, 2, 1, 1, 1)]) Но, городить целую функцию для проверки блока это бред, эту функцию надо применять для обработки полученной таблицы, т. к. при каждом сканировании происходит задержка, лучше сканировать больший объем и затем, обрабатывать, используя такую функцию. Чтобы узнать плотность блока в определенных координатах, достаточно сделать так: scan(x, z, y, 1, 1, 1)[1] Т. е. задаем координаты блока, указываем размер кубоида 1x1x1 блок и сразу обращаемся к первому элементу таблицы. Стоит помнить, что при одном сканировании доступно только 64 блока, т. е. можно просканировать куб x4, либо квадрат x8, думаю, это понятно. Вот примеры: scan(-32, -32, -32, 4, 4, 4) scan(5, 5, 5, 1, 8, 8) scan(-32, 0, 0, 64, 1, 1)

Чередуя дни беспросветной лени с часами бешеного программирования, удалось реализовать редактор обработчиков событий. Таким образом FormsMaker начинает приобретать черты полноценной системы программирования. Продемонстрирую на примере простенькой программы - счетчик количества нажатий на кнопку. Запустим fmaker и создадим на форме метку (addLabel). Эта метка будет отображать количество нажатий. Необходимо установить начальное значение равное нулю, для чего щелкнем ПКМ на метке и откроем окно свойств. Выберем свойство "caption" (надпись) и зададим ему новое значение - "0" Закроем окно свойств метки и аналогичным образом создадим кнопку (addButton). В качестве надписи укажем - "+1" Щелкнем на строчку onClick в окне свойств кнопки. onClick - это обработчик нажатия на кнопку. Пока он не привязан ни к какой функции, о чем нам и сообщается. Что бы создать функцию обработки, нажимаем кнопку "New" и попадаем в редактор обработчика событий Заголовок функции-обработчика и завершающий end создаются автоматически. Наша задача прописать тело функции Строчка Label1.caption=Label1.caption+1 увеличивает значение надписи на единицу. А строчка Label1:redraw() вызывает перерисовку компонента Label1. Для выхода из редактора обработчика событий необходимо кликнуть за пределами поля редактирования или нажать F10. Вот, собственно, и всё программирование. Теперь необходимо сгенерировать код, для чего вызвать соответствующий пункт меню ... и выйти из FormsMaker Что бы посмотреть код, получившийся в результате генерации, откроем его командой "edit Project1.lua" А запустив его на выполнение, можно убедиться в его работоспособности Напоминаю, с последней версией редактора можно поэкспериментировать в дата-центре на компьютере с координатами 10150, 14199.

TextEdit должен быть похож на компонент Edit, с той лишь разницей, что Edit это редактор одной строки, а TextEdit - многострочный редактор. Но с добавлением этого компонента библиотека forms должна остаться "легкой", а для этого нужно максимально использовать системные ресурсы. К примеру, для создания Edit я использовал стандартный term.read, хоть и не совсем обычным способом.

Почему с одним? Сколько надо, столько и делай

Кто сможет сделать компонент TextEditor?

При клике на какое то из свойств открывается окно редактирования свойства (его я не показал на скриншоте), в котором присутствует компонент Edit. В этот Edit вводится новое значение свойства. Или речь идет об одном TextEditorе, в котором редактируются сразу все свойства?

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

Верно. Любой объект на луа есть ничто иное как таблица. Изменение свойств объекта это редактирование таблицы. А если учесть, что переменные и функции являются полями таблицы _G, то можно говорить, что программирование тоже редактирование таблицы.

Пока никаких. Но в будущем, возможно, любые.

А какие свойства можно добавлять?

При выборе пункта "Свойства" теперь доступно окно редактирования свойств компонента В этом окне можно изменять цвет, надпись и другие свойства. Тестовую версию программы по прежнему можно опробовать в дата-центре на компьютере с координатами 10150, 14199.

Желающие могут опробовать генерацию кода. Для этого надо на уже упоминавшемся компьютере создать элементы интерфейса, после чего нажать ПКМ и в выпадающем списке выбрать пункт "Генерировать код". Этот пункт в список не помещается, поэтому список нужно прокрутить колесиком. Результирующий код смотрим в файле Project1.lua. Его можно даже запустить.

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

Судя по всему, это будет что-то грандиозное. Хочется немного ясности. Что пользователь получит в конце после создания дизайна кнопок, окошка или списка + кнопки и прочим. Что это будет после сохранения? Луа код? А его потом уже можно и нужно дорабатывать функционально? Повесить функции кнопкам и прочее? Так? Это система быстрого визуального создания менюшек?

Всё таки, конечным результатом работы системы будет луа-код, получаемый в результате компиляции проекта (да простит меня NEO).

Меня смущает название темы. "Система визуального программирования" это немного другая штука. "Редактор форм" - больше подходит

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

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

Zer0Galaxy, ты как всегда суперские программы пишешь.