Fortgeschrittenes Problem über Movements

Servus an alle^^

Bei meinem aktuellen Projekt ist ein Problem aufgetreten.
Normalerweise löse ich meine Probleme alle selber, aber an diesem beiß ich mir momentan die Zähne aus.
Das ist mein Problem:

Ich habe 2 Events. Beide laufen völlig gleich. Das 2. wird vom 1. Event gesteuert und macht exakt die selben Move-Befehle (sie stehen aber nicht auf der selben y-Achse).
Das Problem ist folgendes: Das 2. Events soll stehenbleiben, wenn das 1. Event gegen ein Hinderniss läuft.
(Das ist eigentlich nicht besonders schwer. Man kann das mit Switches in den Move-Events machen oder einfach mit x und y Koordinaten, die man dann miteinander vergleicht.)
Aber das 2. Event muss nicht nur stehenbleiben, sondern darf erst gar keinen einzigen Schritt mehr tun.
Mit meinen Mitteln bleibt das 2. Event nach einem Schritt stehen, nachdem das 1. gegen das Hinderniss geprallt ist. Ich muss es aber schaffen, dass das 2. Event diesen einen Schritt erst gar nicht tut, sondern im gleichen Moment stehen bleibt, in der das 1. Event stoppt.

Dieses Problem ist ein wenig schwieriger als Standard-08/15-Probleme wie "mein Held kann nicht laufen, wenn ich auf Map xy unterwegs bin".

Ich hoffe ihr könnt mir trotzdem helfen (vielleicht würd ich auch selber nach einer Zeit drauf kommen, aber ich hink jetzt schon hinter dem Projekt-Struktur-Plan her).

Vielen Dank schon mal im Voraus
http://www.multimediaxis.de/images/s.../old/sm_12.gif http://www.multimediaxis.de/images/s.../old/sm_12.gif http://www.multimediaxis.de/images/s.../old/sm_12.gif
G.V.H.

nya, ich würde hingehen, und kein feste moveevent mehr auf das 2.te Event einstellen, sondern in diesem lediglich abfragen, wie sich die Position des 1. Events verändert hat, und dementsprechend das zweite bewegen.

Zitat:

---

Zitat von DR_Zeph

nya, ich würde hingehen, und kein feste moveevent mehr auf das 2.te Event einstellen, sondern in diesem lediglich abfragen, wie sich die Position des 1. Events verändert hat, und dementsprechend das zweite bewegen.

---

