Yes, the Java version has indeed much lower requirements, but it's basically an entirely different game (but playing together works the same way). For the standalone, the Java version has a separate launcher (so you have to put it into a separate folder on your hard drive). But I realized that the Java launcher is missing from the download section for some reason 
I've fixed that now, but you can also find it here 
Posts by red51
-
-
Und ich würde am liebsten bis zum nächsten Update/Release garnicht' s von Entwicklung und Entwicklern hören. Und dann einfach überrascht werden, wenn was am Start ist. Das fände ich um einiges Besser.👉👈
Hehe, naja, ich fürchte damit wären viele aber auch nicht einverstanden (und zugegebenermaßen wirkt es auch etwas abschreckend, wenn es wirklich gar keine Infos gibt)
Für solche Updates müsste es keine Vorankündigung geben. Ein paar Worte wie - Bug xxx wurde geändert, Anpassung von xy ist jetzt möglich etc. - reichen doch.
In der Hotfix-Phase schreibe ich ja eigentlich keine (oder nur sehr selten) Vorankündigungen. Bei Updates, bei denen jedoch etwas Zeit dazwischen lag, versuche ich das möglichst schon zu machen, damit sich zB Serveradmins darauf einstellen können. Die Vorankündigung ist aber keinesfalls der Punkt, der zeitfressend ist, ebensowenig die Ankündigung selber (naja, vll ein bisschen, bei kleineren Änderungen aber eher weniger). Es ist der Release selber (Vorbereiten der Release-Version, der Deploy auf Steam, Testen, ggf. nötige Hotfixes usw).
Das Builden der neuen Version für alle Plattformen dauert ca. 2-3 Stunden (+ ca. 20-30 Minuten Upload), sodass gravierende Probleme in einem Update ein echter Albtraum sind, da ich nicht so schnell einen Hotfix nachliefern kann (anders als in der Java Version, wo der Build gerade mal knapp 10 Minuten dauerte)
Wo wir aber von Ankündigungen reden: Ich persönlich (rein persönliche Meinung als Spieler) bin eigentlich kein Fan davon, wenn die News- bzw. Update-Sektion von haufenweise 1-Zeilern oder "bedeutungslosen" Updates überschwemmt ist, und nur jede 5. oder 10. Ankündigung wirklich Content liefert (für die Mehrheit der Spieler als wirklich nennenswert ist). Ist wirklich reine Geschmackssache. Hier im Forum könnten wir zwar entgegenwirken (zB eigene Rubrik für Bugfixes oder nicht-angepinnte Threads), bei Steam hingegen ist das nicht möglich, sondern jeder Mini-Hotfix ist auf der News-Seite genauso prominent wie ein Riesen-Update
Ein Download von 1-2 GB (für RW) dauert 1-2 Minuten selbst bei Steam.
Ich habe damit auch keine Probleme, aber es gibt immer wieder mal User, die das (bislang immer sehr freundlich [das sage ich wirklich unironisch]) kritisieren.
Bei Nachfragen - warum nur Bugfixes - könnte man einen Standardtext per Makro einfügen.
Nee, sorry, ich will nicht dazu verkommen, Leuten nur noch mit Copy-Paste-Konserven zu antworten
Möglicherweise könnten kleine Updates die Nachfrage nach größeren Updates reduzieren.
Meine Erfahrung ist bisher eher gewesen (vmtl. aber auch mit gewissem Bias), dass häufigere, kleinere Updates (die keinen besonderen Content ins Spiel bringen) eher nicht so die große Resonanz bringen. Tendenziell triggern häufigere, kleinere Updates sogar eher die Hater. Und wenn zu viele User der Meinung sind, ein Update bringe unnötigen Content (während vermeintlich wichtigere Baustellen offen bleiben), resultiert das leider auch eher in viel Negativität.
Was hingegen wirklich was bringt sind die Updates, die auch interessanten Content ins Spiel bringen, die vielen Spielern einen Grund liefern, das Spiel wieder anzuschmeißen (und vll mehr als nur 5 Minuten reinzuschauen). Problem hierbei ist nur, dass der interessante Content meist auch am zeitaufwändigsten ist
Was ich mir hingegen eher vorstellen könnte wäre ein separater Update-Branch, wo häufiger mal Releases landen. Den müsste man explizit aktivieren, würde dann häufigere Bugfixes und Änderungen erhalten, gleichzeitig aber auch eher das Risiko besteht, dass neue Fehler eingeführt werden oder etwas mal nicht auf Anhieb rund läuft (was dann natürlich trotzdem zügig behoben wird). Das würde keine Update-Ankündigung erhalten (hingegen vmtl. eher ein angepinnter Thread irgendwo, der die Changelogs erfasst) und ist damit für die breite Masse wahrscheinlich auch eher unsichtbar. Für Multiplayer-Spieler leider eher problematisch (weil der Server dann auch aktuell sein muss, was dann aber die Spieler, die auf dem normalen Public-Branch sind, wieder ausschließt), wäre daher vmtl. eher für Singleplayer- und Coop-Spieler
-
It's indeed necessary to have a separate license per player. But the Steam- and Standalone version are compatible with each other. Basically just the Steam-features are missing from the Standalone (e.g Steam Cloud). But the main difference: the Steam version has a "Play with Friends" option which is exclusive to Steam (because it uses Steams relay servers). This option enables you to play with a friend from your Steam friends list (very much like a LAN game, but with no additional requirements).
If a Steam player and Standalone player want to play with each other, it's necessary to host a classic LAN game instead. It's the default option in the Standalone (so the easiest way is if the Standalone hosts the game). In the Steam version, however, it's hidden by default (it requires a right-click on the "Play with Friends" button)
About the launcher options, basically these are optional arguments which can be passed to the game. This is mainly for technical reason (e.g if you want to force the game to run with Vulkan instead of DX11 etc)
-
Meint ihr das jetzt eher auf Bugfixes bezogen, oder auf richtige Updates, die neuen Content reinbringen? Falls es eher um Bugfixes geht: Das ist nicht unmöglich, aber leider auch mehr Aufwand. Das würde die Entwicklung insgesamt wohl eher verlangsamen... wir arbeiten ja dann bereits an neuen Features und die Codebasis hat sich dann schon mehr oder weniger stark verändert. Das ist ein absolut lösbares Problem (d.h. man würde in der Praxis einfach auf den alten Code-Stand zurückspringen, einen Hotfix vorbereiten + veröffentlichen, und die Änderungen dann anschließend in den aktuellen Code-Stand einpflegen), das kann gleichzeitig aber auch wieder neue Bugs oder Regressions reinbringen. Ohne ausreichend zu testen ist das echt etwas heikel...
Das nächste Problem ist aber auch, dass Updates trotzdem automatisch Erwartungen schüren - wenn dann aber die Feststellung kommt, dass das Update ja gar keinen Content bringt, sondern nur ein paar kleinere Bugs behebt, führt das schnell mal zu Enttäuschungen.
Wenn wir das sogar ausweiten und nicht nur Bugfixes, sondern auch Änderungen oder kleinere Neuerungen zwischendurch mal reinbringen, wird die Enttäuschung möglicherweise umso größer sein. Manche Spieler werden das leider schnell auf ein "ihr habt 4 Wochen nur an einer kleinen Textänderung gearbeitet?!" reduzieren. Jeder möchte (verständlicherweise) häufigere Updates, aber gleichzeitig wollen die meisten, dass das auch einigermaßen bedeutsame Updates sind.
Gleichzeitig gibts noch ein kleineres Problem, dass manche Spieler not amused sind, wenn häufig kleine Updates erscheinen, die aber größere Downloadmengen bedeuten. In der neuen Version kann es schnell vorkommen, dass selbst kleinere Änderungen 1-2+ GB Downloadgröße verursachen. Ich versuche daher die Updates möglichst zusammenzupacken. Das gilt aber auch eher für reine Bugfixes.
Bislang versuche ich mich die ersten 1-3 Wochen nach einem Release generell komplett auf Hotfixes zu konzentrieren (die durchaus aber auch mal kleinere Neuerungen mitbringen können). In der Zeit fange ich meist noch nicht an, an größeren Sachen zu arbeiten. Manchmal brauchen Bugfixes aber auch etwas länger, gerade wenn es komplexere Probleme sind - dann kann es passieren, dass es der Fix nicht mehr in dieses 1-3 Wochen Fenster schafft.
Wenn aber wirklich gravierende Probleme bestehen versuche ich eigentlich auch ein Zwischenupdate rauszubringen. Die derzeitigen Bugs sind definitiv nervig, aber für die meisten Spieler nicht unbedingt Game-breaking. Eigentlich wollte ich diesmal sogar noch ein Zwischenupdate rausbringen, was noch ein paar Probleme behoben hätte, habs aber vermasselt
-
Leider fehlt noch eine setEquippedItem() Methode bei NPCs, ich kann die aber mit dem nächsten Update noch reinpacken
Was den Modifier oder die Durability angeht, die werden beim Droppen dummerweise fest verdrahtet (daher ignoriert das deine Änderungen)... das muss aber nicht sein, daher kann ich das auch mit dem nächsten Update anpassen. Leider gibts aktuell keinen direkten Workaround (außer höchstens "Settings_NpcDropEquippedItem" in der server.properties zu deaktivieren und stattdessen selbst das Item zu spawnen beim Tod es Npc)
-
Danke für den Hinweis! Die Methode ist leider nicht korrekt verdrahtet, daher funktioniert sie nicht (ist also tatsächlich ein Bug)
Ich werde das aber mit dem nächsten Update beheben! Ich werde auch nochmal andere API-Funktionen durchgehen und schauen, ob da irgendwas schief sitzt. -
Danke für die Permissions! Sorry dass es etwas länger dauerte, aber ich kann bestätigen, dass hier etwas faul ist
Es gibt manche Prüfungen, bei denen die Area-Permission tatsächlich auf die default.json zurückfällt. Das betrifft zwar nicht den Spieler direkt, d.h. beim direkten Setzen der Spielerpermission wird das korrekt übernommen, aber bei positionsbezogenen Prüfungen ist das problematisch (zumindest bei manchen Permissions).Mir ist das vorher leider nicht aufgefallen, da Fliegen davon nicht betroffen ist, und bei den Vehicle-Permissions muss ich editownvehicles wohl doch übersehen haben (obwohl ich das ja extra erwähnte), sodass ich mein Fahrzeug trotzdem editieren konnte
Clientseitig werden die Permissions übrigens korrekt gesetzt (deshalb tauchen sie in der Permission-Liste als positiv auf), aber die Entscheidungen werden in den meisten Fällen vom Server getroffen, wodurch der Bug verschleiert blieb.Ich werde das mit dem nächsten Update beheben, danke nochmal fürs Nachhaken!
Als schnelle Lösung könntest du entweder die gewünschten Werte direkt in der Area-Permission setzen (diese Problematik taucht nur bei den Permissions auf, die nicht von der Area-Permission überschrieben werden), oder alternativ (um zumindest die Fahrzeug-Problematik zu beheben) in der default.json editownvehicles löschen (der Standardwert dafür ist ohnehin true, d.h. der Spieler wird dann seine eigenen Vehicles weiterhin bearbeiten können).was ich grad nicht schnalle - bezieht sich das wirklich auf eine Gruppenberechtigung, oder ist das im Grunde nicht nur eine umbenannte Standardberechtigung die ebenfalls im Hauptordner liegt?
Ja, das ist eine Gruppenberechtigung, d.h. neue Spieler werden automatisch dieser Gruppe zugewiesen. Prinzipiell dasselbe als wäre der Admin immer da und würde den neuen Spieler manuell der Gruppe zuweisen
Die default.json bleibt davon unberührt.
-
ok aber wenn ich dich richtig verstehe müsste dann doch wenn ich in default.json *vehicles: false habe in der gruppen.json *vehicles: true und in allen area.json diese werte NICHt gesetzt habe doch der wert true sein oder? das ist aber nicht der fall. Sobald ein spieler eine area betritt scheint nur noch default.json < area permission zu gelten, ohne gruppen permission zu beachten.
Ja, wenn in der Area-Permission dieser Wert nicht gesetzt ist, dann sollte der Wert der Gruppenpermission weiterhin gelten (sofern der Spieler in der Gruppe ist).
Ich habs bei mir auf einem lokalen Server einmal kurz probiert: In der default.json ist zB Fliegen nicht erlaubt. In der Gruppen-Permission ist es explizit erlaubt. In der Area-Permission ist es gar nicht definiert. Innerhalb der Area kann der Spieler weiterhin fliegen (die Area-Permission wird aber gesetzt und überschreibt alles, was darin definiert war, zB Chat)...
Habe testweise auch die editvehicles und editownvehicles Permissions getestet (d.h. in default.json false, in Gruppen-Permission true, in Area-Permission nicht definiert). Auch das funktionierte
Andererseits will ich meine Klappe auch nicht zu weit aufreißen, da du (und SonoBionda) ja schon einige Area-/Permission-bezogene Probleme gefunden habt, die ich auf Anhieb nicht reproduzieren konnte
Daher sende mir vll am besten mal die Permissions zu, damit ich sie mir genau anschauen kann (oder nenne mir die genauen Permissions, die nicht funktionieren) -
Leider stehen die Biome bzw. neue Regionen momentan noch etwas weiter hinten an
Das Problem ist, dass dafür einiges an neuer Vegetation nötig ist (das aber leider auch recht zeitaufwändig ist)... das ist momentan der größte Blocker bei diesem Thema.Momentan liegt der Fokus (hinsichtlich der "größeren Features") erstmal bei überarbeiteten Höhlen, Höhlen-POIs und auch Dungeons. Außerdem sind die NPCs noch ein wichtiges Thema (leider zu lange vernachlässigt), vor allem deren Pathfinding/Wegfindung. Die Überarbeitung der NPCs ist momentan im vollem Gange (ebenso wie Höhlen). Wenn das durch ist, können wir auch endlich Meeresbewohner reinbringen.
Danach würde ich eigentlich ganz gerne bewegliche Bauteile in Angriff nehmen. Und wir kommen an einen Punkt, ab welchem ich auch langsam gerne in die letzten großen "Klopperthemen" Züge und Elektrizität reinluschern würde (um wenigstens schonmal ein paar Grundlagen zu schaffen).
Einzelne "Spezial-Biome" (wahrscheinlich unter der Haube als POI umgesetzt) könnte ich mir aber durchaus schon früher vorstellen. Das wären zB Oasen in der Wüste, ggf. auch Vulkane (mit Tessellation verspüre ich einen Drang, Vulkangestein endlich natürlich spawnen zu lassen
). Aber ich finde auch den Vorschlag von Devidian zu Krater-Biomen bzw. Meteroiteneinschlägen sehr interessant! Ich müsste mir mal Gedanken machen, ob die bisherige POI-Logik für diese Spezial-Biome wirklich sinnvoll ist, oder ob das noch ein besonderer Untertyp wird Ich würde aber auch weitere Biom-Vorschläge begrüßen, vor allem auch was solche Spezial-Biome angeht!
Außerdem ist das gemäßigte Biom weniger komplex als die anderen beiden. Sind Änderungen geplant?
Wie genau meinst du das? Wünschst du dir mehr Wälder und Sub-Biome im gemäßigten Gebiet? Oder noch weitere Sub-Biome dafür? Wenn du Vorschläge hast bin ich offen dafür
-
Tatsächlich ist es so, dass Area-Permissions bzw. spielerbezogene Area-Permissions eigentlich nicht von der Standard-Area-Permission erbt. Area-Permissions sind etwas spezieller, sie sind quasi eher als "Patch" zu verstehen statt reine Vererbung. D.h. es werden nur die Werte überschrieben, die in der Area-Permission definiert sind. Prinzipiell ist es beim Betreten einer Area so, dass die aktuelle Permission des Spielers (default.json oder Gruppen-Permission) temporär die Area-Permission erbt (und nur die Werte überschrieben werden, die in der Area-Permission explizit gesetzt sind).
Als Area-Permission wird entweder eine spielerbezogene Area-Permission genommen (falls gesetzt), oder die Standard-Area-Permission. Beide haben nichts miteinander zutun, d.h. eine spielerbezogene Area-Permission ersetzt für diesen Spieler die Standard-Area-Permission, erbt aber nichts von ihr.
Wenn die default.json nicht existiert, dann werden dort einfach die Standardwerte, die vom Spiel aus definiert sind, genommen (im MP sind die Werte für Spieler so gewählt, dass ein Spieler fast nichts darf). Wenn der Spieler einer Gruppe zugewiesen wird spielt das aber keine Rolle (lediglich für die Keys, die nicht in der Gruppen-Permission gesetzt sind, denn die stammen dann weiterhin aus der default.json).
Die Prioritätskette ist also: default.json < Gruppen-Permission < server.properties-Overrides (optional) < Area-Permission (Default oder spielerspezifisch)
Zum Fliegen-Beispiel: Wenn in default.json Fliegen nicht erlaubt ist, in der Gruppen-Permission jedoch schon, dann sollte der Spieler eigentlich auch in der Area fliegen dürfen - außer die Area-Permission sagt explizit Nein zum Fliegen. Wenn du hingegen Fliegen nur in der Area erlauben willst, reicht es, in der Area-Permission Fliegen zu erlauben.
-
Sorry for the late response! If you don't get a reply within a few days or a week, it's totally fine to bump the topic. Unfortunately I also tend to lose track of the Java sections of the forum (this isn't your fault, it's my fault, restructuring the forum is still on my to-do list).
However, unfortunately the log files only cover the most recent and previous game session, so they are only helpful immediately after such a problem occurs. Ideally send a report from the game right when you notice that something is missing or weird, this will automatically attach the log files. It's basically the only way to find out what's really happening.
There is a bug that objects and plants sometimes don't get loaded properly on clientside, but this is typically fixed by reloading the chunk (either by moving away or by reloading the world). Losing objects permanently for no reason is that seems to happen extremely rarely... if someone ran into such an issue before, it was typically related to "Gravity", i.e the objects did break because they had no contact to the ground.
However, recently I found a bug that caused gravity to break objects in rare cases, even if they had contact to the ground or something solid (originally this issue was raised in connection with blueprints). This might be responsible for the objects to disappear in your case.
I've also expanded the logging to the "Events.db", so whenever an object is deleted, it will be tracked. When sending a report after the next update, a dump of this file will be attached automatically (this should make it easier to find out why a particular object disappeared).
But as a quick fix in the meantime, you can turn off Gravity for objects (and plants) in the game settings. That should prevent objects from breaking.
-
Can anyone launch fireworks after last update? I've just found that I can't. After I ignite a firework rocket, sparks keep bursting from it for seconds, minutes, tens of minutes... but the rocket doesn't go up. Maybe it's caused by the item placement, that it sticks too strong to the ground?
Unfortunately it's indeed a bug, as mentioned by LoneRanger
It affects fireworks, but also dynamite and grenades... but it will be fixed with the next update -
This is unfortunately a bug, caused by the gravity checks for objects (and plants)
If gravity checks are enabled, the game checks if an object/plant has contact to the ground (or a wall), and if there is no contact, the object breaks (if it was just created a few moments ago, the game spawns the object as item instead of breaking it). When placing a blueprint, this check is sometimes executed too early (before the full collision is actually built), so the game thinks the object has no contact to the ground or walls.I will try to get this fixed with the next update. But in the meantime you can also disable gravity checks in the game settings (turn off "Enable Gravity for Objects" in the Miscellaneous settings), that should prevent the objects from breaking
-
Wie SonoBionda schon sagt, das gibt an, ob jemand das Produkt besitzt bzw. in seiner Steam-Bibliothek hat. Früher hat Steam das mit einem kleinen Maus-Symbol angezeigt, das wurde aber nun durch die drei Striche (oder "Bücher") ersetzt
-
Gibt es für undobp eigene Rechte Eintrag?
Nee, leider nein
Das wird über den normalen undo abgedeckt. Wäre eine separate Permission für Blaupausen denn sinnvoll? -
Ja, theoretisch können wir das via Permissions auch für den Survival ermöglichen
Du möchtest also in Areas das Teleportieren (überall hin) erlauben und außerhalb der Areas nicht, ist das richtig?
In dem zusammenhang wehre es nicht Schlecht wenn mann auch nur in Areas hinein Teleportieren könnte. Also von Stadt zu Stadt.
Das ist wahrscheinlich etwas schwieriger umsetzbar, da Areas auf der Karte nicht angezeigt werden bzw. dort bisher noch nicht berücksichtigt werden... wäre aber trotzdem ein interessantes Feature! Ich packe es auf jeden Fall mal auf die Liste (wirds aber leider nicht mehr ins nächste Update schaffen)
Aktuell ist es mit Plugins noch nicht möglich, Karten Interaktionen abzufangen.
Es wäre wahrscheinlich auch sinnvoll, das in dem Zuge direkt umzusetzen bzw. die nötigen Events (und Kartenzugriff) für die API bereitzustellen
Aber bei beiden Varianten müsste mann noch überlegen, wie mann das auf der Karte Visualisieren kann, das in bestimmte bereiche hinein Teleportiert werden kann.
Es ist geplant, dass mehr auf der Karte visualisiert bzw. gezeichnet werden kann (Linien, Bereiche usw), damit könnte man dann auch grundsätzlich Areas darstellen
Generell sollte es eine Teleportmöglichkeit durch das Spiel geben.
Ein Teleport-System, mit welchem man mehrere Teleportpunkte (dauerhaft) festlegen und bei Bedarf immer wieder dorthin teleportieren kann wird es möglicherweise noch ins nächste Update reinschaffen (sonst spätestens ins Update danach)
-
Ich hab das auch gelesen
... naja gut ... da steht ja auch ein "Probably"Stimmt
Sorry, habe ich glatt vergessen Es sind zwischenzeitlich ein paar andere Themen dazugerutscht, die eigentlich etwas unerwartet waren... aber gut, vielleicht wird Juli noch was (wenn dann eher in den nächsten 1-2 Wochen), sonst August. -
aso, ich meinte Unity Komponenten aufzulisten die schon auf GameObject oder prefab drauf sind. !
NICHT alle die Unity so hat ... uff
Unteranderem will ich wisse ob z.B.: addComponent erfolgreich war, oder welche Komponente kann ich mit setComponentProperty glücklich machenAchso, das habe ich falsch verstanden
So macht das auf jeden Fall mehr Sinn. D.h. du möchtest eine Liste aller Components, die auf dem geladenen Prefab vorhanden sind? Im Falle des Basis-GameObject hingegen wäre es dann meist wahrscheinlich Transform, MeshFilter und MeshRenderer, bei Prefab hingegen dann ggf. noch die vom User im Editor erstellten Components.Ich muss nur mal schauen, wie wir das am besten umsetzen... der Server lädt normalerweise gar keine Assetbundles, sondern nur der Client. Es gibt bereits eine Ausnahme (getAllAssetNames()), aber für Components müssten die ganzen Prefabs geladen werden (samt Texturen usw). Vmtl. wäre hier ein Cachen zwingend erforderlich, damit Mehrfachaufrufe nicht den Server zuballern... ich schaue mir das auf jeden Fall mal genauer an
-
Also ist meine Vermutung mit dem Winkel falsch?
Generell oder nur für das Abfallen der Objekte bei BP's?Weder noch, der Winkel kann dabei durchaus eine Rolle spielen
Ebenso die Skalierung. Es hängt tatsächlich von mehreren Faktoren ab, kann aber auch rein zufällig passieren. In Fällen, wo ohnehin keine Verbindung besteht, fallen Elemente aber natürlich ebenfalls ab.Da du es in deinem Beitrag explizit erwähntest: Zusätzlich zu undo gibt es auch noch undobp, womit die letzte platzierte Blaupause zurückgesetzt wird (dann muss man sich nicht schrittweise durch die letzten Änderungen wühlen)
Aber eine richtige Undo-Liste ist auch noch in Arbeit, vll schafft sie es ins nächste oder übernächste Update. -
red51 kannst du bitte API Methoden einbauen die Unity Komponenten aufzulisten.
Jein... also grundsätzlich wäre das möglich, aber das Problem ist, dass es in Unity so unendlich viele Komponenten gibt, ein nicht unwesentlicher Teil davon aber entweder veraltet, inkompatibel oder nicht für die HDRP geeignet ist
Um wirklich alle kompatiblen bzw. sinnvoll einsetzbaren Komponenten zu erhalten müssten wir eigentlich von Hand eine Liste anlegen... wofür würdest du die Liste denn benötigen? Für ein konkretes Plugin, oder für eine allgemeine Übersicht (zB im Wiki)?
inklusive einer Klasse in der API die UnityComponent repräsentiert mit 3,4 Infos mehr und Methoden wie string getName()
List<UnityComponent> getAllUnityComponents()
Schön wäre es wahrscheinlich, aber so ein 1:1 Mapping ist auch manchmal unerwartet viel Arbeit (besonders wenn es von der allgemeinen Grundklasse "Component" ausgeht)... und würde wahrscheinlich ein umfangreiches und sauberes Planen erfordern (unzureichend durchdachte Design-Entscheidungen in der API sind immer doof, da wir das dann meist nicht mehr so einfach ändern können)
Sinnvoll wäre das aber wahrscheinlich auch erst dann, wenn es in der API auch wirklich entsprechende Repräsentationen jeweiliger Components geben würde (zB Rigidbody, VisualEffect usw). Andererseits gibts aber bereits zB "Collider" usw, d.h. hier müsste eigentlich alles zu diesem eher universelleren System zusammengeführt werden... unter der Haube wiederum ist es aber oft kein 1:1 Mapping, da auf dem Server ohnehin keine Unity-GameObjects o.ä vorliegen, sondern das ganze nur abstrakt repräsentiert ist... und manche Quirks der Unity HDRP von der API ohnehin ausgeblendet werden (zB dass eine Light-Component alleine nicht ausreicht, sondern ebenfalls eine HDAdditionalLightData-Component erforderlich ist, gleichzeitig aber nur die Hälfte der Light-Component-Properties funktionieren, während die andere Hälfte als gleichnamige Methode in HDAdditionalLightData zu finden ist usw).
Unterm Strich leider wahrscheinlich wirklich einiges an Aufwand
eine API Methode die Unity MonoBehaviour Methoden per Reflection aufrufen kann
z.B.: invokeMonoBehaviourMethod() oder so
Theoretisch müsste das eigentlich auch mit invokeComponentMethod() funktionieren (da MonoBehaviour von Behaviour abgeleitet ist, welches wiederum eine Component ist)
Welche Methode von Behaviour/MonoBehaviour würdest du denn auf dem Wege aufrufen wollen?
