Jump to content
Unity Insider Forum

malzbie

Moderators
  • Posts

    5,477
  • Joined

  • Last visited

  • Days Won

    413

Everything posted by malzbie

  1. Willkommen! Nachschlagewerke sind immer gut. Der Carsten Seifert war vor einigen Jahren auch hier im Forum unterwegs (zur Zeit von Unity 5). Viel Spaß bei uns.
  2. Also ich sehe da 2 Wege. Eintweder du gehst davon aus, dass alle Objekte zu Beginn in der obersten Ebene sind, oder sie sind zu Beginn in der untersten Ebene. Es ist ja eine Frage der Verortung. Also wie und wo können Sprites übereinander liegen. Geht es da nur um eine Art Inventory, dann ist es ja leicht zu wissen, welche Sprites an welcher Position liegen. Und wenn sie dann gestackt würden, dann müsste(n) das(die) Sprite(s) im Layer jeweils eins nach unten. Immer nur das Sprite im obersten Layer kann angeklickt werden. Das wäre einfach für den Test und ginge ohne Liste. Wird das oberste Sprite aufgehoben, dann müssten alle da drunterliegenden eine Ebene höher im Layer. Das wäre ein kleiner Befehl (event) für alle Sprites im entsprechenden Fach. Ist es aber irgendwie in einer Spielewelt, wo zufälligerwiese Sprites voreinander liegen würden, dann wird das schon schwieriger, denn jetzt musst du es irgenwie schaffen, diesen Haufen zu gruppieren. Da sehe ich klare Vorteile bei einer oder mehreren Listen, die immer dann da sind, wenn es zu Anhäufungen von Sprites kommt. Was ich aber noch wichtig fände, ist die Tatsache, dass man nicht unendlich viele SortingLayer anlegen muss. Man braucht vielleicht 3 für das Stacken. Das oberste Sprite soll natürlich immer oben gezeichnet sein. Das da drunter dann auch so, dass es optisch direkt unter dem Obersten liegt. Aber alle weiteren Sprites des Stacks können gemeinsam im untersten Layer liege. Ist vollkommen egal, wann welches gezeichnet wird. Nur musst du dann intern wieder eine Liste haben, die die richtige Reihenfolge für alle Sprites darstellt. Und dann ist es wirklich gut, wenn in der Liste das Oberste gelöscht würde und alle anderen nachrutschen. Die jetzt obersten 2 Sprites verschieben sich um einen Layer, fürs optische, und alle weiteren bleiben im untersten Layer. Der Test, welches Sprite denn anklickbar ist, ist ja ganz einfach über die Liste zu ermitteln.
  3. Das müsste eigentlich mit dem Spriterenderer zu machen sein. Der hat nämlich Sorting Layer. Die kann man im Code auslesen und auch setzen. Du musst also den aufnehmbaren Sprites sagen, dass sie in dem obersten Layer sind. Nur Sprites aus diesem Layer können aufgenommen werden. Der Layer ist ja bekannt und den kann man ja beim Versuch eines Drags abfragen. Jetzt musst du nur irgendwie hin kriegen, dass ein Sprite es merkt, dass ein anderes auf ihm drauf positioniert wurde und sich dann selbstständig in einen tieferen Layer schiebt. Genauso muss erkannt werden, dass ein Sprite von obendrauf jetzt weg ist und man selbst jetzt oben liegt.
  4. Da bieten sich die Trigger an. Du brauchst also einen oder mehrere Collider, die über der Wiese liegen. Denen gibst du einen Tag, z.B. Grass und stellst den/die Collider auf Trigger. Wenn dein Player da rein läuft, werden Triggerevents gestartet. Die kannst du im Code nutzen. Das OnTgriggerEnter() Event wäre dann dafür da, zu sagen, dass du ab jetzt auf dem Grass bist. Beim verlassen des Triggers, würde OnTriggerExit() aufgerufen werden, was dir sagt, dass du das Gras wieder verlassen hast. https://docs.unity3d.com/ScriptReference/Collider.html Schau beim Link und scroll runter zu den Messages. Da findest du alles Nötige.
  5. Ich verstehe nicht ganz was du da machst. Dieses Script soll die Coins zählen. Kann sie aber nur zählen, wenn es selber auf einem Coin drauf liegt, denn es wird ja schließlich getriggert und abgefragt, ob der Player berührt wurde. Ergo: Muss es auf dem Coin liegen, denn nur der kann den Player triggern. Sobald du aber den Player berührst, wird einmal Hallo ausgegeben. Die Variable coins wird um eins erhöht und danach wird ein GameObject mit dem Tag "coin" gesucht und dieses dann gefundene wird zerstört. Währenddessen wird der Text vom UI Element Münzenanzahl mit der Zahl, die in coins drinne steht, übergeben. Grundlagen zur Logik: Wenn du ein Script wie dieses erstellest, dann passiert erstmal nichts, wenn dieses Script auch nicht auf einem Gameobject in der Szene liegt. Es ist quasi eine Vorlage für etwas. Wenn du dieses Script aber einem Coin gibst, dann läuft der Code da drin auch ab. Aber! Dieses Script ist jetzt eine Instanz (grob gesagt eine Kopie) des original Scripts, welches immer noch in deinem Projekt Ordner liegt. Wenn du jetzt 2 Coins in der Szene hast und auch beide Coins dieses Script bekommen haben, dann agieren beide Scripts unabhängig voneinander. Wenn also ein Coin vom Player berührt wird, dann wird das Script, was auf diesem einen Coin liegt seinen coins Wert um 1 erhöhen. Das Script, welches auf dem anderen Coin liegt, macht gar nichts, denn es wurde ja nicht berührt. Das ist genauso, als wenn du 2 Computer hättest, die komplett gleich installiert sind. Wenn du bei dem einen Computer ins Internet gehst, ist der andere Computer ja auch nicht im Internet. Klar? So. Coin 1 wurde getroffen, erhöht seine coins von 0 auf 1 und "übergibt" diese 1 an das Textelement und zerstört sich vielleicht. (Zum vielleicht komme ich gleich) Wird danach ein anderer Coin getroffen, dann erhöht der andere Coin seine Variable von 0 auf 1 und übergibt wiederum eine 1 an das Textelement. Die beiden Scripts sind unabhängig voneinander und somit fängt jeder Coin von 0 an zu zählen. Du kannst also nur einen 1 sehen. Das ulkige ander Sache ist, dass dieses Script ja auf einem Gameobject liegt, welches ein Coin ist. Da es nur etwas macht, wenn der Player diesen Coin berührt, brauchst du nicht nach irgeneinem Coin in der Szene suchen und diesen dann zerstören. Nein. Es kann sich gleich selbst zerstören. Dafür gibt es das gameObject mit kleinem g. Also einfach Destroy(gameObject). Das eigene GameObject wird zerstört und alle Komponenten (auch dieses Script) mit ihm. Denn es kann keine Komponente alleine in einer Szene weiterleben. Die große Gefahr beim Suchen nach einem Objekt ist die, dass du nie weißt, welches GameObject mit einem gewissen Tag denn als erstes gefunden wurde. Das Erste was gefunden wurde, wird zerstört. Das muss noch nicht einmal das eigene GameObject sein. Keine Ahnung was da innerhalb von Unity abläuft, jedenfalls kann man nie sagen, welches Object zuerst gefunden wird. Nochmal zum verstehen. Das Objekt, welches die Coins zählen soll, kann nicht auf einem Coin liegen, weil dieser ja zerstört wird. Es muss also auf einem Objekt liegen, welches die ganze Zeit über am leben bleibt, bzw. nicht zerstört werden darf. Da es nicht der Coin sein kann , weil der der sich ja zerstört, könnte es der Player sein. Aber der könnte sich ja auch zerstören, wenn er alle Leben verloren hat, also sollte es ein Objekt sein, was immer da ist und mit dem Spielgeschehen nichts zu tun hat. z.B. die Camera. Diesem Objekt musst du etwas senden und dafür musst du wissen wie es heisst und wo es zu finden ist. Die MainCamera hat von hause aus einen Tag und deswegen kann man den gut nutzen. Camera.main. Also Münze hat eine Variable vom Typ des gesuchten Scriptes. So wie das Script fürs Münzenzählen eben heisst. In der Start() oder der Awake() sucht es nach der Camera und dessen Scriptkomponente (wie oben im Beispiel zu sehen) und verknüpft das mit der Variable. Jetzt kann an dieses Script gesendet werden, wenn eine Münze aufgenommen wurde. (Wieder so wie oben beschrieben) Das Script auf der Camera hat natürlich eine Variable, welche die Coins zählt, und immer wenn sich der Wert erhöht, würde es dem Textelement den neuen Wert übergeben. OK. Jetzt hast du was zu tun. Und sei so lieb und lass das ersteinmal mit den Playerprefs. Die nutzt man mal zu beginn eines Spiels und auch mal wenn gespeichert werden soll, aber nicht ständig. Habe ich auch oben erklärt.
  6. Uiii! Da muss ich mal schnell reingrätschen. Die Playerprefs sind nicht dafür da, dass du sie bei jedem möglichen Event beschreibst oder ausliest. Egal was man macht, aber man will nicht dauernd auf ein Speichermedium schreiben oder von ihm auslesen. Das ist das unperformanteste, was man machen kann! Wenn man Playerprefs nutzt, muss man außerdem bedenken, dass sie nur Werte "ablegen" oder "auslesen". Denen kann man nichts dazu addieren, so wie du das willst. Wenn du da +1 schreibst, dann bekommt der Schlüssel "münzenAnzahl" eine 1. Wenn du da -1 schreiben würdest wäre es die -1. Verstehst du? Immer wenn du PlayerPrefs mit SetInt ausführst, wird direkt ein Schlüssel in die Registry geschrieben und der bekommt dann einen int Wert. Es ist dem Playerprefs komplett egal, ob da vorher ein Schlüssel mit gleichem Name und evtl. schon Werten drin existiert hatte. Es wird einfach geschrieben. Alles ohne Nachfrage oder Warnung! Du brauchst also eine Variable, die fürs Münzenzählen da ist. Diese Variable kannst du so: coins=coins+1; oder in der Kurzform coins+=1; oder noch kürzer coins++; um 1 erhöhen. Wenn es dann später zum Abspeichern mit Playerprefs kommt, schreibst du PlayerPrefs.SetInt("münzenAnzahl", coins); Die Variable coins hat ja die Anzahl der Münzen gespeichert und diese Anzahl übergibst du damit. Jetzt ist wahrscheinlich deine Frage, wer denn die Coins verwaltet. Ich gehe ganz stark davon aus, dass du die Playerprefs als globale Möglichkeit dafür gesehen hast. Du musst jetzt für dich überdenken, wie es am Besten funktioniert. Momentan sind es die Münzen ja selber. Die müssen also irgendwas/irgendwem Bescheid geben, dass ein Coin dazu gekommen ist. Wenn jetzt z.B. dein Player die Coins zählen würde, könnte er es im selben Moment für sich tun, denn ein Triggerevent geht immer in beide Richtungen, oder aber die Münze sendet kurz was an das entsprechende Script des Players. Das es der Player ist, hast du ja schon abgefragt. Wenn der Player jetzt ein Script drauf hätte, welches z.B. MyCoins heisst, könnte sich der Coin schnell das Script verknüpfen und ihm dann in eine public Methode was senden oder gleich eine public Variable erhöhen. if (other.comparTag("Player")){ MyCoins TheCoinscript = other.GetComponent<MyCoins>(); if(myCoins!=null){ TheCoinscript.AddACoin(); // eine public Methode im Script // oder TheCoin.coins ++; // coins wäre eine public Variable im Script. } } Eine weitere Möglichkeit wäre das Beschreiben einer static Variable. Dabei gibt es aber wichtige Dinge, die man beachten muss. Und da weiss ich nicht, ob du dafür schon bereit bist. Versuch einfach mal einen Weg für dich zu finden, wer denn jetzt die Münzen zählen soll und wer dazu anregt. Wann das passieren soll ist ja klar; Wenn der Player eine Münze berührt hat. Der Player kann das tun wenn er den Tag Coin berührt hat und die Münze kann das tun wenn sie den Tag Player berührt hat. Beides passiert zur selben Zeit. Wo jetzt aber die Variable zum Hochzählen liegt, musst du selbst entscheiden. Die könnte der Player haben und die könnte irgendein Objekt in der Szene haben, z.B. die Camera, die ja immer da ist, oder die UI, die es ja sowieso anzeigen soll, oder sogar ein extra Werte-Objekt, was selbst beim Szenenwechsel nicht zerstört wird. Wegen deiner Frage wegen den Neulingen: Es sind nicht soo viele, aber jede Woche kommen neue hinzu. Schau einfach öfter mal hier rein und wenn du eine unbeantwortete Frage siehst, die du beantworten kannst, dann los!
  7. Also: Ich würde dir empfehlen, nicht die Kapseln direkt zu animieren, sondern sie jeweils in ein Empty-Object rein zu tun. Dieses Empty animierst du dann für die Bewegungen! Jede Empty, also jede Kapsel bekommt einen eigenen Animator mit allen Animationen da drin verpasst. Nicht eine Animationsspur fürs steuern zweier unabhängige Objekte nutzen. Ds bedeutet aber nicht, dass du nicht auch Animationen für mehrere Objekte nutzen kannst. Du kannst schon Animationen erstellen, die in allen Animatoren genutzt werden können. Wie z.B. der Einflug der linken und rechten Kapsel. Die beginnt ja irgenwo unten und geht bis zu einer gewissen Höhe im Screen. In der Animation animierst du dann also nur die Y Achse. Wenn jetzt also das Einflugevent in beiden Animatoren gestartet wird, z.B. per Trigger, dann fliegen beide Kapseln in den Screen hinein. Egal wo sie sich auf der X Achse befinden, du animierst ja nur Y. Da du indeinem Fall aber auch irgendwann die andere Achse animieren willst, würde ich das dann doch nicht so machen, sondern wirklich separate Animationen erstellen und auch keys für alle Achsen erstellen.. Wie dem Auch sei. Das Empty wird animiert, die Kapsel selber wird nur mitgenommen. Sollte jetzt eine der Kapseln zerstört werden, dekativierst du einfach die Kapsel und schon ist sie nicht mehr sichtbar und treffbar. Wärend des Deaktivierens, blendest du an selber Stelle ne schöne Explosion ein. Das EmptyObject ist noch da, und kann machen was es will, man sieht es eh nicht.
  8. Genau heute vor 5 Jahren habe ich meine Pinball Collection auf STEAM veröffentlicht! Hui! Junge, war ich damals aufgeregt! 😬 3 Flipper waren fertig, 10 sollten es werden. Ich hatte mich dazu entschlossen, einen Flipper kostenlos und alle weiteren Flipper als DLC anzubieten. Alle DLC-Flipper, die fertig waren, konnte man bis zu einen definierten Score testweise spielen. ( Und kann man heute immer noch) Mit diesem Modell konnte ich schon etwas veröffentlichen, bevor ich die Collection fertig hatte. Das war eigentlich gar nicht so schlecht, weil die Spieler alles vorher testen konnten und dann, wenn's gefallen hat, auch gekauft haben. Es gab und gibt aber einen großen Nachteil bei der Sache. Bei STEAM gibt es nämlich tausende Leute, die sich alle kostenlosen Games holen, um dadurch im Steam-Level anzusteigen. Diese Leute spielen dann auch mal gewisse Spiele an und sehen sich dazu berufen eine Bewertung abzugeben. Wenn denen das Spielprinzip nicht gefallen hat, weil eigentlich gar nicht wissen was ein Flipper ist, gibt's schon mal nach 5 Minuten Spielzeit einen Daumen nach unten. Es gibt sogar einen Daumen nach unten, weil die anderen Flipper nicht auch umsonst sind. Ja, so sind die Leute drauf. Ich musste lernen damit zu leben. Heute würde ich das so nicht mehr machen. Heute würde ich eine Demo erstellen. 2 Jahre habe ich gebraucht, um die Collection zu vervollständigen. Also wurde so ungefähr alle 3 Monate ein weiterer Flipper veröffentlicht. Von daher war das DLC-Modell super. Außerdem habe ich in dieser Zeit echt viel gelernt: Z.B. welche Fehler solle man unbedingt vermeiden oder was wollen die Leute unbedingt haben. Ich hätte nach den 2 Jahren das Dingen einfach laufen lassen können. Aber das hab ich nicht. Ich habe darauf geachtet was der Steam commuinty am Herzen liegt und dann immer mal wieder Updates raus gebracht. Aber einer Sache habe ich mich verweigert. VR ! 3 oder 4 Leute hätten nämlich gerne in VR gespielt. Das war's mir aber nicht wert. Es war eine spannende Zeit und deswegen werden die 5 Jahre auch gefeiert. Diese Woche sind alle Tische um 50% reduziert. Also für rund 3,50€ kriegt ihr die ganze Collection. https://store.steampowered.com/app/729580/Malzbies_Pinball_Collection/ Das wollte ich mal los werden.
  9. Bei 3D Objekten, die in einem 3D Programm, wie z.B. Blender erstellt wurden, kommt die Position des Achsennullpunktes von dem Ersteller selbst. Den kann man in Blender usw. hinschieben wo man will und man kann ihn natürlich auch drehen und somit bestimmen was oben und was vorne ist. Bei den Grundobjekten von Unity ist das nicht so, da ist das Dingen wo es ist. Was du aber machen kannst: Erzeuge ein EmptyObject und ordne den Grundkörper diesem Empty unter. Die Transformwerte, die du jetzt bei dem Grundkörper siehst, sind Werte im Bezug auf den Vater. Schreibst du bei der Position 0,0,0, dann ist das Grundobjekt genau am Punkt des Empty. Du kannst jetzt also das Grundobjekt, also das Kind des Empty so verschieben, dass der Nullpunkt des Empty z.B. am unteren Rand des Kindes ist. Gibts du jetzt nicht dem Grundobjekt einen Collider und Rigidbody, sondern dem Vater, also dem Empty, dann ist der Vater das entscheidende, wenn es um Kollisionen und Kräfte geht. Das KindObjekt ist nur fürs aussehen da. Übrigens, du kannst im Szeneview oben in der Leiste einstellen, welchen Nullpunkt du sehen willst. Entweder den Zentrierten, oder den Wirklichen. (Global oder Local). Um den echten Nullpunkt zu sehen (Bei importierten Objekten, wie oben beschrieben) musst du auf Local gehen. Bei den Grundkörpern und einem EmptyObject ist sind beide Punkte natürlich identisch.
  10. Das kann ich dir nicht sagen. Du wirst wohl irgendwann etwas geändert haben. So wie der Code jetzt ist, kann Jump niemals funktioniert haben. Links-rechts schon. Aber vielleicht hast du da andere Werte genutzt. Keine Ahnung.
  11. Also ganz wichtig ist ja, dass du Forces in der FixedUpdate ausführst. Es würde auch in der Update gehen, aber da die Update einen anderen Zyklus hat (Frameabhängig ist) wirst du je nach Rechner mal mehr und mal weniger bewegt werden. Aber das Wichtigste daran ist, dass Collisionen und Triggerevents auch in dem FixedUpdate Zyklus ablaufen. Und wenn die Force und die Kollision nicht synchron berechnet werden, kann es sein, dass du durch Dinge durchfällst oder durch Wände durchflutscht, wenn du dich zu schnell bewegst. Außerdem wirken die anderen Parameter des RB's auch in der FixedUpdate. Der Drag (Der bremsende Widerstandwert) und die Schwerkraft. Aber jetzt zu deinem Problem selbst. Es ist höchstwahrscheinlich kein Problem vom Input, sondern von den Kräften die du wirken lassen willst. Ich empfehle dir, eine Sache nach der anderen zu testen. Dann lernst du nämlich wie das Ganze funktioniert. Die Velocity ist die Geschwindigkeit des RB's. Ich glaube man kann es gleichsetzen mit Meter/Sekunde. Bin mir da aber nicht sicher. Du setzt in jedem Frame die horizontale Geschwindigkeit. Was maximal 4 sein kann. Denn der Raw- Inputwert ist entweder -1 oder 0 oder 1. Das multipliziert mit dem Speed ergibt -4, 0 oder 4. Diesen Wert übergibst du der horizontal Variable. Hast du bist jetzt noch nie den Jump Button gedrückt, dann ist der Verikalwert ca 0 wenn du irgendwo drauf stehst. Wenn wir jetzt davon ausgehen, dass du die ganze Zeit nach rechts lenkst, dann hat die movement Variable den Wert (4, irgendwas um die 0). Als nächstes fragst du den Jump-Button ab und wenn er gedrückt wird, dann setzt du die Velocity des RB's. Und zwar nimmst du da nicht den Horizontalwert und gibst im für Y den Sprungwert dazu, sondern du nimmst jetzt für die X Achse die Velocity des RB's er er jetzt gerade hat. Das kann irgendwas zwischen 4 und -4 sein. Ist aber nicht die 4, die du eigentlich haben solltest, weil du ja weiterhin rechts lenkst. So, dein RB hat jetzt eine Velocity von (irgendwas, 8 ) bekommen. Jetzt, setzt du aber nocheinmal die Velocity vom RB und dafür nimmst du die movement Variable. Diese Variable hat die Werte ( 4, 0). Somit überschreibst du die 8 für die Y Achse, die der RB genau davor noch bekommen hatte, mit der 0. Deswegen springst du nicht. Dass du dich nicht seitlich bewegen kannst, könnte daran liegen, dass der Wert einfach zu gering ist, oder der Dragwert zu hoch oder die Friction des Colliders zu hoch ist. Also: movement Variable zuerst mit der Velocity des RB's füllen. movement = rigidbody.velocity; InputWert willst du ja immer übergeben, also machste das so: movement.x= (Input.GetAxisRaw("Horizontal)*Speed; dann abfragen ob Button gedrückt und nur dann einen Wert in Movement rein tun. if(Input.GetButtonDown("Jump"){ movement.y=JumpPower; } jetzt erst die Werte dem RB übergeben. rigidbody.velocity=movement; Wird der Jump Button nicht gedrückt, dann bekommt der RB seinen alten unveränderten Wert zurück. Wird er aber gedrückt, dann bekommt er die 8. Probierst aus und nimm ruhig mal höhere Werte für die Bewegung und den Jump.
  12. Also ich frage mich ja, wieso in einem Kurs Aufgaben gestellt werden, wenn vorher nicht das Nötige vermittelt wurde. Ich kann mir nicht vorstellen dass ein Kurs so aufgebaut ist, dass die Teilnehmer "irgendetwas" machen sollen und sich dafür auch "irgendwo" die Techniken aneignen sollen.
  13. Jedes GameObject hat eine Transform-Komponente dabei. Die ist immer ganz oben im Inspector zu sehen. Da wirst du Position, Rotation und Scale finden. Alle 3 Bereiche haben 3 Felder, die du verändern kannst. X,Y und Z. Spiel mal damit rum, du wirst sehen dass es dein GameObject in Lage, Ausrichtung und skalierter Größe verändert. Der Scale.Bereich hat da noch ein Kettenglied-Symbol links vor den Feldern. Damit schaltest du ein/aus, ob du alle Werte gleichmäßig oder separat ändern willst.
  14. Gut! Aber für die Abrissbirne musst du was anderes nehmen. Das sprengt die Epoche.
  15. Ja, die hast du möglicherweise übersehen. Die gegnerischen Gebäude werfen Fuel und Repair Items ab. Natürlich nicht alle, aber wenn du Gegner zerstörst, solltest du immer ein Auge darauf haben. Genauso funktioniert das mit den Upgrades. Die machen aber, sobald sie erscheinen, einen klingelnden Ton, den man nicht überhören kann. Wenn eine Mission vorbei ist, wird der Flieger gewartet und bekommt auch eine gewisse Menge an Hitpoits zurück. Wenn du aber mit dem Doppeldecker in der vorigen Mission kurz vorm sterben warst, dann hast du bei der nächsten Mission mit dem Doppeldecker nicht alle Hitpoints zurück. Das ist das Konzept des Spiels. Stirbst du, dann ist dein Flieger natürlich wieder komplett heile. Die Länge/Größe eines Sektors ist gar nicht so entschedend. Es ist die Herangehensweise an die Gegner. Die Geschütze, die du bis jetzt kennen gelernt hast, sind berechenbar und den Geschossen kann man leicht ausweichen. Wenn die Missionsbeschreibung z.B. sagt, dass du dich nur um die Geschütze kümmern sollst, dann solltest du das auch tun, denn wenn du versuchst alle Gegner zu eliminieren, dann dauert das recht lange und du verbrauchst viel Sprit. Außerdem, wirst du wahrscheinlich öfter von den Geschützen getroffen, weil du sie nicht im Fokus hast. Ja, das Spiel ist schon herausfordernd, weil man nicht einfach drauf los fliegen kann. Man muss die Gegner kennen und vorallem sein Flugzeug fliegen lernen. Dafür hast du aber unbegrenzt leben.
  16. Das erste Spiel mit Bringservice! Das ist mal was Anderes.
  17. Danke für's testen @grinseengel. Mit einem Gamepad lässt sich das doch leichter spielen, stimmts? Die Flugzeuge werden von der Schwerkraft nach unten gezogen, sobald sie den Auftrieb verlieren. Wenn du beim Sinkflug zusätzlich noch Gas gibst, dann geht das natürlich noch schneller. Um dann wieder Auftrieb zu gewinnen, dauert es dann einen kleinen Moment und dann crashed man gerne mal. Um Ziele am Boden zu beschießen ist es am Besten, wenn du drauf los fliegst und dann vor der Drehung nach unten vom Gas gehst. Jetzt schnell eine Salve schießen und wieder gerade drehen. Erst dann wieder Gas geben. Die Flieger gleiten nämlich ein gewisses Stück, bevor die Schwerkraft einsetzt. Du wirst das sehr schnell selber heraus finden. Die Demo hat 12 Missionen und geht bis zum ersten Boss.
  18. Nee. Noch nie gesehen! Was ist das überhaupt für ein Buildfenster?
  19. Dann muss es mit deinen Änderungen zu tun haben. Irgend etwas ist ja jetzt anders. Ich habe vor 10 Jahren mal was für IOS gemacht und XCode, sowie das ganze Prozedere von Apple, hassen gelernt. Ich bin leider raus. Ich habe eben mal gegoogelt und zu deinen beiden Fehlern leider nichts gefunden. Aber Undefined Errors gibt es Seitenweise bei google. Da gibt es für fast alles einen Fehler und jeder muss danach suchen! XCode ist schon 'ne Wucht! Wie dem auch sei. Du musst erst einmal schauen, ob du nicht einen Fehler im Programm hast, den du auch in unity siehst. Sollte da irgend eine Meldung im Log sein, dann bereinige es. Ganz wichtig! Wo der PC oder andere Architekturen ohne Weiteres weiter laufen, schmiert dir IOS sofort ab. Und XCode, wie du ja siehst, meckert schon bei ganz anderen Dingen rum. XCode macht auch komische Dinge, wenn da irgend etwas mit den Versionen nicht stimmt. Ich glaube XCode cached auch gewisse Dinge, die beim weiteren, veränderten Build, zu Problemen führen können. Wenn du da irgendwas siehst, dann lösche es, damit XCode ganz frisch builden kann. Aber wie gesagt: Bei mir ist das viel zu lange her und ich werde es auch nicht mehr anfassen. Da kann das Gummi vom Handschuh noch so dick sein!
  20. @Jog An sich ist das gut, aber das geht nur, wenn das Script und die Textkomponente auch auf dem selben Objekt liegen. Das muss ja nicht so sein. Und wenn es auf dem selben Objekt liegt, kann man sie auch gleich, wie in deinem Beispiel, per Script hinzufügen und braucht eigentlich keine Public Variable mehr. Deswegen würde ich da stattdessen einfach eine Meldung raus geben, bei der man klar erkennt, dass man selber einen Fehler gemacht hat. Dann wäre auch klar (falls beim Start keine Meldung kommt), dass ein späterer Fehler auf das Löschen dieser bekannten Komponente zurück zuführen ist.
  21. Deine Fehlermeldung (rot) sagt es dir eigentlich. NullReferenzException bedeutet: Da sollte eine Referenz zu etwas sein, ist es aber nicht! Die Variable, die das Etwas haben sollte ist null. Also leer. Und wo das im Script das erste Mal auffällt, ist die Zeile 28 in deinem Script. Ich gehe ganz stark davon aus, dass die Variable levelCounterText kein Text-Element bekommen hat. Das siehst du ja sofort, wenn du dir im Inspector mal die Variable anschaust. Die Warnmeldung (gelb) hat mit dem Fehler nichts zu tun, sollte aber auch beachtet werden. Diese Warnmeldung sagt dir, dass du 2 Eventsysteme in der Szene hast, aber nur eines da sein sollte. Das könnte, muss aber nicht, zu Problemen führen, denn was ist wenn mal das eine und mal das andere Eventsystem genutzt wird?
  22. Kann es sein, dass du in deinem Projekt irgendwelche Sonderzeichen oder Umlaute nutzt, die nicht UTF8-konform sind? Also bei Variablennamen, Klassen/Scriptnamen oder Objektnamen. Ist halt Apple-Scheiße! Glaub mal nicht, dass die mit erweiterten Zeichensätzen richtig umgehen können.
  23. Ah, ich sehe es. Du versuchst die Animation vom Entry aus zu starten, was aber nicht geht. Vom Entry, also sobald der Animator erwacht, geht es über die default Transition (orange) in deinen NewState. Von da aus gibt es aber keinen Weg heraus. Du kannst jetzt entweder eine Transition , von NewState zu deiner FadeOut Anim erstellen, oder aber du nutzt AnyState als Anker für deine Animation. AnyState bedeutet, dass dem Animator egal ist welcher State gerade am laufen ist, er wird immer in einen verbundenen anderen State gehen können. Auf jeden Fall ist die Transition von Entry zu FadeOut nutzlos und kann weg.
×
×
  • Create New...