Jump to content
Unity Insider Forum

ArgumentException beim Versuch eine Scene zu laden


Brighthell96

Recommended Posts

Hallo Leute,

wenn ich versuche eine Scene mit buildindex zu laden welche nicht existiert, bekomme ich eine Ausnahme in meinem LevelLoader Script: 

Zitat

ArgumentException: GetSceneByBuildIndex: Invalid build index: 2
To add a scene to the build settings use the menu File->Build Settings...

 obwohl ich eine Überprüfung mache ob die Scene existiert bevor ich sie versuche zu laden.

Hier die Klasse:

public class LevelLoader : MonoBehaviour
{
    public Animator transition;
    public float transitionTime = 1f;

    public void LoadNextLevel()
    {
        if (SceneManager.GetSceneByBuildIndex(SceneManager.GetActiveScene().buildIndex + 1).IsValid() == true)
        {
            StartCoroutine(LoadLevel(SceneManager.GetActiveScene().buildIndex + 1));
        }
        else
        {
            Debug.Log("No next scene found!");
        }
    }

    IEnumerator LoadLevel(int levelIndex)
    {
        transition.SetTrigger("Start");

        yield return new WaitForSeconds(transitionTime);

        SceneManager.LoadScene(levelIndex);
    }
}

ist meine Überprüfung ob die Scene existiert falsch oder warum bekomme ich trotzdem diese Ausnahme? Hoffe ihr könnt mir helfen.

vielen Dank im vorraus 

MFG Marc

Link zu diesem Kommentar
Auf anderen Seiten teilen

Die Überprüfung schaut nicht, ob die Build-Liste überhaupt so viele Elemente hat. Deshalb kracht es schon in deiner if-Zeile bei GetSceneByBuildIndex, bevor IsValid überhaupt aufgerufen wird. Da könnte SceneManager.sceneCountInBuildSettings helfen, aber ganz ehrlich - die Build-Liste ist ziemlich unberechenbar und einfach blind die nächste Szene zu laden kann ganz schnell in die Hose gehen. Da gibt's mehrere Wege, die ich besser finden würde. Am ehesten würde ich wohl zu einem ScriptableObject greifen, aber eine statisches String-Array, in dem die Namen deiner Szenen drin sind tut's auch wunderbar.

Link zu diesem Kommentar
Auf anderen Seiten teilen

danke für die Antwort. Du bist gefühlt in jedem Beitrag anwesend und hilfst den Leuten das finde ich unglaublich :D aber genug geschleimt. Was die ScritableObjects angeht.. ich muss mir das wohl wirklich alles nochmal angucken. Mein Verständnis für die Teile ist leider... 😕 so lala. Ich habe mir bereits tutorials angeschaut wie man sie erstellt und grob anwendet aber ich verstehe noch nicht so ganz wann man sie anwendet und wie man das ganze strukturieren soll. 

Als Beispiel habe Ich noch ein anderes, pausiertes Projekt. und zwar eine Art 2D RPG. in diesem RPG wird es ähnlich wie bei Zeldagames überall verschiedene Truhen geben die man nur genau 1x öffnen können soll. Allerdings macht mir Gedanke Kopfschmerzen für jede einzelne Kiste einen Zustand zu haben(z.b. bool open) der auch mit dem game jedes mal für jeeeede Kiste gespeichert werden muss wenn man das Spiel speichert. Wären für solche Dinge z.b. ScriptableObjects empfehlenswert? Und wie würde ein solches ScriptableObject aussehen? Ich stelle mir das so vor dass man genau ein ScriptableObject hat in dem seeeehr viele booleans sind (für jede Kiste einen). Aber ich glaube das ist nicht die richtige Art wie man ScriptableObjects nutzen sollte.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Ob du jetzt deine bools überall verteilt oder alle auf einem Haufen hast, ändert ja an der Anzahl nichts. Das einzige, was sich ändert, ist dass die Daten plötzlich nicht mehr an der Stelle des Programms sitzen, wo sie relevant sind, sondern irgendwo anders. Von daher sind Werte auf den Kisten selbst schon ganz wünschenswert.

ScrtipableObjects sind für viele irgendwie schwierig initial zu greifen. Du bist da nicht alleine. Ich versuch's mal so auszudrücken: Mit Komponenten kann man ja eine Menge cooler Sachen machen. Man kann welche im Editor erstellen und dann lauter Werte einstellen, damit man ein Ding hat, das genau so ist, wie man es haben will. Komponenten müssen aber auf GameObjects sitzen, und GameObjects wollen in einer Szene sein. Gibt natürlich auch Prefabs, aber die sind halt dafür da, dass man davon mit Instantiate Instanzen erzeugt, die dann in eine Szene geschmissen werden. Komponenten haben deshalb auch etwas Zeugt dabei, wie z.B. die .gameObject-Eigenschaft oder GetComponent, um andere Komponenten auf demselben GameObject zu finden. ScriptableObjects erlauben dir ebenfalls, Dinge zu bauen und Einstellungen vorzunehmen. Dabei haben sie aber den ganzen Ballast nicht. Sie müssen nicht auf ein GameObject und wollen dadurch auch nicht unbedingt in einer Szene sein (können aber). Dadurch kannst du z.B. welche erzeugen und in deine Assets packen. Es sind damit einfach nur Objekte, die im Editor erstellt und eingestellt werden können, und die genau wie Komponenten über Drag and Drop in den Inspektor gezogen werden können. Typisches Beispiel für ScriptableObject-Anwendung ist ein Inventar. Du hast eine ScriptableObject-Klasse "Item" und kannst davon beliebig viele in deine Assets erzeugen. Jedes Item hat einfach nur einen Namen, ein Bild, einen Geldwert, was auch immer du willst. Was es nicht hat, sind Referenzen oder Methoden die irgendwas mit GameObjects oder Nachbarkomponenten zu tun haben. Sie sind einfach nur da.

Letztenendes ist die häufigste Anwendung, sich damit eine Art Datenbank für statische Daten (wie "alle Items, die es im Spiel gibt" oder "eine Sammlung von KI-Verhaltensmustern") zu bauen.

Was ScriptableObjects dir nicht geben, sind irgendwelche Vorteile in Sachen Savegame. Das denken initial auch viele, aber ScriptableObjects besitzen null Funktionalität, um irgendetwas zu speichern, was der Spieler macht.

Aber wie gesagt, das wäre so meine Variante - ist nicht die einzig sinnvolle.

vor 35 Minuten schrieb Brighthell96:

Du bist gefühlt in jedem Beitrag anwesend und hilfst den Leuten das finde ich unglaublich

❤️

Link zu diesem Kommentar
Auf anderen Seiten teilen

Archiviert

Dieses Thema ist jetzt archiviert und für weitere Antworten gesperrt.

×
×
  • Neu erstellen...