Suchergebnisse

Und was hält dich davon ab, einfach alle Objekte relativ zu dem besagten Objekt erstellen? Tut mir nochmals leid, ich verstehe das Problem nach wie vor nicht. Was willst du damit genau bezwecken?

@Max: Ich interpretiere dein Problem folgendermaßen: Du willst die Koordinaten des Mauszeigers relativ zum besagten Objekt ermitteln. ABER genau das löste Tobi97 bereits und da du die Richtigkeit bzw. Zutrefflichkeit in deiner Antwort verneinst, bitte ich dich deine Frage zum besseren Verständnis deines Problems noch einmal zu reformulieren.

Das Problem besteht, weil du nach dem else keine geschweiften Klammern gesetzt hast. Dies wäre außerdem auch eine Variante: GML-Quellcode (11 Zeilen)

Ich habe nun noch einen kleinen, dummen Fehler korrigiert. Jetzt sollte es funktionieren... Edit: Der Fehler war bei: GML-Quellcode (1 Zeile) Statt "- ((hspeed < 0) * 180)" sollte es "+ ((hspeed < 0) * 180)" heißen, da das Skript sonst bei "hspeed < 0" falsche Winkelmaße einbeziehen würde.

Es tut mir leid, ich habe das Sichtfeld anhand deiner ersten Skizze angefertigt. Könntest du eine Skizze erstellen, welche genau zeigt, wie das Sichtfeld aussehen soll? (Den erwähnten kleinen Fehler hab ich außerdem bereits korrigiert.)

Ja, es geht in der Tat etwas kürzer: GML-Quellcode (9 Zeilen) So würde man das Skript zu deinem Code adaptieren: GML-Quellcode (6 Zeilen) Achja: Wenn hspeed des Gegners gleich den Wert "0" annimmt solltest du dies extra behandeln...

Mathematisch gesehen ist dies eigentlich ziemlich simpel zu lösen: Zuerst bestimmst jene Linie der Kandidaten AB, BC, CD und DA auf welcher der Punkt (also der Player) kollidiert. Folgendes Skript sollte dir dabei helfen: GML-Quellcode (2 Zeilen) Es gibt einen negativen Wert zurück, falls der Punkt (x3|y3) links von einer Geraden liegt, einen positiven wenn er rechts davon liegt und 0, wenn er direkt auf ihr liegt. Nun einfach durch die Differenz der Rotation des Spielers und die der zutreffende…

Nein, ohne einer detailliertere Einsicht in deinen Code werden wir dir nicht weiterhelfen können. Bist du dir sicher, dass dein Skript vor dem Erstellen der Instanz des Objekts im Raum ausgeführt wird?

Das liegt sehr wahrscheinlich daran, dass du die Eigenschaften des Objekts und nicht der bereits zuvor generierten Instanz jenen Objekts modifizierst. Verschiebe den Code in ein Event, welches vor dem Create Event des besagten Objekts aufgerufen wird.

Ich habe dir schnell ein Skript geschrieben, welches dieses Problem lösen sollte. Die Anwendung sollte selbsterklärend sein: (Versteckter Text)

@DragonGamer: Ich denke du hast diese Funktion noch immer nicht verstanden, denn execute_string ist im Grunde nichts anderes als das Äquivalent zu JavaScripts oder PHPs eval Funktion. Sie dient ausschließlich zur Ausführung von Code, welcher zur Laufzeit generiert wurde und keinesfalls selbst von der eval Funktion interpretiert wird. (Sorry, ich konnte es einfach nicht so stehen lassen, bitte nimm es mir nicht übel...)

Jedes von GM:Studio erstellte Spiel wird nach wie vor interpretiert. Da jedoch Android und iOS nicht viel mit auf einem Delphi basierendem Interpreter anfangen konnten, wurde jener vollständig in C++ reimplementiert. Dies stellte sich auch als Verursacher der bereits verzeichneten Performancesteigerungen heraus. Lediglich das HTML5 Exportmodul transcompiliert den GML Code, inklusive aller von YoYoGames bereitgestellten Funktionen nach JavaScript, was aber bei den aktuellen JS-Interpretern der Br…

Ich würde dieses Problem dermaßen lösen: - Zuerst erstelle in einem persistenten Objekt eine Instanz des Typs ds_list - Bei jedem Raumwechsel werden nun die Eigenschaften eines jedem im Raum befindlichen Objekts mit einem bestimmten, individuellen Offset für den benannten Room, der ds_list hinzugefügt - Im draw Event jenes persistenten Objekts werden nun einfach die Elemente anhand der gespeicherten Eigenschaften in die Minimap gezeichnet, während man mit Konditionen überprüft, ob das Zeichnen e…

Mit dem Datentyp char (wie du als eingefleischter C++ Programmierer natürlich wissen solltest) kannst du doch die Koordinaten als Ordinalwerte (von -128 bis 127) ohne jegliche Kodierung in Form von char * dem Game Maker problemlos übergeben. Wo soll hier das Problem liegen?

Nun, dann wäre doch die Übertragung eines eindimensionalen Arrays, in welchem ausschließlich die Koordinaten der sich seit dem letzten Frame veränderten "Zellen" vorhanden sind, um ein vielfaches effizienter, oder nicht?

Wenn dein zweidimensionales Array nicht zu groß wird, sollte das Übertragen eines Strings und der Zugriff auf die einzelnen Elemente (welche dann ausschließlich des Types char wären) über string_char_at kein großes Problem darstellen. Es wäre jedoch wirklich hilfreich, wenn du uns etwas näher verraten würdest, aus welchem Grunde du die Echtzeitübertragung eines solchen Arrays benötigst. Eventuell ließe sich dann eine elegantere (bzw. eine Speichernutzungsminimierende) Methode erarbeiten.

Ich habe dir ein Skript geschrieben welches dies bewerkstelligt. Die Anwendung sollte sich von selbst erübrigen. GML-Quellcode (4 Zeilen) €dit: nimm lieber trixt0r's...

Auch wenn das Thema bereits als erledigt markiert wurde, habe ich dir ein Skript geschrieben, welches die Berechnungen anhand eines Arrays ("die allgemeine Liste") durchführt: GML-Quellcode (20 Zeilen)

Manchmal kann auch ein einfacher Tippfehler Schuld am Dilemma sein: move_towards(o_text.x,o_test.y,1);

Um Apps für die iOS Platform letztendllich über den App Store zu vertreiben, bleibt immer ein Mac notwendig. (Es reicht von der finanziellen Seite her aber ein alter Gebrauchter auch...) Du kannst zwar mit einem normalen PC mit dem Game Maker Studio ein Spiel für die iOS Platform entwickeln, aber niemals auf einem PC das Spiel direkt in den App Store übertragen. Wenn du nun einen Mac besitzt bleiben dir unter anderem folgende Möglichkeiten: 1. Du nutzt den Mac lediglich um die mit dem Game Maker…