Godot: Добавьте специальные возможности для слепых разработчиков, использующих программы для чтения с экрана

Это, безусловно, было бы долгожданным улучшением, но я уже могу сказать, что его реализация, скорее всего, займет некоторое время, если вообще будет реализована. Редактор Godot использует собственный набор инструментов с графическим интерфейсом, такой же, как и в играх, и полностью независим от нативных наборов инструментов или кросс-платформенных инструментов, таких как Qt или GTK+, которые имеют хорошую поддержку программ чтения с экрана.

Таким образом, чтобы заставить это работать в Godot, это должно быть реализовано с нуля в основных элементах управления. Не знаю, насколько это сложно, но, наверное, нетривиально.

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

Я был бы рад помочь вам, ребята, добавить это. Я сам слепой. :) По крайней мере, я мог бы отослать вас, ребята, к фреймворкам (в качестве возможностей приходят на ум MSAA и UIA, хотя мне по крайней мере UIA предпочтительнее, так как NVDA (https://github.com/nvaccess/nvda) (открытый исходный код программа для чтения с экрана) использует его) и протестируйте его по ходу дела. А пока есть ли альтернативный редактор godot или способ создания игры вручную, без редактора?

Если бы эта функция была реализована в ядре самого движка, то можно было бы разрабатывать приложения для слепых, а не только позволять слепым разработчикам работать.
+1 к предложению

Я рад видеть, что на это смотрят, и единственное, что я должен добавить по этому поводу, это то, что программное обеспечение для чтения с экрана также используется людьми с ограниченными возможностями/трудностями в обучении, такими как дислексия. Как бы я не ненавидел то, как эти вещи иногда упускают людей, я думаю, можно утверждать, что это расширяет доводы в пользу такого развития событий.

NV Access (NVDA) был бы хорошим первым местом для контакта, так как оба ведущих разработчика слепы и поэтому имеют правильное представление о том, что необходимо. Может совместная работа?

Привет,

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

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

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

Надеюсь, это поможет вам решить.

Ваше здоровье,

Такая модель тоже будет работать, если обратиться к низкоуровневой доступности
API-интерфейсы в некотором роде потерпели неудачу. Я на 100% согласен, что NVAccess будет
ваш лучший выбор для получения самого высокого уровня доступности. :)

18 мая 2018 г. Франсиско Р. Дель Ройо на адрес электронной почты github.com написал:

Привет,

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

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

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

Надеюсь, это поможет вам решить.

Ваше здоровье,

--
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/godotengine/godot/issues/14011#issuecomment -390176511

--
Подписано,
Этин Д. Пробст

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

В качестве более практического примера, прямо сейчас я реализую звуковую игру, похожую на Asteroids. Астероиды издают звуки, чтобы отметить свое положение, и игрок центрирует их в звуковом поле, поворачиваясь / летая вокруг. Меня не особенно интересуют визуальные эффекты, но они были бы полезны для целей отладки, поэтому я могу спросить зрячих людей, совпадает ли, скажем, мое ментальное представление об ориентации моего корабля с грубыми цилиндрами/сферами, которые я использую для отладки/ обнаружение столкновений. Мне интересно, возможно ли хотя бы отдаленно расположить сферу диаметром 5 единиц в 0,0, случайным образом расположить и переместить кучу сфер диаметром 25 единиц, реализовать поведение обертывания и т. Д., Кодируя все это вручную без необходимость редактора Godot. Или это будет беспорядок редактирования неудобного для человека XML?

На данный момент я делаю это более или менее вручную в Rust с помощью ECS. Это не страшно, но мне интересно, выиграю ли я что-нибудь, используя настоящий игровой движок. В идеале Asteroids — это всего лишь проверка концепции, и в конечном итоге я хотел бы делать более богатые аудиоигры без необходимости создавать все это вручную. Является ли Годо тем решением, я не знаю...

В любом случае, я думаю, что реализовать интерфейс с полным доступом к инструментарию пользовательского интерфейса, вероятно, слишком сложно. Если файлы данных в основном текстовые, но неудобные для человека, промежуточным решением может быть DSL, который предоставляет упрощенный интерфейс для задач, описанных выше (позиционирование примитивов формы, присоединение звуков, добавление логики к объектам и т. д.).

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

Я думаю, что самый простой способ (без взлома) — это генерировать сцены процедурно с помощью скрипта. Вы можете либо сделать это во время выполнения, либо создать сценарий, который сохраняет сцены и ресурсы на диск, чтобы вы могли добавлять их в проект. Для первоначального создания каркаса потребуется файл project.godot для настроек проекта (который может быть пустым файлом, созданным ОС сначала) и основная сцена, которая запускается при запуске (которую также можно установить и сохранить с помощью скрипта) . Может быть сложным в управлении, но это возможно.

Технически вы можете создать скрипт, который запускается прямо из командной строки, и этот скрипт сделает за вас весь проект Godot (по крайней мере, я не могу придумать ничего, что могло бы этому помешать). Затем вы также можете запустить и экспортировать игру из командной строки. Вам нужно будет открыть проект в редакторе хотя бы один раз для импорта ресурсов (и каждый раз, когда ресурсы меняются), но это можно решить, запустив безголовую версию Godot, как это делают некоторые люди для использования с серверами непрерывной интеграции.

Если файлы данных в основном текстовые, но неудобные для человека, промежуточным решением может быть DSL, который предоставляет упрощенный интерфейс для задач, описанных выше (позиционирование примитивов формы, присоединение звуков, добавление логики к объектам и т. д.).

Формат текстового ресурса не так уж сложен для чтения, но все же, вероятно, проще просто использовать GDScript для создания материалов для проекта, поскольку вы можете использовать базовый движок для записи и чтения формата (избегая проблем с совместимостью).

К сожалению, GDScript — не лучший язык для слабовидящих, так как пробелы важны. Из-за этого я слышал жалобы слепого разработчика на Python.

Честно говоря, я думаю, что жалобы на размещение пробелов
скорее всего (извините за выражение) стервозная победа. Пробелы
отлично (я слепой и могу очень хорошо работать с python,
а также другие языки, ориентированные на пробелы, такие как F # и подобные).
Те, кто жалуется на пустое пространство, обычно являются теми, кто либо
без энтузиазма при мысли о программировании (что поднимает
вопрос о том, почему именно они проверяют это в первую очередь) или
те, кто даже не пробовал и кто только жалуется, чтобы жаловаться.
Я не хочу быть таким провокационным, но меня действительно бесит, когда я
вижу людей, жалующихся на это. Это просто не имеет абсолютно никакого смысла.
Я никогда не слышал о безголовой версии Годо. Возможно, это могло бы
использоваться для создания проектов и взаимодействия с движком? Тот
может быть полным решением наших проблем на данный момент. Где можно
Я нашел эту версию? (Или это в пакете Godot?)

24 мая 2018 г. Джордж Маркес, [email protected] , написал:

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

Я думаю, что самым простым способом (без взлома) было бы создать
сцены процедурно через сценарий. Вы можете сделать это во время выполнения или сделать
скрипт, который сохраняет сцены и ресурсы на диск, чтобы вы могли добавить их в
проект. Для первоначального создания шаблонов потребуется файл project.godot для
настройки проекта (сначала это может быть пустой файл, созданный ОС)
и основная сцена, которая запускается при запуске (которую также можно установить и сохранить через
сценарий). Может быть сложным в управлении, но это возможно.

Технически можно сделать скрипт, который запускается прямо из командной строки
и этот сценарий делает для вас весь проект Godot (по крайней мере, я не могу
придумайте что-нибудь, что могло бы предотвратить это). Затем вы можете запустить и экспортировать
игра из командной строки, а также. Вам нужно будет открыть проект в
редактор хотя бы один раз для импорта ассетов (и каждый раз, когда ассеты
изменить), но это можно решить, запустив безголовую версию Godot,
как некоторые люди делают для использования с серверами непрерывной интеграции.

Если файлы данных в основном текстовые, но неудобные для человека,
решением может быть DSL, предоставляющий упрощенный интерфейс для видов
описанных выше задач (позиционирование примитивов формы, прикрепление
звуки, добавляющие логику сущностям. и т.д.)

Формат текстового ресурса не так уж сложен для чтения, но, тем не менее,
проще просто использовать GDScript для создания материала для проекта, так как вы можете
использовать базовый движок для записи и чтения формата (избегая
проблемы с совместимостью).

К сожалению, GDScript — не лучший язык для слабовидящих.
люди, так как белое пространство важно. Я слышал жалобы от слепых
разработчик о Python из-за этого.

--
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/godotengine/godot/issues/14011#issuecomment -391900905

--
Подписано,
Этин Д. Пробст

@ethindp Я не буду спорить о том, что есть, а что нет, так как я сам не слепой, но попрошу вас смягчить. Люди имеют разный опыт и могут иметь веские причины, чтобы им было трудно работать, пока вы учились с этим работать. Человек, которого я знаю, зарабатывает на жизнь разработчиком, мне трудно поверить, что он «недостаточно старался» (хотя для меня это все еще подержанное, поэтому я не буду спорить об этом).

Я никогда не слышал о безголовой версии Годо. Возможно, это могло бы
использоваться для создания проектов и взаимодействия с движком? Тот
может быть полным решением наших проблем на данный момент. Где можно
Я нашел эту версию? (Или это в пакете Godot?)

Она называется платформой server и работает только на Linux. Он не распространяется (возможно, когда выйдет 3.1), поэтому вам нужно скомпилировать его самостоятельно, чтобы получить к нему доступ. Это обычный движок Godot, но у него есть фиктивные драйверы для видео, чтобы не требовалась видеокарта.

Я не уверен, сколько вы можете взаимодействовать с ним, вероятно, вы не можете сделать это вручную. Тем не менее, его можно использовать для запуска скриптов и импорта ассетов, так что с ним можно сделать проект, если делать все скриптами (по крайней мере, в теории).

Я повторю то, что говорит @ethindp в том, что отступ не должен быть проблемой. У большинства современных программ чтения с экрана есть настройки для автоматического произнесения отступов (например, «8 пробелов def hello_world():`, и я знаю много многообещающих слепых разработчиков Python.

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

$ godot-shell mygame.godot
Welcome to the Godot shell.

> new entity
Entity created with ID 0.
> add component 0 position
Component "position" added with ID 0.0.
> set component 0.0 [0, 0]
Component 0.0 set.
> save
Scene graph saved.
>

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

Будет ли такой рабочий процесс иметь смысл, если цель состоит в том, чтобы создать более упрощенную игру? Т.е. мне на самом деле все равно, как выглядят мои модели игрока/мира, помимо того, что они представляют собой простые формы, поэтому я могу мысленно моделировать их, прикреплять звуки, а затем иметь систему обнаружения столкновений, которая имеет какой-то смысл. Я также думаю, что CLI немного легче создавать и экспериментировать с ним, чем с полноценным DSL.

Я могу начать заниматься этим, если люди, которые знают о Годо больше, чем я, сочтут это жизнеспособным. Я искал хорошую проблему с интерфейсом CLI, в которую можно было бы вонзить свои зубы, и у меня есть несколько библиотек Rust, которые я хотел бы испытать. Задокументирован ли где-нибудь формат файла/данных?

@George Marques, я извиняюсь за свое грубое поведение... просто позволю этому
с моей груди. Потому что это действительно бесит меня и похоже на победу
больше, чем настоящая правда, понимаете?
@Нолан Дарилек , твоя идея может иметь смысл; можно ли будет закодировать
альтернативный интерфейс пользовательского интерфейса, возможно, с использованием чего-то вроде WXWidgets?
Если бы мы использовали WX, это решило бы все наши проблемы с доступностью за один раз.
(Лично мне так и не удалось полностью разобраться с WX....
слишком сложно для меня.... хех :)).

25 мая 2018 г. Нолан Дарилек, [email protected] , написал:

Я повторю то, что говорит @ethindp в том, что отступ не должен быть проблемой. Большинство
современные программы чтения с экрана имеют настройки для автоматического произнесения отступов (т.е.
"8 пробелов в определении hello_world():`, и я знаю много пролифичных слепых Python
Разработчики.

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

$ godot-shell mygame.godot
Welcome to the Godot shell.

> new entity
Entity created with ID 0.
> add component 0 position
Component "position" added with ID 0.0.
> set component 0.0 [0, 0]
Component 0.0 set.
> save
Scene graph saved.
>

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

Будет ли такой рабочий процесс иметь смысл, если цель состоит в том, чтобы создать более
упрощенная игра? Т.е. мне все равно, как выглядят мои модели игрока/мира.
например, помимо того, что они являются простыми формами, поэтому я могу мысленно смоделировать их, прикрепить
звуки, а затем иметь систему обнаружения столкновений, которая делает что-то вроде
смысл. Я также думаю, что CLI немного легче прототипировать и экспериментировать с ним.
чем полноценный DSL.

Я могу начать взламывать это, если люди, которые знают о Годо больше, чем я,
думаю, что это жизнеспособно. Искал хорошую проблему с интерфейсом CLI, чтобы потопить мой
зубами, и у меня есть несколько библиотек Rust, которые я хотел бы
шагов. Задокументирован ли где-нибудь формат файла/данных?

--
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/godotengine/godot/issues/14011#issuecomment -392111005

--
Подписано,
Этин Д. Пробст

Аналогично: WX. Если бы я собирался сделать графический интерфейс, я бы, вероятно, выбрал GTK.
так как я на Linux, но я никогда не садился изучать GTK или WX, и это
может показаться, что здесь слишком много переменных, с которыми можно играть.

Я думаю, что сначала я бы начал с CLI, который может запускать / останавливать рендеринг.
Годо обрабатывает и гонит эту безголовую версию. Если бы я сделал это в Rust,
Я бы, вероятно, построил реализацию struct и serde для подмножества
формат, который будет поддерживать интерфейс. Взяв это за отправную точку,
должно быть легко создать графический интерфейс позже или параллельно.

Это сработает, да; но как именно вы собираетесь это сделать в
ржавчина? Я думаю, ржавчина идеально подошла бы для этого, но из того, что я видел,
редактор движка по крайней мере написан на C++. На самом деле, кажется,
ядро тоже. Так, поскольку (согласно
https://doc.rust-lang.org/beta/nomicon/ffi.html) Rust не поддерживает интерфейс
с C++ нам нужно было бы создать интерфейс C. Это само по себе было бы
абсолютный кошмар. :)

25 мая 2018 г. Нолан Дарилек, [email protected] , написал:

Аналогично: WX. Если бы я собирался сделать графический интерфейс, я бы, вероятно, выбрал GTK.
так как я на Linux, но я никогда не садился изучать GTK или WX, и это
может показаться, что здесь слишком много переменных, с которыми можно играть.

Я думаю, что сначала я бы начал с CLI, который может запускать / останавливать рендеринг.
Годо обрабатывает и гонит эту безголовую версию. Если бы я сделал это в Rust,
Я бы, вероятно, построил реализацию struct и serde для подмножества
формат, который будет поддерживать интерфейс. Взяв это за отправную точку,
должно быть легко создать графический интерфейс позже или параллельно.

--
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/godotengine/godot/issues/14011#issuecomment -392121156

--
Подписано,
Этин Д. Пробст

Я думал о редактировании файлов напрямую, что кажется более выполнимым, если
вы выставляете более ограниченный интерфейс, который со временем разрастается (т.е. изначально
отображать только основные формы, твердые тела, звуки и т. д., а затем добавлять больше
время.) Я смотрю на формат, и кажется, что это в основном INI, то есть:

[node name="WallContainer" type="Node" parent="." index="0"]

editor/display_folded = true

Хотя я не знал, что названия разделов могут быть настолько произвольными. :) я
думаю, в спецификации INI нет ничего такого, что могло бы предотвратить это.

Итак, как MVP я бы хотел:

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

Я не хочу называть это маленьким подвигом, но если бы я мог понять
узлы, необходимые для реализации этого набора функций, затем создайте текстового пользователя
интерфейс для создания этой структуры, а затем вызов Godot
инструменты для экспорта/рендеринга, мы могли бы что-то найти. Есть много
типов узлов, но если они задокументированы каким-либо
машиночитаемым способом, возможно, в конечном итоге можно будет использовать какой-то
генератора кода Rust или написать макрос для репликации того же пользовательского интерфейса
масса ... но лучше выяснить, как выглядит этот пользовательский интерфейс, прежде чем
достигнув макроса, чтобы автоматически сгенерировать его. :)

Если я прав насчет того, что все основано на INI, я мог бы собрать
MVP PoC, чтобы увидеть, к чему это приведет. Чтобы было ясно, я не стремлюсь к
здесь используется редактор общего назначения, просто способ создания аудиоигр
без необходимости кодировать все это вручную и использовать
реальный игровой движок для кроссплатформенного экспорта.

Но каким бы веселым ни был этот мозговой штурм, мне нужно приступить к работе и закончить
неделя. Скоро выложу репозиторий и посмотрю, куда он пойдет. я
обычно предпочитаю GitLab из-за встроенной CI, но я мог бы
убежден остаться на GitHub, если люди против.

Формат файла описан (хотя бы частично) в документации: http://docs.godotengine.org/en/latest/development/file_formats/tscn.html

Однако создание совершенно нового инструмента для этого требует большой работы и довольно легко устаревает. По крайней мере, вы должны использовать GDNative в качестве моста (который представляет собой интерфейс C для движка C++), который даст доступ ко всей информации о классах и их свойствах. Как бы я ни ценил усилия, я думаю, вам сначала нужно немного понять, что может предложить Годо, чтобы не изобретать все колеса заново.

Если вы действительно хотите работать с Rust, вы можете попробовать привязки для GDNative (хотя я не могу подтвердить его стабильность): https://github.com/GodotNativeTools/godot-rust

Лично я бы попытался сделать что-то с самим ядром Godot (возможно, в виде модуля C++), так как тогда вы можете легко получить доступ ко всему API, включая все средства сохранения ресурсов и загрузчики, поэтому вам не нужно беспокоиться о форматах файлов. .

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

После этого вам нужен способ установить свойства отдельных узлов, включая ресурсы, которые используются для придания надлежащей функциональности (например, узлу CollisionShape2D требуется ресурс Shape2D, чтобы придать ему форму). Скрипты также являются ресурсами, поэтому их также можно настроить через этот интерфейс (хотя вы, возможно, захотите присвоить им особый статус). Это заменит инспектор в графическом интерфейсе.

Кроме того, я бы сделал команды как можно ближе к GDScript. Например, вы хотите создать спрайт, вы можете просто сделать Sprite.new() , что то же самое, что и в скрипте. Таким образом, кривая обучения для тех, кто уже привык к написанию сценариев, будет менее крутой.

Для аудио Godot использует проигрыватели и шины. Существуют проигрыватели для позиционного звука (как 2D, так и 3D) и обычный для непозиционного звука, которые также являются узлами дерева. Объемный звук тоже поддерживается (хотя я им никогда не пользовался). Для работы с шинами необходимо взаимодействовать с AudioServer, устанавливать громкость, отключать или солировать их, добавлять эффекты. Возможно, вы сможете использовать ресурс AudioBusLayout напрямую, но я не уверен, какая его часть доступна внешнему API. Эффекты — это просто ресурсы, поэтому их можно редактировать с помощью одного и того же интерфейса.

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

Эй, спасибо, это полезно. Я не особенно привязан к возне
непосредственно с файлами данных. Рад узнать, как это может
работа — большинство документов для начала работы, с которыми я сталкиваюсь, обучают, создавая
игры, и никто не предполагает, что вам сначала нужно будет создавать свои собственные инструменты. :)

