Godot: GDScript: Variadische Funktionen (variable Anzahl von Argumenten/Varargs)

Nur damit ich das richtig verstehe, sprechen wir von etwas wie Rubys Splat-Operator ?

Als ich das letzte Mal etwas für gdscript vorgeschlagen habe, wurde es von Reduz ziemlich schnell heruntergefahren und gemieden, also nur eine Warnung (ich stimme übrigens mit Ja, gl!)

@ LikeLakers2 Auf einen kurzen Blick ja genau.

@girng Nun, ich hoffe, das hängt wirklich von der vorgeschlagenen Funktion ab. Ehrlich gesagt, sogar das ist mehr schön, einen leben , aber es würde einige allgemeine Fälle ein wenig schöner machen.

Ah, dann bekommt diese Idee meine Unterstützung. Dieser Splat-Operator ist in Ruby zu nützlich.

Die High-Level-Multiplayer-Funktion rpc tut dies bereits. Ist das irgendwie zugänglich?

Möchte damit eine einfache, benutzerdefinierte Logging-Funktion implementieren.

Folgendes können wir bereits tun:

print("Score: ", score)

aber es wäre schön wenn man auch folgendes machen könnte:

_log("Score: ", score)

wo die Ausgabe von log ergeben würde:

[MyClass] Score: 500

Möchte damit eine einfache, benutzerdefinierte Logging-Funktion implementieren.

Folgendes können wir bereits tun:

print("Score: ", score)

aber es wäre schön wenn man auch folgendes machen könnte:

_log("Score: ", score)

wo die Ausgabe von log ergeben würde:

[MyClass] Score: 500

kann ich plus eins das ... ich möchte auch eine Druckfunktion erstellen, die normal wie in Python druckt (Strings und Zahlen usw.), da ich das Drucken unangenehm finde, aber vielleicht mögen es andere Leute?

Ich denke, das wäre eine wirklich tolle Funktion in gdscript. Die Möglichkeit, mehrere Argumente ohne Array übergeben zu können, wäre in Fällen wie benutzerdefinierten Protokollfunktionen sehr hilfreich!

Während Sie argumentieren könnten, dass Sie damit durchkommen können, was die Entwicklung eines Spiels angeht (und Sie hätten absolut Recht), wäre es eine erstaunlich nützliche Funktion für Werkzeugmacher für Godot selbst, die """enthüllen""" a flexible API für ihre Benutzer.

Expose steht in Anführungszeichen, weil technisch gesehen alles in gewissem Sinne exponiert ist.

Ich denke, diese Funktion ist wirklich erforderlich, da einige Funktionen bereits varargs aber wir haben keine Möglichkeit, sie zu überschreiben.

Ich würde Varargs in gdscript lieben. Erwägen:

func rpc_game_info(node:Node, method:String, args:vararg):
    for id in players:
        node.rpc_id(id, method, args)

Die einzige Möglichkeit, die ich mir derzeit vorstellen kann, dies zu implementieren, besteht darin, die beiden Zeilen überall dort einzufügen, wo rpc_game_info sonst aufgerufen würde, und die Methode args als kommagetrennte Liste bereitzustellen.

Gibt es zumindest eine Möglichkeit, ein Array auszurollen/zu verteilen/zu erweitern? Mit anderen Worten, gibt es eine Möglichkeit, so etwas zum Laufen zu bringen?:

func foo(bar: String, args = []):
  baz(bar, ...args)

@rosshadden kannst du Object::callv("method", [..args])

Ich schreibe seit 2012 viel C/C++/Js-Code für Websites, Backends und Spiele und kann mich an keine Situation erinnern, in der ich unbedingt Varargs verwenden musste. Es ist eine nette Funktion zum Protokollieren von Debug-Nachrichten, aber abgesehen davon sehe ich keine Notwendigkeit dafür. Tatsächlich mache ich Godot-Spiele jetzt seit mehr als einem Jahr, und ich bin ziemlich zufrieden damit, wo gdscript jetzt ist: Es macht alles, was ich brauche und noch mehr. Anstatt Zeit damit zu verbringen, der Sprache zusätzlichen Schnickschnack hinzuzufügen, würde ich eher für eine Verbesserung der Effizienz der bestehenden Funktionalität stimmen. Mit freundlichen Grüßen - Alexandre Kharlamov

