Sascha

OnTriggerEnter geht auch. Das eine ist halt für Kollisionen und das andere für Dinge, die einen Trigger berühren. Trigger sind halt durchlässig, deshalb ist das keine Kollision in dem Sinne. http://www.unitystudygroup.com/collisiontable

Grundlegender Hinweis: Wenn etwas nicht funktioniert, und du glaubst, es sei ein Bug in Unity oder so, dann liegt's mit 99.893% Wahrscheinlichkeit in Wirklichkeit an dem, was du gemacht hast Mit if (Input.GetAxis("Fire2") >= 0.5f) kann man einfach nicht sonderlich viel falsch machen. Kannst ja einfach mal einen UI-Text irgendwo hintun und da so ein Script drankleben: private void Update() { GetComponent<UnityEngine.UI.Text>().text = Input.GetAxis("Fire2") + ""; } (Kurz und hässlich hingeschrieben...) Wenn dein Controller nicht irgendwie kaputt ist, dann solltest du damit recht sinnvolle Werte sehen können.

Camera.main.transform.gameObject.transform.position Alter! Das stimmt leider nicht. Vector3.forward ist das gleiche wie new Vector3(0,0,1). Transform.forward ist die Richtung, in die das Objekt "schaut". transform.forward eines Objekts mit Rotation (0, 90, 0) wäre entsprechend (1, 0, 0). Anders gesagt: transform.forward ist ein Shorthand für transform.TransformDirection(Vector3.forward). Wenn du transform.TransformDirection(transform.forward) schreibst, kommt Käse dabei heraus. Ich nehme mal an, du willst den "vorne"-Vektor der Kamera haben. Hast aber nicht Camera.main.transform.forward geschrieben. Du benutzt hier den "vorne"-Vektor des Objekts, auf dem das Script liegt.

Syntax ist fast in Ordnung. Es fehlt das Semikolon hinter Debug.Log, ansonsten ist Debug.Log halt kleingeschrieben. Sollte die Syntax falsch sein, sagt Unity dir das auch in der Konsole, und es lässt dich den Play Mode nicht starten.Wenn du die Komponente also auf einem GameObject hast und keinen Log-Eintrag siehst, dann liegt's am ehesten daran, dass irgendwelche Bedingungen für das Event OnCollisionEnter nicht stimmen. Du könntest z.B. 2D-Collider benutzt oder keinen kinematischen Rigidbody beteiligt haben.

Klingt, als wäre es eventuell ein Problem in deiner Animation-State Machine.

Hm... Spricht für dich etwas dagegen, alle Räume in einer Szene zu haben und im Spielverlauf die Räume einfach zu deaktivieren und beim Betreten wieder zu aktivieren?

Öh... hatte ich doch weiter oben schon gepostet? Ja, können sie ja auch nur. Deshalb musst du eine Grenze setzen (im Beispiel 0.5, also 50%), wie weit man den Trigger runterdrücken muss, damit er wie ein Knopf als "gedrückt" zählt. Hier landet man aber eben ganz schnell in der Falle, die @malzbie beschrieben hat. Drückst du beide Trigger exakt gleichzeitig runter, bleibt der Wert immer auf 0. Um beide Trigger gleichzeitig und unabhängig voneinander abfragen zu können, musst du vom alten Standard-Input-System weg. Ob das neue System da besser ist, weiß ich nicht. Wie gesagt, @malzbie und ich benutzen beide Plugins für Controller-Support. So eins zu bauen oder auch nur zu besorgen ist jetzt nicht mehr unbedingt Anfängerstoff.

