[Variablen] Relative Bildposition in XY-Koordinate umwandeln

[BDraw]

Mag sein, dass ich's überlesen habe, aber welchen Maker benutzt Stray denn?
Das sieht nach 2k/3 aus, da wird Standardmäßig die Mitte des Bilds benutzt. Auswählen, ob der Maker mit der Bildmitte oder der oberen, linken Ecke rechnen soll, konnte man erst ab dem RPG Maker XP.

Ich sehe aber nicht ganz, was damit gewonnen ist, ein unsichtbares Helden-Event zu bewegen. Du kannst die Map-Koordinaten (also gemäß des Rasters) abfragen, aber die Position hast du ja durch das Pixelmovement eh in irgendwelchen Variablen gespeichert.
Weiteres Problem: Das Event wird dir nicht helfen, die Kollision auszutricksen, da dein Bild eben 8px Pufferzone hat, in der es mit anderen Events und Tiles überlappen kann. Die einzige Möglichkeit wäre hier nach dem Tastendruck und vor dem Bewegen des Bildes abzufragen, ob das Bild bewegt werden darf, sprich, du müsstest die Abmessungen deines Pictures nehmen und schauen, ob und wie weit es in das nächste angrenzende Kästchen hineinragt.

Nächstes Problem wäre dann, dass Events die sich zufällig oder gemäß einer Route bewegen, nur das Event erkennen und nicht das Bild und somit auch überlappen würden. Bloß das zu umgehen ist noch einmal komplizierter.

[Stray]

@BDraw:
Naja, solange es umgehbar ist, ist mir die komplizierte Alternative angesichts des restlichen Aufwands (wie Mapgestaltung und Gegner usw.) sehr recht anstatt ALLES mit Bildern und Pixelmovement zu bewegen.
Ein leichtes Überlappen ist ja tolerierbar, jetzt kommt's eben auf eine Grenze an die dafür gelegt werden muss.

Kollisionen hab ich schon gelöst, zumindest mit Wänden: Es werden einfach die Terrains der dem Helden-Event gegenüberliegenden Kästchen abgefragt.
Ist das Terrain 1, bedeutet das, dass sich daneben unbegehbarer Boden befindet. Terrain 2 bedeutet Luft, der Held kann sich dort bewegen. Das Überlappen habe ich gelöst, indem ich ein Kontrollsystem in das Helden-Event eingbaut habe: Es kontrolliert die ganze Zeit, ob sich das Bild in seinen Koordinaten genau auf dem Helden-Event befindet. Sind die relativen Bildwerte des Helden-Events gleich mit den relativen Bildwerten des Bildes kann sich das Bild an dieser Stelle nicht mehr weiter bewegen, wenn das benachbarte Feld eine Blockade bzw. Terrain 1 ist.
Z.B. befindet sich der Held einen Schritt links neben der Wand, sagt ihm das Script, dass rechts davon der Terrain 1 liegt. Steuert man nun nach rechts, während sich das Bild noch etwas weiter links über der Mitte des Helden-Ereignisses befindet, kann man noch nach rechts steuern. Ab dem Zeitpunkt wo es genau darauf liegt ist dann vorerst Sense in der Steuerung gegen die Wand und überlappen ausgeschlossen.


@Bex:
Danke, funktioniert wunderbar!
Und genau mit dem was BDraw beschrieben hat möchte ich jetzt eigentlich auch weiter machen, ich brauche noch ein System um diese Pufferzone von 8 Pixeln zu verkleinern.

[Bex]

Was meinst du genau mit Pufferzone?

Dein Held müsste unterschiedlich lange Schritte machen um das zu beheben wenn du das meinst was ich denke. 16Pixel von Feldmittelpunkt zu Feldmittelpunkt. Und 8 Pixel sinds zur verflichsten kannte,
wo sich 2map tiles gegenüberliegen.
Die Schitte müssten also
5Pixel 6Pixel und 5Pixel lang sein von Feld zu Feld. also in 3Schritten.

Du brauchst das Event unter dem Heldenbild nicht um Treffer zu berechnen, dafür kannst du die Screen Positionen der Monster nehmen und minus der Screenposition des Heldenbildes rechnen .Glaube ich zumindest grad^^ habs nicht getestet.

Edit: Das mit den drei Schritten hatte zwar gelöst das du nicht mehr auf die mitte zwischen 2 tiles laufen kannst, nun noch die lösung für das überlappen...
hmmm....hängt mitlerweile davon ab wie dein code gestaltet ist.....

