Mark

"GetC" + <Tab> "<Light>();" -> "GetComponent<Light>();" Bringt kaum Mehrwert Was evtl sinnvoll wäre wäre ein system was das macht was du da schreibst und dafür sorgt dass Änderungen am Komponentenstatus wiedergespiegelt werden aka, wenn die Komponente nicht da ist, sie a) selbst erstellen oder erneut mit getComponent abfragen bis sie wie wieder da ist. Aber auch da hält sich der praktische Nutzen arg in Grenzen. Sowas wie private Light light = GetComponent<Light>(); wäre schon ne feine Sache, aber das verdammte this gibts da ja noch nicht private Light light = Components.GetComponent<Light>(self => self.light); Wäre wohl noch mit Expressiontrees möglich, aber ob das sinnvoll ist ist wieder eine andere Sache, aber es macht ein spannendes Lernprojekt Einfacher aber wieder mehr Schreibarbeit wäre sowas: private CachedComponent<Light> light = CachedComponent<Light>(); ... light.Value.enabled = true; ... ((Light)light).enabled = true;

Mich würde an Variante1 der Schreibaufwand für die Atribute und das nötige Reflection stören. An Variante 2 stört mich dann wiederum dass ich AutoGet auch gegen GetComponent austauschen könnte und dadurch sogar noch Lesbarkeit gewinnen würde, Von der Lesbarkeit gewinnt daher Punkt 1, benutzen würde ich dann aber eher Variante2 oder eben gleich GetComponent. Ich würde auch wenn ich mir so ein System zulege wünschen dass die Komponenten auf Wunsch erzeugt werden können und ich diese auch bei Bedarf automatisiert neu holen kann. Was dann wieder in Richtung von Variante1 führen würde.

So, Styles gehen nun: <Styles> <Button Name="StdButton" Text="{Binding TextValue}" Background.Color="Red" /> <Text Color="green" /> </Styles> Textelemente haben nun per Style immer eine grüne Farbe: <Text Text="{Binding Path=ToggleValueString}" /> Und Buttons mit dem StdButton Style haben immer einen roten Hintergrund und einen gebundenen Textwert: <Button Style="StdButton" Command="{Binding ClickCommand}"/> @Nax: Wie macht das Angular? Ich befürchte so nett wie es in JS per se möglich ist wird es in C# nicht, dafür fehlt AOP, daher gehts nur rel. schön über doofe Umwege.

Ich nutze es regelmäßig seit dem es VS2013 in der Community Edition gibt (ehrlich wieso nutzt man da unter Windows noch MonoDevelop?). Das Teil hat einige Macken, man bekommt zB recht oft eine "General Exception" aber einfach detachen und reattachen und es läuft wieder. Auch kann man den Ausführungspunkt nicht per Drag&Drop verschieben und das durchsteppen verhält sich auch leicht anders als zu normalen C# Projekten. Wer aber bis dato nur per Debug.Log und Debug.Break debuggt hat wird sich daran aber sicher nicht stören. Die Bugs in Zeitlupe betrachten zu können und einzelne Werte betrachten macht die Arbeit einfach nur angenehmer. Die Bedienung und Einrichtung ist auch Kinderleicht: Ich hab mir zuerst VS2013 Community gezogen. Dann nach der Installation in VS unter Tools->Extensions & Upgrades Unity VS saugen und installieren. In Unity sollte danach (evtl Unity neustarten) per Asset Import UnityVS verfügbar sein. VS beenden und in Unity unter Visual Studio Tools Generate Project Files auswählen. Dann Open In Visual Studio aus dem gleichen Menü aufrufen. Nun hat man sein Projekt und kann schon loslegen: Einfach auf Attach to Unity (grüner Pfeil) klicken. (man kann in dem Knopf noch was umstellen um den nächsten Punkt nicht machen zu müssen) In Unity Play drücken und man kann debuggen. Zum debuggen in VS die Stellen an denen man die Codeausführung pausieren möchte auswählen und F9 drücken (oder links neben dem Textbereich klicken) ein roter Punkt zeigt dann einen Breakpoint an. Dieser Breakpoint zeigt die Stelle an an denen pausier wird. Der Breakpoint bietet noch einiges nützliches an, so kann man zB Bedingungen festlegen ab wann der Breakpoint triggern soll (rechte Maustaste auf den Breakpoint und dann Condition..). Mit F10 geht man einen Schritt im Code weiter. Mit F11 kann man Unterfunktionen und auch Properties (wenn in den Einstellunegn von VS aktiviert) debuggen. Mit F5 führt man den Code normal weiter aus. Beim debuggen gibt es unte dem Codefenster diverse Watchfenster (Watch, Local und Auto) welche einen den aktuellen Zustand diverser variablen anzeigen. Im Watch Fenster selbst kann man eigene Variablen hinzufügen, damit diese überwacht werden. Diese Variablen beziehen sich immer auf den aktuellen debuggenden Codekontext. Auch kann man hier ganze Pfade angeben. Alpha.Beta.Foo geht zB auch geht sowas: Alpha.Beta.TuWasMitRückgabewert() Beim letzten bin ich mir nicht sicher ob UnityVS das unterstützt. Auch ist es evtl möglich den aktuellen Wert einer Variable die im Watchfenster angezeigt wird zu verändern, einfach mal versuchen ob man den Wert doppelklicken kann. Viel Spass beim Debuggen.