Ich schreibe seit 2012 viel C/C++/Js-Code für Websites, Backends und Spiele und kann mich an keine Situation erinnern, in der ich unbedingt Varargs verwenden musste. Es ist eine nette Funktion zum Protokollieren von Debug-Nachrichten, aber abgesehen davon sehe ich keine Notwendigkeit dafür. Tatsächlich mache ich Godot-Spiele jetzt seit mehr als einem Jahr, und ich bin ziemlich zufrieden damit, wo gdscript jetzt ist: Es macht alles, was ich brauche und noch mehr. Anstatt Zeit damit zu verbringen, der Sprache zusätzlichen Schnickschnack hinzuzufügen, würde ich eher für eine Verbesserung der Effizienz der bestehenden Funktionalität stimmen. Mit freundlichen Grüßen - Alexandre Kharlamov

Das ist nett, aber es tut mir leid, Ihnen sagen zu müssen, dass Ihre Stimme nichts bedeutet, wenn es wahrscheinlich ist, dass ein Freiwilliger dies aus freien Stücken umsetzt.

@mitchcurtis Bitte verzichten Sie auf Kommentare, die sich nicht auf das besprochene Problem beziehen. Andere herunterzuspielen trägt nicht positiv zur Diskussion bei.

Wie kann es sein, dass ein Feature, das viele nach "Schnickschnack" verlangen, andere nicht herunterspielt? Mein Kommentar bezieht sich direkt auf das vorliegende Problem - es ist ein Open-Source-Projekt und viele der Commits stammen von Mitwirkenden, die auswählen, woran sie arbeiten möchten.

Drehen wir es um: Trägt Alexandres Kommentar positiv zur Diskussion bei? Wäre es nicht besser für ihn gewesen, ein bestimmtes Feature zu finden, das ihn interessiert, und seine Unterstützung dafür zu zeigen, anstatt Features herunterzuspielen, die andere wollen?

Bei der Implementierung von Features geht es nicht nur darum, „wer es will“ und „wer es implementieren kann“. Es ist auch wichtig zu wissen, "wer es für nicht notwendig hält (und warum)", da wir es vermeiden sollten, Features zu implementieren, wenn wir sie nicht wirklich benötigen. Sie erschweren die Codepflege, können die Leistung beeinträchtigen, Optimierungsmöglichkeiten reduzieren usw. (insbesondere in einer Skriptsprache).

Also ja, das Feedback von @alexkh ist interessant, auch wenn Sie damit nicht einverstanden sind. Jemand kann morgen mit einer perfekten PR für dieses Feature kommen, Core-Mitwirkende werden noch einige Zeit damit verbringen müssen, nachzudenken und zu diskutieren, ob dies aus technischer Sicht und aus Sicht des API-Designs eine Ergänzung wert ist.

Den Umfang von GDScript klein und leicht zu pflegen zu halten, ist definitiv eines der wichtigsten Designprinzipien für die Sprache. Ich sage nicht, dass dieses spezielle Merkmal keine gute Ergänzung wäre, aber wir müssen die Vor- und Nachteile abwägen, was bedeutet, denjenigen zuzuhören, die mit dem Vorschlag nicht einverstanden sind.

Bei der Implementierung von Features geht es nicht nur darum, „wer es will“ und „wer es implementieren kann“. Es ist auch wichtig zu wissen, "wer es für nicht notwendig hält (und warum)", da wir es vermeiden sollten, Features zu implementieren, wenn wir sie nicht wirklich benötigen. Sie erschweren die Codepflege, können die Leistung beeinträchtigen, Optimierungsmöglichkeiten reduzieren usw. (insbesondere in einer Skriptsprache).

Also ja, das Feedback von @alexkh ist interessant, auch wenn Sie damit nicht einverstanden sind. Jemand kann morgen mit einer perfekten PR für dieses Feature kommen, Core-Mitwirkende werden noch einige Zeit damit verbringen müssen, nachzudenken und zu diskutieren, ob dies aus technischer Sicht und aus Sicht des API-Designs eine Ergänzung wert ist.

Den Umfang von GDScript klein und leicht zu pflegen zu halten, ist definitiv eines der wichtigsten Designprinzipien für die Sprache. Ich sage nicht, dass dieses spezielle Merkmal keine gute Ergänzung wäre, aber wir müssen die Vor- und Nachteile abwägen, was bedeutet, denjenigen zuzuhören, die mit dem Vorschlag nicht einverstanden sind.

Faire Punkte.

