Sascha

Also ist deine Szene irgendwie kaputt gegangen? In dem Fall wäre eine NullReferenceException keine Überraschung - Objekte, die von anderen Objekten gebraucht werden, fehlen. Die anderen Objekte sind dann "unzufrieden", dass die referenzierten Objekte weg sind. So "Knopf X öffnet Tür Y" + "Tür Y ist weg" = "Knopf X weiß nicht, was er tun soll". Warum deine Szene kaputt ist, kann ich nicht sagen. Vielleicht vergessen zu speichern, vielleicht irgendein Plugin installiert, das Mumpitz macht. Für solche Fälle ist Versionierung ganz praktisch, aber das muss man auch erstmal lernen. Du musst jetzt jedenfalls deine Szene reparieren. Du hast irgendwo eine "Grid"-Komponente, die ein "ShapeStorage" referenziert. Diese Referenz (das, was du im Inspektor einstellst), ist kaputt. Eventuell, weil dein ShapeStorage-Objekt weg ist.

Moin, was genau heißt denn bitte Ist da ...Code weg? Ansonsten kann man dir bei einem Fehler, den dein Code wirft, nicht helfen, wenn du den Code nicht postest.

Ich hab nicht direkt Erfahrung mit der Kombination WebGL + Asset Bundles, aber da höre ich zum ersten Mal von. Daten dekomprimieren ist nichts, was JavaScript nicht können sollte. Aber wie gesagt... da kann ich mich irren. Du darfst halt die Größe unkomprimierter Dateien nicht unterschätzen. Versuch nochmal, Komprimierung zum Laufen zu kriegen.

Moin! BuildAssetBundleOptions.UncompressedAssetBundle Hmm...

Du benutzt wirklich 2022.1.6? Hoffentlich nicht... Du solltest nicht unbedingt mit bleeding edge (Betaversion, die eine Menge Bugs enthalten kann) arbeiten, sondern dir eine LTS (stabilere Version) runterladen. Das wäre aktuell 2021.3.5. Kommt halt drauf an, ob dein Standard-Anfänger-Spiel Lightmaps haben soll. Hier gibt's was zu lesen: https://docs.unity3d.com/Manual/Lightmappers.html Kurz gesagt: Anstatt eine gewisse Menge an Rechenleistung durchgehend dafür zu verbraten, dass das Licht in der Szene berechnet wird, kann man Licht auch statisch auf seine Oberflächen backen. Dann wird halt einfach ein roter Fleck fest auf deinen Boden gepinselt, anstatt dass das rote Licht die ganze Zeit durch Lichtberechnungen da ankommt. Wenn deine Szene sich darauf verlässt, dass eine Lightmap da ist, diese aber fehlt oder irgendwie nicht geladen werden kann, dann sieht das Licht entsprechend komisch aus. Ausschalten sollte je nach Version in den Lighting Settings (Edit > Project Settings > Lighting) gehen.

Öh... ich würde jetzt einfach mal raten und sagen: Die Priorität lag auf dem Setup im Editor, damit Designer da schön alles anlegen können. Deshalb packt man ja auch nicht mehr einen Haufen Komponenten auf die Kamera, sondern erstellt PostProcessing-Profile, die man Volumen zuweist. Damit man situationsabhängig PostProcessing einstellen kann. Dass bei so einem System dann die API etwas komplexer wird und man definieren muss, wo genau man bestimmte Änderungen haben will (weil es ja nicht mehr mehr nur ein globales PostProcessing gibt), wundert mich wenig.

Benutzt du eine aktuelle oder eher eine veraltete Unity-Version? Was für einen Lightmapper hast du aktiv? Mit welchen Einstellungen? URP oder HDRP an? Das klingt halt sehr danach, dass dein Lightmapper komische Dinge (nicht) macht. Wenn du den Lightmapper gar nicht aktiv benutzt, schalte ihn einfach aus.

Moin! Vermutlich nur mit der obsoleten BuildAssetBundle-Methode. Wozu brauchst du denn die Reihenfolge? Im Notfall kannst du den Dingern ja Namen mit nem Index geben und die danach laden.

