Godot: إضافة إمكانية الوصول للمطورين المكفوفين الذين يستخدمون برامج قراءة الشاشة

سيكون هذا بالتأكيد تحسينًا مرحبًا به ، لكن يمكنني القول بالفعل أنه من المحتمل أن يستغرق التنفيذ بعض الوقت ، هذا إذا تم تنفيذه على الإطلاق. يستخدم محرر Godot مجموعة أدوات واجهة المستخدم الرسومية الخاصة به ، والتي هي نفسها المستخدمة في الألعاب ، وهي مستقلة تمامًا عن مجموعات الأدوات الأصلية أو تلك التي تعمل عبر الأنظمة الأساسية مثل Qt أو GTK + ، والتي سيكون لها دعم جيد لقارئ الشاشة.

لذا لكي يعمل هذا في Godot ، يجب أن يتم تنفيذه من البداية في عناصر التحكم الأساسية. لا أعرف مدى صعوبة هذا ، لكن ربما ليس تافهًا.

لقد فكرت بالفعل في هذا ولكني لا أعرف حتى من أين أبدأ. محرر Godot مرئي للغاية ، فأنت تفعل كل شيء تقريبًا باستخدام الماوس. سنحتاج إلى شخص يعاني من إعاقة بصرية ليقدم لنا المشورة حول هذا الأمر ويوجهنا في هذه المهمة ، وينصحنا بما هو مطلوب بالفعل وكيف يجب أن يتصرف. بدون مستخدم فعلي لتقديم ملاحظات ، تكون في الغالب لعبة تخمين لتنفيذ ذلك.

سأكون سعيدا لإرشادكم في إضافة هذا يا رفاق. أنا نفسي أعمى. :) على الأقل ، يمكنني أن أحيلكم يا رفاق إلى الأطر (يتبادر إلى الذهن MSAA و UIA كاحتمالات ، على الرغم من أن UIA هي الأفضل بالنسبة لي على الأقل ، لأن NVDA (https://github.com/nvaccess/nvda) (مصدر مفتوح قارئ الشاشة) يستخدمه) واختبره تجريبيًا كما تذهبون يا رفاق. في غضون ذلك ، هل هناك محرر أو طريقة بديلة لـ godot لإنشاء اللعبة يدويًا ، بدون المحرر؟

إذا تم تنفيذ هذه الميزة في قلب المحرك نفسه ، فسيكون من الممكن تطوير تطبيقات للمكفوفين ، وليس فقط السماح للمطورين المكفوفين بالعمل.
+1 للاقتراح

يسعدني أن أرى أن هذا يتم النظر إليه والشيء الوحيد الذي يجب أن أضيفه حول هذا هو أن برنامج قارئ الشاشة يستخدم أيضًا من قبل الأشخاص الذين يعانون من صعوبات / صعوبات في التعلم مثل عسر القراءة. بقدر ما أكره الطريقة التي تترك بها هذه الأشياء الناس أحيانًا ، أعتقد أنه يمكن القول إن هذا يوسع من قضية مثل هذا التطور.

سيكون NV Access (NVDA) أول مكان جيد للاتصال به حيث أن كلا المطورين الرئيسيين أعمى وبالتالي يكون لديهم رؤية مناسبة لما هو ضروري. ربما جهد تعاوني؟

مرحبا،

أعتقد أن هذا سيكون جهدًا كبيرًا. يمكن القيام بذلك ولكن النظر في بروتوكولات إمكانية الوصول الأصلية ، يمكن أن يكون التنفيذ الذي تم إجراؤه من البداية مشكلة كبيرة لمستخدمي جميع الأنظمة الأساسية.

إذا كنت تخطط للمضي قدمًا في ذلك ، فإنني أوصيك باستخدام نموذج QT ، وطبقة حدث إمكانية وصول مجردة أعلى عناصر التحكم في واجهة المستخدم الأساسية أولاً وتنفيذ يعتمد على النظام الأساسي.

طريقة أخرى هي استخدام Text To Speech مباشرة. يمكن أن يكون هذا أكثر استقلالية عن النظام الأساسي ويسهل العمل عليه. هناك بعض المشاكل مع هذا أيضًا ، لكنها مرتبطة بالمحرك أكثر من بيئة وقت التشغيل.

آمل أن يساعدك هذا على اتخاذ القرار.

هتافات،

سيعمل مثل هذا النموذج أيضًا ، إذا تم الاتصال بإمكانية الوصول منخفضة المستوى
واجهات برمجة التطبيقات فشلت بطريقة ما. أوافق بنسبة 100 في المائة على أن NVAccess سيكون
أفضل رهان للحصول على أعلى مستوى من إمكانية الوصول في. :)

في 18/5/2018 ، كتب فرانسيسكو آر ديل روا إخطارات github.com:

مرحبا،

أعتقد أن هذا سيكون جهدًا كبيرًا. يمكن القيام بذلك ولكن مع الأخذ في الاعتبار
يمكن تنفيذ بروتوكولات الوصول الأصلية من البداية
إشكالية كبيرة لمستخدمي جميع المنصات.

إذا كنت تخطط للمضي قدمًا في ذلك ، فإنني أوصيك باستخدام نموذج QT ،
طبقة حدث إمكانية وصول مجردة أعلى عناصر تحكم واجهة المستخدم الأساسية أولاً
وتنفيذ يعتمد على النظام الأساسي.

طريقة أخرى هي استخدام Text To Speech مباشرة. يمكن أن يكون هذا أكثر من ذلك
مستقل عن النظام الأساسي ومن السهل جدًا العمل عليه. هناك بعض المشاكل
مع هذا أيضًا ، لكنها مرتبطة بالمحرك أكثر من وقت التشغيل
بيئة.

آمل أن يساعدك هذا على اتخاذ القرار.

هتافات،

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/godotengine/godot/issues/14011#issuecomment -390176511

-
وقعت،
إيثين د

كحل جزئي ، هل هناك أي مستندات ، أو حتى أماكن للبحث ، لتنفيذ لعبة يدويًا دون استخدام المحرر؟ لقد رأيت مستندات سطر الأوامر ، لكنني أتساءل عما إذا كان من العملي / الممتع عن بُعد العمل مع الرسوم البيانية للمشهد وكذا يدويًا ، وبالتالي يلغي الحاجة إلى المحرر تمامًا.

كمثال عملي أكثر ، أقوم الآن بتنفيذ لعبة صوتية تشبه Asteroids. تصدر الكويكبات أصواتًا لتحديد مواقعها ، ويقوم اللاعب بتوسيطها في مجال الصوت عن طريق الدوران / التحليق حولها. لا أهتم بشكل خاص بالمرئيات ، لكنها ستكون مفيدة لأغراض تصحيح الأخطاء ، لذا يمكنني أن أسأل الأشخاص المبصرين إذا كان مفهومي العقلي لتوجيه سفينتي ، على سبيل المثال ، يتطابق مع الأسطوانات / المجالات الخام التي أستخدمها لتصحيح الأخطاء / كشف الاصطدام. أتساءل عما إذا كان من الممكن حتى عن بُعد وضع كرة بقطر 5 وحدات عند 0،0 ، ووضعها بشكل عشوائي وتحريك مجموعة من المجالات ذات قطر 25 وحدة ، وتنفيذ سلوك التفاف ، وما إلى ذلك عن طريق ترميزها يدويًا كل ذلك بدون حاجة محرر جودو. أم سيكون هناك فوضى في تحرير XML غير الصديق للإنسان؟

في الوقت الحالي ، أفعل هذا بشكل أو بآخر يدويًا في Rust باستخدام ECS. هذا ليس فظيعًا ، لكني أتساءل عما إذا كنت أكسب أي شيء من خلال الاستفادة من محرك اللعبة الفعلي. من الناحية المثالية ، فإن موضوع Asteroids هو مجرد إثبات للمفهوم ، وأود في النهاية أن أصنع ألعابًا صوتية أكثر ثراءً دون الحاجة إلى بناء كل هذه الأشياء يدويًا. ما إذا كان Godot هو هذا الحل ، لا أعرف ...

في كلتا الحالتين ، أعتقد أن تنفيذ واجهة وصول كاملة لمجموعة أدوات واجهة المستخدم ربما يكون أمرًا صعبًا بعض الشيء. إذا كانت ملفات البيانات في الغالب نصية ولكنها غير ودية للإنسان ، فقد يكون الحل الوسطي هو DSL الذي يعرض واجهة مبسطة لأنواع المهام التي وصفتها أعلاه (تحديد المواقع الأولية للشكل ، وإرفاق الأصوات ، وإضافة المنطق إلى الكيانات. إلخ.)

كحل جزئي ، هل هناك أي مستندات ، أو حتى أماكن للبحث ، لتنفيذ لعبة يدويًا دون استخدام المحرر؟

أعتقد أن أسهل طريقة (بدون الاختراق) هي إنشاء المشاهد من الناحية الإجرائية عبر البرنامج النصي. يمكنك القيام بذلك في وقت التشغيل أو إنشاء نص برمجي يحفظ المشاهد والموارد على القرص حتى تتمكن من الإضافة إلى المشروع. تتطلب السقالات الأولية ملف project.godot لإعدادات المشروع (والذي يمكن أن يكون ملفًا فارغًا تم إنشاؤه بواسطة نظام التشغيل في البداية) ومشهدًا رئيسيًا يتم تشغيله في البداية (والذي يمكن أيضًا تعيينه وحفظه عبر البرنامج النصي) . قد تكون إدارتها معقدة ، لكنها ممكنة.

من الناحية الفنية ، يمكنك إنشاء برنامج نصي يتم تشغيله مباشرة من سطر الأوامر وهذا البرنامج النصي يجعل مشروع Godot بأكمله من أجلك (على الأقل لا يمكنني التفكير في أي شيء قد يمنع ذلك). يمكنك بعد ذلك تشغيل اللعبة وتصديرها من سطر الأوامر أيضًا. ستحتاج إلى فتح المشروع في المحرر مرة واحدة على الأقل لاستيراد الأصول (وفي كل مرة تتغير الأصول) ولكن يمكن حل ذلك عن طريق تشغيل الإصدار بدون رأس من Godot ، كما يفعل بعض الأشخاص للاستخدام مع خوادم التكامل المستمر.

إذا كانت ملفات البيانات في الغالب نصية ولكنها غير ودية للإنسان ، فقد يكون الحل الوسطي هو DSL الذي يعرض واجهة مبسطة لأنواع المهام التي وصفتها أعلاه (تحديد المواقع الأولية للشكل ، وإرفاق الأصوات ، وإضافة المنطق إلى الكيانات. إلخ.)

ليس من الصعب قراءة تنسيق مورد النص ، ولكن لا يزال من الأسهل استخدام GDScript لإنشاء عناصر للمشروع ، حيث يمكنك استخدام المحرك الأساسي لكتابة التنسيق وقراءته (تجنب مشكلات التوافق).

للأسف ، GDScript ليست أفضل لغة للأشخاص ضعاف البصر ، لأن المساحة البيضاء مهمة. سمعت شكاوى من مطور أعمى حول بايثون بسبب هذا.

بصراحة ، أعتقد أن الشكاوى حول وضع المسافات البيضاء هي
على الأرجح (معذرة لغتي) فوز مشاكس. المسافة البيضاء هي
أنا بخير تمامًا (أنا كفيف وأستطيع التعامل مع بيثون جيدًا ،
بالإضافة إلى اللغات الأخرى التي تعتمد على المسافات البيضاء مثل F # وما شابه).
أولئك الذين يشتكون من المسافات البيضاء هم عادة من هم أيضًا
غير متحمس لفكر البرمجة (مما يثير
سؤال عن سبب فحصهم له بالضبط في المقام الأول) أو
أولئك الذين لم يحاولوا حتى والذين يشتكون فقط للشكوى.
لا أقصد أن أكون ملتهبًا جدًا ، لكن هذا يثير استيائي حقًا عندما أفعل ذلك
رؤية الناس يشكون من ذلك. انها فقط لا معنى لها على الاطلاق.
لم أسمع قط بنسخة جودو مقطوعة الرأس. ربما يمكن ذلك
تستخدم لإنشاء المشاريع والتفاعل مع المحرك أيضًا؟ الذي - التي
قد يكون حلاً كاملاً لمشاكلنا في الوقت الحالي. حيث يمكن
أجد هذا الإصدار؟ (أم أنها موجودة في حزمة Godot؟)

في 24/5/2018 ، كتب George Marques [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 الكامل.

قد أبدأ في اختراق هذا الأمر إذا كان الأشخاص الذين يعرفون أكثر مما أعرفه عن Godot يعتقدون أنه قابل للتطبيق. كنت أبحث عن مشكلة واجهة CLI جيدة لإغراق أسناني فيها ، ولدي عدد قليل من مكتبات Rust التي أود أن أضعها في خطواتها. هل تنسيق الملف / البيانات موثق في أي مكان؟

George Marques ، أعتذر عن سلوكي الوقح ... فقط ترك ذلك
من صدري. لأنه يزعجني حقًا ويبدو وكأنه نبيذ
أكثر من حقيقة فعلية ، هل تعلم؟
Nolan Darilek ، قد يكون لفكرتك ميزة ؛ هل سيكون من الممكن البرمجة
واجهة مستخدم بديلة ، ربما تستخدم شيئًا مثل WXWidgets؟
إذا استخدمنا WX ، فسيحل جميع مشكلات إمكانية الوصول دفعة واحدة.
(شخصيًا ، لم أتمكن مطلقًا من اكتشاف WX .... بدا الطريق
معقدة جدا بالنسبة لي .... هيه :)).

في 25/5/2018 ، كتب Nolan Darilek [email protected] :

سأكرر ما يقوله 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 كامل.

قد أبدأ في القرصنة على هذا إذا كان الناس يعرفون أكثر مما أعرفه عن Godot
أعتقد أنه قابل للحياة. تم البحث عن مشكلة واجهة CLI جيدة لإغراق ملف
الأسنان ، ولديها عدد قليل من مكتبات الصدأ التي أود وضعها من خلال
خطوات. هل تنسيق الملف / البيانات موثق في أي مكان؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/godotengine/godot/issues/14011#issuecomment -392111005

-
وقعت،
إيثين د

وبالمثل بخصوص: WX. إذا كنت سأقوم بعمل واجهة مستخدم رسومية ، فمن المحتمل أن أختار GTK
منذ أن كنت على نظام Linux ، لكنني لم أجلس مطلقًا لتعلم GTK أو WX ، وذاك
قد يبدو وكأنه متغير أكثر من اللازم للتلاعب به هنا.

أعتقد أنني سأبدأ مبدئيًا بـ CLI يمكنه بدء / إيقاف العرض
عملية Godot وقيادة هذه النسخة مقطوعة الرأس. إذا فعلت هذا في Rust ،
من المحتمل أن أقوم ببناء تطبيق Struct و serde لمجموعة فرعية من
التنسيق الذي ستدعمه الواجهة. مع ذلك كنقطة انطلاق ،
يجب أن يكون من السهل إنشاء واجهة المستخدم الرسومية لاحقًا أو بالتوازي.

هذا من شأنه أن يعمل ، نعم ؛ ولكن كيف ستفعل ذلك بالضبط في
صدأ؟ أعتقد أن الصدأ سيكون مثاليًا لهذا ، لكن مما رأيته ،
محرر المحرك مكتوب على الأقل بلغة C ++. في الواقع ، يبدو أن ملف
الأساسية أيضًا. لذا ، منذ ذلك الحين (وفقًا لـ
https://doc.rust-lang.org/beta/nomicon/ffi.html) لا يمكن التفاعل مع الصدأ
باستخدام C ++ ، سنحتاج إلى إنشاء واجهة C. هذا في حد ذاته سيكون
كابوس مطلق. :)

في 25/5/2018 ، كتب Nolan Darilek [email protected] :

وبالمثل بخصوص: WX. إذا كنت سأقوم بعمل واجهة مستخدم رسومية ، فمن المحتمل أن أختار GTK
منذ أن كنت على نظام Linux ، لكنني لم أجلس مطلقًا لتعلم GTK أو WX ، وذاك
قد يبدو وكأنه متغير أكثر من اللازم للتلاعب به هنا.

أعتقد أنني سأبدأ مبدئيًا بـ CLI يمكنه بدء / إيقاف العرض
عملية Godot وقيادة هذه النسخة مقطوعة الرأس. إذا فعلت هذا في 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
أدوات للتصدير / التقديم ، قد نكون على شيء ما. هناك الكثير
من أنواع العقد ، ولكن إذا تم توثيقها بأي نوع من أنواع
بطريقة يمكن قراءتها آليًا ، قد يكون من الممكن في النهاية النقر على نوع ما
من مولد رمز الصدأ أو كتابة ماكرو لتكرار نفس واجهة المستخدم en
الشامل ... ولكن من الأفضل اكتشاف شكل واجهة المستخدم هذه من قبل
الوصول إلى ماكرو لتوليدها تلقائيًا. :)

إذا كنت محقًا بشأن كل شيء قائمًا على INI ، فقد أقوم بتجميع ملف
MVP PoC لمعرفة أين يذهب هذا. لأكون واضحًا ، أنا لا أهدف إلى a
حالة استخدام محرر للأغراض العامة هنا ، فقط بعض الطرق لبناء الألعاب الصوتية
دون الحاجة إلى ترميز كل شيء يدويًا ، والاستفادة من ملف
محرك اللعبة الفعلي للقيام بالتصدير عبر الأنظمة الأساسية.

ولكن بقدر متعة هذا العصف الذهني ، يجب أن أعمل وأكمل
الإسبوع. سأضع الريبو في وقت ما قريبًا وأرى أين يذهب. أنا
يفضل بشكل عام GitLab بسبب CI المتكامل ، لكن يمكنني ذلك
مقتنعًا بالبقاء على GitHub إذا كان الناس يعارضون ذلك.

تم وصف تنسيق الملف (جزئيًا على الأقل) في الوثائق: http://docs.godotengine.org/en/latest/development/file_formats/tscn.html

ومع ذلك ، فإن إنشاء أداة جديدة تمامًا لهذا يتطلب الكثير من العمل ولا بد أن يصبح عفا عليه الزمن بسهولة تامة. على الأقل يجب عليك استخدام GDNative كجسر (وهي واجهة C لمحرك C ++) ، والتي من شأنها أن تتيح الوصول إلى جميع المعلومات حول الفئات وخصائصها. وبقدر ما أقدر هذا الجهد ، أعتقد أنك بحاجة أولاً إلى فهم بعض الشيء لما يقدمه Godot ، حتى لا تعيد اختراع جميع العجلات.

إذا كنت تريد فعلاً التعامل مع Rust ، فيمكنك تجربة روابط GDNative (على الرغم من أنني لا أستطيع أن أشهد على استقرارها): https://github.com/GodotNativeTools/godot-rust

شخصياً ، سأحاول أن أفعل شيئًا ما مع نواة Godot نفسها (ربما كوحدة C ++) ، حيث يمكنك بعد ذلك الوصول إلى كل واجهة برمجة التطبيقات بسهولة ، بما في ذلك جميع أدوات توفير الموارد ومحملات التحميل ، لذلك لا داعي للقلق بشأن تنسيقات الملفات .

إذا كنت تريد استخدام واجهة CLI ، فيجب أن تعتمد على ترتيب شجرة المشهد ، والتي تعد أهم جزء في أي لعبة Godot. ربما يكون تصميم هذه العملية مسبقًا أكثر أهمية: إنشاء طريقة سهلة لفهم كيفية تخطيط الشجرة والأدوات اللازمة لنقل العقد إلى موضع شجرة معين يجب أن يكون حجر الزاوية في التصميم. إذا حصلت على ذلك ، فلن تحتاج حتى إلى تقييد مجموعة الميزات ، حيث يمكن فعل أي شيء تقريبًا باستخدام الشجرة.

بعد ذلك ، تحتاج إلى طريقة لتعيين خصائص العقد الفردية ، بما في ذلك الموارد المستخدمة لإعطاء وظيفة مناسبة (على سبيل المثال ، تحتاج عقدة CollisionShape2D إلى مورد Shape2D لإعطاء شكلها). تعتبر البرامج النصية أيضًا موارد ، لذا يمكن تعيينها عبر هذه الواجهة أيضًا (على الرغم من أنك قد ترغب في منحها حالة خاصة). هذا من شأنه أن يحل محل المفتش في واجهة المستخدم الرسومية.

أيضًا ، سأصدر أوامر بالقرب من GDScript قدر الإمكان. على سبيل المثال ، إذا كنت تريد إنشاء Sprite ، فيمكنك ببساطة عمل Sprite.new() ، وهو نفس الشيء الذي ستفعله في البرنامج النصي. بهذه الطريقة يكون منحنى التعلم لشخص معتاد بالفعل على البرمجة النصية أقل حدة.

بالنسبة للصوت ، يستخدم Godot المشغلات والحافلات. هناك مشغلات للصوت الموضعي (ثنائي وثلاثي الأبعاد على حد سواء) ومشغلات عادية للصوت غير الموضعي ، وجميعها عُقد في الشجرة أيضًا. الصوت المحيطي مدعوم أيضًا (على الرغم من أنني لم أستخدمه مطلقًا). للعمل مع الحافلات ، تحتاج إلى التفاعل مع خادم الصوت ، لتعيين مستوى الصوت ، أو كتم الصوت أو منفردًا ، وإضافة التأثيرات. قد تتمكن من استخدام مورد AudioBusLayout مباشرةً ، لكنني لست متأكدًا من مقدار تعرضه لواجهة برمجة التطبيقات الخارجية. التأثيرات هي مجرد موارد ، لذا يمكن تحريرها بواسطة نفس الواجهة.

كل هذا في رأيي المتواضع بالطبع. لقد استخدمت Godot لفترة طويلة الآن ، لذلك قد أكون متحيزًا إلى حد ما.

مرحبًا ، شكرًا ، هذا مفيد. أنا لست متشبثًا بشكل خاص بالعبث
حول ملفات البيانات مباشرة. سعيد لمعرفة كيف قد يكون هذا
العمل - معظم مستندات بدء الاستخدام التي أواجهها هي التدريس عن طريق البناء
الألعاب ، ولا أحد يفترض أنك بحاجة إلى بناء أدواتك الخاصة أولاً. :)

