X/Y-Radius berechnen

[R.D.]

Geht viel einfacher.

Wenn du abfrage wilslt ob zb ein Held in einem Radius ist machst du das:

Objekt X - Held X
Objekt Y - Held Y
Wenn Objekt X oder Y im Minus bereich, dann *-1
Objekt X * Objekt Y

Dann abfrage ob X in einem bestimmten Bereich ist, zb bei 2, würde die Bedingung war, wenn der Held 2 oder weniger Felder weit weg steht:
Meine Version, ist dann kreisförmig. (Ist imho für ein AKS realistischer, vorallem mit Scene X und Y)

Maker Code:

- SCRIPT -
<> Change Variable: [294] = X position on map (tiles) of event #1
<> Change Variable: [295] = Y position on map (tiles) of event #1
<> Change Variable: [294] -= X position on map (tiles) of hero
<> Change Variable: [295] -= Y position on map (tiles) of hero
<> Fork Condition: If Variable [294] <= -1 then ...
. <> Change Variable: [294] *= -1
. <>
: End of fork
<> Fork Condition: If Variable [295] <= -1 then ...
. <> Change Variable: [295] *= -1
. <>
: End of fork
<> Change Variable: [294] += V[295]
<> Fork Condition: If Variable [294] <= V[385] then ...
. <> Comment: WAHR
. <>
: End of fork

...

See, it's really that simple^^ Das Ganze geht auch mit Scene X und Y, musste halt größerer Bereich machen :/

[Engel der Furcht]

Ah,R.D.s scheint mir am simpelsten.
Vielen Dank.

[MagicMaker]

Den Wert umzukehren, also die *(-1)-Zeilen, hab ich mir erst nachher
gedacht, das war nachdem ich mir dachte "das muss doch andersrum sein",
weil ich da nicht nach Abstandslogik sondern Koordinaten ging und deswegen
lieber die negativen Werte oben und links wollte, auf die andere Art sind sie
ganz klar andersrum.

hero=27 - event=23 = 4, er steht 4 Felder weiter links, nach meiner
Rechnung SOLLTE es so gehen, dass nachher die Zahl umgedreht wird,
also -4 wird, aber ich musste es natürlich irre verdreht wie ich bin, wenn
ichs nicht praktisch teste, in die falsche Zeile schreiben, denn das sollte
erst nach beiden Zeilen passieren und nicht dazwischen:

27 - 23 * -1 = -4
27 * -1 - 23 = -50

Da aber das von R.D. eh wirklich simpler und besser scheint, ist es eh egal.

[Kelven]

@R.D.
Irgendwie verstehe ich deine Methode noch nicht. Zuerst werden die Koordinaten voneinander abgezogen und das Ergebnis gegebenenfalls mal -1 genommen. Das ist soweit klar. Dann werden die beiden Abstände addiert. Mit welchem Wert vergleichst du sie danach?

Nehmen wir mal an, der Gegner hätte die Koordinaten (10,10) und der Held die Koordinaten (6,6). Nach deinem System hätten wir dann zunächst als Ergebnis zweimal 4. Beides addiert gibt 8. Nun wollen wir aber den Abstand 5 haben, wie kommst du jetzt von der 8 auf den? Und inwiefern ist das System kreisförmig?

[Stoep]

R.D. prüft bei seiner Methode nach, ob der errechnete Wert gleich oder kleiner ist als die Varialbe V[385]. Diese Variable muss vorher vom Skripter auf einen bestimmten Wert gesetzt werden. Je höher dieser Wert, desto größer auch der Radius. Ich habe es auch erst mit ein paar Werten proberechnen müssen um es zu verstehen.
Stellen wir uns einfach mal vor, wir hätten die Variable V[385] auf "8" gesetzt:

G [10,10] ; H [6,6] => 4+4 = 8 ==> Der Gegner ist im Radius des Helden!
G [9,10] ; H [6,6] => 3+4 = 7 ==> Der Gegner ist im Radius des Helden!
G [12,8] ; H [6,6] => 6+2 = 8 ==> Der Gegner ist im Radius des Helden!
G [11,10] ; H [6,6] => 5+4 = 9 ==> Der Gegner ist nicht im Radius des Helden!

Oder probiers einfach mal selber aus. Ist ja gar nicht viel Aufwand zum skripten^_-

Gruß
Stoep

[Kelven]

Ja stimmt und nach welcher Formel müsste dann der Wert der Variable berechnet werden? Es wäre ja nicht praktisch, wenn man bei größeren Entfernungen erst rumprobieren müsste. Aber ich denke mal diese Technik und der rechteckige Radius nehmen sich nicht wirklich viel, Tilemovement ist ja auch alles andere als genau. In der Praxis wird man nicht viel davon bemerken, dass die Randfelder nicht berücksichtigt werden.