Ein weiterer Statusbericht und ein kleiner Rant.. -Slider sind nun implementiert. <Slider MinValue="0" MaxValue="0" Value="{Binding MySliderValue}"/> - Container Controls Clippen nun ihre Childelemente (diese werden nicht mehr über den Rand hinaus gerendert) - Layouting wurde nun implementiert: Left und Top können angegeben werden, per "Center" als Wert wird dafür gesorgt dass die Controls an der gewählten Achse zentriert werden. Width und Height sind ebenfalls einstellbar, ein Wert von "Stretch" sorgt wiederum dafür dasss die Controls so groß werden wie ihr Parent es zulässt. <Text Left="200" Top="Center" Height="300" Text="Blabla"/> Als nächstes stehen ScrollBalken und ScrollAreas für die Container Elemente an. Es geht damit quasi von den grundelementen weg zu den komplexeren/abstrakten Dingen. Das Layouting zum laufen zu bringen war echt pain in the ass, die API des neuen UI Systems ist leider nicht so durchdachte bzw hält sich nicht an das was so gang und gäbe wäre, auch Coordinaten verhalten sich nicht so wie man es sich wünschen würde. Eventuell ist das nur weil das System so ganz anders ist als bekannte Systeme und ich mich da erst eingewöhnen muss. Kommentare, Fragen, etc?

So Statusupdate: Es gibt nun Buttons mit dem im vorherigen Post beschriebenen Commands. Die Buttons können also deaktiviert werden wenn das Kommando nicht ausgeführt werden könnte. InputField Elemente sind fast fertig. Genauso wie Toggle Elemente, auch Toggle Elemente mit einer zugehörigen Group sind möglich. Die InputFields benötigen noch ein paar mehr Properties da ich da nur ca 50% des möglichen unterstütze, genauso die Text Elemente. Was auch noch fehlt sind genauere Einstellungsmöglichkeiten für das Layouting, bisher gehen zwar Positionsangaben aber das wars auch schon, Größen Einstellungen wie zB Width, MinWidth und MaxWidth fehlen noch gänzlich. So sieht aktuell meine Test XML aus: <Canvas> <List Direction="Vertical" X="10"> <List.Background Color="black"/> <Text Text="{Binding Path=ToggleValueString}" Color="green"/> <Text Text="{Binding Path=TextValue}" Color="#ff0000"/> <Text Text="Blue transparent text on white background" Color="#aa0000ff" Background.Color="white"/> <Toggle Checked="{Binding ToggleValue}"/> <Button Text="Click Me" Background.Color="Yellow" Command="{Binding Click}"/> <Toggle Background.Color="gray" Name="MyNamedToggle" Group="Alpha" Checked="true"/> <Toggle Background.Color="gray" Group="Alpha" /> <InputField Enabled="{Binding Element=MyNamedToggle Path=Checked}" Background.Color="white" Text="{Binding TextValue}" Placeholder.Text="Enter Text" Placeholder.Color="gray"> <InputField.Colors Pressed="red"/> </InputField> </List> </Canvas> Etwas komplex aber deckt so fast alles ab was interessant für mich beim testen ist. Dies ist mein aktuelles ViewModel dazu: [serializable] public class Model : INotifyPropertyChanged { private string textValue = ""; public string TextValue { get { return textValue; } set { if (textValue == value) return; textValue = value; if (PropertyChanged != null) PropertyChanged("TextValue"); } } private bool toggleValue = false; public bool ToggleValue { get { return toggleValue; } set { if (toggleValue == value) return; toggleValue = value; if (PropertyChanged != null) { PropertyChanged("ToggleValueString"); PropertyChanged("ToggleValue"); } } } public string ToggleValueString { get { return toggleValue ? "Toggle is On" : "Toggle is Off"; } } public readonly SimpleCommand Click = new SimpleCommand(parameter => { Debug.Log("Click"); }); public event PropertyChangedEventHandler PropertyChanged; }