لم أتطرق إلى C ++ منذ ما يقرب من عقدين من الزمن ، لذلك من المحتمل أن ألتزم بها
الصدأ والتعامل مع واجهة برمجة تطبيقات أو مشكلات أقل اكتمالاً في حالة حدوث أي منها
عدم الاستقرار. هل يدعم gdnative القراءة / الكتابة للمشروع والمشهد و
ملفات أخرى مباشرة؟ أم أنها تهدف إلى دعم ألعاب الكتابة باللغتين C و
استدعاء في المحرك؟ لقد أجريت فحصًا موجزًا ​​لـ grep من خلال Rust repo لـ
"مشروع" ولم أجد شيئًا. يبدو أن الأمثلة تركز على
ألعاب البناء مباشرة. إذا كنت لا تمانع في إعطائي نقطة دخول لـ
حيث أبدأ في بناء مشروع ونشره برمجيًا ، سأفعل
اقرأ عن ذلك وانقل المزيد من العمل إلى الريبو الخاص بي.

شكرا مرة أخرى على الإزعاج لي. :)

تهدف GDNative إلى صنع ألعاب ، لتحل محل البرامج النصية بشكل أساسي. ولكن كما قلت من قبل ، يمكنك فعل أي شيء تقريبًا باستخدام البرامج النصية ، ويستخدم GDNative نفس واجهة برمجة التطبيقات.

مرحبا،

للمشهد أو للكائنات المتشابهة والمعقدة ، يمكنك استخدام تنسيق مثل هذا الملف .

في هذه الحالة ، فهي مخصصة فقط لخريطة لمشروع يسمى audioquake ، ولكنها يمكن أن تكون مثالاً. PD: لا تحاول بناء هذا ، فقد لا ينجح.

بالنسبة إلى واجهة المستخدم الرسومية ، يمكنك أيضًا استخدام QT5.11 ، لقد رأيت أنه يتضمن العديد من التحسينات لإمكانية الوصول. في هذه الحالة ، ستحتاج فقط إلى إضافة نوع من دعم إمكانية الوصول لعناصر تحكم مخصصة صلبة مثل الكاميرا.

هتافات،

تنسيق خرائط الزلزال الصوتية محدود للغاية. أنا شخصيا لا أحب ذلك.

في 25/5/2018 ، كتب فرانسيسكو آر ديل روا إخطارات github.com:

مرحبا،

للمشهد أو الكائنات المتشابهة والمعقدة ، يمكنك استخدام تنسيق مثل هذا
ملف .

في هذه الحالة ، فهي مخصصة فقط لخريطة لمشروع يسمى audioquake ، لكنها
يمكن أن يكون مثالا. PD: لا تحاول بناء هذا ، فقد لا ينجح.

بالنسبة إلى واجهة المستخدم الرسومية ، يمكنك أيضًا استخدام QT5.11 ، لقد رأيت أنه يتضمن العديد من التحسينات
من أجل الوصول. في هذه الحالة ، ستحتاج فقط إلى إضافة نوع من ملفات
دعم إمكانية الوصول لعناصر التحكم المخصصة الصلبة مثل الكاميرا.

هتافات،

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/godotengine/godot/issues/14011#issuecomment -392214077

-
وقعت،
إيثين د

انتظر ، أنا غبي. قلت في بداية هذا الموضوع أن
لم تكن بحاجة إلى المحرر على الإطلاق ، باستثناء عند استيراد الأصول. أنا
أعتقد أنه كان من الأصح أن أسأل عما إذا كنت بحاجة إلى
واجهة المستخدم الرسومية لإنشاء الألعاب. أنا سعيد بتشغيلهم من واجهة المستخدم الرسومية ، أريد فقط
لتطويرها على وحدة التحكم. ويبدو أنني أستطيع.

لذا أعتقد أن ما أريده هو سلسلة "Godot from scratch" التي تفترضك
لا يمكنك / لا ترغب في استخدام المحرر ، على غرار الطريقة التي تستخدمها
كتابة لعبة باستخدام pygame أو مكتبة أخرى رفيعة المستوى. أتخيل مرة واحدة
لقد اكتشفت كيفية إنشاء ملف مشروع يقوم للتو بتشغيل ملف
البرنامج النصي ، وربما البرنامج النصي الذي يفتح نافذة ويدور مكعبًا أو ملف
شيء ما ، يمكنني تطبيق ذلك لأعلى. أشك في وجود مثل هذا الشيء ، لذلك
ربما سأحاول بنفسي وأقوم بتدوين العملية. ثم ربما سأبني ملف
أداة CLI للنماذج الأولية لاحقًا ، بمجرد أن أعرف ما قد أرغب في إنشاء نموذج أولي له
بدون رمز.

أنت تعرف ... أتساءل عما إذا كان بإمكاننا بطريقة ما أن نجعل المحرك ليس فقط
محرك مع محرر وكذا ، ولكن مكتبة أيضًا؟ مثل ما قدمته
مكتبات C ++ (libs ثابتة أو ديناميكية) ويمكنها بناء لعبتك
كيفما تشاء ، فإن استخدام Godot لجميع عناصر محرك اللعبة (على سبيل المثال
الصوت ومثل). إذا كان هذا ممكنًا ، فيمكننا التنازل عن المحرر
تماما. لذلك يمكنك إضافة أصول مثل ملفات .caf مثلاً ، ثم في
وقت التشغيل ، يمكنك تجميعها في الذاكرة كملفات بيانات أصول مجمعة (نحن
يمكن فقط تسميتها CADFs). لذلك ستبدو لعبتك عند بدء التشغيل:

// ...
// تجميع الأصول
godot :: الأصول :: LoadAll ({الأصول ، الأصول ، الأصول}) ؛ // تحميل كل أصل على حدة
أو
Godot :: Assets :: LoadAllAssetsFrom ("الأصول") ؛ // تحميل كافة الأصول في
مرة واحدة من مجلد.
// تجميع كافة الأصول
أصول السيارات = Godot :: Assets :: GetAllLoadedAssets () ؛
نجاح منطقي = Godot :: Assets :: Cadf :: CompileAllAssets (أصول) ؛
إذا (نجاح) {
// الأصول المجمعة
} آخر {
// خطأ
}

من المؤكد أن هذا هو أسلوبي في الترميز ، وأشك في أنه طريقة
المحرك مكتوب. ولكن إذا كان من الممكن القيام بذلك ، فسيكون كذلك
الملحم. أو يمكننا فقط التخلي عن تجميع الأصول على الإطلاق ، ما عليك سوى تحميل الكل
عنهم عندما نحتاجهم ، أو كلهم ​​عند بدء التشغيل.

في 25/5/2018 ، كتب Nolan Darilek [email protected] :

انتظر ، أنا غبي. قلت في بداية هذا الموضوع أن
لم تكن بحاجة إلى المحرر على الإطلاق ، باستثناء عند استيراد الأصول. أنا
أعتقد أنه كان من الأصح أن أسأل عما إذا كنت بحاجة إلى
واجهة المستخدم الرسومية لإنشاء الألعاب. أنا سعيد بتشغيلهم من واجهة المستخدم الرسومية ، أريد فقط
لتطويرها على وحدة التحكم. ويبدو أنني أستطيع.

