[Variablen] Relative Bildposition in XY-Koordinate umwandeln

[Bex]

Was genau möchtest du denn erklärt haben? Was meinst du mit relative Variable?

[djeurissen]

Einfach den Befehl bei VariableOprations unter Sprite Screen-Relative X und Y

[Kelven]

@djeurissen
Ja, das ist richtig. Am besten Stray sagt mal, was er mit dem Bild eigentlich vorhat. Vielleicht gibt es für das Problem noch eine einfachere Lösung, als über die Koordinaten zu gehen. Auf den neuen Makern könnte man alternativ zum Bild vielleicht auch ein großes Charset nehmen.

Screen-X und Screen-Y liefern die Pixelkoordinaten eines Events. Sie werden meistens dazu genutzt, um ein Picture zu setzen.

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