So mal ein kleiner Statusreport: Ih hab viel an dem bisherigen refactored, so dass nun einige der Elemente wie zB Images wiederverwendbar innerhalb meines Codes sind. Damit geht nun auch dass ich jedem Element ein Hntergrund geben kann. <List Direction="Vertical"> <List.Background Color="gray"/> ... </List> <List Direction="Vertical" Background.Color="gray"> ... </List> <List Direction="Vertical" Background.Sprite="SomeSprite"> ... </List> Auch gibts nun diverse Converter die verwendet werden um String Werte die in der XML stehen in die tatsächlich gebrauchte Form zu bringen: <Text Text="Text" Color="green"/> <Text Text="Text" Color="#ff0000"/> <Text Text="Text" Color="#88ff0000"/> Das sind 2 Converter die verwendet werden, einmal einer der aus den Hex Farbwerten eine Color generiert und einmal einer der aus Well Known Colornames eine Color generiert. Das ganze ist recht leicht auf beliebige eigene typen erweiterbar, hier mal der Code für die Hex farben: class HexColorConverter : IConverter { public Type ResultType { get { return typeof(Color); } } public bool TryConvert(string value, out object result) { result = null; if (value.StartsWith("#")) { var colorCode = value.Replace("#", ""); if (colorCode.Length == 6) colorCode = "ff" + colorCode; var a = byte.Parse(colorCode.Substring(0, 2), NumberStyles.HexNumber); var r = byte.Parse(colorCode.Substring(2, 2), NumberStyles.HexNumber); var g = byte.Parse(colorCode.Substring(4, 2), NumberStyles.HexNumber); var b = byte.Parse(colorCode.Substring(6, 2), NumberStyles.HexNumber); result = (Color)(new Color32(r, g, b, a)); return true; } return false; } } Auf diese Art und weise kann ich in der XML zB leicht eine URI angeben welche auf eine Material verweist und der Converter könnte diese dann verwenden um das Material zu laden. Mein nächster Schritt wäre nun interaktive Komponenten zu realisieren, wie ein Button und ein editierbarer Text. Sollte nicht sonderlich schwer sein, nur ist die Frage wie ein Button seine Aktionen bekommt, ich hätte da momentan an 2 Möglichkeiten gedacht: Man bindet ein IKommando: public interface ICommand { bool CanExecute(object[] parameters); void Execute(object[] parameters); } oder man bindet direkt eine Methode. Vorteil der ICommand variante wäre dass hiermit der Enabled state des Buttons gesteuert werden könnte, wenn ein Kommando nicht ausgeführt werden kann dann wird der Button disabled ansonsten active. Edit: Hier mal ein Screenshot wie es momentan aussieht, aussehen in Unity, struktur der generierten GameObjekte und die verwendete XML:

Gut gut, ich schau mal bei Zeiten ob die Umstellung ein Gewinn und eine Erleichterung des ganzen wäre. @Damon93: Ich plane wenn dann sowas wie beim Unity Threading Helper. Das Teil gibts kostenlos und im AssetStore für einen Zehner.

XDocument gibts erst ab .Net4 Mono deckt in Unity momentan glaube nur 3.5 ab.

Irgendwelche Kommentare/Anregungen/Kritiken?