لذا أعتقد أن ما أريده هو سلسلة "Godot from scratch" التي تفترضك
لا يمكنك / لا ترغب في استخدام المحرر ، على غرار الطريقة التي تستخدمها
كتابة لعبة باستخدام pygame أو مكتبة أخرى رفيعة المستوى. أتخيل مرة واحدة
لقد اكتشفت كيفية إنشاء ملف مشروع يقوم للتو بتشغيل ملف
البرنامج النصي ، وربما البرنامج النصي الذي يفتح نافذة ويدور مكعبًا أو ملف
شيء ما ، يمكنني تطبيق ذلك لأعلى. أشك في وجود مثل هذا الشيء ، لذلك
ربما سأحاول بنفسي وأقوم بتدوين العملية. ثم ربما سأبني ملف
أداة CLI للنماذج الأولية لاحقًا ، بمجرد أن أعرف ما قد أرغب في إنشاء نموذج أولي له
بدون رمز.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/godotengine/godot/issues/14011#issuecomment -392224709

-
وقعت،
إيثين د

أعتقد أنه كان من الأصح أن أسأل عما إذا كنت بحاجة إلى
واجهة المستخدم الرسومية لإنشاء الألعاب. أنا سعيد بتشغيلهم من واجهة المستخدم الرسومية ، أريد فقط
لتطويرها على وحدة التحكم. ويبدو أنني أستطيع.

لا تحتاج إلى واجهة المستخدم الرسومية لتشغيل الألعاب. في الواقع ، ينشئ المحرر عملية Godot أخرى باستخدام الحجج لتشغيل اللعبة (مع جميع خيارات التصحيح أيضًا). تشغيل اللعبة ليس مشكلة: يمكنك ببساطة تشغيل Godot من دليل المشروع بدون وسيطات ، والافتراضي هو تشغيل المشروع.

المحرر بحد ذاته "لعبة" جودو إلى حد كبير. يستخدم العقد المتاحة ويمدها. الجزء المتعلق بالاستيراد ، ليس أنك بحاجة إلى واجهة المستخدم الرسومية ، فأنت تحتاج فقط إلى أدوات الاستيراد التي تأتي مع المحرر. بشكل أساسي ، تقوم فقط بوضع جميع الأصول في مجلد المشروع (في أي هيكل تريده) وعندما تفتح المحرر ، سوف يستورد كل شيء.

يعني "الاستيراد" في هذه الحالة تخزين البيانات الوصفية (إذا كنت تريد تكرار الصوت وتقليصه ، أو تطبيق مرشح على صورة ، وما إلى ذلك) والتحويل أحيانًا إلى تنسيق يفهمه Godot ويمكن استخدامه (مثل استيراد نموذج إلى شبكة Godot ). لا يمكن إجراء عملية الاستيراد إلا عن طريق بناء الأدوات (أي المحرر) ، حتى لو كان الإصدار مقطوع الرأس.

عندما تقوم بتصدير اللعبة ، يتم حزم الأصول المستوردة فقط ، ويتم تجاهل الأصول الأصلية. بالنسبة للعبة نفسها ، تكون هذه العملية شفافة: يمكنك التعامل مع الأصول كما لو كانت في الموقع الأصلي ، وسيعرف القائمون على التحميل الحصول على الإصدار الذي تم استيراده.

تمامًا مثل المحرر مجرد لعبة ، يمكنك إنشاء "اللعبة" الخاصة بك والتي هي في الواقع أداة لصنع الألعاب. أعني ، يمكنك حتى إنشاء برنامج نصي يمتد إلى MainLoop أو SceneTree وتشغيله مباشرة عبر المحطة الطرفية باستخدام:

$ godot -s my_script.gd

تكمن المشكلة في أنك تريد أداة CLI حقيقية ، فلن يسهل Godot الأمر. حتى عند تشغيل البرنامج النصي ، فإنه سيفتح نافذة ، وسيتم تجاهل كل ما يتم إرساله عبر stdin .

أتساءل عما إذا كان بإمكاننا بطريقة ما أن نجعل المحرك ليس فقط
محرك مع محرر وكذا ، ولكن مكتبة أيضًا؟ مثل ما قدمته
مكتبات C ++ (libs ثابتة أو ديناميكية) ويمكنها بناء لعبتك
كيفما تشاء ، فإن استخدام Godot لجميع عناصر محرك اللعبة (على سبيل المثال
الصوت ومثل).

بينما تم تصميم المحرر والمحرك لبعضهما البعض ، فأنت لا تعتمد كليًا على المحرر لإنشاء اللعبة. ومع ذلك ، لا يمكنك تقسيم Godot إلى أجزاء ، فأنت بحاجة إلى أخذ الحزمة بأكملها (على الرغم من أنه يمكنك تعطيل معظم الوحدات دون مشكلة). نظرًا لأن المحرر هو لعبة Godot ، فمن الممكن تقنيًا استبدال الكود بلعبتك الخاصة. قد يعني ذلك إنشاء المشاهد على الطاير باستخدام الكود.

لا يُقصد باستخدام Godot كمكتبة أو إطار عمل ، ومن المحتمل ألا يتم استخدامه على الإطلاق ، ولكن يمكنك اختراقه وتنفيذ تطبيق MainLoop الذي لا يستخدم حتى العقد على الإطلاق ، وبدلاً من ذلك ، اتصل بالخوادم مباشرة. بالطبع ، سوف تحتاج إلى بناء المحرك من المصدر ، لكني أتخيل أن هذا هو أقل ما يثير القلق.

أي من هذا ممكن تقنيًا ، وربما ليس بهذه الصعوبة ، لكنه يغامر بالذهاب إلى منطقة مجهولة.

آسف لكونك صاخبة ، يا رفاق.

لذلك قمت منذ ذلك الحين بغوص عميق إلى حد ما في Godot وقرأت الكثير منها
وثائق. عادةً لا أفعل هذا لأداة غير مكتبة مثل
هذا لأنه نوع من المسار الطويل نحو المطلوب
النتيجة - بشكل أساسي بناء جميع الأدوات في متجر النجارة الخاص بك
قبل أن تتمكن من قطع ورقة واحدة من الخشب الرقائقي. :)

أنا أتحول ببطء إلى وجهة نظر أن المحرر نفسه قد يكون كذلك
يمكن الوصول إليه من خلال إنشاء قارئ شاشة صغير بتنسيق
GDScript. هذا له فائدة إضافية تتمثل في إنشاء واجهات مستخدم للعبة بنفسها
يمكن الوصول. لا يخلو من سابقة أيضا. نرى
هذه
لمكوِّن إضافي لإمكانية الوصول في Unity UI.

عند النظر إلى فئة Control ، يبدو أن هناك إشارات مكشوفة
للتركيز أدخل / مغادرة. هناك أيضًا إشارات لأحداث الإدخال ، والتي أنا
يتضمن الأمل السهام حول حقول إدخال النص وما شابه. انها تريد ان تكون
يقتصر على قارئ شاشة عام على مستوى نظام التشغيل ، ولكنه قد يعمل فقط مع
شيء خاص بالمجال.

لقد بدأت في شيء ما
هنا . لسوء الحظ،
لا يمكنني إضافة هذا المكون الإضافي إلى مشروعي لأنني بحاجة إلى تعذر الوصول إليه
محرر لإضافة المكوِّن الإضافي الخاص بإمكانية الوصول. :) إذا كان بإمكان أي شخص إضافة هذا
البرنامج المساعد للمشروع وتقديم عرض عام مع تغييرات project.godot ،
سيكون ذلك مفيدًا. أساسا ما سأفعله هو ربط
إشارة node_added (أو أيًا كان ما يطلق عليه) عند التقاطع SceneTree
أي عقد تنحدر من Control ، وتتصل بـ
إشارة focus_entered . بمجرد الوصول إلى هناك ، سأبدأ في إضافة منطق للطباعة
رسائل العرض التقديمي لكل نوع عقدة سيتم توصيلها في النهاية
إلى واجهة برمجة تطبيقات TTS غير المكتوبة حتى الآن. واسمحوا لي أن أعرف إذا كان هناك أي
أسباب واضحة لعدم نجاح هذا.

وكيف يمكنني أن أجعل هذا مكونًا إضافيًا غير محرر يعمل مع أي مكون إضافي
واجهة مستخدم Godot ، بما في ذلك الألعاب الموجودة في الألعاب غير المحرر؟

نأمل أن نتمكن في النهاية من نقل المناقشة إلى هذا الريبو الآخر والتوقف
إرسال بريد إلكتروني غير مرغوب فيه إلى هذه المشكلة. :)

إذا كنت أفهمك جيدًا ، إذا كان هذا يعمل ، فيمكننا اختيار ذلك
تضمينها في ألعابنا أم لا ، أليس كذلك؟ هل هناك أي طريقة يمكن أن نضيفها
إلى المحرر ولكن ليس للمشاريع التي نقوم بإنشائها أو إزالتها
من المشروع ولكن إضافته إلى المحرر؟

في 26/5/2018 ، كتب Nolan Darilek [email protected] :

آسف لكونك صاخبة ، يا رفاق.

لذلك قمت منذ ذلك الحين بغوص عميق إلى حد ما في Godot وقرأت الكثير منها
وثائق. عادةً لا أفعل هذا لأداة غير مكتبة مثل
هذا لأنه نوع من المسار الطويل نحو المطلوب
النتيجة - بشكل أساسي بناء جميع الأدوات في متجر النجارة الخاص بك
قبل أن تتمكن من قطع ورقة واحدة من الخشب الرقائقي. :)

أنا أتحول ببطء إلى وجهة نظر أن المحرر نفسه قد يكون كذلك
يمكن الوصول إليه من خلال إنشاء قارئ شاشة صغير بتنسيق
GDScript. هذا له فائدة إضافية تتمثل في إنشاء واجهات مستخدم للعبة بنفسها
يمكن الوصول. لا يخلو من سابقة أيضا. نرى
هذه
لمكوِّن إضافي لإمكانية الوصول في Unity UI.

عند النظر إلى فئة Control ، يبدو أن هناك إشارات مكشوفة
للتركيز أدخل / مغادرة. هناك أيضًا إشارات لأحداث الإدخال ، والتي أنا
يتضمن الأمل السهام حول حقول إدخال النص وما شابه. انها تريد ان تكون
يقتصر على قارئ شاشة عام على مستوى نظام التشغيل ، ولكنه قد يعمل فقط مع
شيء خاص بالمجال.

لقد بدأت في شيء ما
هنا . لسوء الحظ،
لا يمكنني إضافة هذا المكون الإضافي إلى مشروعي لأنني بحاجة إلى تعذر الوصول إليه
محرر لإضافة المكوِّن الإضافي الخاص بإمكانية الوصول. :) إذا كان بإمكان أي شخص إضافة هذا
البرنامج المساعد للمشروع وتقديم عرض عام مع تغييرات project.godot ،
سيكون ذلك مفيدًا. أساسا ما سأفعله هو ربط
إشارة node_added (أو أيًا كان ما يطلق عليه) عند التقاطع SceneTree
أي عقد تنحدر من Control ، وتتصل بـ
إشارة focus_entered . بمجرد الوصول إلى هناك ، سأبدأ في إضافة منطق للطباعة
رسائل العرض التقديمي لكل نوع عقدة سيتم توصيلها في النهاية
إلى واجهة برمجة تطبيقات TTS غير المكتوبة حتى الآن. واسمحوا لي أن أعرف إذا كان هناك أي
أسباب واضحة لعدم نجاح هذا.

وكيف يمكنني أن أجعل هذا مكونًا إضافيًا غير محرر يعمل مع أي مكون إضافي
واجهة مستخدم Godot ، بما في ذلك الألعاب الموجودة في الألعاب غير المحرر؟

نأمل أن نتمكن في النهاية من نقل المناقشة إلى هذا الريبو الآخر والتوقف
إرسال بريد إلكتروني غير مرغوب فيه إلى هذه المشكلة. :)

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/godotengine/godot/issues/14011#issuecomment -392255752

-
وقعت،
إيثين د

انا لا اعرف.

لقد اكتشفت التنسيق لإضافة مكون إضافي إلى project.godot
ملف. لدي الآن وظيفة يجب إضافتها
focus_entered / mouse_entered معالجات لكل Control ويطبع a
رسالة عندما يكون لديهم التركيز. لسوء الحظ ، أنا لا أحصل عليه بالفعل
أيًا من هذه الأحداث ، ولست متأكدًا من كيفية الحصول على العقدة الفعلية التي
نشأت لهم.

ومع ذلك ، لا شيء في هذا خاص بالمحرر ، ويجب أن يكون تلقائيًا
اكتشاف إضافة أي عنصر تحكم في واجهة المستخدم في أي مكان في شجرة المشهد و ،
في النهاية ، قم بتنفيذ قارئ الشاشة له.

حسنًا ، ها هو المكان الذي أكون فيه بعد بعض عمليات القرصنة المتقطعة في عطلة نهاية الأسبوع:

1. تم نقل المستودع
   هنا . بطاقة تعريف
   بدلاً من ذلك ، أعمل عليها بموجب هوية شركة تطوير الألعاب المحتملة الخاصة بي ،
   لكنني سأطلق المكون الإضافي بموجب ترخيص MIT إذا استمر
   في أي مكان ، لذلك نرحب بالتعاون.
2. من الناحية النظرية ، أقوم بإنشاء فئات برمز خاص بإمكانية الوصول
   كلما تمت إضافة عنصر تحكم إلى الشجرة.
3. قيل على IRC أن سلوك tab / shift-tab محدد بالفعل في ملف
   UI ، ولكن عند بدء تشغيل المحرر ، لا يوجد شيء يركز على علامة التبويب / 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 ،
سوف ينظر جودو إلى يسار العقدة ، ثم فوقها.

هذا هو بالضبط ما كنت سأفعله إذا فعلت ذلك بنفسي ، لذلك يبدو الأمر
الافتراضي هو الكمال.

إذا كان لديك لحظة ، هل يمكنك من فضلك إطلاق المحرر في ملف
مشروع ، ربما يكون مشروعًا فارغًا فقط للاحتفاظ بالأشياء
مماثل ، ونرى تحت أي شروط تعمل علامة التبويب / علامة التبويب shift في المحرر؟
أعتقد أن الشخص الذي ساعد في اختبار الأشياء على IRC ربما يكون قد أنشأ ملفات
التخطيط الخاص ، في حين أن ما أريد القيام به هو اختبار الأشياء مباشرة في
محرر. إذا لم تعمل علامة التبويب / shift-tab ، فحينئذٍ لدي خطأ محدد لتقديمه.
الاعتقاد الحالي الذي أعمل بموجبه هو أنهم لا يعملون
في البداية ، لكن افعل ذلك بعد النقر فوق عنصر.

ومن المثير للاهتمام ، أنه عندما أتتبع focus_exited أحصل على حدث
عندما أضغط على علامة التبويب. لسوء الحظ ، لم أحصل على تركيز آخر مطلقًا ، لذا
بمجرد أن يترك تركيزي عنصر تحكم ، فإنه لا يعود أبدًا إلى عنصر واحد.

شكرا لمساعدتك.

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