Was meinst du mit "offen"? Wenn eine Szene nicht "offen" ist, sieht man sie doch sowieso nicht? 🤔 Oder meinst du "offen" in dem Moment, wo du buildest?

Öh, klar, generell geht das. Ob das jetzt so richtig wäre, weiß ich aus dem Kopf nicht. Du wirst aber vielleicht auch noch ein Attribut über das Array packen müssen.

Es ist auf jeden Fall gut, Strings zu vermeiden, weil man die Nachteile einsieht... "weil Sascha das sagt" ist aber kein sehr guter Grund Viel Erfolg, und nie zu wenige Fragen stellen

Verstehe, ist nachvollziehbar Theoretisch geht das auch, aber du machst es dir damit schwerer als es sein muss. Arrays sind eher für gleichartige Elemente da. Also auch semantisch. Obwohl du da vier Strings hast, sind das ja eine Frage und drei Antworten. Nene, ein Array ist schon gut, aber ein eindimensionales. Da packst du dann z.B. Structs rein. public struct Question { public string word; public string correct; public string wrong1; public string wrong2; } public Question[] questions; Ist jetzt nur ein ganz stumpfes Beispiel, aber du siehst, wie es deinen XML-Code genau wiederspiegelt. Statt einer Tabelle ohne Überschriften hast du jetzt eine Liste von Fragen (wobei jede "Frage" aus deinen vier Strings besteht). Geht alles. Letztenedes sind auch XML- (oder Json- oder Yaml-)Dateien nur Textdateien mit einem bestimmten Format drin. Ob du dieses Format selber erstellst oder ein Standardformat wie diese drei nimmst, gibt sich nicht viel.

Also komm, ein Minimum an Mühe darfst du dir mit deinem Post schon geben.

Das macht das Vorhaben es definitiv um einiges realistischer. In dem Fall brauchst du keine Netzwerkbibliothek wie Mirror, sondern einfach nur HTTP(s)-Abfragen. Die kannst du mit UnityWebRequest senden. Das schaut man sich einmal an und dann läuft das. Herausforderungen sind dann eher, ein vernünftiges Anfrageprotokoll zu designen und das Backend zu schreiben. Vielleicht kann man unter hinreichend starkem Drogeneinfluss tatsächlich einen Unity-Prozess hinter den Webserver schnallen, aber... ich würde dringend davon abraten Insbesondere, da du gar kein Echtzeit brauchst. Dann bringt ein Unity-Prozess überhaupt keinen Mehrwert. Einfach ein ganz normales Backend mit einer beliebigen Webserver-Sprache/-Software bauen und gut is. Für Echtzeit-Multiplayer. Wie gesagt, ohne Echtzeit ist ein mit Unity erstellter Build auf dem Server völlig am Ziel vorbei.

@Michael S. Wenn dir die Nebenunterhaltung zwischen MaZy und mir das Lesen schwerer macht sag Bescheid; ich trenne die Beiträge dann aus dem Thema heraus Dass da Code generiert wird? Ist eine der verfügbaren Modi, der inzwischen immerhin nicht mehr der ist, der im ersten Tutorial empfohlen wird. Stattdessen kann man auch SendMessage (meh), C#-Events oder - mein Favorit - SO-Referenzen nutzen, um zu definieren, von welcher InputAction wir gerade reden. Als das neue InputSystem-Paket gerade neu raus war, war der einzige oder zumindest der erste empfohlene Weg, C#-Code generieren zu lassen und dann statisch darauf zuzugreifen. Das war das erste, was einem gezeigt wurde, und danach hab ich das Paket nicht weiter angeschaut damals. Danke! Leider wird's gefühlt von meiner Seite aus dabei bleiben. Ist aber immerhin modular mit Transport Layer und Serialization Engine... und halt Open Source. Wenn da also jemand Potential sieht und es weiterführen will... Klingt sehr interessant! Hast du da einen spürbaren Performance-Unterschied?