Я не прикасался к C++ почти 2 десятилетия, так что, скорее всего, останусь
Rust и иметь дело с менее полным API или проблемами с файлами, если я столкнусь с любым
нестабильность. Поддерживает ли gdnative чтение/запись проекта, сцены и
другие файлы напрямую? Или он предназначен для поддержки написания игр на C и
вызов в двигатель? Я сделал краткий поиск по репозиторию Rust для
"проект" и ничего не нашел. Примеры кажутся сосредоточенными на
создание игр напрямую. Если вы не возражаете дать мне точку входа для
где я бы начал создавать проект и заполнять его программно, я бы
прочитайте об этом и переместите дальнейшую работу в мое собственное репо.

Еще раз спасибо за юмор. :)

GDNative предназначен для создания игр, по существу заменяющих сценарии. Но, как я уже говорил, со скриптами можно делать практически все, и GDNative использует тот же API.

Привет,

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

В данном случае это просто карта для проекта под названием audioquake, но это может быть примером. PD: Не пытайтесь построить это, это может не сработать.

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

Ваше здоровье,

Формат звуковых карт землетрясений очень ограничен. Мне лично это не нравится.

25 мая 2018 г. Франсиско Р. Дель Ройо на адрес электронной почты github.com написал:

Привет,

Для сцены или подобных и сложных объектов вы можете использовать такой формат
файл .

В данном случае это просто карта для проекта под названием audioquake, но это
может быть примером. PD: Не пытайтесь построить это, это может не сработать.

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

Ваше здоровье,

--
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/godotengine/godot/issues/14011#issuecomment-392214077

--
Подписано,
Этин Д. Пробст

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

Так что я думаю, что мне нужна серия "Годо с нуля", которая предполагает, что вы
не могу/не хочу использовать редактор, подобно тому, как вы это делаете
написание игры с помощью pygame или другой высокоуровневой библиотеки. Я представляю однажды
Я понял, как создать файл .project, который просто запускает
скрипт, а может скрипт, который просто открывает окно и крутит куб или
что-то, я могу применить это вверх. Я сомневаюсь, что такая вещь существует, так что
может быть, я попробую это сам и блог процесс. Тогда, возможно, я построю
Инструмент прототипирования CLI позже, как только я узнаю, что я мог бы захотеть прототипировать
без кода.

Знаете... Интересно, а можно ли как-то сделать двигатель не только
движок с редактором и прочим, но с библиотекой тоже? Мол, тебе дано
библиотеки C++ (статические или динамические библиотеки) и могут создать вашу игру
как вам угодно, используя Godot для всего игрового движка (т.е.
аудио и прочее). Если бы это было возможно, мы могли бы отказаться от редактора
полностью. Таким образом, вы можете добавлять активы в виде, скажем, файлов .caf, а затем, в
во время выполнения, вы скомпилируете их в памяти как скомпилированные файлы данных активов (мы
можно просто назвать их CADF). Итак, ваша игра будет выглядеть при запуске:

//...
// Компилируем активы
godot::assets::LoadAll({актив, актив, актив}); // загружаем каждый ассет по отдельности
или
Godot::Assets::LoadAllAssetsFrom("assets"); // загружаем все активы в
один раз из папки.
// Компилируем все ресурсы
auto assets = Godot::Assets::GetAllLoadedAssets();
логический успех = Godot::Assets::Cadf::CompileAllAssets(assets);
если (успех) {
// скомпилированные активы
} еще {
// ошибка
}

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

25 мая 2018 г. Нолан Дарилек, [email protected] , написал:

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

Так что я думаю, что мне нужна серия "Годо с нуля", которая предполагает, что вы
не могу/не хочу использовать редактор, подобно тому, как вы это делаете
написание игры с помощью pygame или другой высокоуровневой библиотеки. Я представляю однажды
Я понял, как создать файл .project, который просто запускает
скрипт, а может скрипт, который просто открывает окно и крутит куб или
что-то, я могу применить это вверх. Я сомневаюсь, что такая вещь существует, так что
может быть, я попробую это сам и блог процесс. Тогда, возможно, я построю
Инструмент прототипирования CLI позже, как только я узнаю, что я мог бы захотеть прототипировать
без кода.

--
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/godotengine/godot/issues/14011#issuecomment-392224709

--
Подписано,
Этин Д. Пробст

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

Вам не нужен графический интерфейс для запуска игр. По сути, редактор просто создает еще один процесс Godot с аргументами для запуска игры (в том числе со всеми опциями отладки). Запустить игру не проблема: вы можете просто запустить Godot из каталога проекта без аргументов, по умолчанию запускается проект.

Редактор сам по себе в значительной степени является «игрой» Godot. Он использует доступные узлы и расширяет их. Что касается импорта, это не то, что вам нужен графический интерфейс, вам просто нужны инструменты импорта, которые поставляются с редактором. По сути, вы просто помещаете все активы в папку проекта (в любой структуре, которая вам нравится), и когда вы открываете редактор, он все импортирует.

«Импорт» в данном случае означает сохранение метаданных (если вы хотите зациклить и обрезать звук, применить фильтр к изображению и т. д.), а иногда и преобразование в формат, который понимает и может использовать Godot (например, импорт модели в сетку Godot). ). Процесс импорта может быть выполнен только с помощью инструментов сборки (т.е. редактора), даже если это безголовая версия.

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

Точно так же, как редактор — это просто игра, вы можете создать свою собственную «игру», которая на самом деле является инструментом для создания игр. Я имею в виду, что вы даже можете создать сценарий, который расширяет MainLoop или SceneTree и запускать его напрямую через терминал с помощью:

$ godot -s my_script.gd

Проблема в том, что вам нужен настоящий инструмент командной строки, Godot не сделает его легким. Даже при запуске скрипта открывается окно, и все, что отправляется через stdin , будет игнорироваться.

Интересно, сможем ли мы как-то сделать двигатель не только
движок с редактором и прочим, но с библиотекой тоже? Мол, тебе дано
библиотеки C++ (статические или динамические библиотеки) и могут создать вашу игру
как вам угодно, используя Godot для всего игрового движка (т.е.
аудио и прочее).

Хотя редактор и движок созданы друг для друга, вы не полностью зависите от редактора при создании игры. Вы не можете разделить Godot на части, вам нужно взять весь пакет (хотя вы можете без проблем отключить большинство модулей). Поскольку редактор представляет собой игру Godot, технически возможно заменить код вашей собственной игрой. Это означало бы создание сцен на лету с помощью кода.

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

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

