Suchergebnisse

Sehr schönes Ding! Da ich das nun evtl. mal nutzen wollte (vielleicht mit Larsi zusammen), habe ich es mal für GM:S "portiert". Natürlich möchte ich das mit euch teilen und lade es in den Anhang. Ein paar Kleinigkeiten mussten angepasst werden, wie dass kein "variable_local_exists" mehr verwendet wird. Zudem habe ich das Wand-merge Script so angepasst, dass man den Vorgang der Block-Verschmelzungen nun auf mehrere Frames aufteilen kann, wenn man dies möchte um die Last etwas zu verteilen. (obj_c…

Vermutlich kommst du nicht drumrum dir eine Formel zu überlegen oder zu suchen, die die isometrischen Koordinaten auf ein 2D-Array abbildet, das ist auch nicht so ganz trivial... Und hättest du vielleicht noch einen Screenshot von dem, was du bereits hast, damit man sich das ganze besser vorstellen kann? Viel Erfolg!

Optimal ist: Wenn du dein Spielfeld in Kacheln unterteilst (sieht so aus als hättest du das bereits und macht ja auch Sinn mit Tiles) und dann eine Datenstruktur verwendest, um die Begehbarkeit zu speichern. Hier bietet sich natürlich ein 2D-Array an (bzw. Grid) und es reichen binäre Werte. Dies ließe sich dann auch leicht erweitern, z.B. wenn du Wege haben möchtest, die nur in eine Richtung begehbar sein sollen, etwa wie Stufen bei Pokémon. Hier könnte man dann einfach weitere Werte einführen. …

Ich hab dir die korrigierte Version zurück geschickt. Neben dem do (wenn auch irrelevant), war (wie ich ja auch als mögliche Ursache genannt hatte ) der Connector zu weit von der Tür entfernt. Es waren 72 Pixel, anstatt die maximal 16, auf die du prüfst. Du musst hier darauf achten, dass es nicht reicht, dass sich die Instanzen im GM-Editor überlagern. Es zählen die eingestellten Origins der verwendeten Sprites, die mit (0, 0) bei dem Connector und (0, 32) bei der Tür, zu weit auseinander lagen.…

Zitat von DragonGamer: „Welches Objekt führt diesen Code aus?“ Wenn er es richtig macht, ist es das obj_conn_01-Objekt im Create-Event. Zitat von Drachen: „Ok das mit der Do-Schleife habe ich jetzt verstanden, werde ich wahrscheinlich auch nicht brauchen.“ Ähm, ein do kommt da schon hin:GML-Quellcode (1 Zeile)Denn das do gehört zu dem with. Ich sehe gerade sonst keinen Fehler mehr - würde mich wundern, wenn das nicht funktionieren würde, sofern zwei obj_conn_01-Instanzen, die nah genug an Schalt…

Wie ich gesehen habe, hast du es ja fast geschafft. Aber warum legst du einen zweiten Thread zum gleichen Thema an? Ja, das mit den vaiablen IDs war auch der Grund, warum ich mir diese Vorgehensweise überlegt habe. Allerdings würde ich auch das heut zu Tage nicht mehr nutzen, sondern mir direkt einen in-game-Editor schreiben, in dem ich so etwas bequemer lösen kann. Aber ich glaub so weit bist du ja noch nicht ;)

Ja, ich sehe auch absolut keinen Nutzen einer Schleife hier... Aber du hast noch einen weiteren Fehler in Zeile 24, die müsste wie folgt lauten:GML-Quellcode (1 Zeile)sonst speicherst du das Tor in eine andere Instanz als den Schalter.

Ja, sieht ja schon fast so aus als hättest du das Prinzip verstanden. Für jede Verbindung ein Connector-Objekt, d.h. wenn du z.B. einen Schalter hast, der 3 Türen öffnen soll, brauchst du insgesamt 4 Instanzen des selben Connector-Objektes. Die 64 Pixel hab ich natürlich nur mal so dahingestellt - die Connectoren müssen natürlich auch nah genug an den Türen/Schaltern sein. An deinem Fehler kann ich ohne den Kontext leider nicht sehen, wo genau das Problem liegt. Er zeigt einen Fehler mit der Var…

