[Variablen] Relative Bildposition in XY-Koordinate umwandeln

[Bex]

Ah jetzt verstehe ich, relative x und Y heisst beim VX und Ace einfach nur ScreenX und ScreenY. Hatte mich nur gewundert zuvor.
Ja es wäre hilfreich zu wissen was er vorhat, um zu sehen ob es nicht einen anderen oder einfacheren weg für das gibt was er vorhat.Wobei die oben beschriebene Funktion funktionieren sollte^^.

[Stray]

@Kelven:

Ich möchte mich wieder mal an einem Jump'N'Run Spiel versuchen, allerdings mit Pixelmovement, da viele das ungenaue auf Feldern basierende nicht spielen wollen. Meistens wird mir dann das Pixel Movement Script von Simon empfohlen. Der Aufwand dafür scheint mir aber so immens hoch zu sein, weil man dafür die ganze Umgebung und alle seine Gegner per Pictures animieren und bewegen müsste.

Was ich machen möchte ist etwas kompliziert zu erklären:
Ich habe mir gedacht, dass man ein Script machen kann, in dem nur der Held als Bild animiert wird, hauptsächlich damit Pixelmovement in der Steuerung möglich ist. Unter dieses Bild wird permanent ein Ereignis gesetzt, das dann als Orientierungspunkt für den Standpunkt des Helden dient. Überschreitet das Bild dann ein Feld zu mehr als 50% (oder höher) wird das Ereignis auf das am nächsten liegende Feld gesetzt.

Es wäre eine pflegeleichtere Art für Pixelmovement im RPG Maker, denke ich.


@Djeurissen:
Hmmm... ganz klar ist mir die Lösung nicht. :/

[djeurissen]

Was verstehst du den nicht?

[Stray]

Was meinst du mit den "Standardwerten"?
Außerdem ist mir nicht ganz klar, wieso das so funktionieren soll bzw. worin in dieser Rechnung die Logik besteht. (Außerdem erschwert mir deine Rechtschreibung und Grammatik das Verstehen. Ohne es böse zu meinen.)

@Kelven:
Dein erster Vorschlag ist schon sehr nah dran an einer Lösung, aber jetzt braucht es nur noch ein System, dass das ganze auch in Bereichen außerhalb der 20x15 Grenzen einer Map funktionieren lässt.
Da mein Bild die ganze Zeit vom Bildschirm verfolgt wird, lässt sich daraus ja evtl. auch irgendwie feststellen wo sich das Event befindet.

@Bex:
Danke, das funktioniert auf einer 20x15 Map schon sehr gut.


Nun gibt es eine gute und eine schlechte Nachricht:

Die Gute ist, dasss es auch auf einer größeren Map mit Scrolling usw. wunderbar funktioniert! Danke schon mal!
Die Schlechte ist allerdings, dass das Event viel früher auf links/oben gegenüber liegende Felder wechselt, wenn man es mit den Pfeiltasten bewegt.

PROBLEM

Das Kind ist hier das Ereignis, dass sich unter dem Bild befindet. Das Bild ist das weiße Quadrat. Man kann es mit den Pfeiltasten bewegen.
Bild 1:
Wird das Bild nach links bewegt, reicht es schon, wenn dieses 1 Pixel nebenan liegt, das Ereignis
springt sofort auf das links nebenan liegende Feld.
Bild 2:
Bewege ich allerdings das Bild nach rechts, springt das Ereignis nicht auf die rechte Seite. Erst wenn es...
Bild 3:
...ganz auf dem Feld liegt.
Bild 4 & 5:
Selbiges gilt für Hoch und Runter. Bewege ich das Bild nach unten springt das Ereignis nicht auf dieses
Feld bis das Bild komplett auf dem Feld liegt. Bewege ich das Bild nach oben, brauchte es nur einen
einzigen Pixel bis das Ereignis nach oben hüpft.

Mein ideales Ziel wäre nun, dass das Ereignis bereits/erst dann auf dem Feld liegt, wenn das Bild die daneben liegende Fläche zu mehr als 25% übertritt bzw. 4 Pixel.

[Bex]

EDIT:
Zeigst du das Bild mit der Option Center oder Linke obere Ecke an?
Es muss Center sein. Wenn dann immer noch ein Fehler da ist, liegt es an meiner Rechnung.
Ich glaube das liegt daran das das Event oben Links ja nicht die Screenkoordinaten x/y 0/0 hat sondern glaube ich 16/16 im Ace^^ also bei dir wohl 8/8.
Also die Screen Y und X beim Event oben um -8 jeweils rechnen vor dem umrechnen in map koordinaten.

Nun muss du nur noch schauen ob es schon klappt oder ob du die umwandlung von Screenvariablen zu Map Variablen noch rundest fürs fine tuning.

Edit2: Zusätzlich wären Bilder deines gesammten Eventcodes vorteilhaft.
Finde ich cool das du sowas mit so einfachen mitteln bauen willst.

Wofür braucht man das Event unter dem Bild?????????????????????????????

[Bex]

So hab meinen Post editiert, lässt sich leider nicht auf neu stellen.
Push^^ Oben deine Antwort.

[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.