إذا كان لديك لحظة ، هل يمكنك من فضلك إطلاق المحرر في ملف
مشروع ، ربما يكون مشروعًا فارغًا فقط للاحتفاظ بالأشياء
مماثل ، ونرى تحت أي شروط تعمل علامة التبويب / علامة التبويب shift في المحرر؟

لا يفعل Tab شيئًا عند الفتح الأول. إذا نقرت في مكان ما لإعطاء التركيز ، فسيبدأ في الدوران حول عناصر التحكم ، لكن لا يبدو أنها كلها مركزة. لا يبدو أن علامات تبويب حاويات الإرساء مركزة ، مما يعني أنه لا يمكن الوصول إلى بعض أجزاء الواجهة عبر لوحة المفاتيح فقط.

شكرا. هذه القضية تخرج عن نطاق السيطرة قليلاً. انا ذاهب الى ملف
آخر يتعلق بالعصف الذهني للأفكار حول تركيز المحرر.

لست متأكدًا مما يجب فعله ، لقد قدمت # 19230 ولكن لم يكن هناك الكثير من النشاط. لقد نشرت أيضًا في المنتدى ونصحت بتقديم مشكلة. أفكار حول أين تطلب المساعدة بعد ذلك؟ لا يمكنني معرفة ما إذا كانت الوظيفة الإضافية الخاصة بي تقوم بالفعل بتعيين التركيز أم لا ، سواء كانت علامة التبويب Tab / Shift-tab تنقلها أم لا ، فلماذا أحصل على حدث focus_exited عند كل ضغطة مفتاح حتى لو لم يكن مفتاح تنقل. لا أريد أن أكون مزعجًا ، لكني أشعر أنني أستطيع أن أحقق الكثير من التقدم من خلال 10 دقائق من المساعدة من أحد مطوري Godot ذوي الخبرة. اعتقدت أنني سأطرح هذه المشكلة وأطرح # 19230 ، الذي يحتوي على قائمة أسئلة أكثر تركيزًا (لا يقصد التورية).

شكرا.

أردت فقط أن يعرف الناس أن هذا المستودع يحرز تقدمًا سريعًا. أستطيع الآن:

• tab / shift-tab حول المحرر ، والحصول على تعليقات حول عنصر التحكم الذي يركز عليه. يوجد حاليًا عرض تقديمي شبه ذكي Button و LineEdit . المزيد في المستقبل القريب.
• السهم إلى اليسار / اليمين في عناصر تحكم LineEdit ، والحصول على تعليقات حول الحرف الذي يتم التركيز عليه. يأتي دعم LineEdit الإضافي بمجرد أن أرى مدى سرعة التعامل مع العلاقات العامة. لقد أرسلت للتو إشارة واحدة تضيف إشارة caret_moved .

مرحبًا بالمساعدة ، على الرغم من العلم بأن هذا الملحق يتطلب الآن إصدارًا من Godot مع العلاقات العامة غير المدمجة. على وجه التحديد ، راجع https://gitlab.com/lightsoutgames/godot-accessibility/issues/1 للحصول على قائمة مرجعية لجميع العلاقات العامة المقدمة وحالة الدمج الخاصة بهم.

إذا كنت ترغب في المساعدة ولكن لا تريد أن تخطو على أي أصابع ، فإن الطريقة الرائعة للقيام بذلك هي بناء وحدة 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.

أي شيء أكثر تعقيدًا ، مثل الأصوات ، يمكنه الانتظار لاحقًا. إذا أراد شخص ما المساعدة وإنشاء واجهة برمجة التطبيقات هذه ، فمن المحتمل أن أجعلها تعمل مع Linux و Android. وإلا فسأصل إلى هذا في النهاية ، على الرغم من أن قارئ الشاشة يأخذ الأولوية بالنسبة لي.

إذا كان بإمكانك إخباري بكيفية تنفيذ واجهات برمجة تطبيقات GDScript الجديدة ، فيمكنني ذلك
تنفيذ ذلك للنوافذ على الأقل.

في 6/12/18 ، كتب Nolan Darilek [email protected] :

أردت فقط أن يعرف الناس أن هذاالمستودع
تقدم سريع. أستطيع الآن:

• tab / shift-tab حول المحرر ، والحصول على تعليقات حول عنصر التحكم
  التركيز. يوجد حاليًا عرض تقديمي شبه ذكي Button و
  LineEdit . المزيد في المستقبل القريب.
• السهم إلى اليسار / اليمين في عناصر تحكم LineEdit ، والحصول على تعليقات حول أي ملف
  الشخصية لها التركيز. سوف يأتي دعم LineEdit الإضافي بمجرد أن أرى كيف
  يتم التعامل مع العلاقات العامة بسرعة. لقد أرسلت للتو واحدًا بإضافة caret_moved
  الإشارة.

نرحب بالمساعدة ، على الرغم من العلم أن هذا الملحق يتطلب الآن إصدارًا من
Godot مع العلاقات العامة غير المندمجة. على وجه التحديد ، انظر
https://gitlab.com/lightsoutgames/godot-accessibility/issues/1 لملف
قائمة مرجعية لجميع العلاقات العامة المقدمة وحالة الدمج الخاصة بهم.

إذا كنت ترغب في المساعدة ولكن لا تريد أن تخطو على أي أصابع ، فهذه طريقة رائعة للقيام بذلك
لذلك سيتم بناء وحدة تحويل النص إلى كلام. الآن هذا الملحق يطبع فقط إلى ملف
وحدة التحكم. ما أريده هو 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 و
ذكري المظهر. وإلا سأصل إلى هذا في النهاية ، على الرغم من قارئ الشاشة
يأخذ الأولوية بالنسبة لي.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/godotengine/godot/issues/14011#issuecomment -396575401

-
وقعت،
إيثين د

انا لا اعرف. أنا أعمى وأتعلم كل هذا أيضًا ، لذلك إذا كنت أتعلم
كيفية بناء وحدة تحويل النص إلى كلام ، فأنا لا أقوم ببناء قارئ الشاشة
وحدة. :) سأتعلم ذلك في النهاية ، لكن يدي ممتلئة
دفع GDScript بقدر ما أستطيع ، ثم التغيير والتبديل في المحرك عندما لا أستطيع
الحصول على شيء من GDScript. هذه العملية برمتها تشبه إلى حد كبير عندما
بدأت في بناء قارئ الشاشة الخاص بي بنظام Android. لم أكن أعرف ما هو
ممكن ، بدأ للتو في اختراق الأشياء ، ولم يكن لديه سوى معنى حقيقي
لما كنت أفعله منذ بضعة أشهر.

وافتراضي هو أنك ستحتاج إلى GDNative ، ما لم يقدم GDScript
نوع من FFI. أعتقد أنك ستنشئ وحدة C / C ++ تستدعي Windows '
واجهات برمجة تطبيقات الكلام وتصدير الوظائف إلى GDScript. ثم سأقبل ذلك
الوحدة النمطية وجعلها تعمل على Linux / Android باستخدام Speech-dispatcher و
نظام تحويل النص إلى كلام (TTS) الأصلي لنظام Android. أفترض أنه يمكنني أيضًا استخدام الويب بشكل جيد
واجهة برمجة تطبيقات TTS لجافا سكريبت. إذا كان GDScript يقدم FFI إلى C / C ++ ، فالرجاء القيام بذلك
دعني أعلم.

شكرا!

سوف أنظر حولي وأرى ما إذا كان بإمكاني تصدير بعض الوظائف باستخدام Tolk
مكتبة للتواصل مع برامج قراءة الشاشة.

في 6/12/18 ، كتب Nolan Darilek [email protected] :

انا لا اعرف. أنا أعمى وأتعلم كل هذا أيضًا ، لذلك إذا كنت أتعلم
كيفية بناء وحدة تحويل النص إلى كلام ، فأنا لا أقوم ببناء قارئ الشاشة
وحدة. :) سأتعلم ذلك في النهاية ، لكن يدي ممتلئة
دفع GDScript بقدر ما أستطيع ، ثم التغيير والتبديل في المحرك عندما لا أستطيع
الحصول على شيء من GDScript. هذه العملية برمتها تشبه إلى حد كبير عندما
بدأت في بناء قارئ الشاشة الخاص بي بنظام Android. لم أكن أعرف ما هو
ممكن ، بدأ للتو في اختراق الأشياء ، ولم يكن لديه سوى معنى حقيقي
لما كنت أفعله منذ بضعة أشهر.

وافتراضي هو أنك ستحتاج إلى GDNative ، ما لم يقدم GDScript
نوع من FFI. أعتقد أنك ستنشئ وحدة C / C ++ تستدعي Windows '
واجهات برمجة تطبيقات الكلام وتصدير الوظائف إلى GDScript. ثم سأقبل ذلك
الوحدة النمطية وجعلها تعمل على Linux / Android باستخدام Speech-dispatcher و
نظام تحويل النص إلى كلام (TTS) الأصلي لنظام Android. أفترض أنه يمكنني أيضًا استخدام الويب بشكل جيد
واجهة برمجة تطبيقات TTS لجافا سكريبت. إذا كان GDScript يقدم FFI إلى C / C ++ ، فالرجاء القيام بذلك
دعني أعلم.

شكرا!

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/godotengine/godot/issues/14011#issuecomment -396669298

-
وقعت،
إيثين د

هذا يبدو مثاليًا تقريبًا. يُرجى إعلامي إذا كان لديك وحدة GDNative
العمل من أجل هذا. إذا لم يكن الأمر كذلك ، فسأقوم بتنفيذ شيء ما لنظام Linux في غضون شهر
أو هكذا ، ربما.

إذا كنت لا ترغب في جعلها وحدة نمطية (والتي تتطلب إعادة تجميع المحرك بالكامل) ، فإن الطريقة الوحيدة للوصول إلى المكتبات الخارجية هي استخدام GDNative. لا يمكنك عمل FFI مع GDScript.

سأضيفه فقط إلى وظائف GDScript العامة. هذا جيد؟

في 6/12/18 ، كتب George Marques [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 مع ملف
مشروع عينة باستخدام الشمعات. إذا بدأت من هناك ، يجب أن أكون قادرًا على ذلك
خذ ذلك وأضف دعم مرسل الكلام. لست متأكدًا من الكيفية التي يضيف بها المرء ، على سبيل المثال ،
JS للتفاعل مع WebSpeech API ، ولكن شيء واحد في كل مرة.

حماقة جيدة. لقد ارتكبت بالفعل وقمت بتحميله إلى مفترق الريبو الخاص بي
كجزء من GDScript. إذا قمت بزيارة https://github.com/ethindp/godot ،
يمكنك أن ترى كيف فعلت ذلك. أعلم ، لقد خرجت عن المألوف ، لكن Tolk ،
حتى في C / C ++ ، ليست مكتبة قائمة على الفصل. حتى الآن (على ما أظن)
يمكنك استدعائه على النحو التالي:

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

لكي يعمل هذا مع قارئ الشاشة ، ستحتاج إلى بعض الإضافات
الملفات (مع قارئ الشاشة):

• JAWS و Window Eyes و ZoomText و System Access: لا شيء يعمل من خلال COM.
• NVDA: NVDAControllerClient32.dll و NVDAControllerClient64.dll
  (https://www.dropbox.com/s/7txp6iyi65sx12z/nvdaControllerClient32.dll؟
  و https://www.dropbox.com/s/y0pdyxhos31hv9n/nvdaControllerClient64.dll؟dl=1)
• قارئات الشاشة دولفين: 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؟
  لم أختبر هذا ، لقد أدرجته للتو. آسف إذا كان ذلك سيئا
  فكرة أم لا. :) لست متأكدا كيف سنحصل
  tts_speak / tts_output / tts_braille للعمل لأنها تتطلب wchar_t.
  يؤدي ذلك إلى تصدير الوظائف التالية:
  tts_load (): تهيئة Tolk عن طريق تحميل الشاشة وتهيئتها
  برامج تشغيل القارئ وإعداد برنامج تشغيل قارئ الشاشة الحالي ، بشرط
  واحد على الأقل من برامج قراءة الشاشة المدعومة نشط. ايضا
  يقوم بتهيئة COM إذا لم يتم تهيئته بالفعل عند الاستدعاء
  مسلك. سيؤدي استدعاء هذه الوظيفة أكثر من مرة إلى تهيئة COM فقط.
  يجب عليك استدعاء هذه الوظيفة قبل استخدام الوظائف أدناه. يستخدم
  tts_is_loaded لتحديد ما إذا تمت تهيئة Tolk.
  tts_is_loaded (): اختبارات إذا تمت تهيئة Tolk. يعود صحيحا إذا
  تم تهيئة Tolk ، خطأ على خلاف ذلك.
  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 أولاً (صواب) أو
  الأخير (خطأ) في قائمة اكتشاف قارئ الشاشة. وضعه في النهاية هو
  الافتراضي وهو جيد لاستخدام SAPI كخيار احتياطي. وضع
  إنها أولاً جيدة لضمان استخدام SAPI حتى عند استخدام قارئ الشاشة
  قيد التشغيل ، ولكن ضع في اعتبارك أن برامج قراءة الشاشة ستظل قيد التجربة إذا
  SAPI غير متوفر. تعمل هذه الوظيفة على تشغيل قارئ الشاشة
  عملية الكشف إذا لزم الأمر. للحصول على أفضل أداء ، يجب عليك الاتصال
  هذه الوظيفة قبل استدعاء tts_load. المعلمات: preferSAPI:
  ما إذا كنت تفضل SAPI على برامج تشغيل قارئ الشاشة أم لا
  الكشف التلقائي.
  tts_detect_screen_reader (): إرجاع الاسم الشائع لملف
  برنامج تشغيل قارئ الشاشة النشط ، إذا تم تعيينه. إذا لم يتم تعيين أي شيء ، يحاول
  اكتشاف قارئ الشاشة النشط حاليًا قبل البحث عن الاسم.
  في حالة عدم وجود قارئ شاشة نشط ، يتم إرجاع NULL. لاحظ أن السائقين
  الكود الثابت للاسم الشائع ، لا يُطلب من قارئ الشاشة
  بحد ذاتها. يجب عليك استدعاء tts_load مرة واحدة قبل استخدام هذه الوظيفة.
  tts_has_speech (): اختبار ما إذا كان برنامج تشغيل قارئ الشاشة الحالي يدعم
  إخراج الكلام ، إذا تم تعيين واحد. إذا لم يتم تعيين أي شيء ، فسيحاول اكتشاف ملف
  قارئ الشاشة النشط حاليًا قبل اختبار دعم الكلام. أنت
  يجب استدعاء tts_load مرة واحدة قبل استخدام هذه الوظيفة.
  tts_has_braille (): تختبر ما إذا كان برنامج تشغيل قارئ الشاشة الحالي يدعم
  إخراج برايل ، إذا تم ضبطه. إذا لم يتم تعيين أي شيء ، فسيحاول اكتشاف ملف
  قارئ شاشة نشط حاليًا قبل اختبار دعم برايل. أنت
  يجب استدعاء tts_load مرة واحدة قبل استخدام هذه الوظيفة.
  tts_output (سلسلة ، منطقي): لإخراج النص عبر الشاشة الحالية
  سائق القارئ ، إذا تم تعيين واحد. إذا لم يتم تعيين أي شيء أو إذا واجهته
  خطأ ، يحاول اكتشاف قارئ الشاشة النشط حاليًا من قبل
  إخراج النص. هذه هي الوظيفة المفضلة لاستخدامها في الإرسال
  نص إلى قارئ الشاشة ، لأنه يستخدم كل المخرجات المدعومة
  الطرق (الكلام و / أو طريقة برايل حسب قارئ الشاشة الحالي
  سائق). يجب عليك استدعاء tts_load مرة واحدة قبل استخدام هذه الوظيفة.
  هذه الوظيفة غير متزامنة. المعلمات: str: نص للإخراج.
  المقاطعة: ما إذا كان سيتم إلغاء أي خطاب سابق أم لا.
  tts_speak (سلسلة نصية): ينطق النص من خلال قارئ الشاشة الحالي
  سائق ، إذا تم تعيين واحد ويدعم إخراج الكلام. إذا لم يتم تعيين أي شيء أو إذا
  واجه خطأ ، يحاول الكشف عن الشاشة النشطة حاليًا
  القارئ قبل التحدث بالنص. استخدم هذه الوظيفة فقط إذا كنت
  تحتاج تحديدًا إلى التحدث بالنص من خلال قارئ الشاشة الحالي
  دون أيضًا تفريزها بطريقة براقة. قد لا تدعم جميع برامج تشغيل قارئ الشاشة
  هذه الوظيفة. لذلك ، استخدم tts_output كلما أمكن ذلك. أنت
  يجب استدعاء tts_load مرة واحدة قبل استخدام هذه الوظيفة. هذه الوظيفة
  غير متزامن. البارامترات: str: text to talk. المقاطعة: سواء أو
  عدم إلغاء أي خطاب سابق أولاً.
  tts_braille (سلسلة نصية): يتم كتابة النص بطريقة برايل من خلال قارئ الشاشة الحالي
  سائق ، إذا تم ضبط أحدهما ويدعم إخراج برايل. إذا لم يتم تعيين أي شيء أو
  إذا واجهت خطأً ، فستحاول اكتشاف ملف
  قارئ الشاشة قبل تفريغ النص المحدد. استخدم هذه الوظيفة فقط
  إذا كنت بحاجة تحديدًا إلى كتابة نص برايل من خلال الشاشة الحالية
  القارئ دون التحدث عنه أيضًا. لا يجوز لجميع برامج تشغيل قارئ الشاشة
  دعم هذه الوظيفة. لذلك ، استخدم tts_output كلما
  المستطاع. يجب عليك استدعاء tts_load مرة واحدة قبل استخدام هذه الوظيفة.
  المعلمات: str: نص إلى برايل.
  tts_is_speaking (): تختبر ما إذا كان قارئ الشاشة مرتبطًا بامتداد
  يتحدث برنامج تشغيل قارئ الشاشة الحالي ، إذا تم تعيينه ودعمه
  الاستعلام عن معلومات الحالة. إذا لم يتم تعيين أي شيء ، فسيحاول اكتشاف ملف
  قارئ الشاشة النشط حاليًا قبل اختبار ما إذا كان يتحدث. أنت
  يجب استدعاء tts_load مرة واحدة قبل استخدام هذه الوظيفة. يعود صحيحا إذا
  يتم نطق النص بواسطة قارئ الشاشة ، ويكون خطأ بخلاف ذلك.
  tts_silence (): يسكت قارئ الشاشة المرتبط بالتيار
  برنامج تشغيل قارئ الشاشة ، إذا تم تعيينه ويدعم إخراج الكلام. إذا
  لم يتم تعيين أي شيء أو إذا واجه خطأ ما ، فسيحاول اكتشاف
  قارئ الشاشة النشط حاليًا قبل إسكاته. يجب عليك الاتصال
  tts_load مرة واحدة قبل استخدام هذه الوظيفة. يعود صحيحا على النجاح ،
  خطأ خلاف ذلك.
  يتمتع! :)