Ja, ich denke mein Code könnte schon reichen, um das Prinzip zu verstehen. Melde dich einfach wieder, wenn du es genauer angeschaut hast.

Momentan hab ich leider keine Zeit für ein Tutorial. Evtl. komme ich heute Abend mal dazu. Aber zunächst versuche ich es nochmal mit etwas weiterer Erläuterung: Für die maximale Anzahl an solchen Verbindungen, die gleichzeitig in einem Raum existieren können sollen, erstellst du je ein Objekt obj_connector_1 bis obj_connector_n. Dieses prüft im Create sowas wieGML-Quellcode (12 Zeilen) Ich hoffe damit wird es verständlich. Somit musst du keine Nummern mehr rausschreiben und kannst die Verbindung…

Dazu müsste er das Spiel ebenfalls erst starten. Soweit ich das verstanden habe, möchte er mit möglichst wenig Aufwand Instanzen miteinander verknüpfen...

Da kann man leider nichts machen. Das System wurde für die HTML5-Version verändert und in GM:S beibehalten. Die Nummern lassen sich leider auch nicht ineinander umrechnen, da die Hexzahlen nicht aufeinander folgen im Gegensatz zu den dezimalen IDs. Related Threads: gmc.yoyogames.com/index.php?showtopic=567889 gmc.yoyogames.com/index.php?showtopic=583541 Ich würde allerdings eh empfehlen, nichts in Abhängigkeit dieser Nummern zu programmieren, sondern dir etwas zu überlegen, dass ohne auskommt. D…

Was kannst du dann? XD Also was manche Leute hier an Geduld und Verständnis mitbringen... Respekt!

Ja, geht schon ein Weilchen. Hier findet ihr ein paar nette Beispiele mit Code: Shader Examples e806.jpg

Ja, da geht es einfacher. Vielleicht gibt es ja auch schon etwas neues für den Pro Controller...

Das Mappingprogramm erkennt alle und kann sie nutzen. Das Problem ist halt, dass es nicht wie ein direkt angeschlossenes Gamepad erkannt wird und du die Tasten selbst zuweisen musst. Das kann dann bei den Analogsticks Probleme machen, wenn du z.B. ein Spiel nutzen möchtest, bei dem die Einstellungen dir nichts anderes erlauben, auf das du deine Analogsticks mappen kannst. Hoffe du verstehst was ich meine Man kann sie z.B. auch auf die Maus mappen, wodurch man etwa Shooter damit spielen könnte. D…

Ja, das ist logisch, weil du ihn ja in jedem Frame umschaltest. Du müsstest also warten, bis du den Schalter nicht mehr berührst, um das Umschalten wieder frei zu geben. Du könntest dem Schalter also z.B. eine Flag geben, eine Boolean Variable, die dafür steht, ob der Schalter momentan berührt wird. Nennen wir sie mal touch und setzen sie im Create-Event des Schalters auf false. Bei dem Code oder Drag-&-Drop Befehl, bei dem du den Schalter umschaltest, prüfst du zunächst, ob diese Variable noch …

Achso, ok. Aber würde dann trotzdem empfehlen nur ein Objekt dafür zu nehmen, dass die Sprites in irgendeiner Datenstruktur hält. Gerade wenn es was größeres werden soll (ich weiß ja nicht was du vor hast), es auf alten Rechnern und in HTML5 laufen soll, macht sich das irgendwann schon schlagartig und stark bemerkbar. Also Objekte mit Sprites brauchen eindeutig sehr viel mehr Ressourcen als nur Tiles.

Sprites ohne Objekte sollen Code ausführen? Das kann ich mir nicht vorstellen. Sie brauchen vielleicht mehr Speicher, da die interne Sprite-Repräsentation Infos über Kollisionsmasken usw. enthalten, aber ich glaube zur Laufzeit brauchen alle Varianten gleich viele Ressourcen. Der Unterschied ist also das "Drumrum", der einzelnen Bilder-"Datentypen", würde ich sagen.

Hallo, es gibtGML-Quellcode (12 Zeilen)welche du verwenden kannst, für Multitouch (bis 5 Finger gleichzeitig) und Drehbewegungen des Gerätes in drei Achsen.