Jump to content
Unity Insider Forum
  • Announcements

    • Lars

      Allgemeine Forenregeln   03/13/2017

      Forenregeln Nimm dir bitte einen Moment um die nachfolgenden Regeln durchzulesen. Wenn du diese Regeln akzeptierst und die Registration fortsetzen willst, klick einfach auf den "Mit der Registrierung fortfahren"-Button. Um diese Registration abzubrechen, klick bitte einfach auf den "Zurück" Button deines Browsers. Wir garantieren nicht für die Richtigkeit, Vollständigkeit und Brauchbarkeit der Nachrichten und sind auch nicht dafür verantwortlich. Die Beiträge drücken die Meinung des Autors des Beitrags aus, nicht zwangsläufig das, wofür die Forensoftware steht. Jeder Nutzer, der denkt, dass ein veröffentlichter Beitrag unzulässig bzw. störend ist, ist aufgefordert uns unverzüglich per E-Mail zu kontaktieren. Wir haben das Recht störende Beiträge zu löschen und bemühen uns, das in einem realistischem Zeitraum zu erledigen (sofern wir beschlossen haben, dass die Löschung notwendig ist). Du akzeptierst, durchgehend während der Nutzung dieses Services, dass du dieses Forum nicht dazu missbrauchen wirst, Inhalte zu veröffentlichen, welche bewusst falsch und/oder verleumderisch, ungenau, beleidigend, vulgär, hasserfüllt, belästigend, obszön, sexuell belästigend, bedrohlich, die Privatsphäre einer Person verletzend oder in irgend einer Art und Weise das Gesetz verletzen. Des Weiteren akzeptierst du, dass du keine urheberrechtlich geschützte Inhalte ohne Erlaubnis des Besitzers in diesem Forum veröffentlichst. Mit dem Klick auf den "Mit der Registrierung fortfahren"-Button, akzeptierst du zudem unsere Datenschutzerklärung und stimmst der Speicherung deiner IP-Adresse und personenbezogenen Daten zu, die dafür benötigt werden, um dich im Falle einer rechtswidrigen Tat zurückverfolgen zu können bzw. permanent oder temporär aus dem Forum ausschließen zu können. Es besteht keine Pflicht zur Abgabe der Einwilligung, dies erfolgt alles auf freiwilliger Basis.   Zusatzinformationen Der Forenbetreiber hat das Recht, Nutzer ohne Angabe von Gründen permanent aus dem Forum auszuschließen. Des Weiteren hat er das Recht, Beiträge, Dateianhänge, Umfrage, Blogeinträge, Galleriebilder oder Signaturen ohne Angabe von Gründen zu entfernen. Mit der Registrierung verzichtest du auf alle Rechte an den von dir erstellten Inhalten, bzw. treten diese an das Unity-Insider.de und Unity-Community.de ab. Dies bedeutet im Klartext, dass das Unity-Insider.de und Unity-Community.de frei über deine Texte verfügen kann, sofern diese nicht wiederum die Rechte anderer verletzen. Es besteht weiterhin kein Anspruch von registrierten Nutzern bzw. ehemaligen registrierten Nutzern darauf, dass erstellte Inhalte und/oder die Mitgliedschaft (User) wieder gelöscht werden (Erhaltung der Konsistenz dieses Forums).   Einwilligungserklärung Wenn du mit der Speicherung deiner personenbezogenen Daten sowie den vorstehenden Regeln und Bestimmungen einverstanden bist, kannst du mit einem Klick auf den Mit der Registrierung fortfahren-Button unten fortfahren. Ansonsten drücke bitte Zurück. Stand: 07.03.2011

Antragon

Members
  • Content count

    9
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Antragon

  • Rank
    Newbie

Recent Profile Visitors