Leider müssen aber beide Events absolut gleich ablaufen, sonst gibts viele Probleme:( .
Und wenn ich erst Abfrage, ob Event 1 sich bewegt, bevor ich Event 2 den Move-Befehl geben, dann zieht Event 2 nach und das darf nicht passieren.

Versuch das ganze mal so,

http://img49.imageshack.us/img49/8211/code8qe.jpg

hat zurzeit noch den Bug, das wenn das MoveEvent des ersten Events regulär gestoppt wird, also das Move zu ende ist, das zweite Event noch ein Tile weiter bewegen würde. Ließe sich durch nen Switch aller "Bewegung beendet" am MoveEvent des ersten Events und ner zweiten Eventseite beim zweiten Event beseitigen...

Die Idee, die Bewegung direkt nach der Erteilung des Bewegungsbefehls mit Pics zu testen, ob das 1. Events sich bewegt, damit das 2. sich richtig verhält, hatte ich so ähnlich auch schon.

Dummerweise funktioniert dieses System nur, wenn der Held sich nicht bewegt. :(
Denn wenn er sich bewegt (und damit auch der Bildschirm), verändert sich der Bezugspunkt für die Berechnung der ("Set Variable x to pics x") und das 2. Event würde weitergehen, obwohl das 1. immernoch stehen würde.
Ganz einfach, weil die alten Variablen (Held 1 X usw.) nicht mehr mit den aktuellen übereinstimmen (weil der Bezugspunkt sich bewegt hat), denn damit berechnet ja dieses System, ob das Event steht oder nicht.
Aber diese Methode ist auf jeden Fall besser, als mit den Koordinaten der Map zu schauen, ob das Event sich bewegt.

Aber schon mal vielen Dank für deine Mühe^^ http://www.multimediaxis.de/images/s.../old/sm_12.gif
Man kann wirklich sehen, dass du schon einiges an Erfahrung hast.

Ich muss aber leider immernoch dieses Problem lösen:(

Bau eine Art Bullet ein, welches maximale Geschwindigkeit besitzt. Vor jedem Schritt schießt das erste Event dieses Bullet von sich aus ein Feld nach vorne und nur, wenn sich das Bullet bewegt hat, bewegen sich auch die beiden Events

übelste KI's baun, aber an son problem scheitern...^^
und dann auch noch über die probleme der kleinen makerer
lustichmachen... schlimm schlimm...

also wie dhan schon sagte ein event mit maximaler geschwindigkeit
in die gewünschte richtung bewegen lassen... natürlich sollte das
auf gleicher höhe wie die beiden zubewegenden figuren haben..^^
das bringt wirklich nur eine winzig kleine verzögerung..
(hab für jemanden ein Reitscript gebaut, das auf dieser überlegung
beruht, und da gibt es keinerlei bemerkbarer verzögerungen...)
denn man kann bereits nach einen wait von o.o die position des
events abfragen... :
vari x set event x pos
vari y set event y pos
moveevent: event in ner richtung
wait o.o
vari x minus event x pos
vari y minus event y pos
wenn x anders null
dann bewegung der beiden events
ansonsten
wenn y anders null
dann bewegung der beiden events
ende

mfg
üH

Zitat:

---

Zitat von Dhan

Bau eine Art Bullet ein, welches maximale Geschwindigkeit besitzt. Vor jedem Schritt schießt das erste Event dieses Bullet von sich aus ein Feld nach vorne und nur, wenn sich das Bullet bewegt hat, bewegen sich auch die beiden Events

---

:D
Diese Technik ist mir leider auch schon bekannt^^ (schließlich funktioniert so die Wegfindung in RVB 1 und 2).
Das Problem ist nur, dass ich für jeden Bot jetzt schon 3 Events habe, die allein für die Wegfindung arbeiten, alle Layers belegt sind und es zu Überschneidungen kommt, wenn ich noch mehr Events reinbaue (die anderen 3 Events kann ich leider nicht für diese Aufgabe benutzen, da diese ein eigenes System benutzen).
Meine A.I.-Gen. 6 ist nämlich ein wenig komplexer als andere, deswegen muss ich es schaffen, das Problem ohne weiteren Events zu lösen, sonst brauch ich nur für die Bots (insgesamt) über 50 Events!!!

Aber schon mal vielen Dank für eure Unterstützung^^

Zitat:

---

Zitat von übelster Held

und dann auch noch über die probleme der kleinen makerer
lustichmachen... schlimm schlimm...

---

Ich will mich nicht über andere lustig machen (ich hab schließlich auch 2 Jahre ohne Internet und somit irgendwelche Hilfe gemakert, und meine Projekte sahen dementsprechend aus;) ).
Mit 08/15-Fragen meine ich Fragen, die fast täglich vorkommen. Auch ich hatte das Problem in meinem 1. Projekt, dass sich mein Held nicht bewegt hat:) .

was machen denn die 3 events, dass du sie nicht mit call
direkt ansprechen kannst, oder sie auf pp stellen und mit nen switch
aktivieren kannst und sie somit nicht bewegen darfst???

ne andere möglichkeit wäre es die felder die man nicht betreten kann
mit ner speziellen id zu versehen und die dann abfragen...
da müsste man aber zusätzlich noch abfragen, ob ein anderes event
vor einem steht... ist halt ne buckel-variante...

wahrhaftig, das mit dem Helden und den sich dadurch veränderten Koordinaten hab ich völlig vergessen und nicht bemerkt, da ich es auf einer 20*15 Map ausprobiert habe.

Nya, als nächstes würde ich auch eine Art Bullet einbasteln, die jedoch auf den TerrainID's arbeitet und somit keine zusätzlichen Event's benötigt. Nya, bevor ich mir gedanken dazu mache, klär mich nochmal kurz auf, in was für einer Situation du das ganze überhaupt benutzten willst und wie sie das MoveEvent für das erste Event zusammensetzt.

Edit: @üH, schon zum zweiten mal heute...

Zitat:

---

Zitat von übelster Held

was machen denn die 3 events, dass du sie nicht mit call
direkt ansprechen kannst, oder sie auf pp stellen und mit nen switch
aktivieren kannst und sie somit nicht bewegen darfst???

ne andere möglichkeit wäre es die felder die man nicht betreten kann
mit ner speziellen id zu versehen und die dann abfragen...
da müsste man aber zusätzlich noch abfragen, ob ein anderes event
vor einem steht... ist halt ne buckel-variante...

---

Die 3 Events sorgen, dafür dass alle Bots sowohl nicht gegen die Wände laufen, als auch einen richtigen Weg zu ihrem Ziel zu finden.
Das mit der ID funktioniert leider auch nicht, denn wenn Event 1 gegen ein Hinderniss läuft kann ja Event 2 (weil nicht auf der gleichen Position) freie Bahn haben.
Aber diese beiden Events müssen leider immer in der gleichen Position zueinander stehen. :(
Beispiel: Event 1 ist der untere Teil einer Person, Event 2 ist der obere. Sähe schon komisch aus, wenn die Person mit den Beinen gegen ein Hinderniss prallt und der Torso (Brustkorb) sowie Arme und Kopf noch weiter gehen^^.
Außerdem kann Event 2 (also das obere) nicht mehr gegen Hindernisse prallen (wegen SlipThrough), deswegen braucht es ja das 1. um zu wissen wos hängt.
Das 2. Events ist wegen der Isometrischen Ansicht im Maker auf SlipTrough.

@ zeppi: hab halt nen ganz schnellen finger..XD
(und dabei musste ich die 2te nachricht hier 2mal schreiben, weil
mein firefox abgekackt ist...^^)

@ Veronan...(namenverschandeln ist so schön...^^)
laufen die 3 events die ganze zeit???
denn die werden bestimmt auch ihre aufgaben erfüllen, wenn sie an nen anderen ort sind, oder nicht???
du kannst ja so machen... das 1. rechenevent auf die position der füße setzen
nach oben bewegen lassen, position abfragen und wegdamit... oder nicht???
(weiß nicht, ob die die ganze zeit laufen, ob sie gecallt werden, oder anderweitig aktiviert werden.... aber es dürfte eigendlich kein problem darstellen...) aber das problem wäre, dass du die events alle schön in der reihenfolge von einer map zur anderen kopieren müsstest, wie du sie erschaffen hast.. (es sei denn, sie berechnen nichts bei der bewegungsabfrage... dann könntest du die lauffunktion mit nen switch starten und dann teleport event: this event auf koordinate füße machen...)

mfg
üH

Zitat:

---

Zitat von übelster Held

@ Veronan...(namenverschandeln ist so schön...^^)
laufen die 3 events die ganze zeit???
denn die werden bestimmt auch ihre aufgaben erfüllen, wenn sie an nen anderen ort sind, oder nicht???
du kannst ja so machen... das 1. rechenevent auf die position der füße setzen
nach oben bewegen lassen, position abfragen und wegdamit... oder nicht???
(weiß nicht, ob die die ganze zeit laufen, ob sie gecallt werden, oder anderweitig aktiviert werden.... aber es dürfte eigendlich kein problem darstellen...) aber das problem wäre, dass du die events alle schön in der reihenfolge von einer map zur anderen kopieren müsstest, wie du sie erschaffen hast.. (es sei denn, sie berechnen nichts bei der bewegungsabfrage... dann könntest du die lauffunktion mit nen switch starten und dann teleport event: this event auf koordinate füße machen...)

mfg
üH

---

Die Events (jedenfalls die 3, die für jeden Bot verwendet werden), laufen die ganze Zeit um den Bot selber herum.
Das Problem, dass ich alle Events von Map zu Map kopieren müsste, hab ich schon im ersten RVB1 gelöst :D .
Ich mache eine Alpha-Map. Da hau das gesamte AKS drauf. Dann kopiere ich diese Map, ändere das Chipset und kopiere die neue Map drauf. Dann gibt es 0 Probleme mit den Events^^ und ich hab auch 0 Arbeit mit den Kopieren von Events8) .
Das ist die Beste und schnellste Methode, die ich gefunden habe.

Ich muss jetzt aber leider dieses Problem lösen...

Wenn ich dich jetzt richtig verstanden habe steuern die Beine also den Oberkörper. Dieser fragt ab ob er sich bewegen kann, hat aber schon zuvor einen Befehl an den Oberkörper geschickt welches diesen bewegt (so oder so ähnlich ^^°).
Wenn dies tatsächlich so ist würde ich an deiner Stelle tatsächlich auf die IDs zurückgreifen. So wie ich das verstanden habe hat das zweite Event (der Oberkörper) keine weitere Funktion, außer sichtbar zu sein. Nun könntest du diesem Event die Möglichkeit geben sich selbst zu steuern, aber nur eingeschränkt. Ich hab mir den Code in RvB 2 mal flüchtig angeschaut (längst nicht lange genug um ihn zu verstehen ^^) und bin der Meinung, dass ein Kontroll-Event die Bewegung der einzelnen Einheiten berechnet und dann eine Variable auf einen Wert von 1-4 setzt, was dann die Einheiten dazu veranlasst sich in eine entsprechende Richtung (per Route) zu bewegen. So wäre es doch wiederum logisch auch dem Oberkörper die selbe Möglichkeit zu geben, nur in diesem Fall noch etwas erweitert. Deine Beine geben dem Oberkörper per Variable den Befehl in welche Richtung er sich bewegen soll, der Oberkörper überprüft dann die ID des Feldes auf dem er steht. Ist diese ID gleich "Freies Feld" darf er sich bewegen, ist die ID aber bereits "Geschlossenes Feld" (er ist also z.B. schon auf einer Wand) wird die Bewegung gar nicht erst ausgeführt.
Dies sollte bei einer Bewegung nach oben funktionieren, nicht jedoch bei Bewegungen in alle anderen Richtungen.
Dieses Problem zu lösen ist dann wieder etwas schwieriger, wäre aber zu machen wenn du auf einer Map nicht zu viele verschiedene Bodenarten verwendest. Dann könntest du eine weitere ID einbauen (für "Geschlossenes Feld 2" (also für unten, rechts und links), welche du den Bodenfeldern um die Hindernisse herum zuweist. Dazu musst du natürlich jede Bodenart zwei mal haben (einmal mit der ID "Offenes Feld" und einmal mit "Geschlossenes Feld 2"). Zu beachten ist dann nur noch das die Bodenfelder für "Geschlossenes Feld 2" einen Abstand von einem Feld zum Hindernis einhalten müssen sobald sie sich über einem Hindernis befinden (sonst rutscht der Oberkörper auf die Beine, da das "Geschlossenes Feld 2" Feld erst unter den Beinen liegt).

Edit
Sorry, dass mir das erst jetzt auffällt, aber eine Bewegung nach unten braucht natürlich auch ihre eigene "Block" ID. Hier verwende ich dann die ID "Geschlossenes Feld 3". Den obigen Text anzupassen würde jetzt zu lange dauern, ich schätze du kannst dir aber auch so vorstellen was ich meine ^^°
Edit Ende

Dementsprechend müsste also auch die Abfrage im Oberkörper angepasst werden (hier die verkürzte Fassung):

Code:

---

Event: Oberkörper Einheit 1

<>Fork Variable "Einheit 1 Bewegungsrichtung", 1 same //für "nach unten"
<><>Get Terrain ID [Einheit 1 X | Einheit 1 Y] -> "Einheit 1 Terrain ID"
<><>Fork Variable "Einheit 1 Terrain ID", 4 same //für "Geschlossenes Feld 3"
<><><>Move Event [This Event]: down;
<><>End:
<>Else:
<>Fork Variable "Einheit 1 Bewegungsrichtung", 2 same //für "nach links"
<><>Get Terrain ID [Einheit 1 X | Einheit 1 Y] -> "Einheit 1 Terrain ID"
<><>Fork Variable "Einheit 1 Terrain ID", 3 same //für "Geschlossenes Feld 2"
<><><>Move Event [This Event]: left;
<><>End:
<>Else:
<>Fork Variable "Einheit 1 Bewegungsrichtung", 3 same //für "nach rechts"
<><>Get Terrain ID [Einheit 1 X | Einheit 1 Y] -> "Einheit 1 Terrain ID"
<><>Fork Variable "Einheit 1 Terrain ID", 3 same //für "Geschlossenes Feld 2"
<><><>Move Event [This Event]: right;
<><>End:
<>Else:
<>Fork Variable "Einheit 1 Bewegungsrichtung", 4 same //für "nach oben"
<><>Get Terrain ID [Einheit 1 X | Einheit 1 Y] -> "Einheit 1 Terrain ID"
<><>Fork Variable "Einheit 1 Terrain ID", 2 same //für "Geschlossenes Feld 1"
<><><>Move Event [This Event]: up;
<><>End:
<>End:
<>

---

Öhm, na ja, ich hoffe das war so einigermaßen verständlich. Kann sein das ich alles was bis jetzt gesagt wurde falsch verstanden habe und das hier alles Mist ist, hoffe aber es passt trotzdem zu deinem Problem und ist auch machbar (hab es nicht getestet ^^°). (Wenn es schon mal in ähnlicher Form gesagt wurde hab ich das wohl überlesen, dann tut mir das leid XD).

Hier noch mal ein Bild wie die Terrain-IDs verteilt sein sollten:
http://www.directupload.net/images/0...p/q6sZr9be.png
Was ich noch vergessen habe: Das schwarze ist natürlich ein Hindernis, das dunkel graue die Wand darunter...


Edit 2
Beim zeichnen ist mir aufgefallen das man wohl noch 2 weitere IDs braucht XD. Auf der Skizze kannst du es ja sehen. Ich schätze ich muss den Code dafür nicht anpassen da du sicherlich gut genug bist das selber zu tun ;)
Edit 2 Ende

mfg
Phönix Tear

asso...^^... die 3 events kreisen auch schon um die figur drummrumm...
hm... naja... das gleiche problem hatte ich ja auch in dem reit-script...
ich hab aber keine andere möglichkeit gefunden...
und so viele andere möglichkeiten wird es auf dem maker auf nicht geben...
hm... wie es aussieht werden deine alpha-maps um 50 events größer...^^"

die lösung mit den alpha-maps ist übrigens ne gute idee...
aber bei der lösung muss man genau wissen, was alles so in dem spiel
reinkommen soll an technischen schnickschnack... wenn einen dann am ende
noch einfällt, dass man doch noch paar events auf jeder map braucht...^^

mfg
üH#

@ Phoenix Tear:
Also das ist doch mal eine wirklich gute Idee^^
So weit ich das verstehe, meinst du, dass genau ein Feld vor der Wand, der Boden die ID von einem nicht begehbaren Feld erhält, sodass das obere Event (dass das natürlich überprüft), erkennt, dass dort eine Wand ist und noch auf dem freien Feld (mit ID des nicht begehbaren Feldes) stehenbleibt...
Das wäre ein klein wenig schwierig, denn dann müsste ich jeden Chip, der an einer Wand grenzt, doppelt haben. Also einmal begehbar und einmal nicht begehbar (also kurz vor der Wand).
Das Problem kann man allerdings umgehen. D. h. ich lasse berechnen (bevor der Bot sich bewegt), ob 2 Felder vorm Bot eine Wand ist, und wenn der Bot weiterhin in diese Richtung geht, bleibt das 2. Event nach dem nächsten Schritt stehen...
Ein wenig um-die-Ecke-gedacht, aber dürfte funktionieren.

Ich werds sofort ausprobieren^^.

Vielen Dankhttp://www.multimediaxis.de/images/s.../old/sm_12.gif

Edit: Mist, das funktioniert zwar, aber nicht bei Chips auf der Upper-Ebene, die nicht begehbar sind. Dann muss ich alle Punkt um den Chip zu nicht begehbaren Punkten machen und dafür bleibt nicht genügend Platz auf den Chipsets (außerdem dauert das ewig für jede Map). Vielleicht finde ich dafür noch eine Lösung.

@ übelster Held:
Deswegen mach ich immer erst das gesamte AKS (bis ich zurfrieden bin und das kann dauern), bevor ich die Maps mache^^

@phönix träne
stimmt... dem oberkörper ist es ja egal, ob er sich bewegen kann oder nicht...^^...
aber wenn ein erfahrener maker sagt, dass es mit id's nicht geht, hört man irgendwie automatisch auf
mit lesen...^^
aber bräuchte man wirklich soviele verschiedene ID's ???
meiner meinung nach würde eine ander id reichen...
und zwar würde ich nicht neben dem block event die andersartigen ID's setzen sondern AUF dem unpassierbaren event...
und dann sieht der code wie folgt aus (1= runter; 2 = linkst, 3= rechts, 4= hoch):
wenn vari lauf = 1
dann position x und y der beine in einheit x und einheit y speichern...
einheit y + 1 rechnen und
Get Terrain ID [Einheit 1 X | Einheit 1 Y] -> "Einheit 1 Terrain ID

bei vari lauf = 2 rechnest du die x einheit +1
bei lauf = 3 rechnest du die x einheit -1
und bei lauf = 4 rechnest du die y einheit -2 wenn der kopf nicht in der wand sein soll
und -1 wenn die füße wirklich bis zur wand laufen können...

@ venoran
du könntest ja auf jeden uppertile ein event machen und dann
noch extra die set event id abfrage drüberlaufen lassen...
und wenn die id abfrage > 0 ist, muss da ja ein upper dings, oder
ein gegner sein...

Zitat:

---

Zitat von übelster Held

@ venoran
du könntest ja auf jeden uppertile ein event machen und dann
noch extra die set event id abfrage drüberlaufen lassen...
und wenn die id abfrage > 0 ist, muss da ja ein upper dings, oder
ein gegner sein...

---

Das würde schon funktionieren, doch dann müsste ich jede Map mit millionen Events zukleistern, bis alle Upper-Chips mit anderen IDs versehen sind. Außerdem bräucht ich für jedes Event noch Variablen zur ID-Benennung.
Und das größte Problem ist, dass jedes Event auf der Map (hab ich ausgetestet), den Maker mehr zum Rechnen gibt.
D. h. wenn hunderte Events auf der Map sind, fängt das ruckeln wieder an, und bei Maps mit vielen Upper-Chips und diesem System,wäre die Performance wieder im Eimer :(

@üH:
Stimmt, hab mal wieder nicht genug abstrahiert ^^°

@Venoran:
Eine Kombination von meiner ersten Idee und der von üH müsste doch auch das Problem mit dem Upper-Level lösen. Wenn du tatsächlich einfach jeden Bodentyp (können doch net soo viele sein, oder?) doppelt hast, einmal mit der "Begehbar-ID" und einmal mit der "Block-ID" und du unter jedes Upper-Level Tile ein "Block-ID" Lower-Level Tile packst sollte das doch möglich sein... So hast du recht wenig Code, brauchst kein weiteres Event und "nur" jeden Bodentypen doppelt...

Zitat:

---

Zitat von Phönix Tear

@üH:
Stimmt, hab mal wieder nicht genug abstrahiert ^^°

@Venoran:
Eine Kombination von meiner ersten Idee und der von üH müsste doch auch das Problem mit dem Upper-Level lösen. Wenn du tatsächlich einfach jeden Bodentyp (können doch net soo viele sein, oder?) doppelt hast, einmal mit der "Begehbar-ID" und einmal mit der "Block-ID" und du unter jedes Upper-Level Tile ein "Block-ID" Lower-Level Tile packst sollte das doch möglich sein... So hast du recht wenig Code, brauchst kein weiteres Event und "nur" jeden Bodentypen doppelt...

---

Stimmt schon^^
Nur dass bei aufwändigen Maps, dass Chipset darunter leiden muss ;) .
Aber ich hab jetzt eine Lösung gefunden :D :D
Eine Mischung aus, allen Vorschlägen (auch die mit der Terrain-ID)^^
Damit funktioniert es, aber es ist ein wenig aufwendig.
Ich muss das System nur noch ausführlich testen.

Vielen Dank für eure aufopfernde Hilfe und eure Mühe
http://www.multimediaxis.de/images/s.../old/sm_12.gif http://www.multimediaxis.de/images/s.../old/sm_12.gif :D
G.V.H.