Unity ist das richtige Programm wann immer du Echtzeitgrafik haben willst, also eine 2D- oder 3D-Welt, die durchgehend neu gezeichnet wird. Wenn du eine App bauen willst, die eigentlich nur Text und Bilder anzeigt, und die sich kaum verändert, wenn man nichts drückt (stelle dir eine Einkaufslisten-App oder einen Kalender vor), dann geht das mit Unity auch, ist aber irgendwie mit Kanonen auf Spatzen schießen. Zum Thema habe ich vor ein paar Jahren mal etwas geschrieben. Ist etwas "direkt" formuliert, aber ich denke, Keine Ahnung, ich hab davon vorher noch nie gehört und beim Suchen gerade nur andere Apps gefunden. Wenn du dir mal meinen verlinken Post durchgelesen hast, würde ich sagen: Du nimmst dir ein Blatt Papier oder eine Textdatei und schreibst einfach mal auf, wie dein Spiel funktionieren soll. Das geht gerne auch als Diagramm. Du setzt dich an Grundlagentutorials, damit du über kurz oder lang genügend lernst, um dieses Konzept selber zu implementieren. Bei Fragen und Problemen, die dabei entstehen, können wir dir hier gut helfen

Wenn du irgendwie eine Beschreibung, Bilder oder ein Video darüber hättest, was du meinst, das wäre nett Da ich das Spiel nicht gespielt habe, weiß ich nämlich nicht, worum es geht.

Hast meinen Post nicht so richtig gelesen, oder? Es geht darum, wann OnEnable auf dem suchenden Objekt ausgeführt wird. Dass du im Inspektor die Referenz auf den SMR siehst, ist für mich nur ein Hinweis, dass du mehrere Stellen hast, an denen mit dem Wert des Feldes gearbeitet wird. Setzt du den noch irgendwo anders? Zum Beispiel im Inspektor? Ansonsten schau halt mal, was ein Debug.Log(smr); unter der GetComponentInChildren-Zeile sagt.

Ist halt nur minimal anders. if (Input.GetButton("Ein Button")) if (Input.GetAxis("Ein Trigger") >= 0.5f) // mindestens halb runtergedrückt

Da dein ganzes Objekt deaktiviert ist, schau mal, ob OnEnable überhaupt jemals ausgeführt wird. Ansonsten übergibst du ja true, womit er theoretisch auch deaktivierte Objekte finden kann (sofern der Code überhaupt ausgeführt wird).

GetComponent (und alle Varianten davon) werfen keinen Fehler, wenn die gesuchte Komponente nicht gefunden wird. Sie geben einfach null zurück. Eine NullReferenceException wird nur dann geworfen, wenn du eine Variable hast, dessen Wert null ist, und du dann mit dem (nicht vorhandenen) Objekt arbeiten willst. var thing = GetComponent<Thing>(); // Es gibt kein Thing auf diesem GameObject, GetComponent gibt null zurück thing.DoStuff(); // HIER fliegt eine NullReference- (oder ähnliche) Exception Eine NullReferenceException kann daher nur dort auftreten, wo du mit Punktnotation oder Indexer auf eine Variable zugreifst: thing.DoStuff() thing.someField thing[index] Da nichts davon hier der Fall ist, stimmt die Zeilennummer der Exception vermutlich einfach nicht. Speichere mal deinen gesamten Code. Und nur um sicherzugehen, re-importiere ihn nochmal. Probier's dann nochmal aus.

Mit Camera.aspect kannst du das Verhältnis von Breite zu Höhe der Kamera abfragen. Standardmäßig ist die Höhe ja Konstant, also sollte es reichen, die Y-Position der oberen Kante damit zu multiplizieren, um die X-Position der rechten zu ermitteln.

Hierzu sei gesagt, dass das an DirectInput liegt, was Unitys Input Manager standardmäßig benutzt. Ich hab bei meinen Projekten einen Wrapper für XInput 1.3, damit ist der XBox-Controller-Support um einiges besser. Das ist also keine Limitierung der Hardware, sondern von der Software, die Unity da benutzt... also kein Problem, das man nicht lösen könnte. Hat eigentlich mal jemand das neue Input-System ausprobiert, ist das da schlauer? Ich bin von der Funktionsweise des Dings kein Fan, deshalb hab ich damit noch nicht so viel gemacht...