Извините за шум, ребята.

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

Я постепенно прихожу к выводу, что сам редактор может быть
стал доступным, по сути, создав мини-программу чтения с экрана в
GDScript. Дополнительным преимуществом этого является создание самих игровых интерфейсов.
доступный. Это тоже не беспрецедентно. Видеть
это
для подключаемого модуля специальных возможностей пользовательского интерфейса Unity.

Глядя на класс Control , мы видим, что есть открытые сигналы.
для фокуса введите/выйдите. Есть также сигналы для входных событий, которые я
Надежда включает стрелки вокруг полей ввода текста и тому подобное. это было бы
ограничено для универсального средства чтения с экрана на уровне ОС, но может работать только для
что-то специфичное для домена.

я что-то начал
здесь . К несчастью,
Я не могу добавить этот плагин в свой проект, потому что мне нужен недоступный
редактор, чтобы добавить плагин специальных возможностей. :) Если бы кто-нибудь мог добавить это
плагин к проекту и отправить PR с изменениями project.godot,
это было бы полезно. По сути, что я собираюсь сделать, это зацепить
node_added (или как там это называется) сигнал на SceneTree , перехват
любые узлы, которые происходят от Control и подключаются к их
Сигнал focus_entered . Оказавшись там, я начну добавлять логику для распечатки
презентационные сообщения для каждого типа узла, которые в конечном итоге будут передаваться по конвейеру
к еще не написанному TTS API. Пожалуйста, дайте мне знать, если есть
очевидные причины, почему это не сработает.

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

Надеюсь, мы сможем в конечном итоге перенести обсуждение в этот другой репозиторий и остановить
спамить эту тему. :)

Если я вас правильно понял, если бы это сработало, мы могли бы выбрать
включать его в наши игры или нет, верно? Можем ли мы как-нибудь добавить
его в редактор, но не в проекты, которые мы создаем, или удалить его
из проекта, но добавить его в редактор?

26.05.18 Нолан Дарилек (Nolan Darilek) [email protected] написал:

Извините за шум, ребята.

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

Я постепенно прихожу к выводу, что сам редактор может быть
стал доступным, по сути, создав мини-программу чтения с экрана в
GDScript. Дополнительным преимуществом этого является создание самих игровых интерфейсов.
доступный. Это тоже не беспрецедентно. Видеть
это
для подключаемого модуля специальных возможностей пользовательского интерфейса Unity.

Глядя на класс Control , мы видим, что есть открытые сигналы.
для фокуса введите/выйдите. Есть также сигналы для входных событий, которые я
Надежда включает стрелки вокруг полей ввода текста и тому подобное. это было бы
ограничено для универсального средства чтения с экрана на уровне ОС, но может работать только для
что-то специфичное для домена.

я что-то начал
здесь . К несчастью,
Я не могу добавить этот плагин в свой проект, потому что мне нужен недоступный
редактор, чтобы добавить плагин специальных возможностей. :) Если бы кто-нибудь мог добавить это
плагин к проекту и отправить PR с изменениями project.godot,
это было бы полезно. По сути, что я собираюсь сделать, это зацепить
node_added (или как там это называется) сигнал на SceneTree , перехват
любые узлы, которые происходят от Control и подключаются к их
Сигнал focus_entered . Оказавшись там, я начну добавлять логику для распечатки
презентационные сообщения для каждого типа узла, которые в конечном итоге будут передаваться по конвейеру
к еще не написанному TTS API. Пожалуйста, дайте мне знать, если есть
очевидные причины, почему это не сработает.

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

Надеюсь, мы сможем в конечном итоге перенести обсуждение в этот другой репозиторий и остановить
спамить эту тему. :)

--
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/godotengine/godot/issues/14011#issuecomment-392255752

--
Подписано,
Этин Д. Пробст

Я не знаю.

Я разобрался с форматом добавления плагина в project.godot
файл. Теперь у меня есть функция, которая должна добавлять
обработчики focus_entered/mouse_entered для каждого Control и печатает
сообщение, когда они имеют фокус. К сожалению, я на самом деле не получаю
любое из этих событий, и я не уверен, как получить фактический узел, который
породил их.

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

Хорошо, вот где я после некоторого периодического взлома в праздничные выходные:

1. Репозиторий перемещен
   здесь . Идентификатор
   скорее работайте над этим под моим потенциальным имиджем компании по разработке игр,
   но я буду выпускать плагин под лицензией MIT, если он пойдет
   в любом месте, поэтому сотрудничество приветствуется.
2. Теоретически я создаю классы с кодом, ориентированным на специальные возможности.
   всякий раз, когда элемент управления добавляется в дерево.
3. В IRC сказали, что поведение табуляции/Shift-Tab уже определено в
   Пользовательский интерфейс, но когда редактор запускается, ничего не фокусируется, поэтому tab/shift-tab
   ничего не делайте, пока что-то не сфокусируется.
4. Я пытаюсь установить первоначальный фокус, и, похоже, я делаю это с помощью
   какой-то случайный виджет LineEdit, но tab/shift-tab, кажется, не перемещает
   фокус. Это может быть связано с тем, что они захватываются элементом управления LineEdit.
5. Установка начального фокуса на что-то еще, кажется, не работает - на
   по крайней мере, не согласно моему обратному вызову focus_entered .

У меня с этим проблемы, потому что я новичок в движке, но я
приближаясь к нему с направления, которое большинство новичков не принимают. :) Если
кто-нибудь может помочь мне решить эту головоломку с начальной фокусировкой, я думаю, что смогу
много быстрого прогресса. Как только я смогу использовать tab/shift-tab для навигации между
элементы управления, я могу посмотреть, какие свойства предоставляет каждое из них, и начать создавать
доступная презентация для них. Я также рад сообщить о проблемах
против самого двигателя - я просто не знаю, какое конкретное поведение
попроси еще.

Спасибо.

Вероятно, вам нужно установить focus_mode элемента управления. Я считаю, что по умолчанию фокус не принимается, за исключением тех, которые в нем нуждаются (например, элементы управления текстом и кнопками). Вам также может понадобиться установить фокус соседей, я не уверен, насколько хорошо TAB работает без него (и работает ли он вообще).

Спасибо. Я только начал ковыряться с FOCUS_MODE_ALL. С этим я
может вызвать grab_focus для ранее не сфокусированных элементов.

Про соседей читал
http://docs.godotengine.org/en/3.0/classes/class_control.html :

Если пользователь нажмет Tab, Godot переместит фокус на ближайший узел
сначала вправо, потом в низ. Если пользователь нажмет Shift+Tab,
Годо посмотрит слева от узла, затем над ним.

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

Если у вас есть минутка, не могли бы вы запустить редактор в новом
проект, может быть, с пустым проектом.godot просто чтобы сохранить вещи
аналогично, а посмотреть при каких условиях tab/shift-tab работают в редакторе?
Я думаю, что человек, который помогал тестировать вещи в IRC, возможно, создал свой
собственный макет, тогда как то, что я хочу сделать, это проверить вещи непосредственно в
редактор. Если табуляция/Shift-Tab не работают, значит, у меня есть конкретная ошибка для файла.
Текущее убеждение, в соответствии с которым я работаю, заключается в том, что они не работают.
изначально, но сделайте это после того, как элемент будет нажат.

И, что интересно, когда я отслеживаю focus_exited, я получаю событие
когда я нажимаю вкладку. К сожалению, я никогда не получаю еще один focus_entered, поэтому
как только мой фокус покидает элемент управления, он никогда не возвращается к нему.

Спасибо за вашу помощь.

http://docs.godotengine.org/en/3.0/classes/class_nodepath.html#class-nodepath

Если у вас есть минутка, не могли бы вы запустить редактор в новом
проект, может быть, с пустым проектом.godot просто чтобы сохранить вещи
аналогично, а посмотреть при каких условиях tab/shift-tab работают в редакторе?

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

Спасибо. Эта проблема немного выходит из-под контроля. я собираюсь подать
другой касается идей мозгового штурма вокруг фокуса редактора.

Не знаю, что делать, я подал # 19230, но особой активности не было. Я также написал на форуме, и мне посоветовали зарегистрировать проблему. Думаете, куда обратиться за помощью в следующий раз? Я не вижу, действительно ли мой аддон устанавливает фокус, перемещает ли его Tab/Shift-tab, если да, то почему я получаю событие focus_exited при каждом нажатии клавиши, даже если это не клавиша навигации. Я не хочу раздражать, но я чувствую, что мог бы добиться значительного прогресса, если бы мне понадобилось 10 минут помощи от опытного разработчика Godot. Думал, что я подниму эту проблему и найду # 19230, у которого есть более целенаправленный (без каламбура) список вопросов.

Спасибо.

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

• tab/shift-tab вокруг редактора, получая обратную связь о том, какой элемент управления имеет фокус. В настоящее время имеет полуинтеллектуальное представление Button и LineEdit . Скоро будет больше.
• Стрелка влево/вправо в элементах управления LineEdit, получающая обратную связь о том, какой символ находится в фокусе. Дополнительная поддержка LineEdit появится, как только я увижу, как быстро обрабатываются PR. Я только что отправил один, добавив сигнал caret_moved .

Помогите приветствовать, хотя имейте в виду, что для этого дополнения теперь требуется версия Godot с неслитными PR. В частности, см. https://gitlab.com/lightsoutgames/godot-accessibility/issues/1 для контрольного списка всех отправленных PR и их статуса слияния.

Если вы хотите помочь, но не хотите наступать на пятки, отличным способом сделать это будет создание модуля TTS. Прямо сейчас этот аддон просто выводит на консоль. Я бы хотел такой API:

TTS.speak("hello, world.", interrupt = True)
TTS.stop() # Interrupts speech if in progress
TTS.rate = 200 # We'd need to coordinate some sort of rate algorithm between engines.

Все более сложное, например, голоса, можно подождать. Если кто-то захочет помочь и создаст такой API, возможно, я смогу заставить его работать под Linux и Android. В противном случае я доберусь до этого в конце концов, хотя программа чтения с экрана имеет для меня приоритет.

Если вы можете рассказать мне, как вы внедряете новые API-интерфейсы GDScript, я могу
реализовать это хотя бы для окон.

12.06.18 Нолан Дарилек, [email protected] , написал:

Просто хотел, чтобы люди знали, что эторепозиторий делает
быстрый прогресс. Теперь я могу:

• tab/shift-tab вокруг редактора, получая обратную связь о том, какой элемент управления
  фокус. В настоящее время имеет полуинтеллектуальное представление Button и
  LineEdit . Скоро будет больше.
• Стрелка влево/вправо в элементах управления LineEdit, получение обратной связи о том, какие
  персонаж имеет фокус. Дополнительная поддержка LineEdit появится, как только я увижу, как
  быстро обрабатываются PR. Я только что отправил один, добавив caret_moved
  сигнал.

Помогите приветствовать, хотя имейте в виду, что для этого дополнения теперь требуется версия
Godot с неслитными PR. В частности, см.
https://gitlab.com/lightsoutgames/godot-accessibility/issues/1 для
контрольный список всех отправленных PR и статус их слияния.

Если вы хотите помочь, но не хотите наступать на пальцы ног, отличный способ сделать это
так будет строить модуль TTS. Прямо сейчас этот аддон просто печатает на
консоль. Я бы хотел такой API:

TTS.speak("hello, world.", interrupt = True)
TTS.stop() # Interrupts speech if in progress
TTS.rate = 200 # We'd need to coordinate some sort of rate algorithm between
engines.

Все более сложное, например, голоса, можно подождать. Если кто-то хочет
в помощь и создаю такой API, возможно, я смогу заставить его работать под линуксом и
Андроид. В противном случае я доберусь до этого в конце концов, хотя программа чтения с экрана
имеет для меня приоритет.

--
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/godotengine/godot/issues/14011#issuecomment -396575401

--
Подписано,
Этин Д. Пробст

Я не знаю. Я слепой и тоже всему этому учусь, так что если я учусь
как построить модуль TTS, тогда я не создаю программу чтения с экрана
модуль. :) Я доберусь до этого в конце концов, но мои руки заняты
продвигаю GDScript, насколько могу, а затем настраиваю движок, когда не могу
получить что-то из GDScript. Весь этот процесс очень похож на то, когда
Я начал создавать программу для чтения с экрана Android. я не знал что такое
возможно, только начал халтурить на вещи, и только толком сообразил
за то, чем я занимался несколько месяцев.

И я предполагаю, что вам понадобится GDNative, если GDScript не предлагает
какая-то ФФИ. Я думаю, вы бы создали модуль C/C++, который вызывает
голосовых API и экспортирует функции в GDScript. Тогда я бы взял это
модуль и заставить его работать на Linux/Android с помощью Speech-dispatcher и
Родной TTS для Android. Я полагаю, я мог бы также сделать веб-сайт, используя
TTS-API Javascript. Если GDScript предлагает FFI для C/C++, сделайте
дай мне знать.