Hast du schon eine Idee wie du das Picture Animieren willst? Das stelle ich mir recht schwer vor, besonders während des bewegens.

[BDraw]

Es geht bei der "Pufferzone" um folgendes:
Während ein Event nur 16px-Schritte machen kann, kann Pixelmovement eben auch kleinere Schritte machen und befindet sich somit zwangsläufig den Großteil der Zeit irgendwo zwischen zwei Tiles. Es ist also möglich, dass der Picture-Held aufeinmal zwischen zwei Tiles steht. Das ist nicht weiter kritisch, außer, auf einem der beiden Felder ist etwas, was ihn blockieren kann/soll: Während er von den Tile-koordinaten her noch "vor" dem Hindernis steht, befindet er sich aber optisch bereits weiter und hängt somit in dem Hindernis drin.
Wenn der Held jetzt, sagen wir mal, wirklich 16px breit ist, darf er sich also nicht mehr über den Kästchenmittelpunkt hinausbewegen, sollte in der Richtung neben ihm ein Hindernis stehen. Deine drei Schritte lösen dieses Problem nicht, sie sorgen nur dafür, dass der Held sich nur 1/3 oder 2/3 zwischen den Tiles befinden kann. Umgehen kann man das nur, indem jeder Tastendruck den Helden 16px bewegt, aber dann braucht man kein Pixelmovement mehr.

Ergo:
1. Spieler drückt Taste
2. Abfragen, wo der Held ist
3. Abfragen, ob das Feld vor ihm begehbar ist
3.1 JA: Kein Thema, Held darf bewegt werden.
3.2 NEIN: Abfragen, was die Position nach der Bewegung wäre. Geht sie über die Tile-Mitte hinaus, bzw. wäre die neue Position problematisch?
3.2.1 JA: Der Held darf sich nicht bewegen.
3.2.2 NEIN: Okay, kein Thema, Held darf bewegt werden.

So ganz grob. Abfragen, ob ein Feld begehbar ist, hast du ja schon raus, was noch nützlich ist ist abzufragen, welche Event-ID das Event auf dem Zielfeld hat. Ist diese 0, so ist dort kein Event, wenn doch, ist ein Event da (eben das Event mit der jeweiligen ID. Wenn du ordentlich bist, kannst du dann gezielt sagen, welches Event dort steht und ob es eine Blockade oder begehbar ist). Das ist wichtig für NPCs, aber auch wenn du im Upper Layer Sachen hast, die blockieren können, da dem Upper Layer soweit ich das im Kopf habe keine Terrain IDs zugewiesen werden können.

Ich weiß, dass ich sowas mal in einem alten Testprojekt hatte, aber das existiert garantiert nicht mehr. Kurz gesagt, du musst vor dem Bewegen des Bildes abfragen, wo es theoretisch nach der Bewegung wäre und ob es da sein darf.
Für das animieren könntest du einen eine Variable benutzen, die den Animationsstatus angibt (stehen, bewegen wenn Bewegung möglich ist, ...) und einen separaten Parallelen Prozess der anhand dieser Variable das Bild ändert.

