Jump to content
Unity Insider Forum

kayy

Members
  • Content count

    69
  • Joined

  • Last visited

  • Days Won

    5

kayy last won the day on June 18 2014

kayy had the most liked content!

Community Reputation

21 Excellent

About kayy

  • Rank
    Advanced Member
  • Birthday November 17

Contact Methods

  • Website URL
    http://www.scio.de

Profile Information

  • Gender
    Male
  • Location
    Hockenheim
  • Interests
    Mein iPhone-Spiel RRRunner vermarkten; Auf StackOverflow.com im Unity-Tag posten

Recent Profile Visitors

3,347 profile views
  1. kayy

    Der Jammer-Thread

    So jetzt ich <jammer> Nach dem ich zig mal geflucht habe über das State- und Parameter-Handling im Animator, habe ich ein Open-Source-Projekt, aufgesetzt, dass den Kram deutlich besser macht, nennt sich Animator-Access-Generator (s.a. hier im Forum). Und daaann, wenn gerade so gut wie alle Features fertig sind, super geschmeidig laufen, die Doku glatt gezogen ist und überhaupt... daaaann also am gleichen Abend, Donnerstag den 26.06.2014 macht Unity bekannt, dass und baut genau die gleiche Idee in 5.0 ein. Hmh, irgendwie doch so bisschen für'n Eimer gewesen das ganze Open-Source-Gedöns. Jo, jetzt kann jeder mal kucken, wie ich so ein System designe, und dass ich zumindest nicht den letzen Mist zusammencode usw. ist schon gut für die Reputation und es gibt Watches, Stars und Follower auf GitHub und was weiß ich was noch. Aber am Ende bleibt die bittere Pille. Die, die vor allem deshalb so bitter ist, weil alles an ein und demselben Tag passiert ist. </jammer>
  2. Und noch ein Update, jetzt 0.8.2, die wichtigsten Änderungen: Events für alle möglichen Animator-State-Changes, z.B. State-Änderung in Layer X, ein bestimtes Event Enter, Exit, Stay, Active Events für Transitions, z.B. wenn irgendeine Transition zu einem State startet, ... Überladene Check-Methoden für States, nun kann man auch einfach anim.IsIdle () und IsIdle weiß in welchem Layer es ist Alle Infos zu States und Transitions zur Laufzeit, z.B. name, speed, ... bzw. name, duration, source, destination, ... Das Event-Handling eröffnet neue Möglichkeiten, seinen Code auf wesentlich elegantere Weise zu designen. if-Abfragen auf einen State kann man (wenn man will) komplett weglassen. Stattdessen registriert man einfach passende Event-Handler in OnEnable, Beispiele: void OnEnable () { anim.State (anim.stateIdIdle).OnActive += OnIdle; anim.TransitionTo (anim.stateIdJumping).OnStarted += OnStartedTransitionToJumping; } void OnIdle (StateInfo info, LayerStatus status) { // Aufruf in jedem FixedUpdate-Zyklus solange Player im Status "Idle" ist } void OnStartedTransitionToJumping (TransitionInfo info, LayerStatus status) { // Einmaliger Aufruf wenn Transition zum Status 'Jumping' gestartet wird } Vor allem bei komplexen Player-Objekten lässt sich mit dem Event-basierten Ansatz Lose Kopplung (o. Loose Coupling) viel leichter realisieren. Das heißt man kann die Funktionalität in einzelne Skripte delegieren ohne dass diese etwas voneinander wissen. Ein PlayerAnimationSoundController spielt z.B. einfach den Jumping-Clip wenn eine Transition zum Status Jump startet, weiß aber nichts von anderen Komponenten und diese auch nichts von ihm. Da ich ja mehr im Mobile-Bereich unterwegs bin, ist alles extrem auf Performance-Optimierung ausgelegt. Daher habe ich mich auch für C#-Events entschieden und nicht für Unitys SendMessage-Mechanismus. Es wird nur das gecheckt, wofür sich irgendein Skript registriert hat. Und wie geil das wirklich ist, kann man daran ablesen, dass Unity in seinem Blog angekündigt hat, in Version 5 ziemlich genau das auch anzubieten : Ewas anders, weil SendMessage-basiert. Etwas weniger bei den Transitions. Etwas mehr, weil Sub-State-Machines (geplant f. 0.9). Etwas besser, weil Animator-View-Anbindung. Etwas schlechter, weil immer noch das unselige Parameter-Gehampel nötig ist. Jo, Klasse, da muss ich später wohl noch mal in den Jammer-Thread
  3. Neue Version (0.7) ist draußen und unterstützt jetzt Events. Man registriert seinen Callback-Listener und dieser wird immer dann aufgerufen, wenn sich irgendein Animator-State geändert hat, Beispiel: void OnEnable () { anim.OnStateChange += OnStateChange; } void OnDisable () { anim.OnStateChange -= OnStateChange; } void OnStateChange (int layer, int newState, int previousState) { if (anim.IsJumping (newState)) { Debug.Log ("OnStateChange: Jump, previous state was " + anim.IdToName (previousState)); } } Es gibt jetzt auch ein Blog-Posting mit (en, 3:30) und ein 10-minütiges (en). Außerdem noch einen Thread (X-Posting) im Unity-Forum, aber da rollt man ja von Seite 1 bevor man den Submit-Button fertig gedrückt hat Der nächste Meilenstein beinhaltet dann, Events auf Transitions auszudehnen. Zu guter Letzt noch das Feedback von Prime31 auf Reddit, das mir runterlief wie Sahne
  4. So ich habe mal Malzbies Feedback umgesetzt. Je nach SystemInfo.operatingSystem wird nun ein spezielles Template an die Template-Engine verfüttert: Windows-Version mit CR/LF, falls der Rückgabewert mit "Win" anfängt, sonst UNIX mit LF. Somit sollten auch Änderungen im generierten Code, wie ich sie bei den Tricks zum effizienten Umgang mit Namensänderungen beschrieben habe, in MonoDevelop ohne Rückfrage nach Konvertierung gehen. Ich hoffe das tut jetzt ohne rumzunölen. Sieht jemand eine bessere Methode als den String-Compare, um die Betriebssytem-Familie zu bestimmen? Kurz noch zu meiner Motivation, überhaupt .md zu verwenden (ist das erste Mal abgesehen von stackoverflow.com): Der Hauptgrund ist die coole Darstellung auf github.com. Wenn ein README.md im Root-Directory gefunden wird, so wird dessen Inhalt automatisch auf der Einstiegsseite unterhalb des File-Listings mit allen Formatierungen dargestellt. Der Fallback ist also eig. schon eingebaut durch den Link auf das GitHub-Projekt (https://github.com/kayy/AnimatorAccess). Aber klar, wenn man erst mal lokal arbeitet ist das schnell vergessen, daher ist ein PDF eine gute Sache. Auch das habe ich in der aktuellen Version (s. Current) mit drin. Also Malzbie, deine Wunschliste ist 100%-ig durchgekommen
  5. Vielen Dank Das mit den Line-Endings hatte ich schon wieder vollkommen verdrängt. Warnings dürfen keine kommen, da bin ich sozusagen allergisch gegen. Ich habe schon ein paar Ideen und schaue es mir gleich mal an. **freu**
  6. Hi, ich möchte euch mein jüngstes Baby für die Werkzeug-Kiste vorstellen, den Animator Access Generator (ist Open-Source, MIT). Zusammengefasst geht es darum, die Hash-IDs für Animator-States und -Parameter automatisch aus der Animator-Komponente heraus als neue MonoBehaviour-Komponente zu generieren. Jeder der in Awake schon mal ein vermurkstes "BaseLayer" statt "Base Layer" o.ä. gefunden hat, weiß was ich meine Der Kick dabei: Für alle States und Parameter werden auch Methoden erzeugt, so dass man typsicher auf den Animator zugreift. Potenzielle Probleme werden schon zur Compile-Zeit erkannt. Hat man bisher z.B. einen den Int-Paramter Rotate so gesetzt: animator.SetInteger (rotateInt, newRotation); so kann man jetzt schreiben: animAcc.SetRotate (newRotation); Der Code-Generator checkt per Reflection den aktuellen Stand und berücksichtigt ihn bei der Generierung. Das heißt, wenn ich Rotate in RotateTo umbenenne, bleiben die alten Members für Rotate zunächst erhalten und werden nur als Obsolete markiert. Somit kann man einfach seine Änderungen nachziehen Es gibt einen Custom-Editor, für alle generierten Komponenten. Der zeigt an, was sich beim nächsten Update ändern wird: Interessiert? Dann schau dir das an. Auf GitHub gibt's einführende Doku mit ein paar Bildern und das zip-File zum Download Voraussetzung ist wohl Unity 4.3 oder höher. Auf dem Mac läuft es robust und fehlertolerant, habe aber keinen Zugriff mehr auf Linux oder Windows-Rechner. Auf Unity 4.5. habe ich leider auch noch nicht getestet. Über Feedback freue ich mich seeeeeehr
  7. kayy

    Internal Compiler Error

    GIbt's das Verzeichnis? Was hast du für Rechte darin, also kannst im Explorer dort eine Datei anlegen? Gibt's dort evtl. schon eine Datei Assembly-CSharp-firstpass.dll.mdb, die schreibgeschützt ist? Nächster Schritt: Demo-Projekt, geht's damit ein neues Skript zu erstellen? Du hast ja sicher schon Unity (bzw. Windows) neu gestartet ;-)
  8. kayy

    Singleton - The Easy Way!

    Hmmh, ich muss mal kurz trollen - Sorry Also in einem kleinen Projekt nutze ich gerne Singletons und ignoriere die ganze Kritik von wegen Anti-Pattern und so (s. [1][2][3][4][5][6]). Aber in einem sehr, sehr großen Projekt würde ich es anders designen, weil es echte Probleme geben kann. Vor allem die Reihenfolge der Initialisierung - muss nicht aber - kann zu Fehlern führen, die nur schwer zu fixen sind. Mock-Objekt-Instanziierung für Test-Fälle u.ä. wird auch eher komplexer. Da tendiere ich in diesem Fall (großes Projekt) eher zu einer zentralen Klasse, die die Instanzen kreiert und verwaltet. Ich würde auch für ein Singleton ungern den einen Schuss opfern, den man bei der Vererbung hat. Irgendwie kommt mir das nicht natürlich vor, dies als Is-A-relationship zu designen. Wenn ich z.B. von MonoBehaviour abgeleitete Objekte mit DontDestroyOnLoad habe, so sind diese meistens auch Singleton-artig unterwegs. In diesem Fall kann ich kein ": Singleton<MyClass>" angeben und somit habe ich doch 2 verschiedene Wege, mit Singletons zu arbeiten. Aber: Man kann das so sehen und beim Software-Design gibt es kein Richtig und Falsch (manchmal ist da sogar das sogenannte Richtige falsch oder das vermeintlich Falsche richtig
  9. Kommt drauf an wie sehr du unter deinen jetzigen Buttons leidest Ich würde bei der Entscheidung einfach paar Sachen gegeneinander abwägen: Willst du NGUI (3.x) kaufen f. 70€ oder die 2.7 free einsetzen? Nachteil der Free-Version, da kommen immer noch Warnings a la "is obsolete" und der Code entfernt sich im Zweifelsfall immer weiter. Wie ist die Lebenserwartung des Projektes, also wie viele Updates wird es noch geben? Planst du neue Projekte, in denen du es einsetzen könntest? Hast du Open-Source-Parts drin, wo du nicht einfach den NGUI-Source auf GitHub o.ä. einchecken kannst? NGUI ist glaube ich extrem weit verbreitet, ist also zunächst ein Vorteil, davon Ahnung zu haben. Falls uGUI qualitativ da herankommen sollte, wird es sich auf lange Sicht durchsetzen, und NGUI zurückdrängen, aber das wird noch dauern. Da Aren Mook lange dabei war, ist es nicht unwahrscheinlich, dass es eines Tages ein Migrations-Tool geben könnte Ich reiche hier noch das Untiy-Blog als Quelle nach wegen 4.6 und uGUI, da steht am Ende: Btw. if you were wondering, the new GUI system is getting really close and it’ll be included in Unity 4.6, which will also be the last major update in the Unity 4 cycle.
  10. Ich schließe mich Slayers Meinung an, NGUI ist wirklich sehr durchdacht. Für Unity 4.6 ist das neue Unity-GUI angekündigt, dessen Wurzeln wohl in NGUI liegen, da Aren Mook (der NGUI-Entwickler) bis Januar für Unity gearbeitet hat und uGUI als Branch von NGUI gestartet ist (s. hier). Das lässt mich hoffen, dass das eine oder andere Konzept in das neue GUI-System eingeflossen sind, sprich man näher dran ist an der Zukunft - wenn sie es nicht versauen
  11. kayy

    App build für iOS

    Im Prinzip vollkommen korrekt, aber doch nicht so ganz Es gibt natürlich die böse Welt der JBs und da kann man das bestimmt - habe es selbst nie ausprobiert, da Dev-Account.
  12. kayy

    MonoDevelop started nicht

    Es ist tatsächlich erstaunlich robust. Nach 4 1/2 Jahren läuft mein iMac noch flüssig. Etwas Maus-lastig aber das immerhin gut gemacht und damit nett bei der täglichen Arbeit. Aber ich will jetzt bloß kein Religionskrieg hier anzetteln, bin OS-Atheist Ob da ein Mac, KDE, Windows, zur Not auch Gnome rumsteht - was soll's, es gibt wichtigeres
  13. kayy

    MonoDevelop started nicht

    Auf 'nem Mac ist es zumindest nicht so. Die Verknüpfung ist eine dumme Weiterleitung auf das .app-File. Das .app-File wiederum ist so ähnlich wie ein zip-File oder tar-Archiv. Wenn man da mit dem Finder (so wie Explorer@Windows oder Dolphin@KDE) reinschaut, sieht das so aus: In der Info.plist steht drin welches Shell-Script zum Starten ausgeführt werden soll. In diesem Fall ist es monodevelop. Darin werden dann die Start-Parameter gesetzt, das Environment gecheckt und sonst alles, was an Vorbereitungen nötig ist, und am Ende wird dann das eigentliche Binary gestartet. Ist also soweit alles relativ transparent, finde ich, aber wohl auch Geschmackssache Jedenfalls wird beim Kopieren eines solchen .app-Files alles so gelassen wie es ist. Es kann nun sein, dass in dem Start-Script irgendetwas steht, was sich auf relative Pfade o.ä. bezieht. Sieht auf den 1. Blick nicht so aus, aber meine Scripting-Kenntnisse sind nur solide leider nicht Guru. Es ist schon denkbar, dass unter Umständen der User keine Berechtigung hat irgendein Temp-File anzulegen. Da würde ich erwarten, dass man irgendwelches Gemecker in der Konsole.app liest, aber wer weiß.
  14. kayy

    MonoDevelop started nicht

    Wie krass, darauf muss man auch erst mal kommen
  15. kayy

    MonoDevelop started nicht

    Unity starten, neues Unity-Projekt und dann noch mal versuchen. Wobei, komisch, dass das mit dem Löschen nicht funktioniert hat. Hört sich dann doch nach einem systematischen Problem an. Was hast du denn vorher gemacht? "Nix" - ich weiß, mache ich auch immer
×