[R.D.]

Die Variable V[385] ist wie Stoep sagt nur ein Setwert, der vom Benutzer Entwickler bestimmt werden kann, wen ndu 2 eingibst, dann muss der Held 2 oder weniger Felder weit weg sein und man ist "Wahr". (Ich habe das aus meinem Projekt entnommen und ein wenig verändert und dabei vergessen, dass ich da 2 varis vergleiche xD)


Hero (10,4)
Obj (5,5)

X: 5-10 = -5 * -1 = 5
Y: 5-4 = 1

X + Y = 6

Das tuhe ich, damit ich im "UMKREIS" abfragen kann, das hielt ich damals als ic hes gebraucht habe für besser, da man sich ja auch von Schräg nähern kann, usw :/
Und ich sagte ja, das muss man dann auf Scene X und Y abstrahieren. Dann kann man die V[385] berechnen lassen indem man das ganze umkehrt und nicht mehr nachschaut ob der Held in ein der Nähe eines Objektes ist, sondern ob das Objekt in einem bestimmten Umkreis ist, alles möglich
(Btw ist das ein wirklich netter Trick, den man im Studium lernt (was für mich ein wenig zu spät kam xD)

Auf zur Nato!/o

Edit:
Sry, mehr Zeit habe ich das nicht zu erklären und das Dull hat btw das Gleich wie ich, nur aus Held-Sicht xD (das hat er mir gerade unter Tränen in einer Pn gebeichtet)

[niR-kun]

Man kann auch einen Kreisradius nehmen, da würde ich aber dann nicht mit X/Y-Koordinate des Helden/Gegners sondern mit der Szenen-Koordinate des Helden/Gegners rum hantieren.

Dabei muss (xH − xG)^2 + (yH − yG)^2 <= r^2 wahr sein, damit der Gegner im Angriffsbereich ist.

(Legende:
xH, yH : Szenen-Koordinate des Helden
xG, yG : Szenen-Koordinate des Gegners
r : Radius in Pixeln (in dem Falle: r=5*16=80)

Code:

<>Var[xxxx:xTemp] SET,Hero SceneX
<>Var[xxxx:xTemp] -, Gegner SceneX
<>Var[xxxx:xTemp] *, Var[xxxx:xTemp]
<>Var[xxxx:yTemp] SET,Hero SceneY
<>Var[xxxx:yTemp] -, Gegner SceneY
<>Var[xxxx:yTemp] *, Var[xxxx:yTemp]
<>Var[xxxx:rCheck] SET, Var[xxxx:xTemp]
<>Var[xxxx:rCheck] +, Var[xxxx:yTemp]
<>Var[xxxx:rHoch2] SET, Var[xxxx:r]
<>Var[xxxx:rHoch2] *, Var[xxxx:rHoch2]
<>Fork Conditions: Var[xxxx:rCheck] <= Var[xxxx:rHoch2]
 <>Comment: WAHR
:ELSE Case
 <>Comment: FALSCH
:END Case
<>

Ich weiß aber nicht wie fehleranfällig und wie schnell das ganze im Maker ist,
am besten und schnellsten ist der Rechteck-Radius.

Wenn man einen Kreisradius nehmen will, sollte man für die Berechnung den PowerPatch nehmen, da es da schneller geht (arbeitet mit Gleitkommazahlen in der schnelleren und genaueren FPU-Erweiterung des CPU, im Gegensatz: der Maker nur mit Ganzzahlen im CPU).

[Kyuu]

@R.D.: Dein Ansatz ist rautenförmig und nicht kreisförmig. Bei genügend großen Abständen kann sich der Unterschied auch im Kästchenraum des RPG Makers deutlich bemerkbar machen. Wer eine Kreisform will ist mit dem Satz des Pythagoras: a²+b²=c² besser beraten, den niR-kun in seinem Ansatz anwendet.

Ich weiß aber nicht wie fehleranfällig und wie schnell das ganze im Maker ist,
am besten und schnellsten ist der Rechteck-Radius.

...

Inwiefern sollte es fehleranfällig sein?

Wenn man einen Kreisradius nehmen will, sollte man für die Berechnung den PowerPatch nehmen, da es da schneller geht (arbeitet mit Gleitkommazahlen in der schnelleren und genaueren FPU-Erweiterung des CPU, im Gegensatz: der Maker nur mit Ganzzahlen im CPU).

...

Wie bitte?