Ich denke, die Anzahl der Stimmen zu diesem Thema spricht für sich, aber ich werde versuchen, in Zukunft solche Kommentare zu unterlassen.

Ich schreibe seit 2012 viel C/C++/Js-Code für Websites, Backends und Spiele und kann mich an keine Situation erinnern, in der ich unbedingt Varargs verwenden musste. Es ist eine nette Funktion zum Protokollieren von Debug-Nachrichten, aber abgesehen davon sehe ich keine Notwendigkeit dafür. Tatsächlich mache ich Godot-Spiele jetzt seit mehr als einem Jahr, und ich bin ziemlich zufrieden damit, wo gdscript jetzt ist: Es macht alles, was ich brauche und noch mehr. Anstatt Zeit damit zu verbringen, der Sprache zusätzlichen Schnickschnack hinzuzufügen, würde ich eher für eine Verbesserung der Effizienz der bestehenden Funktionalität stimmen. Mit freundlichen Grüßen - Alexandre Kharlamov

Ich programmiere seit mehr als 15 Jahren an diversen Spielen, Programmen sowohl zu Hause als auch auf der Arbeit, aber erst seit 1 Monat in Godot und ich kann sagen, dass ich einige Features vermisse, die bereits als Feature Request offen sind Dieses Feature. In der Lage zu sein, variable Anzahlen von Argumenten zu akzeptieren und zu senden, ist etwas, das ich ziemlich oft benötige und die Qualität des Codes dramatisch verringert, wenn Sie es umgehen müssen.

Ein Beispiel: => Vererbung

class A
_init(arg0, arg1, arg2)

class B extends A
_init(arg0, arg1, arg2, arg4).(arg0, arg1, arg2)

Stellen Sie sich nun vor, Sie müssen die Argumentliste der Klasse A ändern. Sie müssen jede Klasse finden, die diese Klasse erbt, das ist gefährlich. Trotz der Tatsache, dass es keine benannten Argumente gibt, ist das Vermischen der Argumentliste ein Problem für sich

Ein weiteres Beispiel sind Rückrufe, das geht wohl ohne Code ...

Mein Punkt ist also: Godot macht noch nicht alles, was Sie brauchen, es macht einfach alles, was entscheidend ist (naja und natürlich noch einiges mehr :) ...). Es ist jedoch noch nicht an einem Punkt, an dem das Aufhören mit dem Hinzufügen von Funktionen der beste Fall wäre. Es ist jedoch eine gute Entscheidung, vorsichtig zu sein, was hinzugefügt werden soll.

Bearbeiten: Habe gerade festgestellt, dass ein weiteres gutes Beispiel Godots eigene Object.call()-Methode ist;)

DamKoVosh, bitte sagen Sie mir, wie viele Codezeilen Ihr größtes Spiel war? Jedes Mal, wenn ich ein Spiel erstelle, bin ich enttäuscht, wie wenig Codierung es erfordert. Der Großteil der Arbeit ist immer der Inhalt, das Testen, das Ausbalancieren des Gameplays. Sie sagen, dass das Umschreiben gefährlich ist. Nicht zuletzt macht Sie das Umschreiben Ihres Codes besser darin, zukunftssichere Schnittstellen und Datenstrukturen zu schreiben!

Wie in der ersten Nachricht in diesem Thread erwähnt, dreht sich die ganze Diskussion genau um syntaktischen Zucker für etwas, das bereits mithilfe eines Arrays leicht implementiert werden kann, anstatt eine variadische Funktion zu implementieren.

@alexkh

Wie in der ersten Nachricht in diesem Thread erwähnt, dreht sich die ganze Diskussion genau um syntaktischen Zucker für etwas, das bereits mithilfe eines Arrays leicht implementiert werden kann, anstatt eine variadische Funktion zu implementieren.

Wie von Geequlim bereits erwähnt , ist dies nicht nur syntaktischer Zucker, sondern rpc , emit_signal , ... Ich bin gerade auf dieses Problem gestoßen, als Ich habe versucht, rpc an meine Bedürfnisse anzupassen.

Ja, es ist syntaktischer Zucker. Da es sich um syntaktischen Zucker handelt, bedeutet dies jedoch nicht, dass sie gut oder schlecht sind. Kontrollfluss wie if , else und sogar Funktionen sind nur Zucker auf GOTO wenn Sie so wollen. Das heißt nicht, dass Sie die nicht wollen.

