Hl Ks

[Beril]

Jo high erstemal,
also mein problem ist doch etwas komplexer und nach ca. 2 Monaten rumprobieren komm ich zu keinem Ergebnis und frag daher mal nach:

Ich mache mit meinem Kumpel hauptsächlich zum Zeitvertreib ein Half Life Fan Fic. Game. Wir haben schon angefangen und eine Maussteuerung gescriptet. wir bleiben zwar bei der RPG-Maker typischen Perspektive, wollen aber scripten, dass man wo man mit der Maus hinklickt auch die Kugel hinfliegt ohne Wände zu übergehen. So weit so gut. das Kästchen zu ermitteln wo man reingecklickt hat is ja kein prob. allerdings wollen wir die Kugel ja dazu bringen direkt auf das angeklickte Kästchen zuzufliegen dh sich direkt dort hinzubewegen. How the f*ck solln wir das hinbekommen. Funktionen à la f(x)=m*b und so klappen nicht, da der Maker keine Kommastellen beherrscht. ich hoffe ihr könnt uns helfen, denn wir wollen ja nicht für jedes Kästchen n eigenes Mov event machen (300 Move Events).

Tja also wahrscheinlich ist die Lösung ganz einfach aber bitte kommt jetzt nicht mit "Frag doch ab ob x/y ungleich x/y des Ziels sind und lass dann entsprechend einen UP oder Down bewegen". Das gibt einfach eine ungenaue bahn der Kugel, was auch bewirken würden, dass man z.b. um Ecken schießen kann. Also plz help us.

greetz Beril

[eisRegen2k4]

um sowas zu berechnen brauchst sinus usw...
das kann der rpgmaker auch nich^^
oder wie darf ich mir das vorstellen?

[Heaven]

Soll unglaublich schwer sein ei Pic von der Mündung der Waffe zur Koordinate x und y zu bewegen...

[Beril]

Nö das wäre ja nicht das problem. Die Kollisionsabfrage ist eher so ein problem. Und Sinus hat damit eigentlich nix zu tun. Wie gesagt: es würde mit ner Funktion funzen aber wie. ohne Kommastellen?

[Dhan]

Heaven hat das wichtige eigentlich schon gesagt öhm aber...
das mit den Kommastellen stimmt nicht

der Maker kann zwar nicht direkt Kommastellen speichern, es ist aber kein Problem, ganz einfach eine Zehnerpotenz zu speichern!

wenn man beispielsweise 3 Kommastellen haben will macht man einfach
1,284 = 1284 * 10^-3

oder anders ausgedrückt, man hat 2 Variablen, eine speichert 1284, die andere -3

[Beril]

nur das bringt mich ja insofern nicht weiter, dass ich immernoch keine Kommastellen ausgegeben bekomme. aber auch das ist ja nicht das Problem. Ich muss im Prinzip nur ne Kollisionsabfrage eines Pictures machen und how the f*ck soll ich das hinbekommen?

[Teufelsauge]

Hab mal so was ähnliches gemacht (benutzte es aber für ne KI) würde sagen du lässt ,am besten nen char in form einer Kugel, sich direkt auf den Gegner hizubewegen heißt du klickst und der Char bewegt sich genau auf den gegner zu (auch diagonal) dann machste viele Forks so á la if XChar= Xwand then stop movement. vielleicht funzt es so wenn net sry.

[Phönix Tear]

Hmm, ich glaub das ist nicht das, was hier gewollt ist...
Wenn man ein Char benutzt sieht das einfach zu eckig aus. Außerdem soll sich die Kugel ja genau dahin bewegen wo der Mauszeiger ist und zwar ohne Umwege...
Außer das mit dem Picture fällt mir da auch nichts mehr ein...

[Lukas]

Hab mal so was ähnliches gemacht (benutzte es aber für ne KI) würde sagen du lässt ,am besten nen char in form einer Kugel, sich direkt auf den Gegner hizubewegen heißt du klickst und der Char bewegt sich genau auf den gegner zu (auch diagonal) dann machste viele Forks so á la if XChar= Xwand then stop movement. vielleicht funzt es so wenn net sry.
Das geht nicht schräg über Felder, und das ist, was Beril will.

Ich würde versuchen, es so zu machen, dass die Kugel in Schussrichtung fliegt und parallel ein unsichtbares Event (below Hero) über den "zackigen" Kurs (musst du zwar einiges für berechnen, aber es sollte möglich sein). Sobald das irgendwo gegen stößt, brichst du die Bewegung des Bildes ab.
In den internen Berechnungen fliegt die Kugel dann zwar immer noch einen unschönen Kurs mit Ecken, aber die graphische Darstellung ist schöner.
Ich habe keine Ahnung, ob das funktioniert, und kann es nicht nachprüfen, da ich momentan keinen Maker zur Hand habe. Das ist also nur eine Theorie, wie es funktionieren könnte.