Спасибо!

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

12.06.18 Нолан Дарилек, [email protected] , написал:

Я не знаю. Я слепой и тоже всему этому учусь, так что если я учусь
как построить модуль TTS, тогда я не создаю программу чтения с экрана
модуль. :) Я доберусь до этого в конце концов, но мои руки заняты
продвигаю GDScript, насколько могу, а затем настраиваю движок, когда не могу
получить что-то из GDScript. Весь этот процесс очень похож на то, когда
Я начал создавать программу для чтения с экрана Android. я не знал что такое
возможно, только начал халтурить на вещи, и только толком сообразил
за то, чем я занимался несколько месяцев.

И я предполагаю, что вам понадобится GDNative, если GDScript не предлагает
какая-то ФФИ. Я думаю, вы бы создали модуль C/C++, который вызывает
голосовых API и экспортирует функции в GDScript. Тогда я бы взял это
модуль и заставить его работать на Linux/Android с помощью Speech-dispatcher и
Родной TTS для Android. Я полагаю, я мог бы также сделать веб-сайт, используя
TTS-API Javascript. Если GDScript предлагает FFI для C/C++, сделайте
дай мне знать.

Спасибо!

--
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/godotengine/godot/issues/14011#issuecomment -396669298

--
Подписано,
Этин Д. Пробст

Это выглядит почти идеально. Дайте мне знать, если у вас есть модуль GDNative
работает для этого. Если нет, через месяц сделаю что-нибудь для линукса
или так, возможно.

Если вы не хотите делать его в виде модуля (что требует перекомпиляции всего движка), единственный способ получить доступ к внешним библиотекам — использовать GDNative. Вы не можете сделать FFI с GDScript.

Я просто добавлю его к глобальным функциям GDScript. Это здорово?

12.06.18 г. Джордж Маркес, [email protected] , написал:

Если вы не хотите делать его как модуль (что требует перекомпиляции
весь движок), единственный способ получить доступ к внешним библиотекам — использовать GDNative.
Вы не можете сделать FFI с GDScript.

--
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/godotengine/godot/issues/14011#issuecomment -396736512

--
Подписано,
Этин Д. Пробст

Я думаю, что было бы лучше, если бы это был статический класс с членами. То есть:

TTS.speak("Hello, world", interrupt = True)
TTS.stop()

По крайней мере, так делают другие модули.

Быстрый поиск в Google показывает хороший учебник по GDNative с
пример проекта с использованием scons. Если вы начнете оттуда, я смогу
возьмите это и добавьте поддержку диспетчера речи. Не знаю, как добавить, скажем,
JS для взаимодействия с WebSpeech API, но по одному.

Ну дерьмо. Я уже зафиксировал и загрузил его в свою вилку репозитория.
как часть GDScript. Если вы посетите https://github.com/ethindp/godot,
вы можете видеть, как я это сделал. Я знаю, я вышел за рамки нормы, но Толк,
даже в C/C++ это не библиотека на основе классов. Так что прямо сейчас (я думаю)
вы можете вызвать его так:

tts_load()
tts_output("Hi", false);
tts_unload()

Чтобы это работало с программой чтения с экрана, вам понадобятся дополнительные
файлы (вместе с программой чтения с экрана):

• JAWS, Window Eyes, ZoomText, Доступ к системе: Ничего, работает через COM.
• NVDA: NVDAControllerClient32.dll и NVDAControllerClient64.dll
  (https://www.dropbox.com/s/7txp6iyi65sx12z/nvdaControllerClient32.dll?dl=1
  и https://www.dropbox.com/s/y0pdyxhos31hv9n/nvdaControllerClient64.dll?dl=1)
• Программы чтения с экрана Dolphin: Dolapi32.dll
  (https://www.dropbox.com/s/m04mpzi7z6bfu5i/dolapi32.dll?dl=1)
• Microsoft Speech API (MSSAPI/SAPI): sapi32.dll и sapi64.dll
  (https://www.dropbox.com/s/7czg0rt9ht9yloq/SAAPI32.dll?dl=1 и
  https://www.dropbox.com/s/e2fxek89p6muz2h/SAAPI64.dll?dl=1)
  Кроме того, вы можете скачать их все здесь:
  https://www.dropbox.com/sh/aatj7myhczyxs5u/AAA6K5aAZWis9uAF4CsNz_-Za?dl=1.
  Я не проверял это, я просто включил это. Извините, если это было плохо
  идея или нет. :) Я не уверен, как мы получим
  tts_speak/tts_output/tts_braille для работы, так как для них требуется файл wchar_t.
  Это экспортирует следующие функции:
  tts_load(): Инициализирует Tolk, загружая и инициализируя экран
  драйверы считывателя и установка текущего драйвера скринридера, при условии
  активна хотя бы одна из поддерживаемых программ чтения с экрана. Также
  инициализирует COM, если он еще не был инициализирован при вызове
  нить. Вызов этой функции более одного раза только инициализирует COM.
  Вы должны вызвать эту функцию перед использованием следующих функций. Использовать
  tts_is_loaded, чтобы определить, был ли инициализирован Tolk.
  tts_is_loaded(): Проверяет, был ли Толк инициализирован. Возвращает истину, если
  Толк был инициализирован, в противном случае false.
  tts_unload(): завершает Tolk, завершая и выгружая экран.
  драйверы считывателя и очистку текущего драйвера скринридера, при условии
  один был установлен. Также деинициализирует COM в вызывающем потоке. Вызов
  эта функция более одного раза только деинициализирует COM. Вам следует
  не используйте функции ниже, если эта функция была вызвана.
  tts_try_sapi (bool): указывает, следует ли использовать Microsoft Speech API (SAPI).
  в процессе автоматического обнаружения программы чтения с экрана. По умолчанию не
  включить SAPI. Драйвер SAPI будет использовать системный синтезатор по умолчанию,
  голос и звуковая карта. Эта функция запускает программу чтения с экрана.
  Процесс обнаружения, если это необходимо. Для лучшей производительности вы должны позвонить
  эту функцию перед вызовом tts_load(). Параметры: trySAPI: ли
  или не включать SAPI в автоопределение.
  tts_prefer_sapi(bool): если автоопределение для SAPI включено
  через tts_try_sapi(), устанавливает, должен ли SAPI быть помещен первым (true) или
  последний (false) в списке обнаружения средств чтения с экрана. Ставить это последним
  по умолчанию и подходит для использования SAPI в качестве запасного варианта. положить
  во-первых, это хорошо для обеспечения использования SAPI, даже когда программа чтения с экрана
  работает, но имейте в виду, что программы чтения с экрана будут по-прежнему использоваться, если
  SAPI недоступен. Эта функция запускает программу чтения с экрана.
  Процесс обнаружения, если это необходимо. Для лучшей производительности вы должны позвонить
  эту функцию перед вызовом tts_load. Параметры: предпочтение SAPI:
  следует ли предпочесть SAPI драйверам чтения с экрана в
  автоопределение.
  tts_detect_screen_reader(): возвращает общее имя для текущего
  активный драйвер чтения с экрана, если он установлен. Если ничего не установлено, пытается
  определить текущую активную программу чтения с экрана, прежде чем искать имя.
  Если программа чтения с экрана не активна, возвращается NULL. Обратите внимание, что драйверы
  жестко закодировать общее имя, оно не запрашивается программой чтения с экрана
  сам. Вы должны вызвать tts_load один раз перед использованием этой функции.
  tts_has_speech(): Проверяет, поддерживает ли текущий драйвер чтения с экрана
  речевой вывод, если он установлен. Если ничего не установлено, пытается обнаружить
  в настоящее время активное средство чтения с экрана перед тестированием поддержки речи. Ты
  следует вызвать tts_load один раз перед использованием этой функции.
  tts_has_braille(): Проверяет, поддерживает ли текущий драйвер чтения с экрана
  вывод Брайля, если он установлен. Если ничего не установлено, пытается обнаружить
  активное в данный момент средство чтения с экрана перед проверкой поддержки шрифта Брайля. Ты
  следует вызвать tts_load один раз перед использованием этой функции.
  tts_output(string, bool): выводит текст через текущий экран
  драйвер считывателя, если он установлен. Если ничего не установлено или если он столкнулся с
  ошибка, пытается обнаружить текущую активную программу чтения с экрана перед
  вывод текста. Это предпочтительная функция для отправки
  текст в программу чтения с экрана, потому что она использует все поддерживаемые выходные данные
  методы (речь и/или шрифт Брайля в зависимости от текущей программы чтения с экрана)
  Водитель). Вы должны вызвать tts_load один раз перед использованием этой функции.
  Эта функция является асинхронной. Параметры: str: текст для вывода.
  прерывание: следует ли сначала отменить любую предыдущую речь.
  tts_speak(string): произносит текст через текущую программу чтения с экрана.
  драйвер, если он установлен и поддерживает вывод речи. Если ничего не установлено или если
  возникла ошибка, пытается определить текущий активный экран
  читатель, прежде чем говорить текст. Используйте эту функцию, только если вы
  особенно нужно говорить текст через текущую программу чтения с экрана
  без брайлинга. Не все драйверы программ чтения с экрана могут поддерживать
  этот функционал. Поэтому по возможности используйте tts_output. Ты
  следует вызвать tts_load один раз перед использованием этой функции. Эта функция
  асинхронный. Параметры: str: текст для произнесения. прерывание: либо
  не отменять любую предыдущую речь.
  tts_braille(string): текст Брайля через текущую программу чтения с экрана
  драйвер, если он установлен и поддерживает вывод по Брайлю. Если ничего не установлено или
  если он обнаружил ошибку, пытается обнаружить текущий активный
  экранный ридер перед тем, как печатать данный текст по Брайлю. Используйте эту функцию только
  если вам специально нужно вывести текст Брайля через текущий экран
  читатель, не говоря об этом. Не все драйверы программ чтения с экрана могут
  поддерживать этот функционал. Поэтому используйте tts_output всякий раз, когда
  возможный. Вы должны вызвать tts_load один раз перед использованием этой функции.
  Параметры: str: текст в шрифт Брайля.
  tts_is_speaking(): Проверяет, связана ли программа чтения с экрана с
  текущий драйвер чтения с экрана говорит, если он установлен и поддерживает
  запрос информации о состоянии. Если ничего не установлено, пытается обнаружить
  в настоящее время активное средство чтения с экрана, прежде чем проверять, говорит ли оно. Ты
  следует вызвать tts_load один раз перед использованием этой функции. Возвращает истину, если
  текст озвучивается программой чтения с экрана, в противном случае — false.
  tts_silence(): отключает программу чтения с экрана, связанную с текущим
  драйвер чтения с экрана, если он установлен и поддерживает вывод речи. Если
  ни один не установлен или, если он обнаружил ошибку, пытается обнаружить
  в настоящее время активное средство чтения с экрана, прежде чем отключить его. Вы должны позвонить
  tts_load один раз перед использованием этой функции. Возвращает true в случае успеха,
  ложно в противном случае.
  Наслаждаться! :)

12.06.18 Нолан Дарилек, [email protected] , написал:

Я думаю, что было бы лучше, если бы это был статический класс с членами. То есть:

TTS.speak("Hello, world", interrupt = True)
TTS.stop()

По крайней мере, так делают другие модули.

Быстрый поиск в Google показывает хороший учебник по GDNative с
пример проекта с использованием scons. Если вы начнете оттуда, я смогу
возьмите это и добавьте поддержку диспетчера речи. Не знаю, как добавить, скажем,
JS для взаимодействия с WebSpeech API, но по одному.

--
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/godotengine/godot/issues/14011#issuecomment-396753704

--
Подписано,
Этин Д. Пробст

Сам Tolk не обязательно должен быть основан на классах, чтобы экспортировать интерфейс на основе классов. Взгляните на учебник для чистого примера создания класса GDScript на основе C. Первый поиск в Google по запросу «gdnative tutorial».

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

Однако хорошее начало.

Ах, черт с ним, я просто собираюсь ударить его. :) Кроме этого
будет в Rust, вот и все. Похоже, есть Толк Ржавчина
привязка. Я не могу сделать порт Windows, поэтому вам придется заполнить эти
болванки сами.

Есть ржавчина от Толка? Где? Не нашел... поищу. :)

12.06.18 Нолан Дарилек, [email protected] , написал:

Ах, черт с ним, я просто собираюсь ударить его. :) Кроме этого
будет в Rust, вот и все. Похоже, есть Толк Ржавчина
привязка. Я не могу сделать порт Windows, поэтому вам придется заполнить эти
болванки сами.

--
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/godotengine/godot/issues/14011#issuecomment -396768693

--
Подписано,
Этин Д. Пробст

Это первое попадание в гугле, когда я ввожу слово «ржавчина». Кроме того, это
появляется на cargo search tolk ..

