Jump to content
Unity Insider Forum

malzbie

Moderators
  • Posts

    5,296
  • Joined

  • Last visited

  • Days Won

    385

Everything posted by malzbie

  1. Ja, eigentlich könnten wir echt mal wieder ein kleines Event/Battle machen. Aber irgendwie ist das Gefüge nicht mehr so wie damals. Es gibt inzwischen viel zu viele Media-Plätze und die Energie teilt sich unheimlich weit auf, sodass ein Event wohl nicht mehr viele Leute ansprechen würde.
  2. Du brauchst eine Variable, die mit dem Script verknüpft wird, welches die Variable drin hat. private WerteScript DasWerteScript; Das GameObjekt anhand irgendeiner Info suchen und finden. (Aber nicht ständig machen, weil das suchen kostet viel Performance). Dann das angehangene Script einer Variable hinzufügen, die als Typ den gleichen Namen wie das Script, bzw. die Klasse hat, wo die Variable drin ist. void SucheEs(){ GameObject NeuesObject = GameObject.FindWithTag("WieAuchImmer"); // GameObject über den Tag suchen und mit Variable NeuesObject verknüpfen DasWerteScript = NeuesObject.GetComponent<WerteScript>(); // nun die Scriptkomponente mit DasWerteScript verknüpfen } Jet kann der Wert überall in deinem Script abgefragt werden, was natürlich nur geht wenn die Variable im anderen Script auch public ist. derZustand = DasWerteScript.dieBoolscheVariable;
  3. Ja, das sieht bei dir so aus. Wieso kommt denn bei dir dieses NVidia Info-overlay? Bei mir kommt das nicht. [Edit: ich habe gesehen, dass dieses NVidia Overlay in den Expirience Einstellungen unter Allgemein deaktiviert werden kann. Mach das mal bitte und versuche es nocheinmal.] Dieses Intro ist das ganz normale Unity-Intro, wo man eigene Grafiken verwenden kann und der FreeUser immer das Unitylogo sieht. Das ist also kein Problem, was ich lösen könnte, es sei denn es gibt da wirklich einen Bug in der Version, die ich nutze. Da muss ich mal recherchieren. Danke für die Info.
  4. Also ein Trigger ändert nichts an irgendwelchen physikalischen Dingen, außer du machst im Code etwas! So wie du das beschreibst, muss im Code etwas passieren wenn du in den Tigger rein kommst und auch wenn du ihn wieder verlässt. Oder es doch kein Trigger.
  5. Ja dann habe ich keine Ahnung, was da passiert ist. Ich kann dir garnicht sagen wieviele 1000 Mal ich die Taste inzwischen gedrückt habe und IMMER hat's funktioniert. Ja, keine Ahnung. Das muss ein Glitsch gewesen sein. Versuchs einfach nochmal, wird klappen.
  6. Das ist aber nicht schön. Es sollte jedes Eingabegerät funktionieren. Also die Maus, die Tastatur und, falls du hast, auch das GamePad. Ich nutze das neue Inputsystem und das ist noch nicht final. könnte also daran liegen. Aber eigentlich ist das schon ein besonderer Bug. Konntest du denn mit Escape in das Menü zurück? Weisst du noch wo und wie du gestorben bist? Ich gehe davon aus, dass es ganz zu Beginn war, nachdem du das Energietor gefunden hattest.
  7. Is den der Player evtl. auch ein Prefab, welches neu instanziert wird? Dann könnte es sein, dass das Prefab selbst noch keinen gegner im Slot hat, sondern nur der Player, der vor in der Szene drin war. Du musst einfach mal nach dem Start des Spiels auf pause gehen und dann deinen player anschauen. Ist da noch das Prefab im Slot?
  8. Wie der Parameter richtig übergeben wird, kann ich dir auch nicht sagen. Das ist jedenfalls ein Json Ausdruck. Aber vielleicht kriegst du das raus, denn du kannst, wenn du ein Input Action Asset erstellt hast, im Inspector bei dem Asset einen haken setzen. Dadurch wird ein c# Script mit gleichem Namen wie dein Asset erzeugt. Wenn du dir das mal anschaust, kommst du vielleicht dahinter. Ich steige da nicht ganz so durch. Jedenfalls kannst du auch mittels dieses Scripts eine andere Art der Inputabfrage erzeugen. Siehst du unten im Script. Wie dem auch sei. Du willst ja eigentlich nur über ein Testscript Werte in deinen player rein bringen und so tun als ob du ein Input bekommen würdest. So habe ich es jedenfalls verstanden. Warum willst du dafür unbedingt in die Methode rein springen, die ein InputAction.CallbackContext erwartet. Bau dir doch eine public Methode, die dein Vector2 aufnehmen kann und dann genauso die Bewegung des Players bedient. So etwa: using System.Collections; using System.Collections.Generic; using UnityEngine; using UnityEngine.InputSystem; public class InputTester : MonoBehaviour { GameControls controls; public Vector2 movementDirection; // falls du die Werte abfragen willst void Awake() { controls = new GameControls(); // input Kontrollen erstellen controls.Gameplay.XAxis.performed += ctx => MoveLR(ctx); controls.Gameplay.XAxis.canceled += ctx => MoveLR(ctx); } private void OnEnable() { controls.Gameplay.Enable(); } private void OnDisable() { controls.Gameplay.Disable(); } private void Update() { transform.position += new Vector3(movementDirection.x, movementDirection.y, transform.position.z); } void MoveLR(InputAction.CallbackContext context) { var direction = context.ReadValue<Vector2>(); movementDirection = direction; } public void TesteLR(Vector2 direction) // hier springt der Tester rein { movementDirection = direction; } } In der Update wird movementDirection für das setzen der Position genutzt. Ob die Variable nun in der Methode beschrieben wurde, die vom Input angesprochen wird, oder von der Methode, die dein Tester anspricht. Ist doch eigentlich egal, oder? Aber vielleicht habe ich es immer noch nicht richtig vertstanden...oder du willst/kannst das Playerscript nicht mit einer weiteren Methode bestücken. Na ja. Vielleicht hilft's ja doch.
  9. Die Methode rufst du nich von deinem Testscript auf. Die wird nur vom Action Event aufgerufen. Da sind doch die 2 Variablen, links und rechts. Wenn die im Script als Public deklariert sind, kannst du sie doch ständig vom Testscript aus abfragen. Du kannst genauso auch einen Sprung rein in eine Methode von deinem Testscript erzeugen, wo du von mir aus den direction-Wert anstatt der Variablenzustände mit übergibst. Der direction-Wertist ein Float im Bereich von -1f bis 1f.
  10. Das auszuwerten ist relativ einfach: public void LeftRight(InputAction.CallbackContext context){ links=false; //Testvariablen zum Auswerten in der Update oder so rechts=false; var direction = context.ReadValue<Vector2>(); if(direction[0] <0){ // [0] ist die X-Achse, [1] wäre die Y-Achse links=true; } if(direction[0] >0{ rechts=true; } } Bei diesem Beispiel gehe ich davon aus, dass das InputActionElement eine Komponente an deinem zu steuernden Gamobject ist. Beim Bereich Behavior vom InputAction ist "Invoke Unity Events" eingestellt und im Bereich Events hast du dann für diese Action das entsprechende Script und Methode ausgewählt.
  11. Ja genau. Wenn du diese Geschosse im Inspector hinzugefügt hast, brauchst du sie nicht mehr nachladen, denn sie sind ja schon mit den Variablen verknüpft. Und bei den Geschossen selber, wo du ja jetzt nur eine Explosion einlädtst, musst du dir immer vor Augen halten, dass ein Prefab soetwas wie eine Baupause ist. Also eine Bauanleitung mit gewissen festgelegten Eigenschaften, die von dir aber mit unterschiedlichen Dingen bestückt werden kann und soll. Du baust ja aus unterschiedlichen DIngen etwas zusammen. Du nimmst ein oder mehrere geometrische(s) Objekt(e), gibst ihm ein Material, bestimmst die Größen, hängst ein Script an, gibst ihm physikalische Eigenschaften und vielleicht sogar noch einen Sound. Dieses machst du zu einem Prefab also ein vorgefertigtes Produkt und kannst es sofort im Spiel verwenden. Auch die Dinge, die innerhalb einer Komponente variabel sind, wie z.B. die Explosion, die im Script hinzugefügt wurde, oder aber ein ganz bestimmter Sound, der der Audiosource hinzugefügt wurde, sind Bestandteile des Prefabs. Ein Prefab erstellt man ja gerade weil man nicht alles im Code zusammenbauen will. Natürlich kann man per Code ein Objekt dynamisch zusammenbauen und sich die Komponenten nehmen, die man so haben will. Aber sinnvoll ist so etwas nur in ganz wenigen Fällen. Mir würde da ein konfigurierbarer Charakter einfallen, dem du unterschiedliche Outfits geben könntest. Beim Triggern machst du aber immer noch unnötige Dinge: Wie ich oben schon geschrieben habe, musst du nicht das GameObject des getriggerten Colliders holen um den Tag zu überprüfen. Alle Komponenten, die an einem Gameobject hängen, erben den Tag des GameObjects (damit meine ich aber nicht irgendwelche Unterobjekte, die ja selber wieder GameObjects sind und nur mitgeschleift werden, wie ein eigenständigens Rad an einem Auto) . Wenn du hier in der Scripting API mal den Bereich Inherit Members anschaust (Inherit = erben), dann siehst du all die Dinge die vom GameObject oder dem Object an sich weitervererbt werden. https://docs.unity3d.com/ScriptReference/Collider2D.html Du musst also keine weitere Variable bilden den Tag des GameObjects zu erfahren. Der Collider hat den Tag selber! Also kannst du gleich sowas schreiben: public void OnTriggerEnter2D(Collider2D trigger) { if (trigger.CompareTag("IstWand")) { } }
  12. Ja, an sich funktioniert das. Du machst da aber ein paar Dinge, die doppelt gemoppelt sind. Denn: Du hast 2 Prefabs für die Geschosse und du hast 2 Prefabs für die Explosionen. Gut. Der Player hat 2 Slots für die 2 unterschiedlichen Geschosse. Gut. Deine Geschosse haben 2 static Variablen für die Explosionen. Putzig. Deine Geschosse laden sich beide Explosionen rein, obwohl ja nur eine genutzt wird. Putzig. Wenn dein Geschoss die Wand trift, wird entschieden welche Explosion geziegt werden soll. Putzig. Ich würde es anders machen und du solltest es auch. Und zwar: Dein Player hat für die beiden Geschosse ja public Variablen angelegt. Dort kannst du einfach die Prefabs im Inspector rein legen und musst sie nicht extra nachladen. Gut, zur Sicherheit, falls du vergessen hast die Variablen zu bestücken und somit die Variable =null ist, kann man natürlich dieses Nachladen machen. Aber eigentlich braucht man das nicht. Dein Geschoss hat für die Explosionen "statc" Variablen genutzt. Da sehe ich absolut keinen Sinn drin. Static macht man nur etwas, wenn es global gültig und einzigartig sein soll! Auch in diesem Script lädst du prefabs nach, was du nicht müsstest, wenn du die Variable public machen würdest und sie einfach im Inspector bestücken würdest. Vor allem stört mich, dass du beide Explosionen rein holst, obwohl doch klar ist, dass das rote Geschoss nur rot explodiert und das blaue nur blau! Ich würde diesem Script nur eine Explosionsvariable geben, die entweder public ist oder private und das Attribut [SerializeField] davor stehen hat. Dieses Attribut gibt dir die Möglichkeit eine private Variable trotzdem im Inspector zu bestücken. [SerializeFild] private GameObject Geschoss; Aber wenn du einfach nur public nutzen willst, ist es auch voll ok. So, weil ein rotes Geschoss ja nur rot explodiert, legst du also in den Variablenslot einfach das rote Explosionsobjekt rein und übernimmst das im Prefab. Das Gleiche machst du mit dem blauen Explosionsprefab. Jetzt muss dein Geschoss überhaupt nicht mehr überprüfen, ob es blau oder rot ist. Es ist ja alles schon festgelegt. Und jetzt noch etwas wichtiges zum gameObject mit kleinem g : Unity erzeugt für dich automatisch eine Verknüpfung zu deinem GameObject und nennt es gameObject mit kleinem g! Das hier passiert also im Hintergrund für dich: private GameObject gameObject; gameObject= GetComponent<GameObject>(); Da dieses gameObject das Object selbst ist, brauchst du kein this mehr, denn es ist klar definiert. Du kannst es natürlich weiterhin nutzen, wenn es dir bei der lesbarkeit hilft. Du solltest aber aus diesem Grund auch gameObject nicht mit einem anderen GameObject verknüpfen, so wie du es bei deiner Abfrage mit der Wand gemacht hast. Egal ob diese Variable nur innnerhalb eine Methode/Funktion genutzt wird, oder nicht. Das kann zu unschönen Dingen führen. Nutze lieber einen anderen Namen, der eben nicht schon von Unity genutzt wird. Du musst auch beim Triggern keine neue Variable bilden, denn das passiert da oben ja schon. Der Collider2D des getriggerten Objektes wird der angegebenen Variable übergeben. Bei dir heisst sie collision (was auch unschön ist weil du ja triggerst und nicht kollidierst) und Untiy schlägt dir other vor. private void OnTriggerEnter2D(Collider2D other){ if (other.CompareTag("istWand"){ // explodiere } } Alle Komponenten eines Objektes erben dessen Tag. Deswegen musst du nicht extra das GameObject verknüpfen. So. Das war mein Senf dazu. Mir ist klar, dass du dich erst noch so richtig in Unity einarbeiten musst und dir ersteinmal die Funktion wichtig ist. Deswegen nimm das einfach so als Anmerkung.
  13. Also ich glaube eher, dass es am Sommer und der Erfahrung liegt. Du hast da schon recht, der große hype ist vorbei. Heutzutage gibt es viele Engines, die nix kosten und außerdem haben viele der Leute gemert, dass man seine Idee nicht mal eben so mit nen paar Klicks umsetzen kann. Trotzdem sind täglich jede Menge Leute hier und informieren sich. Nur, wenn man dann ne Zeit lang mit Unity gearbeitet hat, gibt es auch nicht mehr so viele Fragen zu stellen. Im Herbst wird es wieder anziehen, da bin ich mir sicher.
  14. Ich habe noch ein paar kleine Anpassungen an der Demo vorgenommen, die hauptsächlich die Steuerung der Flieger betreffen. Ich habe aber auch noch eine Möglichkeit geschaffen, den Missionstext noch einmal zu lesen, falls man ihn beim Missionsstart nur überflogen hatte und dann nicht mehr weiß was man machen soll. Sie kann im Ingame/Pause Menü nocheinmal nachgelesen werden. Die Neue Version steht zum Download bereit. Cavatus-Demo-Download
  15. Bei mir liegen sie im Scriptordner weil ich nach Dingen sortiere. (Sounds,Textures,Scripts,Prefabs usw.) Ja und innerhalb dieser Ordner habe ich natürlich noch Unterordner. Wenn diese Klassen aber jetzt aber unabhängig vom Projekt wären, wie z.B. eine eigene Mathe-Klasse, dann würde ich die auch in einen separaten Hauptordner legen. Aber das ist alles eine Frage der Vorlieben.
  16. So es ist Wochenend und vielleicht habt ihr ja mal Lust eine Vorabversion von meinem Spiel zu spielen. Die Grafiken sind noch lange nicht final. Aber das ist fürs Spiel auch nicht so wichtig. Die Demo geht bis zum ersten Boss. Der Download ist ca 125MB groß. Hier wäre der Link dazu: www.malzbie.com/swap/Cavatus-Demo.zip Zur Info: Ich empfehle das Spiel mit einem Gamecontroller zu spielen. Geht natürlich auch mit Maus und Tastatur. Aber eben nicht so gut. Einstellungen können momentan nur im Hauptmenü gemacht werden. Im Ingame-Menü passiert noch nix. Natürlich würde ich gerne Feedback haben. Und hier ist mal ein kleines Video von einem Element, welches später im Spiel kommt.
  17. @Jog Sesamstrasse! Nicht Rappelkiste! @Dauerbrenner_YouTube Willkommen! Ja, der Anfang in Unity ist nicht ganz so leicht, weil man zwar weiß was man machen will, aber die spezifischen Befehle nicht kennt. Man lernt es aber schnell! Viel Spaß!
  18. Doch das ist meiner Meinung nach schon logisch und richtig. Zum Beispiel: eine Division durch 0 ergibt immer einen Fehler. Dieser kann zwar abgefangen werden, damit das Programm weiter läuft, trotzdem ist dann kein nutzbarer Wert da. Wer weiß, wie da physikalisch berechnet wird. 0 und Unendlichkeiten gehen einfach nicht. Bei mir war es einfach nur ein Untergrund, der keinerlei Reibung hatte (beide Friction-Werte auf 0). Das ging sogar ne Zeitlang gut. Aber dann plötzlich, nachdem ich ganz andere Dinge verändert hatte, hat sich mein Flugzeug beim Starten überschlagen. Da habe ich auch ne Zeit lang gesucht. (Die Räder vom Flugzeug rollen nicht sondern rutschen einfach nur, weils einfacher umzusetzen war und nicht drauf an kommt) Nimm einfach kleine Werte und schon ist alles gut.
  19. Ich kenne mich leider mit den Wheel Collidern nicht so aus, aber ich versuche das mal über den Rigidbody zu erschließen. Bei RB gibt es einen Moment, bei dem er einschläft. Das passiert immer dann, wenn die Forces unter einen Schwellenwert fallen. Ist so ein RB erst einmal eingeschlafen, rollt oder rutsch er ungern wieder los, egal ob sich der Untergrund in der Neigung verändert, oder nicht. Um das zu umgehen gibt es einen WakeUp Befehl, der den RB aufweckt. Ich nutze das bei meinen Flippern. Da frage ich ab ob der RB schläft, und wenn ja, dann wecke ich ihn. Beim WheelCollider soll ja die Physik von der allgemeinen Physik losgelöst sein. Aber es gibt auch hier Reibungen und Kräfte. Da du geschrieben hast, dass der Anhänger sich doch bewegt, nachdem er einen starken Impuls bekommen hat, gehe ich davon aus, dass irgendwo die Reibungswerte zu hoch sind. Möglicherweise kannst du mit der ForwardFriction etwas lösen, indem du sie verringerst. Ich habe auch gelesen, dass gewisse Werte nicht 0 sein können oder dürfen, wie z.B. die Wheel Damping Rate! Mir ist bei der normalen Physik selbst schon aufgefallen, dass eine 0 zu Fehlern führen kann. Einen sehr kleinen Wert (anstatt der 0 eine 0.001 eintragen) hat bei mir geholfen. Vielleicht spiel das Ganze doch auch mit dem RB zusammen und ein aufwecken des RB's könnte helfen. Tja, leider kann ich nicht mehr dazu sagen. Aber vielleicht bringt es dich in die richtige Richtung.
  20. Moin! Damit du der Camera irgendwelche Dinge übermitteln kannst, muss dein Script sie erst einmal kennen. Leg dir dafür einfach eine Public Variable vom Typ Camera in deiner Klasse an und lass die Camera dann im Inspector in den freien Cameraslot vom Script fallen, wenn dein Script gespeichert und dem Objekt zugewisesen wurde. public Camera myCamera; // diese Variable wirst du im Inspector sehen können und da tust du dann die Camera rein Wie du die Variable nennst bleibt natürlich dir selbst überlassen. Jetzt weiss dein Script, welche Camera angesprochen werden soll und nun kannst du ihr auch Sachen mitteilen, wie z.B.: myCamera.clearFlags=CameraClearFlags.Nothing; Hier ein Link zur Scripting API wo du alle Dinge sehen kannst, die mit der Camera zu tun haben: https://docs.unity3d.com/ScriptReference/Camera.html Und hier der Code, wie du ihn nutzen könntest: public class ClearFlagSwitcher: MonoBehavior{ public Camera myCamera; private void OnTriggerEnter(Collider other){ myCamera.clearFlags=CameraClearFlags.Nothing; } }
  21. Möglicherweise hattest du die public Variablen im Inspector geändert und damit dann Dinge getestet. Und später hast du im Code die public Varablen neu gesetzt und gedacht, dass diese neuen Werte im Code auch dann genutzt würden. Das ist aber so nicht. Wenn du Public Variablen im Inspector änderst, dann gelten diese Änderungen, egal wie oft du danach im Code andere Werte reinschreibst. Du kannst aber im Inspector die Werte resetten. Aber Obacht! Es ist dann wirklich alles so wie im Code. Auf die Schieberegler mal rechts drauf klicken und reset auswählen.
  22. Also wenn ich es richtig interpretiere, dann springst du beim Druck eines Buttons in die Methoden Startbutton() bzw. Stopbutton(). Dein Problem ist, dass du da immer einen Button abschaltest. Und diese Eigenschaft willst du dann als Kriterium in der Update nutzen. Ich gehe davon aus, dass zu Beginn beide Buttons enabled sind, denn sonst würd ja garnichts gehen. Also drückst du den Startbutton und der führt Startbutton() aus. Dort aktivierst du den bereits aktiven Startbutton und dekativierst den Stoppbutton. Da jetzt der Stoppbutton deaktiviert ist, kannst du da drauf drücken wie du willst. Er ist deaktivert und wird nix machen! Also wenn ein Druck auf einen Button einen gewissen Button deaktivieren sollte, dann natürlich den, den man gerade gedrückt hat. Das würde Sinn machen, denn man braucht den ja nur einmal drücken. Der Gegenspieler muss aber aktiv sein, denn sonst kann man ja die Stoppuhr nicht beenden, wenn sie läuft. Genauso will man ja die Stoppuhr wieder starten, wenn sie angehalten wurde. Nimm einfach eine Boolsche Variable die du beim druck auf den Startbutton auf true setzt. Diese nutzt du dann für deinen Timer. Wenn du auf den Stoppbutton drückst setzt du diese Variable wieder auf false zurück. Warum spielst du eigentlich mit der Timescale rum? Das macht doch überhaupt keinen Sinn?!
  23. Na ja. Eigentlich gar nicht. Jedenfalls nicht komplett denn: Deine Lichtquelle hat ja diverse Einstellungswerte. Du gibst unter anderem an, wie Hell das Licht ist und wie weit es scheinen soll (Bei Point- und Spotlight). Daraus ergibt sich eine Abschwächung vom Startpunkt zur maximalen Entfernung. Du kanns jetzt einfach mal mit der Intensity und der Range spielen. Also die Range mal viel größer machen als du brauchst (nicht nur bis zum Boden der Szene, sondern darüber hinaus) und die Intensity reduzieren, bis das Material eben nicht mehr so stark beleuchtet wird. Wo wir gerade beim Material der Objekte sind. Die haben natürlich auch einen EInfluss darauf, wie stark Licht reflektiert wird. Du hast bei URP 2 Materialtypen vorgefertigt. Einmal das metallische Material, wo du die Stärke der Metallic Map (falls du da keine Metallic Textur reingelegt hast) einstellen kannst. Das ist für die Grundreflektion. Je höher der Wert, umso mehr reflektiert das Material wie ein Spiegel, dafür verliert es aber an Farbreflektion. Und dann gibt es noch die Smoothness. Das ist ein Weicheitsfaktor für den Glanzpunkt. Ist der Wert gering dann glänzt das Material diffus überall. Ist der Wert hoch, wird der Glanzpunkt immer enger. Das andere Typ nennt sich Specular. Dieses Material glänzt jetzt nur und kann nicht spiegeln. Aus diesem Grund hat der auch nur einen Slider für den Glanzpunkt. Eine Richtige Beleuchtung braucht also richtig eingestellte Lichter und richtige Materialien auf den Körpern. Spiel mal mit den Lichtern und Materialien rum.
  24. Moin Leute! Gestern wurden vermehrt Spamnachrichten versendet und auch heute versucht der Spammerbot sich weiterhin anzumelden und danach Nachrichten zu versenden. Wir sind an dem Problem dran! Momentan heißen alle Spammer Inda mit ner Zahl hinten dran. Solltet Ihr von einer IndaXX eine Nachricht bekommen haben, dann bitte löschen.
×
×
  • Create New...