Hi, ich hatte vor einiger Zeit gefragt wie es mit DataBinding in der neuen UI von Unity aussieht. Da es bisher wohl schon ganz gute Lösungen gibt, ich aber diese aus diversen Gründen nicht verwenden konnte habe ich mich mal selbst daran versucht. Tolles Lernprojekt und so, auf jeden Fall habe ich nun schon etwas teils brauchbares geschaffen. Unity GML (Unity GUI Markup Language) Man kann seine UI einfach erstellen indem man ein View erzeugt und diesen mit einem Model verbindet. Das Model speist Daten in den View und der View kann Daten wieder zurück in das Model leiten. Das ganze sieht so aus dass man sich seinen View anhand einer XML Datei beschreiben und erzeugen lässt und diesem View ein Model zuweist. Konkret würde eine GML Datei (XML) so aussehen: <?xml version="1.0" encoding="utf-8"?> <Canvas> <Template Name="container1ItemTemplate"> <Text Text="{Binding Name}" /> </Template> <Items> <List ChildPadding="2" Direction="Vertical" DataContext="{Binding Path=Main OneWay}"> <Items> <Text Text="Howdi"/> <Text>Some long text, bla bla bla.</Text> <Text Name="id0" Text="{Binding Title}"/> <List Direction="Horizontal" ItemSource="{Binding Items}" Name="LastList"> <List.ItemTemplate> <Text Name="Sub" Text="{Binding Context=Parent Path=Title}"/> </List.ItemTemplate> </List> </Items> </List> </Items> </Canvas> Sieht recht komplex aus auf dem ersten Blick, aber es ist ja noch alles im Aufbau und kann sich ja noch ändern In dieser Datei sieht man auch gleich wie das DataBinding funktioniert. Jedes (variabel) Attribut kann gebunden werden per einfachem String: {Binding Pfad} Bindet "Pfad" an das Attribut {Binding Path=Pfad} Bindet "Pfad" an das Attribut {Binding Context=Self Path=Pfad} {Binding Context=Parent Path=Pfad} Bindet den "Pfad" ausgehend vom eigenen oder Parent Context an das Attribut. Self ist default wenn Context weggelassen wird. {Binding Element=Name Path=Pfad} Bindet den "Pfad" ausgehend vom Element mit dem Namen "Name" an das Attribut. Hierbei wird nicht das Model sondern ein View Element gebunden. {Binding Path=Pfad OneWay} {Binding Path=Pfad TwoWay} Bindet "Pfad" an das Attribut, entweder OneWay, was bedeutet dass der View das Model nicht verändert oder TwoWay, bei dem der View das Model verändern kann (TwoWay ist der default Wert falls weder TwoWay oder OneWay vorhanden sind) Wie sieht nun so ein Model aus? Im einfachsten Fall ist ein Model einfach nur eine Klasse mit einigen Fields oder Properties. Der Name dieser Member ist dann auch das was man beim Binding über den Path angibt. public class Simple { public string Foo = "Hallo"; } gebunden wird Foo einfach so; {Binding Foo} Auch tiefer gehende Pfade sind möglich: public class A { public B Bar = new Simple(); } {Binding Bar.Foo} Dieses Model hat aber den Nachteil das Änderungen am Model sich nicht im View wiederspiegeln können, man muss dem View also irgendwie bescheid sagen. Dies geht mit Modellen die das INotifyPropertyChanged interface implementieren: class Complex : INotifyPropertyChanged { public event PropertyChangedEventHandler PropertyChanged; protected void OnPropertyChanged(string propertyName) { if (PropertyChanged != null) PropertyChanged(propertyName); } private string foo = "Hallo"; public string Foo { get { return foo; } set { foo = value; OnPropertyChanged("Foo"); } } } .. var model = new Complex(); view.DataContext = model; model.Foo = "Welt"; Oder etwas anders, mithilfe der BindableValue<T> Klasse: class Complex { public readonly BindableValue<string> Foo = "Hallo" } .. var model = new Complex(); view.DataContext = model; model.Foo.Value = "Welt"; Welche Variante man nimmt bleibt natürlich jedem selbst überlassen. Aktuell geht nur wenig der Unity GUI, in nur 2 tagen alle Möglichkeiten zu unterstützen ist auch etwas zuviel verlangt. Aber es wächst und wächst. Bisher gehen folgende Elemente: Canvas List (Horizontale und vertikale Anordnung von Elementen) sowie Text Listen können ebenfalls per Model bestückt werden, indem man der List eine ItemSource gibt (IEnumerable), die List wird dann mithilfe eines Item Templates alle Items erzeugen, die dann wiederum mithilfe des DataBindings alles mögliche abbilden können. Ich habe das ganze in einem öffentlichen Bitbucket HG Repository abgelegt: https://bitbucket.or...rrrrk/unity-gml Direkter Link nur zum GML Part: https://bitbucket.or...GML/?at=default Nur falls jemand einen Blick riskieren möchte.