В любом случае, еще один вопрос Годо. Если у меня есть модуль GDNative, который
предоставляет GDScript класс TTS , как я могу гарантировать, что класс
глобально доступны? Я создал свой файл .gdnlib, но учебник на
http://docs.godotengine.org/en/3.0/tutorials/plugins/gdnative/gdnative-c-example.html
просто показывает графику при создании файла .gdns. Что означает .gdns
файл выглядит так, что я могу создать его вручную? Похоже, я загружаю класс
в через preload , а не просто сделать его доступным по всему миру, в том, что
точный?

Спасибо.

если у меня есть модуль GDNative, который предоставляет GDScript класс TTS , как я могу обеспечить глобальную доступность этого класса?

Возможно, его можно добавить как синглтон автозагрузки. На самом деле, в редакторе есть место для синглтонов GDNative, поэтому, возможно, есть еще лучший способ их создания. Однако об этом нет документации, и я понятия не имею, как это работает.

просто показывает графику при создании файла .gdns. Что означает .gdns
файл выглядит так, что я могу создать его вручную?

После выполнения инструкций он генерирует такой файл:

[gd_resource type="NativeScript" load_steps=2 format=2]

[ext_resource path="res://bin/gdexample.gdnlib" type="GDNativeLibrary" id=1]

[resource]

resource_name = "gdexample"
class_name = "gdexample"
library = ExtResource( 1 )

Обновление:

Я подумываю либо полностью отказаться от проекта, либо разветвить движок. В качестве контекста скажу, что я потратил 4-5 лет на создание Spiel, довольно крупной программы чтения с экрана для Android, в то время, когда API-интерфейсы специальных возможностей Android были не очень хороши. Мне нравится думать, что я немного осведомлен о том, что делает хороший API специальных возможностей, а также чувствителен к потребностям базовой ОС и пользовательскому опыту. В конце концов, я отказался от проекта по большей части из-за того, что его было сложно построить на основе неполного API специальных возможностей, и мне пришлось прибегать к хакерским хакам, чтобы сделать Spiel полезным.

Годо примерно такой же. На самом деле сигналов пользовательского интерфейса достаточно для достаточно сложного API специальных возможностей. Но мне нужно еще несколько, чтобы в аддоне специальных возможностей было достаточно информации. В частности, #19522 упростил бы задачу, но меня попросили реорганизовать его в код, специфичный для аддона. Сейчас #19814 также обсуждается. Я понимаю, что не хочу добавлять миллион сигналов, но я стараюсь учитывать это. Все мои изменения должны оставаться ограниченными слоем пользовательского интерфейса, и я не могу себе представить, чтобы это имело большой эффект, если только кто-то не играет в игру с набором текста, где требуется каждая последняя бит производительности для рендеринга EditLine в 120 FPS. :) Тем не менее, ядро ​​потребует некоторых дополнений, если люди действительно хотят, чтобы это произошло.

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

Похоже, #19840 может обсуждаться на предстоящем собрании по связям с общественностью. Если люди действительно хотят, чтобы Godot стал более доступным, я был бы признателен за то, чтобы на этом собрании было больше сторонников, чем я. Я даже не знаю, когда состоится указанная встреча, и не будет ли она конфликтовать с реальными рабочими встречами, которые мне нужно посетить для $dayjobs. :) Я просто понимаю, что не могу сделать это в одиночку, и мне понадобится помощь заинтересованных сторон.

Спасибо.

@ndarilek Если вы все еще заинтересованы в работе над этим, я хотел бы помочь.

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

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

• Где находится вкладка входной карты в разделе «Проект» -> «Настройки проекта»? Я вижу дерево опций - конфигурация, запуск, редактор, плагины редактора и т. д., но нет карты ввода. Я пытаюсь получить список имен действий, чтобы увидеть, что доступно. Мне интересно, находится ли это в той части интерфейса, которую я еще не сделал доступной, хотя я удивлен, что ее нет в дереве категорий.
• Могу ли я программно вызвать действие? В частности, в некоторых учебниках мне предлагается щелкнуть узел правой кнопкой мыши, но я не вижу способа сделать это с клавиатуры. Я хотел бы привязать клавишу меню к щелчку правой кнопкой мыши, чтобы выполнить некоторые шаги, описанные в этом руководстве .
• В качестве альтернативы, есть ли удобный для клавиатуры способ щелкнуть правой кнопкой мыши и список сочетаний клавиш в любом месте? Может быть, моя проблема в том, что Меню работает, но мне не хватает доступа к движку, чтобы знать это.

И @malcolmhoward , если ваше предложение о сотрудничестве все еще остается открытым год спустя, я не согласен. Я готов дать этому еще один шанс. Я вижу, вы пытались объединить поддержку Фестиваля. Если вы заинтересованы в продолжении этой работы, у меня есть плагин TTS на основе Rust, который в настоящее время поддерживает Speech Dispatcher под Linux и Tolk под Windows. Хотелось бы разнообразить эту поддержку (и протестировать поддержку Windows Tolk в этом отношении, поскольку Linux — моя основная платформа).

Спасибо.

Не обращайте внимания на мой первый вопрос выше. Я обнаружил и добавил доступную поддержку для TabContainer . Теперь я могу найти и выбрать вкладку Input Map. Все еще немного смущен тем, есть ли удобный для клавиатуры способ щелкнуть правой кнопкой мыши узлы в дереве сцены, или, если это не удается, как я могу вызвать это действие программно.

Было бы очень полезно, если бы я мог организовать сеанс демонстрации экрана с кем-то, кто знаком с разработкой Godot, чтобы он помог мне выполнить несколько первоначальных задач. Вещи, которые я хотел бы выполнить:

• Создание начального пустого игрового поля.
• Создание узла/сцены игрока и добавление его в область.
• Изучение того, как получить доступ к свойствам каждого узла/сцены, чтобы я мог устанавливать их без перетаскивания.
• Учимся прикреплять скрипты к своим узлам. У меня достаточно доступных настроек, и мне удалось настроить внешний редактор на gedit, поэтому, как только я понял, как прикрепить скрипт к узлу и отредактировать этот скрипт, я вернулся в свой доступный редактор. для этой задачи.

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

Спасибо.

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

Я как-то разобрался, как добавлять скрипты. Я решил начать строить
простая игра вместе с плагином специальных возможностей, чтобы соавторы
иметь более широкую общую систему координат для обсуждения вопросов доступности.
Я создал узел Player Area2D, и множество вкладок выявило
кнопка для добавления скрипта, которая открывала Gedit и была очень полезной
опыт. Прогресс!

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

Я создал экземпляр Player как дочерний элемент сцены, и я могу видеть игрока
и его кнопка для очистки скрипта. Но я понятия не имею, почему я не могу добавить
script только на корневой узел основной сцены.

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

Кроме того, справедливо ли будет сказать, что многие из этих кнопок в редакторе находятся в
панели инструментов? Я пытаюсь придумать более простой способ навигации
через все эти кнопки через клавиатуру, т.к.
табуляция / Shift-табуляция через них все немного медленная. Если многие в
панели инструментов, я могу реализовать табуляцию между панелями инструментов и
стрелка вправо/влево между компонентами панели инструментов.

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

Хорошо, больше прогресса. Я предоставил речи больше свойств на Tree . я
думал, что стрелки вверх/вниз перемещаются по дереву, но они
кажется, выбирает элементы. Я думаю, что происходит то, что у меня есть
выбрано несколько узлов сцены, поэтому кнопка добавления сценария не
появляться. Я могу как бы привести дерево в состояние, в котором есть только один элемент.
выбираются путем развертывания/свертывания элементов, после чего появляется скрипт добавления
появится кнопка Main.

Может кто-нибудь объяснить логику нажатия стрелок вверх/вниз в
дерево? Я предположил, что он перешел к одному элементу и выбрал все, что было
сосредоточены, но в чем-то вроде дерева сцен, которое, как я предполагаю, поддерживает
множественный выбор, мне интересно, ведет ли он себя по-другому? Есть ли
различные нажатия клавиш для навигации по дереву и выбора одного
элемент, или есть что-то, чтобы отменить выбор текущего элемента?

Спасибо.

Много хорошего прогресса вчера. У инспектора по имуществу есть некоторые
складные вещи, у которых нет фокусируемости клавиатуры или интерактивности,
но я раскопал их и применил черную магию с имитацией мыши
кликов, так что теперь я могу разворачивать/сворачивать свойства узла с помощью клавиатуры.
Деревья доступны примерно на 80%, хотя многоколонные деревья с разными
контроль по-прежнему представляет собой проблему.

Говоря об этом, я запутался в том, как работает редактор входных карт. я вижу
ряд действий, представленных элементами дерева. Дерево имеет 3 столбца: 0 =
действие, 1 = мертвая зона. Расширение каждого типа действия, кажется, раскрывает
детей для типов устройств, и я предполагаю, что отсюда я могу настроить
действия, но я смущен многими вещами:

* Что такое немаркированный третий столбец в этом дереве?

* Допустим, я добавляю действие "speak_coordinates". Я получаю предмет дерева за
действие без детей. Как добавить ребенка для сопоставления ключей? Может быть
это связано с некоторым взаимодействием с этим немаркированным третьим столбцом, который
Я еще не поддерживаю доступным образом?

* Что такое немаркированная TextureButton на этом экране? Нажав на нее
кажется, закрывает настройки, но это не кнопка с надписью «Закрыть», поэтому
может это другое действие? Сохранить/Отменить?

Спасибо за любую помощь.

@ndarilek Третий столбец редактора карты ввода содержит кнопку для добавления нового события ввода к существующему действию (рядом с действиями в дереве оно представлено символом «плюс»). Для существующих входных событий он содержит две кнопки: одну для редактирования входного события (левая, обозначенная пером), и одну для его удаления (правая, обозначенная крестиком).

TextureButton, который закрывает настройки, скорее всего, является значком закрытия WindowDialog (обозначен крестиком), он реализован здесь: https://github.com/godotengine/godot/blob/750f8d4926edb14269d9f6a117c5a9fd4765373a/scene/gui/dialogs.cpp#L338 - L345

Настройки проекта — это модальное диалоговое окно, отсюда и использование WindowDialog.

Спасибо, это полезно. Теперь я выставляю количество кнопок в столбце
объявлений на Tree и получаю объявление о том, что
есть кнопки.

Спасибо, что указали мне, где находится Close TextureButton
реализовано - мне трудно отслеживать некоторые из них в
source, и я пытаюсь установить метаполя для некоторых из них, поэтому мой плагин
могут предоставлять доступные описания/метки.

Я только что добавил метод get_button_tooltip(...) к TreeItem , чтобы выставить
всплывающие подсказки кнопок, так как кнопки в столбцах возвращаются только как
Texture объектов и нет возможности получить соответствующую всплывающую подсказку
через это. Надеюсь, это не нежелательное слияние, когда я отправлю
больший PR для этого плагина.

Еще раз спасибо.

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

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

То есть я добавляю действие "speak_coordinates", к которому я хочу привязать
"с". Если появится это диалоговое окно, и я нажму «c», попробуйте перейти на вкладку
Кнопка ОК, делает это:

а) привязать «с» к действию, игнорируя последующие нажатия клавиш?

б) привязать «c», затем «tab», когда я пытаюсь перейти к кнопке «ОК»?

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

Спасибо.

@ndarilek Когда вы нажимаете кнопку, которая добавляет новое событие ввода, она представляет раскрывающийся список с четырьмя вариантами:

• Ключ
• Кнопка радости
• Ось радости
• Кнопка мыши

Опция Key отображает модальное диалоговое окно (поверх существующего), в котором пользователю предлагается нажать клавишу (или клавишу с модификаторами, например, Ctrl+K). Если пользователь нажмет другую клавишу перед подтверждением, она заменит клавишу, которая в данный момент была определена в диалоговом окне подтверждения. Это диалоговое окно будет продолжать прослушивать события клавиатуры, пока пользователь не подтвердит, нажав «ОК», или не отменит действие, нажав «Отмена» в диалоговом окне. Поскольку это диалоговое окно прослушивает все клавиши (включая «специальные» клавиши, такие как Tab), навигация с помощью клавиатуры невозможна. Это связано с тем, что диалоговое окно заменит текущий выбор на Tab. Точно так же клавиша Escape не может использоваться для отмены диалога. Мы должны стремиться улучшить удобство использования этого диалога :slightly_smiling_face:

Напротив, другие типы (Joy Button, Joy Axis и Mouse Button) не прослушивают события, вместо этого они просто используют выпадающие меню в модальных диалогах.

Понятно. Поэтому я думаю, что в целях доступности я произвольно
решить, что первая клавиша в этом диалоговом окне «выигрывает», когда подключаемый модуль
работает, поэтому последующие нажатия Tab/Enter/Escape делают то, что должны
к. Я обнаружил, что перенаправление фокуса на кнопку OK в этом
диалоговое окно приводит к тому, что любая клавиша, используемая для запуска кнопки, не сохраняется.
Т.е. если я использую пробел, чтобы вызвать диалоговое окно, затем Enter, чтобы
нажмите кнопку ОК, пробел сохраняется как ключ, а не Enter.