Manchmal macht das Hinzufügen von etwas syntaktischem Zucker den Code viel lesbarer und ist die zusätzliche Komplexität wert.

unterbricht aber tatsächlich die Möglichkeit, Funktionen zu überschreiben, die Varargs verwenden, wie rpc, emit_signal

Merkwürdig, dass diese Funktionen Varargs und keine Arrays verwenden. ;-) Beachten Sie, wie die Godot-API selbst an verschiedenen Stellen Varargs verwendet? Das hat wahrscheinlich einen Grund.

Auch neugierig, wie viele Sprachen variadische Funktionen implementieren. Vielleicht sind sie nützlich, auch wenn sie "einfach mit einem Array implementiert" werden können?

Ich vermisse sie in GDScript sehr, wenn ich es verwende, und das ist einer der Gründe, warum ich C# bevorzuge. Oder C++. Oder Java. Oder Python. Oder gehen.

Ehrlich gesagt denke ich, dass GDScript die einzige Sprache ist, in der ich gearbeitet habe, die sie nicht hat. Außerdem vielleicht, Lua? Ah, ich habe nachgesehen und sie scheinen dort auch zu existieren. Das heißt nicht, dass wir versuchen sollten, GDScript alles hinzuzufügen, was diese Sprachen haben, aber wenn all diese Sprachen ein gemeinsames Merkmal haben, kann es einiges wert sein.

Ich kann nicht beurteilen, wie viel Komplexität es zum GDScript-Backend hinzufügen würde, und kann daher nicht viel über den Komplexitäts-Kompromiss sagen, aber sie abzuschreiben, weil sie "nur syntaktischer Zucker" sind, ist falsch, denn das kann man sagen viele Dinge.

Beachten Sie wieder, wie viele Dinge in Godot sie verwenden.

Ja, es ist syntaktischer Zucker. Da es sich um syntaktischen Zucker handelt, bedeutet dies jedoch nicht, dass sie gut oder schlecht sind. Kontrollfluss wie if , else und sogar Funktionen sind nur Zucker auf GOTO wenn Sie so wollen. Das heißt nicht, dass Sie die nicht wollen.

GOTO ersetzt if nicht, da es sich um einen unbedingten Sprung handelt. Bist du überhaupt Programmierer?

unterbricht aber tatsächlich die Möglichkeit, Funktionen zu überschreiben, die Varargs verwenden, wie rpc, emit_signal

einmal im Jahr möchte jemand irgendwo die rpc-Funktion überschreiben. Während Tausende andere jeden Tag wünschen, dass Godot 4 veröffentlicht wird.

Auch neugierig, wie viele Sprachen variadische Funktionen implementieren. Vielleicht sind sie nützlich, auch wenn sie "einfach mit einem Array implementiert" werden können?

Ich vermisse sie in GDScript sehr, wenn ich es verwende, und das ist einer der Gründe, warum ich C# bevorzuge. Oder C++. Oder Java. Oder Python. Oder gehen.

C++ hat keinen Standard-Array-Typ, der Werte unterschiedlicher Typen speichern kann, wie es GDscript tut. Obwohl C++ variadische Funktionen unterstützt, wird von ihrer Verwendung abgeraten, da sie typunsicher ist. Es ist ein C-Erbe, und in C selbst war es ein syntaktischer Zucker, da printf viel verwendet wurde, insbesondere zum Debuggen - wo Sie schnell temporären Code eingeben möchten, um einige Daten auszugeben. Es war absolut gerechtfertigt, da es die ganze Zeit benutzt wurde - eine echte Zeitersparnis! Aber haben Sie jemals Ihre eigene Variadic-Funktion in C oder C++ geschrieben?

Beachten Sie wieder, wie viele Dinge in Godot sie verwenden.

