Лидеры

Недавн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

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

текст

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

Вроде, поправил. Обновите либу 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, ты как всегда суперские программы пишешь.