Итак, вот поведение, которое я сейчас наблюдаю, и мне интересно,
есть мысли что с этим делать. Я запускаю кнопку, которая открывает
диалоговое окно при нажатии «ui_accept», поэтому пробел или Enter по умолчанию. Когда я
вызвать диалоговое окно, какую бы клавишу я ни использовал, чтобы вызвать диалоговое окно
является набором ключей для команды. Итак, как указано выше, если я использую пробел для запуска
ui_accept и Enter, чтобы закрыть диалоговое окно, для моей команды установлено значение «Пробел».
Аналогичным образом, если я вызову появление диалогового окна с помощью Enter и использую пробел для
нажмите кнопку OK, команда будет привязана к Enter.

Я думаю, что происходит то, что мое пресс-мероприятие посылает сигнал
нажмите кнопку, которая, в свою очередь, откроет диалоговое окно прослушивания клавиш
Мероприятия. Затем этот диалог получает освобождение клавиши, которую я только что нажал
(т.е. пробел) и устанавливает его как команду. Интересно, есть ли у кого-нибудь
мысли о том, как обойти это? Я пробовал is_action_released
вместо is_action_pressed я думал, что он обнаружит
отпускание нажатого действия как-то и триггер на этом, но не кости.

Вот мой код. По сути, он идентифицирует выбранную кнопку как
щелкнул, затем посылает сигнал. Есть ли способ сделать узел
принять все событие, включая его выпуск? Или есть что-то
здесь происходит что-то еще, из-за чего выпуск события достигает диалогового окна
и запустить захват? Предложения приветствуются - я изучаю GDScript по
прыгать в глубокий конец, так что не имейте понятия:

var button_index


func tree_input(event):
     var item = node.get_selected()
     var column
     if item:
         for i in range(node.columns):
             if item.is_selected(i):
                 column = i
                 break

     # button_index is set to 0 in an item_selected callback based on 
get_button_count(...) != 0

     if item and column and button_index != null:
         if event.is_action_pressed("ui_accept"):
             node.accept_event() # How can I accept the corresponding 
release of the press here so it doesn't leak through?
             return node.emit_signal("button_pressed", item, column, 
button_index + 1)
         var new_button_index = button_index
         if event.is_action_pressed("ui_home"):
             node.accept_event()
             new_button_index += 1
             if new_button_index >= item.get_button_count(column):
                 new_button_index = 0
         elif event.is_action_pressed("ui_end"):
             node.accept_event()
             new_button_index -= 1
             if new_button_index < 0:
                 new_button_index = item.get_button_count(column) - 1
         if new_button_index != button_index:
             button_index = new_button_index
             var tooltip = item.get_button_tooltip(column, button_index)
             var text = ""
             if tooltip:
                 text += tooltip + ": "
             text += "button"
             tts.speak(text, true)

Просто подумал о чем-то @ndarilek. Помимо того факта, что AFAICT нет возможности «щелкнуть правой кнопкой мыши» с клавиатуры, некоторые команды клавиатуры (например, Del) зависят от того, что сфокусировано / выбрано. Ваша комбинация Godot/экранного ридера говорит вам об этом, или нам нужна аннотация (вероятно, в «мета»)?

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

И я имитирую щелчки левой кнопкой мыши, так что я, вероятно, перейду к
щелкните правой кнопкой мыши в ближайшее время. Хотя, найдя список горячих клавиш
в редакторе вместе с кнопками New Script/Scene это не так
сразу критично.

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

Это чертовски халтурно, так что если у кого-то есть лучшее решение, то я весь
уши. :) Мне также может понадобиться добавить в этот диалог неясное мета-свойство
в движке, чтобы плагин специальных возможностей знал, что это особый случай, и
объявить инструкции по нажатию клавиши.

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

Поэтому, естественно, у меня есть еще один вопрос. :) Есть ли сигнал, что я могу
подключите мой EditorPlugin , чтобы определить, когда игра, которую я запускаю, завершается?
При первоначальном запуске редактора я должен установить начальный фокус пользовательского интерфейса, чтобы
что Tab/Shift-Tab может даже перемещаться, иначе нет текущего фокуса
чтобы найти следующий/предыдущий фокус. Но когда запущенная игра выходит,
фокус не установлен, и я не отследил сигнал, который нужно поймать, чтобы обработать
тот. Предположительно что-то столь же важное, как запуск отдельного
дерево игры/сцены в редакторе не исчезает без отправки
сигнал.

Уф, а дорога все дальше и дальше...

Я не думаю, что что-то есть, но вы могли бы как-то использовать WM_NOTIFICATION_QUIT в своем игровом сценарии? Отправить логическую переменную в EditorPlugin? (Хотя я использовал WM_NOTIFICATION_QUIT для автосохранения при выходе, я почти не использовал EditorPlugin)

Хм, а что такое WM_NOTIFICATION_QUIT?

А что происходит визуально в окне редактора, когда я запускаю игру? Я знаю
игра появляется в отдельном окне, но ничего не делает в редакторе
изменять? Интересно, переключается ли он на другой экран или что-то в этом роде. я
увидеть это в моей консоли:

Выполняется: /home/nolan/src/godot/bin/godot.x11.tools.64 --path
/home/nolan/Проекты/godot-accessibility --remote-debug 127.0.0.1:6007
--allow_focus_steal_pid 32312 --позиция 328 225

что подсказывает мне, что, возможно, сам интерфейс изменится на
то, что еще недоступно даже после закрытия игры.

NOTIFICATION_WM_QUIT_REQUEST — идентификатор уведомления (определен в MainLoop).

Например, вы можете реагировать на уведомления в GDScript, написав функцию _notification(what) :

func _notification(what):
    if what == NOTIFICATION_WM_QUIT_REQUEST:
        print("User requested the project to quit")

Вы также можете сделать так, чтобы Godot не закрывался автоматически, когда пользователь нажимает кнопку «Закрыть» или нажимает Alt+F4. См. раздел « Обработка запросов на выход» в документации.

Чтобы ответить на ваш последний вопрос, панель вывода редактора откроется автоматически при запуске игры по умолчанию. Это поведение можно отключить, сняв флажок « Выполнить» > «Вывод» > «Всегда открывать вывод при воспроизведении» в настройках редактора. Он останется открытым после того, как вы закроете игру, если вы не отметите « Выполнить»> «Вывод»> «Всегда закрывать вывод при остановке » в настройках редактора.

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

Привет,

Как я могу проверить это под окнами?

Спасибо,

Тестирование Windows сейчас немного рискованно. Сначала нужно скомпилировать
godot-tts , который
Основан на Rust и требует настройки Rust's Tolk.библиотека и запуск экрана
читатель. Сопровождающий Tolk-rs не активно работает над проектом
больше, но я предложил взять его на себя и сделать его немного проще
работать с. Я просто провожу большую часть своего времени в Linux, так что Windows не
приоритет. Вам также нужна моя вилкадвигатель .

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

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

Спасибо,

Ладно, нативная разработка в моем случае не сильная сторона...

попробую построить сам.

Во всяком случае, я получил это, когда пытался построить godot-tts

   Compiling gdnative-sys v0.5.0
error: failed to run custom build command for `gdnative-sys v0.5.0`

Caused by:
  process didn't exit successfully: `C:\Users\Franci\source\repos\godot-tts\target\debug\build\gdnative-sys-01490563416791dd\build-script-build` (exit code: 101)
--- stderr
thread 'main' panicked at 'Unable to find libclang: "couldn\'t find any of [\'clang.dll\', \'libclang.dll\'], set the LIBCLANG_PATH environment variable to a path where one of these files can be found (skipped: [])"', src\libcore\result.rs:999:5

Так что я застрял...

Хм, у меня в EditorPlugin есть следующее:

func _notification(what):
     print("Notified: %s" % what)
     if what == MainLoop.NOTIFICATION_WM_QUIT_REQUEST:
         print("User requested the project to quit")

Это печатает что-то, но никогда не «Пользователь запросил выход из проекта»,
даже когда я выхожу из самого редактора. Мысли?

Кроме того, я провел эксперимент, в котором я сделал каждый узел
клавиатура/мышь, думая, что фокус должен где-то приземлиться
из которого я мог вкладку. Затем я начал печатать на focus_exited и
обнаружил, что фокус удаляется с того места, где он последний раз находился в игре
запуск. Так что на самом деле это не приземление где-то не в фокусе. Это
вообще нигде.

