Jump to content
Unity Insider Forum

distagon33

Members
  • Content count

    7
  • Joined

  • Last visited

Community Reputation

0 Neutral

About distagon33

  • Rank
    Newbie
  1. distagon33

    C# Klasse oder Objekt? Verständnisproblem

    Pardon, ich meine natürlich nicht die Input-Klasse, sondern GameObject, wie in meinem ersten Post angegeben.
  2. distagon33

    C# Klasse oder Objekt? Verständnisproblem

    Danke, mit dem Hinweis auf statische Klassen ist auf einmal vieles klar. Was es mit statischen Elementen auf sich hat, war mir schon klar (von C++ her). aber ich bin einfach nicht drauf gekommen, dass die Input-Klasse etwas damit zu tun hat. Sorry. Was die Kritik an der Bezeichnung Property betrifft: Warum soll eine Klasse keine untergeordnete Klasse enthalten, in der wichtige Merkmale und Methoden festgelegt sind? In der Unity-Scripting-Referenz wird zur Input-Klasse unter der Rubrik "properties" u.a. "transform" aufgelistet. Mag sein, dass der Begriff nur in englischen Dokumentationen gebraucht wird. Ach ja, und Klugscheißer hin - Klugscheißer her, für mich sind nun mal Referenzen über Klassen und deren Strukturen die aussagekräftigsten Dokumentationen. Ich werden nun verstärkt auf das "static" achten.
  3. Hallo, Als Unity-Neuling bin ich dabei, die ersten Schritte im Scripting zu tun. Mir liegt viel daran, die Dinge nicht einfach nach Rezept anzuwenden, sondern zu durchschauen. Im Fall der Transform-Komponente ist das zum Beipiel klar und durchschaubar. Alle (oder die meisten) GameObjekte haben eine Transform-Klasse als Property eingebunden, die bei der Instantiierung des GameObjekts ebenfalls instantiiert wird, mit Zugriff über transform (klein geschrieben). So weit, so klar - hoffe ich. Was ist nicht durchschaue, ist zum Beispiel der Zugriff auf Input. Input ist in der Dokumentation als Klasse ausgewiesen und beschrieben. Der Zugriff erfolgt direkt über den Klassennamen, z.B. Input.GetKey (...). Wie geht das? Ich war der Meinung, dass man nur auf Instanzen zugreifen kann, und die werden in Unity verabredungsgemäß klein geschrieben. Bei Debug und wahrscheinlich vielen anderen Klassen dürfte es ähnlich sein. Vermutlich habe ich noch Verständnisprobleme mit C#. Kleiner Hinweis, um mir auf die Sprünge zu helfen?
  4. distagon33

    Eigenartiges Verhalten von MonoDevelop

    Gelöst. Es scheint wirklich ein Versionsproblem zu sein. Ich habe auf gut Glück mal Unity 5.3 versucht. Es funktioniert einwandfrei. Es kann aber auch an Windows 7 liegen. Vielleicht verlangt Unity die neuesten Windows-Updates, die aber lassen sich bei mir nicht installieren, weil nach Microsofts Meinung meine neue Handware nach einem neueren Windows verlangt. Kriegen sie aber nicht, Windows 10 wird erstmal wieder in die Ecke gestellt. Danke für eure Mühe. Ich werde mich bestimmt noch wieder melden, aber dann mit echten Unity-Fragen. Gruß distagon
  5. distagon33

    Eigenartiges Verhalten von MonoDevelop

    Klar, alles schon zigmal gemacht. Ständiges Hin- und Herschalten zwischen VS und Mono wird allmählich lästig. Aber ich habe nun festgestellt, dass der Mono-Editor auch an anderer Stelle hakt. Manchmal kommen bestimmte Tastatureingaben (z.B. Klammer) nicht rüber. Das bringt mich nun auf den Gedanken, dass Unity nicht sauber unter Windows 7 läuft. Ich hab's probehalber unter Windows 10 installiert (derselbe Rechner): keine Probleme. Bevor ich nun ungern auf Windows 10 umsteige, möchte ich noch mal anfragen, welche letzte Unity-Version sauber mit Mono unter Windows 7 läuft. Da müsste es doch Erfahrungswerte geben. Unity 5.6 funktioniert übrigens auch nicht mehr, schon probiert. Auf 4er Versionen möchte ich allerdings nicht zurückgehen.
  6. distagon33

    Eigenartiges Verhalten von MonoDevelop

    Nein, ich bin zwar oft etwas vorschnell, aber der Cursor steht auch nach einer Minute starr links oben. Sobald ich etwas anklicke, beginnt der Wartecursorl zu rotieren. Was mich irre macht: Es reicht schon, wenn ich mit Visual Studio ein paar Leerzeilen zwischen die Funktionsgerüste setze. Anschließend verträgt sich auch MonoDevelop mit dem Script. Ok, ich kann mir helfen, wenn ich alle benötigten Skripte anlegen, dann mit VS verlängere und anschließend mit Mono bearbeite. Aber sauber ist das nicht, vor allem so unerklärlich.
  7. Hallo, zunächst mal guten Morgen. Ich bin Neuling in punkto Unity und mache meine ersten Schritte im Scripting. Wenn ich ein neues Script anlege und MonoDevelop starte, rührt sich dort nichts. Der Minimalcode ist zu sehen, kann aber nicht bearbeitet werden. Cursor ist tot. Sobald ich etwas anklicke, beginnt etwas im Hintergrund zu rödeln und hört auch nach einer Stunde nicht auf. Keine Rückmeldung. Wenn ich auf Visual Studio umstelle, lässt sich das Skript problemlos bearbeiten. Jetzt kommt's: Das Skript, dass bereits mit etwas Inhalt gefüllt ist, lässt sich nun auch mit MonoDevelop weiter bearbeiten. Was genau im Skript enthalten sein muss, damit es unter MonoDevelop funktioniert, konnte ich noch nicht feststellen. Das ständige Umschalten ist auch zu mühsam. Bitte jetzt nicht mit dem Tipp ankommen, ich könnte ja Visual Studio benutzen. Mich stößt dieses überfettete, unübersichtliche Softwaremonstrum mit den vielen lästigen Helferlein einfach ab. Auch außerhalb von Unity habe ich mich nicht damit anfreunden können und stattdessen mit CodeBlocks gearbeitet. Ach so: Ich habe Unity 2017 Personal installiert, die neueste Version. Voreingestellt war Visual Studio. Gruß distagon
×