في 6/12/18 ، كتب Nolan Darilek [email protected] :

أعتقد أنه سيكون من الأفضل أن تكون فئة ثابتة مع أعضاء. بمعنى آخر:

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

هذا ، على الأقل ، هو كيف يبدو أن الوحدات الأخرى تفعل ذلك.

يكشف بحث Google السريع عن برنامج تعليمي جميل لـ GDNative مع ملف
مشروع عينة باستخدام الشمعات. إذا بدأت من هناك ، يجب أن أكون قادرًا على ذلك
خذ ذلك وأضف دعم مرسل الكلام. لست متأكدًا من الكيفية التي يضيف بها المرء ، على سبيل المثال ،
JS للتفاعل مع WebSpeech API ، ولكن شيء واحد في كل مرة.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/godotengine/godot/issues/14011#issuecomment-396753704

-
وقعت،
إيثين د

لا يجب أن يكون Tolk نفسه قائمًا على الفئة لتصدير واجهة قائمة على الفئة. ألق نظرة على البرنامج التعليمي للحصول على مثال خالص قائم على C لإنشاء فئة GDScript. الضربة الأولى على Google لـ "برنامج تعليمي gdnative".

لن أتمكن من استخدام هذا لأن لدي بالفعل شوكة محرك بإشارة مخصصة. أرغب في تجنب تعديل المحرك ما لم يكن ذلك ضروريًا ، وبالحد الأدنى من الطرق الضرورية لبناء إمكانية الوصول في الوظائف الإضافية.

بداية جيدة ، بالرغم من ذلك.

آه ، إلى الجحيم ، سأقوم بطعنة فيه. :) ماعدا انها
ستكون في Rust ، إذن هذا كل شيء. يبدو أن هناك صدأ تولك
ربط. لا يمكنني عمل منفذ Windows ، لذلك يجب عليك ملء تلك
الفراغات بنفسك.

هناك صدأ Tolk ملزم؟ أين؟ لم أتمكن من العثور عليه ... سأبحث عنه. :)

في 6/12/18 ، كتب Nolan Darilek [email protected] :

آه ، إلى الجحيم ، سأقوم بطعنة فيه. :) ماعدا انها
ستكون في Rust ، إذن هذا كل شيء. يبدو أن هناك صدأ تولك
ربط. لا يمكنني عمل منفذ Windows ، لذلك يجب عليك ملء تلك
الفراغات بنفسك.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/godotengine/godot/issues/14011#issuecomment -396768693

-
وقعت،
إيثين د

إنها المرة الأولى التي يتم فيها البحث عن "tolk rust" بالنسبة لي على Google. بالإضافة إلى ذلك
يظهر على cargo search tolk ..

على أي حال ، سؤال جودو آخر. إذا كان لدي وحدة GDNative
يعرض فئة TTS لـ GDScript ، كيف يمكنني التأكد من أن هذا الفصل هو
متاح عالميًا؟ لقد قمت بإنشاء ملف .gdnlib الخاص بي ، لكن البرنامج التعليمي في
http://docs.godotengine.org/en/3.0/tutorials/plugins/gdnative/gdnative-c-example.html
يظهر فقط رسمًا عند إنشاء ملف .gdns. ماذا يفعل ملف .gdns
يبدو الملف مثل حتى أتمكن من إنشاء واحد باليد؟ يبدو أنني أحمل الفصل
في عبر preload بدلاً من مجرد إتاحته عالميًا ، هذا هو الحال
دقيق؟

شكرا.

إذا كان لدي وحدة GDNative تعرض فئة TTS لـ GDScript ، كيف يمكنني التأكد من أن الفصل متاح عالميًا؟

ربما من الممكن إضافته كتحميل تلقائي مفرد. في الواقع ، هناك مكان لأفراد 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 رئيسي إلى حد ما ، خلال وقت لم تكن فيه واجهات برمجة التطبيقات لإمكانية الوصول في Android رائعة جدًا. أحب أن أعتقد أنني على دراية إلى حد ما بما يجعل واجهة برمجة تطبيقات الوصول جيدة ، كما أنني حساس لاحتياجات الأداء لنظام التشغيل الأساسي وتجربة المستخدم. في النهاية ، تخليت عن المشروع إلى حد كبير لأنه كان من الصعب إنشاء واجهة برمجة تطبيقات وصول غير مكتملة ، واضطررت إلى اللجوء إلى الاختراق عند الاختراق لجعل Spiel مفيدة.

جودو هو نوع من نفس الطريقة. هناك في الواقع ما يكفي من إشارات واجهة المستخدم لواجهة برمجة تطبيقات وصول متطورة بشكل معقول. لكني سأحتاج إلى المزيد من المعلومات الإضافية للحصول على معلومات كافية عن الأداة الإضافية الخاصة بإمكانية الوصول. على وجه التحديد ، كان من الممكن أن يجعل # 19522 الأمور أسهل ، لكن طُلب مني إعادة بناء ذلك في كود خاص بالملحق. الآن # 19814 قيد المناقشة أيضًا. أفهم عدم الرغبة في إضافة مليون إشارة ، لكنني أحاول أن أكون حساسًا لذلك. يجب أن تظل جميع تغييراتي محصورة في طبقة واجهة المستخدم ، ولا يمكنني تخيل أن يكون لهذا تأثير كبير ما لم يكن شخص ما يلعب لعبة كتابة حيث يلزم كل جزء أخير من الأداء لتقديم EditLine عند 120 FPS. :) ومع ذلك ، فإن النواة ستحتاج إلى بعض الإضافات إذا كان الناس يريدون حقًا حدوث ذلك.

وفي نهاية اليوم ، أردت فقط إنشاء ألعاب ، لذا إذا كان عليّ الدفاع بقوة عن كل العلاقات العامة بمفردي دون الكثير من الدعم من الأشخاص الذين يرغبون في رؤية هذا يحدث ، أو إذا كنت أقوم ببناء جميع الإضافات بنفسي ، أنا لا أفعل ذلك حقًا. لا أحاول إثارة الأمور ، أردت فقط ترك تحديث هنا إما لإلهام نوع من المناقشة العملية حول كيفية تحقيق ذلك إذا كان مطلوبًا حقًا ، أو للسماح لأي شخص يفكر في تناوله بمعرفة أنه قد يكون هناك بعض إدفع إلى الخلف.

قد تتم مناقشة أصوات مثل # 19840 في اجتماع العلاقات العامة القادم. إذا كان الناس يريدون حقًا أن يكون Godot متاحًا بشكل أكبر ، فسأقدر مناصرين أكثر مني في ذلك الاجتماع. لا أعرف حتى متى يكون الاجتماع المذكور ، أو ما إذا كان لا يتعارض مع اجتماعات العمل الفعلية التي أحتاجها لحضور وظائف يومية. :) أدرك فقط أنني لا أستطيع القيام بذلك بمفردي ، وسأحتاج إلى بعض المساعدة من أي أطراف معنية.

شكرا.

ndarilek إذا كنت لا تزال مهتمًا بالعمل على هذا ، فأود مساعدتك.

أعلم أنه قد مر وقت طويل ، لكنني سأحاول التقاط هذا مرة أخرى. لقد أوصى الناس بمجموعة كبيرة واحدة مع جميع إصلاحات إمكانية الوصول اللازمة للمحرك ، لذلك سأعطي هذه اللقطة وآمل ألا يطلب مني أحد تقسيمها. :)

لكنني أضرب بعض الحدود في درجات الحرارة لما يمكنني فعله كشخص كفيف. في الوقت الحالي ، لدي واجهة كلام تتيح لي التنقل حول المحرر ، والتفاعل مع القوائم ، والتفاعل مع / تغيير بعض إعدادات المشروع ، إلخ. البرامج التعليمية المستندة إلى ، ولكن لم يتم فتح ما يكفي من الواجهة. هل يمكن لأحد أن يجيب على ما يلي:

• أين توجد علامة تبويب الإدخال ضمن المشروع -> إعدادات المشروع؟ أرى شجرة من الخيارات - التكوين والتشغيل والمحرر والمكونات الإضافية للمحرر وما إلى ذلك ولكن لا يوجد مخطط إدخال. أحاول الحصول على قائمة بأسماء الإجراءات حتى أتمكن من رؤية ما هو متاح. أتساءل عما إذا كان هذا في جزء من الواجهة لم أقم بإتاحته بعد ، على الرغم من أنني مندهش من عدم وجوده في شجرة الفئات.
• هل يمكنني تشغيل إجراء برمجيًا؟ على وجه الخصوص ، تطلب مني بعض البرامج التعليمية النقر بزر الماوس الأيمن فوق عقدة ، لكنني لا أرى طريقة للقيام بذلك من لوحة المفاتيح. أرغب في ربط مفتاح القائمة بالنقر بزر الماوس الأيمن حتى أتمكن من اتباع بعض الخطوات في هذا البرنامج التعليمي .
• بدلاً من ذلك ، هل هناك طريقة ملائمة للوحة المفاتيح للنقر بزر الماوس الأيمن ، وقائمة باختصارات لوحة المفاتيح في أي مكان؟ ربما تكون مشكلتي هي أن القائمة تعمل ، لكن ليس لدي إمكانية وصول كافية للمحرك مكشوفة لمعرفة ذلك.

و malcolmhoward ، إذا كان عرضك للتعاون لا يزال مفتوحًا بعد عام ، فأنا حزين. أنا على استعداد لإعطاء هذه لقطة أخرى. أرى أنك حاولت دمج بعض دعم المهرجان. إذا كنت مهتمًا بمواصلة هذا العمل ، فلدي مكون إضافي لـ TTS يعتمد على Rust والذي يدعم حاليًا Speech Dispatcher ضمن Linux و Tolk ضمن Windows. أرغب في تنويع هذا الدعم (واختبار دعم Windows Tolk لهذه المسألة ، لأن Linux هو منصتي الأساسية.)

شكرا.

تجاهل سؤالي الأول أعلاه. اكتشفت وأضفت دعمًا يمكن الوصول إليه إلى TabContainer . يمكنني الآن العثور على علامة التبويب "خريطة الإدخال" وتحديدها. لا يزال مرتبكًا بعض الشيء حول ما إذا كانت هناك طريقة ملائمة للوحة المفاتيح للنقر بزر الماوس الأيمن فوق العقد في شجرة المشهد ، أو إذا فشلت في ذلك ، كيف يمكنني تشغيل هذا الإجراء بشكل برمجي.

ما سيكون مفيدًا للغاية هو إذا كان بإمكاني إعداد مكالمة مشاركة الشاشة مع شخص على دراية بتطوير Godot لمساعدتي في بعض المهام الأولية. الأشياء التي أود تحقيقها:

• إنشاء حقل لعبة فارغ أولي.
• إنشاء عقدة / مشهد لاعب وإضافته إلى المنطقة.
• تعلم كيفية الوصول إلى الخصائص الموجودة في كل عقدة / مشهد حتى أتمكن من تعيينها دون سحب / إسقاط.
• تعلم كيفية إرفاق البرامج النصية بالعقد الخاصة بي. لقد حصلت على عدد كافٍ من الإعدادات التي يمكن الوصول إليها لدرجة أنني تمكنت من ضبط المحرر الخارجي الخاص بي على gedit ، لذلك بمجرد معرفة كيفية إرفاق برنامج نصي بعقدة وتعديل هذا البرنامج النصي ، عدت إلى المحرر الذي يمكن الوصول إليه لهذه المهمة.

إذا كان بإمكاني فعل هذه الأشياء ، أعتقد أنه يمكنني إحراز تقدم أسرع بكثير. حتى اكتشاف مشكلات الوصول وتنفيذ أي مما سبق سيساعدني في تركيز جهودي. في الوقت الحالي ، أنا فقط أقوم بالرمي ، وأحاول العثور على الأشياء التي لا يمكن الوصول إليها وجعلها تعمل عندما يكون ما أحتاج إليه هو التركيز على المهام الخاصة بي والتفرع من هناك.

شكرا.

ndarilek نعم ، ما زلت أرغب في المساعدة في هذا العمل. سأحتاج إلى أسبوع أو نحو ذلك لاستعادة قدمي مع كل ما يتعلق بهذه المشكلة ، وسأكون سعيدًا بعد ذلك للانضمام إلى مكالمة. لست خبيرًا في المحرك ، لكنني أعتقد أنني صممت نماذج أولية كافية للعبة لنبدأ.

لقد اكتشفت نوعًا ما كيفية إضافة البرامج النصية. قررت البدء في بناء أ
لعبة بسيطة جنبًا إلى جنب مع المكون الإضافي الخاص بإمكانية الوصول حتى يتمكن المتعاونون من ذلك
لديك إطار مرجعي مشترك أكبر لمناقشة قضايا إمكانية الوصول.
لقد أنشأت عقدة Player Area2D ، وكشفت الكثير من علامات الجدولة حول
زر لإضافة برنامج نصي ، والذي فتح Gedit وكان مفيدًا جدًا
خبرة. تقدم!

الكويكبات هي نوع من ذهابي لتعلم محرك أو إطار عمل ، لذلك
بعد ذلك اعتقدت أنني سأضيف مشهدًا رئيسيًا لتلخيص كل منطق اللعبة
لا يمكن أن يتناسب مع نوع كيان واحد. لقد خلقت مشهدًا ، جلس
نوع عقدة الجذر الخاصة به إلى Node ، ولا يمكنني العثور على ملف
زر لإضافة نص. ليس لدي أي فكرة عما إذا كان من الممكن إضافة
سيناريو لهذا المشهد بالذات لسبب ما ، وما إلى ذلك.

قمت بتثبيت لاعب عندما كنت طفلًا في المشهد ، ويمكنني رؤية اللاعب
والزر الخاص به لمسح البرنامج النصي. لكن ليس لدي أي فكرة عن سبب عدم تمكني من إضافة ملف
البرنامج النصي إلى العقدة الجذرية للمشهد الرئيسي فقط.

عملي هنا
لأي شخص مهتم بالمتابعة. قد تحتاج أيضًا إلى TTSالبرنامج المساعد على الرغم من أنه قد يعمل
بدونها أيضًا وقم فقط بطباعة الأخطاء كلما حاولت التحدث
شيئا ما. ولكن في كلتا الحالتين ، ستؤدي إزالة المكوّن الإضافي لإمكانية الوصول
ربما تكشف لماذا لا يسمح لي إعداد العقدة البسيط بإرفاق ملف
السيناريو الرئيسي. ربما لم أقم باختيار المشهد الرئيسي بشكل صحيح
في الشجرة ، وفي هذه الحالة تكون هذه التعليقات مفيدة.

أيضًا ، هل من العدل أن نقول إن العديد من هذه الأزرار في المحرر موجودة
أشرطة الأدوات؟ أحاول إيجاد وسيلة أسهل للملاحة
من خلال كل هذه الأزرار عبر لوحة المفاتيح ، لأن
الجدولة / التنقل من خلالهم جميعًا بطيء بعض الشيء. إذا كان الكثير في
أشرطة الأدوات ، يمكنني تنفيذ الجدولة بين أشرطة الأدوات و
يمين / يسار - سهم بين مكونات شريط الأدوات.

لا تختلف العقدة الرئيسية في الشجرة عن العقد الأخرى بقدر ما أستطيع ، باستثناء حقيقة أنها محددة عندما يتم فتح علامة تبويب المشهد الجديد لأول مرة عند الإنشاء.

حسنًا ، المزيد من التقدم. لقد كشفت عن المزيد من الخصائص في Tree للكلام. أنا
اعتقدت أن السهم لأعلى / لأسفل كانا يتنقلان داخل الشجرة ، لكنهما
يبدو أنه يتم اختيار العناصر. أعتقد أن ما يحدث هو أنني أملك
تم تحديد عقد مشهد متعددة ، لذلك لا يتم تحديد الزر لإضافة نص برمجي
يظهر. يمكنني نوعًا ما تحويل الشجرة إلى حالة يوجد فيها عنصر واحد فقط
تم تحديده عن طريق توسيع / ​​طي العناصر ، وعند هذه النقطة يتم إضافة برنامج نصي
يظهر الزر الرئيسي.

هل يمكن لأي شخص أن يشرح منطق الضغط على الأسهم لأعلى / لأسفل في ملف
شجرة؟ افترضت أنها انتقلت إلى عنصر واحد واخترت أيًا كان
مركزة ، لكن في شيء مثل شجرة المشاهد التي أفترض أنها تدعمها
متعدد التحديد ، أتساءل عما إذا كان يتصرف بشكل مختلف؟ هل يوجد
ضغطات مختلفة للتنقل في شجرة واختيار واحدة
العنصر ، أو هل هناك شيء لإلغاء تحديد العنصر الحالي؟

شكرا.

الكثير من التقدم الجيد أمس. مفتش الممتلكات لديه بعض
الأشياء القابلة للطي التي لا تحتوي على إمكانية التركيز أو التفاعل على لوحة المفاتيح ،
لكنني اكتشفت هؤلاء وفعلت بعض السحر الأسود بمحاكاة الفأر
نقرات ، لذا يمكنني الآن توسيع / ​​تصغير خصائص العقدة عبر لوحة المفاتيح.
يمكن الوصول إلى حوالي 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 وأنا أتلقى إعلانًا عن حقيقة ذلك
هناك أزرار.

شكرًا لتوجيهي إلى مكان الإغلاق TextureButton
تم التنفيذ - أجد صعوبة في تتبع بعض هذه العناصر في
مصدر ، وأنا أحاول تعيين حقول التعريف على بعض هذه حتى البرنامج المساعد الخاص بي
يمكن أن توفر أوصاف / تسميات يمكن الوصول إليها.

لقد أضفت للتو طريقة get_button_tooltip(...) إلى TreeItem لعرضها
تلميحات الأزرار ، نظرًا لأن الأزرار الموجودة في الأعمدة يتم إرجاعها فقط بتنسيق
Texture كائنات ولا توجد طريقة للوصول إلى تلميح الأدوات المرتبط
عبر ذلك. آمل ألا يكون هذا دمجًا مرفوضًا عند إرسال ملف
أكبر العلاقات العامة لهذا البرنامج المساعد.

شكرا لك مرة أخرى.

لقد قمت الآن بتنفيذ القليل من القرصنة التي تتيح لك السهم الأيمن إلى ملف
عمود من الأزرار في شجرة ، استخدم Home / End للتنقل بينها ، واستخدم
مساحة لتفعيل واحدة. من خلال هذه الآلية ، يمكنني الآن تنشيط مربع الحوار
لإضافة مفتاح إلى عمل تم إنشاؤه.

لدي سؤال حول كيفية عمل هذا ، مع ذلك ، معقد بسبب الحقيقة
لا يمكنني استخدام لوحة المفاتيح لاستكشاف مربع الحوار هذا. هل يعترض
مجموعة واحدة من ضغطات المفاتيح ، ثم دعني أؤكد / ألغي ذلك؟ أو يفعل ذلك
اعترض كل مفتاح يتم إرساله إليه ، واجعل المفتاح الأخير ما هو
في نهاية المطاف ملزمة بالعمل؟

أي أقول إنني أضفت إجراءً ، "Speak_coordinates" ، والذي أريد الالتزام به
"ج". إذا ظهر مربع الحوار هذا وضغطت على "c" ، فحاول الضغط على مفتاح tab إلى
زر موافق ، هل هو:

أ) ربط "ج" بالإجراء ، متجاهلاً ضغطات المفاتيح اللاحقة؟

ب) ربط "c" ، ثم "tab" عندما أحاول الانتقال إلى الزر "موافق"؟

نرحب بالأفكار حول كيفية التعامل مع هذه الحالة المتطورة. يمكنني إضافة meta
خاصية هذا الحوار المحدد لإخبار المكون الإضافي إما فقط
دعم التقاط أول InputEvent أو ، إذا حدث ذلك بالفعل ،
إعادة توجيه التركيز إلى زر التأكيد بعد الحدث الأول هو
التعامل معها. لكنني بحثت في الكود ، ولم أفعل ذلك على الفور
مؤكد ما إذا كان "أ" أو "ب" أو شيء مختلف تمامًا صحيحًا.

شكرا.

ndarilek عند تشغيل الزر الذي يضيف حدث إدخال جديد ، سيقدم قائمة منسدلة بأربعة خيارات:

• مفتاح
• زر الفرح
• جوي أكسيس
• زر الفأرة

يعرض خيار المفتاح مربع حوار مشروط (أعلى الخيار الحالي) يطلب من المستخدم الضغط على مفتاح (أو مفتاح به معدّلات ، على سبيل المثال Ctrl + K). إذا ضغط المستخدم على مفتاح آخر قبل التأكيد ، فسيحل محل المفتاح المحدد حاليًا في مربع حوار التأكيد. سيستمر مربع الحوار هذا في الاستماع إلى أحداث لوحة المفاتيح حتى يؤكد المستخدم بالنقر فوق "موافق" أو الإلغاء بالنقر فوق "إلغاء" في مربع الحوار. نظرًا لأن مربع الحوار هذا يستمع لجميع المفاتيح (بما في ذلك المفاتيح "الخاصة" مثل Tab) ، فإن التنقل باستخدام لوحة المفاتيح غير ممكن. هذا لأن مربع الحوار سيحل محل الخيار الحالي بعلامة تبويب. وبالمثل ، لا يمكن استخدام مفتاح Escape لإلغاء مربع الحوار. يجب أن نهدف إلى تحسين قابلية استخدام هذا الحوار:

في المقابل ، لا تستمع الأنواع الأخرى (Joy Button و Joy Axis و Mouse Button) إلى الأحداث ، بل يستخدمون القوائم المنسدلة في مربعات الحوار المشروطة بدلاً من ذلك.

فهمتك. لذلك أعتقد أنه ، لأغراض الوصول ، سوف بشكل تعسفي
قرر أن المفتاح الأول في مربع الحوار هذا "يفوز" عندما يكون المكون الإضافي
قيد التشغيل ، لذا فإن ضغطات tab / enter / escape اللاحقة تفعل ما يفترض أنها
ل. لقد اكتشفت أن إعادة توجيه التركيز إلى الزر "موافق" عندما تكون في هذا
يؤدي الحوار إلى عدم حفظ أي مفتاح مستخدم لتشغيل الزر.
على سبيل المثال ، إذا استخدمت Space لتشغيل مربع الحوار للظهور ، فعندئذٍ أدخل إلى
قم بتشغيل الزر "موافق" ، يتم حفظ المساحة كمفتاح ، وليس مفتاح الإدخال.

إذن هذا هو السلوك الذي أشهده الآن ، وأنا أتساءل عما إذا كان هناك أحد
لديه أي أفكار حول ما يجب فعله حيال ذلك. أقوم بتشغيل الزر الذي يفتح
مربع الحوار عند الضغط على "ui_accept" ، لذلك قم بإعداد Space أو Enter افتراضيًا. عندما
قم بتشغيل مربع الحوار ، أيًا كان المفتاح الذي أستخدمه لتشغيل مربع الحوار في الظهور
هو مفتاح الأمر. لذلك على النحو الوارد أعلاه ، إذا استخدمت الفضاء لبدء التشغيل
ui_accept ، و Enter لإغلاق مربع الحوار ، يتم تعيين الأمر الخاص بي على Space.
وبالمثل ، إذا قمت بتشغيل مربع الحوار مع إدخال واستخدام Space to
اضغط على زر موافق ، الأمر مرتبط بـ 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 / قارئ الشاشة بذلك أم أننا سنحتاج إلى تعليق توضيحي (ربما في "meta")؟

إذا كنت تقصد تحديد العقدة التي يتم التركيز عليها حاليًا ، فأنا أتتبعها
focus_entered والكثير من الإشارات الأخرى للإبلاغ عن التغييرات عبر الكلام.

وأنا أقوم بمحاكاة نقرات الماوس اليسرى ، لذلك من المحتمل أن أتفرع إلى
النقر بزر الماوس الأيمن قريبًا. رغم ذلك ، بعد العثور على قائمة اختصارات لوحة المفاتيح
في المحرر مع أزرار البرنامج النصي / المشهد الجديد ، هذا ليس كذلك
حرجة على الفور.

تم العثور على حل مخترق. الظرف الوحيد الذي وجدت فيه حتى الآن
يتم التركيز على مربع الحوار هذا لتعيين اختصارات لوحة المفاتيح على AcceptDialog . لذا
إذا حدث ذلك ، فأضيف مؤقتًا ونشوت لمدة 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 / Projects / 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'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: // التي تفترض مواقع في
الدقة: // godot-tts / target / debug. لا أريد أن أفرض تخطيط مشروع على
أي شخص ، لذلك أتساءل ما إذا كان أي من هذه المسارات يمكن أن يكون نسبيًا؟

شكرا.

• هل هناك طريقة معيارية لإنشاء أرشيف للثنائيات المترجمة
  متاح للمكونات الإضافية / الألعاب الأخرى لاستخدامها؟ من المفترض أن الناس ليسوا كذلك
  من المتوقع أن تبني مكتبات GDNative لجهات خارجية في الحالات التي تكون فيها
  التصدير إلى منصات أخرى. أو هي عبارة عن شبكة GDNative سابقة الإنشاء من جهات خارجية
  الإضافات ليست شيئا؟

لسوء الحظ ، لا يوجد معيار لذلك حتى الآن ، لذلك سيتعين عليك تجميع المكتبات وإتاحتها باستخدام إصدارات GitHub أو ما شابه ذلك.