На данный момент у меня есть обходной путь, в котором я устанавливаю первоначальный фокус на экране.
изменить, если ничего не сфокусировано, поэтому нажатие F1-F3 заставит все работать
снова. Возможно ли, чтобы EditorPlugin перехватил ввод графического интерфейса? я
см. метод `forward_gui_input_ (или что-то подобное, документы не открыты
сейчас), но это не задокументировано. Если это так, я могу захватить ввод и установить фокус
где-то, если фокус не установлен.

Спасибо.

Спрашивал на форуме, но ответа не получил. Эта работа зависит
в плагине GDNative TTS, который я написал. Могу ли я сделать плагины GDNative доступными
для использования другими, и если да, то как? Я не имею в виду, как кросс-компилировать и
настроить CI, а лучше:

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

* У меня есть const TTS = preload("res://godot-tts/godot_tts.gdns") в моем
сценарий. Это предполагает установленное местоположение для моей библиотеки плагинов. Точно так же
сами библиотеки имеют пути res://, которые предполагают расположение в
res://godot-tts/target/debug. Я не хочу навязывать макет проекта
кто-нибудь, поэтому мне интересно, может ли какой-либо из этих путей быть относительным?

Спасибо.

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

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

• У меня есть const TTS = preload("res://godot-tts/godot_tts.gdns") в моем
  сценарий. Это предполагает установленное местоположение для моей библиотеки плагинов. Точно так же
  сами библиотеки имеют пути res://, которые предполагают расположение в
  res://godot-tts/target/debug. Я не хочу навязывать макет проекта
  кто-нибудь, поэтому мне интересно, может ли какой-либо из этих путей быть относительным?

Я не думаю, что вы можете заставить GDNativeLibrary использовать относительные пути (если только вы не создадите ее во время выполнения, но это звучит довольно сложно). Тем не менее, надстройки часто находятся в res://addons , что является стандартным расположением, используемым плагинами редактора. Поэтому вы можете попросить пользователей размещать все в res://addons/godot-tts , что должно хорошо работать с большинством проектов.

Ах, хорошо, так что в основном создайте выпуск GitHub или аналогичный, содержащий мои
предварительно созданные двоичные файлы/документы/что угодно, и отправьте все настроенное на
рекомендовать и использовать res://addons/godot-tts? Круто, спасибо, полезно!

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

К сожалению, я немного борюсь с созданием некоторых свойств.
более доступным. В частности, я добавил поддержку клавиатуры в
развернуть/свернуть EditorInspectorSection, после чего я могу перейти через
любые содержащиеся свойства. Чего я не могу сделать, так это получить ярлыки для
некоторые -- например, EditorPropertyVector2.

Я предполагаю, что где-то есть текстовые метки для них? они не сделаны
доступны как экземпляры Label . Может кто-нибудь указать мне, где
отображаются эти метки свойств? Я царапаю дерево, пытаясь найти
их, но я подхожу пустой.

Огромное спасибо.

EditorPropertyVector2 отображает два поля (EditorSpinSlider), помеченные как «x» и «y». Эти EditorSpinSliders по умолчанию являются дочерними элементами VBoxContainer или HBoxContainer, если в настройках редактора включен параметр interface/inspector/horizontal_vector2_editing .

Первоначальный рендеринг выполняется здесь: https://github.com/godotengine/godot/blob/24e1039eb6fe32115e8d1a62a84965e9be19a2ed/editor/editor_properties.cpp#L1150 -L1181.

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

Извините, если я что-то пропустил — я нашел EditorPropertyVector2
реализация некоторое время назад, но кажется, что она отображает пользовательский интерфейс только для
установка свойства, а не связанной с ним метки.

Спасибо.

Ярлыки (а также все, что упоминал @Calinou ) отображаются в инспекторе.

Сверху инспектор содержит следующее:
инспектор | Узел (это две вкладки)
[имя узла, который вы проверяете, например, «маркер»]
текстовое поле для фильтрации свойств
[Заголовок переменных сценария (необязательно) со стрелкой для свертывания]
[здесь отображаются любые экспортированные переменные скрипта]
[класс узла, который вы проверяете, например Node2D]
[Преобразовать заголовок — с крошечной стрелкой, позволяющей свернуть раздел]
Метка позиции — отображается слева от двух полей, которые создает EditorPropertyVector2.
Степень поворота - то же самое, слева от одного поля ввода текста
Метка шкалы - такая же, как и позиция, два поля помечены x, y так же, как и позиция.
[Заголовок индекса Z]
[суперкласс узла, который вы проверяете, например CanvasItem в случае Node2D]
[Заголовок видимости, со стрелкой...]
[Видимая метка рядом с флажком]
[Два селектора цвета]
[Показать за родительской меткой рядом с флажком]
[Слой-маска — сложный контейнер, полный крошечных коробочек]
[Заголовок материала, со стрелкой...]
[Метка узла] — это суперсуперкласс, от которого наследуется каждый узел, поэтому он всегда внизу
Этот раздел всегда содержит два заголовка, оба со стрелками для складывания:
[Пауза — выпадающее меню]
[Сценарий — раскрывающийся список, позволяющий выбрать сценарий]

Например, для 3D-узлов инспектор может быть очень сложным — это был всего лишь простой пример Node2D, который я описал, я думаю, вам лучше всего как-то сделать ярлык для быстрого доступа к наиболее важным вещам — разделу «Преобразование» и «Пауза/скрипт» в внизу, и вы всегда можете легко перейти к экспортированным свойствам, поскольку они находятся вверху.

PS Если выбрать вкладку Node вверху, откроется совершенно другое меню вместо Инспектора.

ППС. Если вы отфильтруете свойства, у вас будут только метки, например Node2D, и только один заголовок (со стрелкой для свертывания), который содержит нужное вам свойство. Я только что проверил, и вы можете фильтровать встроенное свойство, такое как позиция, так что это может сэкономить вам много времени :)

О, я понял это. Забыли, что родители узла не обязательно
его суперклассы. В этом случае у меня была простая проверка на node is EditorProperty , и я говорил ее метку, если она была установлена. В этом случае
LineEdit для позиции компонентов X/Y в дереве предков узла
EditorPropertyVector2 , который, в свою очередь, имеет метку.

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

Похоже, что метки свойств рисуются не с помощью узлов, а с использованием низкоуровневых вызовов draw_string() . (Попробуйте найти draw_string в editor/editor_inspector.cpp .) Я не уверен, как их можно сделать доступными, или потребуется ли превратить их в узлы.

Для дальнейшего использования здесь приведены некоторые дополнительные сведения о EditorInspector/EditorProperty. Я написал это перед поиском экземпляров draw_string() , так что последующее может быть излишним.

Я мало играл с кодом инспектора редактора, но, насколько я понимаю, свойства редактора добавляются в структуру AddedEditor при их регистрации: https://github.com/godotengine/godot/blob/24e1039eb6fe32115e8d1a62a84965e9be19a2ed/editor/ редактор_инспектора.cpp#L865 -L873

Эта структура AddedEditor имеет строку label , которая будет передана экземплярным узлам EditorProperty: https://github.com/godotengine/godot/blob/24e1039eb6fe32115e8d1a62a84965e9be19a2ed/editor/editor_spector.cpp#L1320 -L1367.

Наконец, эта строка label используется для заполнения узла Label с помощью EditorProperty::set_label_reference , но только если горизонтальное редактирование Vector2 отключено: https://github.com/godotengine/godot/blob/24e1039eb6fe32115e8d1a62a84965e9be19a2ed/ редактор/editor_properties.cpp#L1178

В противном случае для размещения редактора под меткой будет использоваться EditorProperty::set_bottom_editor : https://github.com/godotengine/godot/blob/24e1039eb6fe32115e8d1a62a84965e9be19a2ed/editor/editor_properties.cpp#L1158 .

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

Я также исправил некоторые проблемы с вычислением текста для элементов PopupMenu . Этот
имеет дополнительное преимущество, которым на самом деле являются многие элементы, которые, как я думал, не были помечены.

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

Попасть туда...

Я обещаю не использовать эту тему для этой цели, но где
лучшее место, где можно получить помощь по общим вопросам, касающимся движка?

Несколько дней назад я обнаружил, что двумерные аудиопотоки, похоже, предполагают
что они панорамированы/ослаблены относительно центра экрана и не берут
с учетом ротации. Это не то, что я хочу от аудиоигры сверху вниз
которые будут иметь ротацию, возможно закадровые источники звука слышны в
расстояние и т. д. Документы окна просмотра, кажется, указывают, что 3-D звук
возможно даже для 2-D узлов, но я не уверен, могу ли я просто добавить 3-D
транслировать плеер на 2-D узлы и синхронизировать их позиции, если мне нужно
синхронизируйте позиции X и Z вручную с 2-DX/Y и закрепите поток
Y на 0, если мне нужно выяснить, как использовать орто-камеру и визуализировать
3D объекты в 2D и т.д.

я попросил
это
и попробовал опубликовать
это
на Reddit, но на первый нет ответов, а второй не виден.
Я не знаю, получу ли я Reddit, нужно ли мне одобрение и т. д.

В любом случае, я не хочу превращать этот вопрос в тему поддержки, но я
использовать Годо необычным образом, и это может оказаться невозможным даже
после выполнения всей этой работы. Я готов к этому - я решил дать
месяц, чтобы продвинуть это вперед и посмотреть, как далеко я продвинусь с этим, но частично
Чтобы добиться успеха здесь, нужно знать, действительно ли то, чего я хочу,
достижимо даже при доступности. И если я смогу создать аудиоигру
среда разработки, я буду собирать материалы, чтобы показать
другие, как это сделать, так что, надеюсь, мои знания могут помочь другим. Но я
с трудом получая ответы на эти нишевые вопросы, и что
кажется узким местом на этой неделе.

Из других новостей: я также работаю над автоматизацией сборок TTS для Windows.
плагин и собрал доступный начальный проект, сделав его
легко как продемонстрировать мою работу, так и создать в доступной среде. Больной
обновление, когда у меня есть бинарные сборки плагина TTS, доступные для загрузки.

Спасибо.

Добавление узла Listener2D было запрошено в https://github.com/godotengine/godot-proposals/issues/49. Это позволит вам настроить, откуда звук прослушивается в 2D-сцене, как это уже можно сделать в 3D с помощью узла Listener.

Я могу подтвердить, что сообщение Reddit отображается как удаленное, я не знаю, почему. Я утвердил его вручную, но, вероятно, он не появится на главной странице, так как был опубликован вчера. Попробуйте опубликовать его еще раз, пока все должно быть в порядке :)

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

Спасибо за ссылку на предложение.

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

Прогресс немного замедлился, пока я пытался сражаться с Appveyor, чтобы построить
плагин TTS под Windows. С тех пор я отказался от этого горячего беспорядка, и
вероятно, скоро подготовлю свою собственную виртуальную машину Windows и настрою
GitLab CI бегун. Если у кого-то есть запасная виртуальная машина Windows,
с этой целью, я был бы признателен.

Панели теперь можно сфокусировать. Это исправляет проблему прошлой недели, когда
игра в редакторе сломала фокус клавиатуры.

Я также немного переработал плагин TTS для маршрутизации вызовов через TTS.gd.
сценарий. На данный момент это отправляет все вызовы в родную библиотеку Rust, но
будущие версии могут отправлять вызовы в модуль Java/Kotlin на Android,
и Т. Д.

Я также немного работаю над своей первой игрой Godot, пространственной аудиосистемой.
версия астероидов. Отвлечение Appveyor на прошлой неделе убило прогресс
в этой области, но я надеюсь добраться до этого больше на этой неделе. Работа над
навигация, обтекание, говорящие координаты/курс и т.д.
взломать отсутствие 2-D пространственного звука, что, я думаю, я сделал, но
еще предстоит испытать.

@francipvb Вы пытались установить Clang/LLVM? На самом деле я пытаюсь собрать последнюю версию godot-tts под Windows и обнаруживаю, что мне, вероятно, нужно установить clang. Сборка работает под Appveyor, поэтому я подозреваю, что они установили ее там, и это может быть ваша недостающая часть.

Я могу попробовать это позже на этой неделе, но Godot не запускается на моей виртуальной машине Windows, поэтому, даже если это заработает, я буду ограничен в том, сколько тестов Windows я могу провести.

У меня есть доступный стартер , который устанавливает структуру каталогов, в которую вы можете скомпилировать godot-tts. Игнорируйте инструкции по загрузке сборки godot-tts с Appveyor. Я не могу понять, как объединить сборки Linux и Windows в один zip-архив, поэтому я отказываюсь от этого в пользу настройки собственного GitLab CI runner. Но поскольку в настоящее время я не могу запустить Godot под Windows, приоритет этой задачи на данный момент понижен.

Я могу попробовать это позже на этой неделе, но Godot не запускается на моей виртуальной машине Windows, поэтому, даже если это заработает, я буду ограничен в том, сколько тестов Windows я могу провести.

Вы должны иметь возможность установить программную реализацию OpenGL на виртуальной машине: https://github.com/pal1000/mesa-dist-win .

Godot будет работать медленно, но таким образом будут работать как рендереры GLES3, так и GLES2.

@francipvb Вы пытались установить Clang/LLVM? На самом деле я пытаюсь собрать последнюю версию godot-tts под Windows и обнаруживаю, что мне, вероятно, нужно установить clang. Сборка работает под Appveyor, поэтому я подозреваю, что они установили ее там, и это может быть ваша недостающая часть.

Я могу попробовать это позже на этой неделе, но Godot не запускается на моей виртуальной машине Windows, поэтому, даже если это заработает, я буду ограничен в том, сколько тестов Windows я могу провести.

У меня есть доступный стартер , который устанавливает структуру каталогов, в которую вы можете скомпилировать godot-tts. Игнорируйте инструкции по загрузке сборки godot-tts с Appveyor. Я не могу понять, как объединить сборки Linux и Windows в один zip-архив, поэтому я отказываюсь от этого в пользу настройки собственного GitLab CI runner. Но поскольку в настоящее время я не могу запустить Godot под Windows, приоритет этой задачи на данный момент понижен.

Я оставил это нетронутым, но я попробую.

Ваше здоровье,

Привет @ndarilek ,

Я отказался от этой попытки. Я установил набор инструментов LLVM, и это сработало.

Ваше здоровье,

Сладкий! Вы имеете в виду, что он скомпилирован, или он действительно разговаривает под Windows?
У меня еще не было возможности попробовать заставить программное обеспечение OpenGL работать.

Я думаю, что у меня есть реализация OpenGL (у меня есть графический процессор NVIDIA).

Я просто создаю вашу ветку godot.

Привет,

Как мне теперь связать эти две вещи?

Спасибо,

Обратите внимание, что я создал ветку с github.

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

Извините, я не знаю, где искать, потому что в репозитории godot-tts нет файла README.

Ваше здоровье,

О, извините, я думал, что вы видели
это .
Не следуйте инструкциям по загрузке godot-tts, так как они предполагают, что я
может заставить Appveyor работать. И последнее о потере внимания к игре.
бросить уже не правда.

Удачи, надеюсь, это работает под Windows.

Имея настоящую борьбу с всплывающими меню правой кнопкой мыши, которые я получаю, когда
щелчком по узлам дерева в редакторе.
Здесь
это код, с которым я работаю. В частности, иногда get_item_index
возвращает -1, и я не знаю, почему. Это делает это в значительной степени
невозможно получить какие-либо сведения о предмете PopupMenu , а методы
при этом, похоже, ожидается параметр idx , который, как я предполагаю, является индексом.

Глядя на источник, кажется, что -1 означает, что элемент не найден. Но я
передавая идентификатор, полученный id_focused , поэтому я не знаю, почему это
signal передаст мне идентификатор, который не найден.

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

Ой, извините, я думал, вы это видели. Не следуйте инструкциям по загрузке от godot-tts, так как они предполагали, что я смогу заставить работать Appveyor. И последняя фраза о потере внимания к выходу из игры уже не соответствует действительности. Удачи, надеюсь, это работает под Windows.

Судя по всему, это ссылка на частный репозиторий...

Спасибо,

Дох, исправлено, извините.

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

Я не могу воспроизвести 3D-звук и собрать этопример делать вещи
как можно проще, но это не работает. Мое намерение состоит в том, чтобы создать
единый трехмерный пространственный узел с грохотом аудиопотока и слушателем в виде
дети, то играйте в грохот. Это работает в 2D, но не в 3D. Я
здесь что-то не так?

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

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

Я выделил поддержку специальных возможностей в отдельный ScreenReader
узел, который теоретически можно добавить к любому SceneTree , чтобы сделать
внутриигровые интерфейсы доступны. Это делает мой плагин не только редактором
улучшение доступности, но эквивалент доступности Unity
плагин, который использовался во многих поставляемых играх. Конечно,
функциональность все еще отстает, но, насколько мне известно,
Инструментарий Unity пока недоступен, так что мы впереди в этом отношении.

Я не могу воспроизвести 3D-звук и собрал этот пример , чтобы сделать все как можно проще, но он не работает. Мое намерение состоит в том, чтобы создать единый трехмерный пространственный узел с грохотом аудиопотока и слушателем в качестве дочерних элементов, а затем воспроизвести грохот. Это работает в 2D, но не в 3D. Я делаю что-то не так здесь?

Вам нужно добавить 3D Camera в сцену. Затем вы можете поместить прослушиватель в качестве дочернего элемента камеры и переместить камеру или переместить прослушиватель напрямую. Это должно решить проблему...

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

Косяки еще есть, но работать с редактором Godot совершенно слепому разработчику пока можно.

Это приятно слышать, спасибо за вашу работу, чтобы сделать Godot более доступным.

А, я думал, слушателя было достаточно. Могу ли я добавить камеру и предотвратить
это от рендеринга, сохраняя при этом любое свойство, которое делает
слушатель работает? Я хочу иметь возможность визуализировать что- то в 2D, просто
не полноценная 3D сцена. Или я могу настроить 3D-камеру для рендеринга 2D
каким-то образом - может быть, дать ему ортогональную перспективу?

Спасибо, пролистал источники, пытаясь отследить это.

Ах, я думал, что слушателя было достаточно

Я думаю, что так и должно быть, это может быть ошибка, у меня мало знаний в этой области.

Могу ли я добавить камеру и предотвратить ее рендеринг, сохраняя при этом любое свойство, заставляющее работать прослушиватель?

Вы можете поместить все 3D-материалы в Viewport , и они не будут отображаться (не забудьте включить свойство listener).

Я хочу иметь возможность визуализировать что- то в 2D, но не полную 3D-сцену. Или я могу каким-то образом настроить 3D-камеру для рендеринга 2D — может быть, придать ей ортогональную перспективу?

Вы можете визуализировать как 3D в 2D (через ViewportContainer ), так и 2D в 3D через ( Mesh , Material , ViewportTexture ).
Здесь есть некоторая документация:
https://docs.godotengine.org/en/3.1/tutorials/viewports/viewports.html
и демонстрационные проекты здесь:
https://github.com/godotengine/godot-demo-projects
в viewport .

ОК, у меня играет стрим! Я уже прочитал много документов, и я
также немного ограничен моей неспособностью видеть, что на самом деле происходит
визуализировано, поэтому я надеюсь, что вы не возражаете против еще нескольких встроенных вопросов. я
спрашивать об этом в другом месте, но это единственное место, где я получаю
ответы, и я прошу прощения у всех, кто чувствует себя заспамленным, но я почти в
момент, когда я рассматриваю возможность найма консультанта Godot, чтобы помочь с
этот проект с открытым исходным кодом, которого я хотел бы избежать из-за ограниченных средств.
НО мои вопросы:

25.09.19 10:38 Фабио Алессандрелли написал:
>

Вы можете поместить все 3D-материалы в |Viewport| и это не будет отображаться
(не забудьте включить свойство слушателя).

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

* Создайте 2D-игру, как сейчас, позволяя рендерить ее на
область просмотра по умолчанию, которая создается.

* Создайте отдельный вьюпорт с камерой в качестве дочернего элемента и слушателем
как дитя камеры.

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

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

Еще раз спасибо.

Хорошо, столкнулся с еще одной странной проблемой, с которой мне нужна помощь. Если я добавлю Raycast2D
node, затем попытайтесь установить его свойство маски коллизий через редактор,
меню слоев всплывает, когда я нажимаю Enter на кнопке. Но нажатие
Вход на слой, похоже, не закрывает меню и не выбирает слой.
Enter отлично работает в других PopupMenus, что, по-видимому, и происходит.

Любые идеи, почему это может происходить? А если нет, может кто-нибудь пожалуйста
укажите мне, где это конкретное меню реализовано в движке, чтобы я
может расследовать? Поковырялся в редакторе/ но не сразу
очевидно, и я также не уверен, какие конкретные критерии предотвратят
некоторые узлы PopupMenu не отвечают на Enter. Может быть, что-то
работает над _gui_input и блокирует его?

Спасибо.

Хорошо, столкнулся с еще одной странной проблемой, с которой мне нужна помощь. Если я добавляю ноду Raycast2D, то пытаюсь задать через редактор его свойство маски коллизий, меню слоев выскакивает при нажатии Enter на кнопке. Но нажатие Enter на слое, похоже, не закрывает меню и не выбирает слой.

Извините за поздний ответ.
Да, в этом случае PopMenu не закрывается автоматически.
Вам нужно нажать Esc , чтобы закрыть его.
Идея состоит в том, что когда вы устанавливаете слой столкновения (который является полем битовой маски), вы можете захотеть установить более одного бита одновременно, чтобы всплывающее окно оставалось открытым.
Соответствующий код устанавливает для PopupMenu.hide_on_checkable_item_selection значение false.
Видеть:
https://docs.godotengine.org/en/3.1/classes/class_popupmenu.html#class -popupmenu-property-hide-on-checkable-item-selection

https://github.com/godotengine/godot/blob/master/editor/editor_properties.cpp#L799

https://github.com/godotengine/godot/blob/master/scene/gui/popup_menu.cpp#L1145

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

Достиг некоторого хорошего прогресса, хотя большая часть этого находится в моей игре с тех пор, как
Уровень доступности достаточно далеко продвинулся. Есть еще много чего
сделать, однако.

Следующий вопрос, есть ли способ перехватить и отфильтровать тачскрин?
взаимодействие до того, как оно достигнет Control s или других узлов? я бы хотел
начать работать над своего рода поддержкой сенсорного управления, как показано в
VoiceOver для iOS или TalkBack для Android, а также как реализовано в
Плагин доступности Unity. По сути, я хотел бы перехватывать касания
так что для его запуска требуется двойное нажатие на элемент управления, а обычное
касания экрана служат только для раскрытия интерфейса. Быстрое пролистывание
некоторые направления также работают как Tab/Shift-Tab. Я не знаю, нужно ли мне
переопределения области просмотра, какой-то пользовательский слой, который я могу использовать в качестве
фильтр и т. д. Я бы предпочел не менять поведение каждого элемента управления,
вместо этого просто фильтровать, какие взаимодействия достигают их таким образом, чтобы их можно было
включается и выключается во время игры.

Спасибо.

Следующий вопрос: есть ли способ перехватить и отфильтровать взаимодействие с сенсорным экраном до того, как оно достигнет Control s или других узлов?

Вы можете использовать Control._gui_input(event) в корневом элементе GUI или даже Node._input(event) (возможно, даже в корневом окне просмотра).
Затем вы можете использовать SceneTree.set_input_as_handled() или Viewport.set_input_as_handled() , чтобы заблокировать их после проверки типа ввода, например, event is InputEventScreenTouch .

Проверить:
Входной поток событий:
https://docs.godotengine.org/en/3.1/tutorials/inputs/inputevent.html

Метод _input в Node .
https://docs.godotengine.org/en/3.1/classes/class_node.html#class -node-method-input

Метод set_input_as_handled() в SceneTree .
https://docs.godotengine.org/en/3.1/classes/class_scenetree.html#class -scenetree-method-set-input-as-handled

_gui_input в Control
https://docs.godotengine.org/en/3.1/classes/class_control.html#class -control-method-gui-input

Спасибо, здесь есть на что посмотреть. Вот еще:

https://docs.godotengine.org/en/3.1/classes/class_itemlist.html#class -itemlist-method-select

«Примечание: этот метод не активирует сигнал выбора элемента». Почему
тот? Мне приходится переопределять некоторые операции с клавиатурой в виджетах, потому что
например, нажатие стрелки вниз на самом нижнем элементе дерева/списка приведет к
скиттер фокусируется на соседнем виджете, а не просто не продвигается
выбор. То же самое с ItemList . Я также должен реализовать свой собственный
логика выбора. Я столкнулся с одной странной проблемой в селекторе файлов,
где выбор элемента в списке не обновляет имя файла в
текстовое поле. В итоге мне нужно выбрать каталог, в котором находится файл,
затем введите имя файла в это поле.

Учитывая, что мне нужно реализовать свою собственную логику фокуса выбора, я
интересно, может ли тот факт, что select не запускает сигнал, быть
что вызывает это? И тут возникает вопрос, почему не select
запустить сигнал, указывающий, что элемент был выбран?

Спасибо.

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

У меня есть код, который пытается угадать метку для некоторых полей. Часть этого
Алгоритм включает в себя обход родителей узла, нахождение любого
экземпляров EditorProperty и возвращая их метки, если они есть. Этот
работает, если я запускаю свою игру в редакторе или через двоичный файл с
встроенный редактор. Он не работает с экспортированным двоичным файлом, потому что
EditorProperty не определяется в двоичных файлах без редактора. Вещи
Я пробовал:

if node.get_class() == "EditorProperty" не работает, потому что мне нужно
проверка is , а не только равенство классов, и я бы предпочел не проверять
равно ли имя класса любому потомку имени этого класса.

if Engine.is_editor_hint() не работает, потому что ошибочный код все еще
запускается в экспортированном двоичном файле.

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

Для справки, вот код, который я пытаюсь заставить работать:

func guess_label():
     var tokens = PoolStringArray([])
     var to_check = node
     while to_check:
         if Engine.is_editor_hint():
             print(to_check)
             if to_check is EditorProperty and to_check.label:
                 tokens.append(to_check.label)
             if (to_check is EditorProperty or to_check.get_class() == 
"EditorInspectorCategory") and to_check.get_tooltip_text():
                 tokens.append(to_check.get_tooltip_text())
             var label = tokens.join(": ")
             if label:
                 return label
         to_check = to_check.get_parent()

Спасибо.

@ndarilek ,

Решит ли эту проблему замена проверки is_class на проверку get_class ? Документы для этого метода здесь .

Ага, неплохо поработал. Спасибо! Вариант, который я рассматривал, имел бы
было намного грязнее.

Рад слышать это. Я вернулся и прочитал некоторые из этих сообщений, и это не
совершенно ясно, какие нерешенные вопросы и что было решено,
но вы упомянули, что есть некоторые трудности с выяснением того, что происходит
предоставлено. Мне нужен этот плагин для проекта, над которым я работаю, поэтому я открыт для
помощь везде, где вам нужен зрячий разработчик для тестирования или решения
странные причуды. Не стесняйтесь обращаться ко мне с тем, что вам нужно сделать или заполнить
трекер ошибок в ваших репозиториях gitlab с ошибками и запросами функций
нужна помощь, и я возьмусь за все, что, как я думаю, я могу справиться. Мой электронный адрес
Эллен.х. [email protected]

В понедельник, 14 октября 2019 г., 9:50 Нолан Дарилек, [email protected]
написал:

Ага, неплохо поработал. Спасибо! Вариант, который я рассматривал, имел бы
было намного грязнее.

—
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/godotengine/godot/issues/14011?email_source=notifications&email_token=AAOY262NSXUDGOMDFEF5NPTQOSPOXA5CNFSM4EG4X6EKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBFRGQQ4#issuecomment,12#issuecomment
или отписаться
https://github.com/notifications/unsubscribe-auth/AAOY264T3T7KWWSTBIIJUFLQOSPOXANCNFSM4EG4X6EA
.

Возможно, мы сможем закрыть это в ближайшее время, OTOH Я получил много ответов здесь, на которые IRC/форумы не помогли. Это правда снова. :) Надеюсь, я сохранил высокое отношение сигнал/шум, но когда мне нужна помощь с чем-то, это, как правило, выходит за рамки того, что я могу найти в учебнике или книге, и есть много опытных людей, которые следят за этой проблемой и помогают мне. построить эту поддержку.

Сделал много работы над этим за праздники. Мой плагин godot-tts теперь поддерживает Android и HTML 5, и я экспортировал доступные игры на обе платформы. Я также немного поработал над доступностью сенсорного экрана. На моем настольном компьютере с Linux интерфейсы теперь можно легко просматривать на моем сенсорном экране HDMI за 70 долларов. Простые прикосновения сообщают о касании элемента управления пользовательского интерфейса, двойное касание в любом месте экрана активирует последний выделенный элемент управления, а быстрое смахивание вправо/влево действует как Tab/Shift-Tab и перемещает фокус между элементами.

К сожалению, свайп вообще не работает на Android, и я был бы признателен за помощь в выяснении причин. Точнее, сами свайпы обнаруживаются просто отлично. Затем они вводят действия ui_focus_next или ui_focus_prev , используя такой код:

func press_and_release(action):
    var event = InputEventAction.new()
    event.action = action
    event.pressed = true
    get_tree().input_event(event)
    event.pressed = false
    get_tree().input_event(event)

func swipe_right():
    press_and_release("ui_focus_next")

func swipe_left():
    press_and_release("ui_focus_prev")

И эти действия не запускаются на Android, хотя функции swipe_right / swipe_left работают нормально. Любая идея, почему это может быть?

Я подключил клавиатуру к своему телефону, и Tab по крайней мере запускает ui_focus_next . Таким образом, действие работает с точки зрения распознавания, но, поскольку оно сгенерировано с помощью приведенного выше кода, оно, похоже, не срабатывает. Я также пробовал Input.action_press и Input.action_release , но из-за этого все перестало работать даже на рабочем столе. Очевидно, что мой код делает то, чего не делает Input.action_press , но этого недостаточно, чтобы сделать Android счастливым. Я попытался найти, где события были преобразованы в действия, но мне не ясно, зависят ли эти пути от платформы. Очевидно, что они должны быть, поскольку Linux/X11 и Android расходятся.

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

Заменено https://github.com/godotengine/godot-proposals/issues/983.

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