Andere Frage:
Weißt du schon, wie du es erreichst, dass ein Held das größer als 16px ist unter einem NPC angezeigt wird, wenn es auf der Map direkt unter ihm steht? Bei einem Sidescroller (würde sich ja bei Jump'n Run anbieten) hättest du das Problem natürlich nicht. Oder wenn dein Held genau auf ein Tile passt.

[Bex]

Die Abfragen wo was passierbar ist sind glaube ich möglich aber nicht sehr leicht. Bin gespannt ob du was austüftelst.

Die Animation des Pictures stelle ich mir am aller schwersten vor, besonders wenn es sich noch gleichzeitig mit move picture bewegen soll.

[Stray]

Die Animation ist gar nicht so schwer. Beim RPGM2k(3) gibt es ja Wartezeiten in (ich glaube?) Millisekunden. Im Maker heißt das dann 0.0 Sekunden. Das Bild wird dann alle 2x0.0 Sekunden wieder geupdatet. Längere Wartezeiten und Animationen dazwischen werden mit mehreren gleichen Bildern gemacht, damit das Bild auch immer auf der Position bleibt.

Ich habe mittlerweile festgestellt, dass die Bildschirmbewegung am schwierigsten zu scripten ist, da die Position des Heldenbildes (und somit vom Helden) eben genau von der Bildschirmposition abhängt. Das heißt, wenn sie sich verändert, rutscht das Bild mit, egal was man dagegen tun möchte.
Das Problem ist jetzt eigentlich also mehr: Wie schaffe ich es den Bildschirm temporär unabhängig vom Helden zu machen, ohne dass es die Bewegung vom Helden beeinflusst?

EDIT:
Sogar das Scrollen gelöst.

Ein Schritt mit der Geschwindigkeit "Normal" dauert In "Wait": "0,1 Sek" + 2x "0,0 Sek" (also 8x 0,0 Sek)
Ein Schritt mit der Geschwindigkeit "2xSlower" dauert In "Wait": "0,2 Sek" + 4x "0,0 Sek" (also 16x 0,0 Sek)
Das bedeutet, während sich der Bildschirm mit 2x Slower bewegt wird der Spieler alle 0,0 Sekunden jeweils 1 Pixel in die entgegengesetzte Richtung zurückgeschoben.
Bei Normal wären das denn jeweils 2 Pixel, nur macht es das logischerweise ungenauer und wirkt auch im Spiel nicht besondern gut.

[Bex]

Ich hab noch eine Idee zur Ergänzung:
PlayerHeld Event wird erschossen und in eine unsichtbare Kamera verwandelt.
Dann benutzt du unter dem PictureHelden ein simples Mapevent, das bewegt die Kamera nicht.
Nun kannst du zum beispiel Maps machen wo die Karte unterschiedlich schnell scrollt, oder erst an bestimmten Positionen.
Das sollte einem noch ein bischen mehr Spielkram mit der Optik erlauben.

[Stray]

Versteh ich nicht. Erschossen?
Wie wird es in eine unsichtbare Kamera verwandelt?
Irgendwie ist dein Text etwas unerklärt.

Die große Schwierigkeit aktuell ist, wie das Event erkennt, dass der Sprung unterbrochen wird. Das Bild bewegt sich beim Sprung jede Sekunde um jeweils 8 Pixel nach oben. Es ist dem Heldevent dabei also immer einige Pixel voraus, weil es ja etwas überlappen kann. Wie hindere ich es nun am Überlappen? Es geht zumindest schon mal nach unten bzw. fängt wieder an zu fallen, wenn es erkennt, dass sich ein Feld weiter oben ein Terrain, dass eine Blockade ist, befindet. Ich hab schon alles mögliche ausprobiert. *sfz*
Wirklich erst mal umständlich...

[Bex]

Mit erschossen meinte ich , das du statt des Helden ein Event benutzt das unter dein Picture teleportet wird.

zu deinem problem mit der begehbarkeit, wie sieht denn dein bisheriger code aus? So ist es schwer etwas brauchbares zu sagen.

[Stray]

Hab's bereits ganz gut gelöst.

Das Scrolling ist allerdings doch wieder ein größeres Problem, da es rucklig läuft. Das Heldbild bewegt sich nämlich mit Pixel und das Scrolling kann dagegen nur in Feldern. Außerdem wird die Position vom Herobild durch den Bildschirm bewegt und das muss gleichzeitig ausgeglichen werden. Manchmal wird das Heldbild weiter verschoben als eigentlich soll.

Spätestens ab hier wird's irgendwie happig. Tatsächlich ist das das letzte Problem was es gibt. Dannach wäre das Pixelmovement denke ich angenehm spielbar.

[Bex]

Hättest du jetzt den VX Ace hätte ich vorgeschlagen ein Pixelmovement Script zu nutzen oder beim Eventbefehl Set Move Route
bei Script move_to(x,y) eingegeben.Damit kann man ein Char oder Event pixelgenau versetzen. (Solange das Event dann aber nicht genau auf dem Mapgrid ist ignoriert es die Begehbarkeiten. Die Probleme beim Mapscrollen würden aber wegfallen.

Edit: Konnte man beim RM2K nicht Pictures standardmässig an die Map Tackern? Gabs da nicht so ein Kontrollkästchen bei dem Befehl?

[Stray]

Edit: Konnte man beim RM2K nicht Pictures standardmässig an die Map Tackern? Gabs da nicht so ein Kontrollkästchen bei dem Befehl?

...

Das stimmt. Eigentlich.

Wenn man das Kontrollkästchen "Picture Scrolls with Map" aktiviert, bleibt das Bild an seiner Position. Das würde super funktionieren. Allerdings muss das Bild aufgrund der Animationen jede 0.0 Sekunde neu geladen werden. Das bedeutet, dass das Bild immer wieder auf's neue an seine Stelle gesetzt wird, ohne dass es an seiner vorherigen Stelle stehen bleiben würde.