259 profile views
  1. Leveleditor mit Sprites und deren Priorität

    Wir sind ja bereits an dem Punkt mit den Spezialkonstellationen. Nur würde ich diese gerne vermeiden, denn je mehr Diversität es an Sprites im Editor gibt, desto komplizierter wird es. Ich hatte daher gehofft, eine allgemeine Lösung für alle möglichen Konstellationen zu finden (soll heißen, eine Formel, womit ich die sortingOrder immer passend festlegen kann). Am liebsten wäre mir eine Möglichkeit, die Render-Reihenfolge zwischen zwei genau Sprites festlegen zu können. Ähnlich wie Physics.IgnoreCollision(col1, col2) wäre eine Unity-interne Funktion "SpriteRenderer.PrioritizeSprite(sprite1, sprite2)" toll, womit festgelegt würde, dass sprite1 vor sprite2 liegt. Aber das ist wohl nur Wunschdenken. Dass man die Transparency Axis festlegen kann, wusste ich noch nicht. Das wird vermutlich noch nicht das Hauptproblem lösen, aber sicherlich einiges vereinfachen- danke also dafür!
  2. Leveleditor mit Sprites und deren Priorität

    @Zer0Cool: Genau das ist im Endeffekt mein Vorhaben. Aktuell lass ich die platzierten Sprites erkennen, welche Sachen drumherum liegen. Auf dieser Basis könnte dann der Wert sortingOrder im SpriteRenderer festgelegt werden. Nur hapert es genau an dieser Stelle. Hier mal der (sehr abgespeckte) Code: Vector2 gridSize=new Vector2(80, 80); Dictionary<Vector2,GameObject> gridTiles=new Dictionary<Vector2, GameObject>(); void Awake() { for(int y=0; y<=gridSize-1; y++) { for(int x=0; x<=gridSize-1; x++) { gridTiles.Add(new Vector2(x, y), null); } } } public void CreateTile(Vector2 gridPosition, Texture2D tex) { //Eine Einheit im Raster sind 80 pixel; Jeder Sprite hat weitere 80 Pixel als Überhang //Beispiel: eine 2x2-Kiste hat einen 160 Pixel breiten und 160 Pixel hohen Collider und 80 Pixel zusätzlich auf jeder Seite; die Textur ist also 320x320 Pixel groß Vector2 spriteSize=new Vector2(tex.width, tex.height); Vector2 spriteDimension=spriteSize/80-2; //Erstelle GO und schiebe an korrekte Position GameObject tile=new GameObject(tex.name); tile.transform.localPosition=gridPosition; //Die Funktion "GetAdjacentTiles" schaut im Dictionary gridTiles nach allen angrenzenden Objekten und gibt zurück: //- welches Objekt grenzt an (Key-Wert) //- von welcher Seite grenzt es an (Value-Wert, kann "L"[eft], "R"[ight], "U"[p], "D"[own] sein Dictionary<GameObject,string> adjacentTiles=GetAdjacentTiles(tile); int minPriority=-999; int maxPriority=999; foreach(KeyValuePair<GameObject,string> adjacentTile in adjacentTiles) { //Information über Render-Priorität/Sorting Order des benachbarten Sprites erhalten (ist immer im ersten Child); int priority=adjacentTile.Key.transform.GetChild(0).GetComponent<SpriteRenderer>().sortingOrder; if(adjacentTile.Value=="L" || adjacentTile=="D") minPriority=Mathf.Max(priority, minPriority); else if(adjacentTile.Value=="R" || adjacentTile.Value=="U") maxPriority=Mathf.Min(priority, maxPriority); } SpriteRenderer spriteR; //Erstelle für jedes Raster-Element, welches das Sprite belegt, ein eigenes GO und fülle gridTiles mit dieser Info for(int x=0; x<=spriteDimension.x-1; x++) { for(int y=0; y<=spriteDimension.y-1; y++) { GameObject box=new GameObject("Box", typeof(SpriteRenderer)); box.transform.parent=tile.transform; box.transform.localPosition=new Vector2(x, y); gridTiles[new Vector2(gridPosition.x+x, gridPosition.y+y)]=box; if(x==0 && y==0) { //Erstelle den Sprite für das Child-Objekt links unten spriteR=box.GetComponent<SpriteRenderer>(); spriteR.sprite=Sprite.Create(tex, new Rect(0, 0, spriteSize.x, spriteSize.y), new Vector2(80/spriteSize.x, 80/spriteSize.y), //Pivot 80); /* Hier ist das Problem: Es gilt einen Wert für Sorting Order zu finden, welcher: - größer als minPriority und - kleiner als maxPriority ist. spriteR.sortingOrder=????? */ } } } } Die Sorting Order muss halt so festgelegt werden, dass Sprites auch in komplexeren Strukturen wie zum Beispiel im folgenden Bild korrekt dargestellt werden - egal in welcher Reihenfolge Sprites platziert, gelöscht und/oder neu gesetzt werden. @Sascha: So einen ähnlichen Versuch gab es ja bereits; da habe ich beispielsweise 2x2-Kisten in vier einzelne Sprites aufgeteilt. Bei so einem Sprite ist die linke obere Ecke immer hinten und die rechte untere Ecke immer vorn. Allerdings wird beispielsweise die Ecke rechts oben von Objekten darüber verdeckt, während sie aber Objekte rechts daneben selbst verdeckt. Mal ne andere Frage in die Runde: Gibt es denn eine Möglichkeit, Unity direkt zu sagen, dass ein Sprite immer hinter oder vor einem anderen Sprite gerendert werden soll, ohne auf die sortingOrder/sortingLayer/z-Achse zurückzugreifen?
  3. Leveleditor mit Sprites und deren Priorität

    Bei mir wird das Bild unten am Post ganz groß dargestellt? Der verlinkte Thread ist an sich irrelevant, entschuldige bitte die Verwirrung. Hinsichtlich deines Vorschlags habe ich das Problem, dass es immer nur eine "wahre" Darstellung der Sprites gibt. Unten habe ich nochmal ein Bild mit den tatsächlich für das Spiel benutzten Sprites hinzugefügt: Jede Kiste ist ein eigener Sprite und die linke Kiste muss immer eine höhere Priorität haben als die rechte, unabhängig von der Platzierungsreihenfolge. Wenn man als Levelbauer dann aber noch anfangen muss >100 Sprites pro Level händisch zu sortieren, geht der Spaß schnell flöten.
  4. Hallöchen Leute, Ich arbeite zur Zeit an dem rasterbasiertem LevelEditor für Lucy Lamplight: Ein Aufhänger ist leider immer wieder die Priorität der Sprites beim Überlappen. Ich versuche mal die Bauteile anhand des angehängten Bilds zu erklären: - jeder Sprite besteht aus einem Box-Collider und einem Überhang - der Collider richtet sich nach dem Raster (es gibt zum Beispiel (BxH): 1x1, 2x1, 1x2 und 2x2 große Collider, aber nicht 1.3x0.5 o.ä.) - der Überhang ragt in die benachbarten Raster-Teile herein und kann eine Breite von 0-1 haben (aber nie größer als 1) Betrachtet man im angehängten Bild den roten Sprite, hat dieser einen 2x2-Collider und ein wenig Überhang auf jeder Seite. Wie ihr auch seht, wird der rote Sprite von grünen, zweifeldergroßen Sprites überlappt. Die Regeln für die Überlappung sollen sein: 1.) Ist die untere Kante von Sprite A auf der gleichen Horizontalen Ebene wie die obere Kante von Sprite B, so soll Sprite A eine höhere Priorität haben 2.) (Falls 1. nicht gilt) Ist die rechte Kante von Sprite A auf der gleichen Vertikalen Ebene wie die linke Kante von Sprite B, so soll Sprite A eine höhere Priorität haben Es gibt auch Ausnahmefälle, bei denen die zweite Regel für Sprite A umgekehrt wird. Im unteren Bild wäre der blaue Sprite eine solche Ausnahme. Fehlgeschlagene Versuche Die Grundidee ist recht einfach: Priorität=position.y - position.x (Bei der Position gehe ich immer von der linken unteren Ecke des Sprites aus.) Dass das ganze nicht klappt sieht man schon am Beispiel-Bild: Ausgehend davon, dass der rote Sprites beispielsweise eine Priorität von 0 hat, würde der grüne Sprite links unten eine Priorität von 1 haben (also darüber liegen), was nach obiger Regel falsch wäre. Dass das ganze für den blauen Sprite nicht funktioniert, liegt hoffentlich auf der Hand. Eine bessere Idee wäre folgende: Normale Sprites (rot, grün): Priorität=position.y*rastergröße.x - position.x + 1 Blaue Sprites: Priorität=position.y*rastergröße.x Dadurch hätten automatisch alle Sprites mit höher y-Position eine höhere Priorität als alle anderen. Dumm ist nur: Der rote Sprite hat eine niedrigere Position als der grüne Sprite rechts oben; da hier aber Regel 1 nicht greift, muss Regel 2 angewendet werden und er soll den grünen Sprite stattdesse überdecken. Es gab auch viele Versuche Sprites zu splitten, wobei jeder Teil-Sprite eine eigene Priorität bekommen hat. Ein 2x2-Sprite wurde beispielsweise in 4 Einzelsprites zerlegt. Ohne zu weit ausschweifen zu wollen: Nichts hat so richtig funktioniert. Der Lösungsansatz Daher möchte ich eine andere Herangehensweise versuchen: In der Theorie könnte man erst alle Sprites platzieren und ihnen dann händisch Prioritäten zuweisen, bis alles so passt, wie man es haben will. Ein ähnliches Verfahren möchte ich auch programmieren: Sobald ein Sprite platziert wird, werden die Sprites in der Umgebung gecheckt und dann allen beteiligten Sprites Prioritäten vergeben, bis alles passt. Die benachbarten Sprites zu erkennen, ist kein großes Problem. Problematisch wird es, zu identifizieren, welche Prioritäten ich ihnen zuweisen muss. Ich denke, es wäre am sinnvollsten, wenn man den Sprites beim Platzieren schonmal Grund-Prioritäten wie oben zuweist: Priorität=position.y - position.x Anschließend werden in Abhängigkeit von der Umgebung die Prioritäten erhöht oder gesenkt. Hierfür muss ein logischer Algorithmus her. Bevor ich mich jetzt aber dumm und dusselig probiere, wollte ich hier im Forum fragen, ob irgendjemand eine Idee oder einen Ansatz für sowas hat? Oder denke ich viel zu kompliziert und es gibt eine viel viel trivialere Lösung für das Ganze? Ich hoffe, ich konnte das Problem einigermaßen vermitteln und würde mich echt freuen, falls irgendwer hier eine rettende Idee parat hat!
  5. Charakterwechsel durch (De)Aktivierung von Scripts

    Aaah, endlich hat's Klick bei mir gemacht. Das eröffnet mir ja vollkommen neue Möglichkeiten! :-D Besten Dank euch beiden!
  6. Charakterwechsel durch (De)Aktivierung von Scripts

    Hi, ich weiß in etwa wie Vererbung funktioniert, allerdings glaube ich, ich kann dir nicht ganz folgen. Wenn ich einem Charakter sowohl PlayerControlBase als auch das spezifische Script (PlayerControlWarrior/PlayerControlMage) zuweise, aber nur PlayerControlBase aktiviere und deaktiviere, dann ändert das doch nichts an der Funktionalität der anderen Scripts?
  7. Hallöchen, Ich grüble derzeit an einem Problem hinsichtlich der Aktivierung und Deaktivierung von Script-Komponenten. Im Endeffekt versuche ich zwischen verschiedenen Charakteren auf Knopfdruck Hin- und Herzuwechseln; dabei soll immer nur einer vom Spieler gesteuert werden, während die anderen ihrer KI folgen. Pro Charakter gibt es jeweils ein Script für die Spielersteuerung und eines für die KI. Meine Idee: Übernimmt man die Kontrolle über einen Charakter, wird sein Steuerungsscript aktiviert und sein KI-Script deaktiviert. Problem an der ganzen Sache: Die Charaktere sind verschiedenen und brauchen dementsprechend verschiedene Scripts. Beispielsweise heißt das Steuerungsscript des Kriegers "PlayerControlWarrior" und das des Magiers "PlayerControlMage". Ich kann also nicht einfach sagen GetComponent<PlayerControl>().enabled=false. Mir fielen zwar ein paar Lösungen ein, das ganze über Umwege zu erreichen (Child-Object, welches die entsprechenden Scripte beinhält, das man dann aktvieren und deaktvieren kann; oder Referenzen auf die Scripte), allerdings finde diese Herangehensweisen eher unschön und habe das Gefühl, dass das doch einfacher gehen muss. Jetzt ist meine generelle Frage: Ist meine Herangehensweise falsch? Gibt es elegantere Lösungen für mein Problem?
  8. Suchfunktion defekt

    Ach, na dann frag ich ja genau zur richtigen Zeit. :-D Dann mal viel Erfolg dass morgen alles klappt!
  9. Suchfunktion defekt

    Halloechen, wenn ich die Suchfunktion hier nutze, krieg ich nur die Anzahl der Treffer angezeigt, aber nicht die Treffer an sich, siehe hier: Ist das ein Bug oder ein unheimlich unnuetzes Feature? Und wenn ersteres, kann mir jemand sagen, woran das liegen kann? Weiss nicht, ob das weiterhilft, aber wenn ich ein Thema starte, steht bei mir ganz oben im Header auch eine recht merkwuerdige Meldung, wie hier zu sehen: PS: Ich nutze Firefox, aber mit dem Internet Explorer krieg ich die gleichen Fehler.
×