• لدي const TTS = preload("res://godot-tts/godot_tts.gdns") في
  النصي. هذا يفترض موقعًا محددًا لمكتبة المكونات الإضافية الخاصة بي. وبالمثل ، فإن
  المكتبات نفسها لها مسارات res: // التي تفترض مواقع في
  الدقة: // godot-tts / target / debug. لا أريد أن أفرض تخطيط مشروع على
  أي شخص ، لذلك أتساءل ما إذا كان أي من هذه المسارات يمكن أن يكون نسبيًا؟

لا أعتقد أنه يمكنك جعل مكتبة GDNativeLibrary تستخدم المسارات النسبية (إلا إذا قمت بإنشائها في وقت التشغيل ، ولكن هذا يبدو متضمنًا تمامًا). ومع ذلك ، غالبًا ما توجد الوظائف الإضافية في res://addons ، وهو الموقع القياسي الذي تستخدمه مكونات المحرر الإضافية. لذلك ، يمكنك أن تطلب من المستخدمين وضع كل شيء في res://addons/godot-tts ، والذي يجب أن يلعب بشكل جيد مع معظم المشاريع.

آه ، حسنًا ، لذلك قم بشكل أساسي بإنشاء إصدار GitHub أو ما يعادله يحتوي على ملف
ثنائيات / مستندات مسبقة الصنع / أيًا كان ، وشحن كل ما تم تكوينه إليه
أوصي واستخدم الدقة: // 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 ) في المفتش.

من الأعلى يحتوي المفتش على ما يلي:
مفتش | العقدة (هاتان علامتا تبويب)
[اسم العقدة التي تفحصها ، على سبيل المثال "علامة"]
مربع نص لتصفية الخصائص
[عنوان Script Variables (اختياري) ، مع سهم للتصغير]
[تظهر أي متغيرات نصية تم تصديرها هنا]
[فئة العقدة التي تقوم بفحصها ، مثل Node2D]
[رأس التحويل - بسهم صغير يتيح لك طي القسم]
تسمية الموضع - يتم تقديمها إلى يسار المربعين اللذين يصنعهما EditorPropertyVector2
درجة الاستدارة - كما سبق ، إلى يسار مربع إدخال نص واحد
تسمية المقياس - مثل الموضع ، يتم تسمية المربعين x ، y لذلك نفس الموضع
[رأس الفهرس Z]
[فئة فائقة من العقدة التي تقوم بفحصها ، على سبيل المثال CanvasItem في حالة وجود Node2D]
[رأس الرؤية ، مع سهم ...]
[تسمية مرئية بجوار مربع اختيار]
[اثنين من محددات اللون]
[اعرض خلف التصنيف الرئيسي بجوار مربع اختيار]
[قناع الطبقة - حاوية معقدة مليئة بصناديق صغيرة جدًا]
[رأس المادة ، مع سهم ...]
[تسمية العقدة] - إنها فئة فائقة الجودة ترث منها كل عقدة ، لذا فهي دائمًا في الأسفل
يحتوي هذا القسم دائمًا على رأسين ، كلاهما به أسهم قابلة للطي:
[وقفة - قائمة منسدلة]
[البرنامج النصي - قائمة منسدلة تتيح لك تحديد برنامج نصي]

على سبيل المثال ، العقد ثلاثية الأبعاد ، يمكن أن يصبح المفتش معقدًا للغاية - كان ذلك مجرد مثال بسيط على Node2D وصفته ، وأعتقد أن أفضل رهان لك هو بطريقة ما عمل اختصار للوصول بسرعة إلى الأشياء الأكثر أهمية - قسم التحويل و Pause / Script في في الجزء السفلي ، ويمكنك دائمًا التنقل بسهولة إلى الخصائص التي تم تصديرها لأنها في الجزء العلوي.

ملاحظة: إذا حددت علامة التبويب Node في الأعلى ، فإنها تفتح قائمة مختلفة تمامًا بدلاً من المفتش.

PPS. إذا قمت بتصفية الخصائص ، فلديك فقط التسميات ، على سبيل المثال 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/ editor_inspector.cpp # L865 -L873

يحتوي هذا المحرر المضاف على سلسلة label ، والتي سيتم تمريرها إلى عقد EditorProperty: https://github.com/godotengine/godot/blob/24e1039eb6fe32115e8d1a62a84965e9be19a2ed/editor/editor_inspector.cpp#L1320 -L1320

أخيرًا ، يتم استخدام سلسلة label هذه لملء عقدة Label باستخدام EditorProperty::set_label_reference ، ولكن فقط إذا تم تعطيل تحرير Vector2 الأفقي: https://github.com/godotengine/godot/blob/24e1039eb6fe32115e8d1a62a84965e9be19a2ed/ editor / editor_properties.cpp # L1178

بخلاف ذلك ، سيتم استخدام EditorProperty::set_bottom_editor لوضع المحرر أسفل الملصق: https://github.com/godotengine/godot/blob/24e1039eb6fe32115e8d1a62a84965e9be19a2ed/editor/editor_properties.cpp#L1158

لدي الآن مفتاح القائمة الذي يقوم بتشغيل النقرات اليمنى. يبدو أن هذا يسمح
تفاعل برنامجي مع الصفوف الموجودة في الأشجار.

لقد أصلحت أيضًا بعض المشكلات المتعلقة بحساب النص لعناصر PopupMenu . هذه
له فائدة إضافية تتمثل في أن العديد من العناصر التي اعتقدت أنها غير مصنفة هي في الواقع.

الآن يمكن الوصول إلى عناصر قائمة النقر بزر الماوس الأيمن في الأشجار ، أو على الأقل
جزئيا. يبدو أنني أواجه بعض المشكلات الفردية
صعبة التشخيص.

متوجه إلى هناك...

أعدك بعدم اختطاف هذه المشكلة لهذا الغرض ، ولكن أين ملف
أفضل مكان للحصول على مساعدة في الأسئلة العامة حول استخدام المحرك؟

قبل أيام قليلة ، اكتشفت أن تدفقات الصوت ثنائية الأبعاد تفترض مسبقًا
أنه يتم انتقادهم / إضعافهم من مركز الشاشة ، ولا يأخذون
التناوب في الاعتبار. هذا ليس ما أريده من لعبة صوتية من أعلى إلى أسفل
والتي سيكون لها دوران ، وربما مصادر صوت خارج الشاشة مسموعة في
المسافة ، وما إلى ذلك ، يبدو أن مستندات منفذ العرض تشير إلى أن الصوت ثلاثي الأبعاد هو
ممكن حتى بالنسبة للعقد ثنائية الأبعاد ، لكن ليس من الواضح ما إذا كان بإمكاني إضافة عنصر ثلاثي الأبعاد
دفق المشغل إلى العقد ثنائية الأبعاد ومزامنة مواضعها ، إذا اضطررت لذلك
قم بمزامنة الموضعين X و Z يدويًا مع 2-DX / Y وقم بتثبيت الدفق
Y إلى 0 ، إذا كان علي معرفة كيفية استخدام كاميرا ortho والعرض
كائنات ثلاثية الأبعاد ثنائية الأبعاد ، إلخ.

سألت
هذه
وحاول الإرسال
هذه
على Reddit ، لكن السابق ليس لديه ردود والأخير غير مرئي.
لا أعرف ما إذا لم أحصل على Reddit ، وما إذا كنت بحاجة إلى الموافقة ، وما إلى ذلك.

على أي حال ، لا أريد تحويل هذه المشكلة إلى موضوع دعم ، لكنني كذلك
باستخدام Godot بطريقة غير عادية ، وقد يكون من المستحيل حتى
بعد كل هذا العمل. أنا مستعد لذلك - قررت أن أعطي
شهرًا لدفع هذا إلى الأمام ومعرفة مدى تقدمي معه - لكن جزء منه
للنجاح هنا يتضمن معرفة ما إذا كان ما أريده هو زوجي
يمكن تحقيقه حتى مع إمكانية الوصول. وإذا كان بإمكاني إنشاء لعبة صوتية
بيئة التطوير ، سأقوم بتجميع المواد لعرضها
للآخرين كيفية القيام بذلك ، لذلك آمل أن تساعد ما تعلموه الآخرين. لكن أنا
تواجه صعوبة في الحصول على إجابات لهذه الأسئلة المتخصصة ، وذاك
يبدو أنه عنق الزجاجة هذا الأسبوع.

في أخبار أخرى ، أعمل أيضًا على أتمتة إصدارات Windows من TTS
المكون الإضافي ، وقمنا بتجميع مشروع بدء سهل الوصول إليه
من السهل على حد سواء عرض عملي وإنشاء بيئة يسهل الوصول إليها. مريض
التحديث عندما يكون لدي بنيات ثنائية من البرنامج المساعد TTS متاحة للتنزيل.

شكرا.

تم طلب إضافة عقدة Listener2D في https://github.com/godotengine/godot-proposals/issues/49. سيسمح لك بتهيئة المكان الذي يتم فيه الاستماع إلى الصوت في مشهد ثنائي الأبعاد ، كما هو الحال بالفعل ثلاثي الأبعاد باستخدام عقدة المستمع.

يمكنني تأكيد ظهور منشور Reddit على أنه تمت إزالته ، ولا أعرف السبب. لقد وافقت عليه يدويًا ، ولكن من المحتمل ألا يظهر في الصفحة الأولى كما تم نشره بالأمس. حاول نشره مرة أخرى ، يجب أن يكون جيدًا في الوقت الحالي :)

لاف ، محبط للغاية. أعدت للتو المشاركة ، وتم عرضها في علامة تبويب خاصة ،
يظهر كما تمت إزالته مرة أخرى.

شكرا على رابط الاقتراح.

آسف لاستخدام هذه القضية للحصول على دعم مثل هذا.

تباطأ التقدم قليلاً بينما حاولت خوض معركة مع Appveyor للبناء
المكون الإضافي TTS تحت Windows. لقد تخليت منذ ذلك الحين عن تلك الفوضى الساخنة ، و
من المحتمل أن يقوم بتزويد Windows VM الخاص بي في وقت ما قريبًا وإعداد ملف
عداء GitLab CI. إذا كان لدى أي شخص جهاز Windows VM احتياطي يجلس عليه
لهذا الغرض ، سأكون ممتنًا لذلك.

اللوحات الآن قابلة للتركيز. يعمل هذا على إصلاح مشكلة الأسبوع الماضي حيث يتم إنهاء ملف
اللعبة في المحرر حطمت تركيز لوحة المفاتيح.

لقد قمت أيضًا بإعادة تشكيل المكون الإضافي TTS قليلاً لتوجيه المكالمات من خلال TTS.gd
النصي. في الوقت الحالي ، يرسل هذا جميع المكالمات إلى مكتبة Rust الأصلية ، ولكن
قد ترسل الإصدارات المستقبلية مكالمات إلى وحدة Java / Kotlin على Android ،
إلخ.

أنا أيضًا أقوم ببعض العمل في أول لعبة غودو ، صوت مكاني
نسخة من الكويكبات. قتل الإلهاء Appveyor الأسبوع الماضي التقدم
في هذا المجال ، لكنني آمل أن أصل إليها أكثر هذا الأسبوع. يعمل على
التنقل ، والالتفاف ، والتحدث عن الإحداثيات / العنوان ، وما إلى ذلك
الاختراق حول عدم وجود صوت مكاني ثنائي الأبعاد ، والذي أعتقد أنني قمت به ولكن
لم تختبر بعد.

francipvb هل حاولت تثبيت Clang / LLVM؟ أنا في الواقع أقوم بمحاولة بناء أحدث godot-tts تحت Windows أيضًا ، واكتشفت أنني على الأرجح بحاجة إلى تثبيت clang. يعمل الإصدار تحت Appveyor ، لذلك أظن أنهم قاموا بتثبيته هناك وقد تكون القطعة المفقودة.

قد أحاول ذلك في وقت لاحق من هذا الأسبوع ، لكن Godot لا يعمل في جهاز Windows VM الخاص بي ، لذلك حتى لو أدى ذلك إلى نجاحه ، فسوف أقتصر على مقدار اختبار Windows الذي يمكنني القيام به.

لديّ كاتب يمكن الوصول إليه يُنشئ بنية دليل يمكنك من خلاله ترجمة godot-tts. تجاهل التعليمات لجلب بناء godot-tts من Appveyor. لا يمكنني معرفة كيفية دمج إصدارات Linux و Windows في ملف مضغوط واحد ، لذلك أتخلى عن ذلك لصالح إعداد برنامج GitLab CI الخاص بي. ولكن نظرًا لأنني لا أستطيع تشغيل Godot تحت Windows حاليًا ، فقد تم تخفيض الأولوية في الوقت الحالي.

قد أحاول ذلك في وقت لاحق من هذا الأسبوع ، لكن Godot لا يعمل في جهاز Windows VM الخاص بي ، لذلك حتى لو أدى ذلك إلى نجاحه ، فسوف أقتصر على مقدار اختبار Windows الذي يمكنني القيام به.

يجب أن تكون قادرًا على تثبيت تطبيق برنامج OpenGL في الجهاز الظاهري: https://github.com/pal1000/mesa-dist-win

سيعمل Godot ببطء ، ولكن بهذه الطريقة ، سيعمل كل من عارض GLES3 و GLES2.

francipvb هل حاولت تثبيت Clang / LLVM؟ أنا في الواقع أقوم بمحاولة بناء أحدث godot-tts تحت Windows أيضًا ، واكتشفت أنني على الأرجح بحاجة إلى تثبيت clang. يعمل الإصدار تحت Appveyor ، لذلك أظن أنهم قاموا بتثبيته هناك وقد تكون القطعة المفقودة.

قد أحاول ذلك في وقت لاحق من هذا الأسبوع ، لكن Godot لا يعمل في جهاز Windows VM الخاص بي ، لذلك حتى لو أدى ذلك إلى نجاحه ، فسوف أقتصر على مقدار اختبار Windows الذي يمكنني القيام به.

لديّ كاتب يمكن الوصول إليه يُنشئ بنية دليل يمكنك من خلاله ترجمة godot-tts. تجاهل التعليمات لجلب بناء godot-tts من Appveyor. لا يمكنني معرفة كيفية دمج إصدارات Linux و Windows في ملف مضغوط واحد ، لذلك أتخلى عن ذلك لصالح إعداد برنامج GitLab CI الخاص بي. ولكن نظرًا لأنني لا أستطيع تشغيل Godot تحت Windows حاليًا ، فقد تم تخفيض الأولوية في الوقت الحالي.

تركت هذا دون أن يمس ، لكنني سأحاول.

هتافات،

مرحبا ndarilek ،

لقد تخليت عن محاولة هذا. لقد قمت بتثبيت أداة LLVM ونجحت.

هتافات،

حلو! هل تقصد أنه تم تجميعه ، أم أنه يتحدث بالفعل تحت Windows؟
لم تتح لي الفرصة لمحاولة تشغيل برنامج OpenGL حتى الآن.

أعتقد أن لدي تطبيق OpenGL (لدي وحدة معالجة رسومات NVIDIA).

أنا فقط أقوم ببناء فرع جودو الخاص بك.

مرحبا،