Für Debug-Ausgaben - auf jeden Fall! Aber wenn print() nicht variadisch wäre, müsste man statt print("Hello", "World) print(["Hello", "World"]) eingeben - überhaupt kein großer Unterschied...

GOTO ersetzt nicht if, weil es ein unbedingter Sprung ist

Nun, richtig. Ich sprach natürlich von bedingten Sprüngen. Was... Sie wahrscheinlich folgern könnten. Der Punkt steht jedoch: Wir haben eine höhere Funktionalität darüber gebaut, um einige Dinge sauberer vermitteln zu können.

C++ hat keinen Standard-Array-Typ, der Werte unterschiedlicher Typen speichern kann, wie es GDscript tut.

Okay, argumentieren Sie gegen Python, Lua oder Go (oder jeden Host anderer Sprachen), die diese haben und immer noch variadische Funktionen haben.

Aber wenn print() nicht variadisch wäre, müsste man statt print("Hello", "World) print(["Hello", "World"]) eingeben - überhaupt kein großer Unterschied

Klar, in diesem einfachen Testfall. In komplexeren Fällen wird es hässlicher, insbesondere wenn Sie Daten aus mehreren Quellen haben und diese nun manuell in ein Array stopfen müssen. Ich stimme zu, dass es kein großer Verlust ist; dennoch sorgen variadische Funktionen in einigen Fällen für saubereren Code.

Aber...

Aber haben Sie jemals Ihre eigene Variadic-Funktion in C oder C++ geschrieben?

Bist du überhaupt Programmierer?

Wie oben habe ich nicht das Gefühl, dass Sie in gutem Glauben argumentieren. In diesem Fall bin ich nicht mehr wirklich daran interessiert, mit Ihnen zu sprechen, also... nein, ich bin nur als Motormitarbeiter aufgeführt, weil ich ein gutes Maskottchen bin, bitte machen Sie weiter.

GOTO ersetzt if nicht, da es sich um einen unbedingten Sprung handelt. Bist du überhaupt Programmierer?

Meistens sind bedingte Anweisungen, insbesondere Schleifen, nur eine spezialisierte Sprunganweisung, die meistens mit einer goto-Anweisung identisch ist, im praktischen Sinne sind die meisten grundlegenden Sequenzkontrollanweisungen, die Sie finden, eine Erweiterung davon. Dies ist ein törichtes Argument, um sich selbst zu unterstützen (da es nicht wirklich argumentiert, es argumentiert nur Semantik, die nutzlos ist) und dieser zweite Teil ist respektlos.

C++ hat keinen Standard-Array-Typ, der Werte unterschiedlicher Typen speichern kann, wie es GDscript tut. Obwohl C++ variadische Funktionen unterstützt, wird von ihrer Verwendung abgeraten, da sie typunsicher ist. Es ist ein C-Erbe, und in C selbst war es ein syntaktischer Zucker, da printf viel verwendet wurde, insbesondere zum Debuggen - wo Sie schnell temporären Code eingeben möchten, um einige Daten auszugeben. Es war absolut gerechtfertigt, da es die ganze Zeit benutzt wurde - eine echte Zeitersparnis! Aber haben Sie jemals Ihre eigene Variadic-Funktion in C oder C++ geschrieben?

Während C++ keinen Standard-Array-Typ für Varargs (oder nicht typisierte Arrays im Allgemeinen) hat, gibt es seit etwa einem Jahrzehnt erste Manieren, um damit umzugehen (technisch konnte man dies sogar vor C++11 tun, aber es war sehr makrolastig und ziemlich hackig) und zweitens können Sie mit varadic-Vorlagen die Tippprobleme komplett überspringen. Es gibt Manieren, um mit Varargs in C++ umzugehen, indem Varadic-Templates verwendet werden. Diejenigen, die in C++ noch immer an Varargs glauben, gehen heutzutage wahrscheinlich vom falschen Punkt aus.

Ich persönlich kümmere mich nicht sonderlich um die Diskussion (abgesehen davon, dass ich es persönlich sauberer und organisierter finden würde, eine Art Array-basierter varadic-Argumente in GDScript zu haben, anstatt im Backend zu sitzen, denke ich, dass Sprachfunktionen für implementiert werden sollten die Sprache, nicht nur die Ausführung, aber das bin nur ich), aber diese Kommentare mussten korrigiert werden, und abgesehen davon, dass Sie sich in diesem Fall ziemlich unhöflich verhalten, stärken Sie Ihren Standpunkt in den Köpfen Ihres Publikums nicht, wenn Sie auf Einwände, die so objektiv behandelt werden sollten, negativ reagieren.

GOTO ersetzt if nicht, da es sich um einen unbedingten Sprung handelt. Bist du überhaupt Programmierer?

Meistens sind bedingte Anweisungen, insbesondere Schleifen, nur eine spezialisierte Sprunganweisung, die meistens mit einer goto-Anweisung identisch ist, im praktischen Sinne sind die meisten grundlegenden Sequenzkontrollanweisungen, die Sie finden, eine Erweiterung davon. Dies ist ein törichtes Argument, um sich selbst zu unterstützen (da es nicht wirklich argumentiert, es argumentiert nur Semantik, die nutzlos ist) und dieser zweite Teil ist respektlos.

K, ich bin respektlos gegenüber Leuten, die meine Zeit verschwenden. Sein Punkt war: Warum nicht GOTO anstelle von if verwenden, und ich sagte, dass GOTO nicht if ersetzt. GOTO ist keine bedingte Anweisung und wenn Sie eine bedingte Anweisung ersetzen möchten, geben Sie einfach ein, womit Sie sie ersetzen möchten. Gibt es schon Beispiele?

C++ hat keinen Standard-Array-Typ, der Werte unterschiedlicher Typen speichern kann, wie es GDscript tut. Obwohl C++ variadische Funktionen unterstützt, wird von ihrer Verwendung abgeraten, da sie typunsicher ist. Es ist ein C-Erbe, und in C selbst war es ein syntaktischer Zucker, da printf viel verwendet wurde, insbesondere zum Debuggen - wo Sie schnell temporären Code eingeben möchten, um einige Daten auszugeben. Es war absolut gerechtfertigt, da es die ganze Zeit benutzt wurde - eine echte Zeitersparnis! Aber haben Sie jemals Ihre eigene Variadic-Funktion in C oder C++ geschrieben?

Während C++ keinen Standard-Array-Typ für Varargs (oder nicht typisierte Arrays im Allgemeinen) hat, gibt es seit etwa einem Jahrzehnt erste Manieren, um damit umzugehen (technisch konnte man dies sogar vor C++11 tun, aber es war sehr makrolastig und ziemlich hackig) und zweitens können Sie mit varadic-Vorlagen die Tippprobleme komplett überspringen. Es gibt Manieren, um mit Varargs in C++ umzugehen, indem Varadic-Templates verwendet werden. Diejenigen, die in C++ noch immer an Varargs glauben, gehen heutzutage wahrscheinlich vom falschen Punkt aus.

Ich persönlich kümmere mich nicht sonderlich um die Diskussion (abgesehen davon, dass ich es persönlich sauberer und organisierter finden würde, eine Art Array-basierter varadic-Argumente in GDScript zu haben, anstatt im Backend zu sitzen, denke ich, dass Sprachfunktionen für implementiert werden sollten die Sprache, nicht nur die Ausführung, aber das bin nur ich), aber diese Kommentare mussten korrigiert werden, und abgesehen davon, dass Sie sich in diesem Fall ziemlich unhöflich verhalten, stärken Sie Ihren Standpunkt in den Köpfen Ihres Publikums nicht, wenn Sie auf Einwände, die so objektiv behandelt werden sollten, negativ reagieren.

K, aber genau das ist mein Punkt: GDscript hat einen Standardtyp, den Sie iterieren können und der verschiedene Typen darin enthalten kann, sodass Sie sich nicht mit all den Hacker herumschlagen müssen, die erforderlich sind, um die variadic-Funktionen in C++ zum Laufen zu bringen, und deshalb , vielleicht sind in C++ variadische Vorlagen gerechtfertigt.

K, ich bin respektlos gegenüber Leuten, die meine Zeit verschwenden.

Dann lasse ich Sie Ihre Zeit mit anderen Projekten verschwenden, da Sie jetzt 30 Tage lang für die Interaktion mit

Wir haben einen Verhaltenskodex , und es ist auf jeden Fall erlaubt nicht jemand respektlos.

Funktions- und Verbesserungsvorschläge für die Godot Engine werden jetzt in einem speziellen Godot Improvement Proposals (GIP) ( godotengine/godot-proposals ) Issue Tracker diskutiert und überprüft. Der GIP-Tracker verfügt über eine detaillierte Problemvorlage, die so konzipiert ist, dass Vorschläge alle relevanten Informationen enthalten, um eine produktive Diskussion zu beginnen und der Community zu helfen, die Gültigkeit des Vorschlags für die Engine zu bewerten.

Der Haupt-Tracker ( godotengine/godot ) ist jetzt ausschließlich für Fehlerberichte und Pull-Requests bestimmt, sodass sich die Mitwirkenden besser auf die Fehlerbehebung konzentrieren können. Daher schließen wir jetzt alle älteren Feature-Vorschläge im Hauptproblem-Tracker.

Wenn Sie an diesem Feature-Vorschlag interessiert sind, öffnen Sie bitte