[Beril]

musst du zwar einiges für berechnen, aber es sollte möglich sein

Tja und da liegt halt das Prob. Es geht nicht um die Optik, sondern im Moment noch um die Technik :( Wie soll ich das berechnen?

[Dhan]

Du rechnest die Felder aus, die es berührt (16n + 0-15 sind die koords), prüfst, welche terrainart sie sind und lässt entsprechendes passieren (natürlich muss dann das terrain so machen, dass undurchlässiges gebiet eine bestimmte terrainart hat)

[Don_Alexandro]

Ich hab mal so was ähnliches gemacht.
Solltest du zu keinem gescheiten Ergebnis kommen, kann ich dir ein Script schicken, indem man mit Maus in 8 Richtungen schießen kann. Das ist zwar nicht genau das, was du brauchst, aber das funktioniert auf jeden Fall!

Trotzdem viel Glück mit eurer KS Variante!

[Phönix Tear]

prüfst, welche terrainart sie sind
Ich glaub eigentlich nicht, das das so gut funktionieren wird. Bei Wänden schon, aber sobald größere Sachen aus dem Upper-Layer dazukommen versagt die Technik, da sie ja kein Terrain haben. (Außer wenn die Kugel ruhig mal über einen Schrank drüberfliegen darf und dahinter eine Maus trifft ^^. Natürlich ist das nur so, wenn Upper-Layersachen mitten im Raum stehen. Stellst du sie alle an eine Wand ist das auch relativ egal... Aber da ich denke, dass du nicht alles an die Wand klatschen willst...)
Ich würde einfach 2 mal kurz hintereinander die X und Y Koordinate des Schusses bestimmen. (zwischen den beiden Abfragen kommt dann immer die Bewegung des Schuss-Events) Weicht eine der Koordinaten von der vorigen ab, weißt du, dass sich der Schuss bewegt hast, also startet das Event von vorne. Hat sich keine der Variablen verändert wird das Event automatisch beendet. Da ist nun allerdings das Problem, das der Schuss auch gegen z.B. einen tiefen Tisch knallen würde, da der auf "Same Level As Hero" steht, wesshalb das Event ihn nicht passieren kann und daher der Schuss stecken bleibt...

[Dhan]

Für Upper Layer macht man es einfach so, dass man im Lower Layer für eine Bodentextur 2 Chipsetplätze nimmt, die identisch aussehen aber eine unterschiedliche Terrain ID haben und eine eben blockt


deine Methode ähm... wie soll das funzen? Ein Picture wird von Same Level as Hero nicht aufgehalten!

[Beril]

Okay danke ich werde mal die Terrain-Sache ausprobieren

[Phönix Tear]

OK, an das mit dem Boden hab ich nicht gedacht. Dann muss man halt alle verwendeten Böden gleich doppelt haben, aber das ist ja auch egal.



deine Methode ähm... wie soll das funzen?
Wie ja schon einige Posts vorher gesagt wurde, wird ein Event unter dem Schuss entlangbewegt. Der Schuss bewegt sich gerade auf den Helden zu, das Event eben im für den maker typischen zickzack Weg. Stößt das Event irgendwo gegen oder kommt einfach nicht weiter, gibt dieses den Befehl an das Picture event, sofort das Picture zu löschen und die Kollisionsabfrage zu beenden.
(Ich schätze ich hab dich allerdings falsch verstanden... (vieleicht aber auch du mich ^^))

[Beril]

Du kannst aber nicht sagen "Move Event immer under Picture.
Wenn das ginge, dann wär ich froh und müsste diesen Thread nicht machen ^^°

[Dhan]

Das Problem ist die Verzögerung des Events...

ansonsten, jepp, ich hab dich falsch verstanden ^^ (Beziehungsweise den Text net ganz sorgfältig gelesen)

[Deathball]

Na dann versuchen ich mal auch was konstruktives hier beizutragen(fällt mir zwar schwer, aber versuchen kann ich's ja mal... ;) ):

Also, wenn ich dich richtig verstanden hab ist das einzige Problem was du derzeit noch hast die Kollisionsabfrage.
Ich würde nicht nur eine Terrain-ID(für Wände) miteinbeziehen, sondern alles was den Schuss blockieren kann ein Event verpassen. In der Kollisionsabfrage fragst du dann ob x- und y-Koordinate des Schusses mit der x- und y-Koordinate des blockierenden Gegenstandes übereinstimmt.
(natürlich könntest du es auch ohne Events machen und die x/y-Koordinaten dir merken und so abfragen, aber mit Events ist es meiner Meinung nach leichter)

Da du Szene-Koordinaten benutzt musst du evntl. die Koordinaten der Events "korrigieren"(damit der Schuss nicht in der Mitte des Schrankes, sondern schon am Anfang des Schrankes aufgehalten wird), aber ich denke nicht das das größere Probleme verursacht...


Hoffe meine Idee hilft dir...
cya
Deathball

[Dhan]

Nette Idee im Ansatz, wenn du aber größere Maps machst mit ziemlich vielen Hindernissen dann wird die Methode seeehr aufwendig

[Beril]

Ihr verstehts irgendwie alle falsch ^^
Ich möchte nicht die kollisionsabfrage eines Events, sondern eines Pictures bzw eine gute möglichkeit ein Event direkt auf das Ziel zuzubewegen. Wenn du verstehst ^^

[Dhan]

Wozu ein Event?


Und Kollisionsabfrage eines Pictures, genau das meinte ich


hmmm ich hab aber vergessen, die Szene-Koordinatenumrechnung für größere Maps zu sagen ok...

Nummer 1: Gespeichert werden von dem Picture die Koordinaten auf der Karte, allerdings Pixelweise sowie der Vektor
Nummer 2: Die Koordinaten können praktischerweise gleich auf den Hero gesetzt werden bzw auf seine Mapkoordinaten mal 16 minus 8
Nummer 3: Vektoren sind unabhängig von der Fortgeschrittenheit eines Koordinatensystems, d.h. für sie kann man die Scene-Werte nehmen.
Ein Vektor sieht dann so aus dass du einfach die Scene Werte des Helden und des Ziels speicherst, was schonmal die Richtung des Vektors angibt
zur Länge komme ich nacher
Nummer 4: Die Scene Werte des Pictures rechnest du für jeden "Schritt" des Pics auf seinem Vektor so aus:
Pixelwert des Helden bestimmen (Heldenkoords * 16 - 8), davon den gespeicherten Pixelwert des Pics abziehen, anschließend den Scene-Wert des Heldens bestimmen und die Pixelwertdifferenz von selbigem Abziehen, schon hast du den Scene-Wert des Pics.
Nummer 5: Bewegung
Die Bewegung solltest du in winzigen Ticks machen, d.h. jeden Tick wird das Bild auf eine neue Position gesetzt die jeweils um den Vektor verschoben ist.
Ein Vektor sieht ungefähr so aus: (5|2), d.h. 5 Pixel in Richtung X und 2 in Richtung Y
das Problem bei der Ausrechnung des Vektors ist die Länge, die muss nämlich auf einen bestimmten Wert (seine Geschwindigkeit durch die Zeitdauer eines Ticks) gebracht werden.
Das sieht dann so aus: Vektor0 = ursprünglich bestimmter Vektor mit falscher länge, Vektor1 = Vektor mit Richtiger Länge, x0/y0 = X/Y-Wert von Vektor0
Vektor 1 = Vektor0 * Geschwindigkeit des Projektils / Zeit eines Ticks / |Vektor0|

|Vektor0| = sqrt(x0²+y0²)
soa, hier ist das Problem, sqrt, also Squareroot/Wurzel.
Wurzeln kann man im Maker so ermitteln, dass man einfach prüft, welche Zahl mal sich selbst der Zahl unter der Wurzel am nächsten ist

und da sind wir schon bei einem weiteren Problem, sowas würde Kommazahlen ausspucken. Folglich musst du folgendes machen:
Die gespeicherten Werte müssen um einen bestimmten Faktor (Zehnerfaktor) erhöht sein, z.B. 100. Wenn das Pic angezeigt wird, wird der gespeicherte Wert durch diesen Faktor geteilt.

Soa, ich hoffe mal, du hast verstanden, was ich geschrieben habe ^^

[Beril]

Danke für die Super erklärung.
Allerdings habe ich bedenken bei Nummer 1 ^^ wie soll ich denn die koords eines Pics Speichern?

[Dhan]

Du bastelst einen Parallel Process der die Koords speichert und jeden Tick das Bild anzeigt auf den passenden Koords, Move Event lässt du ganz weg

[Dennis]

Wurzeln kann man im Maker so ermitteln, dass man einfach prüft, welche Zahl mal sich selbst der Zahl unter der Wurzel am nächsten ist.
HA!
Sogar mit nachkommastelle:
Rechtsklick -> Ziel speichern unter (http://mitglied.lycos.de/repko/wurzel.rar)

Ja, mir war langweilig!
(auf die Idee bin ich aber selber gekommen.... die is mir glaube ich während nem Cooper-Test gekommen...)