كيف أربط هذين الشيئين الآن؟

شكرا،

لاحظ أنني قمت ببناء الفرع من جيثب.

أعتقد أنه موثق جيدًا في README للمبتدئين. من فضلك دع
أعرف إذا كان لديك أي أسئلة بخصوص ذلك.

عذرًا ، لست متأكدًا من المكان الذي يجب أن أبحث فيه ، لأن مستودع godot-tts لا يحتوي على README.

هتافات،

أوه ، آسف ، اعتقدت أنك رأيت
هذا .
لا تتبع تعليمات تنزيل godot-tts منذ أن افترضوا أنني
يمكن أن تجعل Appveyor يعمل. وآخر شيء يتعلق بفقدان التركيز في اللعبة
الإقلاع عن التدخين لم يعد صحيحًا.

حظًا سعيدًا ، أتمنى أن يعمل هذا تحت Windows.

أواجه بعض النضالات الحقيقية مع القوائم المنبثقة التي تظهر عند النقر بزر الماوس الأيمن
النقر على عقد الشجرة في المحرر.
هنا
هو الرمز الذي أعمل معه. على وجه الخصوص ، أحيانًا get_item_index
يعود -1 ولا أعرف لماذا. هذا يجعلها جميلة إلى حد كبير
من المستحيل الحصول على أي تفاصيل حول عنصر PopupMenu ، والطرق الخاصة به
يبدو أن القيام بذلك يتوقع وجود معلمة idx والتي أفترض أنها فهرس.

بالنظر إلى المصدر ، يبدو أن -1 يعني أن العنصر غير موجود. لكن أنا
تمرير المعرف كما تم استرداده بواسطة id_focused ، لذلك لا أعرف سبب ذلك
ستسلمني الإشارة معرفًا غير موجود.

على أي حال ، حاولت فقط إدخال المعرف عندما أحصل على -1 ، لكن هذا
من الواضح أنه ليس صحيحًا ، لأنني غالبًا ما أنقر على شيء واحد وأحصل على شيء ما
مختلفة تماما. المساعدة في هذا موضع تقدير كبير - لقد أمضيت ساعات في
ولا تعرف ما إذا كانت حالات التحكم هذه هي عربات التي تجرها الدواب
أو إذا كان هناك شيء آخر يحدث هنا. الأشياء تعمل في قوائم أخرى ، ولكن
لا قوائم سياق عنصر الشجرة في قائمة العقد. شكرا.

أوه ، آسف ، أعتقد أنك رأيت هذا . لا تتبع تعليمات تنزيل godot-tts لأنهم افترضوا أنه يمكنني تشغيل Appveyor. والشيء الأخير حول فقدان التركيز على إنهاء اللعبة لم يعد صحيحًا. حظًا سعيدًا ، أتمنى أن يعمل هذا تحت Windows.

يبدو أن هذا الرابط هو إعادة شراء خاصة ...

شكرا،

Doh ، ثابت ، آسف.

أنا آسف ، لا أريد تحويل هذا إلى موضوع دعم عام ، لكن
في هذه الحالة لا أعرف ما إذا كنت قد فعلت شيئًا خاطئًا والمحرر هو كذلك
الإبلاغ عنها بتحذير أو إذا ارتكبت خطأً حقًا. انا حنون
للقيام ببعض سير العمل المختلط حيث أقوم بتعديل بعض الأشياء في
محرر ثم ، مع إيقاف تشغيله ، قم بتحرير بعض الأشياء في الملفات بواسطة
كف. لذلك من الممكن أن أكون قد ارتكبت خطأ ، على الرغم من أنني لم أفهم
أخطاء في بناء الجملة.

لا يمكنني تشغيل صوت ثلاثي الأبعاد ، وقم بتجميع هذاقدوة لصنع الأشياء
بسيطة قدر الإمكان ، لكنها لا تعمل. هدفي هو إنشاء ملف
عقدة مكانية واحدة ثلاثية الأبعاد مع دفق صوتي يدق والمستمع مثل
الأطفال ، ثم لعب الدمدمة. هذا يعمل في 2-D ، ولكن ليس في 3-D. هل انا
تفعل شيئا خاطئا هنا؟

أعتذر مرة أخرى ، سألت في المنتدى بدوناستجابة
ومن الصعب الحصول على دروس نصية. في بعض الأحيان لا أعرف ما إذا كان
أنا أصاب خطأ في Godot ، أو إذا قام المحرر بالإبلاغ عن خطأ و
البرنامج المساعد لا يعرضه.

شكرا على اي مساعدة. بخلاف مشكلة الصوت هذه ، أجعل بعضًا لائقًا
التقدم في التنقل على غرار الكويكبات مع واجهة منطوقة. هناك
لا تزال تجاعيد ، لكن العمل مع محرر جودو كعمى تمامًا
المطور ممكن حتى الآن.

لقد قسمت دعم إمكانية الوصول إلى ScreenReader منفصل
عقدة يمكن نظريًا إضافتها إلى أي SceneTree لصنعها
واجهات مستخدم داخل اللعبة يمكن الوصول إليها. هذا يجعل البرنامج المساعد الخاص بي ليس مجرد محرر
تعزيز إمكانية الوصول ، ولكن ما يعادل إمكانية الوصول إلى الوحدة
المكون الإضافي الذي تم استخدامه في العديد من ألعاب الشحن. بالطبع،
الوظائف لا تزال متخلفة ، ولكن على حد علمي ،
لا يمكن الوصول إلى سلسلة أدوات Unity حتى الآن ، لذلك نحن متقدمون في هذا الصدد.

لا يمكنني تشغيل صوت ثلاثي الأبعاد ، وقم بتجميع هذا المثال لتبسيط الأمور قدر الإمكان ، لكنه لا يعمل. هدفي هو إنشاء عقدة مكانية ثلاثية الأبعاد مع دفق صوتي يدق والمستمع كأطفال ، ثم يعزف الدمدمة. هذا يعمل في 2-D ، ولكن ليس في 3-D. أفعل شيئا خطأ هنا؟

تحتاج إلى إضافة 3D Camera إلى المشهد. يمكنك بعد ذلك وضع المستمع كطفل ثانوي للكاميرا وتحريك الكاميرا ، أو تحريك المستمع مباشرة. يجب أن إصلاح المشكلة...

الذي أعتقد أنه خطأ ، لأنه لا يتم عرض أي خطأ / تحذير على الإطلاق في المحرر عند عدم وجود كاميرا ولا يتم تشغيل الصوت.

لا تزال هناك تجاعيد ، ولكن العمل مع محرر Godot كمطور أعمى تمامًا أمر ممكن حتى الآن.

يثلج الصدر أن نسمع ، شكرًا لك على عملك في جعل Godot أكثر سهولة.

آه ، اعتقدت أن المستمع كان كافيًا. هل يمكنني إضافة الكاميرا ومنعها
من العرض مع الاحتفاظ بأي خاصية تجعل
العمل المستمع؟ أريد أن أكون قادرًا على تقديم شيء ما إلى ثنائي الأبعاد ، فقط
ليس مشهدًا كاملًا ثلاثي الأبعاد. أو يمكنني تعديل الكاميرا ثلاثية الأبعاد لتصيير ثنائية الأبعاد
بطريقة ما - ربما اعطيه منظور متعامد؟

شكرًا ، تم التدفق من خلال المصادر التي تحاول تعقب ذلك.

آه ، اعتقدت أن المستمع كان كافيًا

أعتقد أنه يجب أن يكون ، قد يكون خطأ ، ليس لدي الكثير من المعرفة في هذا المجال.

هل يمكنني إضافة الكاميرا ومنعها من العرض مع الاحتفاظ بأي خاصية تجعل المستمع يعمل؟

يمكنك وضع جميع العناصر ثلاثية الأبعاد في Viewport ولن يتم عرضها (تذكر تمكين خاصية المستمع).

أريد أن أكون قادرًا على تقديم شيء ما إلى ثنائي الأبعاد ، وليس مشهدًا كاملًا ثلاثي الأبعاد. أو يمكنني تعديل الكاميرا ثلاثية الأبعاد لتصيير 2-D بطريقة أو بأخرى - ربما أعطها منظورًا متعامدًا؟

يمكنك عرض كل من ثلاثي الأبعاد ثنائي الأبعاد (عبر ViewportContainer ) وثنائي الأبعاد في 3D عبر ( Mesh ، Material ، ViewportTexture ).
توجد بعض الوثائق هنا:
https://docs.godotengine.org/en/3.1/tutorials/viewports/viewports.html
والمشاريع التجريبية هنا:
https://github.com/godotengine/godot-demo-projects
ضمن المجلد الفرعي viewport .

حسنًا ، لقد تم تشغيل البث الخاص بي! لقد قرأت الكثير من المستندات بالفعل ، وأنا الآن
أيضًا محدودة بعض الشيء بسبب عدم قدرتي على رؤية ما يحدث بالفعل
تم تقديمها ، لذا آمل ألا تمانع في طرح بعض الأسئلة الإضافية في السطر. انا
اسأل هذه الأشياء في مكان آخر ولكن هذا هو المكان الوحيد الذي أحصل عليه
الإجابات ، وأنا آسف لأي شخص يشعر بأنه بريد عشوائي ، لكنني على وشك ذلك
النقطة التي أفكر فيها في الاستعانة بمستشار Godot للمساعدة
هذا المشروع مفتوح المصدر ، والذي أود تجنبه بسبب محدودية الأموال.
BUt أسئلتي:

في 25/9/2019 10:38 صباحًا ، كتب فابيو أليساندريللي:
>

يمكنك وضع جميع العناصر ثلاثية الأبعاد في | منفذ العرض | ولن تقدم
(تذكر أن تقوم بتمكين خاصية المستمع).

انتظر ، اعتقدت أن هذا هو الهدف الكامل لإطار العرض؟ هكذا يبدو
مثل ما تقول إنني أستطيع أن أفعله هو:

* قم بإنشاء لعبة ثنائية الأبعاد كما أنا حاليًا ، مع السماح لها بالعرض إلى
منفذ العرض الافتراضي الذي يتم إنشاؤه.

* إنشاء منفذ عرض منفصل مع الكاميرا كطفل ومستمع
كطفل من الكاميرا.

وفي هذه الحالة ، لن تعرض الكاميرا أي شيء حتى لو كان منفذ العرض
هو طفل من شجرة المشهد؟ هل هذا بسبب حجمه مضبوط على 0 من قبل
افتراضي ، أو أن هناك سببًا آخر يمكنني من خلاله معالجة التعليمات البرمجية على ملف
منفذ عرض غير مرئي؟ هذا غير بديهي تمامًا بالنسبة لي ، لكن إذا كان ذلك
يعمل ثم سيبسط عملي إلى حد كبير. انا ايضا اريد ان اتاكد
التي تستمر الكاميرا في معالجتها حتى لو لم يكن إطار العرض مرئيًا.

هل يجب أن تكون عقد AudioStreamPlayer3D الخاصة بي تابعة لإطار العرض مثل
نحن سوف؟ كنت أبحث في الواقع من خلال مصدر المحرك ، لكنه لم يكن كذلك
من الواضح لي على الفور أن المستمع يجب أن يكون طفلًا مصورًا ،
لذلك لست متأكدًا من كيفية معرفة ما إذا كانت عقد AudioStreamPlayer3D يجب أن تكون كذلك
الأطفال من نفس منفذ العرض.

شكرا لك مرة أخرى.

حسنًا ، أريد المساعدة في حل مشكلة غريبة أخرى. إذا قمت بإضافة Raycast2D
العقدة ، ثم حاول تعيين خاصية قناع التصادم الخاصة بها عبر المحرر ، ملف
تنبثق قائمة الطبقات عندما أضغط على الزر Enter. لكن الملحة
لا يبدو أن الإدخال على طبقة يغلق القائمة ويحدد طبقة.
يعمل الإدخال بشكل جيد في القوائم المنبثقة الأخرى ، وهو ما يبدو عليه الأمر.

أي أفكار لماذا قد يحدث هذا؟ وإذا لم يكن كذلك ، هل يمكن لأحد من فضلك
أشر لي إلى حيث يتم تنفيذ هذه القائمة المعينة في المحرك لذلك أنا
يمكن التحقيق؟ مطعون في المحرر / لكن الأمر ليس على الفور
واضح ، وأنا أيضًا غير متأكد من المعايير المحددة التي ستمنع
بعض العقد 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-select

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 ، وأيضًا كما تم تنفيذه في
المكوِّن الإضافي لإمكانية الوصول في الوحدة. في الأساس ، أود اعتراض اللمسات
بحيث تكون هناك حاجة إلى النقر المزدوج على عنصر تحكم لتشغيله ، وبشكل منتظم
تعمل لمسات الشاشة فقط على الكشف عن الواجهة. الضربات الشديدة في
تعمل بعض الاتجاهات أيضًا مثل Tab / Shift-tab. لا أعرف ما إذا كنت بحاجة
تجاوز منفذ العرض ، نوع من الطبقة المخصصة التي يمكنني استخدامها كملف
مرشح ، وما إلى ذلك ، أفضل عدم تغيير سلوك كل عنصر تحكم ،
بدلاً من ذلك ، مجرد تصفية التفاعلات التي تصلهم بطريقة يمكن أن تكون
التبديل بين التشغيل والإيقاف أثناء تشغيل اللعبة.

شكرا.

السؤال التالي ، هل هناك طريقة ما لاعتراض تفاعل الشاشة التي تعمل باللمس وتصفيتها قبل أن يصل إلى Control s أو العقد الأخرى؟

يمكنك استخدام Control._gui_input(event) في عنصر واجهة المستخدم الرسومية الجذر أو حتى 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 صباحًا Nolan Darilek [email protected]
كتب:

نعم ، عملت بشكل جيد. شكرا! البديل الذي كنت أفكر فيه سيكون
كان أكثر فوضوية.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/godotengine/godot/issues/14011؟email_source=notifications&email_token=AAOY262NSXUDGOMDFEF5NPTQOSPOXA5CNFSM4EG4X6EKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW ،
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/AAOY264T3T7KWWSTBIIJUFLQOSPOXANCNFSM4EG4X6EA
.

قد نكون قادرين على إغلاق هذا قريبًا ، OTOH لدي الكثير من الأسئلة التي تمت الإجابة عنها هنا والتي لم تساعد IRC / المنتديات في حلها. هذا صحيح مرة أخرى. :) آمل أن أكون قد حافظت على نسبة S / N عالية ، ولكن عندما أحتاج إلى مساعدة في شيء ما ، فعادة ما تكون أعلى مما يمكنني العثور عليه في برنامج تعليمي أو كتاب ، وهناك الكثير من الأشخاص المهرة الذين يشاهدون هذه المشكلة ويساعدونني بناء هذا الدعم.

نفذ الكثير من العمل على هذا خلال الإجازات. يدعم المكون الإضافي 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 الجديد حيث نريد أن تتواجد جميع المقترحات ومناقشتها.