Howdi, danke fürs testen. Dass die Box leicht in den Boden eindringt um dann wieder empor gehoben zu werden liegt daran wie ich die Penetrationen zwischen den Collidern löse, dort ist die Tiefe für die Penetration noch etwas zu hoch und sollte entweder einstellbar sein oder 1 Pixel betragen. Dass manchmal Objekte wegfliegen habe ich auch schon beobachtet dachte aber ich hab das problem in Griff bekommen, sieht wohl doch nicht so aus. Allerdings ist die Art und Weise wie Kollisionen gelöst werden noch nicht korrekt. Wie du schon erkannt hast werden gleich beim auflösen einzelner Kollisionen Kräfte ausgewirkt. Ich sollte diese aber eher sammeln und erst am Ende der Auflösephase übernehmen. Dies dürfte schon einiges an Problemen beheben. Wenn ich Zeit finde werde ich mich dem Problem mal annehmen, als totaler Physik Anfänger (Computer) hab ich mich bei dem Feature etwas übernommen, anfangs war auch nur aller simpelste Abprallphysik geplant. Featurecreep und so

Danke

Hiho, ich bin mittlerweile soweit dass ich das Asset gern releasen möchte, aber es ist noch weitestgehend ungetestet so dass ich nun gerne einen Betatest starten möchte. Das ganze soll nicht unbelohnt bleiben, denn ich werde, wenn ich das Asset in den AssetStore stelle (wenn es denn soweit kommt), das ganze für ca 1 Woche hier kostenlos als Download anbieten. Es fehlen im Asset noch einige Basic Samples (mangel an Motivation und Grafiken), aber das bekannte Top Down Sample ist dabei. Auch ist die Dokumentation fast vollständig (es gibt noch einige Referenzen auf FXLab). Mit eurer Hilfe würde ich es gern zu Ende bringen. Ich bin ca 1 Woche im Urlaub und kann daher noch nicht umgehend auf alles antworten. Aber hier die nötigen Links: Dokumentation: https://dl.dropboxusercontent.com/u/2446365/Pix/Documentation/index.html Unitypackage: https://dl.dropboxusercontent.com/u/2446365/Pix/Pix.unitypackage Viel Spass, Mark

Die Grafik enthält Winmkelangaben auf der X Achse. Eventuell wäre eine textuelle Erklärung hier besser.

Hi Sandro, schön dich mal wieder zu sehen. Nur kurz aus Neugierde: Wuppertal? Dacht du wärst in Münster.

text = "Hallo"; anzeige = ""; aktuellePosition = 0; jede sekunde wenn aktuellePosition < text.Length: anzeige += text[aktuellePosition ++]; Um es jede Sekunde auszuführen schau dir Coroutinen an und insbesondere WaitForSeconds.

Gravitation? Rutscht er eventuell irgendwo runter. Dann gibts noch eine Physikkomponente die eine Statische Kraft auf das Rigidbody auswirkt. Ansonsten natürlich noch eigene Scripte die verantwortlich für die Bewegung sind. Ist deine Szene denn leer bis auf den Charakter? Liegen irgendwelche Scripte auf dem Char die besonders sind?

Sieht nett aus koffeinvampir. Darf ich fragen wie ihr es schafft komplett ohne Texturen auszukommen aber dennoch soviele Details zu zaubern? Vertexcolors?

Meine erste Beispiel Szene ist fertig, bis auf eventuelle kleine Details: WebPlayer: https://dl.dropboxusercontent.com/u/2446365/Pix/TopDown/TopDown.html YT Video:

Was schlechte (nicht böse gemeint) Tutorials anrichten sieht man an PHP und der daraus entstandenen Flut an SQL Injections. Ich will deine Euphorie sicher nicht bremsen, eher umleiten. Wenn du ein Tutorial machen willst, für Noobs, dann erhebe dich in einem Bereich über das Niveau von Noobs, lerne einen Aspekt von Unity richtig kennen und schreibe nur über diesen Aspekt ein Tutorial. Das ganze hat den Vorteil dass du erstmal diesen Aspekt gut kennen lernst, hast also einen guten Lerneffekt auf dich. Auch machst du so viele Fehler die du noch alle gut im Gedächtnis hast und kannst so speziell auf diese Anfängerfehler eingehen. Den Vorteil hast du als Anfänger den Erfahrenere nie wieder haben werden. Eventuell kannst du so noch dein gewünschtes Ziel erreichen.

FieldType wäre das was in FieldInfo auf den typen des Feldes verweist und bei MyEnum Bla; wäre der FieldType von Bla MyEnum. Aber das brauchst du von dem was ich an deinem Code sehe ja nicht. FieldInfo.SetValue benötigt ja keinen konkreten typ sondern nimmt alles als object entgegen. EditorGUILayout.EnumPopup dagegen nur ein Enum, der BasisTyp aller enums, auch den kannst du direkt casten ohne den konkreten Typ zu kennen: field.SetValue(item, EditorGUILayout.EnumPopup(field.Name, (Enum)field.GetValue(item)));